AI 模型的「短期記憶」有上限——這篇文章告訴你工程師怎麼在不讓它失憶的前提下，騙它用更少的空間記住更多的事。
先說結論
讀完這篇，你會得到：
- 理解為什麼 context window 是瓶頸，以及「記憶體滿了」會發生什麼事
- 六種主流的壓縮/管理策略，以及各自的適用場景與代價
- Claude、GPT、Gemini 在架構層面怎麼應對，以及現在各家用什麼招數
從類比開始
想像你是一個會議記錄員。
每次開會，你只有一張 A4 紙可以記。開會記錄超過一張怎麼辦？你有幾個選擇：
- 把舊的擦掉（截斷）：簡單，但可能擦掉重要決議
- 把前面的會議摘要成一段話（摘要）：省空間，但細節消失
- 只記跟今天議題有關的部分（RAG）：準確，但你得先知道今天要問什麼
- 換一張更大的紙（擴大 context window）：最直覺，但紙越大越貴
AI 模型面對的問題幾乎一模一樣。context window 就是那張 A4 紙，token 就是紙上的字。問題在於：紙的大小有限，而對話和文件可以無限長。
核心概念
1. Context Window 是什麼？為什麼有壓力？
Context window 是 LLM 在一次推論中能「看到」的最大 token 數。所有輸入（系統提示、對話歷史、文件、使用者問題）加起來不能超過這個上限。
白話版：就是模型的「工作記憶」。超過上限，它就真的不記得了——不是假裝不記得，是物理上看不到。
為什麼有壓力？
Transformer 架構有個根本問題：計算量隨 context 長度平方成長。Context 長度加倍 → 計算資源變 4 倍。這直接影響：
- 推論速度（越長越慢）
- API 費用（token 計費）
- 可用性（超長 context 的模型比較少）
還有一個更微妙的問題："Lost in the Middle"。實驗發現，即使模型有 200K token 的 context window，對話歷史放在中間的資訊，模型的注意力會顯著下降，準確率可能掉 30% 以上。塞再多進去不一定有用。
2. 六大管理策略
策略一：截斷（Truncation）
最暴力的做法。超過上限就直接切掉最舊的 token。
- 優點：實作最簡單，零延遲
- 缺點：可能切掉關鍵資訊，沒有語意意識
- 適用：即時場景、內容本身時效性強（如即時新聞摘要）
策略二：滾動摘要（Rolling Summarization）
定期把舊對話壓縮成摘要，再把摘要放進 context 繼續對話。
[對話 1-10 的摘要] + [對話 11-20 的摘要] + [最近 5 則對話原文]
- 優點：保留語意骨幹，context 不會爆炸
- 缺點：摘要會損失細節；摘要品質影響後續推論；每次摘要都要呼叫一次 LLM
- 適用：長對話 chatbot、多輪任務助理
策略三：分層摘要（Hierarchical Summarization）
像金字塔一樣：先摘要小段落，再摘要段落的摘要，直到整份文件濃縮成可用的大小。
[章節 1 摘要] + [章節 2 摘要] + [章節 3 摘要]
↓
[全文摘要（二次壓縮）]
- 優點：適合處理超長文件（書籍、法律合約）
- 缺點：早期摘要的錯誤會一路傳播；增加延遲；對非結構化文本效果差
- 適用：文件問答、研究工具
策略四：Context 壓縮（Prompt Compression）
不做摘要，而是移除重複、冗餘的 token，保留原文措辭但去掉廢話。
最知名的工具是 Microsoft Research 的 LLMLingua 系列：
| 版本 | 壓縮倍率 | 性能損失 |
|---|---|---|
| LLMLingua | 20x | 僅 1.5% |
| LongLLMLingua | 4x | 提升 21.4% |
LongLLMLingua 反而更準確，是因為壓縮過程過濾了噪音。
- 優點：保留原文語意最完整；token 節省 40–60%
- 缺點：需要額外的壓縮模型；過度壓縮仍有損失
- 適用：API 費用敏感的生產環境
實際數字：每月 30 億 token 的企業用量，用 5 倍壓縮，費用從 $270,000 降到 $54,000。
策略五：RAG（Retrieval-Augmented Generation）
不把整份文件塞進 context，而是把文件切塊存進向量資料庫，每次查詢時只取「最相關的幾塊」注入 context。
問題 → embedding → 向量搜尋 → 取最相關 3-5 塊 → 注入 context → 回答
- 優點：context 永遠精簡；可處理超過任何 context window 的資料量；動態更新
- 缺點：「垃圾進，垃圾出」——檢索品質決定一切；設定複雜；增加延遲
- 適用：知識庫問答、企業文件搜尋、需要引用來源的場景
策略六：切換到更大的模型（Routing）
根據 token 數動態選模型：小問題用小模型，context 爆炸就切換到 window 更大的模型。
- 優點：保留完整資訊，零損失
- 缺點：大模型貴且慢
- 適用：偶發性的超長輸入，不適合高頻場景
決策流程圖
各大模型怎麼實踐
Context Window 大小比較（2025-2026）
| 模型 | Context Window | 架構特點 |
|---|---|---|
| Gemini 2.5 Pro | 2,000,000 tokens | 目前最大，全文注意力 |
| Llama 4 | 10,000,000 tokens | 開源模型，Mixture of Experts |
| GPT-4.1 | 1,000,000 tokens | 長 context RAG 整合 |
| Claude 3.5 / 4 | 200,000 tokens | 強調 mid-context 準確率 |
| Grok 4 | 256,000 tokens | 即時資料整合 |
Gemini：直接暴力擴大
Google 的策略是硬拼 context window。Gemini 1.5 Pro 在 2024 年率先突破百萬 token，靠的是 Mixture of Experts（MoE） 架構，讓超長 context 的計算成本更可控。
但長 context 不代表沒問題——"Lost in the Middle" 仍然存在，Gemini 也不例外。
GPT-4.1：長 context + RAG 混用
OpenAI 的策略是兩條腿走路：一方面把 window 擴到百萬，另一方面在架構上優化對長 context 的注意力分配，並鼓勵搭配 RAG 使用。GPT-4.1 的 API 文件明確建議：超過 128K 的文件場景，優先用 RAG 而不是全部塞入。
Claude：強調中段準確率
Anthropic 在 Claude 的設計上特別強調對 mid-context 資訊的保留能力。Claude 3 系列在「Needle in a Haystack」測試（把關鍵訊息藏在超長 context 中間，看模型能不能找到）的表現優於同期競品。
此外，Claude Code（就是你現在用的這個）在長對話中會自動觸發 context 壓縮：當對話超過閾值，自動把舊對話摘要成精簡版繼續。這就是 src/lib/deployUtils.ts 裡的 sm_compact_config 設定在做的事——minimumMessageTokensToInit: 150000，超過這個值就啟動壓縮。
各家共同面對的根本問題
這三個問題是所有模型共同面對的，沒有人真正解決了，只是用不同方式緩解。
常見誤解
❌ 誤解一：Context window 越大越好，塞滿就對了
真相："Context quality matters more than quantity." 把 200K token 全部塞滿，不代表模型能充分利用。中段資訊衰減加上計算成本，常常讓「塞滿」變成「費錢但不準」。精心設計的 2K token prompt 可能比雜亂的 50K token prompt 表現更好。
❌ 誤解二：RAG 可以完全取代長 context
真相：RAG 有個致命弱點——你必須知道要問什麼，才能檢索到對的塊。對於需要模型「整體理解」全文再回答的任務（如：幫我總結這份合約的所有風險條款），RAG 的切塊方式可能反而漏掉跨段落的關聯。有些場景，直接給完整文件就是最好的。
❌ 誤解三：摘要一定會損失語意
真相：LLMLingua 的實驗顯示，適度壓縮反而可以提升準確率（+21.4%），因為它過濾掉了噪音。「語意損失」不是摘要的必然結果，而是品質差的摘要的結果。好的壓縮是找出哪些 token 對模型的推理真的重要，只留那些。
延伸思考
1. Context Engineering 會成為獨立職能嗎？
現在已有人在討論「Context Engineer」這個角色——不是寫提示詞，而是設計整個記憶架構：哪些記憶要保留、用什麼格式、放在 context 的哪個位置。值得探索：這和傳統的 Prompt Engineering 有什麼本質差異？
2. 記憶的分層架構
人腦有短期記憶和長期記憶。AI 系統也在走向這個方向：短期用 context window，長期用向量資料庫，中期用摘要緩存。值得探索：MemGPT / Letta 框架怎麼把這個概念工程化？
3. Flash Attention 和線性注意力
Transformer 的 O(n²) 問題有沒有架構層面的解？FlashAttention、Mamba（SSM 架構）、線性注意力等都是嘗試。值得探索：這些方案能否真正取代傳統 Transformer？
4. 知識圖譜作為 context 補充
把知識結構化成圖譜，再從圖譜中抽取相關子圖注入 context，而不是直接注入原文。值得探索：GraphRAG（Microsoft 提出）和傳統 RAG 的對比？
5. 模型自己學會「選擇性記憶」
未來的模型能不能自己決定哪些要記、哪些要忘？強化學習 + 記憶管理是一個研究方向。值得探索：Anthropic 在 Claude 的記憶設計上有哪些公開的研究？
參考來源
- Top 6 Techniques to Manage Context Length in LLMs — Agenta
- Prompt Compression Techniques — Medium / Kuldeep Paul
- Context Engineering: Optimizing LLM Memory for Production AI Agents — Medium
- Extending Context Window via Semantic Compression — ACL 2024
- LLM Context Window Limitations in 2026 — Atlan
- LLM Context Windows: What They Are & How They Work — Redis