LLM 应用的缓存设计：语义缓存与精确缓存的取舍

给大模型应用加缓存，最贵的不是缓存本身，而是加错缓存：语义缓存的命中率报表很漂亮，但「相似问题返回相似答案」的近似性会在客服、风控这类场景埋雷。LLM 应用的缓存设计要在三样东西之间做权衡——一致性要求、成本收益、以及「何时不该命中」。本文给一套可以直接落地的分层方案。

一、先分清两类缓存，别混着用

精确缓存（Exact Cache）：key 是请求的确定性指纹。对补全类接口，key = 模型 + 采样参数 + 归一化后的 messages；对 embedding 检索，key = 模型 + 版本 + 原文。命中即返回完全相同的结果，零风险。适用：相同 prompt 高频复现的场景（固定模板的摘要、批处理重跑、回归测试）。

语义缓存（Semantic Cache）：把请求向量化，命中「语义相近」的历史问答，返回旧答案。收益大（重复问题多时命中率可观），但近似性是原罪——用户问「如何退款」命中「如何退货」的答案，业务上可能是灾难。

取舍的第一原则：能精确就精确，必须语义才语义。语义缓存只该开在「答案与问法无关紧要」的场景：FAQ 前置引导、内部知识问答、离线批处理。支付、工单、账号操作类一律禁用。

二、语义缓存的四道闸门

如果确定要用语义缓存，四道闸门缺一不可：

相似度阈值 + 排名隔离：阈值不能一刀切。用「余弦相似度 + 业务分档」：大于等于 0.97 直接命中，0.92~0.97 命中但降级展示（标注「相似问题」），低于阈值回源。阈值要按业务灰度调，别抄别人的数字。

时效绑定：答案附带数据版本或 TTL。知识库类把「检索到的文档版本 hash」记进缓存条目，文档更新即失效——否则知识库更新后语义缓存还在吐旧答案，比没有缓存更糟。

用户/租户隔离：向量空间按租户分片或 key 前缀隔离。A 公司的私有知识绝不能成为 B 公司的命中来源——语义缓存的越权比精确缓存隐蔽得多。

审计与灰度：缓存命中要有独立日志（命中的源问题、相似度、时间），上线先按 10% 流量灰度，对比命中组与回源组的人工差评率。

三、精确缓存的工程细节

精确缓存看似简单，也有三个坑：

归一化规则要固定：messages 里的空白、转义、字段顺序会影响指纹。归一化规则一旦上线就不能变——变了等于全量失效。新规则走新 key 前缀。

流式响应缓存：流式输出缓存的不是 token 流本身，而是完整结果——命中后把缓存内容以流式节奏「重放」给客户端，保持前端体验一致。

失效策略：模型升级、prompt 变更、温度参数调整都该触发 key 前缀轮换。把「缓存版本」纳入发布清单，和 prompt 版本管理用同一套机制。

四、别忽视成本侧的对手：Batch 与结构化复用

缓存之外还有两个降本手段常被忽略。批处理接口（Batch API）对时效不敏感的离线任务给半价，很多「要缓存」的场景其实是「该走批量」；结构化复用——把高频问题的答案沉淀为产品侧内容（帮助文档、快捷回复），直接绕过模型调用。缓存省的是重复计算，内容复用省的是整次调用，后者收益更高但需要产品介入。

五、落地路径

第一步（一天）：接入精确缓存，归一化 + key 版本化，先吃掉确定性重复流量的收益。第二步（一周）：语义缓存灰度上线，四道闸门配齐，选一个容错高的场景验证。第三步（按需）：审计报表与命中率调参，把语义缓存扩展到更多场景。

判断标准很简单：随机抽 20 条缓存命中，人工判断「用旧答案回答新问题是否合适」——19 条以上合适，语义缓存才算合格；低于这个数，要么收紧阈值，要么关掉。