你搭好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。
微調不是萬能藥。它是領域漂移后的補丁,是現成模型失效后的補救。但前提是,你得先確認它真的是瓶頸。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.