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 成本，並不是所有團隊都承受得起的。這套玩法看起來更適合作為深度的架構分析器或離線排錯工具，短期內要完全取代輕量級檢索方案，恐怕在成本和延遲上都還要再算一筆細賬。