布吉岛 Agent

Appearance

11.2.2 哪些环节适合做缓存？ ​

先给结论：RAG 不是只能缓存“最终答案”。检索结果、重排结果、上下文构造结果都可以缓存，但必须绑定权限、版本和时间边界。缓存位置选错，会带来比延迟更严重的风险。

很多团队一谈缓存，第一反应是：

  • 缓存最终答案

这当然是最直接的方式，但在真实系统里，答案缓存往往最敏感，也最容易出错。更合理的做法是按链路分层缓存。

一、适合缓存的环节 ​

1. 检索结果缓存 ​

适合场景：

  • 高频查询
  • 文档更新不频繁

价值：

  • 减少向量库或搜索引擎压力
  • 稳住高并发下的检索延迟

注意：

  • 必须绑定 tenant、permission、version、time_range

2. 重排结果缓存 ​

适合场景：

  • 重排模型成本高
  • 查询重复率较高

价值：

  • 减少重排调用
  • 稳定最终排序

注意：

  • 如果候选池更新频繁，需要设置较短 TTL

3. 上下文构造结果缓存 ​

适合场景：

  • 上下文构造逻辑复杂
  • 长文档、多文档组合成本高

价值：

  • 减少拼接和聚合成本
  • 稳定生成输入

注意：

  • 上下文构造和模板版本要纳入缓存键

4. 生成结果缓存 ​

适合场景：

  • 高频 FAQ
  • 低时效内容

价值：

  • 最显著地降低成本和延迟

注意：

  • 最敏感，必须绑定权限和版本，必要时设置短 TTL

二、不适合缓存的环节 ​

以下情况通常不适合缓存或需要非常谨慎：

  • 强时效问题
    例如实时库存、订单状态、价格等

  • 高风险或强合规问题
    错误答案的代价非常高

  • 高度个性化场景
    与用户上下文强绑定的问题

在这些场景里，缓存会带来：

  • 答案过期
  • 权限穿透
  • 个性化错配

三、缓存设计必须绑定的几个关键条件 ​

一个可用的缓存键至少应包含：

  • tenant / org
    避免租户串数据

  • permission_scope
    避免权限越界

  • version / effective_time
    避免新旧版本混答

  • query_norm
    避免同义问题重复计算

这四个条件如果少了任何一个，缓存就可能从“提升性能”变成“制造风险”。

四、缓存的常见误区 ​

误区一：只缓存最终答案 ​

结果可能是：

  • 缓存命中率不高
  • 风险最高

更稳的做法是：

  • 优先缓存检索或重排结果

误区二：缓存键只用 query ​

这会导致：

  • 权限串数据
  • 新旧版本混用

误区三：缓存没有失效策略 ​

如果没有 TTL 或版本失效机制，缓存会：

  • 越用越不可信

五、一个最小缓存层级示意 ​

python
cache_layers = {
    "retrieval_cache": ["tenant", "permission", "version", "query_norm"],
    "rerank_cache": ["tenant", "permission", "version", "query_norm"],
    "context_cache": ["tenant", "permission", "version", "query_norm", "template_id"],
    "answer_cache": ["tenant", "permission", "version", "query_norm"]
}

这个示意的重点是：

  • 不同环节能缓存
  • 但缓存键必须足够严格

一句话总结 ​

RAG 缓存应该分层放在检索、重排、上下文和生成等环节，但必须绑定权限、版本和时间边界。缓存位置选错或缓存键设计不完整，性能提升会换来系统风险。