完成「Query Normalization 與 Metadata Filtering：便宜但常被忽略的提升」後，下一個問題是「Hard Negative：Fine-tune 前最重要的資料工程」能否重跑、否定並留下失敗原因。這就是今天的範圍。

今天要回答的問題

從 baseline failure 中挖 difficult negatives，避免模型只學會分辨太簡單的正負樣本。

工程邊界

Hard Negative 是讓 Retriever 學會「很像但不對」

隨機 negative 太容易，模型很快就能區分；真正困難的是 BM25／Dense 排得很前、文字很相似、但其實不 relevant 的文件。這些 hard negatives 才能教模型 domain-specific decision boundary。

但要防止 false negative：某文件其實也是合理答案卻被當負樣本，會把模型往錯方向拉。因此 hard negative mining 仍要搭配 qrels 與抽樣人工檢查。

一個可以直接重現的起點

Fine-tune 先防資料洩漏

最重要的不是先挑 learning rate，而是確保同一個 query family、文件版本或高度相似樣本沒有跨 train/dev/test。訓練時完整記錄 base model、seed、batch、learning rate、epoch、negative sampling 與 checkpoint。

base_model: intfloat/multilingual-e5-base
seed: 42
train_split: train.jsonl
dev_split: dev.jsonl
negative_strategy: hard_negative

從錯誤候選建立 Hard Negative

這裡以「從 base retriever 的錯誤候選產生 hard negatives 並人工抽查」為比較目標，只保留 baseline、candidate 與逐項差值；evaluate 再接到實際評測程式。

METRICS = ('negative source', 'false-negative rate', 'query coverage')
baseline = evaluate("baseline", metrics=METRICS)
candidate = evaluate("candidate", metrics=METRICS)

for metric in METRICS:
    delta = candidate[metric] - baseline[metric]
    print(f"{metric}: {delta:+.4f}")

驗證與落地方式

驗證可從「從 base retriever 的錯誤候選產生 hard negatives 並人工抽查」開始。比較前先凍結 corpus、query set、qrels、資料切分與評測程式，確保實驗只改動目標元件。若 index、候選數或前處理同時改變，最後的分數差異就無法歸因，容易把資料變動誤認成模型進步。

這篇優先比較：negative source、false-negative rate、query coverage。除了整體平均，也要保留逐題結果與 query 類型，分辨改善集中在哪些情境、哪些案例反而退步。品質指標還要和 latency、記憶體、索引大小或單次成本一起閱讀，才能判斷提升是否值得帶進 production。

常見誤判

• 只公布最高分，沒有保留 baseline、負面結果與信賴區間，難以判斷改善是否穩定。
• 在相同資料上反覆調參又回頭評分，test set 會逐漸變成隱性的 training set。
• 只看 retrieval 或 generation 的單層指標，忽略錯誤可能沿 pipeline 傳遞，也可能被後段暫時掩蓋。

上線前檢查

每次實驗都應能追回資料版本、模型、index、config 與評測程式版本。上線前再以未參與調參的案例做一次回歸測試，並保留最差案例供 error analysis。若品質提升不足以抵銷延遲、成本或維護複雜度，維持較簡單的 baseline 通常更可靠。

如何閱讀結果

結果應先看逐題變化，再看整體分數。若平均值上升，卻只來自少數容易題，或關鍵 query 類型持續退步，仍不適合直接替換 baseline。每個明顯升降的案例都應回到候選文件、排名與輸入特徵，確認變化符合原先假設。

離線評測通過後，還要檢查線上條件：新文件加入後是否需要重建 index、cache 是否造成舊結果、查詢分布是否漂移。只有資料生命週期也能被管理，實驗中的品質提升才可能持續。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：hard negative 必須難但不能其實相關。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：hard negative 必須難但不能其實相關。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：Embedding Fine-tuning Dataset：怎麼切才不會資料洩漏。

參考資料

• BEIR Benchmark
• Sentence Transformers Documentation
• ir-measures
• RAGAS Documentation