先定義評測集要證明什麼
建立評測集以前，先釐清 RAG 系統必須完成的工作。內部知識助手可能要回答制度問題、比較產品規格、整理跨文件資訊，也可能必須在資料不足或使用者無權存取時拒答。這些任務的失敗成本不同：找錯文件、引用過期內容、拼湊不存在的結論，以及洩漏受限資訊，不能只用同一個「答案看起來合理」的分數處理。
我們通常把每個案例視為一份可驗證的行為規格，至少包含問題、使用者情境、允許存取的知識範圍、預期證據、答案要點，以及應否拒答。評測集因此不只是問題與標準答案的配對，也記錄當時的文件版本、索引設定與權限條件，讓結果能重現。
從風險與真實流量建立案例
初始案例應同時來自業務流程、領域專家訪談、客服或搜尋紀錄，以及上線前的威脅建模。只讓專家編寫「理想問題」，往往會漏掉縮寫、錯字、口語表達、資訊不完整與跨文件追問；只使用歷史流量，則可能延續既有產品的盲點。兩者需要交叉取樣。
- 核心任務：高頻且答案明確的制度、操作與產品問題。
- 長尾問題：低頻但對工作流程重要，需要跨段落或跨文件整合。
- 困難負例：字詞相似但不相關、版本已失效或適用條件不同的文件。
- 不可回答案例：知識庫沒有答案、問題含糊，或證據不足以支持結論。
- 權限案例：同一問題在不同角色、部門或資料範圍下應得到不同結果。
案例比例不必模仿整體流量；評測集的目的也包括放大高風險情境。較實用的做法是分成穩定的核心集、針對近期變更的回歸集，以及反映真實流量的抽樣集，避免單一總分掩蓋重要退步。
標註證據，而不只撰寫標準答案
每個可回答案例都應標出支持答案的最小證據範圍，包括文件識別、版本、段落，以及必要的適用條件。若答案需要結合多份文件，應註明哪些證據缺一不可。這能直接評估檢索是否找到正確內容，也能區分「沒有取回證據」與「模型拿到證據卻解讀錯誤」。
標準答案宜保存為必要要點與禁止主張，而不是要求模型逐字重現一段文字。對程序或合規問題，可另外標註順序、例外條件、日期敏感性與引用要求。對無法回答的案例，則要記錄拒答原因，以及可接受的下一步，例如要求補充資訊或引導使用者查閱指定系統。
分層評估檢索、生成與整體行為
RAG 是一條管線，單一答案分數很難提供修正方向。我們會固定語料快照與查詢條件，分別測量檢索、內容忠實度、任務完成度和系統限制；更換嵌入模型、切分策略或提示詞時，才能知道改善與退步發生在哪一層。
- 檢索層：必要證據是否出現在前 k 筆結果、排名是否合理，以及困難負例是否被排除。
- 生成層：每個重要主張能否被取回內容支持，有無忽略條件、混用版本或自行補完。
- 任務層：答案是否涵蓋必要要點、表達可執行，並符合引用、格式與語言要求。
- 安全層：資料不足時是否拒答，權限受限時是否避免透露內容，提示注入是否改變既定規則。
自動評審適合擴大覆蓋，但不能成為唯一裁判。關鍵案例應保留規則檢查與人工複核，並定期檢查評審模型是否偏好冗長答案、忽略細微條件或接受無法追溯的敘述。發布門檻也應按案例類型設定，而非只看平均分數。
把評測集當成有版本的工程資產
知識庫、權限、模型與使用方式都會變，評測集也必須跟著維護。每次文件改版、索引調整或正式事故都應觸發影響分析：舊案例是更新證據、保留為歷史回歸，還是因業務規則失效而退役。任何變更都要經審查並留下原因，避免團隊為了讓新版本過關而無意中降低難度。
實務上可為案例保存擁有者、來源、風險類別、建立原因、語料快照與最近審查日期；將失敗案例先放入候選區，去除重複並完成標註後再納入核心集。持續追蹤各切片的結果與失敗原因，比追求一個漂亮總分更有價值。當評測集能重現真實問題、指出責任層級並阻擋已知退步，它才真正成為 RAG 發布流程的一部分。