上下文填充反模式：为什么更多的上下文反而会让 LLM 变差

当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。

这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。

“迷失在中间”问题是结构性的

可靠性瓶颈有一个证据充分的原因。关于语言模型如何实际使用长上下文的研究发现了一个一致的 U 型性能曲线：模型对上下文窗口开头和结尾的信息关注度最高，而对中间内容的注意力则会急剧下降。

这并非特定模型的 Bug —— 它反映了 Transformer 架构的工作原理。位置编码方案会对早期的 Token 产生“首因效应 (Primacy Bias)”，对后期的 Token 产生“近因效应 (Recency Bias)”。在 10 万 Token 的情况下，间隔 2 万到 8 万 Token 之间的注意力被稀释得如此严重，以至于模型在功能上忽略了大段的内容。多文档问答实验显示，当相关文档在 20 个文档的上下文中从第 1 位移至第 10 位时，准确率会下降 30% 以上。信息就在那里，但模型无法检索到它。

一项在 2025 年对 18 个前沿模型在不断增加的输入长度下进行的基准测试证实，随着上下文的增长，每一个模型都表现出了准确率的下降。不是大多数，而是全部。有些模型在达到某个阈值前保持稳定，然后猛然跌落。另一些则从一开始就逐渐下降。Claude Sonnet 表现出了最平缓的下降曲线，在整个 20 万 Token 范围内准确率下降保持在 5% 以下。大多数其他模型在达到其标称上下文窗口的 60-70% 时是可靠的，而不是 100%。

广告宣传的上下文窗口是容量限制，而非性能保证。

为什么直到为时已晚你才察觉到损害

这种故障模式非常隐蔽，因为它不会出现在你的评估集上。标准的评估测试模型是否能回答问题，却很少测试位置敏感性。如果你的评估集包含 50 个问题，且相关信息总是落在上下文的前 20% 或后 20%，那么你的评估得分会很高，而生产系统却在用户查询落入中间位置时悄悄失效。

在建立正确的指标之前，有一些行为信号表明上下文堆砌正在损害你的系统：

对冲性表述 (Hedging) 增加。 模型开始在原本应该给出确切回答的查询中添加限定词 —— “根据提供的信息”、“我不确定，但” ——。这通常是模型在进行模式匹配式的“不确定感”，而不是从杂乱的上下文中检索清晰的答案。

Token 膨胀但准确率没有提升。 一项研究对比了上下文堆砌系统与针对相同查询的精准检索方案。堆砌版本消耗了 3,729 个 Token。检索版本仅使用了 67 个 Token。答案完全一致。当增加更多上下文不再提升输出质量时，你已经超过了饱和点。

延迟上升。 一个 70B 参数模型在处理堆砌上下文与精简上下文时，延迟增加了 719%。如果你的首个 Token 时间 (TTFT) 随着用户会话变长而爬升，上下文增长极有可能是原因。

多 Agent 链中的子 Agent 混淆。 如果根 Agent 将其完整的 5 万 Token 对话历史传递给子 Agent，而该子 Agent 又对它的子级执行同样的操作，那么只需三跳，你就可能轻松达到 15 万 Token 的上下文 —— 而其中大部分内容与叶级任务无关。多 Agent 系统会呈指数级放大上下文膨胀。

正确的衡量框架应该追踪 Token 与回答比例 (Token-to-answer ratio，即单位回答质量所消耗的 Token 数) 以及上下文不同文档位置的准确率。大多数团队只在撞到天花板之后，才完成后者的一半工作。

具备预算意识的上下文策展究竟是什么样的

上下文堆砌的替代方案不仅仅是“减少上下文的使用”，而是像管理预算一样有意识地分配你的上下文窗口，并对每一个 Token 都有回报预期。

加载前的相关性过滤。 不要先检索再指望模型忽略不相关的片段。在发送前进行过滤。对用户的查询运行语义相似性匹配，并排除低于相关性阈值的文档。如果你在做 RAG，你的预检索步骤应该在任何内容到达模型之前，显著削减候选池。

加载中…