LightMem用3招重新設(shè)計了LLM的記憶，結(jié)果出乎意料
1. LLM 的“記性”又貴又差
在超長多輪對話里，LLM 面臨兩大痛點：
- 上下文窗口有限——“中間丟失”現(xiàn)象嚴(yán)重。
- 記憶系統(tǒng)昂貴——每輪都把原始對話塞進(jìn) LLM 做摘要/更新，Token 與 API 調(diào)用爆炸。
圖 1 現(xiàn)有記憶系統(tǒng) vs LightMem
如圖 1 所示，現(xiàn)有系統(tǒng)要么“全量硬存”，要么“逐輪硬更新”，冗余信息 > 50%，實時推理被拖垮。
2. 人類記憶的三把鑰匙
Atkinson-Shiffrin 模型把記憶分為：
階段 | 功能 | 對應(yīng) LLM 痛點 |
感覺記憶 | 毫秒級過濾無關(guān)刺激 | 冗余 Token |
短期記憶 | 秒-分鐘級主題整合 | 語義混雜 |
長期記憶 | 睡眠時離線鞏固 | 實時更新延遲 |
LightMem 直接把這套機制搬進(jìn)了 Transformer 時代。
3. LightMem 架構(gòu)：三盞“燈”點亮高效記憶
圖 3 整體架構(gòu)
模塊 | 昵稱 | 關(guān)鍵設(shè)計 | 效果 |
Light1 | 感覺記憶 | 預(yù)壓縮 + 主題分段 | 砍掉 20-80% 冗余 Token |
Light2 | 短期記憶 | 主題緩沖 + 到達(dá)閾值再摘要 | API 調(diào)用 ↓ 17-177× |
Light3 | 長期記憶 | 在線“軟更新”+ 睡眠離線并行合并 | 運行時 ↓ 1.7-12× |
4. 核心技術(shù)拆解
4.1 Light1：預(yù)壓縮 + 主題分段
圖 4(a)：不同壓縮率下 QA 準(zhǔn)確率幾乎不變，token 先砍一半
做法：
- 用 LLMLingua-2 給每輪對話打“保留概率”。
- 動態(tài)閾值 τ = 百分位(r)，只保留信息量最大的 token。
- 壓縮率 r=0.6 時，輸入 token ↓ 40 %，準(zhǔn)確率不掉。
4.2 Light2：主題級短期記憶
- 緩沖結(jié)構(gòu)：?
?{topic, [user_i, model_i]}?? - 到達(dá) Token 閾值后，一次性調(diào)用 LLM 生成摘要 → 入庫。
- 相比“逐輪摘要”，主題純度↑ → 摘要幻覺↓，圖 4(c) 顯示去掉該模塊 ACC 掉 6%。
4.3 Light3：睡眠期離線合并
- 在線階段只做“追加寫”，零延遲。
- 離線階段并行執(zhí)行“讀-改-寫”：每條記憶維護(hù)一個更新隊列 ??(e_i)，僅與更高時間戳的條目合并，可批量并行，總延遲從 O(N) → O(1)。
5. 實驗結(jié)果：又快又準(zhǔn)，全線 SOTA
表 1 在 LongMemEval-S（平均 110k Token）上與 6 個強基線Full-Text、Naive RAG、LangMem、A-MEM、MemoryOS、Mem0對比：
基于GPT和Qwen骨干網(wǎng)絡(luò)在LongMemEval上的實驗表明：LightMem在準(zhǔn)確率上超越強勁基線（最高提升10.9%），同時顯著降低token使用量達(dá)117倍，減少API調(diào)用達(dá)159倍，并將運行時間縮短超過12倍。
6. 關(guān)鍵消融：參數(shù)怎么選？
表 2 給出壓縮率 r 與緩沖閾值 th 的聯(lián)合調(diào)參：
- th↑ → 摘要批次↑ → API/時間↓，但 ACC 非單調(diào)。
- r=0.6 + th=512在 GPT 上取得最佳平衡點；Qwen 則偏好r=0.6 + th=768。
7. 案例：睡眠更新如何避免“誤刪”？
場景 | 硬更新 | LightMem 軟更新 |
用戶先去東京→再問京都 | 直接覆蓋為“計劃京都游”，東京信息丟失 | 追加寫入，兩地行程并存 |
離線合并時再做知識消歧，既保證實時性，又避免不可逆信息損失。
LightMem: Lightweight and Efficient Memory-Augmented Generation
浙江大學(xué) & 新加坡國立大學(xué)
https://arxiv.org/html/2510.18866
https://github.com/zjunlp/LightMem本文轉(zhuǎn)載自??PaperAgent??
