第 5 章 — 評估 LLM 應用
LLM Primer V: Building Real-World LLM Applications 章節走讀的第五篇。這一章承認 assertEqual 對 LLM 輸出來說已死,把測試紀律重建在錨定的 judge、RAG Triad、以及代理的軌跡測試上。
這一章為什麼存在
傳統軟體測試立基於一個假設:正確的輸出是特定的輸出 — 函式回傳 42、字串等於「Hello, world」、JSON 對到 fixture。LLM 系統會產生「意思等價、字元不同」的改寫,而過去五十年支撐著軟體測試的完全比對斷言,遇到第一次重新生成就崩了。團隊接著會伸手拿 BLEU、ROUGE、嵌入餘弦相似度,然後發現這些指標在真正重要的事情上跟人類判斷相關性很弱 — 答案對不對、有沒有根據、是不是在回答那個問題。第 5 章把測試紀律重建在真的會動的東西上:錨定的 LLM-as-a-judge 評分準則、RAG Triad、代理軌跡測試,以及那個把生產環境的 trace 餵回下一輪發布 gate 的評估集的持續迴圈。
5.1 評估落差與 LLM-as-a-judge
評估落差是「傳統測試能量到的」跟「LLM 輸出實際需要被量的」之間的距離。在改寫密集的任務上,完全比對跟參考字串指標抓不到任何有趣的失敗。LLM-as-a-judge 是把落差補起來的主力,而讓它跟派對把戲區分開的是兩項紀律。第一,judge 的評分準則是錨定的:每一個分數值都有寫下來的定義,理想上還帶一個範例,好讓 judge 不是在自由聯想一個數字。第二,judge 先寫推理、再寫分數,因為「必須把推理寫出來」的 judge 打起分來會更一致。程式化檢查跟 judge 互補,補上能確定性檢驗的部分 — JSON 能不能 parse、必要欄位在不在、有沒有禁用字串、回應長度在不在界內。Judge 不是萬用的;它蓋的是確定性檢查蓋不到的那塊地。
5.2 RAG Triad — context、groundedness、answer relevance
對檢索系統來說,已經結晶下來的樣板是把三個頂點各自獨立評分。Context relevance 問「被檢索到的 chunk 到底跟查詢有沒有相關」,把檢索失敗跟生成失敗隔離開。Groundedness 問「生成的答案有沒有從被檢索的 context 推出來」,抓那些通過形狀驗證但幻覺的答案。Answer relevance 問「答案有沒有在回答使用者實際問的那個問題」。三個頂點分開評,失敗會被定位:低 context-relevance 指向檢索、低 groundedness 指向 generator、低 answer-relevance 指向 router 或系統在回答一個鄰近的問題。RAGAS 把 triad 做成一條批次管線;judge 模型的品質壓過分數的品質,所以 judge 自己就是一個團隊要評估的元件。
5.3 框架各自的位置與代理回歸
三個框架各占不同位置。RAGAS 對一組問答資料集在批次上跑 RAG Triad,是週期性資料集評估的對的工具。TruLens 把回饋函式掛在正在跑的生產流量上、直接在 trace 上算 triad,把「生產跟評估」之間的迴圈收起來。DeepEval 像 pytest 跑單元測試那樣把 LLM 測試當 CI gate 跑,可以設每指標的門檻。代理把上述通通往三個方向延伸:軌跡快照測試對一個固定輸入斷言工具呼叫序列的形狀,抓結構漂移;不變式斷言確認代理沒呼叫禁用工具、沒跳過必要的核准;準則測試對軌跡本身評分「路徑合不合理」。一個用錯路呼叫工具卻給對答案的代理,距離下一次 prompt 微調就會用同一條錯路給錯答案只有一步之遙,而軌跡測試就是抓那個的紀律。
第 5 章接下來會怎麼走
評估需要生產 trace 來取樣。CI gate 需要真實回歸來擋。持續改進迴圈只在「每一次呼叫的每一步都有一層可觀測性抓下來」的情況下才會動 — 模型呼叫、工具呼叫、檢索結果、子代理跳轉、成本、延遲、使用者回饋。第 6 章就是那一層。它走過 OpenTelemetry 的 GenAI 語意慣例、對 LLM 系統真的重要的那幾個指標、平台選擇,以及 — 最重要的 — 那條把低分 trace 路由回下一輪發布 gate 的評估集的匯出管線。
下一篇 — 第 6 章:AI 可觀測性與追蹤。讓評估跟除錯都變得可能的那個底層 — 每次呼叫一棵嵌套 trace,把成本跟品質當一級屬性掛上去。
