大模型语义缓存：让AI系统又快又省钱的关键技术

一、先说结论：语义缓存到底是什么？

大模型语义缓存，简单说就是：

用户问的问题意思差不多，就不再重复调用大模型，而是直接返回之前缓存过的答案。

普通缓存看的是“字面是否一样”。

比如：

什么是RAG？

和：

RAG是什么意思？能不能解释一下？

普通缓存会认为这是两个不同问题，因为文字不一样。

但语义缓存会认为：

这两个问题表达的是同一个意思。

于是它会直接复用之前生成过的答案，不再重新请求大模型。

在生成式AI应用中，语义缓存通常会把用户问题转成向量，并把问题向量和模型回答一起存起来；新问题进来后，再和历史问题向量做相似度匹配，如果足够相似，就直接返回缓存答案，而不是再次调用LLM。

二、为什么大模型系统特别需要语义缓存？

1、因为大模型调用很贵

传统系统里，请求一次接口可能只是查数据库、查Redis、查ES。

但大模型系统不一样。

一次完整调用可能包括：

用户提问；
意图识别；
Prompt组装；
向量检索；
知识召回；
大模型生成；
后处理；
安全审核；
结果返回。

其中最贵的通常是：

大模型推理成本。

尤其是：

输入内容很长；
Prompt里拼了大量上下文；
输出内容很长；
并发用户很多；
多轮对话频繁调用模型。

如果用户大量问类似问题，每次都重新调用大模型，就会非常浪费。

例如客服场景：

会员怎么退款？
会员退款流程是什么？
开通会员后能退吗？
买错会员怎么退？

这些问题表达不同，但本质都在问“会员退款”。

如果每个问题都重新调用大模型，成本就会不断上升。

2、因为大模型响应慢

普通接口可能几十毫秒返回。

但大模型生成答案，尤其是私有化部署的大模型，可能需要：

几百毫秒；
几秒；
甚至十几秒。

如果答案已经生成过，再走一次模型，就没有必要。

语义缓存的价值就是：

能不调用模型，就不调用模型。

命中缓存后，系统只需要：

生成当前问题的向量；
查询相似问题；
判断相似度；
返回历史答案。

这通常比完整调用大模型快很多。

3、因为用户问题高度重复

在真实业务里，用户的问题并没有想象中那么分散。

很多系统上线后，会发现大量问题其实集中在少数主题上。

例如：

客服场景

怎么退款？
怎么改手机号？
发票怎么开？
订单在哪里看？
物流多久到？

营销场景

帮我生成短信文案；
帮我写活动标题；
帮我总结活动效果；
帮我分析用户画像；
帮我生成复盘报告。

企业知识库场景

报销流程是什么？
年假怎么申请？
合同审批走哪个流程？
服务器权限怎么申请？

这些问题天然适合做语义缓存。

三、普通缓存和语义缓存有什么区别？

1、普通缓存：必须一模一样才命中

普通缓存一般是这样的：

key = 用户问题原文
value = 大模型回答

比如缓存了：

key = 什么是语义缓存？
value = 语义缓存是一种基于语义相似度复用答案的技术……

用户下一次问：

什么是语义缓存？

可以命中。

但如果用户问：

语义缓存是什么意思？

普通缓存可能就命不中。

因为字面不一样。

2、语义缓存：意思相近就可以命中

语义缓存不直接拿原文做key，而是先把问题转成向量。

可以理解为：

把一句话转换成一串能代表“意思”的数字特征。

不用纠结数学细节，通俗理解就是：

“退款怎么操作”
“怎么申请退款”
“买错了怎么退钱”

这些句子虽然文字不一样，但表达的意思接近，所以转成向量后距离也比较接近。

语义缓存就是利用这个特点来判断：

当前问题和历史问题是不是在问同一件事。

GPTCache 这类开源方案就是典型语义缓存实现，它会把输入问题转为 embedding，再通过向量存储查找最相似的历史请求，并用相似度结果判断是否复用答案；它支持 Milvus、Zilliz Cloud、FAISS 等向量存储。

