如何设计Agent的记忆模块

大模型 天生就有有记忆缺陷 。

就同HTTP请求一般，每次对大模型的请求，都是无状态的。

所以为了让大模型拥有记忆 ，就需要在每次请求里 面，携带上 他之前说过的话。从而模仿他的记忆，让他知道，自己是谁，为谁服务，服务什么，服务对象又有什么性格等等...

但是这就会遇到一个很严肃的问题。大模型的推理文本长度是有限 的。

也就是我们常说的上下文 。这就牵扯出 一个问题：

主流大模型的上下文长度也就1Mtoken左右。而国产大模型通常也就是256K左右。

这就意味着上下文长度是有限的 ，所以非常宝贵。

同时因为大模型的注意力机制的原因，上下文越长 ，推理的所需耗费 的几何倍上升 ，并且精度 也会越低 。

所以，记忆模块的设计，就至关重要！

为好奇的小伙伴，补充一下什么是注意力机制 ：

他的核心就是自注意力机制 （Transformer），不再像RNN那样串行处理，而是一次性看待整段输入（可以并行处理）。
做法就是，对每个token 生成Q 、K 、V 三个向量，计算出所有token的Q 与K 的相似度得分 ，拿着这个相似度去和V做一个加权求和 。从而能让token和语境关联。
就相当于把苹果手机中的，苹果从原本的向量区间，拉到手机品牌向量区间那样。

一、记忆模块设计

在开始搭建记忆模块之初 ，最先做的并不应该是RAG！

而是在domain协议层，定下契约 。之后不论是写入、召回都会按照固定的格式进行。

通常记忆模块 会分四层 。
感知记忆 （当前的输入）、短期记忆 （上下文的压缩）、长期记忆 （沉淀后的记忆）、结构化记忆（存储的用户的习惯、爱好、目标等）。

而我在设计中，

我对所有的 memory 记忆类型 分为三种：

• 结构化type。
• 长期记忆。
• 上下文压缩后的摘要，服务与上下文恢复。

同时，为了保护用户隐私，我又分了三层。

• self：用户个人隐私，像习惯、爱好、自己的上下文等。
• org：组织级别的，拥有对应权限的人可以共享。
• platform：平台运维级别的。

虽然有些功能，暂时不需要实现，但是协议是非常有必要提前定义好的。

二、记忆治理

第一部分，已经定义好类型 与权限 了。

但在入库前，更重要的就是定入库的规则。

我这里分为了两层：

• 软规则：写进 prompt ，让 LLM 按照给定的规则去"理解和生成"。
• 硬规则：负责最终"裁决和落库"，像权限的过滤，字段的合法性校验等，尽可能的规避LLM生成的错误。

其中，软规则中的prompt更多是在告诉LLM。

• 什么样的内容算高价值
• 什么东西不能记
• Fact、Document、摘要等等，给出来的东西应该是什么类型
• 生成的是json格式
• 等等...

硬规则 ，就是对生成的东西进行一次强校验。

就像权限范围 、TTL 等，都是需要自软规则 里面抽取出来，经过 一遍硬规则 的手。

确保一切没有问题。在入库。

我举个简单的例子：

比如用户说：

"以后请你回答时更简洁一点。我最近 30 天目标是刷 200 道题。"

LLM 可能提两个候选：

