9 篇博文 含有标签「context-window」

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

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

用户与 AI 助手进行了一个小时的长代码会话。他们建立了规范，分享了代码库上下文，并详细描述了一个多文件重构方案。接着，在第 40 条消息左右，AI 开始给出忽略其“已知”一切的建议。它推荐了一个用户二十分钟前已经拒绝的方案。当被追问时，它显得很困惑。

没有显示任何错误。没有出现任何警告。模型只是静默地丢弃了较早的消息，以为新消息腾出空间——而用户得出的结论是，该 AI 不可靠。

这不是模型失败。这是产品设计失败。

200K token 的上下文窗口并不是真正的 200K token 窗口。将其填满，你刚刚付费使用的模型就会悄然变成一个更糟糕的版本——这种退化并非发生在“迷失在中间（lost in the middle）”所预言的中间位置，而是在右侧边缘，也就是近因偏差（recency bias）本应拯救你的地方。包装盒上的标签卖给你的是余量；而硅片卖给你的却是悬崖。

这是一种大多数团队尚未内化的不同失效模式。“迷失在中间”训练了一代提示词工程师（prompt engineers），让他们习惯于将关键指令放在开头，将关键问题放在结尾，坚信首因效应（primacy）和近因效应（recency）能确保信号得以传递。然而，当利用率接近宣称的窗口极限时，这种启发式方法会悄然失效。这种下降并非逐渐的、线性的，也与模型在半满状态下的表现不对称。一旦超过某个随模型而异的利用率阈值，你就进入了一个不同的运行机制，在 30K 时有效的提示词结构在 180K 时会彻底失败。

经济上的诱惑让情况变得更糟。如果你刚刚为百万 token 的窗口付费，那么使用它的压力是巨大的——你会倾倒整个代码库，喂入每一张支持工单，交给它季度财报，并让它找出重点。结果就是，你会得到一个看似推导严密、实则自信错误的答案，而在审计时它会瞬间瓦解。

当 100 万 token 的上下文窗口实现商业化时，许多团队悄然认定，他们已经解决了智能体记忆（agent memory）的问题。当你可以把所有内容都丢进去并让模型自己处理时，为什么还要构建检索系统、管理向量数据库或设计淘汰策略（eviction policy）呢？答案就在你的基础设施账单中。在每天 1 万次交互、拥有 10 万 token 知识库的情况下，这种暴力的上下文内（in-context）方法每天的成本约为 5,000 美元。而处理同样负载的检索增强记忆系统的成本约为每天 333 美元 —— 随着用户群的增长，这 15 倍的差距会产生复利效应。

真正的问题不仅仅是成本。更严重的是，更长的上下文会导致答案质量显著下降。研究一致表明，模型会丢失位于极长输入中间位置的信息；当相关的证据被埋没在无关的代码块（chunks）中时，准确率会如预见般下降；且延迟的攀升会使交互式智能体显得反应迟钝。这种“塞进一切”的方法不仅浪费金钱 —— 它还以牺牲准确性为代价换取了简单化的假象。

每一个对话式 AI 功能的 Demo 都做同一件事：向模型传入一个消息列表，然后打印响应。这条快乐路径在 Jupyter Notebook 里运行顺畅、看起来很美，并让你顺利拿到上线许可。然后你到了生产环境——p99 延迟在高峰期开始悄悄爬升。一个月后，有客户投诉说助手"忘记"了会话早期的所有内容。六周后，你的会话存储在某次产品发布期间撞上了内存上限。

根本问题在于：「传递完整对话历史」根本不是一种会话管理策略，它是会话管理策略缺失的表现。

大多数 AI 产品将上下文限制视为一个对用户隐藏的实现细节。这种决定在演示中看起来很简洁，但在生产环境中却是灾难性的。当用户在执行任务中途达到上限时，通常会发生以下三件事之一：请求抛出硬错误；模型因为丢失了关键的早期上下文而悄悄开始产生幻觉；或者产品重置会话并销毁所有积累的状态。对于一个你要求人们在实际工作中信任的产品来说，这些结果都是不可接受的。

Token 预算并不是一个可以敷衍了事的怪癖。它是一个核心产品约束，应该像内存限制在系统编程中那样，被纳入你的设计流程。交付可靠 AI 功能的团队已经不再假装这个天花板不存在了。

你的智能体完美地完成了第一步到第六步。第七步与第二步相矛盾。第八步幻觉出了一个并不存在的工具。第九步自信地提交了垃圾内容。没有程序崩溃，没有抛出错误。智能体只是忘记了它正在做什么 —— 并且无论如何都在继续。

这就是上下文窗口悬崖（context window cliff）：即 AI 智能体积聚的上下文超过其有效推理能力的时刻。它不会优雅地失败，也不会寻求帮助。它会基于部分信息做出自信但错误的决策，而你直到损失造成才会察觉。

大多数团队知道他们的用户发送了多少 token。但几乎没有人知道在用户开口说话之前，他们已经支出了多少 token。

在典型的生产级 LLM 流水线中，系统提示词 (system prompts)、工具架构 (tool schemas)、聊天历史、安全前导词和 RAG 序言在实际用户查询到达之前，就默默消耗了上下文窗口的 30–60%。对于拥有数十个注册工具的智能体 (agentic) 系统，这种开销在 128k 窗口中可能达到 45% —— 约 55,000 个 token —— 而这些工具定义甚至从未被调用过。

这就是隐藏的 token 税。它虚增了成本、增加了延迟并降低了输出质量 —— 然而，它从未出现在任何面向用户的指标中。

你在为一个 200K token 的上下文窗口付费。你的用户可能只用到了其中的 80K。剩下的部分在第一条消息到达之前就消失了——被系统提示词（system prompt）、工具定义、安全前言和聊天历史填充所消耗。这就是隐藏的 Token 税，大多数团队直到在生产环境中达到上下文限制时才意识到自己在为此付税。

宣传的上下文窗口与实际可用的上下文窗口之间的差距是生产级 LLM 系统中最昂贵的盲点之一。它在多轮对话中不断累积，通过注意力开销增加延迟，并在有用信息被挤入模型停止关注的“迷失在中间”（lost in the middle）区域时，悄无声息地降低输出质量。