重排序的好处是什么
上一篇讲了混合检索，通过向量+关键词两条路并行召回，再用RRF融合，大幅提升了召回率。但有个问题还没解决：召回的文档排序准吗？
打个比方，你是技术主管，要招一个"精通Redis且有分布式系统经验"的后端开发。HR帮你从简历库里筛了20份相关简历过来（这是召回）。但这20份简历摞在一起，哪个候选人最匹配你的要求？HR只是按关键词命中了"Redis"或"分布式"就捞出来的，并没有帮你按"和岗位需求的匹配度"排好序。
重排序就是干这个事的：对召回的候选集做一次精细化的相关性打分，把最匹配的排到最前面。
为什么这很重要？因为大模型的上下文窗口是有限的，你不可能把20个文档块全塞进去。通常只取前3-5个。如果排序不准，真正相关的文档排在第8位，而前5个都是"沾点边但不太对"的内容，最终生成的回答质量就会打折扣。
初始检索为什么排不准
不管是向量检索还是BM25，它们在做排序时都有一个共同的局限：查询和文档是分开编码的。
向量检索的工作方式是：先把查询编码成一个向量，再把每个文档编码成一个向量，然后比较两个向量的距离。这种方式叫Bi-Encoder（双编码器）。
Bi-Encoder的工作方式：
查询 → [编码器A] → 查询向量 ─┐
├→ 计算距离 → 相似度分数
文档 → [编码器B] → 文档向量 ─┘
Bi-Encoder的优势是快——文档向量可以提前算好存起来，查询时只需要算一次查询向量，然后做向量距离计算。百万级文档也能在毫秒级返回结果。
但它的劣势也很明显：查询和文档是独立编码的，编码器看不到两者之间的交互关系。
举个例子，查询是"Spring Boot如何配置多数据源"，候选文档有两个：
- 文档A："Spring Boot多数据源配置需要自定义DataSource Bean……"
- 文档B："Spring Boot配置文件支持多种格式，包括yml和properties……"
两个文档都包含"Spring Boot"和"配置"这些关键词，向量距离可能很接近。但人一看就知道文档A才是真正相关的。Bi-Encoder因为没有让查询和文档"面对面交流"，很难捕捉到这种细粒度的差异。
付费内容提示
该文档的全部内容仅对「JavaUp项目实战&技术讲解」知识星球用户开放
加入星球后，你可以获得：
- 超级八股文：100万+字的全栈技术知识库，涵盖技术核心、数据库、中间件、分布式等深度剖析的讲解
- 讲解文档：超级AI智能体、黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的从0到1的详细文档
- 讲解视频：超级AI智能体、黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的核心业务详细讲解
- 1 对 1 解答：可以对我进行1对1的问题提问，而不仅仅只限于项目
- 针对性服务：有没理解的地方，文档或者视频还没有讲到可以提出，本人会补充
- 面试与简历指导：提供面试回答技巧，项目怎样写才能在简历中具有独特的亮点
- 中间件环境：对于项目中需要使用的中间件，可直接替换成我提供的云环境
- 面试后复盘：小伙伴去面试后，如果哪里被面试官问住了，可以再找我解答
- 远程的解决：如果在启动项目遇到问题，本人可以帮你远程解决
进入星球后，即可享受上述所有服务，保证不会再有其他隐藏费用。
