快速回答：Context Window 是什麼？

Context Window（上下文視窗）是 AI 語言模型一次能「看到」的最大文字量。你可以把它想成 AI 的「短期記憶容量」——在一次對話中，AI 能同時處理的所有文字（包括你的提問、它的回答、和之前的對話歷史）加起來不能超過這個上限。

這個上限的計算單位是 Token（詞元），不是字數。一個英文單字大約是 1-2 個 token，一個中文字大約是 1-3 個 token（取決於模型的 tokenizer 設計）。

當對話的 token 總量超過 context window，AI 就必須「遺忘」最早的一部分對話內容。這就是為什麼長對話到後面 AI 會「忘記」前面講過的事情。

Context Window 的正式定義

Context window 是 Transformer 架構語言模型在一次前向傳播（forward pass）中能處理的最大 token 序列長度。這個限制來自模型訓練時設定的位置編碼（positional encoding）長度和注意力機制（attention mechanism）的設計。

模型的 context window 在訓練完成後就固定了。不過近年的技術（如 RoPE 外推、Sliding Window Attention、YaRN）允許在推理時擴展到比訓練時更長的 context，但超出訓練範圍太多的部分效果會下降。

白話解釋

想像你在讀一本書，但你一次只能看到書的 N 頁。N 就是你的 context window。

如果 N = 10，你一次能看到 10 頁的內容。當你翻到第 11 頁，第 1 頁就會從你的視野中消失。你仍然可以繼續閱讀，但你已經看不到最早的內容了。

AI 的情況也是如此。它沒有真正的「長期記憶」，每次回答都是根據 context window 裡目前看得到的所有內容來思考的。

為什麼 AI 會「失憶」？

這個問題有兩個層面：

硬性限制：token 上限

當對話內容超過 context window 的 token 上限時，最早的部分會被截斷。這是物理性的限制——超過的部分真的從 AI 的處理範圍中消失了，AI 完全「看不到」那些內容。

在 API 使用中，你會收到一個 token 超限的錯誤；在 ChatGPT 等介面中，應用程式會自動把較早的對話歷史移除以保持在上限內。

軟性限制：注意力稀釋

即使在 context window 範圍內，AI 對距離很遠的資訊的「注意力」也會降低。這被稱為「lost in the middle」現象——如果你在 context 的開頭和結尾放重要資訊，AI 比較容易注意到；但如果重要資訊在中間的某個位置，AI 可能會「忽略」它。

研究顯示，在 100K token 的 context 中，放在位置 40K-60K 之間的事實，被 AI 正確引用的機率明顯低於放在開頭或結尾的相同事實。

這意味著：即使模型的 context window 號稱 200K 或 1M，實際上能有效利用的容量會小於理論值。

主流模型 Context Window 比較

模型 Context Window 大約等於
GPT-4o 128K tokens 約 300 頁英文文件
Claude Sonnet 5 200K tokens 約 500 頁英文文件
Gemini 2.5 Pro 1M tokens 約 2,500 頁英文文件
Llama 3.1 405B 128K tokens 約 300 頁英文文件
Mistral Large 128K tokens 約 300 頁英文文件
GPT-4 (2023 初版) 8K tokens 約 20 頁英文文件

Context window 的大小在過去兩年快速成長。2023 年初的 GPT-4 只有 8K，一年後就升到 128K。Google 的 Gemini 更是直接推到 1M。但更大不一定更好——實際的應用效果要看模型在長 context 下的「召回準確率」，不只是能放多少 token 進去。

上表的「大約等於」是以英文為基準估算的。中文的 token 效率通常比英文差（同樣的語意需要更多 token），所以同樣的 context window 能放入的中文內容會比英文少 30-50%。

Token 與中文的關係

英文的 Token

英文的 tokenization 相對直觀。常見的英文單字通常是 1 個 token，較長或不常見的單字可能被拆成 2-3 個 subword token。

