为什么 RAG 缓存能省 60% 成本却最容易被忽略
RAG 系统的隐性成本大头不在向量库,而在”重复算”。一个生产级 RAG 系统每天有 30%-50% 的查询语义高度相似,完全没必要重新走一遍 embedding + 检索 + LLM。把缓存层做得正确,P95 延迟可以从 800ms 压到 200ms,月度账单下降 60% 以上。这篇文章不讲缓存框架对比,只讲工程上能落地的 5 个步骤。
步骤 1:把缓存拆成三层,而不是一层
最常见的反模式是把所有缓存都丢进 Redis 一个 key。实际上 RAG 的缓存至少该分三层:
- 查询层缓存 (Query Cache):对原始 query 字符串做精确 + 模糊匹配。命中后直接复用上一次的”检索结果”。命中率经验值 12-25%。
- 嵌入层缓存 (Embedding Cache):对 query 的 embedding 向量做缓存,只要 query 文本命中,就不必再调一次 embedding API。命中率(包含在 query 内)可以叠加到 40-55%。
- 答案层缓存 (Answer Cache):对”query + 检索结果”组合后的最终答案做缓存。命中率最高(50-70%)但一致性最难维护。
三层叠加的命中率经验值在 60-78% 之间。如果你只做了一层 query cache,命中率撑死 20%,性价比不行。
步骤 2:Query 缓存的 key 设计,模糊匹配比精确匹配更值钱
精确匹配只对完全相同的查询有效,但生产环境里用户会写”周报系统登录慢”和”周报系统登录卡顿”,这两条原始字符串不同,但 embedding 余弦相似度高达 0.93。
一种常见做法是用 双键缓存:
- 精确 key:
qa:exact:<sha256(query)>,直接命中即返回。 - 模糊 key:
qa:sem:<embedding_hash>,在 Redis 里用 hash bucket 做粗筛,再二次比对余弦相似度 ≥ 0.92 才算命中。
模糊分支要小心成本:每次”未命中精确”都要先算 embedding(中心化缓存这部分可以分摊),再去 Redis 找近似桶,所以模糊分支适合”高频 query 桶”而不是冷查询。生产经验:精确命中 18%、模糊命中 35% 是比较现实的目标。
步骤 3:Embedding 缓存要分桶,别让新文档拉低命中率
Embedding 缓存的 key 常见错误是用”query 字符串”作为 key——这会让 key 空间无限膨胀,并在文档更新后大量误命中。一个更稳的设计是双段 key:
emb:<corpus_version>:<sha256(query)>corpus_version在语料更新时整体 +1,把旧桶标记为不可用但暂不清除,7 天后清理。
这样新增或更新的文档会立即”绕过”旧缓存,降低答案不一致的概率。同时 corpus_version 可以让缓存层与下游业务解耦,运营人员推一次新文档不需要配合清缓存。
步骤 4:Answer 缓存要区分”事实型”与”建议型”
很多团队把 Answer Cache 设计成”任何 query + 任何 retrieval 结果都缓存”,结果命中率虚高但用户被过期答案糊弄。Answer 缓存要拆成两档:
- 事实型(query 涉及具体数字、年份、版本):只缓存 24 小时,且必须在答案里加”截至 YYYY-MM-DD”标识。
- 建议型(query 涉及方案、对比、解释):可以缓存 7-30 天,但要在每次语料更新后失效。
一种更工程化的做法是把这两档通过 query 路由器自动分流:Llama-3-8B 这类轻模型先做”是否是事实型 query”二分类(单次推理 30ms),再决定缓存 TTL。这个路由器可以独立部署,也方便独立调参。
步骤 5:监控三个指标,而不是看命中率
命中率是滞后指标,真正决定缓存系统好坏的三个指标是:
- P50 命中率下降曲线:连续 7 天下降超过 5% 就要排查,可能是 query 分布漂移或语料更新未生效。
- 过期答案回滚率:通过用户反馈或 A/B 抽样,统计”用户第一次没找到答案就退出会话”的比例。这个数字超过 8% 说明 Answer Cache 命中率是”假命中”。
- 成本节省 / 月度账单:用月度账单减去”假如没缓存”的对照账单,得到真实节省。经验值是 30% 起步,优秀系统在 55% 以上。
把这三个指标写进 dashboard,每周 review,缓存系统的健康度才能稳定追踪。光看”命中率 60%”是看不出问题的。
一个反直觉的工程细节:缓存命中率 60% 反而比 85% 更可持续
听起来不合理,但生产经验说明:命中率超过 80% 的缓存系统要么过期答案多、要么没怎么在 query 区分上花心思。一个命中率 60% 但答案新鲜度 99% 的系统,比命中率 85% 但新鲜度 80% 的系统对用户体验更好。
如果你的 RAG 系统接入了用户反馈,记得把”被点踩的答案”对应的缓存 key 主动失效一次——不要等 TTL 自然到期,这样用户的负反馈会被快速吸收。
5 步跑通后,先不要马上推全
缓存系统上线最常见的错误是一次性开三层、推全量。建议节奏是:
- 第 1 周:仅启用查询层缓存,看命中率与 P95 延迟。
- 第 2 周:在查询层之上叠加嵌入层缓存。
- 第 3 周:在 5% 流量上灰度 Answer Cache,观察”过期答案回滚率”。
- 第 4 周:对查询做事实型/建议型分流,扩大 Answer Cache 灰度。
- 第 5 周起:上 dashboard,持续观察三个月做长尾调优。
这套节奏让缓存层迭代的每一环都能被独立评估,不至于”上了三层缓存、效果没改善,但说不清是哪一层没起作用”。RAG 缓存不是堆功能,是把每层缓存的副作用独立管理。
