編者按： 隨著大語言模型應用從簡單的文本生成，發展到復雜的多輪對話機器人、檢索增強生成（RAG）系統乃至智能體（Agent），我們應如何科學、有效地評估它們的性能，確保其穩定可靠？

我們今天為大家帶來的文章，作者的觀點是，對現代 LLM 應用的評估，必須超越傳統的 NLP 評估指標，轉向一個分場景、系統化的評估體系，綜合運用新興的評價指標與自動化框架，從而全面地衡量系統的綜合表現。

作者系統梳理了從傳統 NLP 評估指標（如 BLEU、ROUGE）到現代 LLM 基準測試（如 MMLU）的演進，并重點闡釋了“LLM-as-a-judge”這一新興評估范式。文章進一步深入探討了多輪對話系統、RAG 系統及智能體的關鍵評估維度，并對比了主流評估框架（如 RAGAS、DeepEval、OpenAI Evals）的功能差異與適用場景，為開發者構建可靠、可追蹤的 LLM 應用提供了清晰指引。

作者 | Ida Silfverskiold

編譯 | 岳揚

Agentic AI 評估主要在于測試 LLM 應用，以確保其表現穩定。

這或許不是很吸引人的話題，但正受到越來越多企業的重視。因此，有必要深入探討應追蹤哪些指標來有效衡量性能。

此外，在每次推送代碼變更時實施恰當的評估，也有助于避免系統出現混亂。

為此，本文研究了多輪對話機器人、RAG 及 Agentic 應用的常用評估指標。

我還簡要梳理了 DeepEval、RAGAS 和 OpenAI 評估庫等框架，助您根據使用場景選擇合適的工具。

本文分為兩部分。新手可從第一部分讀起，其中介紹了 BLEU、ROUGE 等傳統評估指標，提及了一些 LLM 的基準測試，并講解在評估中使用另一個大語言模型來充當“裁判”或“評判者”的理念。

若您已熟悉上述內容，可直接跳到第二部分閱讀。該部分將深入解析不同類型 LLM 應用的評估方法。

01 先前的評估方法

如果你已熟知 NLP（自然語言處理）任務的評估方式以及公共基準測試的運作機制，那么可以跳過這一部分。

如若不然，了解早期評估指標（如準確率、BLEU）的最初用途與工作原理，并理解 MMLU 等公共基準測試的運作方式，將是很有益處的。

02 評估 NLP 任務

在評估分類、翻譯、摘要等傳統 NLP 任務時，我們通常會借助準確率（accuracy）、精確率（precision）、F1 值、BLEU 和 ROUGE 這類傳統指標。

這些指標至今仍在沿用，但主要適用于模型輸出單一、易于比對“標準答案”的場景。

以文本分類任務為例，其目標是為每個文本分配一個唯一的標簽。測試時，我們可以使用準確率指標，通過比較模型分配的標簽與評估數據集中的參考標簽，來判斷其是否正確。

判斷標準非常明確：如果分配了錯誤的標簽，則得分為 0；如果分配了正確的標簽，則得分為 1。

這意味著，如果我們為一個包含 1000 封郵件的垃圾郵件數據集構建分類器，并且模型正確標記了其中的 910 封，那么準確率就是 0.91。

針對文本分類場景，我們還經常使用 F1 值、精確率和召回率。

在文本摘要和機器翻譯等 NLP 任務中，人們通常使用 ROUGE 和 BLEU 來衡量模型生成的譯文或摘要與參考文本的匹配程度。

這兩種分數都基于 n-gram 的重疊程度進行計算。盡管比較的側重點不同（例如，BLEU 更側重精確率，ROUGE 更側重召回率），但其核心思想都是：共享的詞語片段越多，得分就越高。

這種方式相對簡單，因為如果輸出文本使用了不同的措辭，得分就會較低。

所有傳統指標最適用于存在標準答案的應答場景，但對于如今我們構建的 LLM 應用而言，它們往往并非最合適的選擇。

