200萬token上下文，第一次讓「整包貼」變成真選項
過去談到「要餵一大堆文件給AI」，答案幾乎都是同一個：先建RAG（檢索增強生成）。因為模型一次能讀的內容有上限，你得先把文件切塊、做索引，每次提問時只撈出最相關的幾段丟進去。
這件事正在鬆動。市場流出的消息指出，重新打造的 Gemini 3.5 Pro 預計搭載 200 萬 token 的上下文視窗，可在單一工作階段處理大幅擴增的文字、程式碼與資料量 [Source: https://www.inside.com.tw/article/41814-gemini-3-5-pro-rumors-roundup]。這是什麼概念？粗略換算，200萬token大約能容納好幾本書的量。對一人公司或自由工作者來說，這第一次讓「不建RAG、直接把整包資料貼進去問」成為一個實際可行的選項。
問題來了：整包貼真的比較準、比較省事嗎？還是說RAG那套工還是得做？下面用三個維度拆給你看，最後也給已經建過RAG的人一段進階選型——如果你完全沒碰過技術細節，看完決策表就夠用了，進階那段可以放心跳過。
整包貼 vs 建RAG，白話版
先把兩條路講清楚：
- 整包貼：把你手上的合約、產品文件、會議記錄……全部貼進對話框，然後直接問。不用切塊、不用建索引，開箱即用。
- 建RAG：先把文件處理成可檢索的資料庫，每次提問時系統自動撈出最相關的片段，只把那幾段餵給模型。
直覺上整包貼贏在「懶人友善」，RAG贏在「精準省錢」。但實際上沒這麼單純，關鍵在三欄：準確度、延遲、花多少錢。
三欄對照：準確度、延遲、成本
準確度：長不等於準
上下文能塞200萬token，不代表模型對每個角落都一樣專注。長上下文有個常被忽略的風險：內容越長，模型越容易漏掉夾在中間的細節——你問的東西明明貼進去了，它卻答得含糊或直接漏答。這也是為什麼實務上的選型指南，對高頻、需要精準命中的檢索場景，仍傾向用RAG搭配快取，而不是無腦把整包塞進上下文；同一份指南也點出，RAG撈回來的片段形狀差異很大，這正是長上下文品質難以一概而論的原因之一 [Source: https://www.nxcode.io/resources/news/gemini-3-5-flash-vs-3-1-pro-when-to-use-which-2026]。
還有一個容易被忽略的訊號：這波 3.5 Pro 之所以砍掉原本的基礎模型重新預訓練，外媒引述的原因是原架構在多步驟數學推理與 SVG 場景生成上遇到效能天花板 [Source: https://www.inside.com.tw/article/41814-gemini-3-5-pro-rumors-roundup]。換句話說，把上下文從一百萬推到兩百萬，補的是「塞得下」，未必等於「推理更準」——對需要多步推理的檢索問答，長度不是萬靈丹。
一句話：文件不大、問題聚焦時，整包貼夠準；文件很雜、要反覆精準定位某個條款或數字時，RAG的命中率通常更穩。
延遲：每次都重讀一整包，等待感很真實
整包貼的代價之一是速度。你每問一次，模型原則上就要重新「看過」整包內容一遍。文件越大，回應前的等待越明顯。RAG因為每次只餵進撈出來的少數片段，回應通常更輕快。對「一天要問幾十次」的高頻工作流，這個差距會累積成明顯的體感落差。
成本：整包貼是「每問一次付一次」
這欄最容易踩雷。整包貼的隱形成本是——你每問一次，就等於把整包內容重新送一次，重複付一次input的錢。問十次，就送十次。RAG因為只送撈出來的片段，單次輸入量小很多。
模型本身的價差也值得算一筆。有選型指南以「同一任務輸出100萬token」估算：用 Gemini 3.1 Pro 約 $12、用 3.5 Flash 只要 $9 [Source: https://maplefeather.com/article/gemini-model-guide-2026]。同一份文件裡也提到，作者日常大約八成的工作是交給較便宜的 Flash 在扛——寫初稿、整理重點、改一般程式、回較長的問題 [Source: https://maplefeather.com/article/gemini-model-guide-2026]。換句話說，很多人以為需要頂規Pro＋整包貼，實際上便宜模型＋精準檢索就能解決大半。
一張決策表：你到底該貼還是該檢索
不用背理論，用三個問題對照就好：
| 你的情況 | 建議做法 |
|---|---|
| 文件量小（一兩份、幾十頁）、問完就走 | 直接整包貼，別為了一次性任務去建RAG |
| 文件中等、但只問一兩次 | 整包貼，省下建索引的工 |
| 文件很多、很雜，要反覆精準定位某段 | 建RAG，命中率與一致性更穩 |
| 同一批文件天天問、一天問很多次 | 建RAG＋快取，否則重複付input的成本會失控 |
| 需要的答案容不下「漏答」（合約、法遵、財務） | RAG為主，長上下文只當輔助交叉比對 |
簡單原則：一次性、小份量 → 貼；高頻、大份量、要精準 → 檢索。 別因為「模型塞得下」就預設整包貼是最佳解，塞得下不等於划算、也不等於最準。
看到這裡，決策其實已經夠用了。接下來這段是進階，寫給已經自己切過塊、調過chunk、跑過eval的人；如果那些名詞對你很陌生，直接跳到後面的「貼敏感檔前的三件事」完全不會漏掉重點。
給已經建過RAG的人：三個容易被低估的判斷點
如果你已經動手做過RAG，那「貼 vs RAG」這個二選一其實太粗。有三個更細的判斷點值得放進你的決策，每點後面都附一句白話結論：
選型是二維的：模型級別 × 要不要檢索。 別把問題壓縮成「Pro＋整包貼」對「Flash＋RAG」。有選型指南指出，作者日常大約八成的活是交給較便宜的 Flash，而 Flash 一樣帶 1M 上下文，還有「思考」能力 [Source: https://maplefeather.com/article/gemini-model-guide-2026]。所以真正要選的是「Flash vs Pro」和「貼 vs 檢索」兩個開關，而且很多工作負載不管走哪條檢索路線，落點都是 Flash。
白話：先把「用哪個模型」選對，常常比糾結「貼不貼」更省錢。
快取會改寫「每問一次付一次」的算式。 整包貼的成本痛點是重複付input，但對高頻RAG這個工作負載，選型指南給的結論不是「一律再多做檢索」，而是「Flash＋積極快取」，並具體點名「每天上萬次查詢、帶著固定的 3k-token 系統提示」這種場景 [Source: https://www.nxcode.io/resources/news/gemini-3-5-flash-vs-3-1-pro-when-to-use-which-2026]。快取吃掉的是靜態部分（固定系統提示、穩定的文件語料），所以當語料夠穩定時，重複查詢的邊際成本會被壓下來。
白話：語料越穩定，快取越省，RAG純粹的成本優勢也跟著縮小——這時要比的是「維護索引」跟「開快取」哪個工程成本低。
照工作負載選，而不是照「文件多大」選。 有一份按工作負載逐一分析的指南，圍繞五種真實場景給建議：MCP代理、工具密集型工作流程、200頁文件檢索、高頻RAG、ARC風格推理 [Source: https://we0.ai/zh-HK/articles/article-1780312880183]。重點在於：「200頁一次性檢索」和「高頻RAG迴圈」是兩種完全不同的動物——前者常常整包貼就夠、根本不值得養一套索引；後者才是索引＋快取＋eval這套工程真正回本的地方。
白話：先問「這是哪一種工作負載」，比問「文件多大」更能決定該不該建RAG。
貼敏感檔前，一定要想清楚的三件事
整包貼最大的陷阱不在技術，在於「一鍵貼上」太方便，人容易把不該貼的東西也貼進去。動手前先過這三關：
這份檔案裡有沒有你不想外流的東西？ 客戶名單、未公開財務、含個資的表格、API金鑰、內部路徑……貼進去前先問自己：如果這段內容外流，我承受得起嗎？承受不起就先遮蔽或抽掉。
這家服務怎麼處理你貼進去的資料？ 是否會用於訓練、保存多久、有沒有企業版的資料不留存選項——這些在貼之前就要確認，而不是貼完才後悔。
能不能用「去識別化」版本代替？ 很多時候你要的是模型幫你分析結構、抓重點，並不需要真名真數字。把敏感欄位換成代號再貼，往往一樣能得到你要的答案，風險卻低很多。
結論：把「塞得下」跟「該塞」分開想
200萬token上下文確實改變了遊戲——它讓「不建RAG、整包貼」第一次成為一人公司能認真考慮的選項。但它解決的是「塞不塞得下」，沒有解決「準不準、快不快、划不划算」。
給你一句能帶走的判斷：一次性、小份量的活，整包貼最省事；高頻、大份量、答案不容出錯的活，該做的檢索還是得做。 便宜模型配上精準檢索，往往比頂規模型配整包貼更聰明；而對已經建過RAG的人，真正的槓桿是先分清工作負載、把模型級別和快取這兩件事調對。至於敏感檔——方便從來不該蓋過安全，貼之前多想三十秒，可能就省下一場麻煩。
更完整的模型能力與開發者視角，可參考 Gemini 3.5 開發者指南 [Source: https://www.developersdigest.tech/blog/gemini-3-5-pro-developer-guide-2026]。