“语义缓存层”（4） —— LLM后置判等设计

在上一节里，我们讨论了简单的语义缓存存在的几个缺陷。其中，“答不对”的问题是需要最优先处理的，因为用户还没有对系统建立起信心，正确率的降低是致命的。

我们来回顾一下先前的语义缓存架构：

图1：简单语义缓存层架构（Gemini生成，小修）

这个架构能够以极短的时间返回缓存命中的答案，但是评测结果显示了一个致命缺陷：

语义相似不保证业务等价

一、讨论：为什么语义相似的问题可以不等价？

嵌入模型的训练目标是“最大化共现概率”。直观上来说，如果出现在两个单词周围的元素是相似的，那么两个单词就是相似的。这个想法也可以运用到句子和段落中。

考虑下面的两个问题：

部署一套系统需要多少资源？

部署六套系统需要多少资源？

虽然它们在业务上的语义相差很大，但是从嵌入模型的训练目标出发，这两个句子完全可以在相似的语境里出现。事实上，嵌入模型也应该认为这两个句子是高度相似的。

这说明了一个问题：向量检索的核心观点和业务等价存在差距，向量检索可以帮助用于筛选，但是不能最终拍板决定。

当然，现代嵌入模型的底层会更复杂，篇幅所限，这里不会展开，有兴趣的读者可以去读读从Word2Vec到BERT的嵌入技术发展史。

二、还是得用LLM兜底

基于上面的思考，我认为向量化技术并不能完全适用于我的语义缓存层。我认为这里需要一个能力更强的组件来处理，也就是大语言模型。我把这一层次叫做后置判等层。

工作流程变为：

1. 以较高的检索阈值召回最相近的k个缓存问题，作为候选。
2. 将所有候选问题逐个与用户原始提问比较，询问语言模型是否业务等价。
3. 有没有候选问题与用户提问等价？有就直接返回，没有就继续走RAG。

图2：加入了后置判等层的语义缓存层架构（Gemini生成，小修）

从概念上来说，这个设计会比较接近于RAG中的reranker，不过目标完全不同。

Reranker的目标是哪份文档最相关，而我的判等层目标是召回的答案能不能立即解决问题。不是要提高检索质量，而是想方设法在流程的较早步骤结束任务。

三、讨论：用了LLM也叫优化？

判等层的任务极其简单，模型只需要接收：

• 用户查询
• 一个候选问题（甚至可以是几个）

输出只是一个简单的Yes or No。不需要阅读长文本，没有工具调用，甚至不需要开深度思考，也不会生成冗长报告。

实际上就算这里用参数量非常小的模型，效果也会非常好。我反复尝试了轻量级思考模型（hy2-thinking）和Deepseek-R1-0528（满血版），这两个模型在我的评测集里表现几乎没有差别。但是延迟差异相对明显：

• 轻量级思考模型大约在7秒之内完成任务
• Deepseek-R1通常需要20秒左右完成任务

如果不开思考，这一层甚至能够瞬间完成（只输出一个字，多余开销来自于结构化输出的开销，实测仅 11 tokens，几乎没有性能损失）。

很可惜博主手上的评测集规模还不够大，尚且没有足够的生产流量来获得有统计意义的结论。如果读者在不同模型大小在语义等价任务上的大规模评估进行过研究，还请在评论区指出。

四、总结

LLM的表现很不错，有了这一层后置判等之后，我的缓存层可以以多处理数秒的代价提高精度，规避纯向量化架构的弱点。

这个问题的解决途径指出了一个重要的经验教训，尽管向量检索能够在相似片段召回表现良好，但是最终判定问题是否相等还是需要LLM介入。总的来说：

• 用向量召回作为高效检索的手段
• 让LLM介入作为保证质量的兜底

这些手段有效缓解了语义缓存层的第一个主要弱点，在下一节中，我会介绍我的另一个架构，它用于解决QA知识无法被有效利用的问题。