[
  {
    "type": "fact",
    "namespace": "user_preference",
    "key": "answer_style",
    "value": {"style": "concise"},
    "source_kind": "explicit_user_statement",
    "scope_hint": "self",
    "confidence": 0.95
  },
  {
	 "type": "fact",
	 "namespace": "oj_goal",
	 "key": "current_goal",
	 "value": {"goal": "200 problems in 30 days"},
	 "source_kind": "explicit_user_statement",
	 "scope_hint": "self",
	 "confidence": 0.91,
	 "ttl_hint": {
	   "mode": "duration",
	   "days": 30,
	   "reason": "用户明确说最近 30 天目标"
	  }
]

• 先判断一下致信度，太低的话直接skip掉。
• 然后根据LLM生成的，开始配置一下权限，在过滤一遍TTL等，最后入库。

三、上下文压缩，以及上下文恢复

现在定义了如何记忆类型、以及允许什么样的内容入库。

但是另一个影响对话质量的就是上下文的质量。

也就是说：

下一轮对话到来时，如何在有限的 token 预算里，把真正有价值的上下文重新恢复给模型。

技术上，我了解最粗暴的方式，就是滑动窗口 ，自动将越界的删除掉。

其次就是摘要压缩 ，对越界的内容进行压缩后，在携带。但是这样会导致精度问题。

后来就有了层次压缩 ，如：最近10轮的压缩，10~50轮的轻度压缩，更后方的重度压缩。

但是这会导致一些重要信息，被裁剪忽略掉。

所以后来又出现了重要性过滤。不在一味的按先后顺序。等等...

所以我这里做的是分层恢复 策略。

我会将上下文分为好几层进行控制：

第一层放：最新的决策和最近确认过的重要结论，优先级放到最高。

第二层放：当前还没有闭环的问题、待确定的问题。

第三层放：会话级别摘要，用来恢复长对话主线，而不是历史回放。

第四层放：已经沉淀出来的用户偏好、阶段目标、画像信息等。

第五层放：一下RAG召回的经验等。

第六层放：最近的几轮的对话内容。

其中，我把用户最近一次的问题，放到了最后。

因为我之前在读arXiv的一篇论文（读 "archive"），参考他上面的内容：

模型对长上下文的中间信息利用很不稳定，相关信息放到开头或结尾表现会更好。

有兴趣的可以瞅瞅：

四、RAG 切分入库

之前已经把协议、提示词、上下文的组成搞定。

但在，我规定的上下文组成的第五层中，是需要RAG召回的，这也就意味着，需要先切分入库。

切分入库的质量越高，召回的质量就越高。

最简单的切分方式就是固定大小 切分，但是这样很死板，上下文语义会很不完整。

所以就有了语义切分 ，按照标点符号进行切分。

但有时，先表格、函数代码这些特殊情况，是无法进行语义切分 的，所以就需要对这些专项内容切分 。

其实还有成本更高的父子切分，就是你检索到子片的时候，会把与他相连的上下文一起带回。

而我的本项目，需求不高，所以做的是语义切分，

• 首先按段落切分
• 如果越界了在按照符号切分。
  并且会保留相邻chunk的150个字符，用来维持语义。

最后在入qdrant与mysql的时。

我是以mysql作为真相数据源存document与元数据。

在 qdrant 里面存的是向量 、权限范围 用于筛选、和对应mysql的数据索引，用于去数据库中检索。

我在我的代码中也考虑过专项内容切分，考虑到了表格、代码，但是暂时还没有引入语法解析工具这种更高精度的切分。

五、混合召回策略

在上下文压缩的时候，我已经把需要召回的内容，表述的很明白。

但是那个时候为了表述清楚 ，内部的组成结构，所以我说的还是比较直白 和死板。

通常我会先判断一下两个数组：
最近决策 ：只有 key_points 不会空才加载。（这个是对话中的要点）
待完成内容 ：只有 open_loops 不为空才加载，他的存在可以让上下文的连续性更丝滑。
对话压缩后的摘要 ：长对话必备！
Fact格式化内容 ：这个达到阈值才能被加载，比如用户性格爱好，最近有啥目标 等用户画像 。
RAG检索 ：若检索出来了，需执行度高于阈值，且top前5。

最后就是一些tools信息，与用户最近一次的问题了。

六、我想说的话

本次整体是我自己手写搭建的。

目的就是为了深入理解记忆机制的底层原理 。

但是如果要在生产级别项目中，为了追求快速开发。

可以复用像 mem0，这种记忆框架。