昨天我把 corpus 的文件身份、metadata、重複與 snapshot hash 固定下來。但 corpus 乾淨，不代表評測就公平。

如果問題全是我看著文件標題想出來的，BM25 很可能看起來特別強；如果只挑高度改寫的口語問題，又可能反過來偏袒 Dense Retrieval。在任何 retriever 進場以前，我得先知道 query set 裡到底有什麼、沒有什麼。

先把 Query 從「一句文字」變成可統計的樣本

原本的 queries.jsonl 只有 query_id 與 query。這樣可以跑檢索，卻無法回答「我是不是只收集到某一種問題」。我沒有改寫已被舊實驗 hash-pinned 的檔案，而是新建 queries-day04.jsonl 保留擴充 metadata 後的 snapshot。

我為每題補上六個欄位：

{
  "query_id": "q-room-approval",
  "query": "八人以上會議室預約需要主管核准嗎",
  "metadata": {
    "intent": "policy",
    "difficulty": "boundary",
    "lexical_form": "multi-constraint",
    "answerability": "answerable",
    "split": "test",
    "frozen": true
  }
}

這些欄位不是為了把 JSON 變得好看，而是讓我能分別觀察：

• intent：問題是 how-to、policy、troubleshooting 還是 escalation。
• difficulty：是基礎題、邊界題，還是需要多段證據。
• lexical_form：是否直接使用文件詞彙、口語改寫或多個條件組合。
• answerability：corpus 是否應該有答案，或原問題本身需要追問。
• split：這題可以用來調整系統，還是只能在最後評測。
• frozen：是否禁止因為看到錯題就原地改題。

實際 Audit 結果沒有很好看

寫了 labs/retrieval/audit_query_set.py，不跑 BM25、Embedding 或 Reranker，只檢查 schema 與類型覆蓋。執行：

python3 labs/retrieval/audit_query_set.py \
  --output /tmp/day04-query-audit.json

實際輸出的核心結果是：

status: ready-with-gaps
query_count: 7
structural_issue_count: 0
coverage_warning_count: 4

intent:
  escalation: 1
  how-to: 2
  policy: 3
  troubleshooting: 1

answerability:
  answerable: 7

四個 coverage warnings 是：

pilot set has fewer than 20 queries
no unanswerable query is represented
no ambiguous query is represented
no multi-hop query is represented

這個結果比「7 題都能跑」有價值得多。告訴我，目前只有一組結構正確的 pilot set，還不是可以代表真實使用情境的 benchmark。

最大的偏差：每一題都預設「找得到」

現有 7 題的 answerability 全是 answerable。如果直接用這批題目評估 RAG，我其實沒有測到一個很重要的能力：當 corpus 沒有證據時，系統會不會停下來？

同樣地，沒有 ambiguous query，我就無法測到系統是否知道要追問；沒有 multi-hop query，就無法觀察單一文件檢索和多段證據整合的差別。

所以我不會用「再多想幾個類似問題」解決。後續擴充時必須先按 taxonomy 設配額，再在每類裡撰寫：

不會把 7 題硬切成 Train、Dev、Test

小數據隨機切分看起來很「機器學習」，實際上每個 split 可能只剩一、兩題，類型也會因為隨機 seed 而消失。

我現在將這 7 題全部標成 split: test 與 frozen: true，意思不是已經足夠，而是：

• 這 7 題只用來檢查每次改動有沒有後退。
• 不根據這 7 題的錯題逐題調 prompt、權重或 training pair。
• Fine-tune 需要的 train/dev queries 另外建立，不從這份 frozen test set 备製。
• 擴充版 benchmark 先決定類型配額，再撰題，不是先收集容易題再補標籤。

這是我現在能做到的最小污染防線。

結構正確和覆蓋充足要分開

我又用現有 task validator 確認 enriched JSONL 仍然能被後續 pipeline 載入：

status: valid
documents: 7
queries: 7
qrel_pairs: 9
orphan_queries: 0
orphan_documents: 0

這和 query audit 的 ready-with-gaps 並不矛盾。valid 表示 ID、JSONL 與 qrels reference 沒有斷掉；ready-with-gaps 表示雖然可以跑，情境覆蓋還不夠。

這個區別很重要。一套可以成功載入的 benchmark，仍然可能從題目設計階段就已經偏了。

今天的結論

今天我沒有跑任何 retriever，而是把現有問題變成可統計的 query set，然後直接看見缺口。

一個 Query Set 的價值，不是能讓系統答對多少題，而是能不能代表我想要系統處理的成功、邊界與失敗情境。

下一步才是對這些 query 建立 qrels。到時另一個問題會出現：什麼叫「相關」，又該如何處理部分相關與無答案題？

下一篇：Day 05｜Qrels：沒有相關性標註，就沒有真正的 Retrieval 評測

參考資料

1. BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models
2. TREC, Data — English Relevance Judgements
3. Sentence Transformers, Information Retrieval Evaluator

本篇所有 query 均為公開 synthetic data，與我的工作無關。