LLM 評估：2026 年真正有效的指標、框架與實務

LLM 評估是「看起來沒問題」與「我能證明它有效」之間的差異。如果您在沒有系統化評估的情況下，將由 LLM 驅動的功能發布給使用者，本質上就是在部署未經測試的程式碼，只不過失敗模式不是堆疊追蹤（stack traces），而是幻覺、有害內容以及 silently wrong answers（無聲的錯誤答案）。

本指南涵蓋所有內容：指標、方法、框架、管線設計以及歐盟《人工智慧法案》（EU AI Act）的合規性。沒有供應商偏見，沒有廢話。

快速概覽

在深入細節之前，我們先用一張表格呈現全貌。

現在讓我們逐一拆解每個部分。

什麼是 LLM 評估（為什麼在 2026 年很重要）？

LLM 評估是針對定義的標準（準確性、相關性、安全性以及對來源資料的忠實度），系統化地測量並評分大型語言模型輸出品質的過程。它包含自動化指標、LLM 作為評判者評分以及人工審查，以確保 LLM 驅動的應用程式在生產環境中提供可靠的結果。

為什麼這現在如此重要？有兩個原因。首先，LLM 已從原型轉變為真實使用者依賴的生產功能。一個會幻覺公司政策的聊天機器人，或是一個引用不存在文件的 RAG 系統，不再只是有趣的示範 bug，而是支援工單、法律風險或流失的客戶。

其次，歐盟《人工智慧法案》將於 2026 年 8 月開始執法。如果您的 AI 系統服務於歐盟使用者，您將需要文件化的評估實踐，而不僅僅是一則 Slack 訊息說「我測試了幾個提示詞，看起來不錯」。

大多數團隊仍在進行所謂的「憑感覺的評估」（vibes-based evaluation），即在遊樂場中隨機檢查少量輸出並決定其足夠好。當 LLM 還是實驗性質時這行得通。但當它們成為功能時，這就行不通了。

評估回答三個問題：輸出是否正確？是否安全？是否有用？本指南的其餘部分將向您展示如何系統化地回答這三個問題。

一個重要的區別：本指南涵蓋應用程式評估，測試您的 LLM 驅動產品在實際任務中的表現。這不同於模型評估（如 MMLU 等預訓練基準測試），後者告訴您基礎模型的一般表現，但幾乎無法說明它在您的特定應用程式中會如何運作。

**重點：**如果您在沒有系統化評估的情況下發布 LLM 功能，您就像是在盲飛。問題不在於是否要評估，而在於如何評估。

LLM 評估指標：測量什麼以及何時測量

您追蹤的指標完全取決於您正在建構的內容。聊天機器人需要的評估與程式碼生成器不同。以下是一個按用例組織的實用分類法，而非按字母順序排列。

文本相似度指標（當您擁有參考答案時）

這些經典指標將生成的文本與已知正確的參考進行比較：

• BLEU 測量 n-gram 精確度，即輸出中有多少詞序列與參考匹配。最初設計用於機器翻譯。
• ROUGE 測量召回率，即參考內容中有多少出現在輸出中。常用於摘要任務。
• BERTScore 使用上下文嵌入來測量語義相似度，捕捉 BLEU 和 ROUGE 忽略的改寫。

缺點？這些僅在您有地面真值（ground truth）答案可比較時才有效。對於開放式生成，請跳過 BLEU，因為它會懲罰創意改寫，而這正是優秀聊天機器人所需要的。

語義評估指標（當您需要意義而非完全匹配時）

對於開放式生成，您需要評估意義的指標：

• 答案相關性評分回應是否真正解決了使用者的問題。
• 連貫性測量輸出的邏輯流暢度。
• 簡潔性標記不必要的冗長回應。
• G-Eval 是靈活的選項：您用自然語言定義自訂評估標準，然後讓 LLM 評判者評分輸出，使用思維鏈（chain-of-thought）推理。這是 2026 年大多數團隊花費時間的地方。

RAG 專屬指標

如果您正在建構檢索增強生成（RAG），您正在評估兩個組件：檢索器和生成器。Ragas 框架定義了四個核心指標：

• 忠實度：答案是否基於檢索到的上下文？這能捕捉幻覺。
• 上下文相關性：檢索器是否拉取了正確的文件？
• 上下文召回率：檢索器是否找到了所有相關文件？
• 答案相關性：回應是否真正解決了查詢？