四、语义缓存的核心工作流程

可以把语义缓存理解成一个“聪明的AI答题记录本”。

整体流程如下：

用户提问
 ↓
问题标准化处理
 ↓
生成问题向量
 ↓
去语义缓存中查相似问题
 ↓
判断是否命中
 ↓
命中：直接返回历史答案
 ↓
未命中：调用大模型生成答案
 ↓
把新问题、新答案、新向量写入缓存

五、一步步拆解语义缓存怎么做

1、第一步：用户问题进入系统

用户输入：

会员开错了可以退款吗？

系统不要急着调用大模型。

应该先经过缓存层。

因为这类问题很可能之前有人问过。

2、第二步：问题清洗和标准化

用户问题进入缓存前，最好先做一层清洗。

比如：

会员开错了可以退款吗？？？？？

可以清洗成：

会员开错了可以退款吗？

常见清洗包括：

去掉多余空格；
去掉重复标点；
简繁转换；
大小写统一；
去除无意义口头语；
去除表情符号；
敏感信息脱敏。

例如：

我手机号是138xxxx，会员开错了可以退款吗？

不要直接把手机号写入缓存。

应该脱敏成：

用户手机号已脱敏，会员开错了可以退款吗？

否则可能造成隐私泄露。

3、第三步：生成问题向量

清洗后，把问题送到 embedding 模型。

例如：

会员开错了可以退款吗？

会转成一个向量。

不用理解向量的数学含义，只要知道：

向量是机器理解语义的一种表达方式。

意思接近的问题，向量距离更近。

意思不同的问题，向量距离更远。

例如：

会员开错了可以退款吗？
会员买错了怎么退？
开通会员后能不能退钱？

这几个问题的向量会比较接近。

而：

会员开错了可以退款吗？
怎么修改收货地址？

这两个问题的向量距离就会比较远。

4、第四步：查询语义缓存

有了当前问题向量后，就可以去缓存库里查相似问题。

常见存储方案包括：

Redis Vector；
Milvus；
FAISS；
Elasticsearch 向量检索；
PostgreSQL pgvector；
Qdrant；
Weaviate；
Chroma；
Zilliz Cloud。

如果是高并发、低延迟场景，可以优先考虑 Redis + 向量检索。

Redis 在2025年也推出了 LangCache，用于AI应用和Agent的托管语义缓存，同时还推出了 Vector Sets，增强Redis里的向量使用能力。

5、第五步：判断是否命中缓存

查到相似问题后，不能直接返回。

必须判断：

相似度是否足够高。

比如查到历史问题：

历史问题：会员买错了怎么退款？
历史答案：可以在订单中心申请退款……

当前问题：

会员开错了可以退款吗？

这两个问题很接近，可以命中。

但如果当前问题是：

会员开错了可以转给别人吗？

它虽然也提到了“会员开错了”，但问的是“转让”，不是“退款”。

这时候如果直接返回退款答案，就错了。

所以语义缓存一定要有阈值控制。

简单理解：

相似度很高：直接返回缓存
相似度中等：可以让大模型二次判断
相似度较低：不命中，重新生成

6、第六步：命中后直接返回答案

如果判断命中，就可以直接返回历史答案。

例如：

用户问题：会员开错了可以退款吗？
 
缓存命中问题：会员买错了怎么退款？
 
缓存答案：可以在订单中心申请退款，如果订单符合退款规则，系统会自动处理……

这时候不需要调用大模型。

系统响应速度会明显变快。

7、第七步：未命中则调用大模型

如果没有找到相似问题，或者相似度不够，就走正常大模型链路。

用户问题
 ↓
RAG检索
 ↓
Prompt组装
 ↓
调用大模型
 ↓
返回答案

然后再把这次问题和答案写入语义缓存。

下次类似问题就可以复用。

六、语义缓存一般缓存什么？

很多人会误解：

是不是只缓存用户问题和最终答案？

