RAG 上線後怎麼維運?品質監控、回歸測試與答案退化的預警機制

上線那天,那套 RAG 內部知識助手答得漂亮。法遵團隊問「這筆跨境匯款要不要申報」,它引對了條文、標了出處,主管當場拍板全公司開通。三個月後我們回訪,同一個問題,它開始漏掉一條去年底新增的函釋。沒人發現。不是模型變笨,是知識庫悄悄變了,而沒有任何東西在盯著這件事。

這就是 demo 之後最被忽略的一段:維運。**RAG 上線維運監控,指的是在系統上線後,持續量測檢索品質、答案正確性與使用行為,並在品質退化到影響使用者之前主動預警的一整套機制。**它不是「出事再查 log」,而是把「上線且有人在用」變成一個可以每天讀數字的狀態。Demo 證明系統「能對」,維運才證明它「一直對」。

答案為什麼會退化:三個你看不見的來源

RAG 退化很少是一夜崩壞,通常是溫水煮青蛙。

第一個是資料漂移。你的知識庫是活的:PM 每週上傳新文件、法務改版舊條款、有人把一份 PDF 換成掃描檔導致解析失敗。檢索的召回率就這樣一點一點掉,而生成端仍然一本正經地回答。第二個是查詢漂移。使用者用起來之後,問法會偏離你當初測試的那批題目——他們開始問更長、更刁鑽、跨部門的問題,而你的 chunk 切法與 embedding 根本沒為這些問題調過。第三個最隱蔽:沉默的錯誤。使用者被錯誤答案誤導,但他不會來跟你抱怨,他只是默默不再用。使用率從 40% 掉到 8%,你的 dashboard 上卻一片綠燈,因為你只監控了系統有沒有回應,沒監控回應對不對。

一塊該天天看的品質監控儀表板

我們幫客戶上線 RAG,交付的不只是系統,還有這塊儀表板。它把抽象的「品質」拆成四層可量測的指標,每一層都對應一種退化來源。

關鍵在「忠實度」這一欄。我們用一個 LLM-as-judge 的評分器,對每天抽樣的實際問答,自動判斷答案的每一句話是否都能在檢索到的文件裡找到依據。沒依據的,就是幻覺。這個分數比使用者滿意度更早示警——通常忠實度先掉,兩三週後倒讚才跟上。

黃金題庫與回歸測試:別讓修 A 弄壞 B

RAG 系統每一次改動都有副作用。換 embedding 模型、調整 chunk 大小、改寫 system prompt、甚至只是重新索引一批文件,都可能讓原本答對的題目突然答錯。工程師直覺去修客訴的那三題,結果悄悄弄壞了另外二十題。

解法是回歸測試,而它的核心是一份「黃金題庫」:五十到兩百題有標準答案、涵蓋各業務線與已知痛點的問答。每次上線變更前,自動跑一遍全題庫,逐題比對檢索命中與答案忠實度,產出一份 before/after 差異報告。分數掉了就擋下這次發布。這份題庫要持續長大——每接到一個真實客訴、每發現一個新的漂移主題,就固化成一題,讓同樣的錯不會犯第二次。這是 RAG 版本的單元測試,沒有它,你等於每次上線都在賭。

預警要主動,不要等人來報

好的預警機制有兩條線。一條是趨勢線:任何核心指標連續兩個觀測週期下滑,就自動開一張工單,附上退化的主題與樣本問答,讓人直接去看。另一條是資料源線:知識庫每次更新,自動觸發一次針對受影響文件的小型回歸,確認新文件沒有污染既有答案。兩條線都要接到人會看的地方——Slack 或工單系統,而不是一個沒人開的 dashboard。

我們的經驗是,RAG 專案的成敗有一半發生在上線之後,而這一半幾乎沒人在交付時談。所以我們把工程師留在客戶現場,不只是把系統推上生產線,而是陪著把這套監控、回歸與預警的迴路跑順,直到團隊自己讀得懂數字、扛得起維運為止。Demo 很美不算數,三個月後它還在對、還有人在用,才算數。