为什么更多上下文会让AI的回答更糟

更大的上下文窗口为 AI 系统提供了更多容量。它并不保证模型会很好地利用这些容量。在长对话、RAG 流水线、研究智能体和工具密集型工作流中，添加更多历史记录、更多文档、更多工具输出或更多记忆，可能会让回答变得更不可靠，而不是更有依据。

上下文容量不等于上下文可用性

模型宣称的上下文窗口描述的是它能接受多少输入。这并不意味着该窗口内的每个 token 都会获得同等关注，或对最终答案有同等贡献。这一区别很重要，因为生产系统越来越多地用对话历史、检索文档、工具结果、记忆、结构化状态、指令和中间产物来填充上下文。

经典的“迷失在中间”研究表明，当相关证据出现在长输入的中部时，长上下文模型的表现可能比证据出现在开头或结尾附近时更差。更广泛的工程启示并不是长上下文不好，而是上下文中的可用性并不等同于可靠使用。

OpenAI 的上下文管理指南从另一个方向得出了相同的操作结论：即使是非常大的上下文窗口，也可能被未经筛选的历史记录、冗余的工具输出和嘈杂的检索结果淹没。Anthropic 同样将上下文视为一种有限资源，需要主动工程化，而不是被动累积。

额外上下文降低答案质量的五种方式

1. 信号稀释：相关证据与其他所有内容竞争

假设一个问题可以用两段短文回答。一个 RAG 系统“为了保险”检索了这两段，再加上十八段关系不大的内容。检索召回率可能提高了，但生成器现在必须从背景材料中区分出决定性证据。如果相似措辞出现在多个文档中，额外上下文可能会让答案变得不够精确。

这就在检索召回率和上下文效用之间形成了一个重要区别。更多检索材料可能提高答案存在于上下文中某处的概率，同时降低模型给予正确证据足够权重的概率。

2. 证据冲突：更多来源可能意味着更多版本的现实

长上下文常常包含相互不一致的信息：新旧 API 文档、两个政策版本、先前和当前用户偏好、相互竞争的网页来源、缓存状态，或不再与来源匹配的模型生成摘要。

这种失败不一定是幻觉。模型可能是在忠实地组合相互矛盾的证据。因此，架构需要优先级规则：来源权威性、版本、时间戳、司法管辖区、租户、产品修订版、用户状态或显式取代元数据。

如果没有这些规则，增加上下文可能会让矛盾增加得比知识更快。

3. 位置敏感性：证据出现的位置会改变结果

“迷失在中间”的结果表明，仅改变相关信息的位置就可能实质性改变模型性能。这一发现对于按固定顺序拼接大量检索段落或长历史记录的系统尤为重要。

因此，生产测试应改变文档顺序，而不仅仅是测试一个标准提示。如果系统只有在决定性证据位于最前或最后时才能正确回答，那么该应用比单一基准分数所显示的更为脆弱。

4. 陈旧上下文持续存在：模型同时看到真相和历史

长时间运行的智能体经常将先前的结论延续下去。这种连续性在事实发生变化之前是有用的。如果昨天的工具结果显示某个部署是健康的，而当前的工具结果显示它已降级，除非系统明确替换或限定旧状态的范围，否则两者可能都保留在上下文中。

这就是为什么当前操作状态通常应来自权威来源，而记忆则保留持久性上下文，如决策、偏好或流程。更多的对话历史并不能替代重新读取当前状态。

5. 压缩损失：更小的上下文也可能变成更差的上下文

相反的操作——压缩上下文——也有失败模式。摘要可能会丢失例外情况、未解决的问题、来源、精确标识符、负面证据，或结论有效的条件。

微软研究院的智能体上下文工程工作将相关问题描述为简洁性偏差和上下文崩溃：迭代重写可能会移除有用的领域细节。因此，目标不是“尽可能压缩”。而是在减少上下文的同时，保留那些会改变决策的信息。

上下文质量模型

有用的上下文可以从六个维度进行评估。这些维度都不是简单的令牌数量。

上下文压力测试

要确定应用是否能从更多上下文中受益，应将上下文大小作为实验变量进行测试，而不是假设越大越好。

应衡量什么而不是令牌数量

RAG：为什么增加 top-k 可能适得其反