实际企业级系统里，缓存内容可以更丰富。

一般包括：

1、用户原始问题

会员开错了可以退款吗？

用于排查问题和展示命中来源。

2、标准化后的问题

会员开错可以退款吗？

用于生成向量和检索。

3、问题向量

用于相似度搜索。

4、大模型回答

可以退款，但需要满足平台退款规则……

这是缓存的核心价值。

5、业务场景

例如：

scene = customer_service

不同场景不能混用。

客服问题不能和营销文案问题混在一起。

6、租户ID

如果是SaaS系统，必须按租户隔离。

tenant_id = company_001

A公司的答案不能返回给B公司。

7、用户角色

例如：

role = admin
role = normal_user

管理员能看到的答案，普通用户不一定能看到。

8、Prompt版本

同一个问题，不同Prompt版本生成的答案可能不同。

所以要记录：

prompt_version = v3.2

后续Prompt升级时，可以决定是否清理旧缓存。

9、知识库版本

RAG 场景尤其重要。

如果知识库内容变了，旧答案可能过期。

所以要记录：

kb_version = 2026-05-08

10、模型版本

不同模型回答风格和质量不同。

例如：

model = Qwen3-32B
model_version = 2026-04

模型升级后，缓存是否继续复用，要谨慎判断。

11、过期时间

缓存不能永久有效。

例如：

ttl = 7天

不同业务设置不同过期时间。

七、语义缓存适合放在哪一层？

语义缓存可以放在多个位置。

不同位置效果不同。

1、放在网关层

例如：

用户请求
 ↓
AI网关
 ↓
语义缓存
 ↓
大模型服务

优点：

接入简单；
多个业务系统可以共用；
统一做限流、鉴权、审计；
统一统计命中率和节省成本。

缺点：

网关不一定理解具体业务；
复杂业务条件不好判断；
容易误缓存。

这种方式适合通用问答、标准客服、通用Agent平台。

一些API网关方案也在强调在LLM代理层做语义缓存：把Prompt转成向量，与向量库中的历史Prompt对比，相似度足够高时直接返回缓存答案，而不调用LLM。

2、放在业务服务层

例如：

Java业务系统
 ↓
语义缓存模块
 ↓
AI服务
 ↓
大模型

优点：

更懂业务；
可以结合用户权限；
可以按场景隔离；
可以控制缓存粒度；
更适合生产系统。

缺点：

每个业务都要接入；
架构复杂度更高。

企业真实落地时，我更推荐：

业务服务层做主缓存控制，网关层做通用兜底。

3、放在RAG检索前

这叫问题级缓存。

流程是：

用户问题
 ↓
语义缓存
 ↓
命中：直接返回
 ↓
未命中：走RAG检索

优点：

连向量检索都省了；
成本最低；
速度最快。

缺点：

对缓存准确率要求很高；
知识库变更后容易返回旧答案。

适合高频稳定问题。

例如：

报销流程是什么？
会员怎么退款？
发票怎么开？

4、放在RAG检索后

流程是：

用户问题
 ↓
RAG检索
 ↓
Prompt组装
 ↓
语义缓存
 ↓
命中：返回
 ↓
未命中：调用大模型

这种方式缓存的是：

问题 + 检索上下文 + Prompt

优点：

更准确；
不容易因为知识库上下文不同而误命中；
适合知识库问答。

缺点：

已经做过一次检索；
节省不了检索成本；
缓存命中率可能下降。

LangChain 里的 RedisSemanticCache 就属于基于 Redis 和向量相似搜索实现语义缓存的方案。

八、语义缓存和普通Redis缓存是什么关系？

可以这样理解：

普通Redis缓存

适合缓存确定性数据。

例如：

用户ID -> 用户信息
商品ID -> 商品详情
订单ID -> 订单状态

特点是：

key完全一致，value才复用。

语义缓存

适合缓存相似问题的答案。

例如：

用户问题语义 -> 大模型回答

特点是：

