Context 就是一切:LLM 的記憶體管理課

寫過作業系統課的人都熟悉一個概念:記憶體永遠不夠用,所以你需要分頁、快取、回收機制。LLM 的 context window,本質上是同一個問題的翻版—— 差別在於,這裡沒有作業系統幫你管理,一切都要工程師自己設計。

Context window 不是硬碟,是工作記憶

很多人把 context window 想成「你能塞多少資料進去」的容量問題,這個理解只對了一半。更準確的類比,是人類的工作記憶:容量有限、越接近當下的資訊影響力越大、資訊過多時反而會互相干擾,讓模型抓不到重點。塞滿 128K token 的 context,不代表模型能均勻地「記得」裡面每一句話。

三層記憶體,各自管各自的事

把 context 工程拆解成三層,會比一股腦塞資料更容易管理:

短期記憶:當前這輪對話的直接上下文,通常需要完整、逐字保留。
中期記憶:這個 session 裡稍早發生的事,可以摘要壓縮,只保留關鍵決策與結論,而非逐字對話紀錄。
長期記憶:跨 session 的知識,通常不該塞進 context,而是交給檢索系統(RAG)——需要的時候才撈出來,而不是隨時攜帶。

RAG 是分頁機制,不是萬靈丹

檢索增強生成(RAG)常被當成解決 context 限制的萬靈丹,但它本質上只是一種分頁機制:把大量長期知識留在外部儲存,只在需要時把相關片段換頁進工作記憶。這意味著 RAG 系統的品質瓶頸,往往不在生成端, 而在「換頁演算法」——也就是檢索策略本身。

常見的檢索問題並非模型讀不懂資料,而是檢索回來的片段本身就不相關, 或是相關片段之間彼此矛盾,模型只能在矛盾的資訊裡選一個「聽起來合理」的答案。換句話說,RAG 做不好,經常是資料工程的問題,而不是模型能力的問題。

壓縮策略:什麼可以丟,什麼不能丟

當 context 逼近上限,勢必要做取捨。實務上比較安全的壓縮順序是: 先丟棄可以由其他資訊重新推導出的中間過程(例如逐步推理的草稿), 再摘要重複性高的歷史對話,最後才考慮動使用者最初設下的限制條件與目標描述——這些通常應該是最後被犧牲的部分,因為一旦丟失,模型就會悄悄地偏離任務原本的邊界,而且不會主動告訴你它已經忘記了。

把 context 當成預算來編列

最實用的心態轉換,是把 context window 當成一份需要編列的預算,而不是一塊隨便丟東西進去的空間:多少 token 留給系統指令、多少留給檢索結果、多少留給對話歷史、多少留給模型自己的輸出空間。預算編列得越明確,系統在流量與內容都變複雜時,才不會毫無預警地撞上上限,或是在還有餘裕時就過早、過度壓縮重要資訊。

Context 從來不是「越多越好」的資源,而是一份需要主動設計、主動回收的工作記憶。管好它,比換一個更大 context window 的模型,往往能更直接地解決問題。