如何評估 AI 代理程式：測試集、評分器及回歸檢查

每一款出色的 AI 產品背後，都有一套完善的 AI 代理程式評估流程，即所謂的評估（evals），能及早發現錯誤，確保代理程式正常運作。對於代表他人執行退款等高風險操作的 AI 代理程式而言，評估至關重要。

建立這套流程需要一定的技術知識和數據分析能力，但其實遠沒有聽起來那麼可怕或難以入手。為了幫助你起步，我們整理了評估 AI 代理程式的六個實用步驟，以及會令流程失效的常見誤解。

評估 AI 代理程式是甚麼意思？

評估 AI 代理程式，是指評估它能否正確完成任務，以及其決策是否符合機構的要求。具體而言，AI 代理程式評估（又稱evals）是一些特定指標，協助機構判斷代理程式是否足夠可靠，能勝任其預定角色。

設想一家製造廠使用 AI 採購代理程式，負責檢查備用零件庫存並準備補貨申請。如果某個已核准的零件缺貨，或供應商資料已過時，代理程式會標示問題，還是會建議使用未經核准的替代品？

如果你為了修正這個問題而修改它的系統提示，又怎樣知道自己沒有引入另一個問題？

如果沒有評估機制，產品經理基本上只能靠猜測。因此，評估能提供回饋訊號，讓你衡量表現、發現反覆出現的問題，並更有信心地測試變更。

具體來說，代理程式評估可以檢視一次運行的多個方面：

• 最終結果的質素
• 代理程式所使用的資訊
• 它調用的工具
• 是否遵守規範其行為的規則

常見的 AI 代理程式評估指標

評估適用於定性和定量數據。定性評估幫助你了解發生了甚麼事及其原因，包括人手審查代理程式的決策。定量評估則將這些觀察轉化為可量度的訊號，例如統計特定失敗模式的出現次數，或計算任務成功率。

以下是 AI 代理程式評估的基本指標：

• 任務成功率衡量代理程式是否達成預期結果，通常以產生有效結果的運行次數百分比來計算。
• 操作正確性衡量代理程式是否恰當地使用工具、選擇有效參數，並遵守權限設定。
• 答案質素評估最終輸出是否準確、完整和有用，可包括事實正確性、對指示的遵從程度，以及代理程式是否以現有資訊支持其決策。
• 可靠性衡量代理程式在重複試驗、不同輸入及邊緣情況下的一致性。
• 成本與延遲衡量取得成功結果所需的資源，包括執行時間、token 用量及工具調用次數。

視乎你要量度的內容，評估可以衡量代理程式的端到端表現、執行軌跡，或工具調用和檢索步驟等個別組件。

第 1 步：定義怎樣才算代理程式成功運行

首先，明確描述代理程式應完成的工作，也就是產品需求。這聽起來理所當然，但實際上可能出乎意料地困難，甚至有個專門名稱：規格落差（specification gap）。

我們的資深數據科學家 Andrey Khomutov 建議這樣入手：

「先問兩個問題：『怎樣才算完成了工作？』以及『甚麼情況會令一次看似成功的運行變得不可接受？』

對代理程式而言，從技術角度來看，這意味着既要檢查結果，也要檢查它是如何得出結果的。」

代理程式可能透過存取外洩的標準答案而得出正確答案，或在完成任務時採取未經授權的操作。Khomutov 指出，答案外洩和評估期間的不安全操作，都是不應單憑最終答案作判斷的具體原因。

「我預計軌跡檢查將成為代理程式評估套件的標準環節，而不只是在結果看起來可疑時才做的事。」他補充說。

然後，請領域專家驗證你的成功標準。具備該領域實際經驗的人，能判斷我們為 AI 代理程式設定的條件是否真正反映成功的結果。

第 2 步：根據真實任務和失敗案例建立測試集

檢視代理程式的實際行為，了解良好和欠佳的表現是怎樣的。要抵住誘惑，不要一開始就只憑自己猜想可能出錯的地方，生成數十個測試。

