上下文窗口（Context Window）係 AI 模型一次可以處理嘅 Token 上限。即係模型「睇到嘅嘢」嘅總量——包括你輸入嘅 Prompt、之前嘅對話歷史、同模型自己生成嘅回覆。超過呢個上限，模型就會「忘記」之前嘅內容。
簡單比喻：上下文窗口就係 AI 嘅「短期記憶容量」。如果窗口係 128K，即係 AI 最多記得 128,000 個 Token 嘅嘢——再多就會好似人類咁，記得開頭同結尾，但中間嘅細節就模糊咗。
一次對話中，上下文窗口嘅容量被以下幾部分瓜分：
所以「128K 上下文」唔係你可以輸入 128K 字——而係所有嘢加埋唔可以超過 128K。
| 模型 | 上下文窗口 | 大約中文字數 | 大約頁數 |
|---|---|---|---|
| GPT-4o | 128K Token | 9-10 萬字 | ~300 頁 |
| GPT-4o mini | 128K Token | 9-10 萬字 | ~300 頁 |
| Claude Opus 4.x | 200K Token | 14-15 萬字 | ~450 頁 |
| Claude Sonnet 4.x | 200K Token | 14-15 萬字 | ~450 頁 |
| Gemini 1.5/2.0 Pro | 1M+ Token | 70-75 萬字 | ~2000 頁 |
| Gemini Flash | 1M Token | 70-75 萬字 | ~2000 頁 |
數據來源：OpenAI、Anthropic、Google 官方文檔（2026 年核實）。實際可用窗口可能因 API 設定而異。
如果你用 GPT-4o（128K 窗口）分析一份 50 頁嘅合約：
但如果係一份 500 頁嘅書（≈ 250,000 Token），就超過 128K 窗口，需要分段處理或者用 Gemini 1M+。
三種常見情況：
模型會自動「忘記」最舊嘅對話內容。你可能發覺 AI 突然唔記得你之前講過咩，或者答非所問。
API 調用會返回 context_length_exceeded 錯誤，話你知輸入太長。
即使未超出窗口，當上下文好長時，模型對中間部分嘅記憶同理解會明顯下降。研究顯示，模型對開頭同結尾嘅資訊記得最牢，中間嘅細節容易被忽略。呢個叫「Lost in the Middle」現象。
唔一定。大窗口有好處，但都有代價：
| 維度 | 小窗口（32K） | 大窗口（200K+） |
|---|---|---|
| 處理長文件 | ❌ 要分段 | ✅ 一次過 |
| 成本 | ✅ 平 | ❌ 貴（按 Token 收費） |
| 速度 | ✅ 快 | ❌ 慢 |
| 準確度 | ✅ 高（短上下文更精準） | ⚠️ 中間內容易遺忘 |
| 適合場景 | 日常對話、寫作、翻譯 | 長文件分析、合約審閱 |
結論：大部分日常任務 32K-128K 已經足夠。只有真係需要處理成百頁文件時，先需要 200K 或 1M+。
✅ 正確：上下文窗口係「輸入 + 輸出 + 對話歷史」嘅總和。你可以輸入嘅字數 = 窗口大小 - 預留輸出空間 - 已有對話。
✅ 正確：唔一定。1M 窗口嘅模型處理短任務時可能反而慢同貴，而且「迷失中間」問題更嚴重。視乎任務選擇。
✅ 正確：唔係。即使喺窗口內，模型對中間內容嘅注意力都會下降。重要嘢要反覆強調或者放喺顯眼位置。
A：上下文窗口（Context Window）係 AI 模型一次可以處理嘅 Token 上限，即係模型「睇到嘅嘢」嘅總量——包括你輸入嘅 Prompt、之前嘅對話、同模型生成嘅回覆。超過呢個上限，模型就會「忘記」之前嘅內容。
A：128K Token 大約等於 9-10 萬個中文字，或者 9.6 萬個英文單字。足夠處理大約 300 頁書嘅內容。
A：2026 年主流模型中，Gemini 1.5/2.0 Pro 支援 1M+ Token（大約 75 萬字），Claude Opus/Sonnet 係 200K，GPT-4o 係 128K。但上下文越大，成本越高、速度越慢。
A：三種可能：1) 模型自動截斷最舊嘅內容（你會「失去」之前嘅對話）；2) 報錯話 context length exceeded；3) 模型質素下降，因為中間內容被遺忘（「迷失中間」問題）。
A：唔一定。大窗口可以處理長文件，但成本更高、回應更慢，而且模型容易「迷失中間」——忘記上下文中間嘅內容。大部分日常任務 32K-128K 已經足夠。
A：1) 重要資訊放開頭同結尾（模型記得最牢）；2) 長文件先摘要再餵入；3) 用 RAG 技術只擷取相關片段；4) 定期總結對話，避免無限累積。