26个模型实测：百万Token长上下文，Claude与Gemini谁更强？

引言：当百万Token窗口成为标配，我们该问什么问题？

把整个软件仓库丢给AI助手——数千个文件、数百个模块、API文档、数据库Schema、多年的开发历史。模型照单全收，然后你问它一个隐蔽的架构问题。它自信地给出了答案。

但这个答案真的可靠吗？

2026年，问题已经不再是语言模型能不能接收一百万Token。更有意思的问题是：它究竟能正确利用其中多少上下文？

两篇2026年的研究论文给出了令人意外的答案。一项名为ATLAS的研究评估了26个模型、6438个测试实例，覆盖8K到1M Token的输入长度。另一项CorpusQA研究则揭示了当证据分散在整个文档集合中时，传统RAG架构的深层困境。

为什么传统的模型对比方式会误导你

我们经常看到这样一张表：模型A支持128K，模型B支持256K，模型C支持1M。隐含的逻辑似乎是——C能处理更多信息，所以在大型文档任务上一定更强。

这个推理藏着一个未被验证的假设：接收更多信息等于有效利用这些信息。

考虑两类截然不同的任务。第一类是简单检索——文档中写着“部署标识符是QZ-7194”，模型只需找到这个字符串。第二类是复杂推理——一个仓库包含数十个服务定义、配置文件和依赖关系，模型需要判断哪些变更可能引入安全回归。

第二类任务远不止找到一个字符串，它需要跨多个位置整合证据、解决矛盾、理解依赖关系。在任务A上表现优异的模型，很可能在任务B上举步维艰。

这正是ATLAS试图解决的问题。

上下文窗口（Context Window） 指模型单次推理能够接收的最大Token数量，包括输入的系统提示、对话历史、文档内容和输出回复。它是模型架构层面的硬约束：Transformer的自注意力机制计算复杂度随序列长度呈平方级增长，因此扩展窗口需要滑动窗口注意力、稀疏注意力或位置编码外推（如RoPE插值）等技术。但“窗口大小”只说明模型能读入多少Token，不等于它对每个位置的信息分配了同等注意力。实践中普遍存在**“中间遗忘”（lost-in-the-middle）** 现象——位于超长输入中段的信息被回忆的概率明显低于开头和结尾。理解这一区别是理解ATLAS为何强调“跨长度评估”的前提：宣称1M窗口的模型，在1M处可能远不及一个宣称256K窗口但在其全范围内稳定的模型可靠。

ATLAS框架：三个方法论的突破

论文： ATLAS: All-round Testing of Long-context Abilities across Scales 作者： Deli Huang等 发表时间： 2026年5月27日

ATLAS针对传统长上下文评估的两个弱点展开研究：模型性能随输入长度增加而退化，以及基础任务（如检索）的成功未必能迁移到更复杂的应用负载。

其框架引入了三项关键改进。

跨上下文长度评估。 不只在单一输入规模上衡量性能，而是在8K到1M Token的预定义网格上取分。这让研究者能观察性能如何随信息量增加而变化——在128K上表现优异的模型，可能在更长长度上退化得比另一个模型更急剧。

基础能力与应用负载分离。 检索信息和正确应用信息是两种不同的能力。模型可能识别出仓库中的相关函数，却不理解它们如何交互。ATLAS明确区分了这两类操作。

平衡性聚合指标。 研究者提出ATLAScore，一种基于调和平均数的跨能力类别聚合分数，意在惩罚严重偏科的能力画像。一个在某项任务上碾压、却在其他任务上挣扎的模型，不应自动获得最强的整体评价。该框架在计算最终聚合分数时还引入了不确定性传播。

核心发现：领导者在一百万Token处发生更替

ATLAS最引人注目的发现关乎模型排名：

评估范围	领先模型
至128K Token	Gemini 3.1 Pro Preview
至1M Token	Claude Opus 4.6

这并不意味着Claude全面优于Gemini，也不意味着Gemini本质上不可靠。它意味着在ATLAS使用的特定评估条件下，相对排名发生了变化。

研究者还报告，当评估范围从8K–128K扩展到8K–1M时，有七个模型的排名变动至少两个名次。想象你只看了128K的评测结果就选定了模型，而你的生产环境经常处理600K Token的文档——你使用的基准可能根本不反映你的实际工况。

关键洞察：模型质量不是独立于上下文长度的常量。 有用的基准应该测量你的应用实际使用的范围。

为什么更长的上下文会改变问题难度

一个简化的例子可以说明问题。假设一个长仓库中包含以下信息：

service_a.py: Service A sends requests to Service B.
service_b.py: Service B uses Database C.
config.yaml: Database C has public network access enabled.
security_policy.md: Production databases must not expose public access.

现在问：“Service A是否间接依赖了一个网络配置可能不安全的数据库？”

正确回答需要多个步骤：识别Service A与Service B的依赖关系，找到Service B的数据库，定位Database C的配置，再将该配置与安全策略比对。没有任何一个句子包含完整答案。

