生產級 LLM 可觀測性與評估：沒有 eval 的 agent，等於沒有測試的軟體

從 PoC 到 Production：企業 AI Agent 系統工程第 9 / 12 篇

本篇是「從 PoC 到 Production：企業 AI Agent 系統工程」系列的第 9 / 12 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

這是「從 PoC 到 Production：企業 AI Agent 系統工程」系列第 9 篇（共 12 篇）。上一篇：多代理協作。

這一篇是整個系列裡，我覺得最能分辨「玩過 agent」和「把 agent 當系統做過」的人的一篇。因為它要講的兩件事——eval 和 observability——在 demo 階段完全不存在，但它們正是讓系統可以被信任、被維運的東西。

先把最重的一句話放這：

一個沒有 eval 的 agent 專案，本質上就是一套沒有測試的軟體。只是因為它是 AI，大家就默許了這件事。

為什麼 agent 的「測試」這麼難，但更不能省

傳統軟體：輸入固定 → 輸出固定 → assert 相等 → 綠燈。

Agent：輸入「請幫我總結這份報告」→ 輸出每次用字都不一樣，但可能都對；也可能字面很像、實際上錯了。你沒辦法用 assertEqual 測它。

正因為輸出不確定，很多人就放棄測試，改用「我自己試幾題覺得還行」。但這正是災難的開始，因為：

你換個模型版本（連 vendor 都可能 silent update），行為就漂移。
你改一句 prompt 修好 A 問題，常常默默弄壞 B 問題。
你調個檢索參數（第 3、4 篇），不知道整體變好還變壞。

越是不確定的系統，越需要有系統的方法去量它，而不是越不確定就越靠感覺。

Eval Harness：給 agent 蓋一套測試

1. 黃金題庫（golden set）

準備一組「問題 + 期望答案 / 期望性質」的題目，涵蓋常見情境、邊界情境、和已知會出包的情境。每次你改任何東西（prompt、模型、檢索），自動把整組題庫跑一遍，看通過率。

這就是 agent 版的回歸測試。它不需要很大才有用——30 題涵蓋你最在乎的場景，就遠勝於零。重點是它存在、而且每次改動都跑。出包過的 case 一定要補進題庫，確保同樣的錯不會再犯第二次。

2. 怎麼判斷「答對」：三種尺

輸出不固定，怎麼自動判分？由寬到嚴：

規則 / 字串：答案裡有沒有包含某關鍵事實、有沒有附來源、格式對不對。便宜、確定，但只能驗「硬性質」。
語意比對：用 embedding 比對答案和標準答案的語意相近度。能容忍用字不同。
LLM-as-judge：用另一個（通常更強的）模型，照你給的標準（正確性、完整性、有沒有幻覺）來評分。最有彈性，但「要小心偏誤」不是句口號——judge 有三個有名字、可被緩解的已知偏誤要主動防：position bias（偏好排前面的答案，緩解法是交換順序評兩次取一致）、verbosity bias（偏好較長的答案，即使長度沒帶來品質）、self-preference bias（偏袒自己或同家族模型的輸出——所以別拿同一個模型既當 judge 又當被評對象）。把這三個釘死，「要小心」才從感覺變成可勾的檢查清單，也才需要搭配規則與語意比對交叉驗證。

實務上常常三種混用：硬性質用規則、整體品質用 LLM-as-judge。

3. 別只測最終答案，要測中間步驟

對會做事的 agent，光看最終輸出不夠。一個答案剛好對，不代表過程沒問題（可能檢索撈錯，但模型瞎猜對了）。所以 eval 也要看：它檢索到的東西對不對、它選的工具對不對。這需要下面的 tracing 撐著。

這幾件事在業界都有正式名字，方便你搜：整條決策路徑對不對叫 trajectory evaluation（軌跡 / step-level evaluation）；檢索層有現成指標——context precision / recall（該撈的有沒有撈到、撈到的對不對）和 faithfulness（答案有沒有忠於檢索內容，也就是抓幻覺），RAGAS、Arize Phoenix 都內建；工具選對沒對則看 tool-selection accuracy。白話講對是第一步，知道學名你才搜得到工具去自動量它。

