Google 与 Sourcegraph 实测：Gemini 百万上下文让 Cody 幻觉率砍半

如果你接手过一个几十万行代码的陈年老项目，一定体会过那种绝望：改动一行，不知道会在哪个隐蔽角落炸雷，想问 AI，常规模型的上下文窗口又根本塞不下几个文件。

Google 和代码智能工具 Cody 的母公司 Sourcegraph 最近做了一组测试，他们把整整 100 万 token 的上下文窗口直接喂给了 Gemini 1.5 Flash，试图看看把整个代码库一股脑倒给大模型后，AI 到底能不能真正读懂复杂的代码逻辑。

幻觉砍掉快一半，但等第一个字曾要半分钟

Sourcegraph 挑选了一批非常刁钻的技术问答题，专门考验模型对大型代码库底层依赖的理解能力，以此对比 100 万长上下文版本与 Cody 现有生产环境版本的差异。

测试结果相当直观。在核心召回率、核心简洁度和实用度三个关键基准指标上，长上下文版本都拿到了明显更高的分数。

更实在的改变是幻觉问题。代码问答里最怕 AI 信口胡诌不存在的 API 或内部函数，在引入 100 万 token 上下文后，AI 的整体幻觉率直接从 18.97% 跌到了 10.48%。

不过，长上下文并不是免费的午餐，最大的痛点在于速度。首字生成时间会随着上下文长度呈线性增长，在 1MB 大小的上下文下，早期测试中开发者提个问题得干等 30 到 40 秒，才能看到 AI 蹦出第一个字符。

为了解决这个延迟硬伤，Sourcegraph 配合模型执行状态缓存搞了一套预抓取机制，以及分层的上下文模型架构。在 Gemini 1.5 Flash 和 Pro 的配合下，他们最终把首字响应时间压到了 5 秒左右。

为什么重要

长期以来，行业里对代码助手的做法普遍是 RAG，也就是先检索一小段相关代码再拼进提示词里。但复杂工程里的依赖链条犬牙交错，单纯靠检索召回很容易遗漏关键逻辑，导致 AI 频繁产生幻觉。

Sourcegraph 这次给出的数据证明了暴力塞入超长上下文的实际价值。幻觉率从接近两成直接砍半，这意味着对于在大型复杂仓库里排查问题的高级工程师来说，AI 终于从添乱的初级实习生，变成了稍微可以放心的参考助手。

但我们认为，这项方案目前依然有不低的工程隐患。即使首字响应从 40 秒优化到了 5 秒，在代码编写这种对实时交互要求极高的场景里，5 秒的停顿依然会让很多习惯了自动补全顺滑感的开发者感到烦躁。

而且，模型执行状态缓存和超长上下文的 token 成本，并不是所有团队都承受得起的。这套玩法看起来更适合作为深度的架构分析器或离线排错工具，短期内要完全取代轻量级检索方案，恐怕在成本和延迟上都还要再算一笔细账。