Context window 是什麼:為什麼 AI 會「忘記」

兩個你應該見過的場景：

場景一:你跟 ChatGPT 一路聊了 30 多輪。第 31 輪它回答時突然忘了你第一輪講過的設定，還可能把你前後文搞混。

場景二:你貼了一份 100 頁 PDF 給 Claude，問「總結重點」。它的回答看起來只用了前 20-30 頁的內容，後半被忽略。

這不是 bug。Context window 用完了。

Context window(上下文視窗)是 LLM 一次能處理的 token 總量上限。它包含 prompt + 歷史對話 + 文件 + 模型輸出——全部加起來不能超過上限。

理解 context window 是用 LLM 的第二堂基礎課(第一堂是 Tokens)。不懂它，你會在 production 撞到一堆「為什麼模型答得這麼爛」的問題。

為什麼 context window 有上限

不是工程師偷懶。是數學成本的限制。

LLM 用 transformer 架構，核心是 attention 機制——每個 token 都要跟其他所有 token 算相關性。

關鍵字：所有。

如果 context 有 N 個 token,attention 計算量是 N² 級。Context 變兩倍，計算成本變四倍。Context 變十倍，成本變一百倍。

這就是為什麼：

• 2020 年 GPT-3:context 2K(約 1500 字英文)
• 2023 年 Claude 2:擴到 100K
• 2024 年 Gemini 1.5:推到 1M
• 2026 年：Gemini / Claude / GPT-5 級別：1M-2M+ 是新常態

每次擴展都是工程跟成本上的硬仗。

2026 主流模型 context window

(數字會變，以官方為準。)

模型	Context window	註解
Claude Opus 4	~200K	標準長 context，實務 sweet spot
Claude Sonnet 4	~200K	同上，更便宜
GPT-5	~256K-400K(看 tier)	從 GPT-4 的 128K 擴大
Gemini 2.5 Pro	~1M-2M	最大 context，適合長文件
Llama 4 系列	128K-2M+	開源，看廠商實作
多數 reasoning model	~128K-256K	reasoning 吃額外 token

「context 大」不等於「跑得好」。 後面解釋。

Lost in the Middle:長 context 的隱形問題

2023 年史丹佛 Liu et al. 的研究揭露一個重要現象：LLM 在長 context 中會「Lost in the Middle」。

研究方法：把關鍵資訊塞在 context 的開頭、中間、或結尾，看模型能不能正確回答。

結果：

• 資訊在開頭:模型答對率高
• 資訊在結尾:模型答對率高
• 資訊在中間:模型答對率明顯下降

換句話說，塞 100K context 給模型，中段的內容它不一定真的「讀進去」。

這不是個別模型的 bug，是 attention 機制的普遍特性。2026 年的長 context 模型有改善，但這個 U 型曲線還在。

實務影響：

• 長文件 RAG 不能假設模型會均衡讀完——重要 chunk 應該放在 prompt 開頭或結尾
• 多輪對話超過幾十輪後，前期內容效力會降——必要時做 summarization 重啟對話
• 長 prompt 不等於好 prompt——精簡的 5K prompt 經常贏過冗長的 50K prompt

Context 用完了會發生什麼

四種具體症狀：

遺忘前文。 多輪對話超過 context 上限，最早的訊息會被擠掉。模型表現像「失憶」。

截斷輸出。 你問「寫一份 50 頁的 report」，模型寫到一半被切斷——因為 input + output 加起來碰到 context 上限。

回答品質下降。 Lost in the middle 效應讓模型「漏讀」中段資訊，答得不完整或斷章取義。

成本飆升。 Context 越長，每次呼叫 token 越多。100K context 比 10K context 貴 10 倍。沒控好就燒錢。

怎麼跨過 context 限制

不要等更大模型——設計層的解法更可靠。

第一，RAG。 不把整本書塞進 prompt，只撈最相關的 5-10 個 chunk 塞進去。 詳見 RAG 是什麼。

第二，Structured summaries。 多輪對話定期摘要——把前 20 輪壓成一段 500 字 summary，新對話從 summary 開始。OpenAI / Anthropic 的 SDK 都有 conversation memory 模式做這件事。

第三，Agent 切分子任務。 不要一次丟「研究 X 的所有面向」，而是讓 agent 拆成子任務，每個子任務獨立 context、獨立 model call，最後合併。

第四，Context caching。 重複使用的 system prompt、文件、few-shot 例子開啟 caching，只算一次全價、後續呼叫打折(50-90%)。長 context 的成本通常從這裡省下。

第五，選對 context size。 不是越大越好。對 5K token 的任務用 1M context model，只是付溢價買用不到的能力。

對 builder / 企業的判斷

第一，評估你真正需要的 context size。 大部分企業 use case 用 32K-128K 已經夠。1M context 適合長文件分析、long-form research，但成本高。

第二，測試「lost in the middle」效應。 在你的具體場景下放關鍵資訊在不同位置，看模型答對率。決定 prompt 結構。

第三，設計 fallback。 當 context 接近上限，系統要能自動切換策略(切 RAG、做 summarization、提示使用者 reset)。production 不能讓使用者撞牆。

第四，監控 token 使用。 大部分 production AI 帳單失控的原因是 context 沒控好。每次呼叫 log token 數，設 cost ceiling。

收尾

Context window 是 LLM 跟「你的世界」之間的窗。

窗大，看得多，但代價是計算 quadratic 成長 + middle 段被忽略。窗小，要你聰明設計 prompt + RAG + summarization。

2026 年的好 builder 不是用最大 context 的人，是把 context 當成稀缺資源好好設計的人。

下一篇 chronicle:Embedding 是什麼——RAG 跟 retrieval 為什麼能找到「相似」內容，背後的數學基礎。

周詠晴（編輯：廖玄同），《Context window 是什麼:為什麼 AI 會「忘記」》，矽基前沿 [Si]gnals，2026-04-25。https://signals.tw/articles/what-is-context-window/