我第一次認真把「AI 的記憶」這件事想清楚，不是在看論文的時候，而是在自己把樓層弄混之後。
那時候我很自然地把事情切成兩半：不是寫進模型裡，就是放在模型外面。這種分法很順，也很不夠用。因為一旦真的開始碰本地 LLM，你很快就會發現，外面的東西差很多，裡面的東西也差很多。上下文、知識庫、LoRA、system prompt、Modelfile，看起來都像在讓模型「記得一些東西」，但它們根本不是同一種記憶。
這篇想做的，不是把名詞重新排版，而是把記憶的責任邊界切開。因為如果你連記憶長在哪裡都還沒分清楚，後面很容易把所有問題翻譯成「我要不要再訓一層」。而很多時候，真正該改的根本不是參數。
先承認一件事：AI 不是沒有記憶，只是記憶不只一種
「AI 的記憶都是假的」這種說法，我不是不能理解。因為很多你以為是模型記得的東西，最後其實只是暫時留在上下文，或者被掛在外部資料裡，推理時再拉回來。但如果把這句話當成全部真相，後面會一路走偏。
模型當然會在參數層學到東西。不然 pretraining 不會成立，instruction tuning 不會成立，LoRA 也不會成立。真正麻煩的地方從來不是「有沒有學到」，而是：你到底把什麼東西放在哪一種記憶裡。
這也是我後來比較願意用四分類來想這件事的原因。不是內外二分，而是至少先分成：上下文記憶、外部記憶、參數記憶，以及偏好記憶。
第一種：上下文記憶
這是最淺、也最常被誤認成模型真的學到了的一種記憶。
你在這輪對話裡告訴它：「之後請先給結論，再分成原理、風險、做法。」它接下來幾輪都很配合。你補一句「請用簡潔、直接、不說教的方式回答」，它也照做。這當然很像記住了。
但它更像這齣戲還沒演完，所以演員手上還拿著前幾頁劇本。上下文記憶最大的特徵就是：來得快、很方便，但通常短效。只要 session 斷掉、context 被截斷、或者這套要求沒有再被帶進去，它就可能直接消失。
這種記憶非常有用，但不適合承擔長期穩定要求。它適合裝當下任務、一次性的限制、暫時性的格式要求，而不是你希望模型長期都保有的行為傾向。
第二種：外部記憶
這層比較接近大家直覺中的「外掛筆記本」。文件庫、RAG、vector database、外部知識源，基本上都屬於這一類。
它的關鍵不在於模型有沒有能力回答，而在於：知識本身不直接寫進 base weights。模型是在推理時去拿，再把拿到的內容拉回當下回答裡。
這種記憶有一個非常強的優點：好改。資料過期了，可以更新。資料錯了，可以刪掉。文件換版了，可以重索引。它不像權重，一旦動進去，回滾成本高很多。
所以只要你要存的是：
- 會變動的事實
- 文件內容
- 專案資訊
- 使用者資料
- 知識庫查詢結果
我後來幾乎都會先傾向外部記憶，而不是急著往參數裡塞。這不只是工程上比較省力，也是因為很多知識根本不值得被硬寫進模型裡。
第三種：參數記憶
這才比較接近大家直覺裡那種「真的寫進模型」的記憶。
它包括：
- pretraining 累積出來的語言能力與廣泛知識
- instruct tuning 帶進去的對話底子
- LoRA / adapter 帶進去的某些行為傾向
- partial / full fine-tuning 對原始權重的實際修改
參數記憶的優點很明顯：穩。不需要每次都靠外部資料再叫一次，不需要每輪都補 prompt，不需要 session 裡重講一遍。缺點也一樣明顯：重，而且不容易撤回。
你一旦把東西寫進參數，通常就不是「覺得不對，明天再刪掉」這麼簡單。這也是為什麼很多本來只是想調風格的人，最後把模型訓歪時會特別痛。不是因為訓練沒成功，而是因為訓練真的成功了，只是成功寫進去的不是你原本想要的東西。
第四種：偏好記憶
這一類很值得單獨拉出來，因為它既不像外部知識那麼像資料庫，也不像世界知識那麼像底模本身的大腦底子。它比較像：
- 你偏好它怎麼說話
- 它該比較偏向哪種答案風格
- 同一題有幾個都不算錯的答案時，它該更常站在哪一邊
這種東西有時候放 system prompt 就夠，有時候 few-shot 就壓得住，再往下才輪到 LoRA、SFT，甚至 DPO。也因為這樣，偏好記憶是最容易放錯層的一種記憶。你太早往深處塞，成本會暴增；你太淺，則可能根本壓不住。
所以 system prompt、Modelfile、LoRA 各算哪種記憶
這件事如果只講「它們都算記憶」其實沒幫助。我後來更習慣把它們放在不同位置上理解：
- System prompt：比較像外層的短中期偏好記憶。它能穩定一段時間，但依然屬於外層包裝。
- Modelfile：不是單一記憶類型，而是一份包裝藍圖。它把 system、template、message、parameter，必要時還有 adapter 一起固定下來。你可以把它看成外層記憶的編排器。
- LoRA / adapter：屬於參數記憶。它沒有全改 base weights，但它確實把某些傾向寫進可訓練參數裡。
所以這三個東西看起來都像「讓模型比較穩」，但它們根本不在同一層。
continual learning 為什麼難，不是因為大家沒想到要繼續學
continual learning 不是一個新鮮口號，它困難的地方也不是研究者不知道模型需要持續更新。真正難的，是你要讓模型學到新東西，同時又別把舊能力洗掉。
這就是 catastrophic forgetting 的核心：模型在學新任務、新資料、新偏好時，犧牲了舊能力或舊知識的穩定性。Google Research 在 2025 年提出 Nested Learning 時，特別就是把這件事重新框起來。他們把模型視為多層、巢狀的最佳化問題，主張現有深度學習的記憶與更新其實一直被壓得太平，才會讓 continual learning 特別容易卡在新舊能力互相打架。 我覺得 Nested Learning 值得提，不是因為它今天就能直接變成你的本地 LLM recipe，而是因為它幫你換了一個比較好的視角：記憶不是單點，不是「有沒有存下來」而已，而是多層上下文、多層更新規則和多層最佳化如何一起工作。
catastrophic forgetting，最好不要只用一句話帶過
很多文章會把 catastrophic forgetting 簡化成「學新忘舊」。這句話沒錯，但太輕。真正的問題不是抽象上的忘記，而是你很可能在一個窄資料集上，把本來就有平衡感的模型拉到一個更狹窄的行為區間裡。
這也是為什麼小資料 LoRA 和小資料 partial FT 特別容易讓人又愛又恨。它們不是沒學到，而是學得很用力，只是用力的方向常常不夠廣。你以為自己在加一點偏好，結果是拿一小杯很濃的染料，往一大桶本來顏色很均衡的水裡倒。
所以 catastrophic forgetting 不只是一個研究詞，它其實也在提醒本地微調的實作者：不要太浪漫地看待「把東西寫進參數」。
Nested Learning 值得放在這個系列的哪個位置
我不想把 Nested Learning 寫成主角，也不想把它塞成一段很突兀的研究插曲。它比較適合被放在這一篇裡，當成一種高層理解框架。因為這一篇本來就在談：
- 記憶不只一種
- 更新不只一層
- 外部記憶與參數記憶不是同一回事
- continual learning 難在新舊能力如何共存
Google Research 對 Nested Learning 的說法，剛好能幫這些問題多一個視角：模型之所以難以持續學習，不是因為資料不夠，而可能是我們原本就把多層記憶與更新這件事想得太扁。 ## 什麼東西該放哪一種記憶
如果把這篇濃縮成一份能工作的判斷表，我現在大概會這樣分：
上下文記憶適合放
- 當下任務
- 一次性規則
- 短期格式要求
- 這輪對話的限制條件
外部記憶適合放
- 文件
- 知識庫
- 專案資料
- 使用者資料
- 會變動的事實
參數記憶適合放
- 語言能力
- 更深的回答傾向
- 穩定的任務風格
- 不是每次都想靠外掛帶著跑的東西
偏好記憶適合放
- 回答排序偏好
- 語氣取捨
- 哪種答案比較好
- DPO 這類 preference optimisation 想推動的東西
真正重要的不是背下這四格，而是別把不該往深處塞的東西，太早往深處塞。
什麼時候不要把問題翻譯成 continual learning
這篇也要留反例，因為只要一談記憶，很容易把所有事情都說成持續學習的難題。最典型的反例是：你只是想讓模型預設用繁體中文、先講結論、少一點廢話。這種問題很多時候根本不是 continual learning 問題。它可能只是 template 沒對齊，system prompt 沒寫好，或者 Modelfile 這層根本還沒處理。
也就是說，不是每次你想讓模型「更記得」某件事，都要往記憶研究那條線上升級。很多時候問題只是放錯層。
下一篇要接什麼
記憶先分清楚之後，下一個會撞到的現實問題是：你手上的工具到底能碰到哪幾層？Hugging Face、Transformers、PEFT、TRL、Ollama 聽起來都跟模型有關，但它們根本不是同一類工具。
下一篇就來拆這條工具鏈。