6.1 評估 RAG 的挑戰

RAG 搭起來之後，最常見的做法是自己問幾個問題，看答案「感覺還不錯」就上線了。這樣有兩個問題：你只試了幾個容易的問題，而且你沒辦法知道改一個設定之後，是變好還是變壞。

要系統性地改進，先要能量。但 RAG 的評估，比一般程式難很多。

為什麼難

1. 輸出是自由的文字，沒有唯一的正確答案

一般程式的測試很簡單：輸入 2 加 3，輸出應該等於 5。但 RAG 的答案是一段話，同樣的意思有無數種寫法。「公司會把沒休完的假折算成工資」和「未休完的特休天數將以薪資補發」是同一個意思，但文字完全不同，沒辦法用「字串相等」判斷對錯。

2. 有兩個元件，錯誤會疊加

RAG 至少有檢索和生成兩個部分。答案不好，可能是：

• 檢索沒找到對的資料；
• 找到了，但模型沒讀對；
• 兩者都有問題。

只看最後的答案，分不出是哪一邊的問題，也就不知道要改哪裡。所以要分別評估兩個元件，再看整體。

3. 需要「標準答案」，而且很貴

要評估，就要有一批「問題加正確答案」的測試資料。這些通常得靠人一題一題整理，費時費力，而且需要懂這份資料的人才做得了。

4. 模型的輸出有隨機性

同一個問題問兩次，答案可能不完全一樣。評估的結果因此帶有雜訊，要多測幾次、或把隨機性調低。

5. 「好」是多面向的

一個好的答案同時要：

• 正確，
• 有根據，
• 切題，
• 完整，
• 語氣合適，
• 在沒有資料時誠實說不知道，
• 還要快、要便宜。

這些面向可能互相牽制。例如，要求「只根據資料」可能讓答案變保守，過度拒答。

6. 評估也可能出錯

如果拿另一個 LLM 當裁判來打分數（6.3 會介紹），裁判本身也會有偏見和錯誤。

7. 結果因資料而異

別人的評測結果、排行榜上的分數，不一定適用於你的資料。你的文件、你的使用者會問的問題，才是真正的考題。

小樣本的陷阱

測試資料少的時候，要特別小心。後面 6.7 的實驗只有 14 個問題，「Hit@1 從 0.79 變成 0.86」其實只是多答對了一題。這麼小的差異，換一批問題可能就反過來了。

所以：

• 測試集要盡量大、盡量涵蓋各種問題。
• 看到小的差距，不要太快下結論。
• 要記得這個數字是這份測試集上的結果。

評估的基本策略

面對這些困難，常見的做法是：

1. 準備一份測試集：一批有代表性的真實問題，盡量附上正確答案所在的資料。
2. 分開評估各元件：先量檢索（6.2），再量生成（6.3）。
3. 再看端到端：整體的表現（6.4）。
4. 改一個地方，重測一次：確認有進步，沒有改壞別的（6.6）。
5. 持續：資料會變、使用者的問題會變，評估要重複做。

測試集長什麼樣子

一份實用的測試集，至少包含：

欄位	範例
問題	事假最多可以請幾天？
正確答案所在的資料（用於評估檢索）	員工手冊 > 病假與事假
參考答案（用於評估生成，可選）	一年內以十四日為限，不發薪水
問題類型	直接詢問、換句話說、需要多段資料、資料裡沒有答案

特別建議加入：

• 口語、不完整的問法：真實使用者不會照文件的用字問。
• 資料裡沒有答案的問題：用來檢查系統會不會亂編。
• 容易混淆的問題：例如「病假」和「事假」，測試系統分不分得開。

測試集可以從這些地方來：真實使用者的提問紀錄、請熟悉資料的人出題，或是用 LLM 根據文件產生問題再由人審核。