你用來驗收 RAG 的那些指標，可能給的是模糊訊號

企業導入 RAG 助理後，驗收時常用的指標是「答對率」或「相關性分數」。這些指標來自學術基準，而學術基準測的是單輪問答。

問題在於：企業的實際使用情境不是單輪問答。

先界定：企業 RAG 的實際運作型態

Mukul Chhabra 等人的〈Case-Aware LLM-as-a-Judge Evaluation for Enterprise-Scale RAG Systems〉（arXiv:2602.20379，2026 年 2 月 23 日投稿）在摘要開頭就界定了差異：

「企業檢索增強生成（RAG）助理運作於多輪、案件導向的工作流程中，例如技術支援與 IT 維運，其評估必須反映營運限制、結構化識別碼（如錯誤代碼、版本）與問題解決流程。」

這段話裡有三個學術基準不會處理的東西：多輪、案件、結構化識別碼。

用客服的場景理解：客戶不會一句話講完問題。他先說「機器怪怪的」，你問型號，他說「不確定，我拍照給你」，然後才慢慢逼近真正的問題。整個過程是一個案件，不是五個獨立問題。

機制：企業特有的三種失效

論文指出既有評測方法沒抓到的三類問題：

• 案件誤判（case misidentification）　系統把這次的詢問，接到錯誤的既有案件上。後續回答全部建立在錯誤前提上。
• 流程錯位（workflow misalignment）　答案本身正確，但跳過了必要步驟。例如直接給更換零件的方法，略過了先確認保固狀態。
• 部分解決（partial resolution）　多輪對話後解決了一半。單看每一輪的回答都對，整個案件卻沒結案。

第三項最容易被漏掉。如果驗收只看單輪答對率，部分解決會被算成「大部分都對」——但對使用者來說，問題沒解決就是沒解決。

他們的作法：八項營運導向指標

作者提出以嚴重程度為基礎的評估系統，使用八項營運導向的指標，衡量五個面向：檢索品質、依據忠實度、答案效用、精確性完整度，以及案件與流程的對齊程度。

技術上採「決定性提示搭配嚴格的 JSON 輸出」，目的是讓評估能批次執行、可做迴歸測試與生產環境監控。

這個設計取向值得注意：他們把評估當成可自動化、可重複執行的工程流程，而不是上線前跑一次的驗收活動。

邊界：什麼情況下通用指標就夠了

• 單輪、獨立的問答　例如產品規格查詢，問完就結束，沒有案件延續性。
• 沒有結構化識別碼　不涉及錯誤代碼、版本號、料號這類必須精確匹配的資訊。
• 內部參考用途　答案只是輔助，最終判斷仍由人做。

需要案件感知評估的是：技術支援、IT 維運、客訴處理這類有明確案件生命週期、且要求結案的場景。

對台灣企業的意義

對做客服或技術支援自動化的企業，這篇提供了一份可直接照抄的驗收清單。

建議在既有的答對率之外，補測三件事：

一、案件延續性。用完整的多輪對話測，不要用單一問題測。看系統會不會在第三輪把案件接錯。

二、流程完整性。檢查答案有沒有跳過必要步驟。這一項需要領域知識，通常要由熟悉流程的人設計題目，不能外包給工程師。

三、結案率。不是「每一輪答得對不對」，而是「這個案件最後有沒有解決」。這是使用者真正在意的指標。

結構化識別碼那一項對製造業特別相關——料號、機型、版本號打錯一個字元，答案就完全不同。這正是純向量檢索的弱點，我們在向量資料庫那篇提過需要搭配關鍵字檢索的原因。

需要保留的懷疑

這是 arXiv 預印本，投稿時尚未經同儕審查。八項指標的定義與嚴重程度分級由作者團隊建立，非業界標準。

論文的實驗為兩個指令微調模型在長短工作流程下的比較，樣本範圍有限，摘要中未提供具體數值結果。因此本文引述的是其方法論主張，而非效能數據。

另外，以 LLM 作為評審（LLM-as-a-Judge）本身有已知限制：評審模型也會有偏誤，且對自己風格的輸出可能給分較高。使用這類方法時，仍建議保留一定比例的人工抽查。

常見問題

企業 RAG 的評測跟學術基準差在哪？

依 arXiv:2602.20379，企業 RAG 運作於多輪、案件導向的工作流程（如技術支援、IT 維運），評估須反映營運限制、結構化識別碼與問題解決流程。學術基準多為單輪問答，無法捕捉案件誤判、流程錯位與部分解決這三類企業特有的失效模式。

什麼是「部分解決」？為什麼容易被漏掉？

指多輪對話後問題只解決了一部分。單看每一輪的回答可能都正確，因此以單輪答對率驗收時會被計為表現良好，但整個案件並未結案。對使用者而言問題未解決即為失敗，因此建議以「結案率」而非「單輪答對率」作為主要指標。

驗收客服型 RAG 系統應該補測哪些項目？

三項：案件延續性（以完整多輪對話測試，觀察系統是否在後續輪次接錯案件）、流程完整性（檢查答案是否跳過必要步驟，題目需由熟悉流程者設計）、以及結案率（整個案件最終是否解決）。若涉及料號、機型、版本號等結構化識別碼，另需確認系統採用關鍵字與向量的混合檢索。

下一步

把驗收從「上線前跑一次」改成「可重複執行的迴歸測試」，是這篇論文最實用的建議。若你正在規劃客服或技術支援的自動化，可先從建立多輪測試案例開始，相關表單收錄於白皮書專區。

出處

本文引述出自 Mukul Chhabra、Luigi Medrano、Arush Verma〈Case-Aware LLM-as-a-Judge Evaluation for Enterprise-Scale RAG Systems〉，arXiv:2602.20379，2026 年 2 月 23 日投稿，arxiv.org/abs/2602.20379。加註引號者為論文摘要原文之中譯。

該論文為預印本，投稿時尚未經同儕審查。八項指標之定義與分級為作者團隊建立，非業界標準；摘要未提供具體數值結果，本文引述其方法論主張而非效能數據。