ICLR 2026 | LightMem：把大模型「長期記憶」的成本打下來

大模型已經(jīng)很強，但一旦進入 “長對話、跨多輪、多任務(wù)” 的真實智能體交互場景，模型很快就會遇到兩類老問題：

一是上下文窗口有限，越聊越長時不可避免地 “塞不下”；二是經(jīng)典的 lost in the middle，即使塞得下也未必用得好。

于是，給大模型配 “外部記憶系統(tǒng)” 尤為重要：把對話寫進長期記憶、需要時再檢索出來。但現(xiàn)實很快給出了代價 —— 記憶系統(tǒng)往往非常貴：頻繁調(diào)用大模型做總結(jié) / 抽取、實時做沖突消解與更新、長鏈路的維護開銷，最終讓 “有記憶的智能體” 在工程上難以承受。

這篇工作提出 LightMem：一個在 “效果” 和 “效率” 之間更平衡的記憶系統(tǒng)。核心目標很直接：

在不犧牲準確率的前提下，把 token、API 調(diào)用次數(shù)和運行時延降下來。

• 論文標題：LightMem: Lightweight and Efficient Memory-Augmented Generation
• 論文鏈接：https://arxiv.org/abs/2510.18866
• 代碼鏈接：https://github.com/zjunlp/LightMem

為什么現(xiàn)有記憶系統(tǒng) “能用但太貴”？

從主流范式來看，LLM 記憶系統(tǒng)大多是這樣工作的：把原始對話按 turn/session 切分；每一段都讓 LLM 做總結(jié) / 抽取，寫入向量庫 / 知識圖譜；新信息到來時，再讓 LLM 在線做更新 (add/delete/merge/ignore)；推理時檢索相關(guān)記憶拼到 prompt 里回答。

問題在于，不管是 user 側(cè)還是 assistant 側(cè)，真實對話場景中含有非常多的冗余信息：寒暄、重復確認、冗余解釋等等。現(xiàn)有系統(tǒng)往往 照單全收，導致：

1) 冗余信息直接進入管線：token 消耗飆升，而且可能反而干擾 in-context learning；

2) 切分粒度僵硬：按 turn 太細會導致總結(jié)調(diào)用爆炸，按 session 太粗又容易主題混雜，最后總結(jié)不準；

3) 在線更新太重：更新與遺忘在 test time 強綁定，長任務(wù)延遲高，而且 LLM 還可能在更新時 “誤刪” 信息。

LightMem 的出發(fā)點是：人類記憶并不是 “所有信息都進長期記憶”，而是有一套高效的分層機制：

感官記憶先過濾 → 短時記憶組織整合 → 長時記憶在睡眠時離線鞏固。

LightMem 的核心思路：三段式 “類人記憶” 管線

LightMem 把記憶系統(tǒng)拆成三個輕量模塊 (對應(yīng)如下的 Light1/Light2/Light3)：

Light1：感官記憶 (Sensory Memory)

目標：快速過濾無用信息、把輸入壓縮到 “值得記” 的部分，并進行主題切分。

Light2：短時記憶 (Short-Term Memory, STM)

目標：按主題把對話組織成結(jié)構(gòu)化單元，降低總結(jié)調(diào)用次數(shù)，同時減少主題混雜。

Light3：長時記憶 (Long-Term Memory, LTM)+ 睡眠更新 (Sleep-time Update)

目標：把昂貴的記憶更新從在線推理中 “拿出來”，在離線并行地做去重、合并、修復與鞏固。

Light1：感官記憶 —— 先壓縮，再切主題

輕量壓縮：把冗余 token 在系統(tǒng)輸入端過濾掉

LightMem 使用一個輕量壓縮模型 (論文默認采用 LLMLingua-2) 對原始輸入做預壓縮：

保留信息量更高、語義更關(guān)鍵的 token，把大量冗余 token 提前過濾掉并擋在 pipeline 之外。

論文實驗也驗證：在合理壓縮率下 (50% 到 80%)，LLM 依然能理解壓縮后的上下文，準確率基本不受影響。

混合主題切分：避免 “按窗口切” 的粗暴做法

僅靠固定窗口 (turn/session) 很難適配開放對話。LightMem 做了一個混合切分策略：

• 用注意力信號找到候選 topic 邊界 (局部峰值)；
• 再用相鄰片段的語義相似度做二次確認；
• 取二者交集作為最終切分點，降低 attention sink、注意力稀釋等噪聲影響。

Light2：主題感知 STM—— 用 “內(nèi)容邊界” 替代 “窗口邊界”