03 大語言模型基準測試

如果您關注相關新聞，可能會注意到：每次新版本的大語言模型發布時，總會提及 MMLU Pro、GPQA 或 Big-Bench 等基準測試結果。

它們屬于通用性評估，其正確術語應是“基準測試”而非“評估”（后者我們將在后續討論）。

盡管針對每個模型還會進行多種評估（測試毒性、幻覺和偏見等內容），但最受關注的往往是這些更類似標準化考試或排行榜的基準測試。

像 MMLU 這樣的數據集采用多選題的形式，并且已存在相當長的時間。我曾粗略地瀏覽過其中的內容，發現其內容質量參差不齊。

部分問題和答案相當模糊，這讓我認為 LLM 提供商很可能通過針對性訓練來確保模型在這些數據集上取得佳績。

這種現象引發了公眾的擔憂：多數 LLM 在基準測試中的優異表現可能只是過擬合的結果，這也解釋了為何我們需要更高質量的新數據集與獨立的第三方評估。

04 將 LLM 用作評估器

對這些數據集進行評估時，通常仍可使用準確率和單元測試。但如今的不同之處在于，新增了所謂的“LLM-as-a-judge”方法。

為了對模型進行基準測試，團隊大多仍會采用傳統方法。

因此，只要是多選題或僅存在一個正確答案的情況，除了將答案與參考答案進行精確匹配外，無需其他操作。

像 MMLU 和 GPQA 這類包含多項選擇題答案的數據集便屬此類。

對于編程類測試（如 HumanEval、SWE-Bench），評估器可直接運行模型生成的補丁或函數。若所有測試用例通過則判定問題已成功解決，反之則失敗。

然而，不難想象，當問題存在歧義或屬于開放式問題時，答案可能會出現波動。這一差距催生了“LLM-as-a-judge”的興起，即使用像 GPT-4 這樣的大語言模型來為答案打分。

MT-Bench 就是采用 LLM 評分的基準測試之一，它將兩個相互競爭的多輪對話答案提供給 GPT-4，并要求其判斷哪個更好。

原采用人工評分的 Chatbot Arena 平臺，據我了解現也已擴展融合了“LLM-as-a-judge”模式。

為了透明起見，也可使用 BERTScore 等語義評分工具進行語義相似度比對。為保持內容精煉，此處未詳述現有方案。

因此，團隊雖仍會使用 BLEU 或 ROUGE 這類重疊度指標進行快速校驗，或在可能時采用精確匹配解析（exact-match parsing），但新的趨勢是讓另一個大語言模型來評判輸出結果。

05 當前對 LLM 應用的評估方式

現在主要的變化是，我們不再僅僅測試 LLM 本身，而是評估整個系統。

在條件允許時，我們仍會像以前一樣使用程序化的方法進行評估。

若需更精細的評估結果，可先采用成本低廉且確定性的指標（如 BLEU 或 ROUGE）來分析 n-gram 的重疊程度，不過，當前主流框架普遍采用大語言模型作為評分器進行評估。

有三個領域的評估方法和評估指標值得探討：多輪對話系統、RAG（檢索增強生成）以及智能體。

如下所示，在這三個領域已經定義了大量的評估指標。

接下來我們將簡要討論這些指標，然后再介紹那些能為我們提供幫助的不同評估框架。

06 評估多輪對話系統

首先需要構建針對多輪對話的評估體系，這類對話場景常見于聊天機器人。

與聊天機器人交互時，我們期望對話過程自然流暢、體現專業性，且能準確記住關鍵信息。我們希望它在整個對話過程中不離題，并切實解答用戶提出的問題。

目前業界已形成一系列標準的評估指標。首要關注的是相關性（連貫性）與完整性。

相關性指標用于追蹤 LLM 是否恰當地處理了用戶的查詢并保證不偏離主題；而若最終結果真正達成了用戶目標，則完整性得分就高。

