用向量数据库做AI Agent记忆，遇到重复内容怎么去重？

我们之前也遇到过这个，后来是加了个相似度判断再入库，用Chroma自带那套距离计算，超过阈值就直接更新旧记忆而不是新增，效果还行。内容哈希不太建议，因为用户表述稍微变一下哈希就变了，照样存重复。摘要可以考虑，但得注意别把关键细节弄丢，我建议你结合时间戳，对近期高频问题做合并，旧的直接归档，检索时优先看新鲜的。对了，你检索时是不是没加时间衰减？加上能减少混淆。

这题我熟，之前做记忆模块也卡在这。别用哈希，太硬了，语义重复但表述不同的情况会漏掉；LLM摘要成本高，还会把细节搞丢。我最后是写入前先拿新文本和最近N条记忆算余弦相似度，超过0.92就直接跳过，再把时间戳作为metadata，检索时按时间衰减权重，这样既去重又不影响精度。另外Chroma的upsert配合自定义ID也能用，比如用对话轮次加内容hash做ID，重复写入自然覆盖。

说实话这个问题我太有同感了，之前做客服机器人也踩过类似的坑。内容哈希看着简单，但对话稍微换个说法就完全匹配不上，比如“查下订单”和“订单号是多少”其实是一回事，哈希根本认不出来。LLM摘要倒是能抓住语义，但每次调用模型成本不低，而且摘要本身也可能有偏差，反而把关键信息弄丢了。我后来用的折中方案是相似度阈值加时间窗口，存之前先拿新文本跟最近N条记忆做余弦相似度，超过比如0.92就直接跳过，这样既不用动老数据，也不会让库无限膨胀。不过有个副作用是如果用户真的想更新某条信息，比如改地址，新内容可能因为太相似被拒掉，所以还得额外加个“强制写入”的标记或者用时间戳判断是不是更新的。你用的Chroma其实自带过滤功能，可以试试用collection的where条件筛掉旧记录，或者干脆给每个记忆加个expire字段，定期清理。检索精度这块我倒觉得不用太担心，因为真正相关的问题往往表述差异很大，冗余反而容易干扰top-k结果，去重之后召回质量通常只会更好。你现在的库大概堆了多少条了？如果量不大，手动清理一轮看看效果再决定策略也行。

我最近也在搞类似的，试过内容哈希但太死板，用户稍微换个说法就存重了。后来改成先算embedding相似度，超过0.92就直接覆盖旧记录，保留最近时间戳的版本，检索准确率反而上来了。你可以加个轻量级LLM做摘要，只存压缩后的记忆，但注意别把关键细节丢了。Chroma本身支持按metadata过滤，配合时间窗口能省不少事。

相似度阈值+时间戳组合过滤挺实用，Chroma里直接查top-k再按余弦相似度去重就行。

可以试试先算embedding相似度，高于0.95的直接覆盖旧记录，既省空间又保留最新上下文。

之前做记忆系统也踩过这个坑，纯靠内容哈希太机械，用户换个说法就漏了。我后来是先用LLM抽关键意图+实体，再拿这个去做相似度匹配，阈值设到0.92左右，命中就直接复用旧记录，没命中才写新的。时间戳还是要加的，毕竟上下文有时效性，但只影响排序权重，不影响去重判断。还有个偷懒办法是定期跑一次聚类，把相似度高的记忆合并掉，Chroma里直接删旧的就行，检索精度影响不大。

相似度阈值配合时间戳挺靠谱的，低于阈值就覆盖旧的，既能去重又不丢上下文。

直接用哈希去重太死板了，语义相近但表述不同就漏掉了，还是得靠向量相似度来搞。

相似度阈值加时间戳就够了，别搞太复杂，LLM摘要反而容易丢细节。

试过用余弦相似度0.9去重，配合最近N条强制保留，效果还行。

我之前也遇到过这个问题，最后是用相似度阈值加时间窗口搞定的。存之前先拿新问题和库里最近的几条记忆算一下cosine距离，超过0.9就直接跳过，低于0.8才存，中间地带用LLM简单判断下是不是真重复。另外给每条记忆加了expire时间，超过两周的自动清理，这样库不会无限膨胀。哈希去重不太行，因为同一句话可能在不同语境下含义不一样。

相似度阈值+时间戳窗口挺够用的，超过阈值就更新原向量，别让库膨胀。

相似度阈值加时间戳基本够用，亲测能滤掉八成废话，检索也没怎么掉点。

