语义缓存能不能直接顶替检索层？

起初我想偷懒，觉得每次走 Embedding -> Vector DB -> Rerank 链路太慢且贵，就想用语义缓存把相似请求直接拦截掉。逻辑很简单：只要用户问的问题和之前的缓存命中（余弦相似度 > 0.95），直接返回缓存结果，跳过检索。

结果在处理一个技术文档问答项目时翻车了。文档版本更新后，我更新了向量库，但没清理缓存。用户问一个关于 API 变更的问题，语义缓存判定该问题与之前的旧版本问题高度相似，直接把旧答案甩了出来。此时检索层明明已经有了新答案，但被缓存拦截了。

最让我头疼的是这个报错，虽然不是代码崩溃，但属于逻辑层面的“死循环”：

Cache Hit: similarity=0.982, status=success
Response: "The current API version is v1.0" 
Actual Truth: "The current API version is v2.0 (Updated 2 hours ago)"

排查发现，语义缓存的本质是“以空间换时间”，它模糊了精准匹配和语义近似的界限。当我想通过调低阈值来增加命中率时，出现了严重的误报。比如用户问“如何删除用户？”，缓存居然命中了“如何创建用户？”的结果，因为这两个句子的向量距离在某些模型下异常接近。

为了解决这个问题，我最后把方案改成了“缓存+版本校验”。不能让缓存直接顶替检索，而应该给缓存增加一个 TTL（生存时间）和 VersionTag。

目前的折中方案是这样的流程：
请求 -> 检查缓存 (带有 VersionTag) -> 若命中且 Tag 一致则返回 -> 若不命中/Tag 过期 -> 执行检索层 -> 更新缓存并打上新 Tag。

具体的缓存 Key 构造我用了这种方式：

# 伪代码：将文档版本号混入缓存键，强制失效旧缓存
cache_key = f"{user_query}_{doc_version_hash}"
result = semantic_cache.get(cache_key)

这次踩坑让我意识到，检索层（Retrieval）提供的是“当前最正确”的证据，而语义缓存提供的是“曾经正确过”的答案。两者在数据一致性上的权重完全不同，强行顶替会导致系统失去对实时数据的感知能力。