RAG 重排收益与成本

这道题其实问的是[[RAG]]系统里检索精度和效率怎么平衡的问题。如果只靠向量检索，也就是用[[Bi-Encoder]]把查询和文档各自编码成向量，再用余弦相似度去匹配，这样做的好处是快，能一次性从百万级文档里捞回几百个候选，但坏处是匹配很粗，它本质上是把语义压缩成一个固定向量，很多细粒度的交互信息就丢了。比如用户问“怎么退换货”，向量检索可能把“换货流程”和“退货政策”都捞上来，但实际答案只需要其中一篇，另一篇就是干扰。所以说，第一阶段是保召回、牺牲精度的，它适合做“粗筛”。

那[[重排]]就是来解决这个问题的。它用的是[[Cross-Encoder]]，把查询和文档拼在一起同时编码，做深度交互，这样能捕捉到那些向量相似但主题偏离的“伪相关”文档。嗯，你可以这么理解，向量检索像海选，看个大概就行，重排像终面，要仔细看简历细节。所以标准做法是：向量检索先取Top-100到Top-200，然后重排模型在这小候选集上重新打分，最后只取Top-5到Top-10送给大模型生成。代价是重排这一步是同步阻塞的，会引入几十到几百毫秒延迟，所以得控制候选数量，或者用轻量级的Rerank模型。

举个例子，在电商客服场景里，用户问“这个订单为什么还没发货”，向量检索可能同时召回发货延迟政策、物流状态查询入口、以及一个完全不相关的满减活动文档。如果这些文档都送进生成，大模型很可能被满减活动带偏，给出“您可以关注满减优惠”这种答非所问的回复，这就是典型的[[Hallucination]]。加了重排之后，它会优先把真正描述订单状态的文档排到前面，把不相关的压下去，生成质量就稳多了。

这里有个坑，就是重排也不是万能的。它依赖一个前提：第一阶段的召回集里必须包含正确答案。如果向量检索本身就没把相关文档捞回来，那重排再好也没用。另外，重排模型本身也有风险，比如它对文档长度敏感，太长的文档可能被截断导致信息丢失；还有，如果业务文档有大量同质化内容，重排模型可能分不清谁更优。所以上线前我会特别关注：一是用一组历史query回放，对比加不加重排的Recall@K和生成答案的[[Faithfulness]]分数；二是根据延迟预算选模型，如果要求实时，就用Cross-Encoder的小模型，如果允许几秒延迟，甚至可以用LLM本身做重排，效果更好。

还有一个有意思的点，就是重排和[[Hybrid Search]]的关系。很多人以为有了重排就不需要混合检索了，其实不是。混合检索能补上向量检索在精确匹配上的短板，比如订单号、错误码这种，而重排是进一步优化排序。所以真正落地时，我倾向于把关键词检索、向量检索和重排串成一个三阶段流水线，每阶段承担不同角色。

所以整体来看，我不会把重排当成一个可选组件，而是RAG系统里从“能跑”到“跑得好”的关键一步。它的核心价值不是提高召回率，而是提高进入生成器的信息密度，让大模型少被噪声干扰，从而降低幻觉、提升答案准确率。