4.1 精确匹配不够用：语义缓存的动机与原理

4.1 精确匹配不够用：语义缓存的动机与原理

第 3 章的 Prompt 缓存把长系统提示和公共前缀存进平台，省下的是 prefill 算力；可它依赖字节级的前缀精确匹配——只要用户换一种问法，前缀就对不上，缓存全部 miss。一个客服系统里，"怎么开发票""发票怎么开""可以开专票吗"这类同义句每天成千上万次地重复撞向模型，却因为字面不同而被当作全新请求。语义缓存要解决的正是这层浪费：它不再比对字符串，而是比对"意思"。这一节先把动机和原理讲透，下一节我们亲手定一次阈值，看命中率与误命中率到底怎么此消彼长。

当"同一个问题"长出十张面孔

精确匹配失效不是偶发，而是自然语言的天性。同一意图的表层表达几乎无限：疑问句、陈述句、口语、书面语、带错别字、带语气词，都能指向同一个答案。第 3 章的产物在前缀层面无能为力，因为"退货几天到"和"退款一般多久"在字符层面没有任何公共前缀，哈希值天差地别。

我更倾向把这一层理解为"把缓存键从字符串换成坐标"。字符串相等是二值的、苛刻的；坐标相近是连续的、宽容的。宽容带来收益，也带来风险——后面两节会反复回到这条主线。

举个量化的例子把账算清：一个客服系统日均 20 万次请求，其中约四成是高度重复的退款、物流类问题。若全部走模型，prefill 加 decode 是一笔雷打不动的固定开销；而语义缓存命中后，这部分只需付一次嵌入的几毫秒，生成调用整段省掉。把"每次都付全款"变成"付一次首付、后续只付利息"，正是复用经济学在这一层的直观写法。也正因为"首付"（嵌入）是每次请求都要付的，复用率太低时这笔首付就摊不薄——这一点到 4.4 测算时会再钉死。

语义缓存的六跳流水线

把一次请求送进语义缓存，会走过下面这六跳。每一跳都可替换实现，理解它的关键是分清"哪一步在省算力、哪一步在花算力"。

1. 查询接入：用户问题进入缓存层，尚未触碰模型。
2. 嵌入（Embedding）：调用一个嵌入模型，把问题文本变成一串固定维度的向量。这一步要花一次推理，但嵌入模型通常比生成模型小得多、快得多，成本大约只有生成调用的几十分之一。
3. 向量检索：拿这个向量去已存向量的库里，按余弦相似度找最近的若干个邻居。工业做法是用近似最近邻索引（如 HNSW、IVF），毫秒级返回候选。
4. 相似度判断：把最近邻的相似度分数和阈值比较。高于阈值才算"命中"，低于阈值算"未命中"。
5. 命中返回 / 未命中调用模型：命中则直接还回上次存的答案，模型全程不醒；未命中才真正调用大模型生成答案。
6. 写入缓存：把新问题的向量和答案一起写进向量库，供以后复用。这一步是"回收"动作——预付的嵌入算力，靠后续命中慢慢收回来。

这里有个容易被忽略的经济账：嵌入本身也要算力，如果后续命中次数很少，省下的生成算力可能还抵不过嵌入开销。语义缓存划算的前提，是同一类问题被反复问到。复用经济学在这里体现为一条朴素不等式——嵌入成本要被足够多次命中摊薄。

图 4-1：语义缓存请求处理流水线图

开源生态：谁在替你做这件事

不用从零造轮子，几类现成方案各有取舍。

GPTCache 的设计哲学值得先讲。它本身不存向量，而是把"嵌入 + 向量检索 + 相似度判断 + 后端存储"做成可插拔的管道：嵌入用哪款模型、检索用哪种索引、相似度用什么距离、答案存在哪（Redis、SQLite、还是别的），都能换。它的价值在于把上面六跳收敛成一个统一接口，业务侧只管"查"和"取"。但这种高度可插拔也意味着：性能瓶颈和成本结构由你的选型决定，不能默认它一定快。

Redis 的语义检索是另一条路。Redis 自从支持向量数据类型后，可以直接在同一个内存数据库里既做精确键查询、又做近似向量检索。好处是基础设施不膨胀——原本就有 Redis 做会话和计数，顺手把语义缓存也放进去；坏处是大规模高维向量的 ANN 性能不如专用向量库，数据量上亿时要重新评估。

专用向量库的取舍则落在"检索质量 vs 运维复杂度"上。Milvus、pgvector、FAISS 各有所长：FAISS 是库不是服务，适合嵌入进进程、追求极低延迟；pgvector 让 PostgreSQL 直接扛向量检索，省一套独立集群；Milvus 是分布式服务，适合亿级向量的独立部署。我的判断是：中小团队先用 pgvector 把链路跑通，真到了体量再迁专用服务，别一上来就上重架构。

不过语义缓存不是银弹，先把适用边界说清，免得用错地方。它的经济前提是高复用率——同一类问题被反复问。若你的流量是长尾、几乎不重复（比如每人每次都是全新的创作需求），嵌入成本摊不薄、命中又少，多级架构反而亏。另一类是"答错即事故"的场景，如医疗诊断结论、法律条文适用，在没布好 4.3 的防线前，我不建议直接上自动命中，宁可只做"语义召回候选 + 人审"的半自动模式。一句话：先看流量画像，再决定要不要这层。

语义缓存 ≠ 响应缓存

这两个词常被混用，必须分清。

响应缓存复用的是"整段响应"——同一请求进来，原样吐出上次存的完整回答，常见于静态问答、模板化输出。它是"全有或全无"的整块复用。

语义缓存复用的是"语义等价的答案"——问题变了，只要意思够近就命中。它更灵活，但也更危险：因为命中时你并不能 100% 确认这次的新问法和上次存的答案真的等价，误命中就藏在这里。

举个组合用法的例子：用户问"你们支持花呗分期吗"，语义命中到一条"支付方式"类缓存，但答案里含的"当前分期免息活动"是上周的、已过期。这时正确的做法不是整响应返回，而是只取"支持花呗分期"这个稳定结论，把"免息活动"这类时效字段留给实时接口填空。也就是说，语义缓存负责"认出意图"，响应缓存负责"整块兜底"，二者一前一后，比单用任何一种都稳。Intent 识别和答案拼装解耦之后，缓存的命中范围也能放得更宽——因为你要复用的只是"意图判定"，不是一整段会过期的文本。

二者也常组合：语义缓存先判断意图相近，命中后再决定是否整响应返回，还是只取其中可复用的片段（比如先确认"这是退货政策相关问题"，再套用最新的退货时效数据填空）。分清这层，下一节谈阈值时你才会明白：阈值是语义缓存独有的旋钮，响应缓存根本不需要它。

这一节落下的一个待解问题

原理讲清了，开源方案也摆好了，可六跳里最要命的那一跳——"相似度判断"——还空着一个数字没填：阈值到底定多少？定高了，十句同义里只命中一两句，省不下多少；定低了，意思八竿子打不着的问法也命中，答非所问。下一节我们用一份真实的客服问句对，亲手把这个数测出来。