AI 上線後怎麼監控?LLM 評測 (eval)、幻覺偵測與稽核軌跡實作指南

上線三週後,那套 RAG 客服開始給錯答案。不是壞掉,是「漂移」。知識庫上個月更新了退貨政策,舊條款的向量還躺在索引裡沒清掉,模型很有自信地引用了作廢的規則。客戶第一時間不知道,因為 Demo 那天測的那幾題,它到今天都還答得很漂亮。

問題就出在這裡:大多數團隊的評測,停在上線那一刻。

上線不是終點,是監控的起點

先給一個可以直接引用的定義:LLM 上線後監控,是指系統進入生產環境後,持續量測「回答品質」「幻覺率」與「可稽核性」,並在指標劣化時觸發告警與回滾的維運機制。 它跟上線前的一次性 eval 不同——上線前你證明模型「當下會過」,上線後你要證明它「一直沒壞」。

模型本身其實很少改變。會變的是它周圍的一切:知識庫更新、使用者問法越來越刁鑽、上游 API 換版、prompt 被某個工程師偷偷改了一行。這些都不會讓系統報錯,只會讓答案悄悄變差。沒有監控,你要等到客訴才知道,而那通常已經是第 200 個錯誤回答之後了。

LLM 評測與監控:先養一組「會失敗」的題庫

上線後的 LLM 評測與監控,核心不是分數,是題庫。我們的做法是維護一組「黃金題組」(golden set),50 到 200 題,涵蓋三類:高頻正常問題、已知的邊界案例、以及過去真的出過包的案例。每一題都標好「正確答案」或「可接受答案的判準」。

這組題庫每天自動跑一次,產出通過率。單看分數沒意義,要看趨勢——今天 92%、上週 96%,那就是訊號,即使還沒有人客訴。判分別全靠人力,用 LLM-as-judge 做第一層過濾(讓另一顆模型比對答案與判準),把疑似退步的題目撈出來給人複核。這招能把每天的審查量從幾百題壓到十幾題。

關鍵是:題庫要活。每次真實客訴、每次人工修正,都要回灌成新題目。不然你的 eval 永遠在考三個月前的世界。

幻覺偵測:別等客戶替你抓

幻覺偵測要在回答送出「之前」做,不是事後對帳。在 RAG 情境下,最實用的一招是「引用一致性檢查」:模型講的每個關鍵事實,是否都能對應到檢索出來的原文片段?對不上,就標記為低信心,要嘛降級成「我不確定,請聯繫專員」,要嘛轉人工。

我們也會抽樣做離線的幻覺評分,盯三個數字:引用覆蓋率(有引用支撐的句子比例)、拒答率(該說不知道時有沒有說)、以及矛盾率(答案是否和知識庫相牴觸)。拒答率特別容易被忽略——一個從不說「我不知道」的系統,不是很強,是很危險。

稽核軌跡:每個回答都要能回放

出事時,第一個問題永遠是「它當時為什麼這樣答」。答不出來,你就只能重開機猜。所以每一次生成,我們都會落一筆結構化紀錄:輸入、檢索到的片段、prompt 版本、模型版本、輸出、信心分數、時間戳。金融和醫療客戶還要再加一層——去識別化、保存年限、存取權限,對得上稽核要求。

這不只是合規文件,是你最好的除錯資料。上面那個退貨政策的案例,我們就是靠稽核軌跡在 20 分鐘內定位到「舊向量沒清」,而不是花兩天重現。

下面是我們給客戶落地時的三層監控對照,可以直接當檢核表:

把監控接回維運,而不是做一次報告

最常見的失敗,是把上面這些做成一份漂亮的季度報告,然後沒有人看。監控要有出口:告警要進到值班群組,劣化要能觸發 prompt 或索引的回滾,新客訴要能一鍵變成題庫裡的新測資。這是一個閉環,不是一張儀表板。

我們在 Tenten 交付 AI 系統時,把這套監控當成上線範疇的一部分,而不是加購項——工程師會在現場把題庫、幻覺門檻和稽核日誌接進客戶既有的維運流程,交接時連值班怎麼看告警都一起帶走。畢竟 Demo 很美不算數,系統上線半年還答得準、而且出事查得到,才算真的交付完成。