記憶與檢索

語言模型的權重在訓練結束後就固定 (frozen)，而且脈絡視窗 (context windows) 在對話結束後就清空了。可是我們希望它記得上週的會議、記得使用者的偏好、記得昨天才公布的新規定。本週談三種讓模型「記得」的方式，並從語言與認知的角度追問：這些機制所做的，和人類所說的「記憶」是同一件事嗎？

8.1總覽：記憶在哪裡

作個類比：書桌、書架與圖書館，分別是桌上攤開的、架上背熟的、館裡查得到的。

參數記憶與非參數記憶：Lewis et al.（2020）區分兩種知識來源。參數記憶存在模型權重裡，是預訓練時「背下來」的；非參數記憶存在模型外部的索引中，需要時再檢索。加上回答當下放進提示的內容，語言模型的記憶可以分成三處。

8.2脈絡視窗：模型的工作記憶

隨着視窗愈來愈大，模型需要記住的東西也愈來愈多。但放得進去，不等於用得上；放得進去，也不是免費的。

KV 快取（key–value cache）：生成每個新詞元時，注意力都要讀取先前所有詞元的鍵與值。為了不必每次重算，模型把它們存在記憶體中。所需空間與脈絡長度成正比：

記憶體 ＝ 2 × 層數 × KV 頭數 × 每頭維度 × 詞元數 × 每個數值的位元組

GQA（grouped-query attention）是另一個技巧。讓多個查詢頭共用同一組鍵與值，正是為了壓低這筆開銷：8B 模型有 32 個查詢頭，卻只存 8 組 KV。另一筆帳是計算：標準注意力的計算量隨長度平方成長，長度加倍，計算約變四倍。

def kv_cache_bytes(n_tokens, layers, kv_heads, head_dim, bytes_per_value=2):
    """單一序列的 KV 快取大小；乘 2 是因為鍵與值各存一份"""
    return 2 * layers * kv_heads * head_dim * n_tokens * bytes_per_value

# Llama 3 8B：32 層、8 組 KV 頭（GQA）、每頭 128 維
kv_cache_bytes(1, 32, 8, 128)                 # 131072 位元組 ＝ 128 KiB／詞元
kv_cache_bytes(128_000, 32, 8, 128) / 2**30    # 約 15.6 GiB

有效脈絡長度：模型宣稱可讀入的長度，與它真正能可靠運用的長度，往往不同。RULER 基準（Hsieh, C.-P. et al., 2024）發現，幾乎所有模型在單純的「大海撈針」測試上都接近滿分；換成多針檢索、多跳追蹤或資訊聚合等任務並拉長脈絡後，表現明顯下降。在他們測試的模型中，宣稱支援 32K 以上的，約只有一半在 32K 時仍維持令人滿意的表現。

附註：第 6 週談過的「中段遺失」（Liu et al., 2024）是同一問題的另一面：資訊不只要放得進去，還要放在模型用得上的位置。人類的工作記憶容量極小，大約只能同時維持四個左右的組塊（Cowan, 2001），卻很少「看見了卻沒用上」；模型的工作記憶極大，利用率卻不均勻。

8.3檢索增強生成

不必把整座圖書館背下來，只要知道去哪裡查、查到後怎麼用。

檢索增強生成（retrieval-augmented generation，RAG）：先由檢索器從外部文件找出與問題相關的段落 z，再把段落連同問題 x 交給生成器產生答案 y。Lewis et al.（2020）把檢索結果當成隱變數，對前 k 個段落加權求和：

p(y | x) ≈ Σ_{z ∈ top-k} p_η(z | x) · p_θ(y | x, z)

其中 p_η 是檢索器（原論文用 DPR 稠密檢索），p_θ 是生成器（BART）。今日常見的做法更簡單：取前 k 個段落，直接拼進提示。無論哪種，答案的品質都先取決於兩個看似瑣碎的決定：文件怎麼切，以及用什麼方式比對。

