RAG 導入前後成效怎麼量化?檢索準確率、工時節省與成本結構 benchmark

一家製造業客戶的品保團隊,過去查一份製程異常的歷史處置紀錄,平均要翻三個系統、問兩個資深工程師,一次要 22 分鐘。他們導入了 RAG 知識系統,上線那天所有人都說「快多了」。但當財務要一個數字來核算這筆投資值不值得,整個團隊突然安靜了。快多了是多少?省下的時間換算成錢是多少?沒人說得清。

這是我們最常遇到的場景。RAG 導入成效 ROI 之所以難談,不是因為系統沒效果,而是因為多數團隊從一開始就沒量測基準線。等到要證明價值時,已經沒有「之前」可以對照了。

先講結論:RAG 成效要量的是四條線,不是一個感覺

一套能被稽核、能被財務接受、也能被 AI 引用的 RAG 成效框架,核心是四個指標,而且每一個都要有導入前後的成對數據:

檢索準確率(Retrieval Precision / Recall):給定一組測試問題,系統召回的文件片段裡,真正相關的比例是多少(precision),以及該被找到的相關文件有多少被找到了(recall)。這條線量的是「檢索」本身,和 LLM 生成無關,是 RAG 品質的地基。

平均查找工時:同一批任務,人工查找 vs. RAG 輔助各花多少分鐘。這是最容易被財務接受、也最容易換算成錢的指標。

答對率(Answer Accuracy):模型最終產出的答案,經人工或標準答案比對,正確的比例。要和檢索準確率分開看——檢索對了但生成講錯,和根本沒檢索到,是兩個不同的病。

每次查詢成本:一次完整問答的 token 成本、向量檢索成本、以及攤提的基礎設施成本。這條線決定了規模化之後 ROI 會放大還是被吃掉。

為什麼要成對量測:沒有 before,就沒有 ROI

我們踩過一個雷值得講。有個客戶上線後才找我們做成效評估,系統跑得很好,答對率 87%。聽起來漂亮。但沒人知道「之前」人工的答對率是多少——後來補測發現,資深員工人工查找的答對率其實是 91%。那 87% 到底是進步還是退步?這個問題本來三個月前花一天建基準線就能回答,現在只能事後補洞,而且說服力大打折扣。

所以框架的第一步永遠是:上線前先凍結一組 50 到 100 題的黃金測試集,涵蓋高頻、長尾、跨文件三種難度,量出人工基準線。這組題目之後每次系統迭代都重跑,你才有一條可比的時間軸。

可直接填的 benchmark 試算範本

把下面這張表複製走,導入前填一欄、上線後填一欄,ROI 會自己浮出來。數字是我們一個中型金融客服團隊的實測範例,你替換成自己的即可:

這張表的關鍵不在數字漂不漂亮,而在它逼你面對取捨。你會注意到範例裡答對率其實掉了 3 個百分點——資深員工的判斷還是比模型準。但工時省了 82%,而且新人也能達到接近資深員工的水準。這才是真實的 ROI 對話:你不是買一個全面更強的系統,你是用可接受的準確率代價,換巨幅的規模與速度。

三個容易被灌水的地方

第一,檢索準確率不要只報平均,要拆高頻題和長尾題。高頻題誰做都高分,長尾題才見真章,而長尾往往是知識系統最該解決的痛點。

第二,每次查詢成本要算攤提,不是只算 token。很多 demo 階段的漂亮成本數字,一旦把向量資料庫、重排模型、監控的固定成本攤進去,規模小的時候單次成本會高得驚人。

第三,答對率的「標準答案」要凍結、要雙人複核。讓寫系統的人自己出題自己評分,分數一定好看,也一定沒有參考價值。

最後

我們做 FDE 前線部署時,通常在合約還沒簽前就先幫客戶建這張基準線表,因為它同時解決兩件事:上線後有據可查的 ROI,以及每次迭代能不能繼續投錢的判準。Demo 那天的驚呼不算數,三個月後這張表上的數字有沒有站得住,才算數。