點擊數據微調Reranker：現成模型何時失效

你搭好RAG流水線，從Hugging Face拽下bge-reranker-v2-m3，接在雙編碼器后面，看著命中率漲了8個百分點，然后就沒再碰過。兩個季度過去，領域漂移了，語料翻倍，一半查詢都是重排器沒見過的行話，客服工單來得比模型贏的還快。Recall@5看著還行，用戶可不這么想。

這就是現成重排器停止白給的臨界點。它們在MS MARCO和 handful 公開IR數據集上訓練，你的查詢是關于你的賬單流程、零件編號、內部縮寫。交叉編碼器分不清兩個幾乎一樣的產品規格里，工程師到底打開的是哪個。你的用戶能分清，他們點擊了。

點擊數據是你能擁有的最便宜微調信號。每次點擊都是標注正例：這個查詢，這個文檔，用戶選了它。每次點擊上方的跳過都是標注負例：這個查詢，這個文檔，用戶看到了但沒理。數據就在你的搜索日志里，問題是拿來干什么。

微調之前，先證明重排器是瓶頸。追蹤里通常出現的模式：檢索召回94%，重排后掉到78%。這16個點的差距就是重排器的鍋。如果檢索器根本沒召回文檔，怎么微調都沒用。先跑一遍RAG Evaluation Beyond Recall@K的四指標測試。如果忠實度和覆蓋率正常，recall@50很高，但rerank-top-5在下滑，那就微調重排器。其他情況，先修上游。

別搞復雜。最小可用的數據就四列：查詢、展示的文檔ID列表、點擊的文檔ID列表、時間戳。清洗有五條規則：過濾無點擊的查詢、去重同一查詢的多次展示、剔除異常會話、處理位置偏差、過濾過短查詢。清洗后輸出成偏好對列表：每個展示但未點擊的文檔，如果在點擊位置之上，就是硬負例；之下的丟棄，因為用戶可能沒往下翻。

一次展示5個文檔、點擊1個，最多產出4對負例。一個月百萬次展示，就是幾百萬對樣本，足夠了。有了偏好對，損失函數選能處理對的。MarginRankingLoss，概念上跟推薦系統里的BPR類似，要求模型給正例打分比負例高出一個margin。

微調不是萬能藥。它是領域漂移后的補丁，是現成模型失效后的補救。但前提是，你得先確認它真的是瓶頸。