key不一定完全一致，只要意思接近就可能复用。

九、语义缓存和Prompt缓存有什么区别？

这两个很容易混淆。

1、Prompt缓存

Prompt缓存主要缓存的是大模型推理过程中的公共前缀。

比如系统提示词很长：

你是一个专业客服助手……
以下是公司规则……
以下是商品政策……

每次请求都带这一大段内容。

Prompt缓存可以让模型复用这部分前缀计算，减少推理成本。

它更偏底层推理优化。

2、语义缓存

语义缓存缓存的是问题和答案。

比如：

问题：会员怎么退款？
答案：可以在订单中心申请退款……

用户再问类似问题，就直接返回答案。

它更偏应用层优化。

3、简单区别

Prompt缓存：复用模型计算过程
语义缓存：复用最终回答结果

两者可以一起用。

企业级AI系统里，常见组合是：

普通缓存 + 语义缓存 + Prompt缓存 + KV缓存

十、语义缓存和KV缓存有什么区别？

KV缓存是大模型推理内部的缓存。

它缓存的是模型生成过程中的中间状态。

主要用于：

加速多Token生成；
多轮对话复用前文；
推理框架优化；
降低重复计算。

语义缓存是应用层缓存。

它缓存的是：

相似问题 -> 历史答案

简单说：

KV缓存：模型内部用的
语义缓存：业务系统用的

十一、语义缓存和向量数据库是什么关系？

语义缓存通常离不开向量数据库。

因为它需要做：

当前问题向量 -> 查找相似历史问题向量

向量数据库负责存储和检索这些问题向量。

常见选择：

1、Redis

适合低延迟、高并发、热数据缓存。

优势：

速度快；
架构简单；
适合缓存场景；
可以同时做普通缓存和向量缓存。

适合：

AI网关语义缓存
客服高频问题缓存
短周期热点问题缓存

2、Milvus

适合大规模向量检索。

优势：

专业向量数据库；
支持大规模数据；
检索能力强；
生态成熟。

适合：

大规模知识库
海量问题库
长期语义缓存

3、FAISS

适合本地化、轻量化、实验场景。

优势：

性能好；
部署简单；
适合单机实验。

缺点：

工程化能力弱；
分布式能力需要自己封装；
不太适合复杂生产场景。

4、Elasticsearch

适合已经有ES体系的公司。

优势：

可以同时做关键词检索和向量检索；
运维团队熟悉；
方便结合日志和搜索系统。

缺点：

极致向量检索能力不如专业向量库；
成本和调优复杂度较高。

十二、语义缓存的典型架构设计

一个比较完整的生产架构可以这样设计：

用户请求
 ↓
API网关
 ↓
鉴权 / 限流 / 黑白名单
 ↓
业务服务
 ↓
问题清洗 / 脱敏 / 标准化
 ↓
Embedding服务
 ↓
语义缓存查询
 ↓
相似度判断
 ↓
命中缓存？
 ├─ 是：返回缓存答案
 └─ 否：进入RAG / Agent / LLM链路
          ↓
       大模型生成
          ↓
       后处理 / 审核
          ↓
       写入语义缓存
          ↓
       返回用户

十三、企业级语义缓存要考虑哪些字段？

可以设计一张缓存元数据表。

1、缓存主表

cache_id：缓存ID
tenant_id：租户ID
scene_code：业务场景
question_raw：用户原始问题
question_norm：标准化问题
answer：缓存答案
answer_type：答案类型
model_name：模型名称
model_version：模型版本
prompt_version：Prompt版本
kb_version：知识库版本
hit_count：命中次数
quality_score：质量评分
status：缓存状态
expire_time：过期时间
create_time：创建时间
update_time：更新时间

2、向量存储表

cache_id：缓存ID
embedding：问题向量
scene_code：业务场景
tenant_id：租户ID
create_time：创建时间

3、命中日志表

log_id：日志ID
request_id：请求ID
user_question：用户问题
matched_cache_id：命中的缓存ID
similarity_score：相似度分数
hit_type：命中类型
response_time：响应耗时
create_time：创建时间

