向量检索没错，但最相似的记忆未必是对的

过去几年里，我试了好几次教AI Agent模仿我的语气写东西。虽然没太成功，但这对我来说是个绝佳的学习机会，让我深入研究了RAG、Agent记忆和其他进阶话题。

我对自己最初的设计迭代了不少，那个设计基本上就是把整篇博客文章塞进系统提示词当范例。我搭过一个挺有意思的Agent记忆版本，但它有短板。后来我换到Oracle，设计了一套三层记忆的混合检索，客观说比之前好，但依然不够完美。

其实记忆部分还不错，问题出在检索上。我花了很久才想明白，加载相关少样本示例这件事，我到底错在哪。看看你能不能发现这个问题：

SELECT id, content, topic, VECTOR_DISTANCE(embedding, :q, COSINE) AS distance
FROM posts
WHERE user_id = :userId AND platform = :platform AND is_deleted = 0
ORDER BY distance
FETCH APPROX FIRST :k ROWS ONLY

发现了吗？没有？那是因为这段代码技术上挑不出毛病。它确实找出了和问题最相似的记忆。问题在于，最相似的记忆不总是正确的那条。

记忆是会堆积的。写了几年之后，我的库里有一条支持某种方案的旧文，也有一条后来改变主意的更新。还有讲事件驱动架构、事件溯源、事件流的三篇，在嵌入空间里彼此非常接近。另有一篇讲无服务器定价，一篇讲冷启动，用词高度重合，观点却完全不同。从相似度分数看，这些组几乎是一回事。真正区分它们的，只是一个日期、一个具体术语，或者文章的实际论点。

所以检索是跑通了，但喂给模型的上下文是垃圾。

标准解法是加一个重排器，它帮助提升的是相关性，而不只是相似度。

嵌入一条记忆的时候，模型根本不知道以后会有人问它什么。查询被嵌入后，和库里的向量算出一个相似度分数。交叉编码器是重排模型的一种，它把查询和记忆放在一起看，按“这条记忆多大程度回答了这个问题”来打分。这意味着相关性更高，结果通常也更好。

但有个代价。交叉编码器在查询时运行，每个候选、每次请求都要跑一遍，查询延迟必然增加。

如果相关性提升足够明显，这点延迟可以接受吗？一定程度上可以。延迟高到影响用户体验，那就不值；如果只是轻微增加，那完全值得。

于是我搭了一个基准来评估这个取舍。起点是Oracle生产级RAG评估指南里的方案，对比关键词、向量、混合三种检索在标注查询上的表现。然后我在每一种之上都加了一层重排器，看为了这点延迟能换回多少相关性。重排器用的是BGE，以ONNX模型的形式加载进数据库，打分直接在查询里完成，不需要额外调用一个服务。

先过滤，再排序

RAG有意思的地方在于它涉及多种查找方式。词法检索擅长标识符、代码和名称；向量检索通过嵌入找到语义相近的数据。我分别测了这两种，也测了把两个排序列表用倒数排名融合（RRF）合并起来的混合检索。

两条路径跑的是同一个范围过滤条件：租户匹配，所有者为空或等于当前所有者，过期时间为空或晚于当前时间。

这个WHERE子句处理的是“资格”，和“相关性”是两回事。我不希望一条已经过期的记忆回到结果里，比如2025年那套构建AI Agent的看法，我早就翻篇了。更不希望别的租户的数据冒出来，那是安全事故。Oracle的指南把这类过滤列为多租户数据的强制项，它们在排序之前执行，下游处理的都是本来就允许出现的记忆。

设定基线

在判断重排器有没有价值之前，得先知道这些查询的基线值。除了延迟，还需要归一化折损累计增益（nDCG）和召回率，这样才能把相关性和延迟放在一起客观衡量。

基线测量取K=10，也就是前10条结果。

nDCG衡量排序把相关项放在靠前位置的能力，越高越好，但它不衡量答对了多少。向量检索的0.753，意味着这些排序平均拿到了完美排序应有分数的75%。

召回率不看顺序，只看正确的记忆有没有进前10。0.865意味着应该返回的记忆里，大约87%确实回来了。这两个指标都对照已知的标准答案集来评估，也就是说，给定语料和查询，我事先就知道正确结果应该是什么。

从基线结果能看出：词法检索快，但准确度不算高；向量检索能捞回更多，代价是延迟，排序质量仍不理想；把两个排序融合起来结果最好，额外延迟很小。

单看基线，如果延迟不出现断崖式下跌，混合检索就是那个要被挑战的检索方式。

重排器带来的结果

接下来用同样的基准跑一遍，加上重排器。在Oracle里，它只是检索流程末尾多出来的一步。