在上一节里，我们介绍了现在的语义缓存层是怎么做的。它的逻辑很简单：
- 把用户的问题转成向量
- 在向量数据库里匹配最接近的问题
- 最相似的问题相似度是否 >=0.9 ？
- 如果是，就直接返回这个问题的答案
- 否则走完整个RAG流程
博主的配置如下：
| 项 | 配置 | 备注 | 成本 |
|---|---|---|---|
| 向量数据库 | milvus-lite | 本地部署 | 免费 |
| 向量化模型 | text-embedding-3-small | api调用 | 0.02$ / M tokens |
因为对手上QA的质量非常有信心，我的阈值设得很大胆，直接调到了0.85。
如果缓存命中，不需要调用大语言模型，不需要文档检索，也不需要AI对着又臭又长的召回文档思考半分钟总结出答案。整个过程3秒钟搞定，api调用成本低到我想一直点击发送按钮烧钱。
重新评测
然而解决的过程总是不会这么顺利，我把加了缓存层之后的模型重新放回我的评测集里面跑，出现的一些问题甚至想让我马上把刚刚写的代码都删掉。
1. 高度相似的问题有可能并不等价
我的知识库里有这样一个QA：
一个模组大概会对应多少个测点？
很不巧的是评测集里有一条很接近的真实提问：
六个模组一共对应多少个测点？
这两条问题的相似度高达0.87，评测集的问题直接命中我的缓存层，然后我的智能体在3秒钟之内返回了一个完全错误的答案。
博主之前也是搞过NLP的，这个问题非常非常似曾相识。向量的相似性在识别语义上的相近性上表现非常不错，但是对于细微的变化并不敏感，举例来说：
- 一套系统 vs 六套系统
- 生产环境 vs 测试环境
- 单节点部署 vs 集群部署
这些差异会彻底改变问题含义，但是这些用词的改变可能无法造成语义向量的大幅改动。
我的业务场景显然需要确保逻辑上准确无误，但是相似向量匹配这种做法可能还不够好。
2. 最权威的知识无法被模型利用
和腾讯元器不同的是，在我的业务场景中，QA并不是从文档里生成的，而是由真正设计和维护这个系统的开发人员对用户的真实回答。很多答案非常简洁扼要，并且高度浓缩，只通过文档很难推导出来。
我现在的设计对于这些最权威的知识是怎么运用的呢？
- 如果缓存命中，就直接返回；
- 如果缓存没命中，就直接忽略所有QA知识，直接去找文档；
换而言之，下游的RAG流程完全失去了这一部分知识。我在很多的问题里都观察到了这点，添加了缓存层之后，deepseek由于看不到这些答案，回答反而比之前把QA一股脑丢到markdown里更差。大模型完整阅读设计文档和代码片段，深度思考了半分钟（有时候甚至会想一分钟以上），然后给出一堆很长、看起来很对、验证起来非常费劲的回答。相比之下，没有加入缓存层的回答虽然也很长，但是deepseek会把QA的信息放在前面，这些知识非常扼要，用户可以立即验证。
这个案例给出了一个很重要的启示：
QA不仅仅是缓存的答案，也是宝贵的知识来源
如果在其他流程里忽略掉QA的作用，后续的流程就失去了一块价值非常高的知识。