安全與合規指標

這些指標保護您的使用者和公司：

• 幻覺率：針對已知來源的事實正確性
• 有害性檢測：有害、冒犯性或不適當的內容
• 偏差測量：不同人口統計群體間的差別待遇
• PII 洩漏檢測：個人數據出現在輸出中

哪些應用程式對應哪些指標？

這是沒有任何供應商指南會給您的表格。與其按字母順序列出每個指標，不如將您的應用程式類型與真正重要的指標相匹配：

重點：不要測量所有東西。選擇 3-5 個符合您應用程式類型的指標並專注於此。

您實際上如何運行評估？（三種方法）

有三種方法可以評估 LLM 輸出。大多數生產團隊都使用這三種方法，但比例非常不同。

自動化指標（快速、便宜、有限）

使用 BLEU、ROUGE、完全匹配或正則表達式模式等指標進行基於腳本的評分。您編寫一個測試，它在幾毫秒內運行，並獲得通過/失敗結果。

優點：速度快、可重複且幾乎免費。缺點：這些指標無法判斷細微差別、創意或現實世界的幫助性。一個在 ROUGE 上得分完美的回應，對使用者來說可能仍然毫無用處。

在回歸測試、CI/CD 閘道以及需要速度勝過深度的大量篩選中使用自動化指標。

LLM 作為評判者（2026 年的預設值）

這是業界目前的落腳點。您使用單獨的 LLM（通常是 GPT-4o 或 Claude）根據您的標準對輸出進行評分。G-Eval 模式的工作原理如下：用自然語言定義您的評估標準，將標準加上測試用例提供給評判者，它會產生思維鏈推理以及分數。

Zheng 等人的研究顯示與人類評分約有 81% 的相关性，這對於日常評估來說已經足夠好，只要您了解失敗模式（更多內容見下一節）。

在開放式生成、主觀品質評估以及簡單指標無法捕捉的自訂標準中使用 LLM 作為評判者。

人工評估（黃金標準，無法擴展）

專家審查員使用評分規則、李克特量表或 A/B 盲測對輸出進行評分。沒什麼比得上人類閱讀回應並說「這確實有幫助」或「這會讓使用者困惑」。

問題在於：每次評估成本為 $5-50，耗時數分鐘而非數毫秒，且您無法在每個請求上運行它。使用人工評估來校準您的 LLM 評判者、合規審計以及驗證邊緣案例。

選擇您的方法

**重點：**對 80% 的評估使用 LLM 作為評判者，對 CI/CD 閘道使用自動化指標，對校準和合規使用人工審查。這就是 2026 年的劇本。

LLM 作為評判者：工作原理與失敗時刻

LLM 作為評判者已成為預設的評估方法，原因很充分：它靈活、相對便宜，且與人類判斷有良好的相關性。但它存在真正的盲點，而供應商指南通常 conveniently skip（方便地跳過）這些內容。

G-Eval 如何運作

模式很直接。您用自然語言定義什麼是「好」，評判 LLM 閱讀您的標準以及被評估的輸出，逐步推理，並產生分數。

這是一個使用 DeepEval 的 G-Eval 實現 的實際範例：

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

correctness_metric = GEval(
    name="Correctness",
    criteria="Determine if the output is factually correct based on the expected output.",
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.7,
)

test_case = LLMTestCase(
    input="What is the capital of France?",
    actual_output="Paris is the capital of France.",
    expected_output="The capital of France is Paris.",
)

correctness_metric.measure(test_case)
print(f"Score: {correctness_metric.score}")  # 0.0 to 1.0
print(f"Reason: {correctness_metric.reason}")

您可以定義任何標準，如正確性、幫助性、專業性、品牌語音合規性，評判 LLM 將據此評分。

已知偏差（供應商指南不會告訴您的事）

大多數評估指南到此為止。他們向您展示設置然後繼續。但 LLM 評判者具有系統性偏差，可能會無聲地腐蝕您的評估結果：

• **位置偏差：**在比較兩個輸出（A/B 測試）時，LLM 評判者始終偏好首先呈現的選項。交換順序，「贏家」就會改變。
• **自我偏好偏差：**GPT-4 對 GPT-4 輸出的評分高於 Claude 對相同輸出的評分，反之亦然。評判者偏向自己的模型家族。
• **冗長偏差：**無論實際品質如何，較長的回應獲得較高分數。500 字的答案得分高於更清晰表達相同內容的 100 字答案。
• **錨定偏差：**如果您向評判者顯示先前的分數或範例，後續評分會被拉向這些錨點。

