正在加载文章，请稍候…
调大 Top-K 后召回率提高了，用户却觉得答案更差，为什么？
内容提要
拆解 Top-K 从 5 增至 20 后的噪声、版本冲突、上下文干扰与延迟问题，区分候选召回量与最终证据量，并给出重排、版本治理、Token 预算及端到端实验方案。
题目与场景
问题：调大 Top-K 后召回率提高了，用户却觉得答案更差，为什么？场景：Top-K 从 5 调到 20，离线检索指标提升，但回答开始混杂多个版本，还明显变慢。
可以直接口述的面试答案
我会先区分调大的是候选召回数量，还是最终喂给模型的片段数。前者可以提高找到答案的机会，后者可能把噪声、重复内容和新旧版本一起带进上下文。Recall 提高只说明相关资料更可能被找到，不保证模型拿到的是当前适用、足够完整又没有冲突的证据。我的做法是允许候选集适当扩大，再按权限、适用范围、有效版本过滤，重排并去重，在 Token 预算内保留关键规则和例外。通过固定模型和数据的对照实验，分别看候选召回、最终证据质量、答案正确率、冲突率和分阶段延迟，选择满足质量与响应目标的参数。
一、先问清楚：Top-K 是哪一层的 K
| 参数 | 控制什么 | 调大后的潜在代价 |
|---|---|---|
| K_candidate：候选召回数 | 检索或融合阶段保留多少候选，供后续筛选 | 返回、重排和处理成本增加；不一定增加生成上下文 |
| K_context：最终证据数 | 筛选后向模型提供多少段资料 | 噪声、重复、版本混杂、输入 Token 与上下文干扰可能增加 |
| B_context：上下文 Token 预算 | 最终证据允许占多少输入空间 | 如果只限制段数，少数超长片段也可能占满预算 |
若只是候选从 5 增至 20，最终仍送入同样的 5 段，答案变差也可能来自重排不稳定、去重错误或版本选择变化，需要对比最终上下文，不能直接断言是“20 段太长”。若 20 段全部直接送入模型，版本污染与输入膨胀则是重点排查对象。
二、为什么离线指标变好，端到端体验会变差
在相关性标注和同一排序前缀固定的条件下，Recall@K = 前 K 项中命中的相关项数／全部标注相关项数，K 增大时不会下降。但 Precision@K = 前 K 项中命中的相关项数／K，可能降低。示意：若共有 4 个相关块，前 5 项命中 3 个，前 20 项命中 4 个，则 Recall 从 75% 到 100%，Precision 从 60% 到 20%。这只是解释指标的算例，不是本场景的实测结果。若调整 K 还改变了 ANN 搜索或融合流程，结果未必保持同一前缀，实际变化需测量。
- 旧制度、新制度和其他地区制度可能都与“补贴上限”语义相关。若离线标签没有编码时间、地区、员工类别和规则版本，过期片段也可能被算作有效命中。
- 上下文同时出现 500 元和 800 元，却没有清晰的适用范围与替代关系，模型可能挑错、同时输出，或编出原文没有的解释。
- 多个近重复块反复讲一般规则，排除条件、脚注和定义被挤出预算。片段更多，规则反而更不完整。
- 输入可容纳，不代表其中的每条证据都会被同等利用；这需要在当前模型、片段排序和任务上单独评测。
- 更多候选可能增加检索返回、网络传输和重排成本；更多最终证据通常增加输入处理与首 Token 等待，也可能引出更长答案。
Lost in the Middle 研究在其测试任务和模型中观察到：关键证据的位置会影响表现，长上下文中部的证据可能更难利用。这是设计位置扰动测试的依据，不能据此认定所有当前模型、所有查询都会按同一规律退化。
研究依据：Lost in the Middle — How Language Models Use Long Contexts
三、改成充分召回，再精选完整证据
- 按权限和已知的组织、地区、业务时间限制候选。制度状态和适用规则应由治理元数据支撑，不能把上传时间直接当生效时间。未知条件会影响结论时，向用户澄清或按条件分别回答。
- 候选可从 20、40 等实验值起步，最终证据可从 4～8 段起步，并设置 Token 上限。这些数字只是起点，要由本业务评测确定，不能当作通用最优值。
- 重排器比较候选与问题的匹配程度；制度是否有效、是否适用于该员工，仍需显式规则约束。语义高分不能覆盖已知的失效状态。
- 移除同一内容的重复块；按制度族和条款识别版本，同时保留适用的补充细则、例外与附件。不能简单每份文档只留一个块，也不能把冲突内容当重复删除。
- 根据问题保留资格、金额、例外和有效期等必要要素，附带来源、版本、条款 ID。需要时按父子关系补全条款；压缩后核对否定和数字，避免因精简丢掉限制。
- 简单事实查询可用较少证据；跨条款判断应补足关联材料。若预算用尽仍不足，允许有界补检或说明缺口，不强行给出完整结论。
可采用的处理顺序是：确定问题及已知适用条件 → 受控候选召回 → 有效性与范围筛选 → 重排 → 去重和关联条款扩展 → 在预算内组装证据 → 生成并核验。筛选与扩展可迭代，但最终送入模型前必须重新检查版本、权限和规则完整性。
四、用对照实验区分“候选更多”和“上下文更多”
| 实验组 | 设置示例 | 要回答的问题 |
|---|---|---|
| A：基线 | 候选 5，最多 5 段，固定预算 | 原系统的质量与时延是多少 |
| B：只扩候选 | 候选 20，最多 5 段，其余保持 A 一致 | 更多候选经过原筛选后是否改善结果 |
| C：扩最终上下文 | 候选 20，最多 20 段，记录实际 Token | 增加最终证据的增益与污染有多大 |
| D：候选 20＋治理 | 候选 20，版本/范围治理、重排去重，最多 5 段 | 精选证据方案能否提升端到端表现 |
实验固定查询集、语料快照、模型与提示词版本、输出长度策略和并发条件，并记录实际送入的证据及 Token。D 是组合方案；若要归因到具体措施，再分别关闭版本筛选、去重或重排做消融。测试集应包含旧新版本并存、长文档、例外条款、无答案和复杂问题，不能只测容易命中的问题。
检索侧测候选 Recall@K、最终证据 Precision、必要条款覆盖与版本适用性；答案侧测正确率、证据忠实性、引用支持率和版本混用率。Ragas 对不同质量维度的拆分可作评测设计参考，具体业务结论仍需人工标准答案校准。
评测参考：Ragas — Automated Evaluation of Retrieval Augmented Generation
性能侧分别记录检索、重排、上下文组装、首 Token 延迟、完整响应时间、输入/输出 Token 与单次成本，并看 P50/P95。如果最终证据数量不变而仍明显变慢，重点检查候选处理与重排；不能把全部时延都归因于生成。缓存也要按权限、语料版本和适用时间隔离，制度更新后失效。
面试追问：到底该不该调大 Top-K
可以扩大候选召回来减少漏检，但是否扩大最终上下文，需要端到端实验支持。优化目标是足够正确且完整的证据、可靠的答案和可接受的延迟，而不是单独把 Recall@K 做高。