Anthropic 和 Google 测试 AI 上下文窗口限制

Anthropic 本月将 Claude 的上下文窗口提升至 100 万 tokens。Google 随后对 Gemini 进行了相同更新。两家公司现在均声称其模型能够一次性容纳并推理整本书籍或整个代码库。

这一变化将竞争从单纯的答案质量转向内存容量。更长的窗口在需要完整文档回忆的任务中具有优势，但也带来了成本和准确性的新失效模式。竞争现在聚焦于在极端负载下保持可靠准确性，而非仅仅宣传更大的最大长度。根据 The Verge 的报道，这些公告已引发此前将上下文长度视为次要规格的采购团队内部的新预算讨论。

具体变化

Anthropic 于 6 月 10 日将 Claude 扩展至 100 万 tokens。Google 两天后为 Gemini Advanced 匹配了这一数字。在此之前，两项服务对大多数用户的上限均为 20 万 tokens。

新限制允许模型一次性摄入完整技术手册加上数月相关聊天记录。测试该功能的产品团队报告，在如此长的跨度上进行检索时，如果查询位于上下文中间，关键事实仍会被遗漏。多家初创公司的工程师描述了实验：在包含 400 页规范文档的 100 万 token 提示中，模型对前 100 页和后 100 页的问题能给出正确答案，但对 token 位置 450,000–550,000 左右的材料却生成不完整或虚构的摘要。

Anthropic 的发布说明显示，100 万 token 层级最初仅面向有限的企业客户推出，随后才会更广泛开放。Google 的公告强调与现有 Gemini Advanced 消费级套餐的集成，使该功能对个人开发者和小团队似乎更易立即获取。两家公司均使用类似的positional encoding 扩展和注意力优化来达到新规模，但均未以同行评审形式公布精确的架构修改。

进一步的推出细节显示，Anthropic 通过使用量阈值限制访问，并要求明确选择加入扩展层级，而 Google 立即为所有 Gemini Advanced 订阅者启用了该功能。这种分发策略的差异凸显了不同的理念：Anthropic 似乎专注于受控评估以收集失效模式遥测数据，而 Google 则优先在不同领域实现快速用户反馈循环。在 NDA 下共享的早期内部遥测数据显示，Anthropic 在有限发布的前两周观察到多文档推理准确性下降 12%，促使在更广泛推出前进行额外安全微调。

上下文窗口背景

上下文长度指模型在单次前向传递中可处理的最大 token 数量。早期 transformer 模型（如原始 GPT-2）使用 1,024 tokens。后续版本将此数字增加到 4,096，然后是 32,768，最近达到 128,000–200,000 tokens。每次跃升都需要在位置嵌入、注意力机制和训练硬件内存管理方面进行改进。

跃升至 100 万 tokens 代表较此前实际上限约 5 倍的增长。这一规模允许模型接收整部小说、包含测试套件的完整法律代码库，或多个季度的收益电话会议记录拼接在一起。然而，标准注意力的二次方缩放意味着计算和内存需求会迅速增长，这解释了为何一旦用户超过几十万 tokens，定价和延迟惩罚就会立即显现。

历史进程显示，每一个上下文长度里程碑都与硬件进步相吻合——GPU 上更大的 HBM 内存池以及加速器之间改进的互连带宽。100 万 token 门槛现在已触及当前加速器集群的极限，迫使提供商对超出活动注意力窗口的 token 实施激进的 KV-cache 驱逐策略。例如，2023 年从 128k 扩展到 200k tokens 已需要自定义 FlashAttention 内核；再扩展五倍则需要内核融合和内存分页方面的进一步创新。

扩展上下文背后的技术机制

模型通过多种技术组合实现更长上下文。Rotary Position Embeddings (RoPE) 及其扩展允许相对位置信息泛化到训练时未见过的长度。滑动窗口注意力和其它稀疏模式减少了 token 间比较的数量。一些实现进一步将上下文的早期部分压缩为占用更少内存的摘要向量或键值缓存。

Anthropic 和 Google 似乎都依赖这些方法的混合，加上对长文档的持续预训练。非正式共享的内部基准表明，一旦活动上下文超过公布最大值的约 40%，连贯性就开始下降。这种下降表现为实体遗漏、对仅陈述一次的事实的矛盾陈述，以及当相关段落深埋时倾向于使用通用措辞。