減輕評判者偏差

一旦您了解這些偏差，它們是可以管理的：

1. 隨機化選項順序在 A/B 比較中（修復位置偏差）
2. 使用不同的模型家族作為評判者而非您的生成器（修復自我偏好）
3. 在評分標準中包含長度歸一化指令（修復冗長偏差）
4. 運行多評判者小組，使用 2-3 個不同的 LLM 並平均重要評估的分數

**重點：**LLM 作為評判者效果出奇地好，但前提是您知道它的盲點。在完全信任它之前，務必針對您的特定用例進行人類評分驗證。

評估 RAG 系統：忠實度、相關性與召回率

RAG 評估是 2026 年最常見的評估用例，並且與評估獨立 LLM 根本不同。您正在測試兩個組件：檢索器和生成器，其中任何一個失敗都會產生不良輸出。

四個核心指標

• 忠實度：生成的答案是否真正基於檢索到的上下文？聽起來正確但包含檢索文件中不存在資訊的回應是幻覺。這是您最重要的指標。
• 上下文相關性：檢索器是否拉取了與查詢真正相關的文件？垃圾進，垃圾出。
• 上下文召回率：檢索器是否找到了所有相關文件，還是遺漏了關鍵上下文？
• 答案相關性：即使檢索完美，最終回應是否真正解決了使用者的詢問？

使用 Ragas 運行 RAG 評估

Ragas 是專為 RAG 評估打造的框架。以下是核心模式：

from ragas import evaluate
from ragas.metrics import faithfulness, context_relevancy, answer_relevancy
from datasets import Dataset

# Your evaluation dataset
eval_data = {
    "question": ["What is our refund policy?"],
    "answer": ["You can request a refund within 30 days of purchase."],
    "contexts": [["Refund Policy: Customers may request a full refund within 30 days."]],
    "ground_truth": ["Customers can get a refund within 30 days."],
}

eval_dataset = Dataset.from_dict(eval_data)

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, context_relevancy, answer_relevancy],
)
print(result)
# {'faithfulness': 0.95, 'context_relevancy': 0.88, 'answer_relevancy': 0.91}

常見的 RAG 評估錯誤

三種反覆絆倒團隊的模式：

1. 僅評估生成器而忽略檢索器品質。您的答案可能是從錯誤文件中完美生成的。
2. 對 RAG 使用 BLEU 或 ROUGE，這些指標根本無法檢測幻覺。回應可能在 ROUGE 上得分很高，同時包含虛構資訊。
3. 未使用對抗性查詢進行測試，破壞檢索的邊緣案例（模糊查詢、超出範圍的問題、沒有相關文件的查詢）是 RAG 系統失敗最嚴重的地方。

如果您正在為您的 AI 應用程式選擇正確的技術棧，請確保您的基礎設施從一開始就支持評估，事後補上總是更困難。

**重點：**RAG 評估是不可妥協的。faithfulness 和 context_relevancy 是您必須追蹤的兩個指標。其他都是次要的。

評估 AI 代理：超越單次呼叫指標

代理評估是事情變得真正困難的地方。與聊天機器人或 RAG 系統不同，代理採取多個步驟、使用工具、做出決策，並可能朝意想不到的方向發展。傳統的單次呼叫指標無法捕捉這一點。

代理專屬指標

• 任務完成率：代理是否完成了整體目標？這是您的北極星指標。
• 工具使用正確性：它是否使用正確的參數調用了正確的工具？使用錯誤過濾器調用資料庫查詢的代理可能會用錯誤數據「完成」任務。
• 上下文保留：代理在多步驟工作流程中是否保持連貫的上下文，還是失去了對其所做事情的追蹤？
• 每成功任務成本：代理可能會燒盡 API 呼叫。一個需要 47 次 LLM 呼叫才能完成本應只需 5 次呼叫的任务的代理，是一個生產成本問題。
• 錯誤恢復：當工具呼叫失敗或返回意外結果時，代理是適應還是陷入循環？

統計測試挑戰

