LangChain 缓存实战：无缓存、普通缓存与语义缓存成本对比

1. 三档缓存方案的真实成本差距

先把结论摆在前面：同一个 LangChain 问答服务，在真实生产流量下，无缓存、普通缓存、语义缓存三档方案的成本差距可以拉到 5 到 8 倍。这个数字不是拍脑袋来的，是我在一个日均 3 万次调用的客服知识库项目里实测出来的。

很多人做 LLM 应用时，第一反应是"先把功能跑通再说"，缓存这件事往往被排到很后面。但等到账单出来、延迟报警响起来的时候，才发现问题已经积累得很严重了。我见过太多团队在 POC 阶段用无缓存方案跑得挺欢，一上生产就傻眼——每次用户问"你们几点上班"，都要完整走一遍 embedding + 向量检索 + LLM 生成，token 哗哗地烧。

这篇文章要讲的就是这三档方案到底差在哪、为什么差、怎么落地。我会把 LangChain 里的具体实现代码、Redis 的配置细节、语义缓存的阈值调参经验都摊开来讲。不管你是刚接触 LangChain 的新手，还是已经在生产环境跑着 LLM 服务的工程师，应该都能从里面找到能直接用的东西。

先给一个直观的对比，让你对三档方案的定位有个概念：

这张表里的命中率数据来自我自己的项目，不同业务场景会有浮动。但整体趋势是稳定的：语义缓存能把命中率提升到普通缓存的两倍以上，这是它最大的价值。

2. 无缓存方案：为什么它是成本黑洞

2.1 一次完整调用的 token 消耗拆解

要理解缓存的价值，得先搞清楚一次没有缓存的 LLM 调用到底花了什么。以典型的 RAG 问答为例，一次请求的链路是这样的：

1. 用户输入 query，先做 embedding，消耗 embedding token
2. 用 embedding 去向量库检索 top-k 文档
3. 把检索到的文档 + 原始 query 拼成 prompt，送给 LLM
4. LLM 生成回答，消耗 input token + output token

这里面最贵的是第 4 步。假设你检索了 5 个文档片段，每个 300 字，加上系统提示词和用户问题，input 大概在 2000 token 左右，output 按 300 token 算。用主流模型的定价，一次调用大概在 0.01 到 0.03 元之间。

单次看起来不多，但乘以日均 3 万次调用，一天就是 300 到 900 元，一个月接近 1 万到 2.7 万。而且这还没算 embedding 的费用和向量库的查询开销。

2.2 重复 query 的占比远超你的想象

关键问题在于，生产环境里的 query 重复率极高。我统计过一个客服场景的 query 分布，结果是这样的：

• 完全相同的 query 占比约 18%
• 语义等价的 query（比如"怎么退款"和"退款流程是什么"）占比约 35%
• 真正全新的 query 只占 47%

也就是说，超过一半的请求其实是在重复计算。无缓存方案把这部分全部浪费掉了。更麻烦的是，这些重复 query 往往集中在高频问题上，比如"营业时间""退款政策""联系方式"，它们恰恰是消耗 token 最多的一批。

2.3 无缓存方案的适用边界

我不是说无缓存就一无是处。在几种情况下它反而是合理选择：

• 流量极低：日调用量在几百次以内，加缓存的维护成本高于节省的费用
• query 高度发散：比如开放式创作类应用，每次输入都不一样，缓存命中率接近零
• 对实时性要求极高：缓存引入的几毫秒延迟都不能接受（这种情况很少）
• 调试阶段：开发期需要每次都看到真实模型输出，缓存会干扰判断

但只要你进入生产、流量上来了，无缓存就是一个定时炸弹。我的建议是：POC 阶段可以无缓存，但上线前必须把缓存方案设计进去，否则后期改造的代价会大得多。

3. 普通缓存：用 Redis 做精确匹配的完整落地

3.1 为什么选 Redis 而不是本地内存

普通缓存的核心逻辑很简单：把 query 作为 key，把 LLM 的回答作为 value 存起来，下次遇到同样的 query 直接返回。

选存储介质时，很多人第一反应是用 Python 的字典或者 functools.lru_cache。本地内存确实快，但有几个致命问题：

• 多进程/多实例部署时，每个实例的缓存是独立的，命中率直接除以实例数
• 服务重启缓存全丢
• 无法设置精细的过期策略
• 内存无法独立监控和扩容

