跳到主要内容

Agent Memory 与 RAG 数据治理

Memory 和 RAG 一旦从 demo 走向长期运行，问题就会从“能不能用”变成：

  • 写进去的东西靠不靠谱
  • 什么时候该更新
  • 什么时候该删除
  • 检索结果为什么会逐渐变脏
  • 长期运行后系统为什么越来越不稳

这篇文档讨论的，就是这一层数据治理问题。

1. 为什么 Memory 和 RAG 需要单独治理​

在最小 demo 里：

  • Memory 往往只是存几条用户偏好
  • RAG 往往只是把几篇文档切块后丢进向量库

但系统一旦长期运行，问题会马上出现：

  • 旧偏好失效
  • 临时状态误写成长期记忆
  • 文档版本更新后检索命中过期内容
  • chunk 切得过碎或过粗
  • rerank 没压住噪音
  • 敏感内容被错误保留或召回

所以这里要解决的不是“如何接一个 memory / vector store”，而是：

如何让它们长期保持可用、可信、可清理。

2. Memory 最常见的问题​

2.1 什么都记​

这是最常见的问题。

如果把：

  • 临时指令
  • 一次性偏好
  • 噪音信息
  • 错误推断

都写进长期记忆，系统很快就会被污染。

2.2 记了却不分层​

很多系统把所有“记忆”放在同一个池子里，但实际上至少应区分：

  • 用户偏好
  • 用户画像
  • 长期任务约束
  • 工作会话摘要
  • 可验证事实

2.3 记了却不失效​

长期记忆如果没有：

  • TTL
  • 过期策略
  • 版本策略
  • 人工修正入口

就会不断累积陈旧内容。

3. RAG 最常见的问题​

3.1 知识源不干净​

如果源头内容本身：

  • 冲突
  • 过期
  • 未审查
  • 带指令污染

检索质量再好也会有上限。

3.2 Chunk 策略不合理​

典型问题：

  • 切得太碎，语义断裂
  • 切得太长，召回不准
  • 元数据不完整
  • 版本信息丢失

3.3 检索后不做筛选​

如果召回后直接原样送给模型，常见结果是：

  • 噪音过高
  • 上下文膨胀
  • 依据不稳定

3.4 更新机制缺失​

文档更新后，如果旧版本还在库里占主要权重，系统会持续输出过期结论。

4. 一个实用的治理分层​

4.1 Source Layer​

源头层解决：

  • 数据从哪里来
  • 谁能写入
  • 版本怎么管理
  • 什么内容可进入知识系统

4.2 Storage Layer​

存储层解决：

  • 如何切块
  • 如何索引
  • 元数据怎样保留
  • 保留多久

4.3 Retrieval Layer​

检索层解决：

  • 用什么召回
  • 要不要混合检索
  • 是否需要 rerank
  • 是否需要过滤条件

4.4 Injection Layer​

注入层解决：

  • 哪些检索结果进入上下文
  • 进入前要不要摘要
  • 是否标注来源和时间

4.5 Memory Policy Layer​

记忆策略层解决：

  • 哪些内容可写入长期记忆
  • 哪些只能进入短期状态
  • 谁可以修正或删除

5. Memory 写入的最小策略​

可以先用三个问题来判断一条信息是否应该进入长期记忆：

  1. 这条信息是否稳定
  2. 这条信息是否会被未来任务复用
  3. 这条信息是否可以被验证或追溯

如果这三个问题里有两个答不上来，通常不该直接写入长期记忆。

6. RAG 数据治理里优先要做的几件事​

6.1 给 chunk 保留元数据​

至少建议保留：

  • 来源
  • 时间
  • 版本
  • 权限级别
  • 文档类型

6.2 明确更新策略​

例如：

  • 文档更新时是否重建索引
  • 旧版本是否保留
  • 召回时是否优先最新版本

6.3 增加 rerank 或过滤层​

召回只是第一步。

如果没有后续筛选，很多系统会在“能查到”之后直接掉到“查到太多”。

6.4 做脏数据回收​

例如：

  • 删除过期 chunk
  • 标记低可信度来源
  • 清理不再可访问的文档

7. Prompt Injection 和数据治理的关系​

这两件事关系很紧。

因为一旦：

  • 网页抓取
  • 用户上传文档
  • 外部知识同步

进入知识系统，攻击面也会一起进入。

所以数据治理至少要考虑：

  • 来源可信度
  • 审核流程
  • 指令污染检测
  • 敏感字段处理
  • 权限隔离

8. 在浏览器与检索混合系统里要特别注意什么​

如果系统既能：

  • 浏览网页
  • 做 RAG 检索
  • 写 memory

风险会进一步叠加。

因为错误信息可能会经历这条链：

  • 外部页面 -> 检索资料 -> 上下文 -> 长期记忆

一旦这条链缺少校验，污染就会从一次错误变成长期错误。

9. 第一轮优先落地的治理清单​

  1. 长期记忆写入要有显式规则
  2. 临时状态默认不进入长期记忆
  3. chunk 保留来源、时间和版本
  4. 检索结果进入上下文前做筛选或摘要
  5. 旧知识有更新与失效机制
  6. 敏感数据和公开数据分层存放
  7. 给 memory 和 RAG 都准备人工修正入口

10. 和这个专题里的哪些内容最该一起看​

最适合一起看的有：

11. 小结​

Memory 和 RAG 的关键问题，后面往往都不是“有没有接上”，而是“有没有逐渐变脏”。

如果没有治理策略，系统越跑越久，通常会出现：

  • 记忆越来越乱
  • 检索越来越噪
  • 回答越来越不稳

所以这层工作真正要处理的是：

  • 什么能进
  • 什么该留
  • 什么该删
  • 什么该更新