使代理評估根本不同的地方在於：代理行為是非確定性的。運行同一任務十次，您可能會得到七次成功、兩次部分完成和一次無限循環。您需要統計評估，運行每個測試案例 N 次並報告完成率，而非通過/失敗。

框架正在趕上。DeepEval 現在包含代理專屬指標，AWS 也發布了代理評估模式。但老實說，工具仍处于早期階段。如果您正在生產環境中部署 AI 代理，請預期需要建構一些自訂評估邏輯。

**重點：**代理評估仍處於早期階段，但任務完成率和每任務成本是您從第一天起就應該追蹤的兩個指標。

LLM 評估框架比較

每個現有的框架比較都是由供應商撰寫，將自己排在第一位。這是中立版本。

如果...請選擇這個

• 您剛開始： DeepEval 或 Ragas，兩者皆免費、文件完善、設置快速
• 您使用 LangChain： LangSmith，深度整合使其成為阻力最小的路徑
• 您需要 CI/CD 阻擋： Braintrust，唯一原生阻擋評估失敗部署的工具
• 您想要自託管可觀察性： Langfuse，最佳開源追蹤 + 評估組合
• 您需要生產監控： Arize Phoenix，最強的嵌入分析和漂移檢測
• 您僅評估 RAG： Ragas，專門打造、輕量級、最佳 RAG 指標

若要深入了解每個工具及其定價細分和設置指南，請參閱我們的 最佳 LLM 評估工具 [即將推出]。

**重點：**沒有單一的「最佳」框架。自訂指標選 DeepEval，RAG 選 Ragas，CI/CD 選 Braintrust，自託管可觀察性選 Langfuse。選擇符合您工作流程的那一個。

建構您的評估管線：從臨時到自動化

大多數建構 LLM 功能的團隊都卡在我們稱為第 1 級的阶段——手動檢查少量輸出並希望一切順利。以下是進展方式。

評估成熟度模型

建構黃金數據集

您的評估品質取決於您的測試數據。從 50-100 個手工策劃的範例開始，這些範例代表真實的使用者查詢，包括邊緣案例和對抗性輸入，並覆蓋預期行為的全部範圍。

對您的數據集進行版本控制。它們應隨著您的產品演進而演進，新功能意味著新的測試案例。六個月前的黃金數據集可能無法反映您使用者今天的行為。

評估結果的品質等於地面真值的品質。投入時間。

CI/CD 整合

一旦您擁有黃金數據集，將其連接到您的部署管線。在每個触及提示詞、檢索邏輯或模型配置的 PR 上運行評估，以便每次 提示詞工程 更改在發布前都被測量，而不是憑直覺發布。設置分數閾值，例如 faithfulness >= 0.8 和 hallucination_rate < 0.05，如果失敗則阻擋部署。

這是一個最小的 GitHub Actions 設置作為起點：

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths: ['prompts/**', 'src/llm/**']
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install deepeval
      - run: deepeval test run tests/eval_suite.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

這會在有人更改提示詞文件或 LLM 相關程式碼時觸發評估。如果任何指標低於閾值，PR 無法合併。這就是 LLM 應用程式的回歸測試。

生產監控

一旦進入生產環境，採樣並評估即時流量——通常為 1-5%。隨時間追蹤指標漂移，因為模型更新、數據變化和使用者行為轉變都可能在不被察覺的情況下降低品質。

當指標低於閾值時設置警報。記錄所有評估以供合規審計（當歐盟《人工智慧法案》審計到來時，您會感謝自己）。正如 Gergely Orosz 指出，評估需要是一個連續的過程，而非發布時的勾選框。

**重點：**大多數團隊卡在第 1 級（憑感覺）。到達第 2 級（黃金數據集）只需一天，並大幅改變您發布 LLM 功能的信心。

歐盟《人工智慧法案》與 LLM 評估：合規所需內容

這是其他評估指南未涵蓋的部分，隨著 2026 年 8 月執法臨近，這部分對工程主管和 CTO 最為重要。

歐盟《人工智慧法案》的要求

歐盟《人工智慧法案》（法規 2024/1689） 按風險等級對 AI 系統進行分類並相應施加要求。高風險系統需要系統化評估、文件和持續監控。即使是「有限風險」系統（大多數 LLM 應用程式屬於此類）也有透明度和文件義務。

