“语义缓存层”（5）—— 两阶段召回设计

在上一节里，我们讨论了怎么让语义缓存层对于业务等价更加敏感。接下来，我们来讨论一下第二个问题：怎么充分利用QA知识库？

在第三节中，我已经指出：QA层的知识也非常宝贵，需要在RAG的全流程中被充分利用。换而言之，QA层不仅仅是缓存，它也是一个知识库，只不过它的问题和答案都更碎片化、更短。

我重新思考了语义检索和高相似度得分的意义。我的简单直觉是：语义检索类似于我们在面对问题时的最初反应，当我们被问到一个问题，脑海中会立即浮现出几种类似的经历。这些经历并不一定正确、也不一定足以解决问题，但是通常来说会与目前遇到的问题存在关联。

我们会更加仔细地考虑这些知识，然后判断它们是否足以解决问题。即使不够，这些知识也能在后续的处理流程中带来启发。

换句话说，语义相似性并不一定意味着这就是答案，而是表明：这段经验值得考虑。

这种思维会改变语义缓存层的目标，接下来我会介绍我遵循这一思路出发得到的两阶段召回设计。

一、Strict Match

在语义缓存层的第一阶段匹配，核心目标是：

系统之前是否已经解决过这个问题了？

所以，这是一个相对来说比较严格的阶段，我们要求缓存中的问题是严格“业务等价的”：

图1：Strich Match(图由Gemini生成，小修)

在这里，相似度阈值会设定得相当高（我最终采用了0.92），如果候选答案能够在语义相似度上达到0.92以上，也能通过LLM的判定，那么系统将立即返回这个QA答案。

当然，你也可以用最便宜的模型把这个答案润色一下，让用户没那么容易看出我们的系统“偷了个懒”直接返回缓存，也就是我在小节3中指出的问题3。

二、Loose Match

如果Strict Match失败，那么QA层的知识也不会被轻易丢弃。这里的核心目标是：

找到可能相关的经验

图2：Loose Match(图由Gemini生成，小修)

我这里没有使用Rerank，这里的考量有三点：

1. 如果匹配到的QA数量并不是很多，那么它们的上下文长度极其有限，也许10个QA的上下文长度还没有一个doc chunk多；对于后续的RAG流程来说，对这点上下文做优化相当无所谓；
2. 如果匹配到的QA数量相当多，由于QA是十分碎片化的数据，你可能实际需要对上百的QA做重排，此时这些知识缺乏组织、各执一词，甚至很有可能重复论述同一个问题，上下文冗长。我认为使用小模型对这些东西作摘要是更好的方案。

这个层次引入之后，语义缓存层就有了两个作用：

• 快速识别并解决已知问题
• 作为独立知识库为后续流程提供高质量知识来源

这样，即使缓存没有命中，后续的RAG流程也可以从我的高质量QA数据集中获得收益。整个系统对于知识的利用率提高了。

三、总结

这两节里介绍的两种方案就是我对语义缓存层这个组件做的改进。我在五月末完成了改进后的测评，加入了Loose Match之后，系统的表现甚至比纯粹的RAG更好了。一些问题因为上下文变干净，模型在后续流程中表现更好；更重要的是，系统可以那些简单的问题采用简洁有效的回应，延迟也很低。

目前系统已经上线，希望我还能待到有足够数据继续优化这个系统的那天。

到这里我的语义缓存层工作就告一段落了，不过，除了我提到的问题外，其实还有很多问题没有解决：

• QA和Doc RAG知识不一致时，怎么处理？
• 语义缓存层中引入了很多步骤（LLM Check, Strict Match, Loose Match），这些步骤会产生一些“信心”信号，这些信号能被充分利用吗？
• 回答问题的频率远远高于文档的更新，同时语义缓存层的Cache Miss Case恰好是“系统还不会的问题”的有效指标，能不能充分利用这些数据做数据的持续迭代更新？

我也很好奇这些问题的答案，也许我们会在以后继续探讨这些问题。