Redis 解决了全部这些问题。它是独立进程，所有实例共享同一份缓存；支持 TTL 自动过期；有完善的内存监控；还能做持久化。代价就是一次网络往返，但在内网环境下通常只有 1-3ms，完全可以接受。

提示：如果你的服务是单实例且流量不大，本地内存缓存也能用。但只要涉及水平扩展，Redis 几乎是唯一选择。

3.2 LangChain 里接入 Redis 缓存的两种方式

LangChain 其实内置了缓存抽象，最省事的做法是用set_llm_cache：

from langchain.globals import set_llm_cache from langchain_community.cache import RedisCache import redis redis_client = redis.Redis( host="127.0.0.1", port=6379, db=0, password="your_password", decode_responses=False ) set_llm_cache(RedisCache(redis_client))

设置完之后，所有通过 LangChain LLM 接口发起的调用都会自动走缓存。key 是 prompt 的哈希，value 是模型返回结果。这是最省心的方式，适合快速接入。

但内置缓存有个局限：它只缓存 LLM 的最终输出，不缓存 embedding 和检索结果。而且 key 的生成方式你控制不了，没法做自定义的归一化处理。

所以我更推荐第二种方式——自己封装一层缓存逻辑：

import hashlib import json from typing import Optional class QueryCache: def __init__(self, redis_client, ttl=3600, prefix="qa:"): self.redis = redis_client self.ttl = ttl self.prefix = prefix def _make_key(self, query: str) -> str: normalized = query.strip().lower() digest = hashlib.sha256(normalized.encode("utf-8")).hexdigest() return f"{self.prefix}{digest}" def get(self, query: str) -> Optional[str]: key = self._make_key(query) value = self.redis.get(key) if value: return value.decode("utf-8") return None def set(self, query: str, answer: str): key = self._make_key(query) self.redis.setex(key, self.ttl, answer)

自己封装的好处是：key 的归一化规则你说了算（比如统一转小写、去掉首尾空格、去掉标点），TTL 可以按业务调整，还能在 get/set 里加埋点统计命中率。

3.3 key 归一化：普通缓存命中率的关键

普通缓存的命中率完全取决于 key 的归一化做得好不好。我踩过的坑是：一开始直接用原始 query 做 key，结果"退款怎么办"和"退款怎么办？"（多个问号）被当成两个不同的 key，命中率惨不忍睹。

后来我加了一套归一化规则，命中率从 12% 提到了 28%：

import re def normalize_query(query: str) -> str: q = query.strip().lower() q = re.sub(r"[，。！？、；：""''（）【】]", "", q) q = re.sub(r"\s+", " ", q) return q

规则不复杂，但效果立竿见影。核心思路就是把那些不影响语义的差异全部抹掉：大小写、标点、多余空格、全角半角。

注意：归一化要适度。如果把"不要退款"和"要退款"归一化成同一个 key，那就出大事了。否定词、程度词、关键实体绝对不能动。

3.4 TTL 设置与缓存失效策略

TTL 设多长是个需要权衡的问题。设太短，缓存频繁失效，命中率上不去；设太长，知识库更新后用户还在拿到旧答案。

我的经验是按内容类型分档：

除了 TTL，还要有主动失效机制。当知识库更新时，应该能批量清除相关缓存。简单做法是给 key 加业务前缀，比如faq:、policy:，更新时用SCAN匹配前缀删除。

提示：生产环境慎用KEYS *，它会阻塞 Redis。用SCAN游标分批遍历，虽然慢一点但不会拖垮服务。

4. 语义缓存：让"意思一样"的 query 也能命中

4.1 普通缓存的天花板在哪

普通缓存做到极致，命中率也就 30% 左右。因为用户表达同一个意思的方式太多了：

• "怎么退款"
• "退款流程"
• "我要退钱"
• "买错了能退吗"
• "申请退款的方法"

这五句话语义完全一致，但字符串没有一个相同。普通缓存对它们全部 miss，每一次都要走完整的 LLM 链路。这就是普通缓存的天花板——它只能处理字面重复，处理不了语义重复。

语义缓存要解决的就是这个问题：把 query 转成向量，在向量空间里找相似的已缓存 query，相似度超过阈值就认为命中。

4.2 语义缓存的工作机制拆解

语义缓存的完整流程是这样的：

1. 用户 query 进来，先用 embedding 模型转成向量
2. 拿这个向量去缓存向量库里做相似度检索
3. 如果找到相似度超过阈值的缓存项，直接返回对应的答案
4. 如果没找到，走正常 LLM 链路，然后把 query 向量和答案一起存进缓存