十四、语义缓存的命中策略怎么设计？

不能只靠一个相似度阈值。

生产系统建议分层判断。

1、第一层：业务场景必须一致

例如：

客服场景
营销文案场景
知识库问答场景
数据分析场景

不同场景不能互相命中。

用户问：

帮我生成退款说明文案

和：

退款规则是什么？

这两个都包含“退款”，但业务目的不同。

一个是生成文案，一个是查规则。

不能混用。

2、第二层：租户必须一致

如果是多租户系统，必须隔离。

tenant_id必须一致

否则可能出现：

A公司的内部制度，返回给B公司用户。

这是严重事故。

3、第三层：权限必须一致

同样的问题，不同角色答案可能不同。

例如：

这个客户的投诉记录是什么？

客服主管能看，普通客服不一定能看。

所以语义缓存不能绕过权限系统。

4、第四层：知识库版本要一致

如果知识库更新了，旧答案可能失效。

例如旧政策：

会员7天内可退款。

新政策：

会员3天内可退款。

如果缓存没失效，就会返回错误答案。

所以RAG系统里要记录：

kb_version
doc_version
policy_version

5、第五层：相似度阈值判断

常见策略：

高相似度：直接命中
中相似度：进入二次判断
低相似度：不命中

例如：

相似度 > 0.90：直接返回
0.80 - 0.90：让小模型/规则再判断
< 0.80：不命中

具体数值不能照抄，要根据业务评测集调出来。

6、第六层：答案质量评分

不是所有历史答案都应该缓存。

可以设置：

quality_score >= 80 才允许复用

答案质量来源可以包括：

人工审核；
用户点赞；
用户追问率；
投诉率；
规则校验结果；
模型自评结果。

十五、为什么语义缓存不能乱用？

语义缓存虽然好用，但风险也很明显。

1、可能返回错误答案

例如：

用户问：会员可以退款吗？
缓存问题：会员可以续费吗？

如果向量模型判断不准，可能误命中。

结果就会答非所问。

2、可能返回过期答案

政策、价格、活动、库存、权限，都可能变化。

比如：

今天有什么优惠？

这种问题就不适合长时间缓存。

3、可能泄露隐私

如果缓存里包含用户个人信息：

你的订单号是xxx，手机号是xxx……

被其他相似问题命中，就可能造成数据泄露。

所以缓存前必须脱敏。

4、可能影响个性化体验

用户A问：

帮我推荐适合我的套餐。

用户B也问：

推荐一个套餐。

这两个问题很像，但用户画像不同，答案不应该复用。

所以个性化强的问题，要慎用语义缓存。

十六、哪些场景适合语义缓存？

1、客服问答

非常适合。

因为问题重复率高。

例如：

怎么退款？
怎么开发票？
怎么修改手机号？
怎么查看订单？

2、企业知识库问答

适合。

例如：

报销流程是什么？
年假怎么申请？
权限怎么开通？
合同怎么审批？

但要注意知识库版本。

3、营销文案生成

部分适合。

例如：

帮我写一个618短信文案
帮我生成会员召回文案
帮我写活动标题

如果业务要求创意多样性，就不能完全复用。

可以缓存：

模板
结构
示例
风格

而不是直接缓存最终文案。

4、数据分析解释

部分适合。

例如：

什么是转化率？
什么是留存率？
什么是ROI？

这些概念解释可以缓存。

但如果问题涉及实时数据：

今天转化率为什么下降？

就不能简单复用旧答案。

5、代码助手

部分适合。

例如：

Java怎么实现限流？
Redis怎么做分布式锁？

这些通用问题可以缓存。

但如果涉及用户具体代码，就不适合直接复用。

十七、哪些场景不适合语义缓存？

1、强实时问题

例如：

今天库存是多少？
现在订单状态是什么？
当前余额是多少？

这些问题必须查实时数据。

2、强个性化问题

例如：

