2024 年我给一个 AI 客服系统加缓存——这个客服每天要处理上万条用户咨询,每一条都调一次大模型,账单看着肉疼。我想,加个缓存吧:同样的问题,答过一次就把答案存下来,下次直接返回,不用再调模型。第一版我做得很顺手:用一个字典(实际上是 Redis),把用户的问题字符串当 key,大模型的回答当 value;来一个问题,先查字典,命中就直接返回,没命中才调模型、然后把这一对存进去。本地我测了测,反复问"怎么退款",第二次开始就秒回了,命中率看着很漂亮,我心里很笃定:缓存嘛,就是 key 一样返回 value、key 不一样就算一次,这套我给数据库查询加过无数次了,这 LLM 缓存稳了。可等它一上线,一串问题冒了出来。第一种最先把我打懵:线上的缓存命中率几乎是零——明明很多用户问的是同一件事,缓存却几乎从不命中,账单一分钱没省下来。第二种最难缠:我把缓存改成按"语义"匹配,命中率是上去了,可开始出现答非所问——用户问"北京天气怎么样",系统返回了一段"上海天气"的缓存答案;用户问"怎么取消会员",返回的却是"怎么开通会员"的流程。第三种最头疼:有些回答带时效性,比如"这个月有什么活动",我缓存了之后,活动早结束了,缓存还在自信地返回那个过期的答案。第四种最莫名其妙:用户 A 问"我的订单到哪了",答案被缓存;用户 B 一字不差也问"我的订单到哪了",直接命中了 A 的缓存——B 看到了 A 的私人物流信息。我盯着这一连串问题想了很久,才彻底想明白:第一版错在一个根本的认知上。我以为给大模型调用加缓存,和给数据库查询加缓存是同一回事——把请求(用户的问题)当 key,把响应(模型的回答)当 value,下次来一个请求,key 完全一样就返回缓存的 value,key 不一样就重新调一次模型;缓存的命中与否,就是一次简单的 key 字符串相等判断。可这个认知是错的。数据库查询的 key 是结构化、有限、可枚举的(一条 SQL、一个 ID),同一个查询天然就是同一个字符串;而 LLM 缓存的 key 是自然语言,自然语言的根本特点是"同一个意思有无数种说法"——"怎么退款""退款怎么弄""我想申请退款""退货流程是啥",指的是同一件事,可字符串两两不同。用字符串相等去判断 LLM 缓存命中,等于要求用户一字不差地重复别人问过的话,这在自然语言里几乎不可能发生,所以命中率必然趋零。要让 LLM 缓存真正有用,匹配的依据必须从"字符串是否相同"换成"语义是否相同"——这就是语义缓存:把问题转成向量,用向量的相似度来判断两个问题是不是在问同一件事。但语义相似度是一个连续的、模糊的量,"多相似才算命中"是一个危险的阈值:设严了,命中率上不去;设松了,就会把"语义相近但其实答案完全不同"的问题误判为命中,返回一个错误答案——而一个自信地给出错误答案的缓存,比没有缓存更糟。所以语义缓存,根上不是"存一下答案"这一个动作,而是一整套工程:要用语义而非字符串匹配、要谨慎地校准相似度阈值、要给命中加二次校验防误命中、要分清什么内容能缓存什么不能、还要监控误命中率。本文从头梳理:为什么精确匹配对 LLM 几乎无效,语义缓存怎么做,相似度阈值这个旋钮多危险,误命中怎么防,以及一些把语义缓存做扎实要避开的工程坑。
问题背景
先把语义缓存这件事说清楚。普通缓存的逻辑是"key 字符串相等就命中",它对数据库查询、对接口请求都很有效,因为这些场景的 key 是有限的、确定的。而 LLM 的输入是用户用自然语言提的问题,自然语言里"意思相同"和"字符串相同"是两码事。语义缓存(semantic cache)就是为这个场景设计的:它不比字符串,而是先把问题用 embedding 模型转成一个向量,再用向量之间的相似度来判断"这两个问题是不是在问同一件事";相似度足够高,就认为命中,复用之前的答案。
错误认知是:LLM 缓存就是普通的 key-value 缓存,字符串相等即命中。真相是:LLM 的 key 是自然语言,精确匹配几乎永不命中;必须用语义相似度匹配,而相似度是个连续模糊量,阈值设松了会误命中、给出错误答案。把这一点摊开,第一版的几类问题就都能解释了:
- 命中率几乎为零:同一件事有无数种问法,精确字符串匹配几乎永远命不中。
- 答非所问:改用语义匹配后阈值偏松,把"语义相近但答案不同"的问题误判成了命中。
- 返回过期答案:把带时效性的回答缓存太久,内容早已失效,缓存还在返回。
- 私人答案串号:个性化问题用了全局缓存 key,A 的私人答案被 B 命中。
所以让 LLM 缓存真正有用又安全,核心不是"存一下答案",而是一整套工程:语义匹配、校准阈值、二次校验、区分可缓存性、监控误命中。下面六节,就从第一版"字符串相等即命中"的想当然讲起。
一、为什么精确匹配缓存对 LLM 几乎无效
第一版的缓存,就是一个最朴素的 key-value:问题字符串当 key,答案当 value。
# 反面教材:把问题字符串当 key 的精确匹配缓存
cache = {} # 实际是 Redis,这里用 dict 示意
def ask_v1(question):
# 直接拿问题字符串当 key 查缓存
if question in cache:
return cache[question] # 命中,秒回
# 没命中,才真正调用大模型
answer = call_llm(question)
cache[question] = answer # 把这一对存进缓存
return answer
# 本地我反复问一模一样的"怎么退款",从第二次起都命中,
# 看着很美。可线上真实用户问的是 ——
# "怎么退款" "退款怎么弄" "我想申请退款" "退货流程是啥"
# 四句话同一个意思,四个完全不同的字符串,
# 精确匹配下,它们互相之间一次都命不中。问题就藏在这里:本地测试时,是我自己在反复输入完全一样的字符串,所以命中率很高——但这是一个假象。线上的真实用户,每个人有每个人的说话习惯,同一个意图会被表达成千百种不同的字符串。精确匹配缓存要命中,前提是"两个用户碰巧一字不差地问了同一句话",而这个概率,在真实流量里低到可以忽略。于是缓存表越堆越大、命中率却始终贴着零——它存了一堆永远不会被第二个人精确问到的问题。
这一节要建立的认知是:缓存的 key,本质上是一个"用来判断两次请求是否等价"的指纹——而精确字符串匹配,只在 key 的取值是"离散、有限、规范"的时候才是一个好指纹;自然语言恰恰相反,它是"连续、无限、自由"的,用字符串当指纹,等价的请求会算出千百个不同的指纹。第一版的错,是把"给数据库查询加缓存"的成功经验,不加思索地搬到了 LLM 上。数据库查询的 key 为什么用字符串匹配就行?因为一条 SQL、一个用户 ID,它的形态是被代码规范死的——同一个查询,程序生成出来的字符串就是同一个,字符串相等和"语义相等"在这里是重合的。但用户的自然语言提问,没有任何东西去规范它:同一个意图,有的人啰嗦有的人简洁,有的人用"退款"有的人用"退货",有的人带语气词有的人不带。这意味着"字符串相等"这个判据,在自然语言上,远远严于"语义相等"——它把无数本该算命中的等价请求,判成了不命中。所以 LLM 缓存的第一个根本问题,不是"缓存怎么存",而是"拿什么当指纹"。字符串这个指纹在这里失效了,你需要一个能识别"意思相同"的指纹——那就是下一节的语义向量。
二、语义缓存:用 embedding 相似度做匹配
既然字符串不行,就换一个能代表"意思"的指纹。这个指纹就是 embedding 向量:用一个 embedding 模型,把一句话转成一个定长的数字向量,它的特性是——语义相近的句子,转出来的向量在空间里也彼此靠近。
# 语义缓存第一步:把问题转成向量(embedding)
def embed(text):
# 调一个 embedding 模型,把一句话转成一个定长向量
# 关键特性:语义相近的句子,它们的向量在空间里也相近
return embedding_model.encode(text)
# 缓存的结构,从"字符串 -> 答案"变成
# "向量 + 原问题 + 答案"的一条条记录
cache_entries = [] # 每条:{"vec":..., "question":..., "answer":...}
def store(question, answer):
cache_entries.append({
"vec": embed(question),
"question": question,
"answer": answer,
})有了向量,"查缓存"这个动作就从"找字符串完全相等的那条",变成了"找向量最接近的那条"。向量接近程度,常用余弦相似度来衡量。
# 语义缓存第二步:用向量相似度查缓存,而不是字符串相等
import numpy as np
def cosine(a, b):
# 余弦相似度:1 表示方向完全一致,越接近 0 越无关
return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
def ask_v2(question, threshold=0.92):
q_vec = embed(question)
# 在所有缓存记录里,找语义最接近的那一条
best, best_sim = None, -1.0
for e in cache_entries:
sim = cosine(q_vec, e["vec"])
if sim > best_sim:
best, best_sim = e, sim
# 最接近的那条,相似度高过阈值才算命中
if best and best_sim >= threshold:
return best["answer"]
answer = call_llm(question)
store(question, answer)
return answer
# 生产里这个"找最接近"的步骤,要用向量数据库的近似检索来做,
# 几万条缓存逐条算余弦不现实 —— 这里只是示意原理。这一节的认知是:语义缓存把缓存的命中判断,从一个"非黑即白的相等判断",换成了一个"有程度的相似判断"——这个转变让命中率有了起色,但它也引入了一个第一版根本不存在的新难题:相等是确定的,而"相似"是需要你划一条线去裁定的。精确匹配缓存有一个隐性的好处,第一版从没意识到:它的命中判断是绝对可靠的——字符串相等,就一定是同一个请求,绝不会判错,它唯一的毛病是"太严了,命中率低"。语义缓存把这个判断换成了相似度,命中率的天花板一下打开了,但代价是:命中判断从此不再绝对可靠。两个向量的余弦相似度是 0.93 还是 0.91,这中间没有一条天然的、上帝给定的分界线告诉你"这边算命中、那边不算"。这条线得你自己来划。划这条线,就是引入了一个全新的、第一版从未面对过的风险点:线划错了,缓存就会判错——要么把该命中的判成没命中(损失命中率),要么把不该命中的判成命中(返回错误答案)。所以语义缓存不是"精确缓存的免费升级版",它是一个用"判断可能出错"换来"命中率可能很高"的交易。而这笔交易划不划算,几乎完全取决于那条线划得好不好——那条线,就是下一节的相似度阈值。
三、相似度阈值:语义缓存最危险的一个旋钮
相似度阈值,就是上一节说的那条线:相似度高过它算命中,低于它算不命中。这个旋钮极其危险,因为它两端的后果是不对称的。往严了调(比如 0.98),命中率会很低,你只是少省了点钱;往松了调(比如 0.85),你会开始误命中——把意思不同的问题判成命中,返回错误答案。所以阈值绝不能拍脑袋定,要用一个人工标注的评测集去测。
# 阈值校准:先准备一个人工标注的评测集
# 一批 (问题A, 问题B, 这两个该不该命中同一缓存) 的人工标注
eval_pairs = [
("怎么退款", "退款流程是什么", True), # 该命中,同一件事
("怎么退款", "我想申请退款", True), # 该命中
("怎么开通会员", "怎么取消会员", False), # 不该命中!意思相反
("北京天气怎么样", "上海天气怎么样", False), # 不该命中,城市不同
("订单怎么取消", "我的订单到哪了", False), # 不该命中,意图不同
]
# 这个评测集的价值,在于它把"误命中"的几种典型陷阱
# (一字之差意思相反、关键实体不同、意图不同)都摆了出来 ——
# 阈值能不能挡住这些,一测便知。有了评测集,就扫一遍候选阈值,看每个阈值各自的命中、误命中、漏命中情况。
# 阈值校准:扫一遍候选阈值,挑误命中最少的那个
def evaluate(threshold):
hit_ok = hit_wrong = miss = 0
for qa, qb, should_hit in eval_pairs:
sim = cosine(embed(qa), embed(qb))
hit = sim >= threshold
if hit and should_hit: hit_ok += 1
if hit and not should_hit: hit_wrong += 1 # 误命中,最该警惕
if not hit and should_hit: miss += 1 # 漏命中,只是浪费
return hit_ok, hit_wrong, miss
for th in [0.85, 0.90, 0.92, 0.95, 0.98]:
print(th, evaluate(th))
# 选阈值的原则不是"命中率最高",而是"误命中为零的前提下,
# 命中率尽量高" —— 漏命中只是少省一点钱,误命中是给错答案。这一节的认知是:相似度阈值之所以危险,不在于它难调,而在于它两端的代价是严重不对称的——调严一点,你损失的是"钱"(命中率低、多花了 API 费用);调松一点,你损失的是"对"(误命中、给用户错误答案)。把这两种代价当成可以互相交换的同类,是最致命的错误。很多人调阈值,心里那杆秤是"命中率",于是看到命中率低,本能反应就是把阈值往下调,调到命中率好看为止。这个本能,背后藏着一个错误的假设:漏命中和误命中是同一种"失误",都是"缓存没用对",所以可以为了减少漏命中而容忍多一点误命中。但这两者根本不是一回事。漏命中,后果是这一次没省到钱,系统行为完全正确,用户拿到的是一个真实、新鲜的答案——它只是"不够省"。误命中,后果是用户拿到了一个为别的问题准备的、错误的答案,系统在一本正经地胡说——它是"错了"。"不够省"和"错了"不是程度差异,是性质差异。一个会偶尔答错的客服,比一个偶尔多花点钱的客服,糟糕得多。所以校准阈值的正确心态,是"宁严勿松":先把误命中摁到零(在评测集上),在这个前提下,再去尽量争取命中率。命中率是可以慢慢优化的次要目标,不误命中是不可退让的底线。摆正了这两者的关系,你才不会在调旋钮时,亲手把自己的缓存调成一个错误答案的发生器。而即便阈值校准得再好,误命中也无法在阈值这一层被彻底消灭——那需要下一节专门的防线。
四、误命中:为什么"语义相近"不等于"答案能复用"
阈值能减少误命中,但消灭不了。因为有一类问题,它们语义上确实高度相似,embedding 向量也确实很接近,可它们的答案完全不能互相复用——"怎么开通会员"和"怎么取消会员",只差一个词,向量却挨得很近。光靠相似度阈值,挡不住这种。所以命中之后,还得加一道二次校验:确认这两个问题真的能共用一个答案。
# 误命中防线一:命中后,再做一道"答案能不能复用"的二次校验
def ask_v3(question, threshold=0.92):
q_vec = embed(question)
best, best_sim = find_nearest(q_vec)
if best and best_sim >= threshold:
# 别直接信!相似度高,只说明"问法像",
# 再确认一次:缓存里那个问题和现在这个,是不是真同一件事
if is_reusable(question, best["question"]):
return best["answer"]
answer = call_llm(question)
store(question, answer)
return answer
def is_reusable(q_new, q_cached):
# 用一次很便宜的小模型调用,只问一个是非题
verdict = call_small_llm(
f"这两个问题是否在问完全相同的事、能共用同一个答案?"
f"只回 yes 或 no。\nA: {q_new}\nB: {q_cached}")
return verdict.strip().lower() == "yes"
# 这道校验会多花一点点钱(小模型很便宜),
# 但它挡掉的是"自信地给出错误答案"—— 这笔账非常划算。除了让小模型判断,还有一道更轻、更硬的防线:对那些"差一个就意思全变"的关键成分——城市、数字、否定词——做精确比对。
# 误命中防线二:对"关键实体"和"否定词"做硬性比对
import re
def entity_guard(q_new, q_cached):
# 城市、否定词这类"差一个就意思全变"的成分,
# 必须在两个问题里完全一致,否则直接判定不可复用
def key_tokens(text):
cities = set(re.findall(r"北京|上海|广州|深圳|杭州", text))
negation = set(re.findall(r"取消|关闭|删除|退订|不要", text))
return cities, negation
c1, n1 = key_tokens(q_new)
c2, n2 = key_tokens(q_cached)
# 实体集合或否定词集合对不上,就是不可复用
return c1 == c2 and n1 == n2
# "北京天气" 对 "上海天气":城市集合不同,直接拦下。
# "怎么开通会员" 对 "怎么取消会员":否定词集合不同,直接拦下。
# embedding 相似度对这种"一词之差"经常失灵,要靠硬规则补刀。这一节的认知是:embedding 相似度衡量的是"两句话像不像",而缓存真正需要知道的是"两句话的答案能不能复用"——这是两个不同的问题,而第一版(以及只靠阈值的第二版)默认它们是同一个问题。"像不像"和"答案能不能复用",在大多数情况下是一致的,这正是语义缓存能成立的基础。但它们会在一个关键的地方分叉:当两句话的差异,集中在一个"小、但决定性"的成分上。"开通"和"取消",在 embedding 看来,是两个都出现在"会员操作"语境里的、高度相关的词,所以"怎么开通会员"和"怎么取消会员"这两句话的向量挨得非常近——从"像不像"看,它们极像。可从"答案能不能复用"看,它们的答案南辕北辙,绝不能复用。embedding 的这个特性不是 bug,它就是这么工作的:它捕捉的是整体语义氛围,而对"否定""反义""实体替换"这种局部的、决定性的翻转,常常不够敏感。所以你不能把"相似度高"直接当成"可以复用"的结论,中间必须插一道专门回答"能不能复用"的校验——用小模型问一个是非题,或者对城市、否定词这类敏感成分做硬比对。理解了"相似"和"可复用"是两个问题,你才会主动去补上这道第一版结构里根本没有的防线。而就算两个问题确实可复用,还有一类东西压根就不该被缓存——那是下一节的事。
五、缓存什么、不缓存什么:时效性与个性化
前面解决的都是"怎么匹配"。但还有一个更前置的问题:这个答案,到底该不该被缓存?第一版默认"所有答案都缓存",这直接导致了第三、第四种问题。有两类内容是特殊的。第一类是带时效性的:活动、价格、库存、天气——这种答案今天对、明天就可能错,要么不缓存,要么给一个很短的过期时间(TTL)。
# 不是所有回答都该长期缓存:带时效性的内容,要短 TTL
import time
# 给每条缓存记录加一个"过期时间"
def store_with_ttl(question, answer, ttl_seconds):
cache_entries.append({
"vec": embed(question),
"question": question,
"answer": answer,
"expire_at": time.time() + ttl_seconds,
})
def classify_ttl(question):
# 按问题的时效性,给不同的 TTL
if any(w in question for w in ["活动", "价格", "库存", "天气", "现在"]):
return 300 # 时效性强:5 分钟就过期
if any(w in question for w in ["怎么", "如何", "流程", "是什么"]):
return 86400 * 7 # 操作指引类:内容稳定,可缓存一周
return 3600 # 其余:保守地缓存 1 小时
# 第一版的问题三:把"这个月有什么活动"这种答案缓存了很久,
# 活动早结束了,缓存还在自信地返回那个过期答案。第二类是个性化的:答案因人而异。"我的订单到哪了""我的余额是多少"——这种答案绑定具体用户,绝不能全局共享。缓存的 key 必须带上"作用域"。
# 缓存 key 必须带"作用域":别让 A 用户的私人答案命中给 B 用户
def cache_scope(question, user_id):
# 判断这个问题的答案,是"对所有人都一样"还是"因人而异"
personal_markers = ["我的", "本人", "账号", "我的订单", "我的余额"]
if any(m in question for m in personal_markers):
# 个性化问题:作用域绑定到具体用户
return f"user:{user_id}"
# 通用问题(怎么退款、流程是什么):全局共享缓存
return "global"
# 查缓存、存缓存时,都要先按 scope 分桶 ——
# scope 为 global 的桶,所有用户共享;
# scope 为 user:123 的桶,只有用户 123 自己能命中。
# 第一版的问题四:"我的订单到哪了"被当成通用问题缓存,
# A 问出来的答案(带着 A 的物流信息),B 一问同样的话就命中了 ——
# 这不只是缓存错误,这是数据泄露。这一节的认知是:缓存的前提,是"这个答案在被复用的那个时刻、对那个复用它的人,依然成立"——第一版默认所有答案都满足这个前提,而事实上,答案的有效性有两个维度会失效:时间维度(答案会过期)和对象维度(答案只对特定的人成立)。缓存这个机制,骨子里是在做一个假设:一个答案,被算出来之后,它的正确性是恒定的——什么时候拿出来用、给谁用,它都还是对的。对"怎么退款"这种问题,这个假设成立:退款流程不会因为时间流逝而改变,也不会因人而异。但第一版犯的错,是把这个对部分问题成立的假设,当成了对所有问题都成立。一个答案的正确性,其实挂着两个隐含的条件。一个是时间条件:"这个月的活动"这个答案,只在这个月有效,它的正确性带着一个保质期;缓存如果无视保质期,就会在过期之后继续派发一个已经变质的答案。另一个是对象条件:"我的订单到哪了"这个答案,只对问出它的那个人有效,它的正确性绑定着一个特定的人;缓存如果无视这个绑定,就会把一个人的答案错误地(而且是危险地)交给另一个人。所以决定"要不要缓存、怎么缓存"之前,必须先给每个答案问两个问题:它会过期吗?它因人而异吗?会过期的,上 TTL;因人而异的,把 key 绑定到人。把"答案的有效性是有条件的"这件事想清楚,缓存才不会变成一个"过期信息和隐私泄露的分发器"。
把一个用户问题进来后,完整地走一遍语义缓存的决策流程画出来,就是下面这张图:
[mermaid]
flowchart TD
A[用户问题进来] --> B[转成 embedding 向量]
B --> C[向量检索 找最相似的缓存]
C --> D{相似度超过阈值吗}
D -->|没超过| E[调用大模型 把答案存入缓存]
D -->|超过| F{二次校验 答案真能复用吗}
F -->|不能复用| E
F -->|能复用| G{缓存还在有效期内吗}
G -->|已过期| E
G -->|有效| H[返回缓存答案]
六、把语义缓存做扎实,要避开的工程坑
前面五节讲清了语义缓存的核心:语义匹配、阈值、二次校验、可缓存性。但要在生产里真正用稳,还有几个工程坑得专门讲。第一个,也是最容易被忽略的:embedding 模型一旦更换,所有旧缓存的向量都会失效。
# 坑一:embedding 模型一旦换了,旧缓存的向量全部作废
# 缓存记录里,要存下这条向量是用哪个 embedding 模型算的
def store_v2(question, answer, model_version):
cache_entries.append({
"vec": embed(question),
"question": question,
"answer": answer,
"embed_model": model_version, # 记下当时用的模型版本
})
EMBED_MODEL = "text-embedding-v3"
def is_vec_valid(entry):
# 查缓存时,模型版本对不上的记录,直接当未命中
return entry["embed_model"] == EMBED_MODEL
# 不同 embedding 模型产出的向量,处在不同的向量空间里,
# 拿 v2 算的向量和 v3 算的向量去比相似度,结果毫无意义。
# 换模型时,旧缓存要么整体失效、要么用新模型批量重算。第二个坑,是监控。语义缓存如果只监控命中率这一个数,会把你带进沟里。
# 坑二:语义缓存要监控两个数,光看命中率会害死你
class CacheMetrics:
def __init__(self):
self.hits = 0 # 命中次数
self.total = 0 # 总请求数
self.wrong_hits = 0 # 误命中次数(靠抽样人工复核 / 用户反馈得到)
def hit_rate(self):
return self.hits / max(self.total, 1)
def wrong_hit_rate(self):
# 这个数,才是语义缓存真正的"安全指标"
return self.wrong_hits / max(self.hits, 1)
# 只看命中率,你会忍不住把阈值往低调 —— 命中率立刻变好看,
# 但误命中率在悄悄上升,你其实是在用"给错答案"换"省钱"。
# 两个数一起看,才看得见语义缓存真实的健康状况。还有几个坑值得点一下。其一,缓存的"问题原文"一定要存下来,不能只存向量——二次校验、人工复核误命中,都要用到原文。其二,embedding 调用本身也要花钱、也有延迟,如果一个问题大概率不会被复用(比如极其冗长、个性化的提问),为它算 embedding、查缓存可能比直接调模型还不划算,要有个快速跳过的判断。其三,缓存命中返回的答案,最好让用户无感知地标注一下来源,一旦发现误命中,能快速定位是哪条缓存惹的祸。下面把语义缓存的几道关键防线集中对照一下:
语义缓存的几道关键防线对照
防线 挡住什么问题 手段
----------------------------------------------------------
语义匹配 精确匹配命中率趋零 embedding 向量 + 相似度检索
相似度阈值 匹配过松或过严 用人工标注评测集校准 宁严勿松
二次校验 语义相近但答案不同 小模型判是非 或实体否定词硬比对
TTL 分级 时效内容返回过期答案 按问题类型给不同的过期时间
作用域分桶 私人答案串给别的用户 个性化问题的 key 绑定到用户
原则:语义缓存宁可漏命中 不可误命中 ——
漏命中只是没省到钱 误命中是自信地给出错误答案
这一节这几个坑,串起来是同一个意思:语义缓存不是一个"存一下、查一下"的工具,而是一个建立在"概率性判断"之上的系统——它的每一次命中,本质上都是一个"我赌这两个问题是一回事"的概率判断,而一个建立在概率判断上的系统,必须为"判断出错"这件事做好全套的工程准备。第一版的精确缓存,是一个确定性系统:命中就是命中,判断永远不会错,所以它不需要二次校验、不需要监控误命中、不需要追溯——这些东西它一概没有,因为它根本不会犯那种错。语义缓存换来了高命中率,代价是它变成了一个概率性系统:它的命中判断会出错,而且一定会出错,只是频率高低的问题。一旦接受了"它会出错"这个事实,这一节所有的坑就都有了统一的解释:你要存问题原文,是为了出错时能复盘;你要监控误命中率,是为了知道它错得有多频繁;你要给 embedding 模型记版本,是为了不让"换模型"悄悄制造一批错误判断。这些工程设施,没有一个是为了让缓存"命中得更多",它们全都是为了让这个"会出错的系统",在出错时是可观测的、可控制的、可追溯的。把语义缓存当成一个需要被持续监控和校准的概率系统来对待,而不是一个一劳永逸的 key-value 工具,你才能真正用稳它。
关键概念速查
| 概念 | 说明 |
|---|---|
| 语义缓存 | 用问题的语义相似度而非字符串相等来判断缓存是否命中 |
| embedding | 把文本转成定长向量,语义相近的文本其向量也相近 |
| 余弦相似度 | 衡量两个向量方向的接近程度,1 最像,越接近 0 越无关 |
| 相似度阈值 | 判定算不算命中的界线,语义缓存最危险的一个旋钮 |
| 误命中 | 语义相近但答案其实不同,缓存却返回了错误答案 |
| 漏命中 | 该命中却没命中,只是少省一次成本,远不如误命中危险 |
| 二次校验 | 命中后再确认答案能否复用,挡住误命中的关键防线 |
| TTL 分级 | 按问题的时效性给不同过期时间,避免返回过期答案 |
| 作用域分桶 | 个性化问题的缓存 key 绑定用户,防止私人答案串号 |
| embedding 模型版本 | 不同模型向量空间不同,换模型会令旧缓存全部失效 |
避坑清单
- 不要用精确字符串匹配缓存 LLM:自然语言问法千变万化,命中率趋零。
- 不要把相似度阈值拍脑袋定:要用人工标注的评测集测出来。
- 不要为了命中率把阈值调太松:松了就误命中,给用户错答案。
- 不要只信相似度:命中后要做二次校验,确认答案真能复用。
- 不要忽视一词之差:取消和开通、北京和上海,要做实体否定词硬比对。
- 不要无差别缓存一切:带时效性的回答要短 TTL 或干脆不缓存。
- 不要给个性化问题用全局缓存 key:会把私人答案串给别人。
- 不要换了 embedding 模型还用旧缓存:向量空间变了,相似度失效。
- 不要只监控命中率:必须同时盯误命中率这个安全指标。
- 不要本地少量重复测试就上线:真实用户问法的多样性测不出来。
总结
回头看第一版那个"问题字符串当 key"的缓存,它的失败很典型。它不在某一行代码,而在一个对 LLM 缓存的根本误解:以为它和数据库查询缓存一样,字符串相等即命中。真相是,LLM 缓存的 key 是自然语言,而自然语言里同一个意思有无数种说法,字符串相等这个判据严到几乎永不命中——命中率必然趋零。要让它真正有用,匹配必须从"字符串相同"换成"语义相同",而这一换,又引入了"相似度阈值"和"误命中"这两个全新的、必须谨慎对待的难题。
而把语义缓存做对,工程量并不小。它不是"存个答案"那么简单,而是要用 embedding 做语义匹配、要用人工评测集校准相似度阈值、要给命中加二次校验来挡误命中、要对关键实体和否定词做硬比对、要按时效性分级 TTL、要按个性化程度给缓存分作用域、还要监控误命中率、给 embedding 模型记版本。一套真正又省又安全的语义缓存,是这些环节一个不少地拼起来的。
这件事其实很像一个客服老员工凭记忆回答客人的问题。第一版的做法,像是要求"必须有客人一字不差地重复别人问过的原话",老员工才肯调用记忆——可现实里没人会一字不差地重复,于是他那一肚子记忆等于白搭。聪明的老员工是"听意思":新来的客人问的话,只要意思和以前某位客人问过的一样,就直接把那次的答案告诉他——这就是语义匹配。但"听意思"是有风险的:有人问"怎么开通会员",有人问"怎么取消会员",听着像、意思却正相反,老员工要是粗心,就会把开通的流程讲给想取消的人——这就是误命中。所以好的老员工不只"听意思",命中记忆后还会多问一句确认:"您是想取消对吧?"——这就是二次校验。还有些答案是带时效的,"这个月有什么活动",上个月的答案不能照搬给这个月的客人——这就是 TTL。还有些答案是私人的,"我的包裹到哪了",张三的答案绝不能告诉李四——这就是作用域。一个客服记忆要既省力又不出错,靠的从来不是"机械地比对字句",而是"听懂意思,又始终警惕那些听着像、其实不一样的陷阱"。
这类问题还有一个共同的麻烦:它在开发和测试时几乎暴露不出来。你自己测,来来回回就问那么几句话,问法的多样性极其有限,精确匹配也好、阈值调松一点也好,命中率都不会太难看,误命中也压根撞不出来——你会觉得"LLM 缓存嘛,存一下就完事"。真正会把问题撑爆的,是上线后的真实用户:成千上万的人,同一件事有成百上千种问法,你那个精确匹配的缓存会瞬间露馅,命中率贴着零;而海量的、千奇百怪的问法两两组合里,一定会有大量"语义相近但答案其实不同"的对子,把你那个调得偏松的阈值,撞出一连串误命中——而误命中意味着真实用户收到了一个错误答案,这比缓存没命中严重得多。所以如果你正在给一个 LLM 应用加缓存,别等命中率报表难看、别等用户投诉"答非所问",才回头怀疑你的缓存方式。在写下第一行缓存代码时就想清楚:我拿什么判断命中(语义而非字符串)、阈值我用什么去校准、误命中我怎么拦、什么内容根本不该缓存、命中之后我有没有一道兜底校验——把"让缓存能命中"和"让缓存只在真该命中的时候才命中"当成两件必须分别去做的事,这是这篇文章最想留给你的一句话。
—— 别看了 · 2026