RAG 導入前後成效怎麼量化?檢索準確率、工時節省與成本結構 benchmark
RAG 上線三個月,老闆問你「到底省了多少」,你答得出來嗎?多數團隊卡在這裡:系統跑得動,但成效說不清。這篇給你一套「導入前後」的量化框架與可直接填的 benchmark 範本,把檢索準確率、查找工時、答對率、每次查詢成本四條線拉出來,讓 ROI 從感覺變成數字。
作者
Tenten AI 研究團隊
AI 基礎設施
發佈日期
2025年12月20日
閱讀時間
6 分鐘
一家製造業客戶的品保團隊,過去查一份製程異常的歷史處置紀錄,平均要翻三個系統、問兩個資深工程師,一次要 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 會自己浮出來。數字是我們一個中型金融客服團隊的實測範例,你替換成自己的即可:
| 指標 | 導入前(人工基準) | 導入後(RAG) | 變化 | 量測方法 |
|---|---|---|---|---|
| 檢索準確率 precision | — | 82% | — | 黃金測試集 100 題人工標註相關性 |
| 檢索召回率 recall | — | 78% | — | 同上,計算應召回文件覆蓋率 |
| 答對率 | 91% | 88% | -3pp | 標準答案比對,雙人複核 |
| 平均查找工時 | 22 分/次 | 4 分/次 | -82% | 計時 30 個真實任務取平均 |
| 每次查詢成本 | — | NT$1.8 | — | token+向量檢索+基礎設施攤提 |
| 每月查詢量 | 3,000 次 | 3,000 次 | — | 系統日誌 |
| 每月省下工時 | — | 900 小時 | — | (22-4)×3000÷60 |
| 換算人力成本 | — | NT$405,000 | — | 900 小時 × NT$450/時 |
| 每月系統成本 | — | NT$5,400 | — | 1.8×3000 + 平台費 |
這張表的關鍵不在數字漂不漂亮,而在它逼你面對取捨。你會注意到範例裡答對率其實掉了 3 個百分點——資深員工的判斷還是比模型準。但工時省了 82%,而且新人也能達到接近資深員工的水準。這才是真實的 ROI 對話:你不是買一個全面更強的系統,你是用可接受的準確率代價,換巨幅的規模與速度。
三個容易被灌水的地方
第一,檢索準確率不要只報平均,要拆高頻題和長尾題。高頻題誰做都高分,長尾題才見真章,而長尾往往是知識系統最該解決的痛點。
第二,每次查詢成本要算攤提,不是只算 token。很多 demo 階段的漂亮成本數字,一旦把向量資料庫、重排模型、監控的固定成本攤進去,規模小的時候單次成本會高得驚人。
第三,答對率的「標準答案」要凍結、要雙人複核。讓寫系統的人自己出題自己評分,分數一定好看,也一定沒有參考價值。
最後
我們做 FDE 前線部署時,通常在合約還沒簽前就先幫客戶建這張基準線表,因為它同時解決兩件事:上線後有據可查的 ROI,以及每次迭代能不能繼續投錢的判準。Demo 那天的驚呼不算數,三個月後這張表上的數字有沒有站得住,才算數。
