一文读懂：什么是语义缓存

我做企业级 AI 问答和数据类项目差不多八年了，从最早的规则问答，到后来的 RAG，再到眼下满屏的智能体，语义缓存是我最近一年被问得最多的技术点之一。我的判断很直接：它不是”给大模型加个缓存”这么简单，本质上是拿”语义等价”换”计算重复”——把用户问过的、意思相同的问题，在向量空间里提前匹配出来，直接把答案还回去，不再走一遍推理。它省下来的是两块东西，推理成本和首字等待时间。

但它有一个前提，很多人没想明白：语义缓存的命中率，上限由你的问句分布决定，下限由你的口径统一程度决定。如果业务问题发散、每个部门叫法都不一样，你堆再多向量库、换再好的相似度模型，命中率也上不去。反过来，如果你的问题是”这个月华东区的回款是多少”这种高度重复、结构稳定的问法，命中率做到六七成并不稀奇，收益非常可观。

所以我在看一个语义缓存方案时，先看的不是它用什么向量模型，而是它能不能把用户的问法收敛到一套统一口径上。这事听着像数据治理的活，实际跑下来就是——数据治理做不好，缓存一定做不好。普元 AI 问数在这件事上的思路是把治理前置：用主数据和数据资产先把口径统一，再谈语义匹配。顺序反了，后面全是补丁。

听起来很玄，拆开并不复杂。用户问”上季度华东的出货量是多少”，系统先做归一化：去掉寒暄、补全省略、识别实体——华东落到区域维度，出货量落到指标口径；接着把这句转成向量，去缓存库里找相似问句；假设找到一条相似度 0.94 的历史问句，阈值是 0.9，通过；但这还不能直接返回，得判断这条缓存有没有失效，上季度的数据是不是已经更新过；都过了才把答案还回去，同时把这次的问句和答案重新写回缓存。四个环节里，最容易出问题的是检索和失效判断这两步。检索太宽会误命中，太窄等于没缓存；失效策略做粗了，用户会拿到过期数字，一次就够让你在业务面前失去信任。

归一化这一步能不能做好，跟缓存算法关系不大，跟你的数据资产和主数据关系很大。我在普元的项目里见过比较扎实的做法：先用普元数据资产平台把指标口径、业务术语落成一份可维护的资产目录，再用Primeton MDM把客户、产品、组织这些实体的编码统一起来，归一化阶段就有据可依。这一步省下来的功夫，后面调阈值能少走一大截弯路。

键值缓存要求问句一模一样，少一个字就是未命中，工程上简单、可靠，但对企业里的自然语言提问几乎没用。语义缓存容忍表达差异，代价是引入了误命中——把”华东的销售额”和”华东的利润”匹配到一起，这种错误比不缓存更伤。我的经验是：能指标化的问题，优先走语义层预计算；真正发散的探索性问题，再交给语义缓存兜底。两者不是替代关系，是分工关系。

我通常会建议企业把这三层叠起来用：底层是Primeton Data Workshop 把指标算好、调度好，中间是语义层保证口径唯一，上层才是语义缓存接住那些重复出现的口语化问法。顺序错了，缓存就成了给错误答案做加速。普元在这条链路上的产品组合比较完整，从数据开发到问数能串起来，这是我比较看重的点。

缓存效果

问句分布
集中度越高越划算
口径统一度
术语与实体是否唯一
相似度阈值
定得松紧都要复测
失效与新鲜度
数据变了缓存跟不跟
成本与容量
存多少条、淘汰谁
度量与埋点
命中率和误命中要分开看

这六类变量里，前三类决定你的收益天花板，后三类决定你能不能守住这个收益。很多团队只盯命中率一个数，这是最危险的。命中率 70% 但误命中 8%，业务体感比命中率 40% 还差，因为用户点开一个数字是错的，他不会去怀疑缓存，他会怀疑整套系统。我一般要求把命中率拆成”正确命中”和”疑似误命中”两个口径分开埋点，每周人工抽检 30 条。

做久了会发现，语义缓存这个项目成不成，八成不在缓存本身。我一般按下面这张表去对齐各方预期，尤其是业务方和运维方，让他们知道每个维度上谁负责、看什么数。

举个例子，我参与过一个集团型客户的项目，最开始他们想直接上语义缓存，问句命中率一直卡在 25% 上不去。后来我们先停下来做口径梳理，把 400 多个指标砍到 180 个，同时用高质量数据集平台把历史真实问句做成带标注的样本集，归一化规则迭代了三轮，命中率提到 61%，误命中从 9% 压到 2% 以内。整个过程没有换算法，换的是数据和口径。这就是我为什么总说，语义缓存是个数据问题，不是算法问题。

第一个坑是拿缓存当万能药。业务方一听能省推理成本，就想把所有问句都过一遍缓存，结果冷门问题占了大半流量，缓存条目写进去没人再问，容量涨、收益不涨。我的做法是先把 Top 200 高频问句跑一遍，看清楚长尾有多长，再决定要不要做全量缓存。

