RAG 的最後一哩路：將用戶回饋化為可治理的 Evaluation Ops
RAG 系統上線後，優化卻陷入盲點？本文將揭示如何擺脫憑直覺修補知識庫的困境。我們將探討如何把使用者回饋，如成功率、評分與無法回答的問題，轉化為可量化的結構化數據，並建立一套「評估維運」（Evaluation Ops）機制，讓知識庫（KB）的迭代與治理，真正做到可驗證、可衡量。
許多團隊導入檢索增強生成（RAG）系統後，都期望能有效解決內部知識檢索與問答的難題，但很快就會陷入「上線即巔峰，後續優化全憑感覺」的困境。我的觀察是，問題不在模型或數據本身，而在於缺乏一套系統性的「評估維運」（Evaluation Ops）機制。本文的核心觀點是：我們必須停止憑直覺修補知識庫，轉而將使用者回饋——包含成功率、fallback、使用者評分與無法回答的問題——轉化為結構化數據，用以驅動可驗證、可衡量的知識治理迭代。這不僅是技術問題，更是建立可信任 AI 系統的基石。
為什麼多數 RAG 系統的知識庫（KB）更新都像在瞎子摸象？
一個 RAG 系統上線後，最常見的維運場景，是依賴使用者零散的回報來發現問題。例如，有人在內部通訊軟體抱怨「機器人答非所問」，或是在某次會議中提到「某個重要文件似乎沒有被索引到」。開發團隊接著介入，手動檢查日誌、重現問題，然後針對性地更新知識庫（KB）。
這個流程極度被動且缺乏效率。它有幾個根本缺陷：
- 樣本偏差（Sampling Bias）：只有最敢於發聲或最受問題困擾的使用者會回報，他們的意見無法代表整體使用體驗。
- 缺乏量化指標：我們無法回答「整體回答成功率是多少？」、「最常讓系統 fallback 的問題類型是什麼？」、「上週的 KB 更新，是否真的提升了使用者滿意度？」等關鍵問題。
- 驗證困難：當我們根據單一回報調整了 KB，很難驗證這個改動是否對其他查詢產生了負面影響。所有決策都基於軼事證據（anecdotal evidence）而非數據。
這種模式讓 KB 的迭代更像是一門藝術或猜謎遊戲，而非可管理的工程實踐。要擺脫這個困境，我們需要建立一套度量衡，讓 RAG 系統的表現能夠被客觀地衡量與分析。
從使用者回饋到結構化數據：建立 RAG 的度量衡
要實現數據驅動的 KB 治理，第一步是定義需要追蹤的關鍵指標。與其等待使用者回報，不如主動在系統中埋設探針，捕捉每一次互動的訊號。日本開發者部落格 Developers.IO 的一篇文章，便提供了一個基於 Google Chat Bot 的極佳實踐案例。
其核心是將使用者互動的結果，轉換為結構化的 JSON 日誌。我認為，一個最簡可行（Minimum Viable）的 RAG 評估訊號，至少應包含以下四種類型：
- 回答成功率（Success Rate）：系統根據檢索到的上下文，成功生成了回答。
- Fallback 率（Fallback Rate）：系統判斷無法回答，觸發了預設的「我不知道」或轉接真人的流程。
- 使用者滿意度（User Satisfaction）：在每次回答後，提供一個簡單的「👍/👎」或評分機制，讓使用者能即時給予回饋。
- 無法回答的問題（Unanswered Questions）：將所有導致 fallback 的使用者查詢，以及收到負面回饋的查詢，都記錄下來。
透過在應用層（例如聊天機器人後端）實作這些日誌，我們就能將模糊的使用者體驗，轉化為可匯總、可分析的結構化數據。這為後續建立自動化分析管線打下了基礎。
如何打造一套可行的 Evaluation Ops 管線？
有了結構化數據源，下一步就是建立一套從收集、匯總到可視化的自動化管線。這套管線，我稱之為「Evaluation Ops」，其精神與 MLOps 相似，都是為了讓系統的迭代有紀律、可追蹤且自動化。參照前述案例，一個典型的管線可以分為以下幾個階段：
1. 捕捉（Capture）： 在機器人後端，為每一次查詢生成一個唯一的 session ID。當查詢結束時，將查詢內容、結果類型（成功/fallback）、引用的文件來源、以及 session ID，以 JSON 格式寫入日誌。例如，使用 Google Cloud Logging 的結構化日誌功能。
2. 請求（Request）： 不要依賴使用者的善意。在每一次回答後，主動透過 UI 元件（如 Google Chat 的對話框或 Slack 的按鈕）請求回饋。將使用者的評分（例如，1 到 5 星）與對應的 session ID 關聯起來，並寫入另一條日誌。
3. 匯總與分析（Aggregate & Analyze）： 將所有結構化日誌匯出到一個數據倉儲或分析平台。在 Google Cloud 生態系中，可以將 Cloud Logging 的日誌匯流至 BigQuery。接著，使用像 Looker Studio 這樣的 BI 工具，建立儀表板，將數據可視化。
這套流程的核心精神，是將被動、反應式的「問題回報」，轉變為主動、系統性的「訊號收集」。它讓維運團隊從「救火隊」轉型為「數據分析師」。
有了儀表板，我們就能輕易地回答先前無法回答的問題。例如，我們可以設定一個警報，當 fallback 率在 7 天內超過 15% 時自動通知負責人。我們也可以每週檢視「低分回答排行榜」與「最常被問的 fallback 問題」，將其作為知識庫內容補充的優先級排序依據。這使得每一次的知識庫更新，都是基於數據洞察，其成效也能在下一個迭代週期中被驗證，形成一個封閉的改善迴圈。
事實上，這正是 LLM 系統評估領域持續努力的方向。相關研究如 RAGAS 或更廣泛的 LLM 評估框架，都旨在將模型表現的衡量標準變得更客觀、更自動化。
將 RAG 系統的用戶回饋轉化為一套可治理的 Evaluation Ops，是從「能用」邁向「可靠」的關鍵一步。它不僅僅是技術管線的搭建，更是一種思維模式的轉變——從依賴個人經驗，轉向信任數據驅動的決策。唯有如此，我們才能打造出真正能夠持續學習、自我完善、並贏得使用者信任的 AI 系統。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。