模型原理与推理
Gemini 1.5 Pro 的 1M 上下文意味着什么：长上下文没有自动终结 RAG
以 2024 年 2 月 15 日至 17 日资料为边界，拆解 Gemini 1.5 Pro 有限预览、MoE 与长上下文信号，并用大型代码库问答任务判断长上下文和 RAG 的成本边界。
时间与证据
本文研究的是 Google 在 2024 年 2 月 15 日公布 Gemini 1.5 Pro，并向有限开发者与企业客户提供最高 1M token 的实验预览。同期信息边界截止到 2 月 17 日。标准上下文是 128K，1M 是受限实验窗口；后来出现的 2M 上下文、Gemini 1.5 Flash、正式价格与更广泛地区可用性都不属于这次事件。
事实依据是 Google 的发布公告、与其目标完全匹配的发布日快照，以及 Google DeepMind 同日公开的技术报告和报告快照。报告中的 Benchmark、needle-in-a-haystack 与长文档结果均为官方研究结果，本文没有在相同模型快照和硬件条件下复现。
证据等级是 sourced。我能确认发布性质、官方架构说明和报告的方法，但不能把厂商实验等同于自己的生产数据。尤其不能从“模型能接收 1M token”直接推出“任意百万 token 内容都能被可靠理解”，输入容量、信息召回、答案正确性与业务可用性是四个不同指标。
当时发生了什么
Gemini 1.5 Pro 同时释放了两个工程信号。第一，Google 报告它采用 Mixture-of-Experts 架构：并非每次推理都激活全部专家，而是由路由机制选择部分网络参与计算。第二，实验上下文窗口扩大到 1M token，使长视频、长音频、大量代码和文档可以在一次请求的上下文中被处理。
MoE 不应被简化为“参数多但免费”。稀疏激活可能降低每 token 的有效计算量，但权重存储、专家路由、跨设备通信、批处理和服务调度仍决定真实吞吐。外部开发者只看到产品配额与延迟，无法从“MoE”三个字推导自己的单位成本。因此本文把它视为架构解释，不把它写成已验证的成本结论。
长上下文同样需要拆层。容量层回答“请求能否装下”；定位层回答“模型能否找到相关片段”；推理层回答“能否结合多个片段正确回答”；产品层还要考虑首 token 延迟、输入计费、缓存、权限和敏感信息。官方技术报告展示了超长上下文实验，这是强烈的研究信号，但它不是任何企业语料上都成立的服务承诺。
当时最常见的过度结论是“RAG 已经没用了”。这个推论缺少任务前提。RAG 不只为了解决窗口不够，还承担访问控制、增量更新、来源定位、数据删除、成本控制和可观察性。长上下文扩大了直接阅读候选，但没有自动消除这些系统责任。
任务判断
假设一支 40 人的软件团队要建立代码库迁移助手。仓库包含前后端、基础设施、历史 ADR、工单导出和 API 文档，总量可以放进 1M token 的实验窗口。目标不是聊天，而是回答：“将旧鉴权中间件迁移到新网关会影响哪些入口？请给出文件与依据。”
直接把整库塞入一次请求看似省去向量库，却会遇到四个问题：每次输入重复造成的成本与延迟；大量测试、生成文件和旧版本产生干扰；不同工程师不应看到相同目录；答案难以确认引用究竟来自哪个版本。相反，纯 RAG 若切分或召回失败，也可能错过跨目录依赖。
同期合理方案不是二选一，而是设计三条可比较基线：
- 整库长上下文：固定同一仓库快照，将允许访问的内容按稳定顺序输入。
- 检索增强：关键词与向量检索召回有限片段，再由模型回答。
- 分层混合：先按仓库图谱、权限和文件类型缩小到一个子树，再把较完整子树放入长上下文。
评测集必须由真实迁移问题构成，并提前保存“必要证据文件集合”。核心指标是证据召回率、带文件定位的答案正确率、拒答正确率、端到端延迟、每个正确答案成本和越权暴露数。不能只让另一个模型判断文字是否顺滑。
可证伪边界是：若整库方案在相同权限、固定快照和问题集上持续取得更高任务正确率，且其延迟与成本低于混合方案，就可以在该仓库采用；若随着仓库增长成本线性上升、旧代码干扰增加或权限无法隔离，RAG/过滤仍有必要。结论只对该语料分布与模型快照成立。
工程影响
长上下文把“检索系统”升级成“上下文编译器”。输入不应由随意拼接完成，而要有清单、顺序、预算和来源映射：
interface ContextManifestItem {
uri: string;
revision: string;
contentHash: string;
accessDecisionId: string;
tokenEstimate: number;
selectedBy: "direct" | "keyword" | "vector" | "dependency-graph";
}
每次回答保存 manifest，才能复现“模型当时看到了什么”。数据库经验在这里映射为知识版本与权限快照；API 经验映射为模型网关与预算控制；测试经验映射为固定问题集和证据级断言。
系统架构可拆为四层：权限过滤先排除用户不可见内容；候选选择在 token 预算内组织资料；模型调用使用固定快照并输出结构化引用；验证层检查引用文件确实出现在 manifest 中。模型不能用自己没有读取的路径装作证据，工具层应拒绝这类引用。
成本不能只看输出 token：
每个正确答案成本
= 输入 token 与缓存未命中
+ 输出 token
+ 检索、索引和存储
+ 等待时间折算
+ 人工验证与错误处置
长上下文可能减少索引系统复杂度，也可能因重复输入放大成本。若供应商支持可复用上下文缓存，命中率会改变结论；若文档频繁变化，缓存失效又会削弱收益。工程决策必须记录工作负载，而不是只引用窗口上限。
还要设计“上下文降级”。超过预算时不能静默截断尾部，而应根据依赖图、文档版本和问题类型重排；缺少必要证据时输出 insufficient_context，而不是编造完整答案。对大型代码库，随机或固定从头截断会系统性遗漏后置目录。
商业价值
愿意付费的客户包括代码迁移、法务审阅、投研检索、客服知识和工业维护团队。长上下文增强的是一次任务能共同考虑的材料范围，可能减少人工拆文档和多轮搬运上下文的时间。价值不在“窗口数字最大”，而在复杂任务是否减少检索遗漏与上下文切换。
收益成立的条件是：问题确实需要跨越大量材料；输入可以合法地交给模型；高价值答案足以覆盖推理和验证成本；模型能给出可追溯证据。短 FAQ、强权限隔离的多租户库、高频更新且答案只依赖少量片段的任务，通常不该为百万 token 输入付费。
可积累的护城河是任务问题集、证据标注、权限策略、上下文编译规则和成本日志，而非单个供应商窗口。模型或价格变化后，同一评测可以重新决定“整库、RAG、混合”路由。未来 6 至 12 个月的预测只有在长输入的任务正确率、延迟和缓存经济性同时满足门槛时成立；若长上下文产生更多干扰或验证成本没有下降，它只能成为候选路径。
局限与风险
第一，官方长上下文实验的样本与企业语料不同，needle 检索也不等同于复杂推理。第二，1M 是有限预览，不代表所有开发者当日都能获得。第三，MoE 的内部细节和服务基础设施并未开放到足以独立核算，不能由论文参数直接推算 API 成本。
第四，整库输入扩大数据泄露面。权限过滤必须发生在模型调用之前，不能指望提示词阻止模型引用已经看到的秘密。第五，长回答可能带有看似精确但错误的文件引用，必须通过程序验证 revision 和哈希。
本文没有运行 Gemini 1.5 Pro 的历史快照，也没有产生任何对比结果。文中的三基线、指标和架构属于实验设计；只有在固定数据集、模型、权限和原始输出后，才可以升级为复现结论。
面试表达
30 秒版本： Gemini 1.5 Pro 在 2024 年 2 月把 1M 长上下文带入有限实验预览，但标准窗口是 128K，不能倒灌后来的 2M 或 Flash。我的判断是长上下文扩大了整库阅读候选，却没有终结 RAG，因为权限、增量更新、来源定位和成本仍存在。我会用整库、RAG、分层混合三条基线，以证据召回和每个正确答案成本选路由。
追问版本： 如果问“为什么不把所有代码直接塞进去”，我会说明容量不等于定位和推理，完整输入还可能引入旧代码干扰。上下文 manifest 会固定文件 revision、哈希和权限决策；输出引用必须属于 manifest。若真实评测证明整库更准更便宜，我会采用，而不是教条式保留向量库。
复盘
这次事件改变的不是某个固定架构，而是选型问题的变量空间。过去窗口太小，检索几乎是必选；长上下文出现后，“直接、检索、混合”都需要用任务数据比较。全栈工程师的优势在于能把权限、缓存、版本、延迟和审计一并放进模型评测，而不是只讨论 token 上限。
同期可以确认的是有限预览与官方研究结果；不能确认的是任何企业库上的稳定收益。后续窗口和价格变化应作为新证据重新评测，不能修改 2024 年 2 月的开放范围。
方法披露
本文使用 AI 工具协助整理同期公告、构造对照实验问题与草拟原理图；作者核验日期、来源、限定语和最终判断。没有把官方报告改写成本站实测。
修订记录
2024-02-17：初版发布；固定 2024-02-15 至 2024-02-17 的有限预览边界，明确 1M 实验窗口、128K 标准上下文和“长上下文不自动替代 RAG”的可证伪任务判断。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论