这里的关键是第 2 步的相似度检索。有两种实现路径：

路径一：用向量数据库。把缓存的 query 向量存进 FAISS、Milvus 或 Redis 的向量检索功能里，每次查询做 ANN 检索。优点是检索快、支持大规模；缺点是多了一套组件要维护。

路径二：用 Redis + 向量相似度计算。Redis 从 2.0 版本开始支持向量检索（RedisSearch 模块），可以在同一个 Redis 实例里同时做普通缓存和语义缓存。这是我最推荐的方案，组件少、运维简单。

4.3 用 Redis 向量检索实现语义缓存

先看核心实现：

import numpy as np from redis.commands.search.field import VectorField, TextField from redis.commands.search.indexDefinition import IndexDefinition, IndexType from redis.commands.search.query import Query class SemanticCache: def __init__(self, redis_client, embedder, threshold=0.92, ttl=3600): self.redis = redis_client self.embedder = embedder self.threshold = threshold self.ttl = ttl self.index_name = "semantic_cache_idx" def _ensure_index(self, dim: int): try: self.redis.ft(self.index_name).info() except Exception: schema = ( TextField("answer"), VectorField( "vector", "FLAT", { "TYPE": "FLOAT32", "DIM": dim, "DISTANCE_METRIC": "COSINE" } ) ) definition = IndexDefinition( prefix=["sc:"], index_type=IndexType.HASH ) self.redis.ft(self.index_name).create_index( schema, definition=definition ) def get(self, query: str): vec = self.embedder.embed_query(query) vec_bytes = np.array(vec, dtype=np.float32).tobytes() q = ( Query(f"*=>[KNN 1 @vector $vec AS score]") .sort_by("score") .return_fields("answer", "score") .dialect(2) ) results = self.redis.ft(self.index_name).search( q, {"vec": vec_bytes} ) if results.docs: doc = results.docs[0] similarity = 1 - float(doc.score) if similarity >= self.threshold: return doc.answer return None def set(self, query: str, answer: str): vec = self.embedder.embed_query(query) vec_bytes = np.array(vec, dtype=np.float32).tobytes() key = f"sc:{hash(query)}" self.redis.hset(key, mapping={ "query": query, "answer": answer, "vector": vec_bytes }) self.redis.expire(key, self.ttl)

这段代码里几个关键点值得展开说：

距离度量选 COSINE。语义相似度用余弦距离最合适，因为它只看向量方向，不受长度影响。欧氏距离在文本向量上表现通常不如余弦。

索引类型选 FLAT。FLAT 是暴力检索，精度 100%，适合缓存规模在几万到几十万条的场景。如果缓存量级上百万，可以换成 HNSW，牺牲一点精度换速度。

KNN 的 K 设成 1。我们只需要最相似的那一条，K 设大了反而增加计算量。

4.4 阈值调参：0.85 还是 0.95

阈值是语义缓存里最需要仔细调的参数，没有之一。它直接决定了误命中率和命中率的平衡。

• 阈值太高（比如 0.98）：只有几乎一模一样的 query 才命中，退化成普通缓存
• 阈值太低（比如 0.80）：语义不相关的 query 也可能命中，返回错误答案

我实测下来，不同 embedding 模型的最佳阈值不一样：

调阈值的方法论是：准备一批标注好的 query 对（语义相同 vs 语义不同），跑一遍看不同阈值下的准确率和召回率，选 F1 最高的那个点。别凭感觉设，一定要用数据说话。

注意：阈值不是设一次就完事了。业务变化、embedding 模型升级、用户群体变化，都可能需要重新调。建议把阈值做成配置项，方便随时调整。

4.5 误命中的代价与兜底设计

语义缓存最大的风险是误命中——把不相关的问题匹配到了错误的答案。这种错误比缓存 miss 严重得多，因为用户会直接看到驴唇不对马嘴的回答。

我踩过一次坑：阈值设成了 0.85，结果"如何注销账号"匹配到了"如何注册账号"的答案，用户直接投诉了。这两个 query 的向量相似度确实很高，但语义完全相反。

兜底设计有几个层次：

第一层：阈值留足余量。宁可少命中，不可错命中。我现在的项目阈值都设在 0.90 以上。

第二层：加关键词校验。命中后，检查 query 里的关键实体是否一致。比如 query 里有"注销"，缓存答案对应的 query 里必须有"注销"。

第三层：否定词检测。如果 query 里出现否定词（不、别、取消、注销），强制走完整链路，不走缓存。