import math, re
from collections import Counter

def units(text):
    """漢字取二元組，拉丁字母取整詞：不需要斷詞器"""
    han = re.findall(r"[一-鿿]+", text)
    grams = [s[i:i+2] for s in han for i in range(len(s) - 1)]
    return grams + [w.lower() for w in re.findall(r"[A-Za-z]+", text)]

def bm25(query, chunks, k1=1.5, b=0.75):
    docs = [Counter(units(c)) for c in chunks]
    avg = sum(sum(d.values()) for d in docs) / len(docs)
    N, scores = len(docs), []
    for d in docs:
        L, s = sum(d.values()), 0.0
        for t in set(units(query)):
            n = sum(t in e for e in docs)
            idf = math.log(1 + (N - n + 0.5) / (n + 0.5))
            s += idf * d[t] * (k1 + 1) / (d[t] + k1 * (1 - b + b * L / avg))
        scores.append(s)
    return scores

8.4長期記憶：把模型當作作業系統

檢索回答「去哪裡查」；長期記憶還要回答「什麼時候寫下來、什麼時候清掉」。

MemGPT：Packer et al.（2023）借用作業系統的虛擬記憶：脈絡視窗是有限的主記憶體，外部儲存是硬碟，由模型自己透過函式呼叫，決定把哪些內容調入或移出。主脈絡分成三塊：唯讀的系統指令、可讀寫的工作脈絡（存放使用者與角色的關鍵事實），以及先進先出的訊息佇列；外部則有保存完整對話的回想儲存，與存放長期資料的封存儲存。

class MainContext:
    """MemGPT 式主脈絡的骨架：警告與清出的門檻依原論文的例示"""
    def __init__(self, limit, warn=0.7):
        self.limit, self.warn = limit, warn
        self.working, self.queue, self.summary = [], [], ""
        self.recall, self.archival = [], []

    def used(self):
        return sum(len(m) for m in self.working + self.queue) + len(self.summary)

    def push(self, msg, summarize):
        self.queue.append(msg)
        if self.used() >= self.limit:                     # 滿了：清出最舊的訊息
            old = []
            while self.queue and self.used() > self.limit / 2:
                old.append(self.queue.pop(0))           # 直到用量降到一半
            self.recall += old                               # 原文留在回想儲存
            self.summary = summarize(self.summary, old)      # 遞迴摘要：舊摘要＋被清出的訊息
        elif self.used() >= self.warn * self.limit:
            return "記憶壓力警告：請把重要事實寫入工作脈絡或封存儲存"

這個設計的關鍵在於：寫入與遺忘不再由程式寫死，而是交給模型以語言判斷。警告是一段系統訊息，模型讀到之後，自己決定哪些事實值得存下來。換言之，記憶管理本身也成了一種語言行為，第 6 週談過的記憶風險（把推測寫成事實、留下過期的資訊）也隨之而來。

8.5取用與遺忘：哪一段記憶該浮上來

記得愈多，愈需要決定此刻該想起什麼。

記憶流（memory stream）：Park et al.（2023）的生成式代理把每一次觀察都記成一條帶時間戳記的紀錄。需要回想時，每條紀錄依三項分數加總排序，三項各自先正規化到 0 與 1 之間，權重預設相等：

分數 ＝ α_新近 · 新近性 ＋ α_重要 · 重要性 ＋ α_相關 · 相關性

新近性隨時間指數衰減，原論文以遊戲世界中的小時計，衰減因子為 0.995；重要性由模型替每條紀錄打 1 到 10 分；相關性是紀錄與當前問題的嵌入相似度。

8.6重建，而不是取回

人的回憶不是播放錄影，而是每一次都重新講一遍故事。

