RAG 的 Demo 很容易做，生产环境却很容易失控。
一开始你可能只要：
- 一个 embedding 模型
- 一个向量库
- 一个聊天模型
但真到线上，问题会迅速变成：
- 更新怎么做
- 成本怎么控
- 延迟怎么降
- 数据怎么隔离
- 错误怎么排查
- 版本怎么回归
所以生产级 RAG 的重点是“工程稳定性”，不只是“回答效果”。
一、最常见的 10 个坑
1. 把所有文档放进一个大集合
后果：
- 检索范围太大
- 噪声高
- 权限和租户隔离难做
建议按业务边界拆 source，而不是全塞一起。
2. chunk 没有业务上下文
后果：
- 单个 chunk 语义不完整
- query 很难命中真正有用的内容
建议补充标题、章节、对象名、时间版本等上下文。
3. 只做 dense search
后果：
- 编号、缩写、关键词类查询表现不稳
建议逐步升级到 hybrid retrieval。
4. 以为自己有 rerank，其实只是再按向量分数排一次
后果：
- 工程上看似完整
- 效果上没有真正精排
建议接入真实 rerank 模型，再做前后指标对比。
5. top_k 和阈值写死
后果：
- 某些 query 召回不足
- 某些 query 噪声过大
建议把“召回候选数”和“最终注入数”拆开，并用数据集调参。
6. 没有 context budget 设计
后果：
- prompt 过长
- 延迟和成本升高
- 证据质量下降
建议把 prompt 当作“有限预算的证据包”来设计。
7. 文档更新了，索引没同步
后果：
- 回答依据过期
- debug 很难看出问题
建议建立文档版本、增量更新和重建流程。
8. 没有证据引用
后果：
- 用户不信任答案
- 团队也难排查错误
建议把引用显示做成默认能力。
9. 没有离线 benchmark
后果：
- 每次优化都像盲人摸象
建议固定一组 gold queries，长期跟踪 Recall@K 和答案质量。
10. 没有 inspect 页面
后果：
- 系统错了，但没人知道哪一层错了
建议把 inspect 视为 RAG 的标配功能，而不是可选功能。
二、生产环境里最重要的 4 个非功能点
1. 延迟
RAG 延迟常见来源：
- embedding
- 向量检索
- rerank
- LLM 生成
常见优化手段：
- query embedding cache
- 候选结果 cache
- 减少不必要的 rerank 数量
- 把召回和精排拆成不同预算
- 根据 query 类型动态走轻重路径
2. 成本
成本不只是 LLM 调用，还包括：
- embedding 成本
- rerank 成本
- 存储成本
- 索引重建成本
建议至少区分：
- 离线摄取成本
- 在线查询成本
3. 数据隔离
如果涉及多租户、内部知识、权限差异，必须在检索前就做好边界控制。
建议把隔离逻辑放在：
- source 级
- metadata 级
- 查询过滤级
不要把安全问题留给最终 prompt。
4. 可回归
生产系统最怕的是：
- 这次更新后没人知道为什么变差
- 看起来更快了，但答案质量掉了
所以每次重要改动后，都应该至少复跑：
- 检索指标
- 生成指标
- 典型线上 bad cases
三、一个实用的性能优化顺序
不要一开始就做所有优化。更推荐按收益排序。
第一阶段：低成本高收益
- 优化 chunking
- 补 metadata
- 做 source 过滤
- 控制上下文长度
- 加 inspect
第二阶段：质量优化
- hybrid retrieval
- 真实 rerank
- query rewrite
- better prompt assembly
第三阶段：工程优化
- 缓存
- 异步摄取
- 增量索引更新
- trace 级评分
四、推荐的版本路线图
V1：可跑通
- 文档导入
- chunking
- dense retrieval
- 基础引用
V2：可诊断
- inspect 页面
- 原始候选可视化
- prompt 快照
- 基础 benchmark
V3：可优化
- hybrid retrieval
- rerank
- metadata 策略
- query routing
V4：可运营
- trace 打分
- 线上问题回放
- 数据集版本化
- 回归门禁
五、一个推荐的团队协作方式
如果团队里有算法、后端、产品一起协作，最好明确分工：
算法 / NLP
- embedding / rerank 选择
- chunking 方案
- benchmark 设计
后端
- ingestion pipeline
- 索引与缓存
- trace / inspect
产品 / 运营
- bad cases 收集
- 用户反馈归类
- 高价值问题维护
这样 RAG 才不会变成“只有一个人能调”的黑盒系统。
六、最后给一个非常实用的判断标准
如果你的 RAG 系统满足下面这些条件，说明已经开始走向成熟：
- 你知道每次回答用了哪些证据。
- 你能复现一次错误回答的完整链路。
- 你有一组固定 benchmark。
- 你能比较不同版本的检索和答案质量。
- 你知道下一步该优化哪一层。
如果这 5 条还做不到，那么最应该投入的通常不是“换更强模型”，而是把检索、inspect 和评测体系补完整。
七、系列总结
这组 RAG 文章的重点不是讲某一个框架怎么调 API，而是回答更底层的问题：
- RAG 到底该怎么设计
- 为什么 chunking 和检索策略决定了上限
- 为什么 inspect 和评测是刚需
- 怎么把 Demo 迭代成生产系统
如果后面你还想继续往下写，我建议下一批文章可以直接进入更细的专题：
- Query Rewrite 和 Query Decomposition
- Contextual Retrieval
- 多租户与权限过滤
- RAG 的引用生成与 Grounding
- RAG 与 Agent 的结合方式