Parlance Lab 的機器學習工程師 Hamel Husain 與機器學習系統及應用 AI 評估研究員 Shreya Shankar 建議從錯誤分析入手，這是借鑑自機器學習和數據科學的技術。整個流程從對代理程式執行追蹤記錄進行定性分析開始，這些記錄會顯示用戶的輸入、工具調用、檢索到的資訊及代理程式的輸出。

1. 審閱個別追蹤記錄並標註錯誤（開放式編碼）。請領域專家檢查代理程式的運行情況，並簡短記下出錯之處。重點關注第一個有意義的錯誤。
2. 將觀察結果歸納為失敗模式（主軸編碼）。累積足夠筆記後，可使用 LLM 為相似錯誤建議分類，例如推薦不兼容的零件、庫存檢索不準確，以及轉交真人處理失敗。
3. 統計出現次數。將每項觀察歸入一個類別，然後使用試算表或樞紐分析表計算每種失敗模式出現的頻率。
4. 決定優先處理的項目，同時考慮出現頻率和嚴重程度。
5. 將重要的失敗轉化為測試案例。保存相關輸入、初始條件、預期結果和評分標準，以便日後在同一情境下再次測試代理程式。

應該檢查多少條追蹤記錄？大約 100 條，但並無硬性規定。一旦達到理論飽和，即審閱更多追蹤記錄也不再發現有意義的新失敗模式時，便可提早停止。

應用程式尚未推出？合成範例可以幫助建立初始測試集，但一旦有真實用戶數據，就應盡快據此完善測試集。

基準測試在 AI 代理程式評估中的應用

除了建立自己的測試案例，你亦可以使用現有的標準化評估任務集，即所謂的基準測試，來評估代理程式的能力。

但基準測試並非萬無一失。SWE-bench 審核、Epoch AI 的基準測試審查，以及TheoPhysEval 中最初被判錯的正確答案，都說明了有缺陷的任務或預期答案會如何扭曲評估結果。

正如 Khomutov 所建議，應選擇與你的領域相關且最新的基準測試，並在將分數視為代理程式表現的可靠證據之前，先調查意料之外的通過或失敗結果。

第 3 步：在可重複的測試環境中運行代理程式

可重複的測試環境是一個受控的設置，讓你可以在相同的初始條件下，以相同的測試案例運行 AI 代理程式並比較結果。這包括一個存放測試案例的資料夾、一個運行代理程式的 Python 腳本，或一組評估結果的檢查。

你可以先將具代表性的輸入儲存為 JSON 檔案，再使用 Python 腳本執行代理程式的工作流程，並以斷言檢查其輸出。以我們製造廠的庫存代理程式為例，可重複的測試環境可能是這樣的：

放大

要設置可重複的測試環境，請按照以下步驟：

1. 儲存具代表性的輸入。以應用程式在正式環境中接收的相同結構，儲存實際事件或測試案例。在我們的情境中，你會將一份包含機器 ID、所需備用零件和維修日期的維修申請儲存為 JSON 檔案，並同時保存庫存和已核准零件數據的快照。
2. 執行工作流程。讓每個輸入經過代理程式處理，包括其檢索步驟、工具調用和回應生成。
3. 記錄結果和追蹤記錄。擷取最終輸出及相關的中間操作（例如庫存查詢），這樣你不僅能看到代理程式是否失敗，還能看到它在何處失敗。
4. 根據失敗的嚴重程度、頻率及修正問題的難度，重複運行案例。LLM 應用程式具有非確定性（相同輸入可能產生不同結果），因此一次成功運行並不保證下一次也會成功。請報告成功試驗的比例，並檢查失敗的案例。

就後者而言，Khomutov 建議量度 pass@1（代理程式單次嘗試即成功的頻率）和 pass@k（在指定嘗試次數內至少成功一次的機率）。如果報告 pass@k，請註明嘗試次數，因為在多個答案中得出一個正確答案，並不代表代理程式知道應該選擇哪一個。

隨着應用程式規模擴大，可使用 pytest 等測試框架來組織和運行測試，並考慮將大型測試數據集和結果儲存在數據庫中。

第 4 步：為每項檢查選擇合適的評分器

評分器（亦常稱為評估器）是一種機制，可以是一段程式碼、一個由評分準則引導的 LLM，或一位人工審閱者，用於根據既定標準檢查代理程式的輸出或操作。評分器會回傳通過／不通過的判斷，並附上指出相關證據的說明。