第四层：答案置信度标注。缓存返回的答案可以带一个标记，前端展示时如果置信度偏低，可以加一句"如需更准确的信息请咨询人工"。

5. 三档方案的实测数据与选型建议

5.1 实测环境与数据

我在一个客服知识库项目里做了完整的 A/B 测试，环境如下：

• 日均调用量：30000 次
• 知识库规模：约 2000 个文档片段
• Embedding 模型：bge-large-zh
• LLM：主流中文大模型
• Redis：单实例，8GB 内存

三档方案跑了一周，数据如下：

语义缓存把成本砍了一半多，延迟也降了近一半。代价是 3 起误命中投诉，后来通过提高阈值到 0.93 解决了。

5.2 什么场景该用哪一档

选型没有标准答案，要看你的具体情况：

选无缓存：日调用量低于 1000 次，或者 query 极度发散（如创作类应用），或者还在 POC 阶段。

选普通缓存：query 重复率高但表达方式相对固定（如内部工具、固定表单查询），团队没有向量检索经验，想快速上线。

选语义缓存：面向 C 端用户、query 表达多样、对成本敏感、有一定技术储备。这是大多数生产级 LLM 应用的最终形态。

我的建议是分阶段演进：先上普通缓存把架子搭起来，跑一段时间收集 query 数据，等数据够了再上语义缓存。不要一上来就搞语义缓存，调参和运维的复杂度会让你吃不消。

5.3 混合方案：两档缓存叠加

实际生产里，我最后用的是混合方案：普通缓存和语义缓存叠加。

请求进来先查普通缓存（精确匹配，1ms 内返回），miss 了再查语义缓存（相似匹配，10ms 内返回），再 miss 才走 LLM。这样既拿到了普通缓存的极低延迟，又拿到了语义缓存的高命中率。

def get_answer(query: str): answer = exact_cache.get(query) if answer: return answer, "exact" answer = semantic_cache.get(query) if answer: exact_cache.set(query, answer) return answer, "semantic" answer = llm_chain.invoke(query) exact_cache.set(query, answer) semantic_cache.set(query, answer) return answer, "llm"

注意最后一步：语义缓存命中后，会把结果回填到普通缓存里。这样下次同样的 query 就能走最快的路径。这个回填策略能把整体平均延迟再压低 20% 左右。

6. 生产环境踩过的坑与调优经验

6.1 Redis 内存增长失控

语义缓存比普通缓存吃内存得多，因为每个缓存项都要存一个向量。bge-large-zh 是 1024 维，float32 存储就是 4KB，加上 query 和 answer 文本，一条缓存轻松超过 5KB。

我一开始没设内存上限，跑了一周 Redis 内存从 2GB 涨到 7GB。后来做了三件事：

• 设置maxmemory和maxmemory-policy allkeys-lru，让 Redis 自动淘汰旧数据
• 缩短 TTL，语义缓存从 24 小时降到 6 小时
• 定期清理低命中率的缓存项

提示：allkeys-lru会淘汰最久未使用的 key，适合缓存场景。别用noeviction，内存满了会直接报错。

6.2 embedding 调用本身也是成本

语义缓存需要给每个 query 做 embedding，这本身也要花钱、花时间。如果 embedding 比 LLM 还慢，那就本末倒置了。

优化思路有两个：一是用本地部署的轻量 embedding 模型（如 bge-small），避免网络往返；二是对 embedding 结果也做一层缓存，相同 query 不重复计算。

我实测下来，本地 bge-small 做 embedding 只要 5-8ms，比调 API 快得多，而且没有额外费用。对于语义缓存这种高频调用场景，本地模型是更优解。

6.3 缓存穿透与雪崩

这两个是缓存领域的经典问题，LLM 场景同样会遇到。

缓存穿透：恶意用户用大量不存在的 query 刷接口，每次都 miss 缓存直击 LLM。防护方法是加布隆过滤器或者对空结果也做短 TTL 缓存。

缓存雪崩：大量缓存同时过期，请求瞬间全部打到 LLM。防护方法是给 TTL 加随机抖动：

import random ttl = base_ttl + random.randint(-300, 300)

这一个小改动能有效打散过期时间，避免集中失效。

6.4 监控指标不能少

上线缓存后，必须监控这几个指标，否则出了问题你都不知道：

• 命中率：分普通缓存和语义缓存分别统计，低于预期要排查
• 误命中率：通过用户反馈或抽样人工评估
• Redis 内存使用率：接近上限要扩容或调策略
• 平均延迟：缓存命中 vs 未命中的延迟对比
• embedding 耗时：语义缓存的额外开销