其他机制包括 ALiBi 风格的线性偏置和内存高效注意力变体（如 FlashAttention-2），两家公司均已针对推理时扩展进行了适配。独立研究人员进行的实验表明，过于激进地应用稀疏注意力掩码可能会无意中剪除重要的跨文档引用，导致多跳推理准确性可衡量的下降。更新的扩展如 Ring Attention 和 Infini-Transformer 架构进一步支持跨多个 GPU 的分布式注意力，但它们引入了同步开销，在商品硬件上可能使端到端延迟翻倍。

谁感受到压力

构建检索系统的团队现在面临直接选择：依赖新的长窗口，还是继续投资单独的向量存储。销售检索增强生成工具的初创公司报告，早期客户询问付费长上下文选项是否完全取代他们的产品。

大型企业则根据合规要求权衡同一决策。单次 100 万 token 调用可能花费数美元 API 费用，促使财务团队在批准更广泛推出前要求详细的使用预测。法律部门还质疑，即使模型提供商提供提示级删除保证，将整个内部 wiki 或客户历史存储在一个提示中是否违反数据驻留政策。

财富 500 强公司的采购周期现在包含专门的上下文窗口测试项目，安全审查将时间线延长 4 至 6 周。资源较少的小型初创公司通常默认采用混合架构，将向量存储作为主要检索层，仅在最终合成步骤中调用长上下文模式。一家 B 轮代码助手初创公司计算得出，用原生 100 万 token 提示替换现有 RAG 管道将使每月推理支出增加 340%，迫使其转向选择性缓存策略。

真实世界用例与示例

开发团队报告，在代码审查和代码库入职方面，近期最明显的收益最为清晰。包含整个代码库加上提交历史的单个提示允许 Claude 或 Gemini 回答诸如“哪些函数引用了已弃用的身份验证模块，以及最近拉取请求中显示的迁移路径是什么？”等问题。当相关代码和讨论出现在相隔数千 tokens 的不同文件中时，答案仍保持准确。

法律科技公司已开始大规模测试合同分析。一家公司将 60 份单独的主服务协议及其所有修订加载到 100 万 token 窗口中，要求模型找出所有管理数据处理附录的条款。模型正确识别了 93% 的目标条款，但遗漏了最长文档中间三分之一位置的两处条款。分析 200 页临床试验方案的学术团队同样观察到，除非明确提供页码范围提示，否则附录中隐藏的不良事件表会被忽略。

探索科学文献摘要的研究小组也看到了类似模式。当包含 40 篇相关论文的全文时，模型能针对摘要或结论中出现的主题生成连贯的跨论文比较。但当综合仅在 token 序列更深处补充部分描述的方法时，表现较差。

成本与召回的权衡

Token 定价仍是 clearest 的约束。按当前费率，一次完整的 100 万 token 请求成本约为标准 10 万 token 调用的十倍。根据 Anthropic 工程师共享的内部测试，一旦上下文超过 40 万 tokens，模型的幻觉率也会更高。

Google 声称其 Gemini 实现在新规模下保持更强的连贯性。独立基准尚未在多个领域证实这一说法。使用合成“针在 haystack 中”测试的早期第三方评估显示，当插入的事实出现在上下文任一极端时，两家提供商均能实现近乎完美的召回，但当事实置于中间附近时，性能下降 15–30 个百分点，如 9to5Google 的报道所述。详细的成本建模显示，每天运行超过 50 次长上下文查询的组织会迅速耗尽分配用于实验的月度预算。一些团队已开始探索缓存提示前缀——一次性付费加载大型代码库，然后针对缓存状态发出增量查询——尽管 Anthropic 和 Google 尚未在完整 100 万 token 级别公开稳定的缓存 API。

对开发者和企业的实际影响

考虑迁移的组织应首先衡量其工作负载实际所需的上下文长度。许多检索增强生成管道通过使用高质量分块和重排序，已能在 20,000–50,000 tokens 下实现可接受的准确性。只有当任务真正受益于同时查看每个文档部分时，迁移到 100 万 token 提示才有意义。

