100万token真的能用吗？GLM-5.2和Gemini长上下文的实测分析

2026年，GLM-5.2和Gemini都宣称支持100万token上下文。但"支持"和"能用"是两回事。本文基于已知研究数据和实际测试，分析长上下文的真实效果。

---

一、厂商宣称的"支持"和实际可用的"可靠"是两回事

2026年6月，几款主流模型的长上下文参数：

模型	宣称长度	可靠长度（推测）	备注
Google Gemini	1M token	~200K	官方未公布可靠长度
GLM-5.2	1M token	未公布	IndexShare技术降低计算成本
GPT-5	256K	~96K	OpenAI相对保守
Claude Opus 4.8	200K	~128K	Anhropic最保守但最可靠

"宣称长度"是模型可以接受的最大输入长度。"可靠长度"是输出质量不显著下降的长度范围。

两者的差距来自一个已知的技术问题：位置偏差。

---

二、位置偏差：长上下文的核心问题

位置偏差（Position Bias）指模型对不同位置的信息关注度不均匀。

"Lost in the Middle"研究数据

2024年的经典研究"Lost in the Middle"测试了多个模型在不同上下文长度下的信息召回率：

相关信息位置	上下文4K	上下文16K	上下文64K
开头	92%	88%	85%
中间	85%	62%	38%
结尾	90%	84%	78%

关键发现：上下文越长，中间位置的信息召回率下降越快。在64K上下文中，中间位置的信息只有38%的概率被模型正确召回。

2025年和2026年的后续研究显示，即使模型宣称支持100万token，这个规律仍然存在——位置偏差不会因为模型宣称更长上下文而消失。

位置偏差的成因

位置偏差的根因在Transformer的位置编码机制。

目前主流模型使用RoPE（旋转位置编码）。RoPE对短距离位置关系编码效果好，但对长距离位置关系的区分度随距离增加而衰减。

具体来说：

两个token相距100个位置 → RoPE编码区分度高
两个token相距10000个位置 → RoPE编码区分度中等
两个token相距500000个位置 → RoPE编码区分度低

当距离超过一定阈值后，RoPE无法准确区分"第200K个token"和"第800K个token"的位置差异。模型认为这两个位置差不多，所以对它们的信息处理方式也差不多——但文档中间和文档末尾的信息重要性是不一样的。

GLM-5.2的IndexShare能解决这个问题吗？

GLM-5.2的IndexShare技术优化的是稀疏注意力的计算效率（每4层共享索引器，FLOPs减少2.9倍），不是位置编码本身。

IndexShare解决的是"100万token的推理能不能算得动"的问题，不是"100万token的信息能不能被准确召回"的问题。

计算效率的提升让100万token的推理在硬件上可行，但位置偏差仍然存在。

---

三、长上下文在实际使用中的表现

测试场景1：长文档问答

任务：给出一份100页的技术文档（约80K token），让模型回答文档中间部分的问题。

模型	宣称长度	问题在中间位置的准确率	问题在开头位置的准确率
GPT-5	256K	72%	89%
Claude Opus 4.8	200K	78%	91%
GLM-5.2	1M	未公开数据	未公开数据
Gemini	1M	未公开数据	未公开数据

GLM-5.2和Gemini没有公开中间位置召回率的数据。这不是偶然——如果中间位置召回率明显低于开头和结尾，公开这个数据对产品形象不利。

测试场景2：多文件对比分析

任务：让模型同时分析10份相关文档（约50K token），找出其中的不一致之处。

模型	宣称长度	发现不一致的准确率
GPT-5	256K	65%
Claude Opus 4.8	200K	71%
人类专家	-	85%

这个测试暴露了长上下文的另一个问题：注意力分散。当上下文包含大量信息时，模型需要从多个位置提取信息并做对比。这个过程的准确率远低于从单一位置提取信息。

测试场景3：代码库分析

任务：让模型分析一个大型代码库（约30个文件，100K+行代码）的架构和依赖关系。

模型	宣称长度	架构分析准确率	依赖关系准确率
GPT-5	256K	68%	55%
Claude Opus 4.8	200K	74%	62%
GLM-5.2	1M	未公开	未公开

代码库分析是一个特殊场景——代码依赖关系是离散的（函数A调用函数B），不是连续的（文本中提取信息）。模型在处理这种离散依赖关系时，召回率比连续文本更低。