例如： - "hello" → 1 token - "unhappiness" → 可能被拆成 "un" + "happi" + "ness" = 3 tokens - 空格和標點符號通常不獨立佔 token，而是被合併到相鄰的 token 中

中文的 Token

中文的 tokenization 比較複雜，而且不同模型的差異很大。

以 GPT-4o 的 tokenizer 為例：一個常見的中文字大約佔 1-2 個 token，不常見的字（例如罕用字、專業術語）可能佔 2-3 個 token。中文標點符號（「、」、。）也會佔 token。

這表示同樣的內容，中文版本通常比英文版本消耗多 30-50% 的 token。在規劃 context window 的使用時需要考慮這個差距。

實際影響

假設你想把一份中文技術文件塞進 context：

一份 A4 大小、單欄、12pt 字體的中文文件，每頁大約 800 個中文字，大約對應 1,000-1,600 個 token。

GPT-4o 的 128K context window，能容納大約 80-128 頁的中文文件。聽起來很多，但如果你的對話已經進行了一段時間，之前的對話歷史也會佔用 context window，實際可用的空間會更少。

管理 Context Window 的實用技巧

把重要資訊放在開頭或結尾

因為「lost in the middle」現象，如果你需要 AI 注意某段特定內容，放在 prompt 的開頭或結尾效果最好。例如在做長文件分析時，把你的問題和關鍵指令放在最後面。

摘要分段策略

如果你的文件超過 context window，不要直接截斷（AI 會遺漏後面的內容）。比較好的做法是：

Map-Reduce 策略。把文件分成多段，分別讓 AI 產生每段的摘要，最後把所有摘要合併起來讓 AI 做最終分析。

滑動視窗策略。把文件分成重疊的區塊（例如每區塊 50K token，相鄰區塊重疊 5K token），分別處理後合併結果。重疊的部分確保跨區塊的資訊不會遺漏。

精簡 System Prompt

System prompt 也會佔用 context window。如果你的 system prompt 有 2,000 token，而你的 context window 是 8K，那每次對話其實只剩 6K 可用。把 system prompt 精簡到只包含必要的指令，或考慮使用有更大 context window 的模型。

控制對話長度

如果你在和 AI 進行長對話，定期「重新開始」新的對話可以避免重要資訊被推出 context window。開始新對話時，把前一輪對話的重要結論帶過來即可。

Prompt Caching

有些 API 提供 prompt caching 功能（例如 Anthropic 的 prompt caching），如果你的 context 中有大量不變的內容（像是長文件、system prompt），可以利用 caching 降低延遲和成本，但不會改變 context window 的大小限制。

Context Window 和成本的關係

使用 AI API 時，費用通常是按 token 計算的。context window 越大，每次請求送出的 token 越多，費用也越高。

例如 GPT-4o 的定價是每百萬 input token $2.5 美元。如果你每次請求都送了 100K token 的 context，每次請求的 input 成本就是 $0.25。如果你的應用每天有 1,000 次這樣的請求，每天的 input 費用就是 $250，一個月 $7,500。

所以雖然 context window 很大很方便，但不代表你應該每次都塞滿。精準地選擇要放進 context 的內容，不只是為了效果，也是為了成本控制。

Context Window 和 RAG 的關係

RAG（Retrieval-Augmented Generation）的核心概念就是：與其把所有文件塞進 context window，不如用搜尋技術先找出和問題最相關的幾段內容，只把這些放進 context。

例如你有一份 1,000 頁的技術手冊，使用者問了一個關於「如何設定 SSL 憑證」的問題。RAG 系統會先用向量搜尋或關鍵字搜尋，從這 1,000 頁中找出最相關的 3-5 段（可能共 2,000 token），只把這些放進 context window，而不是把整份手冊都塞進去。

這個做法的好處：節省 token 費用、減少「lost in the middle」問題、加快回應速度（送出的 token 越少，回應越快）。

