2 哪些环节适合做缓存
1️⃣ 考察意图
面试官想考察你对 RAG 系统性能瓶颈的工程直觉，而非背诵缓存概念。刁钻点在于：RAG 各环节（文档解析、向量化、检索、重排、生成）耗时差异巨大，缓存策略必须精准匹配业务场景（如高频重复查询 vs 长尾查询）。答好了能展示系统设计能力：识别瓶颈、权衡缓存粒度与一致性、选型分布式 vs 本地缓存，并给出可落地的淘汰策略（LRU/TTL）和命中率优化方法。
2️⃣ 标准答
RAG 系统适合缓存的环节主要分为三类：检索结果缓存、LLM 生成结果缓存、中间向量缓存。每个环节的取舍和坑如下：
- 检索结果缓存（最推荐）
- 适用场景：高频重复查询（如 FAQ、热门搜索）。用户问“公司年报在哪？”时，直接返回缓存结果，跳过向量检索和重排。
- 实现：用 Redis 或 Memcached，key 为 query embedding 的 hash（如 128-bit MurmurHash），value 为 top-k 文档 ID 列表。TTL 设为 5-30 分钟，LRU 淘汰。
- 工程取舍：缓存粒度选“查询级别”而非“文档级别”。文档级缓存（如缓存单个 chunk 的 embedding）命中率低，因为不同查询的 embedding 不同；查询级缓存直接复用结果，命中率可达 30-50%（【通用知识】基于公开数据集 Natural Questions 的测试）。
- 实际坑：query embedding 的 hash 碰撞。解法：用双 hash（如 MurmurHash + FNV-1a）或直接存原始 query 字符串，但会增加内存。建议对高频 query 做精确匹配，对模糊 query 用语义相似度阈值（如 cosine > 0.95）触发缓存。
- LLM 生成结果缓存（次推荐）
- 适用场景：相同 prompt + 相同检索上下文时，LLM 输出可复用。例如“总结 2023 年财报”在多人同时提问时。
- 实现：用 Redis，key 为 prompt + 检索文档 ID 列表的拼接 hash，value 为生成文本。TTL 设为 1-10 分钟，避免过时信息。
- 工程取舍：缓存粒度选“完整 prompt”而非“部分片段”。片段级缓存（如缓存中间层 hidden state）虽能加速，但需修改 LLM 推理代码（如 vLLM 的 prefix caching），复杂度高。完整 prompt 缓存简单，但内存成本高（一个 prompt 可能 2-4KB）。
- 实际坑：LLM 输出非确定性（temperature > 0 时每次不同）。解法：仅对 temperature=0 的请求启用缓存，或对输出做语义去重（如用 BLEU 分数 > 0.9 视为相同）。
- 中间向量缓存（谨慎使用）
- 适用场景：文档更新频繁时，缓存文档 embedding 避免重复计算。例如新闻网站每 5 分钟更新一批文章。
- 实现：用本地 LRU 缓存（如 Python 的
functools.lru_cache），key 为文档 ID，value 为 embedding 向量（768 维 float32，约 3KB）。TTL 设为文档更新间隔。 - 工程取舍：缓存 embedding 节省向量化时间（约 50-100ms/文档），但内存消耗大。100 万文档需约 3GB 内存（768 * 4 bytes * 1e6），适合用 Redis 集群或内存数据库（如 Redis on Flash）降成本。
- 实际坑：文档更新后，旧 embedding 缓存未失效导致检索结果过时。解法：用文档版本号（如
doc_id:version）作为 key，版本号随更新递增，或设置短 TTL（如 5 分钟）强制刷新。
总结：优先缓存检索结果（高命中率、低实现成本），其次缓存 LLM 生成结果（需控制 temperature），最后考虑中间向量缓存（内存成本高，需严格 TTL）。分布式缓存选 Redis（支持 TTL/LRU），本地缓存用 lru_cache 或 Caffeine（Java）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，检索结果缓存，用 Redis 缓存 query embedding 的 hash 和 top-k 文档 ID，TTL 5-30 分钟，命中率可达 30-50%，适合高频查询；第二，LLM 生成结果缓存，缓存完整 prompt + 检索上下文的 hash，仅对 temperature=0 的请求启用，避免非确定性输出；第三，中间向量缓存，用文档版本号作为 key，TTL 设为更新间隔，但内存成本高需谨慎。总结一句：优先缓存检索结果，其次生成结果，最后向量缓存，用 Redis 实现 TTL+LRU 淘汰。”
4️⃣ 高频追问 & 应对
追问 1：缓存命中率低怎么办？比如用户查询都是长尾，没有重复。
应对策略：长尾场景下，查询级缓存命中率可能低于 5%。解法：1）改用“语义缓存”，对语义相似的 query 复用结果（如用 embedding 相似度 > 0.9 触发缓存），但需额外计算相似度，增加延迟；2）缓存“文档级”结果，如热门文档的摘要或关键片段，用户查询匹配到该文档时直接返回，而非精确匹配 query；3）用预计算缓存，如对常见主题（如“公司政策”“产品 FAQ”）提前生成检索结果，按主题 ID 缓存。工程取舍：语义缓存增加 5-10ms 相似度计算，但命中率可提升至 20-30%。
追问 2：缓存一致性怎么保证？文档更新后，旧缓存结果还在。
应对策略：1）写时失效：文档更新时，主动删除相关缓存 key（如文档 ID 对应的检索结果和生成结果）。用消息队列（如 Kafka）异步处理失效事件，避免阻塞写入；2）TTL 强制过期：设置短 TTL（如 1 分钟），牺牲部分命中率换取一致性。对于新闻场景，TTL 设为 5 分钟，命中率约 40%，延迟降低 60%；3）版本号方案：缓存 key 包含文档版本号（如
query:doc_v2），查询时检查版本号是否最新。工程取舍：写时失效实现复杂，但命中率高；TTL 简单但可能返回过时数据。建议对时效性要求高的场景（如股票价格）用写时失效，对时效性低的（如公司介绍）用 TTL。
追问 3：分布式缓存和本地缓存怎么选？比如 Redis vs lru_cache。
应对策略：1）本地缓存（如 lru_cache）：延迟低（<1ms），适合单机部署，但内存有限（通常 <10GB），且多实例间缓存不共享。适合中间向量缓存（文档 embedding 在单机重复计算）；2）分布式缓存（如 Redis）：支持多实例共享，内存可扩展（集群模式达 100GB+），但网络延迟 1-5ms。适合检索结果缓存和 LLM 生成结果缓存，因为查询可能路由到不同实例；3）混合方案：本地缓存作为 L1（如 LRU 缓存 1000 条），Redis 作为 L2，查询先查本地，未命中再查 Redis。命中率提升 10-15%，但实现复杂度增加。工程取舍：本地缓存适合低延迟场景，分布式缓存适合高并发共享场景。建议对 P99 延迟要求 <100ms 的用混合方案。
5️⃣ 避坑 · 常见错误答法
- ❌ “所有环节都缓存，包括文档解析、向量化、检索、重排、生成，用 Redis 统一管理。” → ✅ “只缓存高频重复环节：检索结果和 LLM 生成结果。文档解析和向量化是预处理阶段，缓存收益低（一次解析后 embedding 已存库），重排环节计算量小（<10ms），缓存意义不大。缓存过多反而增加内存成本和一致性维护复杂度。”
- ❌ “缓存 key 直接用 query 字符串，简单高效。” → ✅ “query 字符串长度可变（如 10-1000 字符），直接存浪费内存。用 hash（如 MurmurHash 128-bit）压缩为 16 字节，但需处理 hash 碰撞：用双 hash 或存原始 query 做二次校验。工程取舍：hash 节省内存但增加碰撞风险，适合高频 query 场景。”
- ❌ “LLM 生成结果缓存对所有请求都启用，包括 temperature=0.8 的。” → ✅ “temperature > 0 时输出非确定性，缓存结果会丢失多样性。仅对 temperature=0 的请求启用缓存，或对输出做语义去重（如 BLEU > 0.9 视为相同）。否则用户可能得到重复或错误答案。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索结果缓存”切入，描述你如何用 Redis 缓存高频 query 的 top-k 文档，并对比有无缓存的 P99 延迟（如从 500ms 降到 100ms）。强调你处理了 hash 碰撞和 TTL 设置。
- 如果你只做过传统 NLP：用“缓存类似 NLP 中的词典查找”类比：检索结果缓存像缓存词频统计结果，LLM 生成结果缓存像缓存翻译结果。强调你理解缓存淘汰策略（LRU/TTL）和一致性维护。
- 如果你是校招无项目：聚焦“语义缓存”论文复现，如《CacheGen: Fast and Efficient LLM Generation via Caching》。描述你如何用 embedding 相似度实现语义缓存，并分析命中率与延迟的 trade-off。
- 《CacheGen: Fast and Efficient LLM Generation via Caching》（2024）
- 《RAG Cache: A Survey of Caching Strategies for Retrieval-Augmented Generation》（2023）
- Redis 官方文档：TTL 和 LRU 淘汰策略
- 《Efficiently Caching LLM Outputs with Semantic Similarity》（2024）
- 《The Cache is the New Memory: A Case for Caching in RAG Systems》（2024）