在拿到 topic segments 后，LightMem 把它們以 {topic, turns} 的結(jié)構(gòu)送入 STM buffer。

當 buffer 達到 token 閾值時，才觸發(fā)一次 LLM 總結(jié)，對每個 topic 生成更結(jié)構(gòu)化的 summary，并寫入 LTM。

相比 “每一輪都總結(jié)一次”，這種做法直接帶來兩點收益：

• 調(diào)用次數(shù)降低：總結(jié)不再是 N 次，而是按 buffer 觸發(fā)的更少次數(shù)；
• 總結(jié)更準確：輸入被 topic 約束，不容易 “把 A 主題的細節(jié)總結(jié)進 B 主題里”。

論文的消融實驗也顯示：去掉 topic segmentation 會帶來明顯準確率下降 (GPT/Qwen 都一致)。

Light3：睡眠更新 —— 把開銷最高的部分從在線推理中剝離

記憶系統(tǒng)最貴、也最容易出錯的一步，往往是 “更新 / 遺忘”。

現(xiàn)有系統(tǒng)經(jīng)常在 test time 做 hard update：合并、刪改、沖突消解都在線執(zhí)行，延遲高且風險大。

LightMem 的策略是 “兩段式更新”：

在線只做 Soft Update：先寫入，不糾結(jié)

測試時新記憶條目到來，LightMem 直接插入 LTM (帶時間戳)，不做復雜更新。

這極大降低了在線延遲，并避免 LLM 在實時更新中誤判沖突導致信息丟失。

離線做 Parallel Update：每條記憶維護 “可更新隊列”

離線階段 (sleep time) 觸發(fā)更新：

對每個條目構(gòu)建一個 update queue (只允許 “新的更新舊的”，即時間戳約束 tj ≥ ti)，然后把這些更新操作并行執(zhí)行。

并行化的關(guān)鍵好處是：

傳統(tǒng)在線更新存在順序依賴 (讀寫約束) 導致串行累計延遲；而 LightMem 把更新拆成多個獨立隊列，可以離線并行，整體更快。

結(jié)果：不僅更準，而且便宜很多

論文在兩個長記憶基準上驗證了 LightMem 的效果與效率：

• LongMemEval (LongMemEval-S)
• LoCoMo

并在不同 backbone 上測試：GPT-4o-mini 、 Qwen3-30B-A3B、GLM4.6。

整體結(jié)論非常清晰：LightMem 在準確率上超過基線，同時把成本打下來。

論文報告的代表性結(jié)果包括：

• 在 LongMemEval 上，LightMem 相比強基線準確率最高提升約 7.7% / 29.3% (不同設(shè)置與 backbone)；
• 總 token 消耗降低最高可達 38× / 20.9×，API 調(diào)用次數(shù)降低最高可達 30× / 55.5×；
• 如果只看在線 test-time 成本，節(jié)省幅度更夸張：token 最高 106× / 117×，API 調(diào)用最高 159× / 310×。

LightMem 是一套面向真實長交互場景的 “輕量記憶系統(tǒng)” 答案：

它不追求讓記憶機制越來越復雜，而是用更接近人類記憶分工的方式，把冗余擋在入口，把維護放到離線，把代價控制在可部署的范圍內(nèi)。

如果你正在做長對話助手、長期在線 agent、或者任何需要 “記憶但又怕貴” 的系統(tǒng)，這篇工作值得細讀。

我們將 LightMem 的方法論與工程經(jīng)驗沉淀到 OpenMem 社區(qū) ，推動記憶機制的開放共建與演進。

OpenMem 旨在共建一個 AI 記憶科學探索與產(chǎn)業(yè)實踐的全球協(xié)作社區(qū)，讓記憶成為 AI 的新 computer layer，促進 Memory Engineering 開源開放，成為 “記憶研究者的家” 與 “記憶技術(shù)的標準化基地”，支撐企業(yè)級學術(shù)級開發(fā)者級的記憶應(yīng)用生態(tài)。

作者簡介

方繼展，浙江大學人工智能碩士在讀，師從張寧豫副教授。研究方向為 Continual Learning、LLM/Agent Memory 與大模型知識編輯，聚焦記憶系統(tǒng)、自進化 Agent 與模型可控更新。以第一/共一作者身份在 ICLR、ACL、ACM MM等國際頂級會議發(fā)表/接收多篇論文。提出并開源面向 Agent 的輕量化長期記憶框架 LightMem，獲得較高社區(qū)關(guān)注（GitHub 600+ Star），受到MIT technology review邀請專訪，并收到國內(nèi)多家投資機構(gòu)/大模型廠商的創(chuàng)業(yè)交流邀請。