8 篇博文 含有标签「context-management」

你的聊天机器人在前十五轮对话中运行完美。然后，问题出现了。它与之前的决定相矛盾。它询问用户已经提供过的信息。它丢失了对话开始时明确定义的多步骤任务的脉络。对话历史在技术层面上还在那里——你没有删除任何内容——但模型的行为却好像它不存在一样。

这就是上下文腐化（context rot）：随着对话历史增长，输出质量逐渐下降的现象。2024 年对 18 个最先进模型进行的评估，涵盖近 20 万次受控调用，发现即使在名义上拥有更大窗口的模型中，可靠性在超过 30,000 个 Token 后也会显著下降。在扩展对话中，高性能模型会变得和小得多的模型一样不可靠。问题不在于你的上下文窗口耗尽了，而在于 Transformer 注意力机制是二次方的——100,000 个 Token 意味着 100 亿对关系——模型被迫将注意力分散得如此稀薄，以至于重要的早期内容实际上被忽略了。

当团队遇到这个瓶颈时，通常会采用两种解决方案之一：截断或摘要。这两种方法都会以可预见的方式让情况变得更糟。

下次当用户抱怨“AI 今天变笨了”时，去看看你产品的分析数据。筛选出对话轮次超过 20 轮的会话。你会发现每次都是同样的 U 型曲线：前几轮表现良好，中间几轮表现也不错，而到了后期轮次，质量却直线下跌。提示词没变，模型也没变。变化的是，后期每一轮对话都背负着沉重的载荷：用户的拼写错误、话说到一半的废话、模型的模棱两可、后来被撤销的更正、没人重读的工具输出，以及用户在第四轮就放弃了的目标残余。你的提示词模板把这些“沉积物”当成了信号，模型也是如此。但这不应该。

对话历史并非免费的上下文。它是一种你每一轮都在付费重新发送的负债；它变得越混乱，就越会损害你向用户收费提供的答案。“聊天”这个隐喻是混乱的根源。聊天界面让用户和工程师习惯于将记录视为神圣不可侵犯的 —— 可滚动的、仅限追加的、从不重置。这种习惯被原封不动地引入了 LLM 应用中，尽管在模型处理上下文的物理机制上并没有这种依据。模型是无状态的。对话记录只是你选择不断拉长的一段字符串。你可以缩减它，而且通常你应该这样做。

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

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

一场持续 90 分钟的客服会话。一个已经浏览文档一小时的研究助手。一个已经处理十几个文件的编程 Agent。所有这些最终都会撞上同一堵墙——但撞上时，它们不会大声报错。它们只会变得迟钝。

模型开始遗忘二十分钟前做出的决定。它自相矛盾。本应显而易见的检索结果莫名消失。用户察觉到有些不对劲，却说不清助手为何变差了。这就是上下文窗口悬崖：不是一个硬性错误，而是一种渐进的质量崩塌——而你的监控系统几乎肯定没有衡量它。

扩大上下文窗口并不能解决这个问题。拥有百万 Token 窗口的模型在处理中间位置内容时仍然会退化；即便不退化，你也在为多出 100 倍的 Token 买单，而模型实际关注的只是其中一小部分。解决方案是应用层的上下文管理——明确策略什么留在窗口里、什么被压缩为摘要、什么完全移到窗口之外。

前沿模型如今宣传的上下文窗口动辄 200K、1M 乃至 2M token。工程团队将其视为已解决的问题而继续前行。数字如此之大，我们应该永远不会触及上限。

然而，在一个自主研究任务执行六小时后，agent 开始产生幻觉，对它三小时前编辑过的文件路径一无所知。一个代码 agent 自信地打开了它在第四轮已删除的函数。文档分析流水线开始与它之前从同一文档得出的结论相矛盾。这些不是模型失败——它们是上下文预算失败：可预测、可测量，而且只要将上下文窗口视为它实际所是的稀缺计算资源，几乎完全可以预防。

当你的 API 成本飙升，有人建议“直接压缩上下文”时，这个方案听起来很简洁：输入更少的 token，支付更低的费用，获得同等的输出。LLMLingua 的基准测试显示，在数学推理上实现了 20 倍的压缩，而准确率仅下降了 1.5%。这听起来怎么会不好呢？

问题在于，这些基准测试衡量的是压缩后的上下文在干净、精心策划的测试集上的得分。它们没有衡量当你的智能体悄悄丢弃三轮对话前给出的约束、将代词解析到错误的实体，或者因为原始工具输出被总结掉而胡编乱造一个确切的文件路径时会发生什么。上下文压缩不仅仅是减少 token —— 它改变了模型实际看到的内容。而原始上下文与压缩版本之间的差距，正是你的系统注定会失败的地方。

大多数团队发现他们上下文管理问题的方式都如出一辙：一个在演示中表现良好的生产级智能体，在对话进行 15 轮后开始出现幻觉。日志显示 JSON 格式正确，模型返回了 200 状态码，且没有人修改代码。变化的是累积效应——工具结果、检索到的文档和对话历史悄无声息地填满了上下文窗口，直到模型需要在 80,000 个相关性参差不齐的 Token 上进行推理。

上下文溢出（Context overflow）是显而易见的故障模式，但“上下文腐化”（context rot）则更具隐蔽性。研究表明，在达到限制之前，LLM 的性能就已经开始下降。随着上下文的增加，模型会出现“中间迷失”效应（lost-in-the-middle effect）：注意力集中在输入的开头和结尾，而中间的内容则变得不可靠。埋藏在 30 轮对话中第 12 轮的指令可能会实际上消失。模型不会报错——它只是悄悄地忽略了它们。

大多数初次发布 LLM 应用的团队都会犯同一个错误：他们将上下文窗口视为免费存储。模型支持 128K tokens？太好了，塞满它。模型支持 1M tokens？更棒了——把所有东西都扔进去。接踵而至的是在产品真正跑通前三周就提前到达的账单冲击。

上下文不是免费的。它甚至一点也不便宜。除了成本之外，盲目填充上下文窗口实际上会让你的模型变得更糟。一个精简的 300 token 上下文通常优于一个松散的 113,000 token 上下文。这不是极端情况——而是一个有明确名称的文档化失效模式：“中间迷失”（lost in the middle）。管理好上下文是你对 LLM 产品做出的最高杠杆的工程决策之一。