"怎么退换货"有无数种问法——精确缓存（完全相同字符串才命中）对这种场景几乎无效，每个改写都穿透到模型烧一遍 token。需要的是"语义"层面命中。

核心论点

语义缓存（Semantic Cache，按语义相似度而非精确文本匹配来命中缓存）是网关层独有的成本/延迟杠杆：相似 prompt 直接返缓存答案，根本不进模型，既省 token 又降延迟。

精确缓存为什么不够

精确缓存可作为语义层的前置短路（完全一致直接命中，免 embedding 计算）；语义层把"意思相同"归一到同一答，显著提升对话式、复述式流量的命中率。

缓存层必须卡在网关（唯一出口）

决策：与护栏、限流同一逻辑——凡"所有流量都要过"的能力，放网关才完整（接《LLM流量网关设计》）。

命中判定：相似度阈值的权衡

阈值按场景定——涉及金额/身份的严谨回答应收紧甚至不缓存。命中判定基于 embedding 余弦相似度，内置默认阈值similarity_threshold（env 可配，三层兜底：分片值→env→代码内置常量，绝不无值）。

PII 命中 = 整条不写入

含个人敏感信息的 prompt 本就是个人化的，把它（及模型据此生成的答案）共享给后续相似请求，既泄隐私又语义错；且脱敏后 embedding 与未来未脱敏查询错位，命中也不准。

所以缓存写入门禁应是"无 PII 才写"，而非"脱敏后写"（呼应《合规护栏》跨平面）。该门禁在写入前调用《合规护栏》的脱敏引擎做 PII 检测，而非缓存内另写一套正则——否则规则漂移（引擎形态见《脱敏引擎工程化》）。

不同业务要求不一致：位置统一、策略按业务分片

网关统一做缓存不代表"全局一个阈值 / 一个 TTL"——那样会用客服 FAQ 的宽松策略去服务支付问答，触发误命中。

正确做法：缓存键带业务维度：

缓存键 = embedding(归一化 prompt) + 业务维度标签

每个标签绑定一组策略（相似度阈值 / TTL / 是否启用 / 写操作跳过），命中时先按标签路由到对应策略分片再算余弦相似度。不同业务互不影响。

业务维度标签的治理归属（按约束强度分层）：

原则：标签由开发者贴，策略由网关维护者+业务方共建守护，硬门禁由网关维护者强制——既不让业务方乱来，也不让网关维护者替业务背锅。

失效与一致性：答案会随模型/知识过期

决策：缓存省成本的前提是"答案仍正确"，否则省下的 token 不如一次错误回答的代价。

与成本治理联动

缓存命中 = 不计 token，成本账才能区分"真实模型消耗"与"缓存短路"。

缓存是成本治理的"前端省钱"，限流/预算熔断是"后端兜底"，两层合力（引《成本治理与限流》）。

核心要点

• 语义缓存是网关专属杠杆：相似 prompt 直接返缓存、不进模型，既省 token 又降延迟——必须卡在唯一出口，否则各业务重复建、命中率低、失效策略乱。
• 阈值按场景、失效有保障：高频标准问答可放宽，涉金额/身份须收紧甚至不缓存；靠 TTL + 知识版本化 + 写操作不命中兜底。
• 不同业务要求不一致，靠"位置统一、策略按业务分片"化解：缓存键带业务维度，每个业务域走各自阈值/TTL，互不污染。
• PII 整条不写是跨业务硬门禁：含敏感信息的 prompt 个人化、共享即泄隐私又语义错，写入前统一调《合规护栏》脱敏引擎，不在缓存内另写正则（防规则漂移）。