[Day 13] 建立高品質評估資料集：讓測試案例更接近真實使用情境

昨天我們完成了自動化 RAG Evaluation Pipeline，開始用指標衡量 Retrieval 與 Answer 的品質

但很快會遇到一個問題：

如果測試問題本身就不夠好，那麼評估結果再精準也沒有意義

雖然可以確認系統是否能回答，但這無法代表真實使用者會遇到的所有情境

因此今天的重點不是再增加一個 Evaluation Metric，而是建立一套：

更接近真實使用情境的 Evaluation Dataset

為什麼 Evaluation Dataset 很重要

Evaluation Dataset 是整個 RAG 評估系統的基礎

什麼才算是高品質測試案例

一個好的測試案例，不應該只有問題與回答

而應該包含更多資訊，這樣後續就可以同時評估

建立 Question Type

真實使用者不會只問一種類型的問題

因此第一步，可以先將問題分類

事實型

直接從文件取得答案

關鍵字型

問題中包含明確關鍵字

語意改寫型

相同問題，但使用不同說法，兩者意思相同

這類問題可以測試 Embedding 與 Semantic Search 是否有效

Multi-Context

答案需要多個 Chunk

Unanswerable 文件無法回答

這是非常重要的一類

這可以用來測試 RAG 是否會：

在不知道答案時，選擇不知道，而不是自行猜測

問題不應該全部由人工想像

當文件數量增加之後，成本會非常高

因此可以讓 LLM 協助產生測試案例

這可以大幅降低人工建立 Dataset 的成本

但不要完全相信 LLM 產生的 Dataset

這是一個很重要的觀念：

LLM 可以協助建立 Evaluation Dataset，但不能直接視為 Ground Truth

加入真實使用者問題

除了人工設計與 LLM 生成之外，還有一個非常重要的來源：

真實使用者問題

例如產品正式上線後

如果發現某個問題經常失敗

那麼這就是非常有價值的 Evaluation Case

這種資料通常比單純自己想像的問題更有價值

今天的重點

今天不是單純「增加測試題數量」

而是建立一個觀念：

好的 Evaluation，不是問題越多越好，而是測試案例越能代表真實使用情境越好

從一開始的概念：

「把 RAG 做出來」

進入：

「用工程方法驗證 RAG 是否真的有效」

Day 14 預告

有了 Evaluation Dataset 之後，下一個問題就會出現：

測試失敗了，到底是哪裡出了問題

因此下一步，我們會開始進行：

Day 14：從失敗案例找出真正的問題

讓每一次 Evaluation 不只是得到一個分數，而是能回答：

「為什麼這次回答失敗」