上下文視窗大小決定了你可以做什麼。總結整個程式碼庫？需要大規模的上下文。快速提問回答？小規模就夠了。但規模更大不一定更好—模型在非常長的上下文中可能會失去焦點。
上下文視窗並不是儲存空間 — 它是工作記憶。視窗中的每個 token（您的系統提示、對話歷史、貼入的任何文件，以及模型到目前為止的輸出）都競爭相同的固定大小預算。當人們說 Claude 有 200K 的上下文視窗，或 Gemini 支援 1M tokens 時，這些數字包含所有內容：輸入與輸出合計。常見的錯誤是將上下文視窗當作資料庫，塞滿文件後預期模型能完美搜尋。事實上，模型透過注意力機制處理上下文，而注意力有計算與品質上的限制。
「中間遺失」問題是真實且有文獻支持的。史丹佛大學等機構的研究顯示，當關鍵資訊位於非常長的上下文中央時，模型使用它的表現會明顯比位於開頭或結尾時差。這不是理論上的問題 — 它直接影響您設計提示的結構。如果您要讓模型處理 50 頁的文件，應將最重要的部分放在開頭與結尾，而不是埋在第 25 頁。有些團隊會透過將文件分塊並使用 RAG 只檢索相關片段，而非將所有內容塞進上下文來應對這個問題。
上下文視窗大小已大幅成長。GPT-3 於 2020 年推出時有 4K tokens（約 3,000 個字）。到 2024 年，Claude 提供 200K tokens，Gemini 1.5 Pro 更推至 1M tokens。Google 的 Gemini 2.5 模型維持這百萬 tokens 的視窗。但更大的視窗伴隨真實的妥協。延遲增加，因為模型必須處理更多 tokens。成本上升，因為大多數 API 提供商按處理 tokens 數收費。而且如前所述，檢索任務的品質不會隨著上下文大小線性提升 — 1M tokens 的視窗並不會比 200K tokens 的視窗好五倍。
對使用 API 的開發者而言，上下文管理是核心工程問題。長對話會快速累積 tokens。一次來回的對話可能每次交換消耗 500–1,000 tokens，這表示 4K tokens 的模型僅需幾個回合就會耗盡空間。生產系統透過滑動視窗（移除最舊訊息）、摘要（壓縮先前對話為較短摘要），或混合方法（使用 RAG 將參考資料卸載到向量資料庫，僅按需拉取相關片段）來處理此問題。正確處理這一點，往往是區分一個能運作的示範與可擴展產品的關鍵。
一個常見的誤解：上下文視窗限制是針對 tokens，而非字元或字數。分詞方式因模型與語言而異。英文文本平均約 1 token 對應 4 個字元，但程式碼可能更密集（變數名稱與語法快速消耗 tokens），而漢語或印地語等非拉丁文字通常每個字使用更多 tokens。同一份文件在英文中可能消耗 10K tokens，在日文中則可能需要 15K tokens。大多數提供者提供分詞工具或函式庫 — Anthropic 在 API 回應標頭中內建 token 計數器，OpenAI 發布了 tiktoken — 讓您能精確測量，而非估測。