做AI Agent记忆管理时，向量数据库到底该存什么？

我们线上是分层存的，原始对话单独放文档库，向量库只塞提炼后的“事实+意图”，比如“用户偏好川菜，最近在控糖”，再带上时间戳和来源。摘要确实容易丢细节，所以关键实体还是得抽出来单独存结构化字段，检索时用元数据过滤兜底。成本这块不用太纠结，向量库存储本身不贵，贵的是无效检索拖垮推理，宁可多存几条精炼的也别把整段聊天灌进去。

我现在的做法是向量库里只存“可独立成句的事实”，比如“用户不吃香菜”“偏好Python而不是Java”，每条都带时间戳和来源会话ID。原始聊天记录扔冷存储，摘要作为payload字段挂在向量旁边，检索时先拿向量召回再用摘要过滤。这样召回准很多，也不会因为摘要太干丢细节。实体关系我也试过，但维护成本高得离谱，除非你的场景特别依赖推理链，不然先跑通“原子事实”这层就够用了。

我们生产环境里向量库只存“可独立成句的事实”，比如“用户对花生过敏”“偏好靠窗座位”，不存原始对话也不存纯摘要。每条记忆带上时间戳和来源会话ID，检索时先按相似度召回再按时间衰减重排。实体关系其实更适合放图数据库，向量库塞太多结构化标签反而会稀释语义信号。你可以试试把摘要和原始片段分两个collection，先粗筛再精排，成本能降不少。

我们生产环境是把每轮对话拆成“用户意图+实体+时间戳”存一条，原始消息另存冷库，向量库只放摘要向量加元数据。检索时先用元数据过滤时间范围和实体，再跑相似度，精度能上来不少。纯存全文确实不行，噪声太大，但只存摘要会丢指代，最好把关键实体单独拎出来做字段。

我们线上也是踩过全量存的坑，检索出来全是寒暄和语气词。现在只向量化“带上下文的短摘要”，比如用户偏好、关键决策和实体关系，原文丢冷存储，需要时按ID回查。意图标签单独存元数据做过滤，别硬塞进向量里，不然相似度会被标签稀释。你们摘要用LLM实时生成还是异步跑？实时延迟有点扛不住。

我存的是“用户偏好+触发场景”的键值对，全文向量纯属给自己挖坑。

这事儿我也踩过坑，一开始把整段对话塞进向量库，检索出来全是“嗯嗯好的”这种没营养的东西。后来我改成存“原子记忆”，就是每轮对话里抽出来的独立事实，比如“用户对花生过敏”“用户偏好深色模式”，每条记录还带上时间戳和来源会话ID。光存意图标签太干了，Agent回起来像机器人，我一般会把标签跟原始片段的关键实体绑一起，比如“过敏：花生”后面跟一句用户当时的原话摘录。实体关系图那套我也试过，维护成本太高，小团队根本扛不住，最后退回成“摘要+关键实体列表+情感倾向”三个字段。检索时先用元数据过滤（比如只查最近三个月的），再做向量相似度，精度能提不少。存储成本嘛，别存全文，存抽出来的三元组和一句话摘要就够了，反正原始记录在业务库里还能捞回来。你们有没有试过把用户反馈显式写回记忆库？我觉得那个比啥都管用。

我们线上是拆成三类存：用户事实（比如偏好、身份）、对话摘要、原始片段，分别打不同tag，检索时按intent路由再混合排序。全文裸向量确实不行，噪声太大，但摘要单独用又太干，得配合原始chunk做召回后再重排。实体关系我们没硬塞进向量库，而是走图库，向量只管语义相似，别让它干结构化的活。成本上冷数据降维或换小模型，热数据才用大embedding，能省不少。

我现在的做法是向量库里只存原子级的记忆单元，比如“用户不吃香菜”这种，而不是整段对话。每条记录带上类型标签和时间戳，检索时先按类型过滤再算相似度，精度高很多。摘要和原文可以分开存，向量库放摘要做召回，命中后再去关系库拉原文补细节。成本上别怕多存几条，真正贵的是检索出一堆没用的上下文把窗口撑爆。

我们现在不存原始对话，存的是“用户说了什么+为什么这么说”的组合，比如意图标签加上关键实体和当时的情境摘要。纯摘要确实太干，但全文又太吵，折中办法是让LLM先抽一层结构化事件再向量化，检索时用标签过滤加语义召回。成本上可以冷热分离，高频偏好放向量库，低频细节丢关系库按需拼上下文。你们有没有试过把时间衰减加进相似度打分里？

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？