我对比了纯向量检索和混合检索，给AI代理加了个记忆层

先说背景。我最近在做一个客户项目，核心是让AI代理处理一批跨部门的售后工单。跑了两周，遇到一个很典型的问题：代理今天能答对的问题，明天换个说法就答不对了。不是模型不行，是它没有记忆。上一轮对话里的关键信息，比如客户ID、设备型号、之前承诺过的处理时限，下一轮就丢了。

所以我把目光投向了记忆层（memory layer）这个方向。简单说，就是给AI代理配一个外置的存储和检索系统，让它能记住历史对话和业务上下文。现在市面上主流方案是向量检索（vector search），也就是把文本转成高维向量，按语义相似度捞回相关内容。听起来合理，但实际跑下来问题不少。

我做了个对照测试。用同一批工单数据，一套纯向量检索，一套混合检索（hybrid retrieval），跑了大概三天，喂了上百轮模拟对话。结果挺有意思：

最让我头疼的是纯向量检索在处理精确标识符上的表现。比如客户报修时报了个设备序列号，向量检索经常把它当成普通语义内容，捞回来一堆相似但不相关的东西。后来我查了查，这其实是行业里公认的痛点。有一篇Oracle的开发者博客直接点明，混合检索能把语义召回和精确匹配结合起来，让代理选到人类操作员一眼就能认出的那条记忆。Reddit上也有团队在吐槽，说纯向量检索的精度尾巴越来越差，最后他们改成了向量加BM25（一种经典的关键词匹配算法）并行跑，再用RRF（排名融合）合并结果。

我这边复现了同样的思路。底层用了PostgreSQL的tsvector做关键词召回，配合一个开源的向量库做语义召回，最后用RRF把两个结果排序融合。改完之后，工单里那些设备型号和客户ID基本都能稳定命中了。有一轮测试，代理需要从三个月前的一封邮件里找到某个配件的采购价格，纯向量检索翻了半天没找到，混合检索一次就捞出来了。

不过也不是没有坑。第一条，混合检索不是简单加个模块就完事。两个检索通道的权重怎么调，RRF的参数怎么设，都需要根据实际数据反复试。我这边调了两轮才找到一个相对稳定的组合。第二条，数据清洗的工作量一点没少。记忆层里存的东西如果本身是脏的，比如日期格式不统一、字段有缺失，检索再准也白搭。这点跟之前做Grab那个项目时遇到的制造业数据孤岛问题很像，底层数据质量永远是第一道坎。

另外我想说一句，记忆层和检索（retrieval）其实是两件事。检索回答的是「我的数据里有什么」，记忆回答的是「之前发生了什么」。生产环境里的代理，两者都得有。Redis那篇博客说得挺直白，光有检索没有记忆，代理就是金鱼脑，七秒忘光。

这套方案目前我已经部署到测试环境，跑了大概一周。客户那边的反馈是，工单处理的一次性解决率肉眼可见上去了。下一步我打算把记忆的分层做得更细一点，参考MindStudio说的三层架构，自动对话日志、结构化记忆文件、向量库各管一摊，再加一层手动编辑的入口，让业务人员能直接修正代理记错的东西。

对我个人来说，这次测评最值的一点是确认了方向：混合检索不是噱头，是代理记忆落到生产环境的基本盘。纯向量方案的便利性确实诱人，但真要扛业务，精确性那根弦松不得。

---

本文编译自 Hacker News，原文：https://github.com/deepmemteam/deepmem
版权归原作者所有，本文为基于公开报道的编译与独立分析。