向量数据库做Agent记忆时，到底该存“原始文本”还是“embedding+原文”？

存原文加embedding，元数据带时间戳，检索按时间衰减加权，重复问题基本就没了。

我去年也踩过这个坑，每次把整段对话历史重新向量化，token烧得真的心疼，后来改成只对新产生的对话轮次做embedding，检索的时候用会话id做filter，重复问题就基本没了。存原始文本我觉得是必须的，不然检索回来只有一堆向量，你没法做后续的rerank或者给LLM拼上下文，光靠embedding根本不知道那条记忆到底说了啥。至于时间衰减，我试过加一个简单的指数衰减权重，老记忆分数会降，但别做得太激进，否则用户上周提过的偏好这周就忘了，体验反而差。重要性过滤我一般靠LLM打标，比如让模型判断这条记忆是临时信息还是长期偏好，只有后者才进长期库，不然库里全是“今天天气不错”这种垃圾。Pinecone和FAISS在Agent场景下差别还挺明显的，Pinecone省心但延迟和成本摆在那，FAISS本地快、免费，但得自己管持久化和扩容，小规模用FAISS完全够，上了百万级向量再考虑托管吧。

我踩过这个坑，只存embedding纯属自找麻烦，检索回来你还得反查原文，不如直接把原文塞metadata里，Chroma和Pinecone都支持。每次全量重新向量化太蠢了，按轮次或滑动窗口切块存，配个时间戳字段，检索时加个时间衰减权重，重复问题基本就没了。Pinecone和FAISS在Agent场景差别不大，小规模FAISS够用还省钱，量大了再迁Pinecone，别一上来就托管，调试起来反而麻烦。

我也踩过这个坑，整段历史反复向量化纯属烧钱，后来改成只对每轮新对话单独embedding，原文塞metadata里，检索命中后再拼上下文，token直接降了一大截。去重的话可以给每条记忆加个hash或者时间戳，检索时做个相似度阈值过滤，不然旧内容反复召回很烦。时间衰减我加了，按半衰期给score乘个系数，效果还行但别调太狠，不然早期重要信息全被压没了。Pinecone和FAISS我都用过，小规模本地FAISS够快够省，但记忆量上到几万条以后，托管服务的稳定性和运维省心程度确实香，看你的量级选吧。

存原文是必须的，不然检索回来只有一串向量你根本没法拼进prompt。我现在的做法是embedding只用来检索，metadata里存原文加时间戳和对话轮次id，检索时按相似度加时间衰减打个分再排序。整段历史反复向量化这个坑我也踩过，改成只对单轮问答做embedding会省很多，重复内容基本就没了。Pinecone和FAISS在延迟上差别不大，但托管服务省运维，小项目用FAISS就够了。

我踩过这坑，后来改成只存embedding加原文和元数据，原始对话单独存数据库，检索命中后再按id拉原文，token一下就降下来了。重复旧内容基本是没去重，存之前先算相似度过滤一层会好很多。时间衰减有用但别太激进，我一般给重要记忆打个权重标签，检索时加权就行。Pinecone省心但贵，FAISS本地快但要自己管索引和持久化，小规模FAISS够用，上量再换托管。

我也踩过重复向量化的坑，后来改成只对新增对话做embedding，原始文本丢metadata里，检索时再取出来拼上下文。时间衰减挺有用的，我加了个按天数的权重衰减，旧记忆排序自然就靠后了。Pinecone和FAISS在Agent场景下差别主要在延迟和运维，小规模本地FAISS够用，但要跨设备共享记忆还是托管省心。

我也踩过这个坑，早期就是把整段对话历史直接丢进去向量化，结果检索出来的全是高度相似的片段，token哗哗地烧。后来改成只存“单轮问答对”或者“一小段摘要”作为记忆单元，metadata里带上时间戳、对话ID和原文，embedding只负责召回，原文用来给LLM做上下文，这样清晰很多。存原始文本是必须的，不然召回之后你拿不到可读内容，还得再查一次库，反而更麻烦。时间衰减我建议做，最简单的就是按天数算个权重，检索时对旧记忆降权，不然半年前的闲聊会一直干扰当前任务。重要性过滤可以用LLM打个分，但别每轮都打，成本扛不住，可以异步或者按需触发。Pinecone和FAISS在Agent场景下差别挺明显的，前者省运维但延迟和费用随规模涨，后者本地快但得自己管索引和持久化，小规模FAISS够用，上量了再考虑托管。另外重复召回的问题，可以加个去重逻辑，比如按原文hash或者语义相似度阈值过滤，比单纯调top_k管用。

存原文加向量才靠谱，不然检索回来一堆没法用的ID，还得再查库。

我踩过这坑，千万别每次整段历史重存。我的做法是只对新增那轮对话做embedding，原文和元数据（时间戳、角色）一起放metadata里，检索命中后再按需取原文给LLM。时间衰减挺有用的，我加了个简单的指数衰减打分，重复旧内容少了很多。Pinecone省心但延迟和成本摆在那，本地FAISS快又便宜，就是得自己管索引和持久化，小规模Agent我倾向先用FAISS跑通。

存原始文本基本是必须的，不然检索回来一堆embedding你没法塞进prompt里用，metadata里挂原文是最常见的做法。你说的每次把整段历史重新向量化，这个思路本身就有问题，应该是按轮次或者按语义块切分后单独存，每块配自己的embedding和原文，而不是把历史越滚越长整体编码。重复旧内容多半是因为你存的粒度太粗，检索时相似度都挤在一起了，加个时间戳和去重逻辑会好很多。时间衰减我建议加，但别搞太复杂，简单按时间倒序加权或者只检索最近N天的就够，重要性过滤可以靠LLM打个分，但别每轮都打，成本扛不住。Pinecone和FAISS在Agent场景下差别没想象中大，主要差在运维和并发上，本地FAISS够用就先别急着上托管，等数据量上来了再迁。

只存embedding不存原文，检索回来你拿什么塞进prompt？还得再查一次库或者重新读对话日志，纯属给自己加活。我现在的做法是原文和embedding都存，但原文会做一层压缩摘要，比如把一轮完整对话压成一两句关键信息再向量化，这样token消耗能降不少。整段历史反复重新向量化这个坑我也踩过，检索出来全是近义重复，后来改成按对话轮次切分、每轮单独存，重复率明显下来了。时间衰减我加了，但没用纯时间函数，而是用“最近N轮优先+相似度加权”的混合排序，效果比单纯衰减好。Pinecone和FAISS在Agent场景下差别其实没那么大，真正影响体验的是你的切分策略和检索后的重排逻辑，托管服务省的是运维，不是效果。重要性过滤建议加，但不是靠模型打分，而是用规则先筛掉寒暄和工具调用日志，不然记忆库很快就被垃圾填满了。

存原文是必须的，不然检索回来一堆向量你根本没法拼进prompt里，embedding只是索引不是内容。我自己是原文加向量都存，metadata里再塞时间戳、session_id、消息类型这些，方便后面过滤和排序。你说的token爆炸，大概率是把整段历史反复向量化导致的，应该只对新增的对话轮次做embedding，历史的部分靠检索召回而不是重新灌进去。重复召回旧内容这事我也踩过，后来加了时间衰减和去重逻辑才好转，重要的事可以打个标记加权，但别指望模型自己判断重要性。Pinecone和FAISS在Agent场景下差别挺实在的，托管服务省心、支持元数据过滤和在线更新，本地FAISS快但得自己管持久化和扩容，量小无所谓，量一上来运维成本就出来了。