语义缓存是什么？什么场景省大钱、什么场景会答错话？
谁在问：二面；有明确成本压力的团队、客服与知识库问答方向的产品团队
口语化问法
- 听说过语义缓存吗？它和普通缓存有什么区别？
- 你们成本这么高，为什么不上语义缓存？
- 如果让你上语义缓存，相似度阈值你会设多少？为什么？
考察意图
这道题表面考概念，实际考三件事：
- 你能不能把语义缓存和 prompt 缓存分清楚。 这是本章最高频的混淆点，两者作用位置、命中粒度、正确性风险完全不同。
- 你有没有意识到它是拿正确性换钱。 这道题的满分答案全在"什么场景会答错话"这半边——能说出具体失败形态的人，才是真评估过的。
- 你会不会以为调高阈值就安全了。 这是最典型的直觉错误，而且有公开数据可以直接反驳。
参考答案
60 分答案（及格线）
语义缓存是把用户问题向量化，和历史问题做相似度检索，超过阈值就直接返回之前那个问题的答案，不再调用大模型。
它和普通缓存的区别是：普通缓存要求请求完全一样才命中，语义缓存只要"意思差不多"就能命中，所以命中率高很多。比如"怎么退货"和"退货流程是什么"，字面不同但意思一样。
适合的场景是重复度高的：客服 FAQ、产品说明、内部知识库问答——用户问来问去就那些问题，命中率高，省钱也省延迟。
会答错话的场景主要是个性化和时效性强的，比如"我的订单到哪了""今天的股价是多少"，这类问题字面很像但答案完全不同，命中了就会答错。所以要么把这类请求排除在外，要么把阈值调高一点。
为什么只有 60 分：定义、适用场景、危险场景都点到了，但有两个硬伤——一是没和 prompt 缓存做区分，而这是面试官最想听的；二是最后那句"把阈值调高一点"是错的，有公开数据直接反驳。而且缓存键设计、失效策略一个字没提。
90 分答案（有生产经验的回答）
我先把它和 prompt 缓存分开，因为这两个东西经常被混为一谈，但性质完全不同：
| prompt / prefix 缓存 | 语义缓存 | |
|---|---|---|
| 位置 | 厂商侧、模型内部 | 应用或网关侧、调模型之前 |
| 命中条件 | 前缀逐 token 完全相同 | 向量相似度 ≥ 阈值 |
| 模型跑不跑 | 跑，照常生成新输出 | 不跑，直接吐旧答案 |
| 省什么 | 只省输入侧的重算（命中价约 0.1 倍） | 省整次调用：输入、输出、延迟全省 |
| 正确性风险 | 零（厂商明确保证输出与不用缓存时完全相同） | 不可消除 |
一句话记忆：prompt 缓存省的是"重算"的钱，语义缓存省的是"再想一次"的钱；前者不会错，后者一定会错一部分。
然后是那个最反直觉的结论：误命中是结构性的，调阈值消不掉。 有一组公开的官方基准可以直接说明——六万多条真实对话 query 测出来，阈值拉到 0.99（几乎等于精确匹配）时命中答案的准确率仍只有 92.1%；放宽到 0.75，准确率只掉到 91.2%，而降本幅度从 15.8% 涨到 86.3%。
所以阈值买的是命中率，不是准确率。 真正决定准确率的是另外两件事：
第一，缓存键必须做硬相等隔离，不能靠向量相似度软隔离。 必须进 key 的至少有：租户 ID、用户或权限组、模型与版本、embedding 模型与版本、prompt 模板版本、语料版本、语言。已有公开安全 issue 证明软隔离必然会漏——某开源实现把命名空间拼进 query 做隔离，结果一个用户以 0.9085 的相似度（阈值 0.8）拿到了另一用户逐字节相同的响应；修复方案是硬相等比对命名空间、根本不看相似度。
第二，有一整类 query 必须在查缓存之前拦掉： 时间敏感、个性化、权限相关的"易变查询"。最锋利的例子是——"现在几点"在 14:00 和 14:05 问，两次余弦相似度永远是 1.0，答案却不同，而且分数不会给你任何"过期了"的提示。 相似度天然无法表达时效性。这个判定只能放在应用层：正则做快速分类，开发期用模型发现新模式再固化成规则。
危险场景按失败机理分四类：
- 个性化上下文："我的订单/余额/工单"——不同用户的问句几乎同构，不把用户 ID 进硬 key 必然串答案。
- 时间与实时数据——见上，相似度恒为 1.0。
- 否定词与数量词的微差："能退款吗"和"不能退款吗"、"3 天内"和"30 天内"。背后有学术依据：语义缓存用的双塔编码器在否定对上的表现接近随机排序。真实案例是"我不想要这个账户了"以 0.887 的相似度命中了"自动取消付款"流程。
- 多轮与 Agent 场景——官方明确不建议：连续轮次文本几乎相同、相似度约 0.99，会导致 agent 重放旧响应、重复工具调用；这类负载命中率本来也只有 5%–15%。
命中率是场景函数，不是产品函数（业界经验区间）：FAQ 与客服 40%–60%、分类打标 50%–70%、内部知识库 30%–45%、RAG 只有 15%–25%、开放聊天 10%–20%、代码与 Agent 工具调用只有 5%–15%。顺带纠正一个常见误读——厂商宣传的"95%"通常指命中的准确率，不是命中率。
所以我的实际建议是有次序的：
- 先上精确缓存：零正确性风险，单独就能吃掉典型流量的 15%–30%。
- 再把 prompt 缓存做满：同样零风险，输入侧降到 0.1 倍。
- 测真实流量的重复度再决定要不要上语义缓存——如果第 1 步测出重复率本来就低，语义缓存也救不了。
- 真要上，从 0.90–0.95 起步、边 A/B 测准确率边往下降，且只对确定性强的场景开（固定 FAQ、政策问答），交易类、个性化、多轮一律关。TTL 按数据类型分档：静态事实 24 小时、产品信息 12–24 小时、实时数据 5–15 分钟，并加随机抖动防雪崩。
追问链
「阈值买的是命中率不是准确率」，那准确率到底由什么决定？
期望① 缓存键硬隔离（租户、用户权限、模型与 embedding 版本、模板与语料版本）—— 唯一能把「绝对不能串」变成结构上不可能串；② 易变查询前置拦截；③ embedding 懂不懂你的领域 —— 通用模型分不清医疗「出院小结」和财务「出账」。兜底是命中后加一层轻量重排核对信号把「硬隔离」排在第一位 → 理解了机制；还在纠结「阈值调到多少合适」 → 没跳出直觉模型换版本了，或者知识库更新了，缓存怎么办？
期望模型版本、embedding 版本、语料版本都必须进缓存键，否则静默返回自信的错误答案：文档改了，缓存照吐旧结论还不报错。key 带版本号则版本一变自然全量失效；不想全废就按主题定向失效。换 embedding 后新旧向量不在同一空间，只能整体重建信号主动说「换了 embedding 旧向量就不可用」 → 真运维过向量库；只说「设个 TTL」 → 没考虑版本漂移你怎么知道线上的误命中率是多少？
期望难点是误命中没有天然负反馈：用户拿到别人的答案只觉得「AI 有点笨」，不投诉。只能主动测 —— ① 影子对比采样，对一部分命中请求照常调一次模型做一致性判分；② 零成本信号：命中率涨的同时重问率也涨；③ 按场景、租户、阈值分桶，把误命中集中的那类关掉信号提出「影子对比」或「命中率上升伴随重问率上升」 → 真监控过；只说「看用户反馈」 → 永远发现不了问题语义缓存和流式输出冲突吗？
期望冲突。读侧：命中返回整段，要么破坏流式契约，要么伪装成流式一帧帧吐。写侧更麻烦 —— 流完才拿得到全文，写入必然滞后，并发同一问题时全部未命中，形成击穿，得上写入锁或单飞。叠上流式的「先出后审」，缓存把一次错误放大成持续错误信号说得出「缓存写入滞后导致击穿」或「缓存把一次错误放大成持续错误」 → 真接过；只说「改一下返回格式」 → 没考虑时序老板要求本季度成本降 50%，点名「上语义缓存，别的团队都上了」，你怎么答？
期望① 先给数据，别先表态：大头若在输出或思考 token，缓存救不了 → ② 零风险的先做完 —— 精确缓存吃 15%–30%、prompt 缓存做满（输入侧 0.1 倍）、能异步的走批处理（五折），多数团队能拿 30%–50% → ③ 语义缓存只对固定 FAQ 开，交易、账户、多轮 Agent 一律关，误命中率当验收指标信号第一动作是「拉成本构成」而不是讨论上不上 → 真做过成本治理；能按场景分开而不是一刀切、并顶回「别人都上了」 → 扛得住压力
评分要点
- 把语义缓存与 prompt 缓存在四个维度上分清（位置、命中条件、模型跑不跑、正确性风险）
- 说得出误命中是结构性的，调阈值消不掉，并能给出量级
- 知道租户与用户隔离必须硬相等匹配，不能靠向量软隔离
- 说得出易变查询要在查缓存之前拦掉，并能举出"相似度恒为 1.0"这类例子
- 知道否定词与数量词的微差是双塔编码器的固有弱点
- 知道多轮与 Agent 场景不适用，且这类负载命中率本来就低
- 命中率按场景给区间，而不是一个数字；不把"95% 准确率"误读成命中率
- 有次序：精确缓存 → prompt 缓存 → 测重复度 → 才谈语义缓存
- 说得出监控误命中率的方法（影子对比、重问率等零成本信号）
- 压力面下能分场景开关，而不是一刀切