87%的RAG系統(tǒng)在生產(chǎn)環(huán)境"帶病運行"，而監(jiān)控面板全綠。這是硅谷某AI基礎設施團隊去年Q3的真實數(shù)據(jù)——他們花了11周才發(fā)現(xiàn)，自家客服機器人把退貨政策解釋錯了整整一個版本。

Silent RAG failure（靜默檢索失?。┎皇窍到y(tǒng)崩潰，是系統(tǒng)"成功"地給出了錯誤答案。檢索模塊跑通了，大語言模型（LLM，Large Language Model）生成流暢，用戶甚至點了"有幫助"。但答案本身可能是幻覺、過時信息，或者從錯誤文檔里撈出來的"相關但無關"內容。

為什么傳統(tǒng)監(jiān)控抓不住它

大多數(shù)團隊的檢測手段停留在"系統(tǒng)健康"層面：API響應時間、token消耗量、余弦相似度分數(shù)。這些指標回答的是"流程走完了嗎"，而非"答案對嗎"。

余弦相似度尤其具有欺騙性。它能告訴你檢索到的文檔塊和用戶問題在向量空間里靠得多近，但完全不管文檔內容是否準確、是否過時、是否來自被廢棄的內部Wiki頁面。一個2022年的報銷政策文檔，和2024年的問題在向量空間里可以"相似度0.91"，但答案就是錯的。

更隱蔽的是用戶行為信號。用戶看到錯誤答案后的反應往往不是投訴——是沉默離開。某金融科技公司的數(shù)據(jù)顯示，RAG客服給出錯誤理財建議后，用戶平均停留時長下降34%，但差評率僅上升2%。錯誤被消化在"用戶體驗一般"的黑箱里，從未觸發(fā)任何告警。

生產(chǎn)環(huán)境的三種典型死法

第一種是"文檔腐爛"。知識庫更新后，舊版本文檔未被清理，檢索系統(tǒng)同時召回新舊兩版，LLM隨機拼接。某電商平臺的促銷規(guī)則RAG曾同時引用"滿199減20"和"滿299減50"兩個版本，生成的答案讓用戶直接放棄下單。

第二種是"邊界幻覺"。用戶問"你們支持哪些國家"，系統(tǒng)檢索到一篇講"歐洲市場戰(zhàn)略"的內部PPT，答案變成"我們重點布局英法德"——實際支持列表是另外一份表格。向量相似度高達0.94，但答案殘缺且誤導。

第三種最致命：答案正確，但來源錯誤。某醫(yī)療AI的RAG系統(tǒng)回答用藥劑量時，引用了正確的數(shù)字，卻標注了錯誤的臨床指南版本號。醫(yī)生按版本號核查時發(fā)現(xiàn)對不上，整個系統(tǒng)信任崩塌。

一些團隊在嘗試的笨辦法

Anthropic的工程師在公開分享中提到，他們在Claude的RAG管線里加了"答案-文檔交叉驗證層"：讓另一個模型獨立判斷，生成的答案是否真的能被檢索到的文檔支撐。代價是延遲增加40%，但幻覺率下降了一個數(shù)量級。

更輕量的方案是"結構化溯源"——強制要求答案中的每個事實句都標注來源文檔的精確位置（段落ID+行號），而非模糊的"參考了某文檔"。這讓人工抽檢成為可能，雖然無法全自動，但能把發(fā)現(xiàn)周期從"數(shù)月"壓縮到"數(shù)天"。

LangChain團隊去年開源的Ragas框架，嘗試用合成數(shù)據(jù)自動生成"問題-答案-文檔"三元組，再訓練一個評估模型打分。實際落地中，評分和人工判斷的一致性約在72%-81%之間——不夠完美，但比純靠余弦相似度靠譜。

「我們現(xiàn)在的做法是讓產(chǎn)品經(jīng)理每周隨機抽50條對話，人工過一遍?！挂晃蛔銎髽I(yè)知識庫RAG的PM告訴我，「聽起來很土，但這是唯一能讓我們睡著的辦法?！?/p>

你的RAG系統(tǒng)上一次"答案正確性"審計是什么時候做的？如果答案是"上線前測過"，那它現(xiàn)在可能正在安靜地給出錯誤答案——而你的儀表盤，一片翠綠。