百万 token 的上下文窗口，Gemini 3.1 Pro 真的解决了「越长越烂」的问题吗
Gemini 3.1 Pro 支持 100 万 token 的输入上下文。官方宣传说解决了"迷失在中间"（Lost in the Middle）问题，100 万 token 下检索准确率接近 100%。听起来很厉害，不过我把 Model Card 里的实测数据翻了一遍，结论要打些折扣。
"迷失在中间"指的是什么
这个问题其实在 2023 年就被学术界提出来了：当上下文很长时，语言模型对文档中间部分的内容记忆明显差于开头和结尾。换句话说，你塞了 50 万字，模型可能认真读了第 1 章和最后一章，中间的部分基本忘了。
针对这个问题，研究者设计了一类叫做"Needle In A Haystack"的测试：把一条关键信息藏在超长文本的某个位置，看模型能不能找到。
Gemini 3.1 Pro 的实测数据
Model Card 里用的是 MRCR v2（Multi-Range Context Recall，8 针测试），结果分两档：
- 128k context（平均）：Gemini 3.1 Pro 84.9%，Claude Opus 4.6 84.0%，GPT-5.2 83.8%。几乎持平，没什么明显差异。
- 1M context（单点测试）：Gemini 3.1 Pro 26.3%，Gemini 3 Pro 也是 26.3%，Claude 和 GPT 不支持。
26.3%。这个数字和"接近 100% 检索准确率"的宣传明显对不上。注意这里的测试方法是"pointwise"，是单点精确检索，不是整体理解任务，所以不能直接跟 Needle In A Haystack 单针测试对比。但不管怎么算，在 100 万 token 的窗口里准确召回信息，目前确实还是个难题。
Gemini 3.1 Pro 的 1M 性能和 Gemini 3 Pro 一模一样（都是 26.3%），说明这次升级并没有在超长上下文召回上带来改进。
什么场景用百万 token 是有意义的
单纯的信息检索在超长上下文下并不靠谱，但有几个场景用长上下文确实有实际价值：
整体理解任务。 让模型总结一份 500 页的技术报告，或者分析整个代码仓库的架构，不要求精确定位某条信息，只是要理解全局。这类任务长上下文通常比分段送效果好。
代码仓库分析。 Gemini 3.1 Pro 支持直接输入整个代码仓库，这对做依赖关系分析、全局代码重构建议是有用的。但你要问它"第 1247 行的这个变量是在哪里定义的"，不如直接搜索。
多轮长对话。 会话历史不用频繁截断，对话上下文完整保留。100 万 token 大约可以装下几百轮长对话。
不太适合的场景。 把一个几十万字的知识库塞进去，希望模型像数据库一样精确检索，MRCR 26.3% 的召回率告诉你这条路走不通。RAG 在这类场景下仍然更可靠。
一个值得注意的限制
Model Card 里提到，64K token 是输出上限。输入可以 100 万 token，但输出最多 64K。如果你的任务是让模型把一本书处理完之后输出很长的结果，超过 64K 的部分就需要分批处理了。
最后一个问题我还没想清楚：100 万 token 的上下文在 Vertex AI 上跑一次要多少钱？按 $2/百万输入 token 算，满负荷跑一次输入就是 $2，加上输出再算一笔。频繁使用的话成本积累会很快。这个留到定价那篇细说。
参考资料
- Gemini 3.1 Pro Model Card（MRCR v2 测试结果），Google DeepMind：https://deepmind.google/models/model-cards/gemini-3-1-pro/
- Gemini 3.1 Pro Technical Deep Dive，n1n.ai：https://explore.n1n.ai/blog/gemini-3-1-pro-technical-deep-dive-performance-2026-02-20
- Gemini 3.1 Pro on Vertex AI 官方文档，Google Cloud：https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-1-pro
- Gemini 3.1 Pro Long-Context Analysis，Medium（Sebastian Buzdugan）：https://medium.com/@sebuzdugan/gemini-3-1-pro-deep-think-long-context-that-actually-thinks-5bba76e65b1d