第 7 章重排、排序与结果精选

先给结论：很多 RAG 系统答不好，不是因为完全没找到内容，而是因为找到之后没有把最值得使用的证据排到前面、整理干净、组织成适合模型理解的上下文。

前面几章已经把这些问题拆开讲过：

怎么切块
怎么设计 metadata
怎么做索引和更新
怎么做召回、过滤和路由

但到了真实系统里，你很快会发现另一个事实：

候选池里“有正确内容”并不等于模型最后就会答得稳

原因通常出在中间这一段：

初次召回拿到了候选
候选之间相关度并不完全等价
有些结果只是表面相似
有些结果虽然正确，但排得太后
有些结果彼此重复，白白占掉上下文预算
有些结果本来该合并、扩展或截断，却被直接原样送进了模型

所以这一章关注的核心不是“怎么把更多内容找出来”，而是：

找到之后，怎样把真正关键的证据更稳定地送进模型

这也是很多系统从“能跑 Demo”走向“回答稳定”时，必须补上的一层能力。

本章要解决什么问题

这一章主要回答四类问题：

为什么召回到了内容，模型还是可能答偏
为什么很多系统需要在召回之后再加一层 Rerank
为什么高分结果也要继续做去重、聚合和上下文整理
为什么最终排序和结果精选，本身就会影响生成质量

如果把第 5 章和第 6 章理解成“怎样把候选找进来”，那么这一章更像是在处理：

候选已经有了，怎样让模型更可能用对

学这一章时，最值得先建立的判断

召回问题和排序问题不是一回事，必须拆开定位
Rerank 解决的是候选优先级问题，不是替代初次召回
高分候选之间也可能高度重复，结果精选不只是简单截前几条
最终上下文的排列顺序、去重方式和合并策略，会直接影响模型回答质量

建议阅读顺序

主题模块

学完这一章后，你最好能更稳地判断

当前系统的问题更像出在“没召回”，还是“没排好”
什么时候值得引入 Reranker
最终送给模型的结果到底该保留多少、怎么去重、怎么扩展
回答不稳时，问题到底是检索层失效，还是结果组织层失效

关联章节

这一章承接第 6 章查询理解与检索链路设计。
学完后建议继续看第 8 章上下文构造与答案生成。