資訊：評分準則是一組標準和指示，用於界定怎樣才算正確或可接受的結果。

合適的評分器類型取決於你想驗證甚麼。以下是三種方法的比較：

有時同一次運行的不同方面可能需要不同的評估方法，因此你或須結合多種評分器。

如何結合評分器？

問問自己：「結果能否根據已知規則或預期值來驗證，還是需要類似人類的判斷？」

• 如果可以精確驗證結果，請先使用基於程式碼的評分器。基於程式碼的評分器亦可驗證結構化輸出、有效的欄位值、工具參數或數據庫的最終狀態。
• 如果檢查需要解讀情境，請使用 LLM 評審（LLM-as-a-judge）。
• 對於特定領域或有爭議的決策，請交由人工審閱者處理。

重要！LLM 評分器可能會誤解證據，或錯誤套用評分準則，因此需要額外的評估步驟：以人工判斷進行校準。

以人工判斷校準 LLM 評分器。

基本上，校準需要由領域專家評估代理程式的實際運行，然後將自己的判斷與 LLM 的判斷作比較，並根據分歧之處完善評分準則。

以下是五個步驟的評分器校準流程：

1. 收集代理程式輸入、輸出及相關追蹤記錄的範例。
2. 請領域專家獨立評估每個範例是否符合評估標準。
3. 以這些範例運行 LLM 評分器。
4. 比較人工判斷與模型判斷。
5. 調查分歧之處並完善評分器的評分準則，然後再以新範例進行測試。

Khomutov 亦強調，須另行測試 LLM 評分器的一致性：

「將完全相同的已儲存運行記錄和檔案多次交給它，而不重新運行代理程式。這樣就能把代理程式工作上的差異與評分上的差異區分開來。」

如果同一輸出得到不同的判定，不要假設每次分數變化都源於代理程式。相反，應檢視混淆矩陣，了解評分器何時正確識別錯誤、何時遺漏錯誤，以及何時錯誤標示了可接受的輸出。

人工審閱對於建立參考判斷、解決有爭議的案例，以及發現現有評分器原本未設計偵測的新失敗模式，仍然不可或缺。

第 5 步：比較不同版本並進行回歸檢查

假設錯誤分析顯示，你的庫存代理程式經常推薦未經核准的替代零件。你修改了它的系統提示，要求進行明確的兼容性檢查。原本失敗的案例現在通過了。但你怎樣知道這項變更沒有影響其他任務？

這正是回歸測試派上用場的時候。

回歸測試是指在更改代理程式的提示、模型或工作流程後，重新運行先前成功的測試案例，以確保變更沒有引入新的失敗。

1. 使用測試集中已儲存的輸入重現原本的失敗。
2. 對提示、模型或工作流程作出針對性的變更。
3. 重新運行失敗的測試，檢查問題是否已解決。
4. 執行其他測試，確認是次變更沒有破壞先前運作正常的行為。
5. 檢查結果，並調查任何新出現的失敗。

使用相同的測試案例和評分準則，比較基準版本與更新後的代理程式，以取得準確結果。

第 6 步：監察 AI 代理程式在生產環境中的表現

部署應用程式後，代理程式評估並不會就此結束。正如 Husain 和 Shankar 所解釋，你在開發期間使用的評估器，同樣可以在真實的生產數據上執行，以衡量代理程式隨時間推移的表現。

這稱為線上評估，是更廣泛的生產環境監察流程的一部分，有助發現反覆出現及先前未知的失敗。

這個流程需要反覆迭代，涉及四項相輔相成的工作：

• 在生產環境追蹤記錄上執行已校準的 LLM 評審。抽樣真實的代理程式互動，並套用你已對照人工判斷驗證過的評估器。
• 持續追蹤失敗率的變化。運用錯誤分析期間建立的失敗類別，量化反覆出現的問題。
• 持續人手審閱追蹤記錄。自動評分器只能偵測其設計所針對的問題。請人手檢查真實代理程式互動的樣本，以發現新的錯誤或不尋常的用戶要求。
• 使用 A/B 測試衡量業務成果（僅在適用時）。使用任務完成度、用戶滿意度和解決時間等指標，比較不同的提示、模型或工作流程。這個流程有助判斷某項變更除了通過個別測試之外，是否真正改善實際的產品體驗。