關鍵點：即使您不在歐盟，如果您的 AI 系統服務於歐盟使用者，這些規則也適用於您。歐盟委員會的風險分類框架 幫助您確定您的系統屬於哪裡。

將評估實踐映射到合規性

以下是您的評估指標如何直接連接到歐盟《人工智慧法案》條款：

合規性的紅隊測試

歐盟《人工智慧法案》要求對高風險系統進行對抗性測試。紅隊測試意味著系統化地嘗試破壞您的系統：

• 提示詞注入：使用者能否操縱系統提示詞？
• 越獄嘗試：使用者能否繞過安全指南？
• 偏差探測：系統是否對不同人口統計群體有不同對待？
• 數據提取：使用者能否提取訓練數據或 PII？

記錄一切：方法論、發現、緩解措施。至少安排每季度紅隊演練。

2026 年 8 月就緒的實際步驟

1. 分類您的 AI 系統風險等級（大多數 LLM 應用程式為「有限風險」）
2. 現在建立評估指標和閾值
3. 在 CI/CD 中實施自動化評估
4. 設置帶有審計日誌的生產監控
5. 正式記錄您的評估方法論
6. 安排定期紅隊演練
7. 準備事件響應程序

**重點：**即使您不在歐盟，《人工智慧法案》也在設定全球標準。現在建立評估和文件實踐可以避免以後的匆忙。

常見評估錯誤（以及如何避免）

在幫助團隊設置 LLM 評估管線後，這些是我們反覆看到的錯誤：

1. 使用訓練數據進行評估：如果您的測試案例與模型在微調期間看到的內容重疊，您的分數就毫無意義。始終使用保留的評估集。
2. 對開放式任務使用 BLEU/ROUGE：這些指標測量表面層級的文本重疊。它們無法檢測幻覺、評估幫助性或判斷創意品質。
3. 盲目信任基準測試：基準測試污染是真實存在的。在 MMLU 問題上訓練的模型在 MMLU 上得分良好，但這並不意味著它們在您的特定任務上表現良好。始終使用應用程式專屬評估。
4. 跳過人類校準：在信任 LLM 作為評判者之前，需要針對您的數據進行人類評分驗證。至少通過人類審查員和 LLM 評判者運行 50 個範例，然後檢查相關性。
5. 一次性評估：評估不是發布時的勾選框。模型會變化，使用者行為會轉變，檢索品質會下降。使其連續化。
6. 使用相同的模型作為評判者和生成器：自我偏好偏差會 inflate scores（膨脹分數）。使用不同的模型家族進行評判。
7. 未對評估數據集進行版本控制：您的評估應隨您的產品演進。追蹤變化，添加新的邊緣案例，淘汰過時的測試案例。
8. 忽略成本：對每個生產請求運行 LLM 作為評判者會迅速變得昂貴。明智地採樣——1-5% 的流量足以進行監控。

Techsy 如何處理 LLM 評估

我們已為跨聊天機器人、RAG 系統和 AI 代理發布 LLM 功能的初創團隊建構了評估管線。我們的典型參與遵循以下模式：

1. 審計：我們審查您當前的 LLM 輸出，識別失敗模式，並映射您在成熟度模型上的位置
2. 指標選擇：根據您的應用程式類型，我們定義真正重要的 3-5 個指標（使用本指南中的框架）
3. 黃金數據集創建：我們建構您的初始評估數據集，包括大多數團隊錯過的對抗性邊緣案例
4. 管線設置：CI/CD 整合，帶有自動化評分和部署閘道
5. 移交：您的團隊從此擁有它，並附帶文件和操作手冊

大多數團隊不需要外部夥伴來做到這一點，如果您有一位 ML 工程師和一週的專用時間，本指南提供了您需要的一切。但如果您時間緊迫、面臨合規截止日期，或希望獲得有關評估策略的經驗豐富的第二意見，我們很樂意提供幫助。

需要幫助為您的 LLM 應用程式建構評估管線嗎？獲取免費諮詢

常見問題

您如何評估 LLM 性能？

首先定義您的成功標準，準確性、安全性、相關性或對您的用例重要的任何內容。選擇 3-5 個符合您應用程式類型的指標（參見上面的指標到應用程式表），建構至少包含 50 個測試案例的黃金數據集，並使用 DeepEval 或 Ragas 等框架運行自動化評估。在信任自動化分數之前，針對樣本進行人類判斷驗證。

