AI Agent 成功率很高，為什麼還是不能放心上線？

我們常用整體準確率或任務成功率，判斷 AI Agent 的表現。但一個漂亮的總分，未必能回答最重要的問題：它在哪些情境容易出錯？這些錯誤，又會造成多大的影響？

2023 年 10 月，紐約市推出 MyCity 聊天機器人，協助企業主查詢開業與營運資訊。然而，2024 年 3 月，The Markup 的測試發現，它會提供錯誤的法規建議，包括聲稱雇主可以抽取員工小費，以及員工排班變更沒有通知規範。〔1〕

這個案例提醒我們：回答看起來專業，不代表內容可靠；即使系統在多數問題上表現良好，也不能因此忽略少數高風險情境。

要讓 Agent 穩定運作，除了看總分，更需要把問題類型與執行步驟拆開評估。

核心問題

當 Agent 給出錯誤答案，你知道應該修哪裡嗎？

是選錯工具、填錯參數、沒找到關鍵資料，還是拿到了正確資訊，卻沒有依據資料回答？也可能答案忠於文件，但文件本身已經過時，或不適用於當前情境。

只看整體分數，容易留下兩種盲點：

1. 看不見高風險情境。 大量簡單問題的正確答案，可能掩蓋法律、付款或權限等重要場景的錯誤。
2. 看不見出錯的步驟。 同樣是任務失敗，原因可能出在不同組件，不能每次都靠調整 Prompt 解決。

於是，團隊雖然知道結果不好，卻仍得在資料、工具、模型與流程之間反覆排查。

真正需要改善的，不只是分數，而是讓分數能幫助我們判斷：哪裡出問題，以及下一步該檢查什麼。

關鍵洞察

評估 Agent，需要同時看兩個方向：按情境細分風險，按步驟定位問題。

例如，在客服系統中，可以把一般商品諮詢、退款與個人資料存取分開評估；再針對每類任務，檢查工具使用、資料檢索與回答是否符合規範。

這就是本文所說的「分層解耦評估」：保留端到端的任務成功率，同時拆開檢查各環節，而不是用組件分數取代最終成果。

導入追蹤工具，也不代表已完成評估。執行紀錄可以告訴我們 Agent 呼叫了什麼工具、取得哪些資料；但工具是否選對、資料是否足夠、回答是否違反規範，仍需要明確的判斷標準。微軟的 Agent 可觀測性指南，也將追蹤、評估與治理視為不同但互補的工作。〔2〕

行動方案

可以先從以下三個層級建立評估。這是一套實務上的檢查方式，應依系統功能調整；沒有使用檢索或外部工具的 Agent，不必硬套所有指標。

一、工具調用層：選對工具，也要確認參數與執行結果

這一層要分開回答三個問題：Agent 有沒有選對工具？輸入是否正確？工具是否成功執行？

可以追蹤的指標包括：

• 工具選擇準確率： 是否選擇了完成任務所需的工具。
• 參數解析或驗證錯誤率： 輸入是否符合必要欄位、型別與格式規則。
• 工具執行成功率： 呼叫是否因逾時、權限不足或服務錯誤而失敗。

例如，使用者要求查詢退款進度，Agent 卻呼叫一般商品搜尋工具，就應先檢查工具描述與選擇規則。如果工具選對，卻漏填訂單編號，可以檢查欄位定義、輸入驗證與缺少資訊時的追問流程。

但格式正確，也不代表內容正確：訂單編號符合格式，仍可能屬於另一位使用者。因此，還需要檢查參數值與存取權限，而不是只確認程式能執行。微軟的 Agent 評估文件，也將工具選擇、輸入正確性與呼叫成功分開衡量。〔3〕

二、檢索生成層：資料有沒有找齊，回答有沒有依據？

使用 RAG 的系統，需要分清楚「沒找到資料」與「找到資料卻沒有正確使用」。

兩個值得觀察的指標是：