也就是說，若能追蹤整個對話過程中用戶的滿意度，我們也能驗證該系統是否真正“降低了支持成本”、增加了用戶信任度，同時保持較高的“自助解決率”。

該評估體系的第二個核心維度，是知識留存能力（Knowledge Retention）與應答可靠性（Reliability）。

即：它是否記住了對話中的關鍵細節？能否確保不會“迷失方向”？僅記住細節還不夠，它還需要能夠自我糾正。

這類問題常見于智能編程工具：它們會忘記自己犯過的錯誤，然后一犯再犯。我們應將其記錄為低可靠性或低穩定性表現。

第三部分可追蹤的是角色一致性與提示詞遵循度，用于檢驗 LLM 是否始終遵循預設角色設定，是否嚴格執行系統提示詞中的指令。

接下來是涉及安全性的指標，例如幻覺和偏見/毒性。

追蹤幻覺雖重要但也相當困難。常見做法包括設置網絡搜索驗證輸出內容，或將輸出拆分為多個可獨立驗證的論點后交由更大模型評判（采用 LLM-as-a-judge 模式）。

此外還有像 SelfCheckGPT 的這類方法：它通過多次調用模型處理同一提示詞，檢查其是否堅持原始答案以及出現分歧的次數，以此檢驗模型的一致性。

對于偏見/毒性檢測，可采用微調分類器等 NLP 技術。

根據具體應用場景，可能還需其他定制化指標，例如代碼正確性、安全漏洞數、JSON 格式合規性等。

至于如何進行評估，雖然在這些情況下標準解決方案確實常用 LLM，但并非總是必須使用它。

在可以提取正確答案的場景（例如解析 JSON），我們自然不需要使用 LLM。如我之前所說，許多 LLM 提供商也會使用單元測試對代碼相關指標進行基準測試。

需要說明的是，用于評判的 LLM 并非總是超級可靠，就像它們所測量的應用一樣，但此處無法提供具體數據佐證，建議您自行查閱相關研究。

07 評估檢索增強生成（RAG）系統

承接多輪對話系統的評估思路，我們再來探討 RAG 系統需要衡量的指標。

針對 RAG 系統，我們需要將評估流程拆分為兩部分：分別衡量檢索環節與生成環節的質量。

首先要評估的是檢索環節，檢驗系統為特定查詢抓取的文檔是否精準。

若檢索環節得分偏低，可通過以下方式進行優化：制定更合理的文本分塊策略、更換嵌入模型、引入混合搜索與重排序技術、使用元數據進行過濾等方法。

評估檢索效果時，我們既可采用依賴標注數據集的傳統指標，也可以使用無需參考答案、以 LLM 作為評判者的方法。

我必須先介紹這些經典的信息檢索指標，因為它們是該領域的奠基者。使用這些指標的關鍵在于，我們需要一套“標準答案” —— 即針對每一個預設的查詢，我們都已事先為每個文檔標注好了它與該查詢的相關性等級。

雖然可以使用 LLM 來構建評估所需的數據集，但評估過程無需 LLM 參與，因為數據集中已經包含了用于比對的基準分數。

最著名的 IR 指標包括 Precision@k、Recall@k 和 Hit@k。

這三個指標分別從不同角度衡量檢索系統的表現：實際檢索到的前 k 個文檔中，有多少個是真正相關的、所有應該被檢索到的相關文檔（在標準答案里的）中，有多少個出現在了你檢索到的前 k 個結果里、在前 k 個結果里有沒有“命中”至少一個相關文檔。

而 RAGAS、DeepEval 等新興框架，則引入了一種無需參考答案且使用 LLM 對檢索結果進行評判的評估指標，如上下文召回率與上下文精確度。

這些指標通過使用 LLM 作為評估者，來統計：針對給定查詢，系統返回的前 k 個結果中，究竟包含了多少真正相關的文本塊。

也就是說，針對給定查詢，系統是否真正返回了相關文檔？是否混入了過多不相關的內容以致于無法正確回答問題？