有一點值得注意：評估不必打磨得盡善盡美，只要足以改善你的產品就可以了。

AI 代理程式評估的常見誤解

• 評估只是單元測試。並非如此；單元測試是細小的自動化檢查，只是評估的其中一部分。評估還包括定性錯誤分析、人工判斷、生產環境監察，以及衡量應用程式質素的實驗。
• 評估平台可以為你包辦一切。現成工具可以將部分檢查自動化，但無法判斷哪些失敗模式（錯誤類型或不理想的代理程式行為）對你的產品而言真正重要。
• 你可以讓 LLM 評估一切。這是一大謬誤。由人主導的錯誤分析和評分器校準仍然不可或缺，因為 LLM 缺乏發現所有問題所需的業務背景。
• A/B 測試或單純使用代理程式就能取代評估。這並不正確。A/B 測試可以顯示哪個版本在選定指標上表現較好，但單靠它本身無法解釋背後的問題。

AI 代理程式評估常見問題

1. AI 代理程式評估與 LLM 評估有何分別？

LLM 評估衡量語言模型執行特定任務的表現，例如回答問題、總結文件或擷取資訊。AI 代理程式評估則評估一個能獨立執行多個步驟以完成任務的系統。

與一般的 LLM 評估不同，代理程式評估會同時檢視最終結果，以及為達成結果而採取的一連串行動，包括工具調用、決策，以及是否遵守預先定義的規則。

2. AI 代理程式評估的關鍵指標

AI 代理程式評估指標大致分為兩類：

• 技術效能指標：任務成功率、行動正確性、答案質素、可靠性（pass@1 和 pass@k）、延遲、token 用量，以及每項成功任務的成本。
• 業務及用戶體驗指標：客戶滿意度（CSAT）、問題解決率、升級處理率、轉換率、任務完成時間，以及其他與代理程式角色相關的成果。

例如，客戶支援代理程式可以按成功解決問題的情況和客戶滿意度來評估，而 AI 採購代理程式則可以按補貨申請的準確度、審批率和採購週期時間來衡量。

合適的指標應同時反映代理程式表現的可靠程度，以及其工作是否改善業務成果。

3. 評估 AI 代理程式的最佳工具有哪些？

常見選擇包括：

• 測試框架：Python 斷言和 pytest 適合用來執行可重複的測試案例及檢查確切條件，例如代理程式是否選用了正確的工具，或傳回了有效的零件 ID。
• AI 代理程式評估框架：DeepEval 和 Google 的 agent-eval 工具包支援更複雜的評估，包括執行追蹤記錄、以 LLM 為基礎的評分器，以及自動化回歸測試。
• 評估及可觀測性平台：LangSmith、Arize Phoenix 和 MLflow 協助團隊檢查代理程式行為、管理評估數據集、比較代理程式版本，以及監察生產環境中的表現。

4. 如何將 AI 代理程式評估自動化？

你可以透過建立可重複的測試、套用自動評分器，並將這些檢查整合到開發及生產工作流程中，將 AI 代理程式評估自動化：

1. 建立評估數據集：收集具代表性的用戶任務、預期結果、已知失敗及代理程式執行追蹤記錄，並納入邊緣案例，例如工具調用失敗、資訊缺失及未經授權的操作。
2. 自動執行測試及評分：使用 pytest 或 DeepEval 等框架執行測試案例，並套用以程式碼為基礎的檢查或 LLM 評分器。在依賴 LLM 評分器的分數之前，先對照人工判斷進行驗證。
3. 將評估整合到 CI/CD：當開發人員更新代理程式的提示、模型、工具或工作流程時，自動重新執行回歸測試。將結果與基準比較，並設定質素門檻，在關鍵檢查未通過時阻止發佈。
4. 對抽樣的生產環境追蹤記錄套用已校準的評分器，追蹤失敗率及其他效能指標，並透過人手審閱調查新的錯誤。