先记住这个答案
相似度阈值高则命中率低但错误风险小，调低阈值能提升命中率却可能返回语义不同、实际错误的答案。嵌入模型应选择对领域词汇敏感、与下游任务对齐的模型，并针对典型查询做验证。失效策略可按缓存条目来源、更新频率和业务容忍度分层：静态知识用TTL，动态数据用主动失效或写穿透。关键是通过线上错误样本和延迟收益来校准阈值。
- 阈值需在命中率和错误容忍间折中
- 嵌入模型选择需贴近业务语义
- 失效策略应按数据变更频率分层
阈值如何影响命中与错误率
阈值设得太高，只有近乎复述的查询才能命中，缓存形同虚设；设得太低，不同意图的查询可能因向量接近而被错误复用答案。例如用户问“怎么退订会员”和“如何关闭自动续费”语义接近，可缓存；但“怎么退款”则可能不同。错误命中率会随阈值下降呈非线性上升，因为真实语义差异往往集中在相似区间。
嵌入模型把文本映射到向量空间，但不同模型的区分粒度不同。通用模型可能认为“苹果手机”和“苹果公司”过于接近，需要领域微调。失效策略则负责清理随时间失效的知识，比如促销规则。三者相互作用：低阈值+弱嵌入+长TTL最容易产出过期或错误答案。
客服机器人的混合策略
假设一个电商客服机器人，问题多为“物流到哪了”“怎么退货”。先收集一周日志，用候选嵌入模型离线圈出重复意图。发现阈值0.92时命中率仅12%，但错误率为0；降到0.85时命中率31%，错误率0.4%。业务可接受错误率0.5%以下，故取0.86。对订单状态类问题，因数据实时变化，缓存TTL设为30秒；对退货政策则用24小时。
同时启用主动失效：当后台价格或规则更新时，按知识库ID清除相关缓存。运行两周后命中率稳定在28%，错误率0.3%。关键是把错误答案的代价量化——客服场景0.4%可能造成投诉，因此阈值没有进一步降低。实践中还发现，使用专门针对电商语料微调的嵌入模型，在同样阈值下命中率提升5个百分点。
失效的适用条件与代价
如果问题高度依赖上下文或用户个性化信息，语义缓存几乎无效。例如“我的订单”这类查询需要user_id，即使嵌入接近也不能复用其它用户的答案。此时应放弃缓存或做两层键：语义层+用户ID精确匹配。另一类是数据频繁更新且无法感知变更，如实时库存，任何TTL都可能给出已缺货的答案。
处理方式是对可变数据使用“语义缓存+DB校验”，在返回缓存前查询一次库存状态，失败时回源模型。这增加一次DB查询，但远低于一次LLM调用的成本。若业务对正确率要求极高（医疗、法律），建议只缓存确定性FAQ，复杂推理全部回源。明白代价是：过度设计缓存会增加系统复杂度和维护成本，不如直接调用模型。
容易答错的地方
- 追求高命中率一味降阈值
- 有人把阈值从0.9降到0.7期望更多命中，却忽视了错误答案的代价。正确做法是先定义可接受错误率，再倒推阈值，并用线上抽样评估错误样本比例。
- 所有数据用同一失效策略
- 静态知识用短TTL会浪费命中，动态数据用长TTL会给出过期答案。应当按数据源变更频率分层，结合业务规则做主动失效，而不是一刀切。
面试官还会怎么问？
如何评估一个嵌入模型适不适合我们的语义空间？
用有代表性的查询对构建测试集，人工标注预期是否相同意图。计算在不同阈值下的精确率-召回率曲线，选择在目标错误率下召回最高的模型。
失效策略如何与缓存命中率联动监控？
监控每个条目的命中次数和创建时间，若大量条目命中但从未失效，且查询多样性上升，可能意味着数据变化未被感知。对比使用缓存前后的答案一致性，可发现过期。
如果业务允许偶发错误，缓存能省多少成本？
通常可把命中率提升到30%左右，相应减少LLM调用成本。但要计算额外存储和向量检索开销，以及错误造成的人工补救成本，实际节省低于毛成本。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。