语义缓存怎么用：大模型回答何时可以复用？

语义缓存可以省去重复的模型调用，前提是：不同说法的问题，确实可以安全地使用同一个答案。整个流程只有 4 步：将提示词转成向量、查找近邻、检查阈值，最后返回已存答案或调用模型。真正难的是判断：一个看起来很接近的问题，为什么仍然不能沿用原来的答案。

适合的起点是内容稳定的帮助中心，或公开的产品常见问题。大语言模型（LLM）负责生成答案，但不该仅仅因为用户换了一种问法，就重新解释一遍已发布的政策。账户余额、订单状态，以及发起退款等操作，都应排除在这种共享缓存之外。

下文的实现细节已于 2026 年 10 月 21 日依据一手文档核验。文中的商店案例为虚构示例；相似度分数仅用于说明判断过程，并非实测的向量计算结果。

语义缓存、精确缓存和提示词缓存有什么区别？

语义缓存在判断新请求与旧请求含义相近时，复用先前生成的回答。可以把它想象成客服从文件柜里查找已审核的答复：问法不同，也可能找到同一份文件，但客服仍要确认，这份答复适用的是哪项政策、哪位客户。

**嵌入向量（embedding）**是文本的数值表示，用来比较含义。缓存会保存旧提示词的向量、对应答案，以及用于识别适用情境的信息。新提示词也会被转成向量，再通过向量搜索查找邻近条目。Microsoft 的语义缓存文档介绍了这种回答复用方式，也解释了为什么必须考虑对话上下文。

这些缓存层省下的是不同环节的工作：

在精确响应缓存中，“这副耳机能退吗？”和“这副耳机可以退货吗？”通常对应不同的键。语义缓存则可以把这两种问法关联起来。但无论哪种方式，都无法让过时或适用范围错误的答案变得可靠。

模型服务商的提示词缓存，不会因为问题听起来相似就取出旧答案。 Anthropic 的提示词缓存文档说明了如何复用匹配的提示词前缀，并明确将其与输出生成区分开来。应用仍然需要让模型生成回答。KV cache 详解介绍了这一差异背后的模型侧状态。

这些缓存层可以一起使用：先查精确响应缓存，再查语义响应缓存，最后调用模型，并在可用时启用服务商的提示词缓存。评估语义缓存时，应与这套已经优化过的基线比较。

LLM 语义缓存如何工作？从请求到回答的 4 个步骤

缓存查找的目标，是在允许的上下文中找到可复用的答案。搜索之前先确定上下文：已认证的用户或租户、适用政策、语言，以及其他会改变回答内容的条件。

1. 1

   1. 将提示词转成向量

   使用与已存条目相同的嵌入模型和兼容配置，将新问题转成向量。应纳入理解请求所需的对话上下文；如果做不到，就只缓存不依赖上下文的独立问题。

   “那我的呢？”不能单独构成完整的缓存键。如果理解“我的”必须读取私人订单数据，就应绕过共享响应缓存。

2. 2

   2. 查找近邻候选

   在允许的范围内，搜索与新问题接近的已存提示词向量。取出每个候选条目的答案和元数据，也就是记录其归属、来源版本和过期时间的字段。

   最近邻只是搜索结果中距离最近的条目，仍然可能毫不相关。搜到了结果，不代表缓存命中。

3. 3

   3. 检查阈值与复用条件

   将候选条目的相似度或距离，与经过校准的阈值比较。然后检查那些会改变答案的字段，要求它们精确一致，例如商品状态、政策版本和访问范围。

   即使分数达标，只要上下文不符，就按未命中处理。无法可靠确定必要的上下文时，同样按未命中处理。

4. 4

   4. 返回已有答案或调用模型

   确认命中后，直接返回已存答案，无需再次调用模型生成。未命中时，执行正常的模型调用或检索流程，返回结果；只有结果符合缓存准入规则，才将其存入缓存。

   不要默认把每次模型输出都变成可复用的答案。错误内容、个人信息，以及依赖临时工具结果的回答，都可能不适合缓存。

它与语义搜索的关键区别，在于检索之后做什么。搜索展示相关资料；响应缓存则可能直接把旧答案当作本次请求的答案。因此，错误匹配的后果也更严重。

一个可以命中的问题，以及一个必须拒绝的相似问题

