前一篇討論「兩個標註者不同意怎麼辦:一致性與裁決」,這篇聚焦「MRR、NDCG、Hit@K、Macro-F1@K 到底各在量什麼」,並沿用同一組輸入、環境與判讀規則,避免只做名詞比較。
用同一批 toy ranking 展示不同指標的偏好,選定本系列 primary/secondary metrics。
Hit@K 問 Top-K 有沒有命中;MRR 關心第一個 relevant 結果多前;NDCG 同時考慮 graded relevance 與排序位置;Precision/Recall/F1 則觀察集合層面的取捨。
所以報告時至少同時保留「有沒有找回來」與「排得夠不夠前」兩種視角,並搭配 per-query 分析。只看一個平均值,很容易掩蓋某類重要 query 全部失敗。
MRR 特別在乎第一個 relevant document 出現多早;NDCG 同時看排序位置與 graded relevance;Hit@K 回答 Top-K 內有沒有命中;Macro-F1@K 則能把每個 query 的 precision/recall 平衡後再平均。本文應用同一組 toy ranking 手算一次,讓讀者知道「同一個結果,在不同指標上可能有不同解讀」。
這裡以「用手算小例子與 evaluator 同時計算四種 retrieval metrics」為比較目標,只保留 baseline、candidate 與逐項差值;evaluate 再接到實際評測程式。
METRICS = ('MRR', 'NDCG', 'Hit', 'Macro-F1 的逐題值')
baseline = evaluate("baseline", metrics=METRICS)
candidate = evaluate("candidate", metrics=METRICS)
for metric in METRICS:
delta = candidate[metric] - baseline[metric]
print(f"{metric}: {delta:+.4f}")
驗證可從「用手算小例子與 evaluator 同時計算四種 retrieval metrics」開始。比較前先凍結 corpus、query set、qrels、資料切分與評測程式,確保實驗只改動目標元件。若 index、候選數或前處理同時改變,最後的分數差異就無法歸因,容易把資料變動誤認成模型進步。
這篇優先比較:MRR、NDCG、Hit、Macro-F1 的逐題值。除了整體平均,也要保留逐題結果與 query 類型,分辨改善集中在哪些情境、哪些案例反而退步。品質指標還要和 latency、記憶體、索引大小或單次成本一起閱讀,才能判斷提升是否值得帶進 production。
每次實驗都應能追回資料版本、模型、index、config 與評測程式版本。上線前再以未參與調參的案例做一次回歸測試,並保留最差案例供 error analysis。若品質提升不足以抵銷延遲、成本或維護複雜度,維持較簡單的 baseline 通常更可靠。
結果應先看逐題變化,再看整體分數。若平均值上升,卻只來自少數容易題,或關鍵 query 類型持續退步,仍不適合直接替換 baseline。每個明顯升降的案例都應回到候選文件、排名與輸入特徵,確認變化符合原先假設。
離線評測通過後,還要檢查線上條件:新文件加入後是否需要重建 index、cache 是否造成舊結果、查詢分布是否漂移。只有資料生命週期也能被管理,實驗中的品質提升才可能持續。
判讀不只看最大或最漂亮的數字。這一天真正要回答的是:理解不同 metric 對排序錯誤的敏感度。
如果核心指標改善,但錯誤率、尾端延遲、資源成本或恢復能力變差,這代表取捨,而不是無條件進步。相反地,沒有改善也不是無效結果;至少能排除一條看似合理、實際上不值得增加複雜度的路。
今天的工程判斷是:理解不同 metric 對排序錯誤的敏感度。無論結果支持或否定原本假設,都必須保留完整條件,才能和下一天的實驗串在一起。
下一篇將處理:BM25 Baseline:先尊重一個很難被淘汰的對手。