记忆型Agent为何用向量数据库?

这道题问的是[[Agent]]记忆为什么用[[向量数据库]]，其实本质是在问：怎么让智能体记住那些没法用精确条件表达的东西。比如用户说“上次我有个类似的退款问题”，你没法用SQL的where条件去匹配，因为关键词不一定对得上。所以向量数据库解决的是语义检索，不是精确查询。但真正落地的时候，它跟关键词检索不是二选一，而是互补的。我会用 [[Hybrid Search]]，把关键词和向量两条路结合起来，比如先用[[BM25]]粗筛，再用向量精排，这样既能处理同义改写，又能保证高频词不丢。

[[Embedding]]模型的选择，我主要看几个前提。先说领域适配，通用场景我用BGE或者E5就够了，但如果是医疗法律这种垂直领域，我会用领域数据微调过的模型，否则语义可能偏。接着说上下文长度，Agent的记忆可能很长，比如一个对话回合超过4K tokens，那模型窗口必须支持8K以上，不然切碎了语义就丢了。再补充效率成本，端侧部署我用轻量模型，云端可以用更大的。还有一点，我倾向于选经过[[指令微调]]的模型，比如instructor系列，这样检索时query和doc的表示更对齐。

向量化表示的设计，我重点做两件事。一个是元信息增强，不只是存文本向量，还会把session_id、时间戳、实体标签作为metadata。这样检索时可以先用实体过滤缩小范围，比如用户提到“北京”，我就只查metadata里包含“北京”的chunk，再算向量相似度，效率能高很多。另一个是多粒度表示，我会同时存句子级向量和会话级向量。句子级用来精细检索，比如找具体的一句话；会话级用来主题召回，比如找整个对话的脉络。切分策略上，我按语义切分，而不是固定长度，保留“用户问-Agent答”完整回合作为独立chunk，这样上下文不割裂。

检索策略我走两阶段。粗排用 [[HNSW]] 索引，快速召回Top-100，距离度量用余弦相似度，阈值低于0.7的直接丢掉。精排用 [[Cross-Encoder]] [[重排]]Top-20，精度高但慢，所以只对少量候选做。这里有个坑：如果延迟敏感，比如要求200ms以内，我会放弃重排序，纯用HNSW加向量相似度，或者用轻量的 [[ColBERT]] late interaction。另外，时间衰减很重要，我会在相似度分数上乘一个指数衰减因子，优先近期记忆，不然几周前的对话权重太高会误导。举个例子，客服退款场景，用户说“上次那个优惠券用不了”，系统通过向量检索找到上次对话，结合时间衰减，优先匹配最近的沟通记录，再根据实体过滤锁定具体订单，这样召回率能提高不少。

不过重排序这一步有个取舍：Cross-Encoder精度高但延迟高，尤其当候选集超过50条时，响应时间可能翻倍。我上线前会做压测，看延迟和精度的平衡点。如果业务对延迟更敏感，我会考虑用双编码器加[[蒸馏]]后的重排模型，或者干脆不做重排，只靠粗排加阈值过滤。

所以整体上，我更倾向于把向量数据库看成是Agent记忆的“语义索引”，跟关键词、时间过滤这些传统手段配合使用，而不是替代它们。前提是embedding模型要选对，元信息要设计好，检索流程要压测过。如果忽略这些，常见失败场景就是召回结果跟问题不相关，或者延迟超标，导致Agent反应慢半拍。