加了重排模型，RAG为什么还是找不到那份答案？

给RAG接上重排模型，答案却没有变好。第一反应往往是：“是不是reranker不够强？”

先别急着换模型。打开它实际收到的候选列表：那份真正写着答案的说明书，可能根本没有进来。

重排负责把已找到的材料排得更合适，不负责把没找到的材料变出来。 本文回答一个具体问题：什么时候该加重排，什么时候该先修召回，以及怎样避免“排名变了、引用却串了”的接线错误。

AI原创概念插画：紫绒托盘里的珐琅甲虫与后景抽屉中的红甲虫，比喻候选集合内的选择与集合外的遗漏。画面是艺术化静物，不是昆虫解剖图、真实搜索界面或算法执行证据。

两次筛选，承担两种工作Copy Anchor Link

RAG是先找资料、再让模型基于资料回答的一类方法。资料库很大时，常见做法不是让一个模型逐篇精读全库，而是分两步：

1. **初步检索：**用关键词、向量或其他检索方法，快速取得一批可能有用的候选。
2. **重排：**把问题与候选交给另一个打分过程，重新比较相关程度，再保留其中一部分。

Sentence Transformers的Retrieve & Re-Rank文档给出这种两阶段安排，并以bi-encoder检索、CrossEncoder重排说明机制。[1] bi-encoder分别编码问题和文档，文档向量通常可以提前建立；典型的cross-encoder则把问题与一份候选一起输入，让两边的信息在模型内部共同参与计算。

直观地说，第一阶段适合快速找“可能值得读的页”，第二阶段更仔细地看“这页是否切中这个问题”。后者需要在查询时对候选进行额外计算，所以不能只算排序收益，不算延迟与成本。

这里说的是一种常见架构，不是“所有reranker必然是同一种cross-encoder”。重排也可以采用其他模型与方法；某个模型在公开任务上更好，也不保证它在你的中文手册、缩写或行业规则上一定更好。

跟一遍案例：离线浏览，不等于离线扫描Copy Anchor Link

以下资料与产品均为虚构，候选顺序和期望顺序由人工指定，没有调用检索模型或远端API。

用户问：

资料扫描器断网时能继续扫描吗？恢复联网后会自动补传吗？

知识库里有三份说明：

情况一：候选只有A和CCopy Anchor Link

不管把A排在C前面，还是把C排在A前面，B都不会因此出现在候选里。即便重排器完美识别了这两份资料的局限，它也只能把“不足以回答的资料”排一个顺序。

这时要检查的是：B有没有正确入库？对应内容是否可被检索？用户问题中的“断网”“暂存”“补传”与索引用语是否接得上？初检范围、过滤条件或候选截断有没有把它挡在外面？

Pinecone的SDK文档对此说得很直接：重排只能重排第一阶段已经找到的内容。[2] 如果系统在识别缺口后主动再次搜索，那是额外的检索步骤，不是重排本身补出了文档。

情况二：候选里有B，却排在后面Copy Anchor Link

假设初检顺序为A、C、B，而交给回答阶段的预算只够保留前两份。此时重排有机会把B提升到可见位置，帮助系统在较小的阅读预算内保住关键资料。

“有机会”很重要。B是否真的上升，取决于所用模型、输入字段、文本完整性与问题分布；这里展示的是重排可以解决的问题类型，不是一次模型效果报告。

保留B后，回答还应注意账号与队列条件，不能只抽出“自动补传”四个字。相关性排序解决选材，可回答性与条件核对解决能说什么，二者不能互相代替。

分开设置两个预算，不要只留一个top-kCopy Anchor Link

本文把初检候选数量记为K，把重排后保留数量记为N。这只是便于解释的记号；具体接口可能使用top_k、top_n或其他字段名。

• K决定重排器有多大的选择空间。
• N决定后续阅读拿到多少份材料。
• 最终送入回答模型的token预算，还取决于每份材料有多长，以及是否去重、扩展或裁切。

这三个量不是一回事。只把N变小，通常不会减少已提交给重排阶段的候选集合；只把K变大，也不保证新增候选能进入最终上下文。

一个合理的调试顺序是：先固定问题集，检查需要的证据能否进入候选；再固定候选，比较原始排序与重排后的证据保留情况；最后看完整回答与延迟。这样才知道收益或损失发生在哪一层。

别直接照抄教程里的候选数量。语料规模、文档长度、语言和服务预算不同，适合的取舍也不同。若原始排序已经足够好，新增一次重排的成本可能不值得；若只需在一小段已知文本中搜索，甚至未必需要先做全库检索。[1]

最容易被忽略的接线错误：返回第一项，不是原文第一份Copy Anchor Link

重排改变了顺序，返回结果里的位置就不能直接当成原候选位置。

Cohere的v2接口参考将index定义为结果对应的原始文档列表索引；Pinecone的SDK文档也专门提醒，忽略这个索引会把分数与文档配错。[2][3] 这是两份具体接口文档的语义，不表示所有服务都使用同名字段。

沿用本例，原候选顺序为A、C、B。如果人为指定的重排索引是[2, 0]，应取出B、A，而不是拿返回位置[0, 1]去取A、C。

