152、RAG 检索增强生成（六）：生产落地——缓存、预热、增量索引与故障降级

152、RAG 检索增强生成（六）：生产落地——缓存、预热、增量索引与故障降级

一、从一次线上事故说起

凌晨两点，告警电话把我从梦里拽出来。用户反馈搜索“2024年Q3财报分析”时，系统返回了“2023年Q2财报分析”的内容。我第一反应是索引出问题了，但查了日志发现——向量数据库的索引更新任务在凌晨1点跑完，但缓存层还挂着旧数据。更诡异的是，部分节点因为内存溢出自动重启，导致缓存穿透，直接打到数据库，结果数据库连接池被打满，整个RAG链路瘫痪了半小时。

这个事故让我意识到：RAG系统在Demo里跑得再欢，到了生产环境，缓存策略、预热机制、增量索引和故障降级这四个环节，任何一个出问题，都会让用户觉得“这AI是智障”。

二、缓存：别让数据库成为你的瓶颈

2.1 缓存层级设计

我见过很多团队直接把向量数据库当缓存用，每次查询都去算相似度。这在大规模场景下就是找死。正确的做法是分层缓存：

第一层：内存缓存（L1）

• 用Redis或者本地内存（比如Python的cachetools）
• 缓存最近N次查询的完整结果
• 注意：别把整个文档向量存进去，存的是query_hash -> [chunk_ids, relevance_scores]的映射