Bartlett（1932）請英國受試者反覆重述一則美洲原住民的故事〈鬼魂之戰〉，發現每次重述，細節都會流失，陌生的情節會被改寫成受試者熟悉的樣子。他據此主張，記憶是依據既有基模（schema）所做的重建。四十年後，Loftus 與 Palmer（1974）把這個主張帶進語言：同一段車禍影片，只要問題裡的動詞不同，受試者對車速的估計就跟著改變。

實驗二更進一步：一週後再問受試者「是否看到碎玻璃」（影片中並沒有）。先前聽到 smashed 的一組，答「有」的比例約為 32%，聽到 hit 的一組約 14%，未被問車速的對照組約 12%。動詞不只影響估計，還把不存在的細節寫進了記憶。

8.7記憶壓縮：記得少一點，記得對一點

視窗再大也有上限，KV 快取再省也有成本。壓縮要回答的是：哪些可以丟，丟了之後還剩下什麼。

脈絡壓縮（context compression）：在不改動、或只少量改動模型權重的前提下，把要放進脈絡的內容縮小。依被壓縮的對象，大致可以分成五類：

前兩類在詞元的層次上動手，壓完的結果仍是文字；後三類壓的是模型內部的表示，壓完的東西只有模型讀得懂。這條界線決定了一件事：壓縮後的記憶能不能被人檢查、被另一個模型接手（見本週的記憶轉移實驗）。

刪詞：讓記憶變成電報

自訊息量（self-information）：一個詞元在上下文中的「意外程度」，I(w_t) ＝ −log₂ p(w_t | w_<t)。Selective Context 用小模型計算每個詞元的資訊熵，直接刪掉高預測性、低資訊量的詞元，只留關鍵實詞給大模型；LLMLingua 沿用同一思路，報告在部分任務上可壓縮到約 20 倍而表現損失不大。LLMLingua-2 改為訓練一個分類器，逐詞判斷「保留或刪除」。

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

name = "uer/gpt2-chinese-cluecorpussmall"          # 任一小型中文因果語言模型
tok, lm = AutoTokenizer.from_pretrained(name), AutoModelForCausalLM.from_pretrained(name)

def compress(text, keep=0.5, protect=("不", "沒", "非")):
    ids = tok(text, return_tensors="pt").input_ids
    with torch.no_grad():
        logp = lm(ids).logits.log_softmax(-1)[0, :-1]
    nxt = ids[0, 1:]
    info = -logp[torch.arange(len(nxt)), nxt] / torch.log(torch.tensor(2.0))  # 位元
    toks = tok.convert_ids_to_tokens(nxt)
    k = max(1, int(keep * len(toks)))
    top = set(info.argsort(descending=True)[:k].tolist())
    top |= {i for i, t in enumerate(toks) if t in protect}   # 白名單
    return "".join(t for i, t in enumerate(toks) if i in top)

軟壓縮 (soft compression)：只有模型看得懂的小抄

另一條路是不刪字，而是訓練模型把一段文字「讀進」少數幾個特殊詞元。Mu et al.（2023）在指令後面插入幾個要旨詞元（gist tokens），並修改注意力遮罩，讓後面的詞元只能看到要旨詞元、看不到原始指令；模型因此被迫把指令的內容壓進這幾個位置。他們報告可把提示壓縮到最多約 26 倍。ICAE（Ge et al., 2024）則以自編碼器的方式，把長脈絡壓成約四分之一長度的記憶槽。但因此失去人類可讀性（不可稽核），且綁定特定模型權重。

KV 快取壓縮 (KV Cache Eviction & Merging)：留下哪些鍵與值

第三類方法直接處理 8.2 節的那筆記憶體帳。StreamingLLM（Xiao et al., 2024）發現，最前面的幾個詞元會吸收大量注意力，成為「注意力匯點」（attention sink）；只要保留這幾個詞元與最近的一段視窗，模型就能穩定處理極長的串流。H2O（Zhang et al., 2023）則保留累積注意力最高的「重擊詞元」（heavy hitters）。這些方法省下大量記憶體，代價卻不是平均分攤的。Chen et al.（2026）以多條指令的提示測試五種驅逐方法，發現不同指令被刪除的速度並不相同；在中等壓縮率下，「不得透露系統提示」這類防禦指令可能先失效，造成系統提示外洩。他們提出的補救之一，是把關鍵指令列入白名單，強制保留。

