什么是语义缓存？

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link and all formatting exactly as you requested.

为什么语义缓存对生成式 AI 很重要

随着越来越多的应用采用生成式 AI，每次查询的成本成为一个主要痛点。
例如，Gemini 的定价如下：

即使是使用量适中的应用，也可能每月产生数千美元的费用。
一个拥有 500 名每日用户的小型客服机器人，如果不进行缓存，到了第 2 个月 API 费用就可能超过 $2 k。

底线： 减少 LLM 调用次数（以及向量数据库查询）对于成本效益和延迟都至关重要。

什么是语义缓存？

语义缓存的工作方式类似于传统缓存（LRU/LFU），但匹配的是含义而不是精确文本。

示例

典型的 RAG 流程与语义缓存

1. Chunk & embed 知识库（例如 Chroma、FAISS）。
2. 用户查询到达 → 语义缓存查找 首先。
   • 缓存命中 → 检索缓存的上下文 → 传递给 LLM → 返回响应。
   • 缓存未命中 → 执行普通向量‑DB 检索 → 生成响应 → 存储 新的查询‑结果对到缓存中。

余弦相似度

[ \text{cosine}(\theta) = \frac{A \cdot B}{|A| \times |B|} ]

• 返回值在 [0, 1] 之间。
• 1 = 方向相同（意义相同）。
• 0 = 正交（无相似度）。

好处

• 成本节约 – 减少向向量数据库和大型语言模型的调用次数。
• 响应时间更快 – 缓存结果可瞬间返回。
• 资源利用率更高 – 为更复杂的任务或更大流量释放计算资源。

功能比较

当语义缓存可能不是最佳选择

• 高度独特的查询（例如，代码生成、法律研究）。
• 缓存为空——在缓存预热之前，初始延迟较高。
• 相似度阈值过宽——可能返回不相关的片段（例如，“关于太空旅行的书籍” vs. “关于太空旅行健康风险的书籍”）。
• 实现复杂——比简单的键值缓存需要更多的工程投入。

需要监控的关键权衡

1. 阈值调优——阈值过高 → 命中少；阈值过低 → 命中不相关。
2. 缓存预热时间——需要为初始的高延迟阶段做好规划。
3. 相关性与成本——确保缓存结果真正满足用户意图。

TL;DR

• 语义缓存 通过匹配含义而非精确文本，减少对 LLM 和向量数据库的调用。
• 当查询模式重叠时，它能实现显著的成本和延迟降低。
• 它并非万能方案——需要谨慎选择阈值、处理缓存预热以及关注查询的唯一性。

当你的产品出现重复的、语义相似的查询时使用语义缓存；否则可考虑 查询改写、重新排序或混合搜索 等替代方案。

When to Skip Semantic Caching

• 个性化使用场景 – 缓存几乎不会命中，你只会增加开销。
• 低流量应用 – 如果你每天只有少量查询，几乎没有实际收益。
• 知识库快速变化 – 当文档持续更新时，你花在使缓存失效的时间会超过从中获得的收益。
• 精度不可妥协 – 缓存的上下文可能略有偏差。对于即使一点点错误也比慢更糟的场景，请不要使用缓存。

有效语义缓存的技巧

1. 校准相似度阈值

   • 一个好的起始范围是 0.85 – 0.90。
   • 根据具体使用场景进行调优并监控质量；没有通用的“正确”答案。

2. 使用 TTL（生存时间）值

   • 缓存条目应在底层数据变化或主题具有时效性时过期。
   • 过期的缓存比没有缓存更糟。

3. 预热缓存

   • 预先填充常见或预期的查询，这样在生产环境中就不会完全是冷启动。
   • 冷缓存无法提供任何好处。

4. 在知识库更新时失效

   • 如果向量数据库中的文档发生变化，基于旧块的缓存响应会悄然降低输出质量。

5. 监控命中率

   • 健康的语义缓存通常能达到 30 %–60 % 的命中率。
   • 太低 → 阈值可能设得太严格。
   • 命中率异常高但质量下降 → 阈值太宽松。

6. 考虑作用域（全局 vs. 用户级）

   • 全局缓存 能保存最多的条目，但在非常不同的用户上下文之间可能返回不匹配的结果。
   • 对于个性化应用，用户级缓存 即使效率稍低也可能更合适。

现成库（避免重复造轮子）