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

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

建立這套流程需要一些技術知識與資料分析技能，但它遠不如聽起來那麼可怕或難以入手。為了幫助你踏出第一步，我們整理了評估 AI 代理程式的六個實用步驟，以及會讓流程失靈的常見迷思。

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

評估 AI 代理程式，是指衡量它能否正確完成任務，以及它的決策是否符合組織的要求。實務上，AI 代理程式評估（簡稱 evals）是一系列特定指標，可協助組織判斷代理程式是否足夠可靠，能勝任其預定角色。

想像一下，某座製造工廠有一個 AI 採購代理程式，負責檢查備品庫存並準備補貨申請。如果某個核准零件缺貨，或供應商資訊已經過時，這個代理程式會標記問題，還是會推薦未經核准的替代品？

而如果你為了修正這個問題而修改它的系統提示詞，又要如何確定自己沒有引入另一個問題？

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

話雖如此，代理程式評估可以檢視一次執行的多個面向：

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

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

評估可針對質性與量化資料進行。質性評估可協助你了解發生了什麼事以及背後的原因，包括人工審查代理程式的決策。量化評估則將這些觀察轉化為可衡量的訊號，例如計算特定失敗模式出現的頻率，或計算任務成功率。

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

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

依據你要衡量的項目，評估可以檢視代理程式的端對端效能、執行軌跡，或是工具呼叫與檢索步驟等個別元件。

步驟 1：定義成功的代理程式執行應有的樣貌

首先，明確描述代理程式應該完成的事情，也就是產品需求。聽起來理所當然，實際上卻可能出乎意料地困難。這種現象甚至有個專有名稱：規格落差。

根據我們的資深資料科學家 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-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. 將經過校準的評分器套用到抽樣的正式環境追蹤記錄上，追蹤失敗率與其他效能指標，並透過人工檢閱調查新的錯誤。