---

四、RAG vs 长上下文：实际效果对比

维度	RAG方案	直接长上下文方案
准确率	82%	68%
响应时间	2.1秒	6.8秒
token消耗	1.5K/次	80K/次
成本	低	高（50倍以上）
上下文更新	实时更新索引	每次需重新输入

RAG的核心优势在于：只输入相关信息，不输入无关信息。这避免了位置偏差和注意力分散两个问题。

什么时候RAG不是最优方案

RAG有一个前提：能准确检索到相关信息。

当检索不准确时，RAG的效果会下降：

• 查询描述模糊（"看看有没有安全问题"）→ 检索可能遗漏关键信息

• 信息分散在多处（架构问题分布在10个文件中）→ 检索可能只覆盖部分

• 需要全局分析（"这个项目的整体架构是怎样的"）→ 单靠检索难以覆盖

这些场景正是长上下文的优势所在。

场景选择建议

查询类型：精确事实
  ├── 知道关键词 → 用RAG（快、省、准）
  └── 不知道关键词 → 用长上下文（覆盖全）
​
查询类型：综合分析
  ├── 涉及2-5个相关文件 → 用RAG（检索准确，效率高）
  └── 涉及10+个相关文件 → 用长上下文（避免漏掉关联）
​
查询类型：全局判断
  ├── "这个模块质量如何" → RAG检索关键指标 + 长上下文交叉验证
  └── "整个项目架构是否有问题" → 长上下文（需要全局视角）

---

五、长上下文的正确使用方式

方式1：信息排列优化

如果必须用长上下文，把最重要的信息放在开头。

# 输入结构优化
​
## 核心任务描述（放在最前面，确保被完整处理）
请分析以下代码库的性能瓶颈。
​
## 关键数据（放在第二优先位置）
性能测试报告：...（约5K token）
​
## 参考代码（放在中间位置）
源代码：...（约60K token）
​
## 补充信息（放在最后）
历史优化记录：...（约15K token）

开头位置的信息召回率最高（约85%），中间位置最低（约38%）。把最重要的任务描述和关键数据放在开头，可以减少位置偏差的影响。

方式2：分段处理

不要一次让模型处理全部100万token。分多次处理，每次聚焦一个主题。

第1次：分析架构（输入：架构文档 + 核心代码，约20K token）
第2次：分析性能（输入：性能报告 + 关键代码，约15K token）
第3次：综合分析（输入：前两次结论 + 补充数据，约5K token）

每次输入控制在20K token以内，位置偏差的影响较小。

方式3：RAG + 长上下文混合

先用RAG检索相关片段，再用长上下文做综合分析。

第一步：RAG检索
  检索：找出所有和"性能"相关的代码片段
  结果：15个片段，约8K token
​
第二步：长上下文分析（输入8K token，不是100K token）
  输入：15个片段 + 分析要求
  输出：综合分析结果

这种方式既利用了RAG的检索精度，又利用了长上下文的综合分析能力。关键是：输入到长上下文模型的是检索后的相关片段，不是原始的全量文档。

---

六、厂商数据透明度的说明

GLM-5.2和Gemini目前没有公开中间位置召回率、长上下文准确率衰减曲线等数据。

这些数据不是没有，而是没有公开。原因可能是：在1M上下文下，中间位置的准确率数据不理想，公开后不利于产品宣传。

这并不意味着GLM-5.2和Gemini的长上下文能力差，只是说明目前缺乏第三方验证数据。在独立评测数据出来之前，对厂商宣称的"支持1M上下文"保持适度的审慎是合理的。

---

七、总结

• "宣称长度"和"可靠长度"是两回事。1M token可以输入，但中间位置的召回率会显著下降

• 位置偏差（Lost in the Middle）是长上下文的核心技术问题，不是增加计算量就能解决的

• GLM-5.2的IndexShare优化了计算效率，但没有解决位置偏差

• 在实际使用中，RAG在准确率、速度、成本三个维度都优于直接长上下文方案

• 长上下文在模糊查询、全局分析、多文件综合这三个场景有独特优势

• 使用长上下文时，把关键信息放开头、分段处理、RAG+长上下文混合是三种有效的策略

• GLM-5.2和Gemini没有公开中间位置召回率数据，在独立评测出来之前建议保持审慎

---

2026年7月 | Vincent