随着上下文增长，模型需要在更多无关材料中识别相关信息，同时保持不同证据碎片之间的连接。这产生了多种可能的失败模式：遗漏某块必要证据、检索到相似但错误的细节、正确检索但错误连接、或产生一个看似合理但无来源支撑的结论。

这个例子是说明性的，不是ATLAS的测试用例。但它展示了为什么更长的上下文会增加难度——即使每份相关文档都在模型宣称的窗口内。

多跳推理（Multi-hop Reasoning） 指答案无法从单一位置直接读出、必须串联多个证据片段才能得出的任务。上文的Service A→Service B→Database C例子正是典型的多跳链条：每一跳都可能成为断点。在长上下文中，多跳推理还叠加了信息覆盖（Information Coverage） 与证据关联（Evidence Linking） 的双重负担——模型不仅要“看到”全部相关片段，还要在噪声干扰下保持它们之间的语义连接。注意力机制对远距离位置的权重会随距离衰减，因此即便所有证据都在窗口内，模型也可能在推理中途“丢失”前面已确认的环节。这解释了为什么检索类任务（单跳）的成功率远高于推理类任务（多跳），也解释了CorpusQA中全局聚合任务为何如此困难：它不是找一句话，而是要在千万Token上维持一个连贯的证据图。

CorpusQA的补充证据：当证据分散在整个语料库中

ATLAS跨模型和规模评估长上下文能力。另一项2026年研究CorpusQA则追问一个不同的问题：当证据分散在整个文档集合中时，AI系统能否分析整个集合？

论文： CorpusQA: A 10 Million Token Benchmark for Corpus-Level Analysis and Reasoning 作者： Zhiyuan Lu等 原始发表： 2026年1月21日，修订于2026年4月25日

CorpusQA包含金融、教育和房地产文档任务。有些问题需要从大量文档中聚合数值信息——比如分析数百份财务报告，找出所有满足多个会计条件的公司。传统检索系统可能找到几份相关文档，但如果回答问题需要分析每一家公司，只检索五份文档远远不够。

这是一个与“找到一段包含答案的文本”本质不同的问题。

已发表的结果

CorpusQA在多个上下文长度上评估了若干模型。对于Gemini 2.5 Pro：

上下文长度	整体准确率
128K	80.19%
1M	50.73%

在该研究的条件下，准确率下降了29.46个百分点。需要注意，CorpusQA评估的是Gemini 2.5 Pro，而非Gemini 3.1 Pro，因此其结果不能直接替代新模型的表现。但它说明了一个问题：即使模型支持极长输入，语料库级别的分析仍然非常困难。

该研究还发现，传统RAG在需要全局分散证据的任务上表现很差。在1M Token的CorpusQA评估中，标准RAG的准确率为17.38%，而使用Gemini 2.5 Pro的Memory Agent方法达到44.95%。

这并非说RAG无用，而是说检索几段相关文本块和分析整个文档集合是两回事。

传统RAG为什么在全局问题上失效

典型的RAG流程是：用户提问→向量搜索→Top-K相关块→LLM→生成答案。当一个问题可以用少量相关段落回答时（比如“API速率限制是多少？”），这套流程运作良好。

但换一个问题：“在过去一年的所有客户报告中，哪个故障类别的增长最多？”答案需要全局聚合。只检索语义最相似的文档可能会排除数据集的大部分。无论LLM多强大，它都无法正确聚合从未接收到的信息。

这是一个信息覆盖问题，不仅仅是语言模型问题。

对于需要精确聚合的问题，结构化处理流程可能更合适：文档集合→信息抽取→结构化记录→SQL/分析计算→证据验证→LLM生成解释。这种设计将事实计算与语言生成分离——LLM负责解读用户问题并解释结果，确定性代码负责计算。

当然，这种方法也有局限。抽取错误、Schema不完整、数据过时仍可能导致错误答案。但它创造了对单一步骤进行验证的机会，而不是依赖一个巨大的Prompt。

Top-K检索（Top-K Retrieval） 是RAG流程的核心步骤：将用户问题编码为向量，在向量数据库中检索语义相似度最高的K个文本块，通常K在3到20之间。这个机制隐含一个假设——答案集中分布在少数几段文本里。但当问题要求“对全集合做聚合”时，这个假设崩溃：语义相似度衡量的是“像不像”，而非“是否覆盖了计算所需的全部样本”。例如统计所有客户报告中的故障类别增长，需要的是完备集（所有报告），而向量搜索只会返回与“故障”“增长”语义最近的几段，绝大部分样本被排除在外。Memory Agent 这类方法试图缓解该问题：它让模型分块处理语料，把中间结论写入外部记忆，再对记忆做汇总，从而在不一次性吃下全部Token的前提下提高覆盖率，但仍受限于记忆的粒度与写入策略。

供应商基准需要谨慎解读

独立研究只是证据来源之一。模型开发者也会发布技术评估。Anthropic的Claude Opus 4.6系统卡讨论了MRCR和GraphWalks等长上下文基准。MRCR评估在长输入中定位和区分相似信息的能力，GraphWalks考察对上下文中图状结构信息的结构化推理。