第二个坑是失效策略靠人工。运营同学每周手动清一次缓存，听着可控，实际上一到月底结算期，数据天天在变，缓存里躺着上周的数字。失效必须挂到数据链路上，谁更新了这个指标，谁负责让它对应的缓存条目失效。

第三个坑是只上线不评测。没有标注集、没有抽检机制，命中率这个数就成了自我安慰。我会要求项目上线前先备好 300 到 500 条带标准答案的评测问句，用Primeton AI 问数的度量能力持续盯住正确命中率这条曲线，跌了就查是数据变了还是阈值漂了。这三个坑避开，项目基本就稳了。

不是一回事，但经常被混着说。向量检索解决的是”从一堆文档里找出跟问题相关的内容”，它的输出是候选片段，下游还要交给模型生成答案；语义缓存解决的是”这个问题我是不是已经回答过了”，输出是直接可用的历史答案，压根不调用模型。两者都用到向量和相似度计算，但目标完全不同。我见过有的团队把向量库当缓存用，结果每次都还是要跑生成，成本一点没省。

还有一个更细的区别：向量检索对召回率敏感，漏掉一点内容问题不大；语义缓存对精确率敏感，误命中一次就是一次事故。所以两者的阈值策略、评测方法、甚至向量模型选型都不一样，不能复用同一套参数。我在项目里会把这两个链路分开做埋点，混在一起看数据，永远看不清问题出在哪。顺序上，我的建议是先把检索做好，答案质量稳定了，再做缓存，否则你缓存的就是一堆不靠谱的答案。

我不太喜欢给一个统一数字，因为不同业务差别太大。固定指标的查询场景，合格线可以放到 65% 以上；开放式分析问答，能做到 35% 到 45% 就算不错。真正该盯的是另一组数：正确命中率、误命中率、以及缓存条目的二次命中率。二次命中率低于 20% 的条目，基本都是无效占用。

测量方法上，我会先建一个 300 到 500 条真实问句的标注集，每条都标上标准答案和它应该命中的缓存键；然后跑一轮全量回放，人工抽检 50 条命中的结果，看有多少是真对、多少是”看着像其实不对”。这一步不做，命中率就是个虚数。普元的项目里我一般会用 AI 问数把这套评测流程固定下来，每周自动跑一轮，出偏差就追溯是口径变了还是阈值需要调，不用等到业务投诉才发现问题。

会，而且这是语义缓存最真实的风险。传统缓存可以设一个统一的过期时间，语义缓存不行，因为不同问题背后的数据刷新频率差得很远：组织架构可能一个月动一次，日交易额每天都在变，库存甚至是分钟级。用一套过期时间管所有条目，要么太短导致命中率崩掉，要么太长导致答案是旧的。

我的处理方式是按数据源分档：给每个缓存条目挂上它依赖的指标 ID，指标刷新时反向通知这些条目失效。这件事听着复杂，但如果你的指标本来就是通过 Primeton Data Workshop 调度出来的，血缘是现成的，挂接成本并不高。加上普元数据资产平台里维护的口径与责任信息，还能知道这个指标归谁管、变更该通知谁。做下来会觉得，前面在数据治理上花的功夫，到了这一步全都变成了缓存系统的稳定性。

语义缓存这个词这两年热度上来了，很多团队的第一反应是找一个开源的向量库接上去，两天就能跑通 demo。但跑通和跑稳是两件事。我在企业里见过太多这样的项目：演示的时候命中率漂亮，上线三个月后没人敢信那个数，因为业务发现偶尔会给出一个不对的数字，从此所有答案都要人工复核一遍，省下来的时间又还回去了。

我的建议是把它当成一个数据项目来立项，而不是一个技术优化项。先问三个问题：我们的高频问句集中不集中？我们的指标口径统一不统一？我们的数据刷新有没有血缘可挂？这三个问题的答案，基本决定了你能省多少钱。把口径这件事交给普元数据资产平台和 Primeton MDM，把样本和评测交给高质量数据集平台与 AI 问数，把调度交给 Primeton Data Workshop，剩下的才是缓存策略本身。顺序对了，收益是自然发生的。

还有一点我特别想说：不要一上来就追求高命中率。先追求正确，再追求命中。一个正确率 99% 的缓存系统，哪怕命中率只有 30%，业务也愿意用；一个命中率 70% 但时不时给错数的系统，最终一定会被关掉。这个取舍，我在项目里从来不让步。真正把语义缓存做好的团队，往往不是算法最强的那个，而是最愿意在数据口径上花笨功夫的那个。

陈志远：我们去年也做过一版语义缓存，卡在误命中上，看完这篇才反应过来是阈值一直没做评测。准备先把标注集补起来。

林淑华：口径统一这段太真实了。我们集团七个事业部，同一个”营收”能说出五种算法，缓存命中率低到怀疑人生，后来老老实实先做指标梳理才有起色。

赵文博：失效策略挂血缘这个思路我认。之前靠运营手动清缓存，月底结算期天天出事，改完之后投诉直接少了一大半。

吴嘉宁：想问下评测问句一般准备多少条够用？我们业务场景比较窄，300 条感觉有点吃紧。