跳转到主要内容

上下文长度军备竞赛:为什么填满窗口是错误的目标

阅读需 2 分钟Tian PanTian Pan

每隔六个月,就会有一款配备更大上下文窗口的模型问世。GPT-4.1 达到了 100 万 Token,Gemini 2.5 紧随其后,达到 200 万,而 Llama 4 如今更是号称支持 1000 万 Token。隐含的承诺是:把所有内容都塞进去,不用再纠结该放什么,让模型自己搞定。

这个承诺在生产环境中站不住脚。一项 2024 年针对 18 个主流 LLM 的研究发现,随着输入长度增加,每一个模型的性能都出现下降——不是某些模型,而是每一个。上下文窗口是天花板,而非地板。把它当作地板来用的团队,正在以痛苦的方式发现这一点。

"上下文腐败"究竟是什么样的

Chroma 研究团队创造了"上下文腐败"(context rot)这个术语,用来描述一种普遍规律:无论相关信息是否存在,随着上下文长度的增长,LLM 的准确率会持续下降。仅仅检索 20 个文档(约 4000 个 Token),准确率就可能从 70–75% 的区间跌至 55–60%。这不是微小的退化——这是一种失效模式。

其机制源于架构本身。Transformer 注意力机制的计算复杂度是二次方的。在 10 万个 Token 时,模型需要处理大约 100 亿对的配对关系。注意力权重被稀释。语义相似但不相关的内容会主动干扰模型,而不是被过滤掉。更多的上下文意味着更多的干扰,而非更多的信息。

性能退化也不是渐进式的。模型通常能稳定保持性能,直到触及某个阈值,然后急剧下滑。一个在 5000 个 Token 下能可靠处理简单检索任务的模型,在需要全程专注于 1200 个 Token 进行复杂多步推理时,可能会失效。

"中间丢失"问题尚未解决

2023 年斯坦福大学的一项研究(2024 年发表于 TACL)记录了如今被称为"中间丢失"(Lost in the Middle)的问题。当相关信息被放置在长上下文的中间位置时,模型准确率会大幅下降。这种 U 形性能曲线在各模型中表现一致:开头部分表现强,结尾部分表现强,中间部分则不可靠。

数据触目惊心。早期和晚期上下文的准确率达到 85–95%,而中间部分跌至 76–82%。当 GPT-3.5-Turbo 无法可靠地关注到埋在上下文中间的文档时,其准确率降至 56.1%——甚至比该模型在没有任何文档的情况下直接作答(闭卷测试)的表现还差。

根本原因在于架构设计。大多数现代 LLM 使用的旋转位置编码(RoPE)引入了一种长距离衰减效应:距当前位置越远的 Token,所获得的注意力权重越小。"100 万 Token 上下文"并不意味着模型能对所有 100 万个 Token 同等关注,而是说模型在技术上可以接受这么多 Token,但注意力分布极度不均匀。

这不是一个会被修复补丁消除的 Bug。CARoPE、3D-RPE 和 DoPE 等变体正在逐步解决这一问题,但注意力机制的根本特性仍然偏好最近和最前的内容。信息的位置与信息本身同等重要。

你未曾预料到的延迟与成本

上下文窗口大小在时间和金钱上都有直接的非线性成本。在推理时,模型必须处理上下文中的每一个 Token;在 API 计费时,每个输入 Token 都要计费。这些不是抽象的担忧——它们决定了一个 AI 产品是否具备经济可行性。

提示词缓存对重复的前缀内容有所缓解。Anthropic 的缓存在命中时可将输入成本降低高达 90%,OpenAI 的自动缓存则提供 50% 的节省。但缓存只对静态的、重复的内容有效。每次请求都会变化的动态上下文无法从缓存中受益。

会员专享

余下内容仅对会员开放。

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

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

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

参考资料

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

阅读需 8 分钟

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

将完整文档、原始工具输出和长聊天历史直接塞进 LLM 上下文窗口是一个可靠性陷阱。本文将介绍如何检测上下文何时在损害你的系统 — 以及如何通过具备预算意识的策展模式来修复它。

insider
llm
阅读需 8 分钟

摊销上下文:持久化智能体记忆 vs 长上下文窗口

长上下文模型诱使你将所有内容都塞进去 —— 但这会导致成本增加 15 倍,且生成的答案质量更差。本文介绍了一套决策框架,帮助你确定哪些内容应存入外部记忆、哪些内容需重新检索,以及哪些内容应保留在窗口内,并配合压缩模式,让记忆增强智能体在大规模应用中更便宜、更准确。

insider
ai-engineering
阅读需 8 分钟

分析 LLM 流水线:推理之外的性能瓶颈

大多数 LLM 流水线的延迟并不发生在推理阶段。本文将详细分析真正的瓶颈——预处理、重复分词、同步检索、序列化——以及如何通过分阶段追踪使它们可见。

insider
llm
阅读需 10 分钟

LLM 应用的特征存储模式:停止检索那些你可以预计算的内容

将特征存储架构应用于 LLM 上下文组装,可以显著降低检索延迟、减少推理成本,并防止因训练-推理偏差(training-serving skew)而导致的模型性能静默下降。

insider
llm
阅读需 8 分钟

推理优化陷阱:为什么提升单个模型的速度反而会拖慢你的系统

将模型组件更换为更快的版本往往会增加端到端的延迟和成本。本文将探讨其中的原因,并介绍如何通过严谨的性能分析流程来避免这一问题。

insider
ai-engineering