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

大多数工程团队对待 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
• 为模型输出预留：2,000 Token
• 总计：12,000 Token

预算不是上限——它是一份契约。当某个类别超支时，其他类别必须缩减。这种约束迫使每个内容来源证明自己存在的价值。

预算制度也会暴露悄然膨胀的类别。一个从 500 Token 起步、经过六个月"只加一条指令"已增长到 2,500 Token 的系统提示词，正在消耗本应留给检索上下文的预算。未经摘要的对话历史会无限传入原始轮次；第 40 轮相比对第 1–40 轮的优质摘要几乎不增加任何信息，却与其他任何 100 Token 块耗费相同的成本。

优先级驱逐

有了预算，就需要一套内容超限时的驱逐策略。操作系统已发展出多种驱逐机制——LRU、LFU、成本感知驱逐——这些机制可以移植到上下文管理中，但需要针对 LLM 推理的特点加以调整。

时间近性不总是正确的维度。 LRU 在缓存中有效，因为最近访问的数据统计上更可能再次被访问。在对话上下文中，最新的轮次固然要保留，但最早的轮次可能同样关键——用户最初的目标、声明的约束条件，或是后续一切都依赖的先前决策。纯粹按时间近性驱逐，会在保留噪声的同时丢弃锚点。

与当前意图的相关性是主要信号。 正确的驱逐问题是：考虑到模型当前的任务，哪些上下文项最不可能影响输出？对于多步骤 Agent 而言，第 1 步的任务分解在第 10 步时可能仍至关重要；第 3 步的中间工具结果在第 6 步时可能已可安全压缩。相关性驱逐需要一个轻量级分类器，或更简单的启发式方法——与当前语义意图的距离。

驱逐前先压缩。 在彻底移除某个上下文项之前，先对其压缩。一个 2K Token 的工具调用结果通常可以在不损失关键信息的情况下压缩到 200 Token。压缩在回收预算的同时保留了信号。应用于检索文档的提示词压缩技术可实现 50–70% 的 Token 缩减，同时保持下游任务 98% 的逐字准确率——在某些基准测试中，压缩后的上下文甚至优于两倍长度的原始上下文，因为压缩强制过滤了相关性。

关键内容设置硬性下限。 部分上下文项必须在任何驱逐中幸存：任务描述、用户的最新消息，以及用户明确声明的任何约束。这些内容获得专属预算，任何其他类别都不得侵占。没有硬性下限，系统会陷入一种失效模式：上下文被检索文档填满，模型回答的是用户三轮之前就停止追问的问题。

RAG 上下文构建：一项一等关切

检索增强系统在每次检索调用中都在隐式地做上下文管理决策。默认行为——检索 top-k 片段并拼接——会产生高 Token 数和不稳定的质量。更好的方法将上下文构建视为一个显式的组装步骤：

检索更多，传入更少。 用快速的词法-语义混合方式（BM25 + 嵌入）检索 10–15 个候选，再用交叉编码器重排到 3–5 个，最后只将重排结果传给 LLM。相比朴素的 top-k，这个流程通常能减少 60–70% 的输入 Token，同时提升精准度，因为重排器能够跨候选进行全局相关性评估。

按问题切分，而非按文档切分。 大多数 RAG 流水线在索引时以固定大小切分文档。在检索时，相关单元往往更小——通常是包含关键事实的一段或几句话。提取最小相关片段而非完整块，能减少噪声并改善内容在上下文中的位置分布。

有意识地安排相关内容的位置。 鉴于 U 形注意力曲线，价值最高的检索内容应出现在组装上下文的最开头或最末尾，而非埋在中间。当你有五个相关性大致相当的检索块时，排列顺序比大多数团队意识到的更重要。

在生产环境中追踪检索精准度。 如果检索到的文档很少被模型输出引用——你可以通过检查输出中的主张是否可追溯到检索内容来衡量——说明检索质量低下，再多的上下文工程也无济于事。检索精准度是一个独立的调节旋钮，与上下文构建相互独立，两者都需要监控。

无需重写即可上手

上下文预算和驱逐策略听起来像是基础设施工程，但第一个版本只需要纪律和日志：

1. 审计当前上下文构成。 用一周时间，对抽样请求记录按来源划分的 Token 数量（系统提示词、历史记录、检索内容、工具调用）。光是这一步，通常就能发现某个类别已经失控膨胀。

2. 为每个类别设定预算。 根据审计结果，为每个来源分配 Token 上限。让这些限制在代码中可见——不是魔法数字，而是带有注释说明权衡的命名常量。

3. 为对话历史实现摘要。 在 5–10 轮后，用滚动摘要替代原始历史记录。这是大多数对话式系统中杠杆效应最高的改动，一天内即可实现。

4. 为 RAG 流水线添加重排。 在将 top-10 检索候选传给 LLM 之前，加一个交叉编码器重排——这只是一次额外的 API 调用，却能稳定地提升质量并缩减上下文规模。

5. 增加质量-上下文大小实验。 对 5% 的请求进行采样，改变上下文大小并比较输出质量。如果质量峰值远低于你的最大上下文分配，说明你找到了可以回收的预算。

上下文窗口还会继续增大，往其中塞更多内容的诱惑也会随之增强。但成本和质量的动态规律不会因窗口变大而改善——它们只是将退化点推得更远，同时保持惩罚曲线不变。把上下文当成稀缺的、需要显式管理的资源的团队，将构建出随规模增长依然保持连贯和可预测的系统。把它当成免费存储的团队，将在未来几年里持续调试无法定位的质量回归，并支付无法解释的推理账单。