只改动一个条件，就可能让看似十分可信的匹配失效。假设一家虚构商店允许未拆封耳机退货，但不接受已拆封耳机。这里使用的是教学数据，不代表任何零售商的政策。

缓存中已有：

• 已存问题：“未拆封的耳机可以退货吗？”
• 已存答案：“可以。按照本店退货政策，未拆封的耳机符合退货条件。”
• **已存上下文：**该商店的当前政策版本、耳机品类、英语，以及 condition=unopened。

仅为说明这个例子，假设最低余弦相似度为 0.90。余弦相似度比较的是向量方向，不是答案正确的概率。下表中的分数均为虚构，只用于展示如何决策。

两个候选都超过了数值阈值，但只有换了一种说法的那个问题可以复用答案。另一个问题的商品、操作和大部分措辞都很相似，却改变了决定答案的关键事实。

如果商品状态已知，应用应将其作为结构化字段传递。如果必须从文本中提取状态，一旦无法确定，就应回到正常的回答流程。再做一次向量相似度比较，不能代替确认商品是否已经拆封。

哪些控制项决定答案能否安全复用？

阈值、有效期和适用范围需要共同发挥作用。只调阈值，仍然挡不住那些表述完全相同、却必须给出不同答案的请求。

相似度阈值：围绕错误答案做校准

更严格的阈值会牺牲一部分有效命中，以减少错误匹配。更宽松的阈值能增加复用，也可能增加错误复用。应从自己的真实流量中，整理带标注的同义改写和难负例；后者指的是看起来相似、答案却必须不同的问题。

测试集应包含日期、商品款型、否定表达、币种、账户角色和对话历史发生变化的情况。要判断的是已存答案能否用于新请求，而不只是两个提示词是否在谈同一个主题。

调参数前，先看清指标的定义。**Redis Vector Library（RedisVL）**是用于构建 Redis 向量搜索应用的库。其文档说明，distance_threshold 使用 Redis COSINE 距离，范围为 0 到 2，值越小，匹配越严格。最低相似度阈值的调整方向通常恰好相反。参见 RedisVL API 参考。

没有一个通用阈值，可以直接套用到不同的嵌入模型、数据集或产品。更换嵌入模型时，还需要有计划地迁移索引并重新校准，不能随意混用新旧向量。

TTL 有效期：过期机制只是兜底

**生存时间（TTL）**决定一个条目在过期前还能被复用多久。应根据业务能容忍旧答案多长时间来设置，而不是看缓存能存多久。

内容稳定的文档答复，与实时库存答复，对时效性的要求不同。后者可能更适合不缓存。政策若有紧急修正，即使 TTL 尚未到期，也应立即让受影响的条目失效。

把来源版本或政策版本纳入复用条件检查。版本一变，旧条目就不再匹配。RedisVL 同时提供默认 TTL 和单条目覆盖设置，但合适的有效期仍需由应用决定。参见 RedisVL 缓存 API。

按用户划定范围：身份边界必须精确

只有本来就允许共享的答案，才能放进共享缓存。租户指的是一个客户组织；如果同一组织内的员工拥有不同访问权限，仅有租户隔离还不够。

账户专属答案的适用范围，必须反映已认证用户的身份和当前权限。“我的续费日期是什么时候？”不能在所有问过同样问题的用户之间搜索答案。身份信息应来自可信的应用认证机制，不能从用户输入的一句话或嵌入向量中推断。

在选择候选条目之前先应用范围过滤，返回答案之前再验证授权。权限变更和删除操作，必须使受影响的复用路径失效。RedisVL 的 filterable_fields 和 filter_expression 提供了过滤能力，但不会自动替应用定义授权策略。参见过滤参数。

上下文与版本：让答案始终带着适用前提

应根据会影响答案的系统提示词、模型要求、输出结构、语言和来源版本，限定条目的适用范围。如果新请求要求另一种结构化响应，缓存中的一段文字就不能满足它。

在对话缓存中，同一句结尾可能指向前文中不同的对象。Microsoft 的上下文窗口说明明确解释了这种失效情况。除非能够表示并验证相关对话历史，否则先从独立问题做起。

如何落地：网关功能、Redis 方案还是专用库？

选择在哪里接入缓存，要看在哪里能够落实答案的适用边界。下面介绍的是几种实现方式，并不是对可相互替代的产品做排名。