代理的壓實：摘要裡混進了什麼

長時間執行的代理，歷史紀錄遲早會超過視窗。常見的做法是「壓實」（compaction）：把較早的歷史改寫成一份摘要，再接著工作。8.6 節已經看到，摘要會漂移。Min 與 Chen（2026）進一步追蹤失敗的執行紀錄，發現 83% 的失敗可以追溯到代理照著摘要中的某一條去做，而那一條大多找不到任何環境輸出的支持：它是壓縮器自己推論出來的。他們的解法很簡單：不刪歷史，而是逐條檢查摘要，刪去沒有來源的條目；擔任檢查者的，正是 W07 談過的 System One 模型 Jev。另一條路線是把壓實納入訓練，讓模型在強化學習中同時學會做事與寫摘要（Li et al., 2026，CompactionRL）。

附註：Min 與 Chen（2026）在 AppWorld 與 OfficeBench 上報告，來源檢查讓跨次執行的可靠度提高 2.1% 至 8.9%，代理使用的詞元數沒有增加。

光學壓縮：越舊的記憶越模糊

最出人意表的一條路線，是把文字畫成圖。DeepSeek-OCR（Wei et al., 2025）以少量視覺詞元編碼一整頁文件，再由解碼器把文字讀回來：在文字詞元數不超過視覺詞元十倍時，辨識精確度約為 97%；壓縮到約二十倍時，降到約 60%。作者據此提出一個構想：較舊的對話可以畫成解析度愈來愈低的圖片，用愈來愈少的詞元保存，像人的記憶一樣逐漸模糊。這只是構想，論文本身只做了文字辨識的實驗。

回顧：取回與重建之間

回到本週問題。各種記憶機制不是「像」或「不像」人，而是落在取回與重建之間的不同位置。

Lab 實務：記憶轉移（memory transfer）

若「記憶」真的寫在模型外面，就應該能拿出、搬運、交給另一個模型繼續用，這也是檢驗它算不算記憶的實驗。

課堂練習（約 25–30 分鐘）。兩人一組，或一人開兩個對話視窗亦可：

1. 養成。在模型 A（例如 Claude／GPT／Gemini 擇一）進行一段有延續性的對話：使用者偏好、專有名詞、尚未完成的任務。請模型把「值得長期保存」的內容整理成一份 MEMORY.md（建議含：事實、偏好、未決問題、來源或時間戳；分開「已確認」與「推測」）。
2. 抽出。把該檔案（或等價的工作脈絡／封存條目）存成獨立文字檔，結束與 A 的連線。不要複製整段聊天紀錄。
3. 移植。開模型 B（最好是不同廠商或不同規模）。系統提示只放：你是接班的助手；以下是前任留下的記憶檔；先讀檔再回答。把 MEMORY.md 貼入後，用同一組追問測「還記不記得」。
4. 對照。另開一個空白的模型 B（不給記憶檔）當對照組。比較：哪些問句在有檔／無檔時答案不同？哪些「記得」其實只是檔案裡的字被讀回來？

* The user's name is <name>.
    * Evidence: User said "call me <name>". Date: [YYYY-MM-DD].

Imported from: <ChatGPT | Claude | Grok | …>

可觀察的現象（寫進筆記即可）：格式漂移（B 改寫了欄位）、事實被補完或捏造、時間戳失效、專有名詞發音／別名對不上、以及換了模型之後，「個性」還在不在。

延伸：代理之間如何共享記憶

