Google 发布 Gemini 1.5 Pro：百万 token 上下文窗口是什么概念

2024 年 2 月 15 日，Google 发布新一代模型家族 Gemini 1.5，距离 Gemini 1.0 正式发布不到三个月。这次发布的重点是首发旗舰版本 Gemini 1.5 Pro，采用了与前代不同的 Mixture-of-Experts（专家混合，简称 MoE）架构——这种架构让模型在推理时只启动部分“专家”子网络来处理特定任务，而不是每次都调用整个模型，从而在保持甚至提升性能的同时，大幅降低训练与算力成本。根据 Google 公布的基准测试，Gemini 1.5 Pro 在多数评测项目上已经超越前代的 1.0 Pro，性能表现接近当时 Google 阵容中最强大的 1.0 Ultra。

但这次发布真正引发业界关注的，并不是基准分数的提升，而是“上下文窗口”的规格。Gemini 1.5 Pro 可以稳定处理长达 100 万 token 的输入内容——换算成实际素材，大约等于一小时的视频、11 小时的音频，或是超过 3 万行代码、逾 70 万字的文本文件。这个数字在当时是业界公开发布过的最长上下文窗口，远超同期 GPT-4 Turbo 的 12.8 万 token，也超越 Claude 2.1 的 20 万 token。目前 Gemini 1.5 Pro 尚未全面开放，而是先以有限预览（limited preview）形式，通过 Google AI Studio 与 Vertex AI 提供给开发者与企业客户申请试用。

技术意义：为什么“上下文长度”是关键指标

过去大型语言模型受限于上下文窗口大小，处理长文档或长视频时，往往需要先把内容切成片段、分批喂给模型，再自行拼接回答，这个过程容易遗漏片段之间的关联信息。100 万 token 级别的上下文窗口，代表模型可以一次“读完”一整份长篇合同、一整场会议录像，甚至一整套代码库，并在其中准确定位特定细节——Google 在发布时展示的其中一个测试，是要求模型在近 70 万字的文本中找出一句被刻意藏入的特定句子，模型准确找到并回答。这种能力被称为“长上下文检索”（needle-in-a-haystack），是评估超长上下文模型是否真的“读进去了”而不是“随便应付”的重要指标。

与前代及竞品的对比

相较于 Gemini 1.0，1.5 Pro 不只是上下文变长，MoE 架构本身也代表训练效率的路线转变——用更少的算力资源达到接近旗舰模型的效果。相较于同期竞品，OpenAI 的 GPT-4 Turbo 上下文为 12.8 万 token、Anthropic 的 Claude 2.1 为 20 万 token，Gemini 1.5 Pro 的 100 万 token 是数倍到近十倍的差距，等于把“模型能一次处理多少内容”这个赛道直接拉开一个量级。不过这也只是有限预览阶段的规格展示，实际大规模开放后的稳定性、延迟与费用，仍待后续观察。

业界反应

发布后，开发者社区与科技媒体的讨论焦点集中在“超长上下文是否会取代 RAG（检索增强生成）架构”——如果模型能直接吞下整个知识库，还需要额外做向量检索、切片索引这些工程吗？多数评论认为两者短期内会并存：超长上下文适合处理单一大型文档或音视频素材的深度分析，RAG 则仍适合面对持续更新、规模远超百万 token 的知识库。这也让 Gemini 1.5 Pro 被视为 Google 在“长文档理解”这个应用场景上，向 OpenAI 与 Anthropic 抛出的一记重拳。

对管理者的意义

对管理者而言，这则新闻的重点不在于技术架构，而在于一个具体可能性：未来把一整份年度合同、一整场董事会录像或一整套内部规章，直接交给 AI 一次读完并回答问题，不再需要事先拆解摘要，理论上已经可行。企业导入前仍需留意公开预览阶段的稳定性与数据安全考量，但这意味着“文档审阅”“会议记录整理”这类高工时任务，未来有机会被大幅压缩。