我习惯在缓存 get/set 的地方埋点，用 Prometheus 收集，Grafana 展示。命中率曲线一掉，立刻能发现。

6.5 缓存预热

服务刚上线或重启后，缓存是空的，所有请求都会打到 LLM。这时候如果流量大，很容易把 LLM 配额打满。

解决办法是缓存预热：把历史高频 query 提前跑一遍，把结果灌进缓存。我一般从日志里捞出 top 500 的 query，写个脚本批量预热。这样服务一上线就有 30% 左右的命中率打底。

def warmup(queries, cache, llm_chain): for q in queries: if cache.get(q): continue answer = llm_chain.invoke(q) cache.set(q, answer)

预热脚本要注意限流，别把 LLM 的 QPS 配额打爆。加个 sleep 或者用信号量控制并发。

7. 几个容易被忽略的细节

7.1 多轮对话场景的缓存处理

前面讲的都是单轮问答的缓存。多轮对话要复杂一些，因为同一个 query 在不同上下文里答案可能不同。

我的处理方式是：把最近 N 轮对话的摘要拼进 query 再做缓存 key。这样"那它多少钱"这种依赖上下文的 query，在不同上下文里会生成不同的 key，避免误命中。

但这样会降低命中率，因为上下文稍有不同 key 就变了。折中方案是只把关键实体（如产品名）拼进去，而不是完整上下文。

7.2 流式输出的缓存

如果 LLM 是流式输出（streaming），缓存要特殊处理。不能缓存流式的 chunk，要等完整答案生成完再存。

实现上，可以在流式输出的同时把 chunk 拼起来，结束后一次性写入缓存。下次命中缓存时，直接把完整答案按 chunk 切分模拟流式效果，用户体验一致。

7.3 敏感信息的缓存隔离

如果 query 里可能包含用户隐私信息（手机号、身份证号），缓存时要特别小心。不同用户的敏感 query 绝对不能互相命中。

我的做法是对包含敏感信息的 query 打标记，这类 query 要么不缓存，要么按用户 ID 隔离缓存空间。宁可牺牲命中率，也不能泄露隐私。

7.4 缓存版本管理

当知识库更新、prompt 调整、模型升级时，旧缓存可能就不适用了。这时候需要能快速失效旧缓存。

我在 key 里加了一个版本号前缀，比如v2:qa:xxx。需要全量失效时，直接把版本号升到 v3，旧缓存自然就不再被访问，等 TTL 到期自动清理。这比手动删除安全得多。

8. 从零搭建的完整步骤清单

如果你要从头搭一套带语义缓存的 LangChain 服务，按这个顺序来：

1. 装 Redis。Linux 下用包管理器，macOS 用 Homebrew，Windows 建议用 WSL2 或 Docker。装完确认redis-cli ping返回 PONG。

2. 装 RedisSearch 模块。语义缓存依赖向量检索，需要 Redis Stack 或者单独装 RedisSearch。用 Docker 的话直接拉redis/redis-stack镜像最省事。

3. 选 embedding 模型。中文场景推荐 bge 系列，英文推荐 text-embedding-3 系列。优先考虑本地部署，省调用成本。

4. 搭 LangChain 链路。先把无缓存的 RAG 链路跑通，确认能正常问答。

5. 接入普通缓存。用前面讲的 QueryCache 类，先跑一周收集命中率数据。

6. 接入语义缓存。建向量索引，实现 SemanticCache 类，和普通缓存叠加使用。

7. 调阈值。准备标注数据，跑不同阈值下的准确率召回率，选最优点。

8. 加监控。埋点统计命中率、延迟、内存，接 Prometheus + Grafana。

9. 做预热。从日志捞高频 query，批量灌缓存。

10. 压测。模拟真实流量，观察缓存表现和 Redis 负载，确认没有瓶颈。

这套流程我走过好几遍，每一步都有坑，但整体是可控的。最花时间的是第 7 步调阈值，需要反复试。其他步骤基本一两天能搞定。

最后分享一个我自己的体会：缓存这件事，投入产出比极高。花两三天搭一套语义缓存，能省下一半以上的 LLM 成本，延迟还降了。这笔账怎么算都划算。真正难的不是技术实现，而是愿不愿意在生产环境里认真对待成本这件事。我见过太多团队把 LLM 当黑盒用，账单来了才后悔。早点把缓存设计进去，后面会轻松很多。