根据我的情况推荐方案。

不同用户答案不同，不适合直接复用。

3、权限敏感问题

例如：

某个客户的手机号是多少？
某个员工工资是多少？

这类问题要谨慎，甚至禁止缓存。

4、法律、医疗、金融高风险建议

例如：

我这个病该吃什么药？
这只股票能买吗？
这个合同有没有法律风险？

这类问题不能随便复用旧答案。

5、创意生成要求高的场景

例如：

帮我写10个完全不同的广告语。

如果缓存命中，用户可能觉得答案重复、不新鲜。

十八、语义缓存怎么和RAG结合？

RAG系统一般流程是：

用户问题
 ↓
向量检索知识库
 ↓
召回相关文档
 ↓
组装Prompt
 ↓
调用大模型
 ↓
生成答案

加入语义缓存后，可以有两种做法。

1、RAG前置缓存

用户问题
 ↓
语义缓存
 ↓
命中直接返回
 ↓
未命中再走RAG

优点：

最省钱；
最快；
可以跳过检索和大模型。

缺点：

容易受知识库变更影响；
缓存准确性要求很高。

适合高频稳定问答。

2、RAG后置缓存

用户问题
 ↓
RAG检索
 ↓
得到相关文档
 ↓
语义缓存判断
 ↓
命中返回
 ↓
未命中调用大模型

优点：

更安全；
答案更贴近当前知识库；
误命中风险低。

缺点：

节省不了检索成本；
链路稍长。

适合企业知识库、政策问答、制度问答。

十九、语义缓存怎么和Agent结合？

Agent系统比普通问答更复杂。

因为Agent可能会：

调工具；
查数据库；
查接口；
多步推理；
执行任务；
生成总结。

Agent场景下，不能简单缓存最终答案。

更推荐分层缓存。

1、缓存意图识别结果

例如：

用户问题：帮我查一下这个订单物流
意图：查询物流

类似问题可以复用意图判断。

2、缓存工具选择结果

例如：

问题：订单到哪里了？
工具：物流查询工具

这样可以减少Agent规划成本。

3、缓存工具调用结果

这个要谨慎。

如果工具结果实时变化，就不能长缓存。

例如订单状态、库存、余额，都要短TTL。

4、缓存最终总结

如果工具结果相同，最终总结可以缓存。

例如：

订单状态相同 + 用户问题相似

可以复用总结话术。

二十、语义缓存的生产级落地方案

下面给一个比较企业级的方案。

1、请求进入Java业务系统

Java系统接收请求：

POST /ai/chat

请求包含：

{
  "tenantId": "t001",
  "userId": "u001",
  "scene": "customer_service",
  "question": "会员开错了可以退款吗？"
}

2、Java做基础校验

包括：

鉴权；
限流；
参数校验；
敏感词检查；
租户隔离；
用户权限判断。

3、Java调用Embedding服务

Java可以通过HTTP调用Python AI服务：

Java服务
 ↓ HTTP/gRPC
Embedding服务
 ↓
返回问题向量

Embedding服务可以用：

bge-large-zh；
bge-m3；
text-embedding 模型；
企业内部训练的embedding模型。

4、查询向量缓存

Java拿到向量后，去Redis/Milvus查相似问题。

查询条件不要只查向量，还要带过滤条件：

tenant_id = 当前租户
scene = 当前场景
status = enabled
expire_time > now
kb_version = 当前知识库版本

5、判断是否命中

伪代码：

if (similarityScore >= highThreshold) {
    return cacheAnswer;
}
 
if (similarityScore >= middleThreshold) {
    boolean pass = secondCheck(question, matchedQuestion);
    if (pass) {
        return cacheAnswer;
    }
}
 
return callLLM();

6、未命中调用大模型

未命中后，走完整AI链路：

问题改写
 ↓
意图识别
 ↓
RAG召回
 ↓
Prompt组装
 ↓
大模型生成
 ↓
后处理
 ↓
安全审核

7、答案写入缓存