这些评估有价值，因为测试了普通问答之外的能力。但开发者发布的基准结果需要仔细解读——不同提供商可能使用不同的推理设置、推理预算、输入限制、过滤规则或评估配置。在一个提供商设置下获得的基准分数，不应自动视为可与独立基准直接比较。

尤其是，用长Prompt回答问题不仅取决于模型权重，还取决于推理预算、工具使用、Prompt构造、上下文截断、采样配置、数据集过滤和评估指标——这些差异可能实质性影响观察到的结果。

MRCR（Multi-Round Co-reference Resolution） 和 GraphWalks 是Anthropic系统卡中使用的长上下文基准。MRCR测试模型在超长输入中定位并区分多个语义相似目标的能力——例如在一段充满相似代码片段的仓库里准确找到被多次引用的那个特定函数，它考验的是“分辨力”而非“记忆力”。GraphWalks则要求模型对上下文中以文本形式描述的图结构（节点与边）执行遍历、路径查找等操作，检验模型能否把线性排布的Token还原成图拓扑并进行结构化推理。推理预算（Reasoning Budget） 指模型被允许用于内部思考（如扩展推理链）的Token配额，不同提供商可设置不同上限。当推理预算、采样温度、工具可用性不一致时，同一模型在不同榜单上的分数可能相差悬殊，这正是“供应商基准不可直接与独立基准比较”的技术根源。

对AI编程助手的启示

考虑一个能访问大型仓库的AI编程助手，有两种设计思路。

方案A：把所有东西放进Prompt。 整个仓库→大上下文窗口→LLM响应。概念上简单，但可能昂贵，且引入大量无关信息。它也不保证模型能正确连接所有重要细节。

方案B：搜索、检查、验证。 用户提问→仓库搜索→相关文件→依赖分析→LLM推理→工具验证→最终答案。这种方法可以使用搜索工具、静态分析、测试和定向上下文检索。对于某些软件工程任务，这些工具可能提供比简单扩展Prompt更可靠的证据。

核心原则是：把上下文窗口当作工程系统中的一个资源，而不是系统本身的替代品。

如何为现代AI模型设计基准测试

基于已发表的结果，可以提出一个面向真实开发工作流的实用评估方案，从四个维度测试每个模型。

测试A：上下文长度。 在8K、32K、128K、256K、512K、1M上评估同一任务族，只包含每个被测模型和API配置真正支持的长度。

测试B：证据位置。 将答案相关信息放在输入的开头、中间和结尾，测量准确率是否变化。

测试C：推理复杂度。 使用多个难度级别：L1检索一个显式陈述的事实；L2连接来自两个文件的信息；L3整合来自多个文档的证据；L4对整个语料库执行全局分析。

测试D：工具辅助推理。 对比直接长上下文Prompt与使用检索、代码执行或其他验证工具的工作流。

每个实验记录：答案准确率、上下文长度、输入/输出Token数、延迟、成本、证据完整性。模型版本和推理设置应固定并文档化，任务应使用多个独立样本重复，并报告不确定性估计。

局限与谨慎解读

有几点需要注意。ATLAS是2026年5月的预印本，其结果是有用的研究证据，但不应被视为普遍接受的模型排名。比较覆盖的是特定的26个模型集合和评估设置，不确立2026年后续发布的所有模型的性能。CorpusQA评估的是不同的模型和任务，其数值结果不能与ATLAS分数直接比较。1M Token处的性能可能涉及推理设置和上下文处理等实现特定约束。最后，基准结果不自动预测真实世界表现——回答法律问题、写代码、分析科学论文或处理财务记录，可能需要非常不同的能力。

结语：我们需要比“多少Token”更好的问题

上下文窗口的快速增长是一项重要的技术成就。但2026年的研究讲述了一个更复杂的故事。ATLAS发现当评估延伸到一百万Token时模型排名会变化。CorpusQA展示了当相关证据分散在众多来源中时，分析大型文档集合的困难。

对开发者而言，实际启示很直接：不要仅凭宣传的上下文大小选择LLM。 在你应用实际使用的长度上评估它。分别测试检索和推理。衡量证据的质量，而不只是生成答案的流畅度。并考虑结构化工具、检索系统或确定性计算是否能让你的应用更可靠。

长上下文AI的未来可能不在于把所有东西塞进一个Prompt，而在于构建知道该检索什么、该记住什么、该计算什么、该验证什么的系统。

一百万Token的上下文窗口是一种能力。在一百万Token上进行可靠推理是另一种成就。

参考文献

[1] ATLAS — All-round Testing of Long-context Abilities across Scales (2026). Deli Huang et al. https://arxiv.org/abs/2605.28079

[2] CorpusQA — A 10 Million Token Benchmark for Corpus-Level Analysis and Reasoning (2026). Zhiyuan Lu et al. https://arxiv.org/abs/2601.14952

[3] Claude Opus 4.6 System Card (2026). Anthropic. https://www.anthropic.com/system-cards