我之前也踩过这个坑，Chroma里堆了几万条重复向量，检索时召回的全是相似片段，反而把关键信息淹没了。试过内容哈希，但用户表达稍微变一点（比如加个“请问”）就失效了，而且对同义改写完全没招。后来改用LLM摘要+时间戳组合，每次存之前先把新对话和历史最近几条拼一起生成一个“状态摘要”，再和库里已有的摘要做相似度比对，超过0.92就只更新时间戳，不新增向量。这样既保留了语义上的去重，又不会因为阈值太严而丢掉真正的新信息。不过有个问题得提醒你，摘要本身会损失细节，比如用户中途改口说“其实是另一个订单”，这种转折单靠摘要可能抓不住，所以我额外留了个原始文本的短期缓存（比如保留最近50条不压缩），只有更早的才走摘要去重。至于相似度阈值，建议你根据实际场景调，别迷信0.9，我这边试下来0.85到0.95之间波动挺大，跟你的embedding模型关系也很大。还有个土办法，可以在入库前先用BM25粗筛一遍，把明显重复的过滤掉，再交给向量库做精细去重，能省不少API调用。总之别指望一个策略通吃，混合着来更稳。

我之前也踩过这坑，直接上相似度阈值卡在0.95以上就跳过写入，配合内容哈希做第一道粗筛，能干掉八成重复。摘要其实更适合做长期记忆压缩，短期对话直接用原始文本加时间戳更稳，不然LLM摘要本身也会有信息损耗。你试过检索时按时间衰减权重吗？同样的query，新记忆应该比旧记忆优先级高，这样就算有重复内容影响也会小很多。

相似度阈值+时间戳窗口过滤挺实用的，摘要反而容易丢细节，建议先试试前者。

先算个余弦相似度，超过0.95直接覆盖旧记录，保留最新时间戳就行，成本低还不影响召回。

试试相似度阈值去重，配个时间衰减权重，比哈希和摘要都稳，检索精度基本不受影响。

相似度阈值+时间戳挺实用的，低于阈值直接覆盖旧的，能省不少空间。

LLM摘要成本有点高，可以先哈希粗筛再向量细查，两层过滤更稳。

我之前也遇到过同样的问题，后来是用相似度阈值+时间窗口解决的，比如新向量和已有记录cosine相似度超过0.95就直接丢弃，这样能挡住大部分重复提问。不过阈值得调，太松会漏掉语义相近但表述不同的，太紧又容易误杀。内容哈希对完全一样的文本有效，但用户稍微改个标点或说法就没辙了，所以还是得结合LLM摘要做归一化。另外建议在存之前先跑一次检索，命中就直接复用旧的memory条目，顺便更新下时间戳，这样比事后清洗省心多了。

相似度阈值+时间戳组合挺实用，超过阈值就更新旧记录而不是新增，能省不少空间。

可以先算余弦相似度，超0.9就只更新摘要和时间，检索精度基本不受影响。

说实话这问题我太有同感了，之前做客服机器人也栽在这上面。我当时试过内容哈希，简单是简单，但用户稍微换个说法比如“查一下订单号”和“我的订单号是多少”，哈希值就完全不一样，根本去不掉重复。后来我换成LLM摘要，先把每轮对话抽成关键意图再存，效果好了不少，但延迟和成本又上来了，得看你对实时性要求高不高。还有个思路是检索时下手，别光靠写入时去重，你可以在召回后加一道相似度过滤，比如设定余弦相似度阈值，超过0.95的直接丢弃，只保留时间戳最近的那条，这样就算库里堆点垃圾也不影响最终返回。不过Chroma本身没有内置这功能，得自己写个后处理逻辑。另外我踩过个坑，就是别只对用户问题去重，还得把Agent的回答一起考虑进去，有时候问题不同但答案一样，那种冗余更坑人。你现在是单轮记忆还是多轮窗口？如果是后者，我建议你做个滑动窗口缓存，最近N轮强制保留，更早的才做去重，这样精度和存储能平衡些。

这个坑我太熟了，之前用FAISS也遇到过一模一样的问题。我个人觉得纯靠内容哈希不太行，因为用户表达可能换几个词但语义相同，哈希直接就当成新内容了，反而更乱。我现在是这么处理的：写入前先拿query去库里做一次相似度检索，如果top1的余弦相似度超过0.92，就直接复用旧记录，把新对话的时间戳和关键信息合并进去，而不是新插一条。这样检索精度几乎不受影响，还能顺势更新记忆的时效性。另外LLM摘要我试过，效果不错但开销太大，用在实时写入路径上不现实，更适合做离线清理任务，比如每天跑一次把相似度高的旧摘要合并掉。Chroma本身没有内置这功能，但你可以用collection的query接口自己实现这个逻辑，也不复杂。还有个小技巧，给每条记忆加个“最后访问时间”字段，做一个衰减权重，这样就算重复了，检索时也能优先匹配最近活跃的那条，混淆问题会好很多。