北京
周三下午三點，一個前端團隊的產品經理盯著看板發愁。他們的智能客服已經上線三個月，但用戶滿意度卡在72%死活上不去。技術負責人調出最近的查詢日志，發現一個尷尬的事實：檢索系統找回來的文檔基本都對，但大模型給出的答案卻經常驢唇不對馬嘴。
這不是個例。2026年，越來越多前端團隊發現，把檢索增強生成（RAG）產品真正推上生產環境之后，評判系統好不好的標準完全變了。過去大家習慣把檢索質量、答案準確性和用戶體驗拆成三件事，找不同的團隊分頭優化。但實際跑下來，這三層是長在一起的——檢索得當成搜索質量來調，生成得當成有據可查的寫作來評，而UI層面要么把問題暴露出來，要么替系統藏著掖著。
目前主流的做法是混合檢索。稠密嵌入搜索搭配稀疏檢索或關鍵詞搜索，比單純依賴向量相似度要穩健得多。第一輪檢索跑完之后再加一層重排序器，讓大模型看到的文本塊更少但更精準，這一手對答案質量和響應延遲都有幫助。而那些前端交互比較重的產品，團隊調檢索鏈路的時候，眼睛盯著的往往是頁面上可見的行為——信息來源標簽是否準確、引用是否到位、回答帶不帶可信度標識、碰到答不上來的問題時有沒有兜底話術——而不是只看模型打分。
真正能用的評估體系至少得搭三層。第一層測檢索，看召回率、平均倒數排名（MRR）和平均精度均值（MAP），因為正確答案根本沒出現在上下文里，模型再怎么發揮也白搭。第二層測生成，看忠實度、正確性和相關性，因為一段流暢的回復可能完全是瞎編的或者找不到出處。第三層測產品行為，看延遲、追問率、答案采納率和來源點擊率，這才是前端團隊真正關心的——用戶到底信不信這個功能，用不用它。
落地實踐中有一個很實用的套路：先攢一批“金標準”測試集，100到500條有代表性的查詢，覆蓋正常場景、邊緣場景和刁難的對抗性場景。每條查詢都標注好預期答案、預期來源文檔，再加一個簡單的評分指南，說清楚什么樣的回復算合格。之后只要動了切片策略、嵌入模型、過濾規則、重排序、提示詞或者UI交互流，就把這套測試集自動跑一遍。很多檢索效果的退化，恰恰來自那些看起來人畜無害的鏈路調整。
判斷檢索質量的思路也得換一下。最有價值的問題不是“向量相似度高不高”，而是“該出現的內容有沒有擠進前幾名的結果里”。實用的檢查項包括：正確答案有沒有出現在前5或前10個結果中；排名靠前的文檔類型是否足夠多樣，能支撐需要跨文檔推理的多跳式回答。尤其當業務領域涉及技術文檔、法律條文、醫學資料、密集代碼或多語種場景時，團隊會在同一批標注數據集上先對比候選嵌入模型的效果，再確定用哪個。
答案評判通常走“大模型當裁判加人工抽查”的路線。裁判模型要評的維度包括：答案是否在檢索到的上下文中有據可查、信息是否完整、有沒有夸大檢索結果實際支撐的結論。這個環節特別關鍵，因為RAG系統翻車的方式很微妙——有時候它確實找對了相關段落，但綜合出來的結論卻超出了原文能證明的范圍；有時候答案本身是對的，引用的卻是一堆不太靠譜的證據。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
