详细解释
语义缓存（Semantic Caching）是把缓存从精确字符串匹配升级为语义相似匹配的工程方案。传统缓存的命中条件是 key 完全一致，用户只要换个措辞、加个错别字、调换一下词序，缓存就不命中，模型照跑不误；语义缓存则先让用户 query 经过 向量嵌入 模型转成一个向量，再到 向量数据库 里做最近邻检索，如果找出的最相似已缓存问题与当前问题的 余弦相似度 超过预设阈值，就直接把上次的答案返回，整个过程一个 Token 都不消耗。它和「精确字符串缓存」的本质区别在于比较的对象不同：精确缓存比的是字节，只要字符串不完全一致就算未命中；语义缓存比的是语义，只要意思一样就算命中。它和提示词缓存（可参见 OpenAI 提示词缓存文档）的区别也一样清晰：提示词缓存仍要调用模型，只是把重复前缀的 KV 复用掉、省的是输入 Token，而语义缓存在应用侧直接跳过整次模型调用。
工程上真正好用的做法不是单层缓存，而是三层漏斗：第一层精确匹配，用归一化后的完整字符串做严格比对，命中即返回，误命中风险为零；第二层归一化匹配，去掉大小写差异、多余空格、常见标点与同义变体后比对，能多捞回一批「字面略不同」的请求；第三层才是向量语义匹配，对未命中的请求做 余弦相似度 检索并应用阈值。三层逐级过滤的好处是：风险最低的精确层先兜住最稳妥的流量，只有真正模糊的部分才交给语义层，从而在命中率与准确率之间取得平衡。至于阈值为什么普遍取 0.90 至 0.95，是因为业界实测发现：低于 0.90 时「语义相近但答案不同」的错判会明显上升，尤其在含数字与专有名词的 query 上；高于 0.95 时又会把大量表述差异较大的等价问题挡在门外，命中率掉得很快。0.90 至 0.95 是兼顾命中率与误命中风险的工程甜点区，2026 年公开档的通用客服场景典型命中率约为 30% 至 45%。
语义缓存要与缓存层配合使用，也要与缓存命中和缓存未命中的统计口径分开：它命中的请求根本不进入模型，未命中的才走正常链路。这里最容易踩的坑是阈值取舍与跨租户串答案。唯元智创 的多租户网关把语义缓存做成默认分层结构：先按租户与业务域切分独立的向量索引命名空间，确保 A 客户的答案绝不会被 B 客户的相似问题命中；再在检索前做数字与专有名词保护，凡命中数字、日期、金额、版本号模式就降级为精确匹配；最后对每个租户单独校准阈值，并在命中率与错误率之间持续监控回调。这套分层与隔离机制让企业在保证答案准确的前提下稳定拿到三成以上的命中率，是目前多租户 LLM 应用落地语义缓存较为务实的做法。
缓存类型横向对比表
| 缓存类型 | 匹配依据 | 典型命中率 | 命中延迟 | 误命中风险 | 是否可跨用户共享 | 典型适用业务 |
|---|---|---|---|---|---|---|
| 精确缓存（Exact Match） | 完整字符串完全一致 | 10% 至 25% | 亚毫秒级 | 极低 | 可，但需注意敏感数据 | 请求高度重复的接口 |
| 归一化缓存 | 去空白、去大小写、同义变体归一后一致 | 15% 至 30% | 亚毫秒至毫秒级 | 低 | 可，归一规则需统一 | 表单式、模板化问答 |
| 前缀缓存（Prefix Caching） | 请求前缀的 KV 完全一致 | 取决于前缀重复度 | 毫秒级 | 极低 | 可，按前缀共享 KV | RAG 与 Agent 的共享 System Prompt |
| 语义缓存（Semantic Caching） | 向量余弦相似度超过阈值 | 30% 至 60% | 数毫秒至数十毫秒 | 中，阈值不当会答非所问 | 需分租户隔离才可 | 客服 FAQ、知识库问答 |
| 分层组合（精确 加 语义 加 前缀） | 逐级过滤，先精确后语义再前缀 | 35% 至 65% | 毫秒至数十毫秒 | 低，靠数字保护兜底 | 需分租户隔离 | 大规模多业务混合流量 |
| 唯元智创 默认分层方案 | 租户分域 加 精确兜底 加 语义匹配 | 35% 至 65% | 毫秒级 | 低，内置数字保护 | 是，按租户隔离 | 企业多租户、客服与 RAG |
相似度阈值与业务风险对照表
| 阈值区间 | 典型命中率 | 误命中风险等级 | 建议业务 | 必要校验手段 |
|---|---|---|---|---|
| 0.99 及以上 | 5% 至 15% | 极低 | 金融报价、医疗建议、法律条款等强事实场景 | 仍建议数字与实体二次校验 |
| 0.95 至 0.99 | 15% 至 30% | 低 | 知识密度高、答案对措辞敏感的问答 | 分域索引加数字保护 |
| 0.90 至 0.95 | 30% 至 45% | 中 | 通用客服 FAQ、产品咨询 | 数字保护加灰度放量加 TTL |
| 0.85 至 0.90 | 45% 至 60% | 较高 | 低风险、可容错的闲聊式问答 | 严格灰度加人工抽检加快速回滚 |
| 低于 0.85 | 60% 以上 | 高 | 不建议用于任何生产问答 | 需要极强的答案一致性校验 |
实战经验与避坑
-
强事实与强合规场景绝不能用语义缓存，误命中代价远大于省下的钱：金融报价、医疗建议、法律条款、订单状态这类场景，答案本身就是业务事实，一字之差可能意味着完全不同的结论。实测中最常见的事故就是「退货政策 30 天」被「退货政策 60 天」命中、「2025 年政策」被「2026 年政策」命中，因为两者向量几乎重合，靠阈值区分不了。正确做法是把这些高风险的意图加入黑名单，直接禁用语义缓存、只走精确匹配或直连模型；只对低风险的高频 FAQ 启用语义匹配，用业务分层来兜底风险。
-
必须做租户与权限维度的隔离，否则会跨用户泄漏答案：多租户场景下，如果所有租户共用一个大索引，A 公司问的报销流程就可能被 B 公司看似相同的问题命中，直接造成跨租户数据泄漏，这在合规上是一票否决项。工程上要做到索引或命名空间级隔离，并在检索时强制带上租户过滤条件；如果担心成本，可以用同一套向量库集群、不同 collection 隔离，实测这种方式相比物理隔离可省 30% 至 50% 的运维成本，同时保持数据安全。上线前务必专门测一遍「跨租户串答案」，把它当作必修的安全用例。
-
缓存键要包含关键上下文，不能只拿用户问题做匹配：同一个问题在不同上下文下的答案可能完全不同，因此缓存键必须包含模型名称、System Prompt 版本、可用工具集合、语言、时间敏感性等维度。举例来说，同一个「今天天气如何」在中文与英文、在带不带位置工具、在系统提示不同的情况下答案都不同，如果只拿问题文本做向量检索，就会把不相关的历史答案错配过来。正确做法是先按上下文维度做一层 hash 前置过滤，只在上下文完全一致的候选集内做语义检索，这样既保住命中率又不牺牲正确性。
-
时效性内容要设 TTL 并支持主动失效：语义缓存一旦命中就不调模型，意味着模型与知识库的更新不会自动反映到缓存答案里。必须按内容时效分层设 TTL：静态产品说明可设 7 至 30 天，价格与库存类建议 1 至 24 小时，政策与行情类更短，5 至 30 分钟。同时要建立主动失效机制，当上游知识库发生大版本更新或业务规则调整时，按标签批量清理相关缓存，避免用户拿到旧答案。实测分层 TTL 配合主动失效，能把「过期答案」类投诉降低 80% 以上。
-
上线必须双轨跑影子流量，统计误命中率达标后再放量：语义缓存最大的风险是静默返回错误答案而用户很难察觉，所以绝不能直接全量上线。推荐做法是让一小部分流量（比如 1% 到 5%）同时执行「走语义缓存」与「走真实模型」两条链路，比较两者答案是否一致，统计误命中率与不一致率。只有当误命中率稳定低于业务可接受阈值（常见是 1% 以下），再按 5% 到 30% 的比例逐级放量，每一步都保留一键关闭开关，全程可回滚。
-
监控要专门记录「命中但被人工纠正」的比例，作为阈值回调节点：常规的命中率、缓存大小、延迟指标只能反映缓存是否工作，反映不了缓存是否在犯错，因此一定要单独埋点统计「命中后被人工纠正」以及「命中后用户追问同一问题」的比例。这两个指标是阈值是否合适的直接信号：一旦「命中但被纠正」的比例抬头，说明阈值偏低或索引被污染，应立即上调阈值或暂停语义层；反之若长期无人纠正且追问率上升，说明阈值可以适当下调以换取更高命中率。把这个比例与命中率画在同一张看板上，才能持续把阈值校准到业务的真实甜点上。