让大模型真正「记住你」|LightMem:轻量高效的记忆增强生成框架

Community Article Published March 1, 2026

本文也提供英文版本 English


导读

当我们向 AI 助手说"上次你帮我规划的那个旅行方案",它只会礼貌地回答:"对不起,我没有上次对话的记忆。" 这不是一个小缺陷,而是当前大语言模型在实际应用中的根本性障碍——模型没有长期记忆

每次对话都是一张白纸,用户不得不反复重新介绍自己的背景、偏好与上下文。随着 AI Agent 越来越多地被部署在真实场景中,这一问题愈发突出:一个真正有用的个人助手,必须记住你是谁、你喜欢什么、你之前说过什么。

LightMem 正是为解决这一问题而生。它是一个轻量、高效、模块化的 记忆增强生成(Memory-Augmented Generation) 框架,为大语言模型和 AI Agent 提供结构化的长期记忆存储、检索与更新机制。LightMem 已被 ICLR 2026 正式接收,并已在 GitHub 上完整开源。

Motivation

代码库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 采用模块化架构,整个记忆生命周期被拆分为清晰的处理阶段:

LightMem Pipeline

这种流水线设计使每个模块都可以独立替换,用户可以根据自身资源和需求灵活组合配置。


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. 实验结果

我们在 LongMemEvalLoCoMo 两个长期记忆基准数据集上,将 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

Community

Sign up or log in to comment