2M Token 陷阱:为何“Context Stuffing”会削弱推理

发布: (2026年1月11日 GMT+8 22:56)
11 min read
原文: Dev.to

Source: Dev.to

为什么更多上下文常常让大型语言模型表现更差——以及该怎么做

1. Introduction

The Context‑Window Arms Race

The expansion of context windows has been staggering:

  • Early 2023 – GPT‑4 launches with 32 K tokens
  • Nov 2023 – GPT‑4 Turbo extends to 128 K
  • Mar 2024 – Claude 3 reaches 200 K
  • Feb 2024 – Gemini 1.5 hits 1 M (later 2 M)

In just two years, capacity grew from 32 K to 2 M tokens—a 62× increase.
The developer intuition was immediate and seemingly logical:

“If everything fits, just put everything in.”

The Paradox: More Context, Worse Results

Practitioners are discovering a counter‑intuitive pattern:

The more context you provide, the worse the model performs.

Typical symptoms:

  • Supplying an entire codebase → misunderstood design intent
  • Including exhaustive logs → critical errors overlooked
  • Providing comprehensive documentation → unfocused responses

This phenomenon appears in the research literature as “Lost in the Middle” (Liu et al., 2023). Information placed in the middle of long contexts is systematically neglected.

The uncomfortable truth is:

A context window is not just storage capacity; it is cognitive load.

This article explores why Context Stuffing fails, what Anthropic’s Claude Code reveals about effective context management, and how to shift from Prompt Engineering to Context Engineering—the discipline of architectural curation for AI systems.

2. 为什么“更多上下文”不等于“更好理解”

容量 vs. 能力

  • 容量 – 能在内存中容纳多少数据(例如,200 K、2 M 令牌)
  • 能力 – 对这些数据进行优先级排序、关联和推理的能力

一个能够摄取 2 M 令牌的模型并 不会 对所有令牌给予同等关注。
向 LLM 提供 2 M‑令牌的上下文,就像在第一天把 10 000 页文档交给一名新开发者,并期望他们在五分钟内修复一个 bug——他们会被淹没。

注意力稀释与“中间丢失”

限制来源于 自注意力机制。随着令牌数量增加,注意力分布趋于平坦,信噪比下降,相关信息被埋没。Liu et al.(2023)表明,在长上下文的中部信息会 系统性地被忽视,即使它们明确相关,而开头和结尾的内容则获得不成比例的关注。

上下文扩展增加了可访问的内容,而不是可理解的内容。

现实中的症状

  • 整个代码库 → 架构误解
  • 详尽日志 → 关键信号被埋藏
  • 完整文档 → 答案偏离主题

这些并非模型智能的失败,而是 信息结构和优先级 的失败——任何上下文容量的提升都无法解决这些问题。

3. 75 % 规则:Claude Code 的经验教训

问题 – 长时间会话中的质量下降

Claude Code 是 Anthropic 的基于终端的编码代理,拥有 200 K 的上下文窗口,表现出:

  • 长时间会话中代码质量下降
  • 忘记之前的设计决策
  • 自动压缩失败导致无限循环

当时,Claude Code 常规使用 > 90 % 的可用上下文。

解决方案 – 在 75 % 时自动压缩

2024 年 9 月,Anthropic 推出了一个逆向思维的修复:

当上下文使用率达到 75 % 时触发自动压缩。

结果:

  • 大约 150 K token 用于存储
  • 大约 50 K token 故意留空

看似浪费的空间实际上是实现 显著质量提升 的关键。

为什么有效 – 推理空间

假设:

  1. 上下文压缩 – 删除低相关信息
  2. 信息重构 – 摘要重新组织分散的数据
  3. 保留推理空间 – 空白区域促进生成

“这块空闲的上下文空间并没有浪费——它正是推理发生的地方。” – 开发者

这类似于计算机内存的行为:运行在 95 % RAM 并不意味着剩余的 5 % 处于闲置状态;它是系统开销。推到 100 % 时,一切都会卡住。

收获

  • 将上下文填满到极限会降低输出质量。
  • 有效的上下文管理需要 预留余量——为推理预留空间,而不仅仅是检索。

Source:

4. 上下文工程的三大原则

提示词微调的时代即将结束。正如 Hamel Husain 所言:

“AI 工程就是上下文工程。”

关键技能不再是 对模型说什么,而是 在模型面前放什么——以及有意识地 留出什么