开发者还应实施渐进式检索策略，仅加载可能重要的上下文部分。分层摘要等技术——生成早期对话轮次或文档部分的浓缩版本——可以在保留关键细节的同时减少有效上下文大小。一旦长上下文功能从实验转向生产，监控每请求 token 数量和成本仪表板就变得至关重要。运行合规审计的企业现在要求明确记录输入这些扩展窗口的每个 token，增加了另一层运营开销。

限制与风险

在 100 万 token 下的准确性仍然因文档类型而异。代码仓库的表现优于混合的会议记录和幻灯片。尚无公开研究测量法律合同或金融模型在这种长度下的错误率。

监管机构已开始询问，长上下文模型是否会增加同一窗口中存储的敏感信息泄露的风险。两家公司均表示，提示级控制可限制暴露，但企业安全团队希望在迁移前获得独立验证，相关报道见 Bloomberg。另一个担忧涉及位置偏差：模型似乎会过度重视上下文前 10% 和后 10% 呈现的信息，这可能为提示注入攻击创造机会，攻击者可将误导性指令置于这些高可见位置。延迟也会明显增加；当前基础设施上完成一次 100 万 token 的请求可能需要 30–90 秒，即使成本不是主要障碍，这也限制了交互式用例。研究人员还指出，一旦上下文窗口超过大多数公开可用文档的长度，训练数据污染风险会急剧上升。

与其他提供商的比较分析

OpenAI 目前为 GPT-4o 提供 128,000 token 的上下文窗口，并表示将继续投资检索工具而非立即增加长度。因此 Anthropic 和 Google 的举措形成了暂时的差异化，可能会迫使 OpenAI 做出回应。与此同时，Gradient 的 100 万 token Llama 衍生版本和 Together AI 的长上下文托管等开源努力表明，该能力正在主要云提供商之外普及，尽管稳定性和支持程度各不相同。Meta 的 Llama 3.1 405B 版本进一步原生支持 128k，社区扩展已突破 500k，表明长上下文技术正在专有和开源生态系统中快速扩散。

企业采用挑战

大型组织还必须应对这些模型能力出现前就已存在的内部治理框架。数据治理负责人现在要求提供明确的数据流图，精确显示在长上下文调用期间哪些 token 会离开本地系统。审计轨迹必须不仅捕获最终答案，还要记录每一次中间 KV-cache 驱逐决策——这是大多数供应商尚未在工具中解决的工程负担。

仍不确定的事项

极端长度下的准确性仍未得到充分表征。文档类型差异、模型特定的架构选择以及是否存在领域特定微调都会影响结果。系统性地改变文档体裁、关键事实位置和查询复杂度的公开基准仍然稀缺。

另一个开放问题是最佳定价模型。当前的每 token 定价线性惩罚长上下文，但额外 token 的边际价值可能遵循收益递减曲线。两家提供商最终可能会引入分层定价或上下文压缩额度，以鼓励采用而不导致成本同比增加。

接下来要关注的事项

三个信号将表明长上下文窗口是否会成为标准实践。首先，关注未来八周内发布的、在 500,000 token 文档上测试召回率的基准。其次，观察 OpenAI 是否会推出匹配的限制，或转而强调检索工具。第三，跟踪已将生产工作负载迁移到新窗口的团队的 API 成本报告；如果持续支出高于计划数字，将会减缓采用。已经在探索持久内存系统的团队可以通过在两条路径上测试同一文档集，来比较新的上下文选项与 remio.ai。

常见问题

100 万 token 的窗口是否取代了对向量数据库的需求？

并非完全如此。向量搜索对于简单查找任务仍然更快、更便宜。当推理需要同时考虑整个语料库中分散的关系时，长上下文窗口更具优势。

团队应如何负责任地测试新限制？

首先在具有代表性的文档类型上进行合成大海捞针评估，然后逐步过渡到真实工作负载，同时监控准确性指标和 token 消耗。

Anthropic 和 Google 的实现在行为上是否存在差异？

早期用户报告显示，Gemini 在叙事文本上保持略好的连贯性，而 Claude 在代码上表现更可靠。全面的头对头研究仍在涌现。