跳转到主要内容

上下文窗口不是免费存储:显式驱逐策略的必要性

阅读需 2 分钟Tian PanTian Pan

大多数工程团队对待 LLM 上下文窗口的方式,就像早期 Web 开发者对待全局变量:先塞进去,问题以后再说。上下文里堆满了最近 40 轮对话、仓库里的三个完整文件、十几份检索到的文档,以及一个经过六个月集体修改、越来越臃肿的系统提示词。一切看起来都能运行——直到某天突然不行了,而那时已经很难判断究竟是哪里出了问题。

上下文窗口不是堆内存。它更接近于 CPU 寄存器文件:容量有限、单位成本高昂,且其内容直接影响模型执行的每一次计算。当你把寄存器当成草稿纸随意使用而忘记管理时,程序会以各种匪夷所思的方式崩溃。当你把上下文窗口当成草稿纸时,LLM 会以悄无声息且代价高昂的方式退化。

为何"塞满一切"的直觉看似正确

上下文填充背后的直觉乍看合理:信息越多,答案越好;模型看不到的内容就无法利用;检索有延迟,不如把所有东西都留在上下文里。当上下文窗口还只有 4K Token、稀缺性强制约束行为时,这些论点有一定道理。随着窗口扩展到 128K、200K 乃至更大,稀缺压力消失了——约束意识也随之消失了。

取而代之的是另一种直觉:越大越安全。200K Token 的窗口可以容纳整个代码库,为什么不用呢?模型自己会判断什么内容相关。

然而事实并非如此,而且后果会以大多数团队从未度量过的三种方式复合叠加。

成本是二次方增长,而非线性增长。 Transformer 注意力机制的复杂度相对于序列长度是 O(n²)。将上下文加倍,计算量不是翻倍——而是翻四倍。一个传入 8,000 Token 文件内容的系统,处理成本是传入 1,000 Token 以回答相同问题的系统的 64 倍。那些看到账单飙升却归因于"用量增长"的团队,往往面对的其实是披着规模问题外衣的上下文膨胀问题。

质量在触及上限之前就已开始下降。 Chroma 在 2025 年针对"上下文衰退"(context rot)的研究——覆盖了 18 个前沿模型,包括 GPT-4.1、Claude Opus 4 和 Gemini 2.5 Pro——表明输出质量在上下文窗口填满之前就已出现明显退化。退化并不均匀:它遵循 U 形注意力曲线——位于上下文开头和结尾的 Token 获得的关注不成比例地多,而中间的 Token 则被部分忽略。针对多文档问答的研究发现,当相关文档从 20 个文档列表的第 1 位移到第 10 位时,准确率下降超过 30%。GPT-3.5-Turbo 有时在添加额外上下文后,表现反而比没有上下文时更差。

有效容量低于宣传值。 一个声称支持 200K Token 的模型,实际可靠的工作范围更接近 120K–140K。在宣传窗口的 60–70% 处,准确率就开始退化,而这种退化很难在聚合指标中发现,因为错误答案看起来和正确答案一样。

这些问题不会出现在请求延迟仪表盘或错误率监控中。它们表现为细微的质量漂移——输出在技术上逻辑通顺,但缺少关键细节、做出错误权衡,或自信地忽略了埋藏在检索文档第三页的相关约束。

度量缺口

大多数团队默默承受这些成本却浑然不觉,原因在于上下文利用率几乎从未被监控。团队会跟踪 Token 数量(通常作为成本信号而非质量信号),也会记录延迟。但几乎没有人追踪:

  • 上下文利用效率:上下文中有多少比例的 Token 被模型输出实际引用?如果传入了 20K Token,而答案只用到了其中 500 Token 的信息,那么你为 97.5% 的浪费买了单。
  • 相关内容的上下文位置:模型实际使用的信息出现在上下文窗口的什么位置?如果总是在中间,这就是一个警示信号。
  • 质量与上下文大小的相关性:随着上下文增大,输出质量(通过评估而非感觉来衡量)是否下降?这是上下文衰退最直接的信号,但几乎没有团队做这个实验。
  • 单次查询的上下文构成:系统提示词、对话历史、检索文档、工具调用结果各占多少 Token?这些数字自上个季度以来如何变化?

没有这些监控,上下文填充就是隐形的。账单上涨,质量下降,诊断结果是"模型变差了"或"用户变了",而不是"我们开始在每次调用中传入完整聊天记录加三份支持文档"。

上下文预算:一种工程实践

操作系统应对寄存器稀缺的方式不是购买更多寄存器——而是通过纪律和工具显式管理寄存器分配。同样的方法适用于上下文窗口。

上下文预算是按请求分配的 Token 容量,按来源细分。以下是一个处理编程任务的 Agent 的具体示例:

  • 系统提示词:2,000 Token(固定,每季度审查)
  • 任务描述和当前意图:500 Token
  • 对话历史(摘要版):1,500 Token
  • 检索到的代码上下文:4,000 Token
  • 本轮工具调用结果:2,000 Token
会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 12 分钟

擦除模型仍在读取的上下文:数据保留策略带来的隐患

一个每晚运行的删除作业正在清理你的提示词组装器在请求时读取的消息表。模型进入了一个被截断的对话,并自信地捏造了用户实际同意的 SLA。这个 Bug 存在于两个都认为自己拥有该表的团队之间。

insider
ai-engineering
阅读需 8 分钟

渐进式上下文替换:在长 AI 对话中保持质量的方法

硬截断和朴素摘要在长 AI 对话中都会导致质量下降。滚动替换模式——对近期轮次保持原始状态,同时对较旧内容进行增量压缩——是在会话超过四十轮时保持质量的有效方法。

insider
ai-engineering
阅读需 11 分钟

幽灵上下文:矛盾信念如何破坏长期运行智能体的记忆

持久化智能体记忆库会随时间积累相互矛盾的事实——而大多数系统会在不加警告的情况下同时检索它们。以下是该故障在生产环境中的表现及预防模式。

insider
ai-agents
阅读需 8 分钟

零样本之墙:为什么上下文示例在生产规模下失效

少样本提示能让你以最小的投入达到 80% 的效果。除此之外,每提升一个百分点的准确率,成本都会剧增。本文将告诉你如何识别这些信号,并了解何时微调成为你唯一的杠杆。

insider
llm
阅读需 10 分钟

工具输出压缩:决定上下文质量的注入策略

AI智能体管道中的工具结果Token密度相差100倍。你选择的注入策略——原始注入、压缩还是提取——从根本上决定了智能体在规模化后的准确率上限、成本上限和延迟下限。

insider
llm-agents