让大模型真正「记住你」|LightMem:轻量高效的记忆增强生成框架
本文也提供英文版本 English。
导读
当我们向 AI 助手说"上次你帮我规划的那个旅行方案",它只会礼貌地回答:"对不起,我没有上次对话的记忆。" 这不是一个小缺陷,而是当前大语言模型在实际应用中的根本性障碍——模型没有长期记忆。
每次对话都是一张白纸,用户不得不反复重新介绍自己的背景、偏好与上下文。随着 AI Agent 越来越多地被部署在真实场景中,这一问题愈发突出:一个真正有用的个人助手,必须记住你是谁、你喜欢什么、你之前说过什么。
LightMem 正是为解决这一问题而生。它是一个轻量、高效、模块化的 记忆增强生成(Memory-Augmented Generation) 框架,为大语言模型和 AI Agent 提供结构化的长期记忆存储、检索与更新机制。LightMem 已被 ICLR 2026 正式接收,并已在 GitHub 上完整开源。
代码库:https://github.com/zjunlp/LightMem
论文(ICLR 2026):https://arxiv.org/abs/2510.18866
1. 为什么大模型需要长期记忆?
大语言模型在推理、对话和代码生成方面已展现出令人惊叹的能力,但它们本质上是 无状态(stateless) 的——每次推理都在一个独立的上下文窗口内完成,窗口之外的信息完全不可见。
当前业界主要有两种应对方案,但各有其局限:
方案一:扩大上下文窗口。 近年来模型的上下文长度从 4K 扩展到了 128K 乃至更长,但这带来了二次方级别的计算开销,且模型在超长上下文中的"中间遗忘"(lost-in-the-middle)问题依然严重。简单地把所有历史对话塞进 context 并不是可持续的解法。
方案二:外挂向量数据库(RAG)。 将历史对话存入向量数据库,检索时召回相关片段。但原始对话往往充斥冗余信息,直接存储效率低下;更重要的是,同一用户的记忆往往彼此矛盾或需要更新("我之前喜欢辣,但最近肠胃不好改吃清淡了"),简单的向量检索无法处理这种记忆冲突与演化。
LightMem 的出发点正在于此:记忆不只是存储,更需要理解、压缩、去冲突和组织。 它将对话历史转化为结构化的、语义丰富的记忆单元,并在适当时机以最低的代价完成更新。
2. LightMem:记忆管理的系统性解法
核心设计理念
LightMem 的设计围绕三个核心原则展开:
轻量(Lightweight):记忆的存储与检索必须足够高效,不能成为系统的性能瓶颈。LightMem 通过预压缩、摘要生成和离线批量更新,将 Token 消耗控制在最低水平。
结构化(Structured):原始对话是非结构化的流水账,而真正有价值的记忆是结构化的事实单元。LightMem 将对话中的关键信息抽取为带有元数据(时间戳、主题、实体标签)的记忆条目,支持精准检索。
可演化(Evolvable):用户的状态和偏好会随时间变化,记忆系统必须能够识别并处理冲突信息,及时更新已有记忆,而非简单地追加新条目。
架构总览
LightMem 采用模块化架构,整个记忆生命周期被拆分为清晰的处理阶段:
这种流水线设计使每个模块都可以独立替换,用户可以根据自身资源和需求灵活组合配置。
3. 关键技术模块详解
对话预压缩与主题切分
真实对话中充满冗余:闲聊、重复确认、填充词。在将对话存入记忆系统之前,LightMem 使用 LLMLingua-2 或基于熵的压缩算法对原始文本进行精简,在保留核心语义的前提下大幅降低后续 LLM 调用的 Token 消耗。
与此同时,一段对话往往横跨多个话题(从旅行计划聊到工作问题再到饮食偏好),主题切分模块识别对话中的语义边界,将长对话切割为独立的话题片段。这样不仅使记忆的粒度更加精细,也避免了不同话题的信息彼此干扰。两个模块可以通过 precomp_topic_shared 配置共享底层模型的中间计算结果,进一步节省开销。
记忆提取与离线更新
话题片段经过 LLM 处理,被提炼为结构化的记忆条目(Memory Entry),包含:核心事实、关联实体、时间戳、话题标签,以及一段压缩摘要。这是 LightMem 与简单 RAG 的核心差异所在——存储的不是原始对话,而是经过理解和组织的语义单元。
离线更新是 LightMem 处理记忆演化的关键机制。当新的记忆条目与已有条目存在语义重叠时(相似度超过可配置阈值 score_threshold),系统会触发冲突检测并调用 LLM 进行知识融合,将旧记忆更新为最新状态,而非简单地追加重复内容。这一过程以批处理方式运行,将 LLM 调用次数和 Token 消耗降至最低。
混合检索策略
LightMem 支持三种检索模式,适应不同场景:
embedding:纯语义向量检索,适合语义模糊的开放性问题context:基于 BM25 的上下文检索,适合包含精确关键词或时间的结构化查询hybrid:混合策略,先用上下文检索过滤候选集,再用向量相似度重排,在召回率与精确率之间取得更好平衡
此外,LightMem 支持层次化检索:首先检索会话级摘要以确定相关时间段,再深入该时间段的细粒度记忆条目,从而在保证检索效率的同时减少无关噪声的干扰。
4. 快速上手 LightMem
安装
git clone https://github.com/zjunlp/LightMem.git
cd LightMem
conda create -n lightmem python=3.11 -y
conda activate lightmem
pip install -e .
初始化记忆系统
from lightmem.memory.lightmem import LightMemory
config_dict = {
"pre_compress": True,
"pre_compressor": {
"model_name": "llmlingua-2",
"configs": {
"llmlingua_config": {
"model_name": "/path/to/llmlingua-2-bert-base-multilingual-cased-meetingbank",
"device_map": "cuda",
"use_llmlingua2": True,
}
}
},
"topic_segment": True,
"precomp_topic_shared": True,
"memory_manager": {
"model_name": "openai",
"configs": {
"model": "gpt-4o-mini",
"api_key": "your_api_key",
"max_tokens": 16000,
"openai_base_url": "your_base_url",
}
},
"index_strategy": "embedding",
"text_embedder": {
"model_name": "huggingface",
"configs": {
"model": "/path/to/all-MiniLM-L6-v2",
"embedding_dims": 384,
"model_kwargs": {"device": "cuda"},
},
},
"retrieve_strategy": "embedding",
"embedding_retriever": {
"model_name": "qdrant",
"configs": {
"collection_name": "my_chat_memory",
"embedding_model_dims": 384,
"path": "./my_chat_memory",
}
},
"update": "offline",
}
lightmem = LightMemory.from_config(config_dict)
存储记忆
session = {
"timestamp": "2025-06-15",
"turns": [
[
{"role": "user", "content": "我最喜欢吃开心果口味的冰淇淋,我的猫叫小橘。"},
{"role": "assistant", "content": "记住了!开心果口味和小橘。"}
],
]
}
for turn_messages in session["turns"]:
for msg in turn_messages:
msg["time_stamp"] = session["timestamp"]
lightmem.add_memory(messages=turn_messages, force_extract=True)
离线更新与记忆检索
# 批量处理记忆冲突与知识融合
lightmem.construct_update_queue_all_entries()
lightmem.offline_update_all_entries(score_threshold=0.8)
# 检索相关记忆
question = "我的猫叫什么名字?"
memories = lightmem.retrieve(question, limit=5)
print(memories)
MCP Server 支持
LightMem 同时提供 MCP(Model Context Protocol) 服务端,可直接接入支持 MCP 协议的客户端(如 Claude Desktop、Cursor 等):
pip install '.[mcp]'
# 以 HTTP 模式启动服务(端口 8000)
fastmcp run mcp/server.py:mcp --transport http --port 8000
客户端 MCP 配置文件示例:
{
"yourMcpServers": {
"LightMem": {
"url": "http://127.0.0.1:8000/mcp"
}
}
}
5. 实验结果
我们在 LongMemEval 和 LoCoMo 两个长期记忆基准数据集上,将 LightMem 与 Mem0、A-MEM、MemoryOS 等主流记忆框架进行了全面对比。
以 LoCoMo 数据集为例(backbone: gpt-4o-mini,judge: gpt-4o-mini):
| 方法 | 整体准确率 ↑ | Multi | Open | Single | Temp | 总 Token 消耗(k)↓ | 总耗时(s)↓ |
|---|---|---|---|---|---|---|---|
| FullText | 73.83 | 68.79 | 56.25 | 86.56 | 50.16 | 54,884 | 6,971 |
| NaiveRAG | 63.64 | 55.32 | 47.92 | 70.99 | 56.39 | 3,870 | 1,884 |
| A-MEM | 64.16 | 56.03 | 31.25 | 72.06 | 60.44 | 21,665 | 67,084 |
| MemoryOS | 58.25 | 56.74 | 45.83 | 67.06 | 40.19 | 10,519 | 26,129 |
| Mem0 | 36.49 | 30.85 | 34.38 | 38.41 | 37.07 | 25,793 | 120,175 |
实验揭示了一个值得关注的现象:将全文直接塞入上下文(FullText)能获得最高准确率,但代价是海量 Token 消耗;而大部分现有记忆框架在大幅增加构建和更新开销的同时,准确率反而显著低于 FullText 基线。 这表明,如何在记忆压缩的同时保留关键信息,是记忆系统设计的核心难题。
完整的实验数据(包含不同 backbone 和 judge model 的完整结果)已开放于 Google Drive,并提供一键复现脚本,欢迎下载验证。
6. StructMem:面向事件结构的层次化记忆
2026 年 2 月,我们在 LightMem 基础上发布了 StructMem,进一步提升了记忆系统对复杂叙事场景的处理能力。
普通的扁平化记忆提取将对话中的事实视为独立的知识片段,彼此割裂。但现实中,许多重要信息天然具有事件性结构:一件事发生在特定时间、涉及特定人物、由特定原因导致、产生特定结果。这些要素之间的关联才是真正有价值的记忆内容。
StructMem 引入了事件级别的记忆绑定(event-level memory binding)和跨事件记忆连接(cross-event memory connection),将记忆组织为保留时间绑定和因果关系的层次化结构。在涉及时序推理、因果追溯和人物关系理解的复杂问答场景中,StructMem 相比扁平记忆能够显著减少关键信息的丢失。
在 LightMem 中启用 StructMem 只需修改一个配置项:
config_dict["extraction_mode"] = "event"
详细文档参见:StructMem.md
7. 展望:记忆系统的未来
LightMem 是我们在记忆增强生成方向上迈出的重要一步,但我们深知这条路还很长。以下是我们正在积极探索的方向:
KV Cache 预计算
对于固定的长期记忆内容,可以预先计算并缓存其 KV 表示,在推理时直接复用而无需重新编码,从而实现无损加速(离线预计算)或有损但高效的在线预计算。这将大幅降低记忆增强推理的延迟。
上下文与长期记忆的协同调度
当前的记忆系统更多是"召回后拼接",而如何动态地决定哪些记忆放入上下文、哪些按需检索,是一个值得深入研究的调度问题。
多模态记忆
当前 LightMem 主要处理文本记忆。随着多模态 Agent 的普及,如何存储和检索图像、音频中的关键信息,是下一阶段的重要课题。
多智能体协作与知识共享
在多 Agent 协作场景中,记忆不再是单个 Agent 的私有状态,而是需要在 Agent 之间共享、同步和协商。如何设计支持多智能体知识共享的记忆架构,将是未来智能体系统的重要基础设施问题。
我们真诚希望 LightMem 能成为研究者构建具备长期记忆的 AI 系统的实用工具。项目完全开源,欢迎 Star、Issue 和 PR。
👉 代码与文档:https://github.com/zjunlp/LightMem
👉 论文(ICLR 2026):https://arxiv.org/abs/2510.18866
👉 Demo 视频:YouTube | Bilibili

