8.1.4 什么时候应该“少给”，而不是“多给”？

先给结论：当上下文里的重复、噪声、边缘相关内容已经开始压过核心证据时，继续多给材料通常不会提升效果，反而更应该做减法。对很多 RAG 系统来说，答案不稳不是因为“给少了”，而是因为“给杂了”。

很多人一看到回答不完整，第一反应就是：

• 再多塞一点材料

这有时确实有帮助，但更多时候要先分清：

• 当前问题到底是缺信息，还是信息已经太乱

如果后者成立，那么更好的方向不是“多给”，而是：

• 给得更准
• 给得更整洁
• 给得更有层次

一、哪些信号说明现在更该“少给”

下面这些现象，通常说明系统该先做减法。

1. 上下文里重复内容很多

比如：

• 同一规则出现了三四次
• 同一文档的相邻块大面积重叠
• FAQ 和正文在重复表达同一件事

这时继续加材料，带来的往往不是更多信息，而是更多重复。

2. 回答开始变散、变绕

如果模型本来能答得比较直接，但一加更多候选就开始：

• 背景铺垫过多
• 回答重点不突出
• 说了很多相关但不直接的内容

这通常说明上下文已经开始被边缘信息稀释。

3. 候选里正确证据其实已经在前面

如果正确证据本来就在前几条里，只是后面又塞了很多：

• 旧版本
• 相似背景
• 模板说明

那么“多给”只是在增加模型分心的机会。

4. 长上下文让冲突更明显

有些问题本来只需要几条直接证据，但一旦上下文拉得很长，就会混进：

• 一般规则与例外规则
• 新旧版本
• 不同场景下的不同口径

这时不是模型不聪明，而是：

• 你给了它太多需要临场裁决的材料

二、什么时候“多给”才是对的

当然，不是所有情况都该少给。

更应该多给的场景通常包括：

• 问题本身需要跨段综合
• 证据天然分散在多个块里
• 单个块信息量很小
• 当前失败模式明显是“证据不够”

关键不是“默认少给”或“默认多给”，而是要先判断：

• 当前系统的瓶颈，到底在证据不足，还是在证据过杂

三、一个更实用的判断方法

如果你怀疑现在该做减法，可以先问这四个问题：

1. 正确证据是不是本来已经在前排
2. 最终上下文里重复内容是不是很多
3. 回答变差时，新增候选是不是大多只是背景或边缘相关
4. 删除后排若干块后，回答是否反而更稳

如果这四条里有两到三条成立，通常就说明：

• 现在更应该少给，而不是多给

一个最小示意

candidates = rerank(query, retrieve(query, top_k=20))
candidates = deduplicate(candidates)

if context_is_getting_noisier(candidates):
    final_context = candidates[:4]
else:
    final_context = candidates[:8]

这段代码想说明的是：

• 最终上下文数量不该固定不变
• “给多少”应该受质量信号控制

四、少给不是粗暴删减，而是更精细地保留

这里也要避免一个误解：

• 少给，不等于盲目截短

真正有价值的“少给”通常包括：

• 去掉重复
• 去掉模板
• 去掉边缘相关块
• 保留直接证据
• 必要时补上最少量的相邻上下文

也就是说，少给不是偷懒，而是：

• 更认真地做筛选

一个常见误区

很多人会把“更多上下文窗口”理解成：

• 那就应该尽量把更多材料喂进去

这不够稳。窗口更大，只是代表你有能力放更多内容，不代表：

• 更多内容一定对当前问题有帮助

在真实系统里，更大的窗口如果被低质量材料填满，只会把问题放大。

一句话总结

当上下文里的重复、噪声和边缘相关内容已经开始压过核心证据时，就更应该少给，而不是多给。真正高质量的上下文构造，不是把能找到的都塞进去，而是把最值得模型使用的那部分材料保留下来。