布吉岛 Agent

Appearance

7.3.1 Top K 召回后，最终应该送几个结果给模型？ ​

先给结论：没有一个对所有系统都成立的固定数字。最终送给模型的结果数，应该同时由问题复杂度、块大小、候选冗余度、模型上下文预算和后续提示词结构共同决定。

很多人一开始会问：

  • 是送 3 条最好，还是送 5 条、8 条、10 条最好

这个问题本身不算错，但如果只想找一个固定数字，通常会走偏。因为真正应该问的是：

  • 在当前问题和当前数据形态下，送多少条结果，既能保留足够证据，又不会让噪声压过关键信息

为什么这个问题不能只看一个数字 ​

同样都是“送 5 条”，效果可能完全不同，因为这 5 条背后可能对应的是：

  • 5 个很短、互不重复的关键块
  • 5 个很长、内容高度重叠的块
  • 5 个来自同一文档的相邻片段
  • 5 个来自不同文档、彼此冲突的候选

也就是说，真正影响效果的不是条数本身，而是：

  • 这些条目一共占了多少上下文
  • 这些条目之间有多少重复
  • 这些条目是否真的覆盖了回答问题所需证据

一个更稳的判断框架 ​

决定最终送几个结果给模型时，至少要同时看下面四件事。

1. 问题复杂度 ​

如果问题很简单，比如：

  • 一个术语是什么意思
  • 某个参数默认值是多少
  • 某一步操作的入口在哪

那么最终上下文通常不需要太大，过多候选反而会增加噪声。

但如果问题本身需要：

  • 多条件对比
  • 跨章节拼接
  • 从定义、限制、步骤中综合回答

那么送入模型的结果数通常就要更多，或者至少需要更完整的上下文块。

2. 单个块的大小 ​

如果你的 chunk 本身很短，比如每块只保留一个小段落，那么通常需要更多条结果才能拼出足够背景。

如果你的 chunk 已经比较大，单条里就包含完整局部语义，那么最终送入模型的条数通常应该更少。

这也是为什么“Top K=5 好不好”不能脱离切块策略讨论。

3. 候选冗余度 ​

候选之间如果高度重复，即使你送了很多条，模型真正获得的信息增量也很有限。

这时问题不在于“结果太少”，而在于：

  • 结果虽然多，但增量信息太少

所以在很多系统里，真正应该先做的是：

  • 去重
  • 聚合
  • 相邻块合并

而不是盲目把 K 再调大。

4. 最终 Prompt 结构 ​

有些系统会把候选原样拼到上下文里，有些系统会先做摘要、结构化整理、证据分组。

如果后续生成前还有一道压缩或结构化步骤，那么最终候选数可以稍大一点。

如果是直接把候选块原样塞进 Prompt，那么保留过多结果通常会很快把上下文弄乱。

一种常见但不稳的做法 ​

很多系统一开始会简单写成：

python
retrieved = retrieve(query, top_k=20)
final_context = retrieved[:5]

这当然可以作为最小起点，但它的问题是：

  • 20 和 5 往往只是拍脑袋定的
  • 没有考虑候选重复
  • 没有考虑块大小
  • 没有考虑问题类型差异

所以更稳的想法通常不是“固定保留前 5”，而是“先取一批候选，再按质量和预算筛到合适数量”。

一个更现实的最小思路 ​

python
candidates = retrieve(query, top_k=20)
candidates = deduplicate(candidates)
candidates = expand_neighbors_if_needed(candidates)
final_context = select_by_budget(candidates, max_chunks=6, max_tokens=2500)

这段代码想说明的是：

  • 最终送给模型的条数，应该是筛选后的结果
  • 决策依据不只是一行 top_k
  • 数量控制最好和 token 预算一起考虑

实际调的时候先看什么 ​

如果你想判断“最终结果送多了还是送少了”，可以优先看这些信号。

送少了的常见信号 ​

  • 回答经常缺半句背景
  • 模型抓到定义，但抓不到限制条件
  • 多条件问题里只回答了其中一部分
  • 正确证据分散在不同块里，但只送进去一小段

送多了的常见信号 ​

  • 回答开始变散
  • 模型引用了边缘相关块
  • 同一意思在上下文里重复很多次
  • 后排噪声把前排关键信息淹没

这类现象往往不是模型“能力不够”，而是最终上下文组织得不对。

一个实用原则 ​

如果你暂时还没有完善的自动策略，可以先遵守这个顺序：

  1. 先取比最终需要稍大一点的候选池
  2. 对候选去重和聚合
  3. 按问题类型决定是否做相邻块扩展
  4. 再按 token 预算和信息增量截断到最终数量

这样比“直接写死一个数字”更稳。

一个常见误区 ​

很多人会把“回答不完整”直接理解成：

  • 送给模型的结果不够多

但真实情况常常是：

  • 送进去的结果虽然多，却重复、发散、顺序混乱

这时继续加大 Top K，通常只会让上下文更乱。

一句话总结 ​

Top K 召回后，最终送给模型的结果数没有统一标准。真正该看的不是固定条数，而是问题复杂度、块大小、候选重复度、上下文预算和最终 Prompt 结构。对很多系统来说，关键不是“送更多”，而是“送得刚好、送得有增量、送得有顺序”。