⚡ 站長快讀:核心重點
- 文章屬性:觀念解析 / 規格解析(AI 教學)
- 核心結論:Context Window 是 AI 的「短期記憶上限」,以 token 計算;塞爆就會忘記前文,但塞好塞滿也不代表更聰明。
- 適用對象:用 ChatGPT / Claude / Gemini 會遇到「怎麼講一講就失憶」、想搞懂 token 計價的人。
📌 快速答案
一句話答案:Context Window(上下文視窗)是語言模型一次能「讀進去」的文字上限,用 token 計算;對話、附檔、模型的回應全都占用同一個額度,一旦超過,最舊的內容就會被擠掉,AI 就「忘記」前文了。
🔍 故事的起點:AI 為什麼講到後面就「失憶」?
你大概遇過:跟 ChatGPT 聊了半天,交代好的設定、貼過的資料,講到後面它突然像沒看過一樣,重複問你已經講過的東西。很多人第一反應是「這 AI 變笨了」,其實不是——它撞到了 Context Window(上下文視窗) 的天花板。
Context Window 是理解 2026 年這一代 AI 最關鍵、卻最常被跳過的一個概念。搞懂它,你才會知道:為什麼長對話會失憶、為什麼同樣一段話用中文問比較「貴」、為什麼把整本 PDF 丟進去有時反而找不到重點,以及為什麼「context window 越大」不等於「越好用」。這篇站長就用白話,把上下文視窗與 token 這兩個綁在一起的概念一次拆給你看。
🧪 原理拆解:上下文視窗與 token 到底是什麼
Context Window 是什麼:AI 的「短期記憶」,不是硬碟
先講定義。Anthropic 官方文件把 context window 描述成模型的「working memory(工作記憶)」——它指的是模型產生這次回應時,能夠參照的全部文字,而且連模型自己正在生成的回應也算在內。Google 的 Gemini 官方文件用了更好懂的比喻:context window 就像人的短期記憶,能暫存的資訊量有限。
這裡要先打破一個常見誤會:context window 不是模型「學過的知識」。模型訓練時吃過的海量資料,是它的長期記憶(內化成參數);而 context window 是這一次對話的「臨時桌面」,你這回合放上去多少,它才看得到多少。關掉對話重開,桌面就清空了。
而且這張桌面上放的東西比你想的多。根據 Anthropic 官方說明,會占用 context window 的包括:系統提示(system prompt)、你和 AI 的每一輪對話、貼進去的附件與圖片、工具定義,以及模型輸出的回應本身(連它「思考」的過程都算)。這也是為什麼你只是想問個小問題,額度卻消耗得莫名其妙——因為前面所有東西都還躺在桌上。
Token 是什麼:不是「字」,也不是「詞」
Context window 的單位不是字數,而是 token。這是新手最容易卡住的地方。
根據 OpenAI 官方說明,token 是「文字被切開後的碎片」,可能是一個完整單字,也可能是子詞(sub-word)、甚至含前面的空格。模型在處理你的輸入前,會先把文字切成一連串 token。幾個官方給的英文換算基準值得記起來:
| 換算(英文) | 大約值 |
|---|---|
| 1 token | 約 4 個英文字元 |
| 1 token | 約 ¾ 個英文單字 |
| 100 tokens | 約 75 個英文單字 |
| 1,500 個英文單字 | 約 2,048 tokens |
舉個 OpenAI 官方的例子:名言「You miss 100% of the shots you don’t take」這句話,是 11 個 token。看得出來 token 的切法跟「單字數」並不一致——標點、空格、數字都會各自吃掉 token。
💡 為什麼要用 token 而不是字數? 因為模型內部根本不是一個字一個字讀,而是把文字對照一張「詞彙表」換成數字編號來運算。token 就是這張表的最小單位,計價、限額也全都以它為準。
中文為什麼比較「吃」token?破除兩個迷思
這是台灣使用者最有感、卻最多誤解的一段。先講結論:中文確實傾向比英文吃更多 token,但差距沒有你想的那麼誇張,而且這幾年已經大幅縮小。
OpenAI 官方就明講:token 的切法跟語言有關,非英文語言的「token 對字元比」通常更高,用起來也更貴。它舉的例子是西班牙文的「Cómo estás」——10 個字元卻要 5 個 token(英文平均 4 個字元才 1 個 token)。
那中文呢?關鍵在 tokenizer(分詞器)的世代。OpenAI 在 GPT-4o 發表時公布過一張官方對照表,拿同一句自我介紹在新舊 tokenizer 下比較:
| 語言 | 新 tokenizer(GPT-4o)改善 | token 數變化 |
|---|---|---|
| 中文 | 少 1.4 倍 | 34 → 24 |
| 日文 | 少 1.4 倍 | 37 → 26 |
| 韓文 | 少 1.7 倍 | 45 → 27 |
| 英文 | 少 1.1 倍 | 27 → 24 |
看懂這張表,兩個迷思就破了:
迷思一:「用 AI 處理中文超吃 token、超不划算。」 這在早期(GPT-3、初代 GPT-4 的 tokenizer)確實比較明顯,但新一代 tokenizer 已經大幅優化中日韓文。上表裡那句自我介紹,中文在 GPT-4o 的分詞器下從 34 token 降到 24 token,跟英文的 24 token 幾乎打平。
迷思二:「一個中文字剛好一個 token,所以中文其實比英文省。」 這也不對。常見字或許接近一個 token,但生僻字、罕用詞會被拆成 2~3 個位元組層級(byte-level)的 token;而英文一個 token 平均塞得下約 4 個字元(等於好幾個字母)。逐「字元」比是一回事,逐「同等資訊量」比又是另一回事——整體而言,表達同樣一段意思,中文的 token 數通常仍略高於英文,只是差距已經從早年的一大截,縮小到沒那麼痛了。
實務上的意義是:如果你在意 API 成本,別再用「字數」估價,要用 token;而且拿舊模型的印象套到 2026 的新模型上,往往會高估中文的成本。
為什麼 AI 會「忘記」前文?
回到最一開始的痛點。當一段對話越拉越長,所有輪次的內容持續往 context window 裡堆,總有一刻會塞到上限。
這時候會發生什麼,要看你用的是 API 還是聊天介面。根據 Anthropic 官方文件:若是直接呼叫 API,輸入一旦超過上限,會直接回報錯誤(400,「prompt is too long」);而像 claude.ai、ChatGPT 這類聊天介面,則多半採「先進先出(FIFO)」的滾動方式,把最舊的對話默默丟掉,好把空間讓給新的。
被丟掉的那部分,模型就真的看不到了——這就是「失憶」的真相。它不是變笨,是你早先講的話已經滑出了它的短期記憶。理解這點,你就會知道重要的設定要適時再貼一次,而不是假設它「應該還記得」。
塞好塞滿不等於更聰明:Context Rot 與「迷失在中間」
既然 context window 越做越大(下面會講到已經來到百萬 token 級),那把資料整包塞好塞滿,是不是就穩了?恰恰相反。
Anthropic 官方直接點名一個現象叫「context rot(脈絡腐化)」:隨著 token 數增加,模型的準確度與回想能力會衰退——所以「context 裡放了什麼」跟「還剩多少空間」一樣重要。Google 的 Gemini 文件也坦承,在「大海撈針」測試中,找單一一根針可以做到約 99% 準確,但要同時撈多根針時,表現就會明顯下滑。
學術上更早就有經典發現。Stanford 團隊 2023 年的論文〈Lost in the Middle〉指出:模型對放在開頭和結尾的資訊記得最牢,一旦關鍵內容被埋在超長脈絡的中間,準確度會顯著掉下去;而且脈絡越長,整體表現越差——連號稱長脈絡的模型也一樣。
所以「把整本手冊貼上去讓 AI 自己找」這招,不見得比「只給它最相關的三段」聰明。這也是為什麼有一整套技術(例如 RAG 檢索增強生成)專門在做「先幫模型篩出真正相關的內容,再放進有限的 context window」——context window 是上限,RAG 則是想辦法在上限內塞進最對的東西,兩者是互補的。
Context Window 越大越好嗎?延遲與成本的代價
2026 年的 context window 有多大?回顧一下演進:Google 官方文件寫道,早期模型一次只能處理 8,000 token,後來推進到 32,000、128,000,而百萬 token 級是這兩年才普及的量級——1,000,000 token 大約等於 5 萬行程式碼、或 8 本一般長度的英文小說。以目前(2026-07)官方公布的現況為例:Anthropic 的 Claude 旗艦機種(如 Opus 4.8、Sonnet 5)為 1M token、部分機種為 200K;Google Gemini 也提供 1M 以上。(以上規格請以各家官方最新公告為準,型號與數字更新很快。)
但「更大」是有代價的,而且是雙重的:
- 更花錢。 context window 裡的每一個 token,每一回合都會被重新當成輸入計費。對話越長、貼的資料越多,每問一句都在為前面那一大坨重複付費。想省錢,可善用各家的「快取(prompt/context caching)」機制,讓重複的前綴不必每次全額重算。
- 更慢。 Google 官方也說明,輸入越長,延遲(尤其是「吐出第一個字」的時間)通常越高。原理上,模型每生成一個新字,都要回頭參照前面全部 token,而這份「臨時筆記」(KV cache)會隨脈絡長度線性膨脹、吃掉記憶體與頻寬——這也是 本地 LLM 餵長脈絡會明顯變慢的主因之一。
💡 總結:實務上怎麼跟 Context Window 相處
站長我把這幾年用各家模型的心得,濃縮成幾個可以馬上用的原則:
- 重要的東西講在最後。 Google 官方 FAQ 直接建議:長脈絡下,把你的問題/指令放在整段內容的最後面,模型表現會更好。對照〈Lost in the Middle〉的發現(頭尾記得牢、中間容易漏),這招很合理。
- 別把 context window 當硬碟。 它是短期記憶,不是儲存空間。與其把十份文件整包倒進去賭它自己找得到,不如先篩出最相關的段落——需要規模化就上 RAG。這跟你把 prompt 寫清楚是同一件事的兩面:給對的、給精的,勝過給多的。
- 長對話定期「重講重點」。 既然聊天介面會默默丟掉最舊的內容,關鍵設定、規格、決策,隔一陣子就重貼一次,別假設它還記得。
- 算成本用 token,不要用字數;而且用新模型的行情估。 中文吃 token 的舊印象,在 2026 的新 tokenizer 上多半已經被高估了。
一句話收尾:context window 決定 AI 一次「看得到多少」,token 決定「怎麼算」;真正的高手不是把視窗塞爆,而是懂得在有限的視窗裡,只放最該放的東西。
❓ 常見問題
Q:Context Window 和模型的「記憶功能」是同一回事嗎?
不是。Context window 是單次對話的短期記憶上限,關掉重開就沒了。有些產品另外做了跨對話的「記憶(memory)」功能,那是把你的偏好額外存起來、下次再撈回來塞進 context window,屬於產品層的加值設計,和 context window 本身是兩件事。
Q:1M token 的 context window,是不是就能把整套百科全書丟進去問?
技術上塞得下,但不代表問得準。如同內文提到的 context rot 與「迷失在中間」,資料越多、埋越深,模型漏看的機率越高,而且每次都要為這一大包重複付費、等更久。與其硬塞,不如先篩選相關內容再餵。
Q:為什麼我用中文,token 消耗好像特別快?
中文相對英文確實傾向多用一些 token,因為中文沒有空格分詞、又有大量字元。但差距在新一代 tokenizer(如 GPT-4o 的 o200k)已大幅縮小,別再用舊模型的印象去估算 2026 的成本。真的要精算,用各家官方的 tokenizer 工具或 token 計算 API 實際跑一次最準。
Q:怎麼知道我這次對話用了多少 token?
各家官方都有工具:OpenAI 有線上 Tokenizer 網頁工具,Anthropic 提供 token 計算 API,Google Gemini 也有 count tokens 的方法。API 的每次回應通常也會在 usage 欄位回報這次用掉多少。
🔗 延伸閱讀
- MoE 混合專家是什麼?為何 235B 模型只算 22B、卻還是很吃 VRAM
- 本地 LLM 模型怎麼選?7B/70B、Q4/Q8 量化與 VRAM 一次搞懂
- LM Studio 完整教學:不打指令,在 Windows 本地跑 LLM
- Mac 跑本地 LLM 記憶體怎麼挑?Apple Silicon 統一記憶體與 M4/M5 選購全解析
📎 參考資料來源
📖 第一級|廠商官方:
- Anthropic — Context windows(官方文件) — 2026-07-08 查證
- OpenAI — What are tokens and how to count them(官方說明) — 2026-07-08 查證
- OpenAI — Hello GPT-4o(官方發表,含各語言 tokenizer 對照表) — 2026-07-08 查證
- Google — Long context(Gemini API 官方文件) — 2026-07-08 查證
📖 第二級|學術研究:
- Liu et al. 2023 — Lost in the Middle: How Language Models Use Long Contexts(arXiv:2307.03172) — 2026-07-08 查證
⚠️ 本文核心事實以第一級官方為準,token 數字均引自 OpenAI 官方公布之範例(非站長實測);第二級學術研究為長脈絡衰退現象之補充佐證。
📅 本文查證戳記:2026-07-08 依據各家官方文件與 GPT-4o tokenizer 官方對照表撰寫。context window 規格與型號更新快,若你在後續版本看到數字變動,以官方公告為準,也歡迎在留言區回報。