缓存策略
RAG 链路比纯 LLM 调用长：嵌入、检索、重排、生成。缓存命中能同时省延迟和钱，但 RAG 的缓存有个特殊问题：用户问题几乎不会逐字重复，缓存键不能直接用原始文本。
三个缓存层级
RAG 缓存层级
语义缓存（最高层）：用户查询先向量化，和缓存的查询向量比对，相似度超阈值直接返回缓存的回答。适合高频重复问题，比如客服场景八成的提问是重复的。风险是语义误命中：两个问题语义相似但答案不同，会返回错误回答，阈值要校准。
检索缓存：相同或相似查询的检索结果复用，跳过嵌入和 ANN。适合查询稳定、知识库更新不频繁的场景。知识库更新时要按文档版本失效相关缓存。
生成缓存：完整回答缓存，按查询相似度加 TTL 管理。和语义缓存功能重叠，二选一即可，通常语义缓存就够。
缓存失效
RAG 缓存的一致性比传统缓存更难：知识库一更新，所有相关缓存都可能过期。策略：
- TTL：简单兜底，按知识更新频率设置
- 版本化失效：缓存记录知识库版本，版本变更时全量或按文档失效
- 敏感查询不缓存：涉及权限、个人信息、实时数据的查询跳过缓存
生产实践
- 缓存键用归一化后的查询（去标点、统一大小写），提高命中率
- 热度统计，只缓存高频查询，冷查询写缓存是浪费
- 缓存层和检索层分开部署，缓存抖动不影响主链路
- 监控命中率，低于预期先查查询归一化和阈值
面试追问
- 为什么 RAG 缓存不能用原文做键？ 用户问题几乎不会逐字重复，要用 Embedding 相似度做语义匹配
- 语义缓存的风险？ 语义误命中：两个问题相似但答案不同，返回错误回答。阈值要校准，敏感查询跳过缓存
- 知识库更新了缓存怎么办？ TTL 兜底加版本化失效，缓存记录知识库版本，变更时按文档失效
- 哪一层缓存性价比最高？ 语义缓存。高频重复问题命中后跳过整条 RAG 链路，延迟和成本同时省
- 什么查询不该缓存？ 涉及权限、个人信息、实时数据的查询。缓存会绕过权限校验和新鲜度要求