原则 1:隔离

不要一次性倾倒整个单体。
借鉴领域驱动设计中的 有界上下文(Bounded Contexts)。为任务提供最小且有效的上下文。

示例 – 添加 OAuth2 认证

必需的非必需的
User modelBilling module
SessionControllerCSS styles
routes.rbUnrelated APIs
Relevant auth middlewareOther test fixtures

提问: 解决此问题所需的最小上下文是什么?

原则 2:链式

传递制品,而非历史记录。
将工作流拆分为多个阶段:

  1. 计划 → 生成简洁的计划(几百个 token)
  2. 执行 → 仅使用第 1 步产生的制品来执行计划
  3. 反思 → 总结结果,并将提炼后的视图反馈到下一轮迭代

每个阶段只接收 前一阶段的输出,而不是完整的对话历史。

原则 3:预留

为模型留出思考空间。

  • 在上下文窗口中预留约 25 % 作为“思考空间”。
  • 将此空间用于 草稿推理、中间计算或即时摘要。

当模型的头部空间耗尽时,它必须截断或压缩,这往往会导致关键推理步骤的丢失。

5. 综合运用

  1. 审计 当前提示:识别单块式的冗余输出。
  2. 划分 问题为有界上下文。
  3. 链式 工作流,仅向前传递必要的产物。
  4. 预留 大约 25 % 的上下文窗口用于推理。
  5. 迭代:每个循环后,在下一轮之前压缩上下文(总结、裁剪)。

通过将上下文视为 设计资源 而非免费存储箱,你会看到:

  • 更高的设计意图忠实度
  • 更快收敛到正确的解决方案
  • 更可预测、易维护的 AI‑辅助工作流

TL;DR

  • 更大的上下文窗口 ≠ 更好的理解。
  • “中间丢失”表明对中间 token 的注意力会下降。
  • Claude Code 的 75 % 自动压缩规则证明 余量很重要
  • 采用 隔离、链式和预留 来构建有效的上下文。

祝上下文工程愉快! 🚀

原则 3:余量

永不让模型以 100 % 容量运行。
采用 75 % 规则

令牌限制通常包括 输入 + 输出。把 195 K 令牌塞进 200 K 窗口几乎没有留下推理的空间。

思考:

  • 是否可以将其分解为多个阶段,传递摘要而非完整记录?
  • 我是否为模型留下了足够的思考空间——而不仅仅是回应?

将上下文窗口视为稀缺的认知资源,而非无限存储。

5. 为什么 200 K 是最佳点

认知规模

150 K tokens(≈ 200 K 的 75 %)大致相当于一本技术书——这是人类和大型语言模型(LLMs)能够管理的最大连贯“项目状态”。超出此范围,需要章节、摘要和架构。

成本与延迟

注意力的计算复杂度为 O(n²)
上下文长度翻倍,成本会增加四倍。
200 K 在性能、延迟和成本之间取得平衡。

方法论纪律

200 K 强制进行策划
超过它是代码异味:边界不清、任务过大,或是填塞而非结构化。

Anthropic 提供 1 M tokens——但仅在高级套餐中。
隐含的信息:1 M 只用于特殊情况。200 K 是默认设置是有原因的。

约束不是限制——它就是设计原则。

6. 结论:从提示工程到上下文工程

上下文窗口的竞争带来了 62 倍的容量提升,但容量从来不是瓶颈。
瓶颈是——而且一直是——策展

提示工程上下文工程
“我该如何表述?”“模型应该看到什么?”
优化用词构建信息
单轮提示多阶段流水线
填满容量保留余量

在每个任务之前要问的三个问题

  1. 我是不是仅仅因为能放就把上下文塞进去?
    相关性胜过穷尽。

  2. 这些上下文是否仅限于真实问题?
    如果你无法界定边界,就说明你还没找到它。

  3. 我是否为模型留出了思考空间?
    输出质量需要输入的约束。

提示工程时代奖励的是巧妙的措辞。
上下文工程时代奖励的是架构判断

问题不再是:我该对模型说什么?
问题是:模型应该看到什么样的世界?

7. 参考文献

研究论文

  • Liu et al., Lost in the Middle: How Language Models Use Long Contexts (2023)

工具与方法论

  • planstack.ai

实证研究

  • Greg Kamradt, Needle in a Haystack

文章与分析

  • (根据需要添加条目)
Back to Blog

相关文章

阅读更多 »