RAG 的驗收不能只看回答像不像

RAG 把企業文件帶進語言模型的回答流程，但它同時增加了多個可能出錯的環節。只請幾位同事試問、覺得回答不錯，往往會漏掉沒有被找到的資料、引用錯置與應該拒答的問題。

先把「回答錯」拆成四個問題

文件是否正確進入知識庫？相關片段是否被檢索到？模型是否忠於片段回答？來源標示是否真的支持結論？只有分層檢查，改善時才知道要調整文件、切分、搜尋、重新排序或提示。

資料層版本、缺漏、解析與權限

檢索層相關片段是否出現在候選結果

生成層回答是否只使用可支持內容

呈現層引用、拒答與風險提示是否清楚

問題集不能只收錄容易查到的標準問法。應包含同義表達、跨文件問題、過期內容、缺少前提、權限外資料，以及知識庫中根本沒有答案的問題。

一組有用的測試問題，至少要標記

如果正確片段沒有出現在檢索結果，後面的模型很難補救。檢索測試可以觀察正確來源是否進入前幾名、是否被無關片段擠掉，以及文件切分是否破壞了必要上下文。

評估時也要保留實際權限過濾；如果測試環境讓所有人看到全部文件，得到的分數無法代表正式系統。

回答評估重點不是文字是否自然，而是主張能否被來源支持、有沒有混入模型自行補充的內容，以及引用是否精確。對高風險題目，正確拒答通常比看似完整的猜測更有價值。

知識庫、模型、提示與檢索設定都會更新。每次變更後重新跑固定測試集，才能知道改善某類問題時是否傷害了另一類。正式環境則持續蒐集低信心、拒答、使用者修正與高風險查詢，轉成下一輪測試案例。

如此一來，RAG 評估就不再是上線前的一次性活動，而是系統維運的一部分。