大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
客服机器人上线第二周，早上十点，数据库读 QPS 直接翻了三倍，慢查询开始往外冒。查日志发现，用户的问题高度重复，"发票怎么开""开发票流程是什么"这种话，一个上午能出现几十次，每一次都老老实实走完整套 RAG：向量检索、回表查文档、再调大模型生成。又慢又贵。
我给它前面加了一层语义缓存，意思相近的问题直接命中缓存答案，不再重复调大模型。两周跑下来，命中率五成七，大模型成本降了六成左右，数据库也消停了。今天把这套东西的原理、坑和实测数据一次讲清。
一、先算账：一次 RAG 回答到底有多贵
一次普通的 RAG 问答，背后不止一次大模型调用。用户提问后，系统要把问题向量化，去文档库里做相似度检索，把命中的几段原文捞回来拼成上下文，再整包丢给大模型生成答案。
用户提问
→ ① embedding：问题转成向量（一次模型调用，便宜）
→ ② 向量检索：在文档库里找最相关的片段（数据库读）
→ ③ 回表取原文：按 id 把命中片段读出来（数据库读）
→ ④ 大模型生成：带着上下文生成答案（贵，还慢）
贵的是第 ④ 步。第 ②③ 步把数据库的读 QPS 顶上去，第 ④ 步把账单顶上去。最亏的是，这些问题大量重复。同一个意思换个说法又来一遍，前面几步全部重跑，答案还几乎一样。传统缓存只认字符串完全相等，"开发票"和"发票怎么开"匹配不上，等于没缓存。
二、语义缓存：用"像不像"代替"一不一样"
语义缓存的做法，是把问句也变成向量，拿它跟历史问句的向量比相似度。像到一定程度，就认为用户问的是同一件事，直接把上次的答案返回，不再调大模型。
用户提问
→ embedding 转向量
→ 在缓存里找最相似的已答问题
├─ 相似度 ≥ 阈值 → 命中，直接返回缓存答案（不调大模型）
└─ 相似度 < 阈值 → 走完整 RAG，再把新问答写进缓存
判断命中靠相似度，常见用余弦相似度，范围从 -1 到 1。两个问句向量越接近，值越接近 1。超过阈值就算命中。这就是"语义"两个字的意思：它认的是意思像不像，不是字面一不一样。
三、落地：数据放哪，怎么比
缓存里要存两类东西：答案原文，和问句的向量。答案原文放哪、向量放哪，决定了这套系统好不好维护。
| 数据 | 建议存放 | 作用 |
|---|---|---|
| 答案原文 + 元数据 | MySQL / 对象存储 | 命中后返回，可查可审计 |
| 问句向量 | Redis / 向量库 | 相似度检索 |
| 命中统计 | MySQL 一张日志表 | 算命中率、做监控 |
向量检索这块，量小用 Redis 的向量能力就能顶住，量大再上独立的向量库。关键点在于，别把答案原文也塞进向量库。向量库里只放向量和指针，原文留在 MySQL 里，这样原文要改、要审计都方便，向量库挂了也不丢答案。
这么分是有代价的：多养一套组件。原文在一个库，向量在另一个库，跨库调用和一致性都得自己兜。有没有更省事的存法？我后来看到一条路，金仓 KES 把向量做成了原生类型，原文和向量放同一个引擎，向量相似度匹配和标量过滤可以在一条 SQL 里完成。少维护一层东西，排查的时候能少绕一圈。手上有信创选型的，可以顺手评估下。当然没这条件，前面那套两库方案照样跑得动，别为了架构好看硬折腾。
MySQL 这边的日志表，是后面调参和算账的基础。每次问答记一行，是不是缓存命中、用的哪个阈值，都落下来。
CREATE TABLE llm_cache_log (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
ts DATETIME NOT NULL,
query_md5 CHAR(32) NOT NULL,
is_hit TINYINT NOT NULL DEFAULT 0,
similarity DECIMAL(5,4) NULL,
model_cost_tokens INT NULL,
INDEX idx_ts (ts)
) ENGINE=InnoDB;
四、真正的难点不是技术，是阈值和一致性
语义缓存看着简单，落地全是坑。最大的坑是阈值。
阈值定太高，命中率低，省不了钱；定太低，把意思不一样的问题当成一样的，返回答非所问的答案，比慢更糟。我用 800 条测试问句跑了一遍，其中一半是意思相近的重复问法，一半是无关问题，看不同阈值下的表现：
| 相似度阈值 | 命中率 | 答非所问率 |
|---|---|---|
| 0.85 | 78% | 3.1% |
| 0.90 | 66% | 0.8% |
| 0.93 | 57% | 0.2% |
| 0.95 | 43% | <0.1% |
我最后选了 0.93。客服问答这种场景，宁可少命中一点，也不能把错误答案发给用户。如果是合同条款、政策解释这种错不起的，阈值要拉到 0.96 以上，甚至干脆不缓存。
第二个难点是知识库更新了怎么办。缓存里的答案是拿旧文档生成的，文档一改，旧答案就过期了。精确到"哪条答案对应哪篇文档"太难，我用的是笨办法：版本号隔离。每次知识库发布，缓存整体换个命名空间，旧缓存让它自然过期，新问题重新走 RAG 生成。再给缓存设个 TTL，比如 7 天，兜底防止答案永远不更新。
第三个难点是别什么答案都缓存。用户问"现在库存还有多少""推荐个适合我的方案"，这种结果实时变、或者因人而异的，缓存了就是坑。语义缓存只适合答案稳定的场景：使用手册、政策条文、FAQ。我会在代码里按问题类型打标，只有确定性的问题才允许写缓存。
第四个难点是多租户和隐私。用户 A 问的私密问题，不能因为用户 B 问了句意思相近的，就把 A 的答案返回给 B。缓存必须按租户隔离，检索只在同一个租户的范围内做，涉及个人信息的问句直接不缓存。这条是底线，不是调优项。
五、实测：命中率、延迟和成本
方案上线跑了两周，监控表里看数据。先看整体命中率和成本：
| 指标 | 无缓存 | 有语义缓存 |
|---|---|---|
| 平均首字延迟 | 约 3.2 秒 | 命中时约 0.45 秒 |
| 日大模型 tokens | 约 1280 万 | 约 480 万 |
| 折算日成本 | 约 5120 元 | 约 1960 元 |
大模型 tokens 降了约六成，成本跟着降了约六成。命中时首字延迟从三秒多压到半秒以内，用户的体感是"机器人变快了"。数据库那边的读 QPS，也从高峰期回落了不少，因为重复问题不再每次都去文档库检索、回表。
命中率怎么盯，直接查日志表：
SELECT DATE(ts) AS d,
SUM(is_hit) AS hit_cnt,
COUNT(*) AS total,
ROUND(SUM(is_hit)/COUNT(*)*100, 1) AS hit_rate
FROM llm_cache_log
GROUP BY DATE(ts)
ORDER BY d DESC;
除了命中率，我每周还会人工抽检一百条命中记录，看返回的答案是不是真对得上问题。指标会骗人，答非所问率只有抽检才看得见。这是语义缓存上线后必须长期做的功课。
六、什么时候别用语义缓存
语义缓存不是万能的，有几类场景我明确不碰。
实时数据不缓存。库存、价格、天气、订单状态，问一次一个样，缓存命中就是在发过期信息。这种该走实时查询，别为了省 tokens 把业务带沟里。
个性化内容不缓存。推荐方案、千人千面的回答，每个用户要的不一样，语义相近也不该共享答案。缓存它，等于把 A 的偏好硬塞给 B。
错误答案更不能缓存。大模型偶尔会答错，一旦进了缓存，所有意思相近的问题都会命中这个错误答案，等于把一次偶发错误放大成系统性错误。我的做法是，低置信度、被用户点踩、或者人工标记过的回答，一律禁止写缓存。
语义缓存的定位，是给"重复的确定性问答"减负，不是给所有 AI 流量兜底。分清哪些能缓存，比怎么缓存更重要。
避坑清单
阈值别拍脑袋定。用一批"相近问法 + 无关问题"的测试集，把不同阈值下的命中率和答非所问率都跑出来再选。业务错不起就把阈值拉高，宁可不命中，别答错。我见过有人图命中率好看，把阈值压到 0.85，答非所问率三个点，用户骂声一片。
知识库更新后记得让缓存失效。文档改了，旧答案还挂在缓存里，用户会一直拿到过期信息。我用版本号换命名空间 + TTL 兜底，发布流程里把清缓存这一步写死，别靠人记。
多租户场景，缓存必须按租户隔离，含隐私的问句别缓存。这条比命中率重要得多。向量检索范围一旦跨了租户，就是数据泄露，不是性能问题了。上线前先把隔离规则定清楚。
我的判断
AI 应用火了之后，大家都在盯着大模型的"聪明"，少有人算它有多贵、把数据库压得多狠。语义缓存解决的就是这个问题：把重复的、确定性的问答挡在缓存层，让大模型只回答真正的新问题。
作为数据库出身的人，我看这套东西其实很亲切。它本质还是缓存那套老手艺：命中率、淘汰策略、一致性、隔离。只是匹配的键从字符串换成了向量。这两年国产库也在补这块。金仓 KES 把向量检索做进了内核，缓存和业务数据收在同一套库里。技术会变，底层的工程问题没变过。谁先把这些老问题管好，谁就能把这波 AI 的红利吃得更稳。
你们的 AI 应用上缓存了吗？是被数据库 QPS 逼的，还是被大模型账单逼的？评论区聊聊，我猜大多数人是被后者。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