Tracing：把 agent 的黑盒打開

第 1 篇的鴻溝三講過：agent 答錯，你常常什麼線索都沒有。Tracing 就是要把那條從問題到答案的完整路徑，變成一條可以攤開來看的紀錄。

對 agent，一條 trace 應該記錄這些 span：

一條 agent trace：把一個請求拆成檢索、工具呼叫、模型推理、生成等可量測的 span，每一步的耗時、token、花費都看得到

把一個 agent 請求拆成檢索、工具、模型、生成幾個可量測的 span——打開黑盒，每一步的耗時與花費都看得見。

有了這個，你 debug 的方式就從「再問一次看看」變成「攤開 trace，看是哪一個 span 出錯」。是檢索撈錯？工具回傳怪資料？還是模型拿到對的東西卻推理歪了？根因一眼可見。

這套東西，做後端的人應該很熟——它就是 distributed tracing 套到 agent 上。我寫過用 tracing 去抓 PHP-FPM 記憶體洩漏、談過 fire-and-forget 服務的可觀測性陷阱，那套「每一步都要留下可追的足跡」的肌肉記憶，搬到 agent 上完全適用。差別只在 span 的內容從「DB query、HTTP call」變成「retrieval、tool call、model call」。這正是後端工程師做 AI agent 的優勢：可觀測性對你不是新觀念，只是新對象。

而且這件事在 2024 後已經不只是「概念上像」了——它有了正式的開放標準。OpenTelemetry 的 GenAI SIG 從 2024 年起在制定 GenAI Semantic Conventions（CNCF 旗下），直接把「LLM / agent 的 span 該長什麼樣」標準化：模型呼叫叫 chat / inference、工具呼叫叫 execute_tool、agent 層級叫 invoke_agent，屬性有 gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.tool.name 這些。意思是上面那張 trace 圖不是各家自己亂畫的，而是一套有共識的 schema。一個誠實的提醒：截至 2026 它仍是 experimental 狀態，屬性名還可能變，採用時要留意版本相容。

成本與 Token 監控：因為它會悄悄燒錢

LLM 系統有個傳統服務沒有的特性：每一次呼叫的成本是浮動的，取決於 token 量。一個沒人注意的功能，可能因為 context 越塞越大、或一個 multi-agent 迴圈（第 8 篇）失控，悄悄把帳單翻倍。

所以要把「成本」當成一級 metric 來監控：

每個功能 / endpoint 平均花多少 token、多少錢？
每個使用者 / 租戶燒多少？（抓異常、做計費）
有沒有哪個 trace 異常昂貴（爆 token）？要能告警。

這直接餵給第 10 篇的成本權衡——你不先把成本看見，就無從優化。

上線後：偵測「品質漂移」

最後一層，是上線後的持續監控。你的黃金題庫是固定的，但真實世界的問題會變、資料會變、模型會被 vendor 偷偷更新。所以要盯著線上的健康訊號：

代理指標：使用者重問率、轉人工率、負評率、「這個答案沒幫助」的比例——這些不需要標準答案，就能反映品質掉了。
定期回歸：固定排程重跑黃金題庫，模型供應商一更新就可能漂移，你要第一個知道，而不是等客訴。
抽樣人工複查：定期抽真實對話人工看，補進黃金題庫。

工具地景（會變，但方向很清楚）

你可能會問：實際上用什麼做？我刻意不把這篇綁死在某個工具上（它們明天就可能改名），但給你一個 2026 的版圖方便開始搜：開源自架有 Langfuse、Arize Phoenix、Opik；商業 SaaS 有 LangSmith、Braintrust；既有 APM 則有 Datadog、New Relic 的 LLM Observability。但比「選哪個」更重要的是一個正在發生的收斂——這些工具都在往 OpenTelemetry GenAI conventions 靠。所以選型第一個該問的不是「dashboard 漂不漂亮」，而是「它能不能吐標準的 OTel span」——能，你換工具時 trace 還搬得走，不會被單一廠商鎖死。