• 上下文召回率（Context Recall）： 回答所需的關鍵資訊，有多少被檢索出來。計算時需要參考答案或標註資料，作為比較依據。
• 忠實度（Faithfulness）： 回答中的陳述，有多少能被提供給模型的資料支持。〔4〕 〔5〕

例如，使用者詢問退貨期限，但檢索結果漏掉現行政策，就應檢查資料是否收錄完整，以及切分、搜尋、過濾與排序方式。

如果正確政策已經交給模型，回答卻自行增加不存在的例外，就需要檢查回答指令、上下文組合方式，以及缺乏依據時的處理規則。

忠實度高，仍不代表答案一定正確或合規。 如果引用的是過時文件，模型即使完全照著回答，也可能給出不適用的建議。因此，資料的版本、來源與適用條件，同樣需要驗證。

三、語義合規層：答案有依據，也要符合使用情境

有些問題，不是檢查關鍵字或格式就能發現。

例如，Agent 引用了真實的內部流程，卻把只適用於特定客戶的規則套用到所有人；或在回答個人資料問題時，透露了使用者無權取得的資訊。

這一層可以運用 LLM-as-a-Judge：讓另一個模型依照明確的業務準則，協助檢查回答是否符合政策、權限與適用條件。

評審標準需要寫清楚，包括哪些內容不得揭露、何時應拒答或轉交人工，以及什麼情況算通過。除了整體評分，也可以分別追蹤各類規範的通過率與嚴重違規案例。

但模型評審不是安全保證。團隊仍需用人工標註案例檢查它是否會誤判；涉及法律、金流或個人資料等高風險情境時，更需要適當的專業覆核與人工處理機制。

別只問分數提高了多少，也要問風險降低了多少

分層評估的目的，不是建立更多儀表板，而是讓團隊能根據證據採取行動。

可以先整理一組真實任務，標註預期工具、必要資料與驗收條件，再依問題類型和風險程度分組。每次調整系統後，都使用同一組案例比較，確認原本的錯誤是否改善，也檢查其他情境有沒有退步。

對高風險任務，還應設定獨立的驗收門檻，不能因為整體平均表現良好，就讓嚴重錯誤被抵銷。

可靠的 Agent，不只是多數時候答得對，而是團隊知道它在哪裡可能出錯，並有能力及早發現與處理。

金句啟發

「總分告訴你表現如何；分層評估，才幫你看見風險藏在哪裡。」

延伸閱讀

[1] 紐約市聊天機器人提供錯誤法規建議｜NYC’s AI Chatbot Tells Businesses to Break the Law
The Markup，2024。

[2] Agent 可觀測性的五項實務建議｜Agent Factory: Top 5 Agent Observability Best Practices for Reliable AI
Microsoft Azure，2025。

[3] Agent 工具使用與任務評估指標｜Agent Evaluators for Generative AI
Microsoft Learn。

[4] 上下文召回率｜Context Recall；忠實度｜Faithfulness
Ragas 官方文件。

[5] 檢索與生成組件的評估方法｜Evaluation of Retrieval-Augmented Generation: A Survey
Hao Yu 等，2024。

以上文章整理自【數創電子報 Vol.18】高成功率未必代表安全，真正的風險往往藏在平均值之下。

想收到更多 AI 相關學習與趨勢文章嗎？訂閱數創電子報

重點整理

為什麼 AI Agent 評估不能只看整體成功率？

因為大量低風險任務的成功，可能掩蓋少數高風險情境的錯誤。除了總分，也需要按問題類型與風險程度分開檢查，並為重要場景設定獨立的驗收門檻。

分層評估與執行追蹤有什麼不同？

追蹤記錄 Agent 做了什麼；評估判斷它做得對不對。把工具選擇、輸入參數、資料檢索與回答品質分開衡量，才能縮小排查範圍，避免每次出錯都盲目調整 Prompt。

回答忠於文件，再加上模型評審，就能保證安全嗎？

不能。文件可能過時或不適用，模型評審也可能誤判。團隊仍需檢查資料來源、政策與權限，並透過人工標註校準評審；高風險情境則應搭配專業覆核與人工處理機制。