考察点
这道题出自 OpenAI 大模型应用岗的技术面试，DSPrep 标注 Google/Amazon/OpenAI 常考。LLM 应用的成本和延迟大头都在模型调用，缓存是最直接的优化手段，面试官想看你能把「缓存」这个老话题在 LLM 语境下讲出新问题：key 不再精确、命中是概率性的、错误答案会被缓存放大。考察重点是两类缓存的机制差异、语义阈值的确定方法、以及缓存的正确性风险。追问会往 GPTCache、缓存击穿、prompt 变量影响走。
参考答案
两层缓存，解决两个不同的问题
**精确缓存（exact cache）**是传统思路：把请求的完整输入（模型名 + messages + temperature 等参数）做哈希当 key，相同 key 直接返回上次结果。LangChain 里设置 set_llm_cache，后端可以用内存、SQLite、Redis。它的局限一目了然——用户的自然语言几乎不会逐字重复，「怎么退款」和「如何办理退款」是两个 key，命中率低到没意义。它真正的用武之地是：测试和开发阶段（跑评测集、调 prompt 时反复重放相同请求，省钱省时间），以及输入高度模板化的场景（固定格式的分类、抽取任务）。
**语义缓存（semantic cache）**才是生产的主角：把 query 做 embedding，在向量库里找最近邻，相似度超过阈值（比如 0.95）就认为「问过等价的问题」，返回缓存的答案。这样「怎么退款」「退款流程是什么」「我要退货怎么办」都能命中同一条缓存。GPTCache 是这条路线的代表实现，Redis 8 的向量语义缓存也是同一思路。
语义缓存的核心矛盾：阈值即正确性
语义缓存本质是拿「两个问题的向量距离」近似「两个问题等价」，这个近似是风险的来源。阈值定低了，「iPhone 15 多少钱」会命中「iPhone 16 多少钱」的缓存——向量距离很近，答案完全不同，而且是权威地返回错误答案，比模型幻觉更难发现。阈值定高了，退化成精确缓存，失去意义。
工程上确定阈值的办法：
- 按业务风险分层。FAQ 类、答案稳定的知识问答可以用相对宽松的阈值（0.92-0.95）；涉及价格、库存、政策条款这类时效敏感或精确数字的 query，要么拉到 0.98 以上，要么直接加黑名单不走语义缓存。
- 用数据定阈值而不是拍脑袋。收集一批真实 query 对，人工标注「语义等价/不等价」，画出不同阈值下的命中率和错误命中率曲线，选错误率可接受的最高点。
- 缓存 key 带上上下文指纹。RAG 场景里，同样的问题在知识库更新后答案应该变，所以缓存项要绑定知识库版本号或文档摘要哈希，库更新了缓存自然失效。这是最容易被忽略的一点——缓存和底层数据的一致性。
收益测算与失效设计
语义缓存值不值得上，看命中率。真实流量里用户提问的重复度通常比直觉高——客服场景头部 20% 的问题能覆盖 60-80% 的流量，这部分被缓存拦截后，LLM 调用量可能直接砍半，延迟从秒级降到毫秒级。做一次 embedding 的成本（约 0.1 token 级别）对比一次完整生成，ROI 非常可观。
但要做全失效设计：每条缓存带 TTL（知识型可以几天，资讯型几分钟）；知识库更新时按命名空间批量失效；缓存答案要留「来源标记」，出问题时能追溯是哪次生成被复用了。另外语义缓存本身是个向量库，它也需要运维——规模上去后检索延迟、embedding 服务的可用性都会成为新的依赖项，缓存层挂了要能透明降级到直连模型，不能反而成为单点。
和 prompt cache 分清
面试里容易混淆的一个概念：Anthropic、OpenAI 都有 prompt caching——供应商侧对重复的长前缀（系统提示、长文档）缓存 KV，降低计费和首 token 延迟。这是「输入侧」的缓存，由供应商实现；我们上面讲的是「输出侧」的应用层缓存。两者可以同时用、互不冲突，能分清这一层说明你跟进了实际计费模型。
可能的追问
1. 多轮对话场景缓存怎么做？
单看最后一轮 query 会丢上下文——「那保修呢」本身没有意义。做法是把会话状态（或滚动摘要）和当前 query 拼接后再算 embedding，或者只对首轮问题做缓存、后续轮次直连。多轮缓存的命中率天然低，预期别定高。
2. 缓存雪崩怎么防？
知识库大版本更新会瞬间失效一大片缓存，流量全打到模型上可能触发限流。措施：失效分批进行、热点 query 预热重生成、模型侧预留突发配额或 fallback 链兜底。
3. 流式输出还能缓存吗？
可以，缓存的是完整结果——流式只是传输方式。收到完整响应后再写入缓存；命中时如果想保持流式体验，可以把缓存文本按 chunk 模拟推送，用户感知一致。