一种常见的 RAG 调优模式是：当系统漏掉答案时，就增加 top-k。这可以提高候选召回率，但也会增加无关上下文、重复证据、过时段落以及相互冲突的文档。

更好的问题是：决定性证据究竟是缺失于检索阶段，还是仅仅在上下文组装后失去了影响力。如果正确的段落已经出现在候选集中，那么增加 top-k 可能是在解决错误的问题。

长时间运行的智能体：连续性不等于累积

智能体需要跨步骤的连续性，但连续性并不要求重放此前的每一个 token。OpenAI 展示了针对长时间运行会话上下文的裁剪和压缩方法。Anthropic 推荐压缩、结构化笔记以及其他技术，以在控制上下文污染的同时保留有用信息。

一个强大的长时间运行架构通常会将持久记忆、当前状态、外部工件、检索以及面向模型的上下文分离开来。这样系统就能保留重要内容，而不必把每一个历史细节都塞进每一次推理中。

上下文顺序应当是有意设计的

上下文构建是一个信息架构问题。关键指令、当前状态、决定性证据以及任务特定约束不应被随意放置。当系统机械地拼接来源时，它们实际上是把优先级隐式交给了位置效应和模型注意力。

并不存在适用于所有模型和任务的通用最佳顺序，因此顺序应通过实证评估。一个有用的测试套件会随机化或系统地改变文档位置，并衡量同一主张是否保持稳定。

在压缩过程中保留决策边界

一个只说“采用方案 X”的摘要，弱于一个保留了为什么选择 X 以及什么会使该决策失效的摘要。上下文压缩应保留那些可能改变答案的变量：版本、日期、假设、状态、权威性、未解决的分歧以及证据来源。

这将上下文工程直接与答案有效性联系起来。如果压缩保留了一个结论，却移除了它的有效性边界，那么未来的回答可能仍然内部一致，却在外部变得错误。

一种实用的上下文构建策略

• 从当前任务出发，而不是从系统所知的一切出发。
• 在做出重大决策之前，从权威系统重新读取易变状态。
• 针对当前问题检索证据，而不是把庞大的静态语料库一直带下去。
• 移除重复或低价值的工具输出。
• 为重要证据保留来源版本、时间戳、权威性和出处。
• 当当前信息与历史信息冲突时，明确优先级。
• 将规则与其例外和前提条件一起保留。
• 当持久决策和可复用流程不需要逐字重放时，将其存储在即时上下文之外。
• 只有在测试了约束、标识符、例外和出处保留情况后，才压缩历史。
• 通过重复试验而非单次提示来评估上下文大小、顺序和噪声。

什么会改变这个答案？

这种权衡会随模型架构、训练方式、任务类型和上下文长度而变化。未来的模型可能会对位置、噪声和冲突信息变得显著更加稳健。对于拥有小型干净语料库的任务，直接提供完整来源，而不是构建复杂的检索流水线，也可能同样有益。

当遗漏比噪声更危险时，这一建议也会改变。在高召回率的研究或发现任务中，在后续的过滤或综合阶段之前，使用更大的候选上下文可能是合理的。在对延迟敏感的生产系统中，更严格的上下文选择可能更可取。

只有当模型能够可靠地对无关信息、位置、矛盾和过时证据保持不变时，核心原则才会改变。在此之前，上下文应被视为一种经过精心策划的执行资源，而不是被动存储。

局限性

长上下文行为在不同模型和工作负载之间差异很大。最初的“迷失在中间”实验使用的是早期几代模型，因此不应假设其确切的效应量能够代表当前系统。这一发现作为需要测试的失败模式仍然有用，但不应被视为普遍固定的性能曲线。

同样，减少上下文可能会移除必要的证据。压缩会引入摘要风险，而激进的检索过滤可能会降低召回率。目标不是不惜一切代价追求最少 token，而是为正在做出的决策提供充分、最新、可追溯的上下文。

结论

“模型能接受多少上下文？”这个问题，不如“这些上下文中有多少能改善决策？”更有用。更多 token 可以增加证据，但也可能增加干扰、矛盾、过时状态、位置脆弱性和压缩债务。

将上下文视为经过工程化设计的工作集。从最小充分证据开始。只有当信息能改善可衡量的性能时才添加它。明确测试噪声、冲突、排序和压缩。大上下文窗口是一种容量；上下文质量则是一种架构。

常见问题

术语表

主要来源与延伸阅读