從信心分數到可觀測性：RAG 品質治理的最後一哩路
許多 RAG 系統仍過度依賴信心分數來評估品質，卻往往忽略了更為關鍵的「可追溯性」。當使用者回報答案有誤時，若無法精準追溯到具體的知識庫來源，品質改善便無從下手。本文將深入探討如何建立一個串連使用者回饋、檢索來源與知識庫內容的完整閉環，將 RAG 的品質管理從模糊的猜測轉化為一套可驗證、可迭代的工程實踐。
RAG 的品質不能只靠信心分數判斷；無法追溯回答來源，就無法有效修正錯誤。把使用者回饋、檢索來源、知識庫版本與答案結果串成閉環，才能把知識庫維運轉化為可驗證、可迭代的治理流程。
「高分答案」背後的治理盲區是什麼？
許多團隊在導入 RAG 系統時，會將重心放在優化檢索演算法與提升回答的「信心分數」（confidence score）或「相關性分數」（relevance score）。這些分數固然重要，但它們本身就像一個黑盒子，無法完整呈現答案的生成脈絡。我最近看到一篇日本開發者社群的實踐分享，他們在維運一個基於 Vertex AI RAG Engine 的聊天機器人時，很快就遇到了一個棘手的問題：當使用者回報答案不佳或給予負面回饋時，開發團隊雖然能在日誌中看到查詢內容、回答文本與相似度分數，卻完全不知道系統是參考了知識庫（KB）中的哪一份文件。
這是一個普遍的治理盲區。如果我們無法將使用者的負面回饋精準對應到某一份、甚至某一版的來源文件，那麼知識庫的改善就只能憑空猜測。我們不知道是文件內容過時、資訊錯誤，還是檢索演算法撈錯了毫不相干的資料。在這種情況下，所謂的「持續改善」變成了一句空話，知識庫的維運也無法形成一個可管理的工程流程。
為什麼單純的回答分數不足以支撐治理？
在講求嚴謹與合規的企業環境中，「可解釋性」與「可追溯性」遠比單一的分數指標來得重要。一個只回報「85% 信心」的答案，與一個能明確指出「此答案根據內部文件《2024 Q3 產品規格書 v1.2》第 3 節內容生成」的答案，兩者在可信度上有天壤之別。前者是個統計數字，後者則是可驗證的證據。
當前的 RAG 評估框架，如 RAGAs，已經開始強調「忠實度」（Faithfulness）與「答案相關性」（Answer Relevancy）等更細緻的指標，這些指標都隱含著對來源內容的依賴。然而，這些評估多半發生在開發或測試階段。一旦系統上線，面對真實世界千變萬化的使用者查詢，我們需要的是一個持續運作的監控與回饋機制，也就是所謂的「評估運維」（Evaluation Operations, or EvalOps）。
真正的挑戰不在於單次評估得到高分，而在於建立一個能持續監控、分析並根據回饋迭代的系統。將 RAG 品質問題提升到 EvalOps 的層次，意味著我們承認 AI 系統的維運是一個永不停止的循環，而非一次性的交付。
若缺乏來源的可觀測性，任何後續的治理措施都將窒礙難行。例如，在金融或醫療領域，一個錯誤的 AI 回答可能導致嚴重的合規風險。如果監管機構要求說明某個建議的依據，僅僅拿出一個演算法的信心分數是完全不夠的，必須能夠追溯到具體的政策文件或臨床指南。
如何建立可追溯的 RAG 品質閉環？
要解決這個問題，我們必須將 RAG 系統的日誌（logging）提升到可觀測性（observability）的層次。這不僅是記錄更多資料，而是有策略地將回答生成的關鍵節點串連起來。前述的日本團隊提供了一個清晰的實作路徑，我認為可以歸納為一個通用的架構模式：
- 儀器化 RAG 管線 (Instrument the Pipeline)：修改 RAG 應用程式的程式碼，在生成答案的同時，不僅記錄查詢與回答，更要明確地將檢索階段回傳的來源文件資訊（例如：檔案名稱、文件 ID、甚至是版本號）加入結構化日誌中。例如，若檢索回傳了 3 份文件，這 3 份文件的名稱都應該被記錄下來。
- 集中化日誌與數據 (Centralize Logs and Data)：將這些包含來源資訊的結構化日誌，從應用程式傳送到一個集中的數據分析平台。在 Google Cloud 的生態系中，這條路徑是 Cloud Logging → BigQuery。這讓原本散落的日誌變成了可供查詢與分析的結構化數據。
- 建立分析視圖 (Create Analytical Views)：在 BigQuery 這類的數據倉儲中，建立專門的視圖（View）來串連使用者回饋、查詢內容、回答品質與被引用的知識庫文件。例如，可以建立一個視圖來呈現「所有獲得『不滿意』回饋的對話，以及它們各自參考了哪些文件」。
- 可視化與行動 (Visualize and Act)：利用 Looker Studio 或其他 BI 工具，將分析視圖轉化為儀表板。知識庫的管理者或產品經理可以一目了然地看到「被引用最多次但負評率最高的文件 Top 10」，從而知道應該優先審核與修改哪些內容。
這個閉環讓知識庫的改善從「被動回應」轉變為「主動優化」。團隊可以設定明確的 KPI，例如「將引用文件 A 的回答負評率從 15% 降至 5% 以下」，並透過這個系統來驗證改善措施是否有效。這正是將 AI 維運轉化為可驗證工程流程的核心。
從修正錯誤到洞察知識缺口
當這個可追溯的閉環建立起來後，它的價值不僅僅是修正錯誤。透過分析大量查詢與引用來源的數據，我們可以獲得更深層的洞見。例如，如果我們發現大量關於「產品退貨政策」的查詢，最終都無法在知識庫中找到高相關性的文件，這就暴露了知識庫的「內容缺口」（content gap）。這為知識管理團隊提供了明確的指引，告訴他們需要建立或補充哪些主題的內容。
將 RAG 品質管理從單一的分數指標，提升到一個涵蓋回饋、來源、內容的完整可觀測性系統，是讓 RAG 應用從「有趣的玩具」走向「可信的企業級服務」的關鍵一步。這不僅是技術問題，更是流程與治理的議題，需要開發團隊、產品團隊與知識管理團隊的通力合作。唯有如此，我們才能確保 AI 系統的回答不僅看起來正確，而且實際上可靠、可追溯、可治理。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。