Rerank 为什么重要

Rerank 解决的是把召回出来的候选片段重新排序的问题。它不是替代召回，而是把最相关的片段排到前面。

在 Way To Agent 的知识体系里，这篇文章关注的是 Rerank 在 RAG 中的作用、与向量召回的关系，以及如何记录和使用 rerank_score。

Rerank 在补什么

Rerank 不是在补所有检索问题，它只补一种缺陷：召回已经把“可能相关”的片段捞上来了，但前排顺序不够好。

典型场景是：

• 向量召回能找到语义相近的内容，但最重要的片段没排在最前面。
• 候选里混入了主题相近但不直接回答问题的内容。
• topK 必须收得更紧，否则上下文预算会被低质量片段占满。

如果问题是根本没召回到正确片段，Rerank 帮不了你；那通常是解析、切片、embedding 或过滤条件的问题。

它放在链路哪里

Rerank 的工作方式是先召回一批候选，再用更精细的打分模型重新排序。

用户输入
  -> 业务上下文与权限判断
  -> 数据、检索、Prompt 或工具编排
  -> 模型调用或确定性服务执行
  -> 结构化校验、引用、日志和反馈

Rerank 的价值不是把召回“变魔法”，而是把有限上下文预算留给更值得放进去的片段。

哪些地方要记录 rerank_score

如果系统已经上了 Rerank，却不记录 rerank_score 和重排前后的候选顺序，后面几乎没法判断它到底有没有价值。

至少要能看到：

问题文本
召回前 topK
召回分数
重排后 topK
rerank_score
最终进入 Prompt 的片段

这些记录的价值有两个：

• 判断 Rerank 是真的提升了前排质量，还是只是“看起来更复杂”
• 区分问题到底出在召回阶段，还是出在重排阶段

什么时候值得上 Rerank

不是每个 RAG 系统都应该默认上 Rerank。

更适合上的情况：

• 候选片段很多，topK 必须压缩
• 召回“基本能找到”，但前排顺序经常不对
• 问题表达和原文表述差异大，单纯相似度排序不够稳

不急着上的情况：

• 文档量还很小，topK 很低也够用
• 召回阶段本身经常漏掉关键片段
• 成本和时延预算很紧

Rerank 应该建立在“召回已经大致可用”的前提上，不应该用来掩盖前面链路的基础问题。

最常见的误解

• 上了 Rerank，召回问题就基本解决了。
• rerank_score 不重要，只看最终答案即可。
• 任何场景都该默认加一层 Rerank。
• Rerank 效果不好，一定是模型太弱。

怎么排查

当 Rerank 相关功能表现不稳定时，不要先猜模型不好。更有效的排查顺序是：

输入是否明确
上下文是否正确
权限与数据范围是否匹配
Prompt / 工具 / 检索配置是否符合预期
模型调用是否超时、限流或输出不合规
日志、引用和评估样例是否能复现问题

排查 Rerank 时，最重要的是先问一句：它是在补排序问题，还是被拿来替召回背锅。

一句话结论

Rerank 为什么重要的核心不是记住一个名词，而是理解它在 AI 应用链路中的责任边界。Rerank 的作用是改善上下文质量，而不是弥补错误解析或缺失文档。

上手前先画清楚

1. 标出召回前 topK、重排后 topK 和最终进 Prompt 的片段。
2. 记录 rerank_score 以及重排前后的顺序变化。
3. 单独判断 Rerank 在补排序问题，还是在掩盖召回问题。

继续阅读

04-rag/001-what-is-rag.md
04-rag/002-rag-architecture.md
04-rag/003-document-parsing.md