语义缓存不等于正确缓存
Jampolhz · reddit · 2026-07-17
作者对比了 **exact-match caching** 和 **semantic caching** 在 LLM 场景里的实际效果，结论是：语义缓存看起来命中率更高，但真正风险在于“近似但不等价”的误复用。 ### exact-match：安全但命中低 - 通过完整请求做哈希，只有请求完全一致才命中； - 优点是不会“差不多就算”，返回缓存答案时可确认请求完全相同； - 缺点是现实用户会不断改写同一问题，导致大量 miss。比如“如何重置密码”“我忘了密码怎么办”对人类同义，但对哈希来说完全不同。 ### semantic caching：命中更高，但可能答错 - 先把 prompt 做 embedding，再在向量空间里找相近请求； - 对 FAQ、支持类问题很有效，但“语义相近”不等于“答案相同”； - 例如“澳大利亚首都是哪？”和“澳大利亚最大城市是哪？”在向量上可能很近，却对应不同答案。缓存如果把它们当成同一个问题，就会把错误答案快速返回。 ### 作者现在的做法 - 默认先用 exact-match； - 只有在“不同写法可以共享同一个答案”的场景，才启用 semantic caching； - 对计费、法律、医疗、用户个性化等场景要么不用，要么把阈值设得非常严格； - 还强调语义缓存的阈值不是纯 infra 参数，而更像产品策略。 文末他也提醒：语义缓存并非免费，所有请求都要先做 embedding；如果请求本来就很独特，可能是“为了命中而花了更多钱”。