不是所有答案都写入。

需要判断：

是否可缓存；
是否包含隐私；
是否依赖实时数据；
是否通过安全审核；
是否质量达标；
是否命中黑名单场景。

可缓存才写入。

二十一、语义缓存的更新和失效机制

语义缓存最怕“旧答案一直被复用”。

所以必须设计失效机制。

1、TTL过期

最简单。

例如：

客服常见问题：7天
营销文案：1天
政策制度：看知识库版本
实时数据：不缓存或几分钟

2、知识库更新后失效

如果某篇文档更新了，相关缓存要失效。

例如：

退款规则文档更新
 ↓
清理退款相关缓存

可以通过标签实现：

cache_tags = ["退款", "会员", "售后"]

更新退款规则时，删除包含“退款”标签的缓存。

3、Prompt版本升级后失效

Prompt变化会影响答案质量。

例如：

prompt_version: v1 -> v2

可以只命中新版本缓存。

4、模型升级后失效

模型升级后，回答风格可能变化。

可以设置：

model_version必须一致

或者灰度复用旧缓存。

5、人工下架

如果发现某条缓存答案有问题，要支持后台禁用。

status = disabled

二十二、语义缓存的安全设计

企业系统里，语义缓存必须重视安全。

1、缓存前脱敏

比如：

手机号
身份证号
银行卡号
地址
订单号
合同编号
客户姓名

这些内容要脱敏或不入缓存。

2、按租户隔离

多租户系统必须做到：

A租户只能查A租户缓存

3、按权限隔离

管理员答案和普通用户答案不能混用。

4、敏感场景禁用缓存

例如：

工资
合同
财务
医疗
法律
个人隐私
账户余额

这些场景最好禁用语义缓存，或者只缓存通用解释，不缓存具体结果。

5、命中日志可追踪

每次缓存命中，都要记录：

谁问的
问了什么
命中了哪条缓存
相似度是多少
返回了什么
耗时多少

方便排查问题。

二十三、语义缓存的监控指标

上线后不能只看“有没有命中”。

要看完整指标。

1、缓存命中率

命中次数 / 总请求次数

命中率越高，说明复用效果越好。

但不能盲目追求高命中率。

命中率太高，可能是阈值太低，存在误命中风险。

2、误命中率

这是最重要的指标之一。

例如用户问A，系统返回B的答案。

这就是误命中。

要通过：

人工抽检；
用户反馈；
点踩率；
追问率；
日志分析；

持续优化。

3、节省Token数

语义缓存可以减少大模型调用。

要统计：

节省了多少输入Token
节省了多少输出Token
节省了多少费用

4、平均响应耗时

对比：

命中缓存耗时
未命中耗时
完整LLM耗时

这样才能看出优化效果。

5、缓存答案质量

可以统计：

点赞率；
点踩率；
重新提问率；
人工质检通过率；
业务完成率。

二十四、语义缓存常见问题

1、相似度阈值怎么定？

不要拍脑袋。

建议用评测集调。

准备一批问题对：

问题A
问题B
是否应该命中

例如：

会员怎么退款？ / 会员买错了怎么退？ / 应该命中
会员怎么退款？ / 会员怎么续费？ / 不应该命中

然后测试不同阈值下的效果。

目标不是命中率最高，而是：

在误命中可控的前提下，提高命中率。

2、缓存答案会不会不准确？

会。

所以要做：

场景隔离；
权限隔离；
知识库版本控制；
TTL过期；
高风险场景禁用；
中等相似度二次判断；
人工审核高频缓存。

3、语义缓存是不是一定要用大模型判断？

不一定。

常见组合：

Embedding相似度判断
+
规则判断
+
小模型二次判断

只有中间灰区才需要大模型判断。

例如：

相似度 > 0.92：直接命中
0.82 - 0.92：小模型判断
< 0.82：不命中

这样成本更可控。

4、缓存答案要不要流式返回？

可以。

如果命中缓存，可以模拟流式输出。

