检索环节召回了一组候选片段后，下一个关键步骤是对这些片段进行排序，确保真正与问题最相关的内容排在最前面，进入后续的生成阶段。因为大语言模型的上下文窗口有限（即使窗口越来越长，输入质量仍然直接影响回答准确性），把最相关的片段放在生成模型视线的最前端至关重要。排序环节相当于给检索结果做一次“精筛”，直接决定了模型看到的“参考资料”的质量。
1. 为什么需要二次排序
初检（如向量相似度搜索、BM25 关键词匹配）追求的是高召回，即尽量不漏掉相关文档。但这种宽泛的召回也容易混入“看起来相关但其实没用”的片段，比如：
- 含有关键词但表达的是相反意思的段落；
- 同一文档内与问题无关但碰巧包含相似词汇的片段；
- 过长文档中分散的、关联度一般的段落。
二次排序（重排序，re‑ranking）利用更精细、计算成本更高的模型，对初检结果重新打分和排序，把真正有信息量的片段推到结果的顶部。这样，模型在生成时看到的就是精华中的精华。
2. 常见的排序策略
实践中，排序通常采用分层递进的方式：粗筛 → 精排。
- 向量相似度 / BM25 粗排：
负责从海量文档中快速召回几十到几百个候选片段。速度快但准确性相对粗放，侧重于不放过任何相关材料。
- 重排序模型精排：
对粗排返回的 top‑K 片段（如 50～100 个）进行重新打分。常用方法是交叉编码器（cross‑encoder），它同时对问题和每个候选片段进行深度语义交互打分，能精准判断片段对回答问题的有用性。由于交叉编码器计算量较大，只在小范围候选集上使用，效率和效果得以兼顾。
- 元数据加权排序：
在特定场景中，还可以结合文档的元数据进行加权。例如：更近发布的文档、来自较高级别权威来源（如制度 vs. 讨论稿）的片段、更匹配用户角色（如员工 vs. 经理）的内容，获得额外权重。这类规则可以穿插在精排之前或之后，贴合业务逻辑。
3. 一个实用的例子
某企业内部知识助手的检索流程如下：
- 用户提问：“出差住宿费用报销的标准是多少？”
- 粗排阶段，向量检索和 BM25 召回 80 个候选片段，覆盖了《费用报销制度》《出差管理办法》、部分会议纪要以及一些项目报告。
- 精排阶段，交叉编码器模型对每个候选片段打分。高分的片段直接回答了住宿标准（“一线城市 500 元/天，其他城市 350 元/天”），而会议纪要中虽然也提到“住宿费用”，但只是零散评论，排名被压下。
- 业务规则补充，优先采用标注为“现行有效”的《费用报销制度 v4.2》片段，确保不会用到已作废版本。
- 最终，最相关的 3 个片段送入 LLM 生成回答：“一线城市出差住宿标准为 500 元/天，其他城市 350 元/天，具体见《费用报销制度》第 3.2 条。”
4. 实际落地注意事项
- 初检阶段尽量保召回：宁可多召回一些，给精排充分的候选池，精排有能力滤掉噪声。
- 精排模型选型要务实：许多开源交叉编码器（如 bge‑reranker、Cohere Rerank）在领域内已有很好的泛化效果，不需要从头训练。如果业务高度垂直，可以用少量标注数据进行微调，快速提升特定领域相关性判断。
- 监控并反馈：记录哪些片段最终被模型引用、用户点击“查看原文”的频率，以及有无“答非所问”的投诉。这些信号可以用来评估重排序效果，甚至作为训练数据迭代排序模型。
- 成本控制：重排序调用模型有计算开销，设置合理的初检返回数量（如 50～100 个）可以平衡精度与延迟。
通过精心设计检索片段排序流程，RAG 系统能有效将“用户问题 → 最相关原文片段”的匹配精度大幅提升，让最终生成的回答既有扎实的事实支撑，又能节省生成模型的上下文窗口，兼顾成本与效果。