多代理系統裡，記憶不再只是「我與模型」的私人筆記，而變成可讀寫的共同資源。不過至少有四件事要討論：

• 寫入權。誰可以追加、誰可以覆寫、誰只能讀？一個代理的「推測」被另一個當成「事實」寫入，錯誤會跨代理傳播。
• 命名空間。個人記憶、任務記憶、團隊記憶是否分開？共同基礎（common ground）需要共享；隱私與角色邊界需要隔離。
• 一致性。兩個代理同時改同一條記憶，或一個還在用舊摘要、另一個已清出原文——以誰為準？需不需要版本或時間戳？
• 取用協議。共享索引用同一套切塊與嵌入嗎？若代理 A 用關鍵詞、B 用語意向量，它們「想起」的會是同一件事嗎？

課堂討論

1. 圖 8.4 中，把切塊調到一句，再問「石虎住在哪裡？」。除了加大切塊，還有哪些辦法能保住「牠們」的先行詞？
2. 如果一個代理只用 RAG、從不摘要，它還會「忘記」嗎？它的遺忘和人的遺忘有什麼不同？
3. Loftus 與 Palmer 的問題措辭改變了受試者的記憶。使用者提問的措辭，會不會也改變 RAG 取回的內容？請舉例。
4. 圖 8.6 的三項權重應該固定，還是隨任務調整？準備報告和聊天，該想起的記憶有何不同？
5. 遞迴摘要會漂移，逐字保存會占空間。你會如何替 A3 的代理設計記憶，兼顧兩者？
6. 記憶轉移實驗裡：B 答對了，算不算「B 記得」？若你改把整段聊天紀錄貼給 B，和只貼 MEMORY.md，哪一種更像記憶、哪一種更像複讀？
7. 若兩個代理共享同一份記憶檔，A 寫入「使用者姓王」，B 稍後寫入「使用者姓黃」——系統該拒絕、合併，還是保留衝突並標註來源？這和人類共同基礎的修復有何異同？
8. 圖 8.9 中，演算法最先刪去的是「不」。請列出另外三類「頻率高、資訊量看似低，卻不能刪」的詞，並說明它們承載了什麼語意。
9. 軟壓縮的記憶只有原模型讀得懂。如果 A3 的代理日後要換模型，你會選擇哪一種壓縮？為什麼？

閱讀

• Lewis, P., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. arXiv:2005.11401
• Packer, C., et al. (2023). MemGPT: Towards LLMs as operating systems. arXiv:2310.08560
• Tulving, E. (1985). How many memory systems are there? American Psychologist, 40(4). doi（選讀）

講義另引：Baddeley & Hitch (1974)；Brown (1973) A First Language；Chen, A., et al. (2026) The pitfalls of KV cache compression；Chevalier et al. (2023) AutoCompressors；DeepSeek-AI (2024) DeepSeek-V2（MLA）；Ge et al. (2024) ICAE；Jaeger (2010)；Jiang et al. (2023) LLMLingua；Li, Y., et al. (2023) Selective Context；Li, Yujiang, et al. (2026) CompactionRL；Liu, Z., et al. (2024) KIVI；Min & Chen (2026) Source-judged compaction；Mu et al. (2023) Gist tokens；Pan et al. (2024) LLMLingua-2；Reyna & Brainerd (1995)；Wei, H., et al. (2025) DeepSeek-OCR；Xiao et al. (2024) StreamingLLM；Xu et al. (2024) RECOMP；Zhang et al. (2023) H2O；Bartlett (1932) Remembering；Cowan (2001)；Ebbinghaus (1885)；Fillmore (1982) Frame semantics；Hsieh, C.-P., et al. (2024) RULER；Karpukhin et al. (2020) DPR；Liu et al. (2024) Lost in the middle；Loftus & Palmer (1974)；Park et al. (2023) Generative agents；Robertson & Zaragoza (2009) BM25；Tulving & Thomson (1973)。