知识库给出一段流畅答案，人一查原文件，发现引用的是相邻产品或旧制度。模型常被先换掉，真正的偏差可能出在回答之前。检索系统拿回了十几段文字，却把最能回答问题的那一段放在后面，生成模型根本没有看到。
我对照了 Cohere 的 Rerank 文档和 Azure AI Search 的 semantic ranker 说明。两者都把重排放在第二阶段。关键词、向量或混合检索先从大量资料里找出一批候选，重排模型再把用户问题和每个候选一起看，重新给相关性排序。
第一轮负责找到，第二轮负责排好
拿售后知识库举例。员工问某型号电机在低温环境怎样保养，第一轮向量检索可能找回该型号说明书、同系列产品文档和一份通用保养规范。它们在字面和语义上都很接近。重排模型会比较完整问题与候选内容，让同时提到型号、温度条件和保养动作的段落往前走。
Cohere 的接口直接接收 query、documents 和要保留的 top_n，返回新顺序与相关性分数。它还能处理邮件、发票、JSON 和表格等半结构化材料。使用这些材料时，字段怎么拼进候选很重要。邮件主题、发件人和正文全挤成一段，可能让姓名盖过真正的业务内容。表格只留下数值，不带列名，模型也很难判断每个数字表示什么。
Azure 给出了更明确的边界。semantic ranker 接手的是 BM25 或 RRF 已排过的候选，当前只让前 50 个结果进入重排。第一轮若没找回正确文件，第二轮没有办法去整个资料库补找。分块切错、权限过滤过严或索引没更新，都会让正确答案在重排前消失。
输入长度也有限。Azure 会按标题、关键词和正文的优先级整理每份候选，内容过长时后面部分会被裁掉。一份合同把生效日期藏在附件末尾，重排收到的片段没有那一页，再高的相关性分数也帮不上忙。分块要保留标题、版本和相邻条款，关键字段还要放在模型能看到的位置。
分数只能服务于自己的测试集
Azure 提醒，重排分数会随基础设施条件和模型更新略有变化，阈值不要切得过细。更可靠的办法是收集真实问题，给每个问题标出应命中的文件与段落，然后分别算第一轮召回和重排后的前几名命中率。
检查时把失败分开。正确段落完全没进入候选，先修索引、分块或第一轮检索。正确段落已经在候选里，却排得太后，再调重排模型和字段组织。前几名材料都对，最终回答仍错，才去查提示词、引用约束和生成模型。这样每次改动都有明确对象，也能看见新增的延迟和费用换来了多少真实命中。