/
#AI

不丟失語意地縮小 Context Window 壓力

AI 模型的「短期記憶」有上限——這篇文章告訴你工程師怎麼在不讓它失憶的前提下，騙它用更少的空間記住更多的事。

先說結論

讀完這篇，你會得到：

  1. 理解為什麼 context window 是瓶頸，以及「記憶體滿了」會發生什麼事
  2. 六種主流的壓縮/管理策略，以及各自的適用場景與代價
  3. Claude、GPT、Gemini 在架構層面怎麼應對，以及現在各家用什麼招數

從類比開始

想像你是一個會議記錄員。

每次開會，你只有一張 A4 紙可以記。開會記錄超過一張怎麼辦？你有幾個選擇：

  1. 把舊的擦掉（截斷）：簡單，但可能擦掉重要決議
  2. 把前面的會議摘要成一段話（摘要）：省空間，但細節消失
  3. 只記跟今天議題有關的部分（RAG）：準確，但你得先知道今天要問什麼
  4. 換一張更大的紙（擴大 context window）：最直覺，但紙越大越貴

AI 模型面對的問題幾乎一模一樣。context window 就是那張 A4 紙，token 就是紙上的字。問題在於：紙的大小有限，而對話和文件可以無限長。

核心概念

1. Context Window 是什麼？為什麼有壓力？

Context window 是 LLM 在一次推論中能「看到」的最大 token 數。所有輸入（系統提示、對話歷史、文件、使用者問題）加起來不能超過這個上限。

白話版：就是模型的「工作記憶」。超過上限，它就真的不記得了——不是假裝不記得，是物理上看不到。

為什麼有壓力？

Transformer 架構有個根本問題：計算量隨 context 長度平方成長。Context 長度加倍 → 計算資源變 4 倍。這直接影響：

還有一個更微妙的問題："Lost in the Middle"。實驗發現，即使模型有 200K token 的 context window，對話歷史放在中間的資訊，模型的注意力會顯著下降，準確率可能掉 30% 以上。塞再多進去不一定有用。

2. 六大管理策略

策略一：截斷（Truncation）

最暴力的做法。超過上限就直接切掉最舊的 token。

策略二：滾動摘要（Rolling Summarization）

定期把舊對話壓縮成摘要，再把摘要放進 context 繼續對話。

[對話 1-10 的摘要] + [對話 11-20 的摘要] + [最近 5 則對話原文]

策略三：分層摘要（Hierarchical Summarization）

像金字塔一樣：先摘要小段落，再摘要段落的摘要，直到整份文件濃縮成可用的大小。

[章節 1 摘要] + [章節 2 摘要] + [章節 3 摘要]
        ↓
   [全文摘要（二次壓縮）]

策略四：Context 壓縮（Prompt Compression）

不做摘要，而是移除重複、冗餘的 token，保留原文措辭但去掉廢話。

最知名的工具是 Microsoft Research 的 LLMLingua 系列：

版本壓縮倍率性能損失
LLMLingua20x僅 1.5%
LongLLMLingua4x提升 21.4%

LongLLMLingua 反而更準確，是因為壓縮過程過濾了噪音。

實際數字：每月 30 億 token 的企業用量，用 5 倍壓縮，費用從 $270,000 降到 $54,000。

策略五：RAG（Retrieval-Augmented Generation）

不把整份文件塞進 context，而是把文件切塊存進向量資料庫，每次查詢時只取「最相關的幾塊」注入 context。

問題 → embedding → 向量搜尋 → 取最相關 3-5 塊 → 注入 context → 回答

策略六：切換到更大的模型（Routing）

根據 token 數動態選模型：小問題用小模型，context 爆炸就切換到 window 更大的模型。

決策流程圖

各大模型怎麼實踐

Context Window 大小比較（2025-2026）

模型Context Window架構特點
Gemini 2.5 Pro2,000,000 tokens目前最大，全文注意力
Llama 410,000,000 tokens開源模型，Mixture of Experts
GPT-4.11,000,000 tokens長 context RAG 整合
Claude 3.5 / 4200,000 tokens強調 mid-context 準確率
Grok 4256,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 的記憶設計上有哪些公開的研究？

參考來源

分享
不丟失語意地縮小 Context Window 壓力 - Nigel Lee Digest