下面这段是已在本地执行的纯Python索引教学代码。ranked_indices由人工填写，既不是模型预测，也不是伪造API响应：

candidates = ["A", "C", "B"]
ranked_indices = [2, 0]  # 人工指定的排序夹具

wrong = [candidates[pos] for pos, _ in enumerate(ranked_indices)]
correct = [candidates[index] for index in ranked_indices]

print(wrong)
print(correct)

实际输出：

['A', 'C']
['B', 'A']

这说明的是适配层索引错误，不是重排质量。哪怕排序模型判断正确，接线错误也能把正确结果换回错误材料，甚至让引用ID指向另一篇文档。

工程上应保留稳定文档ID及原候选顺序，按当前接口契约映射返回值，并检查索引范围、重复项与缺失项。如果做了分批重排，批内索引还需先映射回对应批次的原候选，不能把每一批的零号都当成全局零号。

传给重排器的，未必是你以为的全文Copy Anchor Link

候选ID正确，也不说明排序模型读到了关键句。

若B的“自动补传”在文档后部，而传入的只是标题、摘要或被截断的前半段，重排器无法依据未见文字判断它的价值。Cohere当前v2参考页明确说明，长文档会按max_tokens_per_doc限制截断。[3] 这是该接口的具体约束，不应扩写成所有重排服务都采用相同截断方法；其他模型和接口可能分块或有不同处理。

所以排查时，要保存或可重建实际参与打分的文本、字段、顺序与版本，而不是只记录“用了B”。检查问题包括：标题和正文有没有传错？关键例外是否在裁切之外？表格是不是只剩数值而没有列名？

同样，相关性分数不应直接改名为“答案正确率”。Cohere参考页明确提醒，不能把两个相关性分数当成相关程度的简单倍数。[3] 不同模型的分数含义和尺度也不必相同。若要设门槛，应按实际模型、语料和风险验证，不要给所有查询统一套一个未经校准的数值。

把验收拆成三个问题Copy Anchor Link

重排上线后，别只展示“第一名分数提高了”。至少分别问：

1. **候选覆盖：**标注需要的证据有没有进入初检候选？如果没进来，排序阶段无从挽救。
2. **保留质量：**在相同阅读预算下，重排是否把更有用的证据留了下来？是否被重复片段挤满？
3. **端到端结果：**最终回答是否更准确、条件更完整，同时延迟与成本是否可接受？

这三项是本文的工程验收建议，不是三个厂商共同规定的标准。候选覆盖好，不代表排序好；排序好，也不代表生成阶段一定忠实于资料。多个子问题还可能需要互补证据，不能只盯着单篇第一名。

建议的对照包含：相似措辞但答非所问的资料、关键证据排在后面、证据根本缺席、长文末尾才出现条件，以及重复片段占满候选。这些是待在真实系统验证的测试设计，本轮没有执行模型评测，也没有报告准确率或性能提升。

接入检查清单Copy Anchor Link

• 已区分“没召回”“排低了”“映射错了”和“读到后答错了”。
• 初检候选预算、重排保留预算与最终token预算分别设置。
• 排序前后都能回查稳定文档ID、版本及原始候选顺序。
• 返回索引按原请求列表映射；分批时不混淆批内与全局位置。
• 核实实际打分字段与文本截断，关键条件确实在输入内。
• 权限与有效版本在进入外部重排服务前已经检查；重排本身不授予读取许可。
• 与不重排的基线在同一问题集、同一最终阅读预算下比较。
• 同时检查证据覆盖、最终回答、延迟和成本，不用分数上涨替代业务收益。
• 重排服务失败时采用明确的降级或停止策略，不把原始顺序谎称为重排结果。

给一盘已经取出的标本重新安排位置，可以让重点更清楚。但想找到仍在抽屉里的那一只，必须先回到检索这一步。

来源、日期与阅读范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理。扫描器及规则为虚构案例；索引代码与完整断言脚本已实际本地执行，仅验证列表映射及候选集合的排列边界，没有调用LLM、嵌入模型、重排模型或付费服务。资料检索截止：2026年10月21日14:38 UTC。

1. Sentence Transformers：Retrieve & Re-Rank。动态文档，未标独立发布日期或固定软件版本。本轮获取公开HTML，实际读取两阶段管线、bi-encoder、cross-encoder与小文档集合可直接打分的相关正文；仅据其说明机制，不采用示例数量作为调参标准，也不推广其中示例分数范围为通用契约。
2. Pinecone Python SDK：Reranking results。动态SDK文档，未确定页面原始发布日期或锁定安装版本。本轮获取公开HTML，实际读取概览、原始索引映射、保留数量及管线边界章节；采用“只重排既有候选”和映射语义，不引用页面中的模型可用性或示例得分作为本轮事实测试。
3. Cohere：Rerank API v2，并核对其官方Markdown正文。动态接口参考，v2为API版本，未标固定发布日期。本轮实际读取请求参数、长文截断、返回索引及相关性分数说明；不把网页提取与直接正文中不同的示例模型名包装成新产品公告，不依赖其默认模型选择，不声称调用过服务。