iT邦幫忙

2026 iThome 鐵人賽

DAY 8
0
AI Engineering

企業知識檢索與 RAG 工程:標註、微調、混合檢索、Rerank 與可重現評測系列 第 8 篇

Day 08|BM25 Baseline:先尊重一個很難被淘汰的對手

  • 分享至 

  • xImage
  •  

前一篇處理「MRR、NDCG、Hit@K、Macro-F1@K 到底各在量什麼」,這篇進一步討論「BM25 Baseline:先尊重一個很難被淘汰的對手」。共同的量測條件是前後比較的基礎。

今天要回答的問題

建立 lexical baseline,處理繁中 tokenization/欄位 weighting/參數,保留完整設定供後續比較。

工程邊界

BM25 是必須尊重的 Baseline

BM25 對精確詞彙、專有名詞、料號與低頻 token 很有優勢,而且計算成本低、可解釋。企業 corpus 內常存在大量這類詞,因此 Dense Retriever 並不保證全面勝出。

真正有價值的比較是:哪些 query BM25 贏、哪些 Dense 贏,以及兩者錯誤是否互補。如果互補,才有 Hybrid Retrieval 的工程理由。

一個可以直接重現的起點

Baseline 要夠強,後面的提升才有意義

BM25 不該只是裝上套件跑預設值。繁體中文至少要交代 tokenization、欄位組合與參數設定,並把設定檔保存。企業資料常有專有名詞與精確字串,這正是 lexical retrieval 可能比 dense retrieval 更穩的地方。

先保留一個可比較的 BM25

這裡以「在固定 corpus/query/qrels 上重跑 BM25」為比較目標,只保留 baseline、candidate 與逐項差值;evaluate 再接到實際評測程式。

METRICS = ('Hit@K', 'MRR', 'NDCG', 'Macro-F1', 'per-query rank')
baseline = evaluate("baseline", metrics=METRICS)
candidate = evaluate("candidate", metrics=METRICS)

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

驗證與落地方式

驗證可從「在固定 corpus/query/qrels 上重跑 BM25」開始。比較前先凍結 corpus、query set、qrels、資料切分與評測程式,確保實驗只改動目標元件。若 index、候選數或前處理同時改變,最後的分數差異就無法歸因,容易把資料變動誤認成模型進步。

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

常見誤判

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

上線前檢查

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

如何閱讀結果

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

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

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是:建立所有後續方法都必須超越的 lexical baseline。

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

今天的結論

今天的工程判斷是:建立所有後續方法都必須超越的 lexical baseline。無論結果支持或否定原本假設,都必須保留完整條件,才能和下一天的實驗串在一起。

下一篇將處理:Dense Retrieval Baseline:Embedding 真的懂你的 Domain 嗎。


參考資料


上一篇
Day 07|MRR、NDCG、Hit@K、Macro-F1@K 到底各在量什麼
下一篇
Day 09|Dense Retrieval Baseline:Embedding 真的懂你的 Domain 嗎
系列文
企業知識檢索與 RAG 工程:標註、微調、混合檢索、Rerank 與可重現評測 共 12 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言