前端体验保持一致。

例如：

缓存答案按句子分段返回

这样用户不会感觉“有时候流式，有时候瞬间返回”很割裂。

5、语义缓存会不会影响模型创造力？

会。

所以创意类任务不要直接复用最终答案。

可以缓存：

Prompt模板；
文案结构；
历史优秀案例；
生成策略；
中间分析结果。

最终内容仍然让模型重新生成。

二十五、一个完整案例：客服问答语义缓存

用户问：

会员开错了可以退款吗？

系统流程：

缓存答案：

如果会员订单符合退款规则，可以在订单中心提交退款申请。系统会根据订单状态、开通时间和使用情况进行判断，具体以页面提示为准。

这次请求不需要调用大模型。

结果：

响应更快；
成本更低；
答案更稳定；
用户体验更好。

二十六、一个完整案例：营销文案语义缓存

用户问：

帮我写一个618会员召回短信。

系统查到历史问题：

生成618老用户召回短信。

如果直接返回旧文案，可能会显得重复。

所以更好的做法是：

缓存历史结构：

利益点 + 限时感 + 行动引导

缓存历史示例：

亲爱的会员，618专属福利已开启……

然后让大模型重新生成新文案。

这样既节省了一部分推理成本，又保留了创意变化。

二十七、语义缓存的推荐技术选型

1、小规模系统

适合：

Redis + 向量检索

特点：

架构简单；
延迟低；
易接入；
适合快速上线。

2、中大型系统

适合：

Redis + Milvus

Redis存热点缓存。

Milvus存长期语义缓存。

Redis：高频热点
Milvus：大规模历史
MySQL：元数据
ES：日志检索

3、企业知识库系统

适合：

Milvus / Elasticsearch / pgvector + MySQL

重点是：

知识库版本；
文档权限；
缓存失效；
审计日志。

4、Agent平台

适合：

Redis + 向量库 + 状态库

缓存内容包括：

意图识别；
工具选择；
中间结果；
最终总结；
用户偏好。

二十八、语义缓存最佳实践

1、不要全局混用缓存

一定要按场景隔离。

客服缓存
营销缓存
知识库缓存
Agent缓存

2、不要只看相似度

还要看：

租户；
权限；
场景；
版本；
时间；
答案质量。

3、不要缓存隐私数据

涉及用户个人数据的答案要慎重。

4、不要缓存强实时问题

例如订单状态、库存、余额、价格。

5、要有缓存后台

支持：

查询缓存；
禁用缓存；
删除缓存；
查看命中日志；
查看质量评分；
手动调整答案。

6、要有灰度策略

刚上线时不要直接全量。

可以先：

只记录不返回

观察命中效果。

再逐步开启：

低风险问题自动返回
高风险问题人工审核

二十九、语义缓存的核心价值总结

语义缓存解决的是大模型应用里的一个核心问题：

很多问题意思相同，但系统却反复调用大模型，导致成本高、速度慢、稳定性差。

它通过：

问题向量化；
相似问题检索；
阈值判断；
答案复用；
缓存失效；
权限隔离；

让大模型系统变得更快、更省、更稳定。

总结

大模型语义缓存不是简单的Redis缓存，也不是简单地把问题和答案存起来。

它的本质是：

缓存“语义”，而不是缓存“文字”。

普通缓存要求问题一模一样。

语义缓存只要求问题意思相近。

在企业级AI系统中，语义缓存非常适合客服问答、知识库问答、标准流程解释、高频重复问题等场景。

但它也不是万能的。

对于实时数据、个性化推荐、权限敏感、金融医疗法律等高风险场景，必须谨慎使用。

真正生产级的语义缓存，一定要做到：

场景隔离；
租户隔离；
权限校验；
知识库版本控制；
Prompt版本控制；
TTL过期；
敏感信息脱敏；
命中日志审计；
质量评估；
灰度上线。

一句话概括：

语义缓存是大模型应用从“能用”走向“好用、省钱、稳定”的关键工程能力。