大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

客服机器人上线第二周，早上十点，数据库读 QPS 直接翻了三倍，慢查询开始往外冒。查日志发现，用户的问题高度重复，"发票怎么开""开发票流程是什么"这种话，一个上午能出现几十次，每一次都老老实实走完整套 RAG：向量检索、回表查文档、再调大模型生成。又慢又贵。

我给它前面加了一层语义缓存，意思相近的问题直接命中缓存答案，不再重复调大模型。两周跑下来，命中率五成七，大模型成本降了六成左右，数据库也消停了。今天把这套东西的原理、坑和实测数据一次讲清。

## 一、先算账：一次 RAG 回答到底有多贵

一次普通的 RAG 问答，背后不止一次大模型调用。用户提问后，系统要把问题向量化，去文档库里做相似度检索，把命中的几段原文捞回来拼成上下文，再整包丢给大模型生成答案。

```text
用户提问
  → ① embedding：问题转成向量（一次模型调用，便宜）
  → ② 向量检索：在文档库里找最相关的片段（数据库读）
  → ③ 回表取原文：按 id 把命中片段读出来（数据库读）
  → ④ 大模型生成：带着上下文生成答案（贵，还慢）
```

贵的是第 ④ 步。第 ②③ 步把数据库的读 QPS 顶上去，第 ④ 步把账单顶上去。最亏的是，这些问题大量重复。同一个意思换个说法又来一遍，前面几步全部重跑，答案还几乎一样。传统缓存只认字符串完全相等，"开发票"和"发票怎么开"匹配不上，等于没缓存。

## 二、语义缓存：用"像不像"代替"一不一样"

语义缓存的做法，是把问句也变成向量，拿它跟历史问句的向量比相似度。像到一定程度，就认为用户问的是同一件事，直接把上次的答案返回，不再调大模型。

```text
用户提问
  → embedding 转向量
  → 在缓存里找最相似的已答问题
      ├─ 相似度 ≥ 阈值 → 命中，直接返回缓存答案（不调大模型）
      └─ 相似度 < 阈值 → 走完整 RAG，再把新问答写进缓存
```

判断命中靠相似度，常见用余弦相似度，范围从 -1 到 1。两个问句向量越接近，值越接近 1。超过阈值就算命中。这就是"语义"两个字的意思：它认的是意思像不像，不是字面一不一样。

## 三、落地：数据放哪，怎么比

缓存里要存两类东西：答案原文，和问句的向量。答案原文放哪、向量放哪，决定了这套系统好不好维护。

| 数据 | 建议存放 | 作用 |
| ---- | ---- | ---- |
| 答案原文 + 元数据 | MySQL / 对象存储 | 命中后返回，可查可审计 |
| 问句向量 | Redis / 向量库 | 相似度检索 |
| 命中统计 | MySQL 一张日志表 | 算命中率、做监控 |

向量检索这块，量小用 Redis 的向量能力就能顶住，量大再上独立的向量库。关键点在于，别把答案原文也塞进向量库。向量库里只放向量和指针，原文留在 MySQL 里，这样原文要改、要审计都方便，向量库挂了也不丢答案。

这么分是有代价的：多养一套组件。原文在一个库，向量在另一个库，跨库调用和一致性都得自己兜。有没有更省事的存法？我后来看到一条路，金仓 KES 把向量做成了原生类型，原文和向量放同一个引擎，向量相似度匹配和标量过滤可以在一条 SQL 里完成。少维护一层东西，排查的时候能少绕一圈。手上有信创选型的，可以顺手评估下。当然没这条件，前面那套两库方案照样跑得动，别为了架构好看硬折腾。

MySQL 这边的日志表，是后面调参和算账的基础。每次问答记一行，是不是缓存命中、用的哪个阈值，都落下来。

```sql
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，也从高峰期回落了不少，因为重复问题不再每次都去文档库检索、回表。

命中率怎么盯，直接查日志表：

```sql
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 逼的，还是被大模型账单逼的？评论区聊聊，我猜大多数人是被后者。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


客服机器人上线第二周，早上十点，数据库读 QPS 直接翻了三倍，慢查询开始往外冒。查日志发现，用户的问题高度重复，"发票怎么开""开发票流程是什么"这种话，一个上午能出现几十次，每一次都老老实实走完整套 RAG：向量检索、回表查文档、再调大模型生成。又慢又贵。

客服机器人把数据库读QPS顶三倍：加一层语义缓存，大模型成本降62%

客服机器人上线两周，用户问题高度重复，每次都走完整套RAG，数据库读QPS翻三倍，大模型账单飞涨。文章讲清语义缓存怎么用"向量相似度"代替"字符串相等"去命中重复提问，落地时数据该存哪、相似度阈值怎么定，以及多租户隔离、知识库更新失效、别缓存低质量回答这几个真正的难点。附两周实测：命中率约57%，大模型成本降约62%，命中时首字延迟从3.2秒降到0.45秒。

数据库

人工智能

架构设计

客服机器人RAG成本高、响应慢？语义缓存以向量相似度判断重复问法，命中率57%，大模型成本降60%，首字延迟从3.2秒降至0.45秒。重点解析阈值调优、知识库更新、多租户隔离等避坑策略，并提供可落地的日志监控方案。

对象存储

数据泄露

代码解释

MySQL

Redis

2026上云采购 | AI焕新·智启新局

cslr

lexiang

cscbot

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

客服机器人把数据库读QPS顶三倍：加一层语义缓存，大模型成本降62%-腾讯云开发者社区-腾讯云

客服机器人把数据库读QPS顶三倍：加一层语义缓存，大模型成本降62%

客服机器人把数据库读QPS顶三倍：加一层语义缓存，大模型成本降62%

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