← 返回概念解读

Concept Fable精修版

语义缓存

Semantic Cache · AI platform / cost optimization

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

茶馆掌柜终于听懂了‘还是老样子’

槐树茶馆每天早晨都很忙。有人点清茶,有人点浓茶,有人说少糖,有人说照昨天那样。新伙计每次都从头问。

老客人被问得不耐烦。张先生的“老样子”已经说了三个月,李老板的“开会那杯”每周一都一样,可柜台只听见字面。

掌柜发现,很多订单说法不同,背后的茶却一样。有人说“昨天那杯”,有人说“少糖热茶”,实际都是同一壶。

于是他做了一本常客册。册子不只记原话,还记原话对应的茶:热度、糖量、姜片、杯型,以及哪些变化不能自动套用。

有了册子,新伙计遇到相似请求先查。意思相同,就复用已有配方;意思接近但有差异,就稍作调整;拿不准,再向客人确认。

茶馆速度快了,浪费少了。掌柜提醒,两个句子长得像,不一定是同一杯;换了说法,也不必完全重来。真正可复用的不是字,而是背后稳定的意思。

有一次,另一位客人也说“老样子”,新伙计差点套用张先生的茶。掌柜拦住他:相似说法要结合来人、时间和历史,不能只看四个字。

常客册因此越来越讲究。它复用稳定的意思,也保留确认的机会。茶馆省下重复劳动,却不把所有近似都当成相同。快,是因为懂意思;稳,是因为知道何时不能复用。 后来新手入门时,老师傅不再先讲抽象名目,而是让他们复盘那次失误:原先哪里靠直觉,第一次修补为什么不够,新的安排怎样把风险留在能检查的位置。等他们能说清这些细节,还能指出什么时候该沿用、什么时候该升级,才算真正懂了这套办法。 后来他们还把这套办法交给新人演练:先让新人按旧办法做一遍,看错误怎样出现;再按新规矩重做,看哪一步被提前拦住,哪一步留下了证据。新人若只会背名字,仍会在相似场景里乱用;只有能说出适用边界、代价和失败后的补救,才被允许独立接活。 这道关卡不能省。

揭示

这个故事讲的是:语义缓存

语义缓存 Semantic Cache 是根据请求的语义相似度复用已有回答、中间结果、检索结果或工具结果的机制。它不同于只按完全相同字符串命中的普通缓存,而是判断两个请求在含义上是否足够接近。对 AI 系统来说,语义缓存可以降低模型调用成本、减少延迟,但也需要控制相似度阈值和过期策略,避免复用错误答案。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 茶馆订单:用户请求或 Agent 子任务
  • 说法不同但意思一样:语义相似请求
  • 新伙计每次从头配:没有缓存时重复调用模型或工具
  • 常客册:语义缓存,保存可复用的结果和上下文
  • 老样子、昨天那杯、少糖热茶:不同表达可能映射到同一意图
  • 意思接近但有差异就调整:缓存命中需要相似度判断和补充处理
  • 不能因为长得像就当成一样:语义缓存需要阈值、验证和失效机制
  • 记住可复用的意思:Semantic Cache 的核心是按含义复用,而不是按字面复用

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Response cacheembeddingvector searchcache hit ratetoken costlatency