構建檢索評估數據集時，可從真實日志中挖掘問題并由人工標注。

也可以利用 LLM 輔助的數據集生成器，這類工具存在于多數評估框架中，或者有獨立的工具提供此功能，如 YourBench。

如果要用 LLM 搭建自己的數據集生成器，可參考以下實現方案：

# Prompt to generate questions
qa_generate_prompt_tmpl = """\
Context information is below.
 
---------------------
{context_str}
---------------------
 
Given the context information and no prior knowledge
generate only {num} questions and {num} answers based on the above context.
 
...

接下來看 RAG 系統的生成部分，這部分評估的是系統利用所提供文檔回答問題的質量。

若此環節表現不佳，可采取以下措施：調整提示詞模板、優化模型參數（如溫度值）、更換基礎模型或針對特定領域進行微調。還可引入思維鏈推理循環、驗證答案自洽性等方法。

這方面，RAGAS 框架提供的 Answer Relevancy、Faithfulness 和 Noise Sensitivity 等指標非常實用。

這些指標分別驗證：答案是否切中用戶問題核心、答案中每個論斷是否都有檢索文檔支撐、以及少量無關上下文是否會誤導模型輸出。

以 RAGAS 為例，它在衡量第一個指標（Answer Relevancy）時，很可能通過以下方式計算：向 LLM 提供問題、答案及檢索到的上下文，要求其“評判該答案在 0-1 分范圍內對問題的直接回應程度”，這個過程會返回一個原始的 0-1 分值，該分值可被用于計算整體平均值。

綜上所述，我們將 RAG 系統拆分為檢索和生成兩個獨立環節進行評估。雖然可以沿用依賴標準答案的傳統信息檢索指標，但也可以選擇依賴大語言模型進行評分的無參考答案方法。

最后，我們需要探討的是，智能體（Agent）技術如何擴展了我們所需追蹤的指標范圍，這超出了我們之前已討論的所有內容。

08 評估智能體

對于智能體，我們的評估范疇不再局限于輸出結果、對話內容或上下文質量。

如今還需評估其“行為能力”：能否完成特定任務或工作流、執行效率如何，以及是否能在適當時機調用正確的工具。

盡管各評估框架對這些指標的命名可能不同，但最核心的兩項追蹤指標是任務完成度與工具調用準確率。

對于工具使用的追蹤，我們需要驗證智能體是否根據用戶查詢準確選擇了對應的工具。

這需要預先編寫包含真實場景的基準測試腳本，該腳本可一次性創建，并在每次系統變更時重復用于驗證。

對于任務完成度，評估方法是讀取完整的執行軌跡和任務目標，然后返回一個 0 到 1 之間的分數，并附上評估理由。該指標應有效衡量智能體達成任務的執行效果好壞程度。

對于智能體，你仍然需要根據您的具體應用，測試我們前面已經討論過的其他評估維度。

需要特別說明：盡管現有框架已有不少定義好的評估指標，但你的實際使用場景可能會有所不同。了解通用評估指標是有價值的，但切勿直接假定它們完全適用于你的應用場景。

接下來，我們將概覽當前主流的輔助評估框架。

09 主流評估框架概覽

目前已有不少框架能協助進行評估工作，本文將重點介紹幾個熱門選擇：RAGAS、DeepEval、OpenAI 的 Evals 庫以及 MLFlow 的 Evals，并分析它們各自的優勢及適用場景。

完整的評估框架清單可在此倉庫（??https://github.com/ilsilfverskiold/Awesome-LLM-Resources-List/blob/main/README.md\[#evaluation]()-frameworks-and-add-ons?? ）中查看。

你也可以使用許多框架內置的評估系統（如 LlamaIndex 提供的工具），特別適合快速原型驗證。

OpenAI 的 Evals 和 MLFlow 的 Evals 更像是附加組件而非獨立框架，而 RAGAS 最初是專為 RAG 應用設計的指標庫（盡管后續也擴展了其他指標）。

DeepEval 可能是現有框架中功能最全面的評估庫。

但需要指出的是，所有框架都支持對自有數據集進行評估，以不同方式兼容多輪對話、RAG 和智能體場景，都支持 LLM-as-a-judge 模式，都允許配置自定義指標，并且都能無縫接入持續集成流程。

正如前文所述，它們的差異主要體現在功能完備度上。

MLFlow 最初為傳統機器學習 pipelines 設計，因此針對 LLM 應用的預置指標較少。OpenAI 提供非常輕量的解決方案，需要用戶自行設定評估指標（盡管它提供了一個示例庫幫助入門）。

RAGAS 提供了豐富的評估指標，并且與 LangChain 集成，便于快速部署。

DeepEval 則提供了大量開箱即用的功能，其功能集完全覆蓋 RAGAS 指標。

上述對比表格的詳細內容可在此 Github 倉庫（??https://github.com/ilsilfverskiold/Awesome-LLM-Resources-List/blob/main/README.md\[#evaluation]()-frameworks-and-add-ons?? ）中查看。

通過分析各框架提供的評估指標，我們可以大致了解這些解決方案的覆蓋范圍。

值得注意的是，這些框架的指標命名尚未形成統一標準。相同含義的指標可能具有不同名稱。

例如，某個框架中的“忠實度（faithfulness）”可能等同于另一框架的“事實性（groundedness）”。“答案相關性（Answer relevancy）”與“響應相關性（response relevance）”可能指向同一概念，等等。

這使得從業者需要花費額外的心力去理解和管理這些術語差異，而不是專注于更重要的評估設計和結果分析工作。

盡管如此，DeepEval 仍以超過 40 項預置指標脫穎而出，同時提供名為 G-Eval 的框架，能快速創建自定義指標，成為從指標構思到可運行指標的最快捷路徑。

OpenAI 的 Evals 框架則更適合需要高度定制化邏輯的場景，而不僅僅是需要一個快速評判器。

根據 DeepEval 團隊反饋，開發者最常使用的是自定義指標功能。因此不必糾結于框架預置了哪些指標，您的應用場景獨一無二，評估方式也應如此。

那么，在什么情況下應該選擇哪種框架呢？

當我們需要專為 RAG pipeline 設計、開箱即用的專項指標時，請選用 RAGAS；若追求功能完整的全場景評估套件，DeepEval 是最佳選擇。

若您已深度集成 MLFlow 生態或偏好內置追蹤與可視化界面，MLFlow 值得考慮；OpenAI 的 Evals 框架最為輕量，最適合深度依賴 OpenAI 基礎設施且追求靈活定制的用戶。

最后，DeepEval 還通過其 DeepTeam 框架提供紅隊測試功能，可自動化對 LLM 系統進行對抗性測試。雖存在其他具備類似功能的框架，但實現深度通常不及此方案。

未來我將專門探討 LLM 系統對抗測試與提示詞注入防護這一有趣領域。

10 幾點補充說明

數據集業務利潤豐厚，這也反襯出當前我們能利用其他 LLM 進行數據標注或測試評分的可貴之處。

但需要注意的是，LLM 評估器并非萬能 —— 正如我們開發的任何 LLM 應用一樣，我們搭建的評估系統也可能出現不穩定的狀況。根據業界普遍做法，大多數團隊和公司會每隔幾周進行人工抽樣審核，以確保評估結果真實可靠。

我們為 LLM 應用定制的評估指標很可能需要進行個性化設置。因此，盡管本文介紹了大量現有指標，但最終你大概率需要構建自己的評估體系。

不過了解行業內的標準評估指標仍然很有價值。

希望本文能對你有所啟發。

END

本期互動內容 ??

?你有沒有遇到過“評估性能很好，但用戶體驗很差”的情況？你是怎么解決的？

本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯系獲取授權。

原文鏈接：

??https://www.ilsilfverskiold.com/articles/agentic-ai-on-evaluations??