网关功能：Kong AI Semantic Cache

Kong AI Semantic Cache 是 Kong 的 AI Gateway Enterprise 产品中的插件，将语义响应缓存放在网关层，也就是模型请求经过的入口。其文档介绍了基于嵌入向量的查找方式，以及 Redis 和 pgvector 配置。配置参考列出了 cache_ttl、message_countback 和 vectordb.threshold。

这种方式适合集中管理、重复性较高的请求流程。主要限制在于应用上下文：网关只能识别并执行那些已传入配置和请求的区分条件。用于个性化聊天之前，要先验证用户隔离和对话历史的处理方式。

还有一个容易被名称误导的细节：Kong 的插件概览指出，启用精确缓存选项，并不会关闭基于相似度的匹配。不要把这个开关当作“仅精确匹配”的安全模式。

Redis 语义缓存

Redis 是具备向量搜索能力的数据存储系统，可以让应用自行控制缓存查找与未命中后的处理流程。RedisVL 文档中的 SemanticCache 提供 check 和 store 操作，以及元数据、过滤和 TTL 控制。参见 RedisVL 文档。

如果应用已经掌握租户、政策和记录版本，并且需要在返回结果之前强制检查这些条件，这种方案就很合适。同样的架构也可以基于其他合适的向量存储实现：提示词向量负责定位候选，已存答案及其元数据决定哪些内容能够复用。

代价是这些职责都要自己承担。向量索引不会提供缓存准入规则、失效机制、授权逻辑，也不会保证答案正确。你需要实现并监控这些行为，还要维护能够支持所用向量查询的部署环境。

专用库：GPTCache

GPTCache 是用于构建语义缓存的库，将嵌入向量生成、答案存储、向量搜索和相似度评估拆成可配置的组件。其文档明确提醒，并非所有模块组合都相互兼容。

如果开发者希望在应用内部试验不同的检索与评估组件，这种方式比较合适。主要限制是集成责任：需要验证所选适配器能否配合当前的模型 SDK 和部署环境，并保留同样的适用范围与时效性检查。库提供了抽象，并不意味着一次语义命中就一定正确。

如果还在选择请求路由层，可以参考 AI 网关对比和 LiteLLM 与 OpenRouter 对比，评估更完整的选型问题。除了缓存，还需要考虑路由、凭据和可观测性。

按自己的请求构成，算清大模型缓存能省多少钱

只有省下的生成费用超过向量生成、查找、存储和运维费用，缓存才真正省钱。未命中的请求也要计入：它们承担了缓存开销，最后仍然需要调用模型。

计算时使用同一个统计周期和同一种货币。设 N 为经过精确缓存命中分流后，进入语义层且符合缓存条件的请求数；H 为被接受的语义命中数；G 为在每次生成费用相同这一简化假设下，单次请求的生成费用；E 为每个符合条件的请求所需的向量生成与查找费用；W 为每次未命中后的缓存写入费用；F 为该周期内固定的基础设施与运维费用。

计算公式如下：

• 不加语义层： N × G
• 加入语义层： (N − H) × G + N × E + (N − H) × W + F
• 净节省： H × G − N × E − (N − H) × W − F

用自己的日志代入：先用有效命中数乘以这些命中所避免的模型费用，再减去所有符合条件请求的查找费用、未命中后的写入费用，以及固定费用。生成费用应使用享受服务商提示词缓存优惠后的实际费用，而不是未命中缓存时的标价。

在上述假设下，收支平衡条件为：

H > [N × (E + W) + F] / (G + W)

如果请求的成本各不相同，就把 H × G 替换成实际命中请求所避免的生成费用总和。如果部分回答不会被存入缓存，应按实际写入次数计算。重试、评估调用和运维工作，也应计入相应的费用总额。只看命中率，无法判断复用是否回本。

延迟也要按同样的思路分析。命中请求省去了生成环节；未命中请求则在生成之前，多出向量生成和搜索环节。两条路径都要记录，包括长尾延迟。如果大部分问题都不重复，即使偶尔命中时很快，整体也可能变慢。

关于语义缓存，哪些说法被夸大了？

“含义相似”并不保证答案可以互换。 缓存只是选出了一个已有答案，并没有证明它仍然正确、仍有权提供给当前用户，或仍然符合当前情况。

