Gemini 3.5 Pro 帶 200 萬 token 脈絡逼近 GA：超長脈絡到底在哪些場景才真的有用

Google 的 Gemini 3.5 Pro 帶 200 萬 token 脈絡與 Deep Think 推理逼近正式發布，是目前量產前沿模型裡最長的脈絡視窗。但長脈絡不是「把整包資料倒進去就贏」。它真正划算的落地場景只有幾類：單一長文件的整體理解、整包程式碼的跨檔推理、長時程 agent 的記憶。其餘像知識庫問答這種要精準檢索又要引用出處的活，用 RAG（檢索增強生成）或混合架構通常更省、也更準。選錯場景，你付的是 20 萬 token 以上的長脈絡加價，換來的卻是資訊埋在中段就失憶的風險。

先把事件講清楚。Gemini 3.5 Pro 在 Google I/O 亮相後，GA 時程從六月延到七月，到七月初仍在 Vertex AI 的企業預覽名單制階段。官方確認的規格是 200 萬 token 脈絡，是 Gemini 3.5 Flash 的兩倍，也是任何量產前沿模型裡最大的，外加一個用延遲換準確度的 Deep Think 推理模式。要注意的是，Google 到現在還沒公布官方定價；根據企業預覽流出的估算，標準脈絡（20 萬 token 以下）輸入約每百萬 token 12 到 15 美元，超過 20 萬的長脈絡段還要再往上加。這個「加價區」等一下會變成台灣團隊算帳的關鍵。

這裡要先踩一個剎車：廣告上的脈絡長度，不等於你真的用得到的脈絡。這不是猜的，是有基準打臉的。輝達團隊做的 RULER 基準把長脈絡任務從「大海撈針」擴到多跳推理、實體追蹤這些更接近真實工作的題型，結論很直白：這些模型雖然都宣稱支援 32K 以上脈絡，能在 32K 長度維持像樣表現的只有一半。連號稱 200K 脈絡的模型，隨著輸入變長、任務變難，表現都明顯掉。宣稱的脈絡上限，跟實際能可靠工作的長度，是兩個不同的數字。

衰退還有一個位置問題。史丹佛團隊那篇 Lost in the Middle 講得很清楚：模型抓資訊，放在開頭或結尾表現最好，一旦關鍵資訊埋在中段，表現會明顯掉下去。這件事的殺傷力在於，真實工作幾乎都是「多針」的，一個問題的答案要跨好幾段材料拼起來，不是找一根針就結束。你把 100 份文件全倒進 200 萬 token 的視窗，模型很可能把夾在中間第 47 份裡的關鍵句讀漏。Databricks 的長脈絡實測也對上這個現象：不同模型開始衰退的長度不一樣，有的過了 32K、有的過了 64K 就掉，而且多數模型在塞到最滿時反而比中等長度表現更差。愈長不等於愈好。

那長脈絡到底在哪些場景真的有用？我把它收斂成三類，共同點是「這件事本來就沒辦法切成小塊各自處理」：

• 單一長文件的整體理解。 一份幾百頁的合約、財報、研究報告或病歷，你要問的是跨越全篇的問題，例如「這份合約前後有沒有互相矛盾的條款」。這種問題切成小段各自檢索反而會漏掉關聯，把整份餵進去讓模型一次看完才對。
• 整包程式碼的跨檔推理。 要模型理解一個橫跨幾十個檔案的專案、做跨檔重構或追一條穿過多層的呼叫鏈時，關鍵在檔案之間的關係，不是單一函式。這是長脈絡少數能大幅省掉工程麻煩的場景。
• 長時程 agent 的記憶。 agent 跑一長串多步驟任務，要記得前面幾十步做過什麼、拿到什麼結果，這種連續脈絡本來就難用外部檢索硬切。

反過來，有一整類場景把長脈絡當萬靈丹其實是解錯題。最典型的是知識庫問答：客服要從幾萬篇文件裡找答案、內部文件系統要回答員工問題。這種活的本質是「精準找到那幾段相關內容」，不是「一次讀完全部」。把整個知識庫塞進脈絡，你付了長脈絡的加價、扛了中段失憶的風險，還拿不到明確的引用出處，反而不如先用 RAG 檢索出最相關的幾段再交給模型。Databricks 那篇的結論也是這個方向：長脈絡跟 RAG 是互補、不是取代，「長脈絡會取代 RAG」這個說法還撐不起來。現在做得好的團隊多半走混合：先用檢索把材料壓縮到最相關的一小撮，再丟進長脈絡做跨材料推理，順便把最強的證據排到開頭跟結尾，避開中段失憶。

那台灣團隊該怎麼讀這條新聞？別因為 200 萬 token 這個數字很亮就急著把系統改成「什麼都倒進去」。先分清楚你要解的是哪一類任務：是要跨全篇理解一份長文件、還是要從一大堆文件裡找答案。前者長脈絡值得，後者 RAG 或混合更划算。成本這關尤其要算：長脈絡在 20 萬 token 以上是加價區，一個高頻呼叫的產品，把整包資料每次都塞滿，帳單會很有感。這跟我先前寫模型分層對開發者的差別、以及先定義問題再選工具的順序是同一條線：決定性的從來不是規格表上哪個數字最大，而是你有沒有先把任務類型、資料供給跟驗證機制想清楚。200 萬 token 給了你一個更大的工具，但工具對不對得上題目，還是要你自己先定義題目。

常見問題

長脈絡視窗是不是可以取代 RAG 了？
還不行。Databricks 的長脈絡實測指出兩者是互補而非取代，多數模型塞到最滿時表現反而比中等長度更差。要精準檢索又要引用出處的知識庫問答，用 RAG 先把材料壓縮到最相關的幾段，通常比整包倒進脈絡更省也更準。

模型宣稱支援 200 萬 token，是不是整段都能可靠使用？
不一定。RULER 基準發現宣稱 32K 以上脈絡的模型，只有一半能在 32K 維持像樣表現。廣告上的脈絡上限跟實際能可靠工作的長度是兩個數字，長度愈長、任務愈複雜，可靠度就愈往下掉。

什麼是 lost in the middle？會怎麼影響我？
指模型對放在脈絡開頭與結尾的資訊抓得好、埋在中段的容易讀漏，這是史丹佛團隊在 Lost in the Middle 提出的現象。真實任務多半要跨多段材料拼答案，如果把大量文件全倒進去，夾在中間的關鍵內容就有被忽略的風險。

哪些情況真的該用長脈絡？
三類：要跨全篇理解的單一長文件（合約、財報、病歷）、要跨檔推理的整包程式碼、要記住多步驟過程的長時程 agent。共同點是這件事本來就沒辦法切成小塊各自處理。反之像客服知識庫這種「找出那幾段」的活，用檢索或混合架構更合適。

用長脈絡會比較貴嗎？
會，尤其超過門檻之後。以 Gemini 3.5 Pro 的預覽估算，20 萬 token 以下輸入約每百萬 token 12 到 15 美元，超過 20 萬的長脈絡段還要再加價（官方定價尚未公布）。高頻呼叫又每次塞滿脈絡的產品，成本會明顯放大，先算清楚再決定要不要塞滿。