Gemini 3.1 Pro 支持 100 万 token 的上下文窗口，是目前公开模型中最大的。Google 在宣传里说 Gemini 3.1 Pro 解决了"迷失在中间"问题，检索准确率接近 100%。
我翻了 Model Card 的实测数据之后，对这个说法打了个大问号。
"迷失在中间"是怎么回事
2023 年斯坦福和加州大学伯克利的研究者发了一篇论文叫 "Lost in the Middle"，实验发现一个规律：当上下文变得很长时，语言模型对文档中间部分的内容记忆质量明显下降，开头和结尾的内容反而记得牢。
他们用的测试方法后来被叫做 Needle In A Haystack——在一大段文本里随机插入一条关键信息（"针"），然后问模型这条信息的内容，看模型能不能准确找到并复述。
这个测试揭示了一个根本性问题：上下文窗口大不等于模型真的"理解"了窗口里的所有内容。100 万 token 的窗口可能只是"看过"而不是"记住"。
Gemini 3.1 Pro 的实测数据
Model Card 里用了一个更严格的测试叫 MRCR v2（Multi-Range Context Recall），8 针版本。和 Needle In A Haystack 的区别是，MRCR 同时在文档里藏了 8 条信息，分布在不同位置，模型需要同时找到全部 8 条。这比找一根针难很多。
结果分两档：
128k 上下文：
| 模型 | MRCR v2 (128k, 平均) |
|---|---|
| Gemini 3.1 Pro | 84.9% |
| Claude Opus 4.6 | 84.0% |
| GPT-5.2 | 83.8% |
128k 窗口下三家基本持平，差距在误差范围内。这说明在"中等长度"上下文里，当前顶级模型的信息召回能力已经收敛了，谁也不比谁强多少。
100 万 token 上下文：
| 模型 | MRCR v2 (1M, pointwise) |
|---|---|
| Gemini 3.1 Pro | 26.3% |
| Gemini 3 Pro | 26.3% |
| Claude Opus 4.6 | 不支持 |
| GPT-5.2 | 不支持 |
26.3%。这个数字和宣传里的"接近 100% 检索准确率"差距太大了。
这里需要做一个说明：MRCR v2 的 1M 测试用的是 pointwise 评估，是单点精确召回，和 Needle In A Haystack 单针测试的设定不完全一样。Google 宣传里提到的"接近 100%"有可能是基于单针测试的结果——只藏一根针要比同时藏 8 根针简单很多。
但即便打了折扣，26.3% 的 8 针精确召回率也说明：在 100 万 token 的窗口里准确找到分散在各处的信息，Gemini 3.1 Pro 目前做不好。
更让人注意的是：Gemini 3 Pro 的 1M pointwise 也是 26.3%，一模一样。3.1 Pro 这次升级在超长上下文召回上零改进。升级的重点去了推理能力，长上下文检索没有被优先处理。
那 100 万 token 窗口有什么用
既然精确检索不靠谱，为什么还要用这么大的窗口？因为"精确检索"只是长上下文的一种使用方式，其他几种使用方式对召回精度的要求没那么高。
全局摘要和理解。 让模型读完一整份 500 页的技术报告然后写一个摘要，或者分析一个代码仓库的整体架构。这类任务不需要模型准确定位到某一个段落，只需要对整体内容有把握。长上下文在这里比分段送+手动拼接要好，因为模型能看到所有段落之间的关系。
代码仓库分析。 把整个仓库的代码丢进去，让模型分析依赖关系、找出潜在的设计问题、或者理解某个功能的实现路径。这类任务的要求是"理解全局结构"而不是"找到第 1247 行定义的那个变量"（后者你直接搜索就行了）。
多轮长对话。 100 万 token 大约可以装下几百轮中等长度的对话。这意味着会话历史不需要频繁截断，模型可以记住你在对话早期提到的需求和偏好。对做客服机器人、编程助手这类需要长期记忆的应用来说，窗口大小是有实际意义的。
不适合的场景。 最常见的误用是把长上下文当向量数据库的替代品——把几十万字的文档库整个塞进 prompt，然后问一个很具体的问题。26.3% 的多针召回率告诉你这条路走不通。这类场景用 RAG（Retrieval-Augmented Generation，先用向量检索找到相关段落，再送给模型）仍然是更可靠的方案。
128k 就够用了吗
对大多数生产场景来说，可能真的够了。
一个 128k 的上下文窗口大约能放下：一本 200 页左右的书，或者一个中等规模的代码仓库（约 5-8 万行代码），或者 100 轮左右的长对话。84.9% 的多针召回率虽然不算完美，但比 26.3% 高了太多。
真正需要 100 万 token 窗口的场景，比如让模型同时处理一个超大型代码仓库（几十万行），或者同时阅读十几篇论文做交叉比对。这类任务确实存在，但不是大多数人的日常需求。
输出上限和成本
输入可以塞 100 万 token，输出上限是 64K token。这意味着如果你让模型读完一本书然后写一份非常详细的分析报告，报告长度不能超过 64K token（大约 5 万中文字）。超出的部分需要分批处理。
成本上，输入 token 按 2。加上推理 token（MEDIUM 模式下可能有 5000-8000 token）和输出 token，一次完整请求的成本大约在 2.5 之间。
如果每天跑 100 次百万 token 的输入，一天就是 6000-7500。这个数字不小，决定用 100 万 token 窗口之前建议算清楚 ROI。
我的判断
100 万 token 的上下文窗口是一个很好的技术指标，但对大多数人来说，实际可用价值集中在"全局理解"而非"精确检索"。如果你的需求是后者，RAG 依然是更好的选择。
Google 宣传里的"接近 100% 检索准确率"大概率是基于单针测试的结果。多针场景下 26.3% 的数字更接近你在生产环境里会遇到的情况。
下一代模型如果能把 1M 窗口下的多针召回率提到 60%+ 以上，长上下文才真正有可能替代 RAG。目前还没到那个程度。