最容易误导人的指标，是不断提高、却没有配套错误命中审查的命中率。放宽阈值可以让看板更好看，同时让客服承担更多返工。应把缓存答案与新请求逐一对照审查，尤其关注那些最接近接受阈值的请求。

响应缓存也不能替代检索增强生成（RAG）。RAG 会把检索到的来源资料交给模型，辅助它生成答案。缓存可以放在这个流程之前，但跳过该流程，也就跳过了一次新的来源检索。因此，要将缓存答案与来源版本绑定；如果底层事实必须保持最新，就应绕过复用。

“取消我的订单”应被视为操作，而不是可以复用的问题。之前的一条确认信息，不能证明新的操作已经获得授权或已经执行。操作执行及其当前结果，都应走正常的应用流程。

谁适合现在开始，下一步该做什么？

如果应用经常收到重复的公开问题，开发者可以从小范围开始。 选择一个稳定的问答意图，明确允许的适用范围，并保留精确缓存基线。这样可以减少重复生成调用，同时不扩大应用原本允许复用的答案范围。

运维团队应先做影子评估。 正常答案继续对外提供，同时记录缓存本来会返回哪个答案。标注真正的同义改写，以及看似接近却不适用的问题，再围绕不可接受的错误调整阈值。还要测量缓存开销、过期行为，以及已存答案本身的质量。

采购方应要求查看隔离与失效机制的证据。 功能表上勾选了“语义缓存”还不够。要问清楚：不同用户提出相同问题时，系统如何处理？政策一旦变化，系统会立即做什么？

如果大部分问题依赖持续变化的记录，或依赖尚无法清晰隔离的多轮上下文，就先等等。 如果精确重复已经覆盖了可复用流量，语义查找能带来的增益可能很少。服务商的提示词缓存仍可优化重复的输入前缀，而无需复用已经生成完毕的答案。

下周一就可以着手：选取帮助中心里的一个问答意图，收集它的不同问法，再刻意加入容易混淆的问题；定义缓存范围和失效规则，然后在影子模式下回放。只有确认会导致错误答案的案例都能被安全拒绝，才启用响应复用。

常见问题

什么是语义缓存？

语义缓存保存先前的答案，并根据含义相似度检索它们。允许复用之前，还应确认上下文匹配、权限有效，以及内容足够新。

这里讨论的三类缓存分别是什么？

在 LLM 场景中，需要区分精确响应缓存、语义响应缓存和模型服务商的提示词缓存。这种分类有助于理解本文的取舍，并不是对所有计算机缓存的通用分类。

如何实现语义缓存？

先定义允许的适用范围，将新提示词转成向量，检索候选，再应用经过校准的阈值和复用条件检查，最后返回已存答案或调用模型。启用复用之前，还应加入过期机制、主动失效机制和错误命中监控。

CDN 就是缓存吗？

不是。内容分发网络（CDN）将内容交付分散到不同地点，缓存只是它使用的一种机制。参见 Cloudflare 的 CDN 架构说明。

Cloudflare 是 CDN 还是 WAF？

Cloudflare 同时提供 CDN 服务和用于过滤应用流量的 Web 应用防火墙（WAF）。无论哪个名称，单独看都不代表具备 LLM 语义响应缓存。参见 Cloudflare 架构说明。

CDN 和 Redis 有什么区别？

CDN 通过边缘网络交付内容。Redis 是一种数据存储系统，应用可以用它实现缓存，也可以配置本文介绍的语义缓存方案。两者处于系统中的不同位置。

CloudFlare 只提供 CDN 吗？

不是。Cloudflare 的参考架构还介绍了 DNS、防火墙和其他边缘服务。

Kafka 比 Redis 更好吗？

它们解决的是不同问题。Apache Kafka 是事件流平台，不能直接替代本文所述的 Redis 语义响应缓存方案。

Netflix 使用 Redis 吗？

使用。Redis 文档介绍了 Netflix 如何利用 Redis 实现优先级队列，并附有 Netflix 关于 Timestone 的文章链接。但这个历史案例，既不能证明 Netflix 使用了 LLM 语义缓存，也不能成为在自己的应用中启用它的理由。

想了解构建可靠 AI 应用的实用经验，可以订阅邮件通讯。