上周我帮一个做公司知识库的团队看缓存问题，他们第一句话不是“模型太贵”。而是：

这句话基本概括了很多 LLM 应用在 年会上线遇到的第二阶段问题：第一阶段大家学会了加缓存，第二阶段才发现LLM 缓存最难的不是命中，而是失效。

传统缓存里“失效”通常代表着数据旧了；语义缓存里“失效”更麻烦：它可能没有旧，甚至刚生成一分钟。但它已经不适合当前请求、当前使用者、当前权限、当前 Prompt 模板或当前知识库版本。

”的入门概念，也不把它包装成省钱银弹。我们只讨论生产环境最容易踩的 个坑：

• 只看相似度阈值，把 threshold 当安全边界；
• cache key 没有带租户、角色、区域、策略版本；
• Embedding 模型、Prompt 模板、生成模型升级后仍混用旧缓存；
• RAG 文档更新和向量索引重建之间存在不一致窗口；
• 监控只看 hit rate，不看 wrong reuse rate。

如果你正在做 AI 客服、公司知识库、代码问答、数据分析助手或 Agent 网站，这些坑比“缓存命中率不够高”更值得先解决。

. 语义缓存不是“向量查到了就返回”

精确缓存的逻辑很简单：同一个 key 命中同一个 value。说到例如，

GET /api/user/ -> cache:user:

语义缓存则不一样。说到使用者问，

如何重置密码？我忘了登录密码，怎么重新设置？账号进不去了怎么恢复访问？

这些句子文字不同，但语义接近。怎么说呢，程序会把 query 转成 embedding。在向量库里找近邻，如果距离小于阈值，就复用之前生成过的答案。Redis 今年的语义缓存文章也把流程拆成了几步：向量化、近邻搜索、阈值判断、命中返回、未命中则调用模型并写入缓存。 RedisVL 的 SemanticCache 也把 distance_threshold。ttl,filterable_fields 等参数做成了显式配置。

问题在于的观点是。近邻搜索只是在回答“像不像”，不是在回答“能不能复用”。

Certain database vendor’s Spring AI semantic caching architecture article said directly:

. 陷阱一：阈值越低，命中越高。事故也越集中

很多团队第一次接入语义缓存时会把调整目标定成 hit rate：

目标：语义缓存命中率> % 

“管理员能看哪些审计日志？” “普通成员能看哪些审计日志？” “删除项目会删除数据吗？” “归档项目会删除数据吗？” “Python 连接 Redis 报 timeout 怎么办？” “Java 连接 Redis 报 timeout 怎么办？” 

示例实验结果 此表说明阈值不是业务安全边界。仅调节召回多少候选，而非判断答案是否适合当前使用者。

阈值	命中率	精确率	召回率	错误复用率
%10%	%60%	%55%	%70%	%5%

生产里更合理的策略是两阶段：

• 用向量相似度召回候选；
• 用结构化策略判断候选是否可复用。

可以把缓存命中拆成：

• tag>  semantic_candidate_hit：向量召回到了候选policy_approved_hit：策略允许复用served_cache_hit：最终真的返回缓存wrong_reuse：后来被反馈/审计判定为错误复用
• 如果你只看 served_cache_hit，团队会自然倾向于放宽阈值；说起来，如果你同时看 wrong_reuse，缓存策略才会回到正确方向。

. 陷阱二：缓存 key 没有“作用域”。导致跨租户/跨权限复用

语义缓存最常见的线上事故，不一定是模型幻觉，而是 scope 没带全。说起来，

PITFALLS	为什么影响复用？
tenantIdA 公司知识库答案不能给 B 公司userRole / permissionHash管理员答案不能给普通成员locale 中英文 、地区政策 、术语不同productPlan免费版/公司版功能不同safetyPolicyVersion合规策略升级后旧答案可能不合规promptTemplateVersion模板改变会改变回答风格和约束modelId / modelVersion生成模型差异会影响答案可复用性embeddingModelVersion向量空间不同 分数不可混 用ragCorpusVersion知识库内容版本不同

一个更安全的候选查询应该长这样：

---