RAG 重排作用与实现

这道题其实问的是[[RAG]]系统里召回和[[重排]]的职责分离，为什么不能一步到位。我的理解是，召回阶段追求效率，用[[Bi-Encoder]]把query和doc分别编码成向量，然后近似检索，这个阶段能快速拿到几百个候选，但精度有限。因为向量相似不总是等于真实相关，比如用户搜“退款流程”，向量可能召回“退货地址”，语义上相关但实际不是用户要的。重排就是专门解决这个问题的，用更精细的模型在几十毫秒内把这批候选重新打分排序。

具体来说，重排有几个关键作用。首先是语义精排，召回用的双塔模型把query和doc独立编码，交互不够精细，而重排可以用[[Cross-Encoder]]让query和doc做全注意力交互，捕捉细粒度匹配。举个例子，在客服退款场景里，用户问“商品破损怎么退款”，召回可能出来一堆“退货流程”“退款时效”“破损定义”的文档，重排能准确把“破损退款操作步骤”排到最前面。其次是多路融合，实际系统常常同时用关键词[[BM25]]、向量、[[知识图谱]]等多路召回，它们的分数不在一个尺度上，重排可以用一个统一的模型给所有候选打分，把不同来源的结果融合起来。

常见的实现方式，最主流的是Cross-Encoder，比如BGE-Reranker，精度高，但计算成本也高，所以一般只对召回Top-100做重排，再输出Top-10给LLM。另一个是[[ColBERT]]，用late interaction机制，在token级别做MaxSim，速度和精度比较平衡，适合对延迟要求更高的场景。我的选择倾向是：如果业务对精度要求极高，比如金融风控合同检索，必须用Cross-Encoder；如果延迟敏感，比如实时对话，用ColBERT或[[蒸馏]]版MiniLM。 当然，真正落地常常是两者结合，先用ColBERT粗排到Top-50，再用Cross-Encoder精排到Top-5。

这里有个坑：重排模型一定要和召回模型在训练数据分布上对齐，否则重排可能把本来对的候选打低。举个例子，召回用的向量模型是在通用语料上训练的，重排模型如果只在QA对数据上微调，遇到企业SOP这种长文档就会误判。上线前我会特别关注候选集的覆盖率和重排分数的分布，如果发现重排后Top-10里召回阶段的高分文档被大量丢弃，就要排查是不是重排模型有偏见。

另外，最近也有用大模型直接做重排的尝试，比如让LLM输出相关性分数或直接生成排序。这个方向精度很高，但成本和延迟都太大，我觉得短期内只适合离线场景或作为精排的最后一层。不过如果未来推理成本降下来，可能会改变现有架构。

所以我会把重排看作RAG系统里精度和效率的平衡器，它不是一个可选项，而是保证LLM输入质量的最后一道关卡。没有重排，召回阶段的噪声会直接污染生成结果，导致[[Hallucination]]。我的建议是，先做一套轻量级重排上线，再根据业务反馈逐步升级模型。