用於評估 LLM 的指標有哪些？

核心指標包括 RAG 系統的忠實度、答案相關性和幻覺率；翻譯和摘要的 BLEU 和 ROUGE；安全性的有害性和偏差；以及代理的任務完成率。正確的指標取決於您的應用程式類型，聊天機器人需要的評估與程式碼生成器不同。

什麼是 LLM-as-a-judge？

一種方法，其中單獨的 LLM（通常是 GPT-4o 或 Claude）根據您定義的標準評估另一個 LLM 的輸出。G-Eval 是最流行的實現，使用思維鏈評分。研究顯示與人類評級約有 81% 的相關性，使其成為 2026 年日常評估的實際預設值。

您如何檢測 LLM 中的幻覺？

使用將生成文本與來源文件進行比較的忠實度指標。DeepEval 和 Ragas 都提供內建的幻覺檢測，檢查輸出中的每個主張是否基於提供的上下文。對於生產系統，將自動化檢測與對標記輸出手動抽查相結合。

最好的 LLM 評估框架是什麼？

沒有單一的最佳選擇。DeepEval 用於自訂指標和綜合評估，Ragas 用於 RAG 專屬評估，Braintrust 用於 CI/CD 整合和部署阻擋，LangSmith 用於已使用 LangChain 的團隊，Langfuse 用於自託管可觀察性。選擇符合您工作流程的那一個。

您如何評估 RAG 系統？

測量四個指標：忠實度（答案是否基於上下文？）、上下文相關性（檢索到正確文件了嗎？）、上下文召回率（找到所有相關文件了嗎？）和答案相關性（解決查詢了嗎？）。Ragas 和 DeepEval 是標準工具。關鍵的是，評估檢索器和生成器兩者，大多數團隊只測試生成器而錯過檢索失敗。

什麼是 G-Eval？

G-Eval 是一個 LLM-as-a-judge 框架，使用思維鏈提示詞根據自訂標準評估輸出。您用 plain English 描述什麼是「好」，評判 LLM 推理每個輸出並分配分數。Liu 等人發表的原始論文顯示在多個 NLG 任務中與人類評估有強烈的一致性。

歐盟《人工智慧法案》如何影響 LLM 評估？

歐盟《人工智慧法案》要求服務於歐盟使用者的 AI 系統進行系統化評估、文件和監控。高風險系統必須通過正式評估實踐證明準確性、魯棒性、透明度和非歧視性。即使是有限風險系統也有透明度義務。執法於 2026 年 8 月開始，要求適用於任何服務歐盟使用者的公司，無論您位於何處。

您如何評估 AI 代理？

追蹤任務完成率、工具使用正確性、跨步驟的上下文保留和每成功任務成本。代理評估需要統計方法，多次運行同一任務並報告完成率，而非單次通過/失敗結果。工具仍處於早期階段，但 DeepEval 和 AWS 都提供新興的代理評估框架。

什麼是基準測試污染？

當 LLM 訓練數據包含基準測試問題時，人為地 inflate scores（膨脹分數）而不反映真實能力。這就是為什麼像 MMLU 這樣的公共基準測試不應是您唯一的評估方法。模型可能在受污染的基準測試上得分令人印象深刻，而在現實世界任務中表現不佳。始終用您自己數據的應用程式專屬評估來補充基準測試。

LLM 評估的成本是多少？

DeepEval 和 Ragas 等開源工具是免費的。LLM-as-a-judge 的成本約為每次評估 $0.01-0.05，取決於評判模型。Braintrust 和 LangSmith 等商業平台為小團隊提供免費層級，為生產使用提供付費方案。人工評估運行成本為每次評估 $5-50。大多數團隊可以以每月低於 $100 的成本運行堅實的評估管線。

來源

• DeepEval 文件，指標
• Ragas 文件，指標
• Braintrust 文件，評估
• LangSmith 文件，評估
• Langfuse 文件，分數和評估
• Arize Phoenix 文件
• 歐盟《人工智慧法案》，全文（法規 2024/1689）
• 歐盟《人工智慧法案》，風險分類（歐盟委員會）
• Judging LLM-as-a-Judge, Zheng et al., 2023
• G-Eval: NLG Evaluation using GPT-4 -- Liu et al., 2023
• How to Build an LLM Evaluation Framework, The Pragmatic Engineer