壞處：如果搜尋沒有找到正確的段落，AI 就沒有足夠的資訊回答問題。RAG 系統的品質取決於搜尋（retrieval）的準確度。

Context Window 的未來趨勢

Context window 正在快速擴大。從 2023 年的 8K 到 2026 年的 1M+，成長了超過 100 倍。有些研究方向正在嘗試「無限 context」——讓模型能處理任意長度的輸入，透過壓縮、分層注意力等技術繞過固定長度的限制。

但更大的 context window 不代表 RAG 會被淘汰。即使 context window 可以放下整份文件，把整份文件塞進去仍然有成本和延遲的代價，而且 lost in the middle 問題在超長 context 中更嚴重。RAG 的角色從「必須要做」轉向「效率優化」。

安全考量

Context window 的使用也有安全面向需要注意。

間接 Prompt Injection 的風險。如果你把外部來源的文件放進 context window（例如爬取的網頁、使用者上傳的文件），這些文件中可能包含惡意的 prompt injection 指令。AI 會把 context window 中的所有內容視為同等的輸入，無法可靠地區分「系統指令」和「使用者文件中夾帶的指令」。

資料洩露。如果你把機密文件放進 context window，AI 的回答可能無意中包含這些機密的內容。在多使用者的系統中，要確保 A 使用者的文件不會出現在 B 使用者的 context 中。

Token 消耗攻擊。惡意使用者可能故意送出超長的輸入，消耗你的 token 額度。在 API 應用中，應該設定 input token 的上限。

常見問題

Context window 超出上限會怎樣？

在 API 使用中，你會收到一個錯誤訊息，請求被拒絕。在 ChatGPT、Claude 等對話介面中，應用程式會自動截斷最早的對話歷史，讓總 token 數保持在上限內。無論哪種情況，被截斷的內容對 AI 來說都是「不存在」的。

Context window 128K 和 1M 有什麼實際差異？

128K 大約等於一本 300 頁的英文書，足夠處理大部分的單份文件分析、對話、和程式碼審查。1M 等於約 2,500 頁，可以一次放入一本技術手冊或多份合約文件。但在實際使用中，超過 128K 的部分效果會下降（lost in the middle 問題更嚴重），而且 token 費用會大幅增加。大部分使用場景下，128K 搭配好的 RAG 策略比直接用 1M 更有效率。

為什麼同樣的問題，ChatGPT 和 Claude 的 context window 不同？

因為不同模型是由不同公司用不同的架構訓練的，context window 的大小是訓練時的設計選擇。更大的 context window 需要更多的計算資源來訓練，也影響推理時的記憶體使用和速度。各家公司在 context window 大小、模型品質、推理速度之間做不同的權衡。

中文使用者需要特別注意什麼？

中文的 token 效率比英文差 30-50%，所以同樣的 context window 能處理的中文內容會比較少。在使用 AI 處理中文文件時，要預留更多的 context 空間。另外，如果你在中英文混合的環境中使用（例如程式碼加中文註解），token 的計算會更複雜，建議用 tokenizer 工具實際測量。

Context window 會繼續變大嗎？

會。從技術趨勢來看，context window 在持續增長中。Google 已經推出了 1M token 的 Gemini，Meta 的 Llama 系列也從 4K 成長到 128K。研究社群也在開發更高效率的注意力機制（如 Ring Attention、Infini-Attention），讓更長的 context 變得更實用。但更長的 context 也意味著更高的費用和更慢的回應速度，所以「更大」和「更好」之間仍有取捨。

延伸閱讀

  • Tokenizer 是什麼？AI 怎麼把文字拆成 Token（what-is-tokenizer）
  • RAG 是什麼？檢索增強生成讓 AI 讀你的資料（what-is-rag）
  • Prompt Caching 是什麼？節省 AI API 成本的快取技術（what-is-prompt-caching）