索引与重排的协同优化：先定瓶颈再动手

索引与重排的协同优化，指的是先判断瓶颈在取候选还是在排顺序，再决定动手的位置。这两段经常被同时调整，结果是收益无法归因 —— 变好了不知道是哪一步起作用，变差了也不知道该回退哪一步

两段各自的瓶颈表现

• 索引侧瓶颈：正确答案根本不在候选集里，表现为换了问法也答不出来。
• 重排侧瓶颈：正确答案在候选集里但没有进入前几名，表现为偶尔答对、结果不稳定。
• 两段都正常：此时问题多半出在上下文组装或生成环节，继续调检索收益有限。

索引侧先看哪几处

• 切分粒度：切得太碎会丢失上下文，切得太大则命中精度下降，需要按文档类型分别设定。
• 文本预处理：标题、表格、编号在进入索引前是否被正确处理，直接影响可比性。
• 候选数量：取得太少会在第一步就丢掉正确答案，之后无法补救。
• 元数据过滤：密级与时效过滤如果过紧，会把可用内容挡在候选集之外。

重排侧先看哪几处

• 重排依据：是否按当前问题的类型排序，例如编号类问题需要精确匹配优先。
• 候选规模：送进重排的候选太多会拉长延迟，太少则重排无从发挥。
• 同分处理：分数相同时的排序规则要稳定，否则同一问题两次得到不同答案。
• 延迟预算：重排通常明显增加耗时，需要事先约定可接受的上限。

组合调参的顺序

• 先固定候选数量，只调切分与预处理，把召回做稳。
• 再在稳定的召回上引入或调整重排，观察前几名的变化。
• 最后调组装环节，包括送入上下文的数量、顺序与来源标注。
• 每一步只动一个变量，并保留前后对照，否则改动效果无法判断。

什么时候不值得加重排

• 候选集很小且正确率已经稳定：加重排只是增加延迟，收益有限。
• 延迟预算很紧：交互式问答对首字响应敏感时，重排的代价可能超过收益。
• 瓶颈在召回：候选集里没有正确答案，重排无法凭空创造。
• 重排与业务语料不匹配：通用重排模型对企业内部术语的判断可能不如简单规则。

验收

• 分阶段指标可查：召回是否包含正确答案、正确答案的排名位置各有一条记录。
• 每次调整都注明动了哪一段，并有前后对照结果。
• 延迟变化有测量，而不是只在准确率上比较。
• 同一问题重复提问的结果稳定，不因排序随机性而漂移。

一次改动怎么验证

调检索最容易出现的问题是「感觉变好了」。可行的做法是把验证变成固定动作：同一批问题、同一套判定规则、改动前后各跑一次，并记录是哪一段发生了变化。

• 固定问题集：每次使用同一批问题，避免问题本身变化带来的干扰。
• 记录位置：不只记录答对与否，还要记录正确答案排在第几位。
• 记录延迟：准确率提升若伴随明显延迟上升，需要一并呈报。
• 注明变量：一份记录只对应一次改动，多个变量混在一起就失去意义。