1.2.2 一个生产级 RAG 系统相比 Demo 多了哪些能力？

很多 RAG Demo 看起来都很顺：能导入文档、能问问题、也能生成一段像样的回答。但一旦进入真实业务场景，难点往往才刚开始出现。

一个生产级 RAG 系统和 Demo 的差别，通常不在“有没有大模型”，而在“能不能稳定、可控、持续地工作”。

Demo 解决的是“能不能跑”

一个 Demo 的重点通常只有三件事：

• 能把资料读进来
• 能检索到一些相关内容
• 能基于这些内容生成答案

这对于验证方向很有价值，但它只回答了一个问题：

这条链路理论上能不能成立？

生产系统要解决的是“能不能长期可用”

一旦系统真的面向用户，就会多出很多 Demo 里不明显的问题。

如果从“系统组成”的视角看，生产级 RAG 相比 Demo，真正多出来的不是一句抽象的“更复杂”，而是一批必须补齐的能力模块。最常见的额外能力包括下面几类。

1. 更完整的数据接入与更新能力

生产环境里的知识不是一次性导入就结束了，通常会不断新增、修改和删除。

所以系统需要处理：

• 增量更新
• 旧索引失效
• 重复内容清理
• 版本管理

如果这些事情做不好，知识库很快就会越来越乱。

从系统组成看，这一类能力补的是：

• 数据同步链路
• 版本状态管理
• 失效传播
• 增量重建机制

2. 更强的检索质量保障

Demo 常常只做最基础的向量检索，但线上系统通常会进一步补：

• 混合检索
• Metadata 过滤
• 重排
• 分层检索

原因很简单：线上问题更复杂，资料更多，用户也不会容忍“偶尔答得好，偶尔答偏”的系统。

从系统组成看，这一类能力补的是：

• 更多检索路径
• 更严格的过滤能力
• 候选结果优化能力
• 大知识库下的稳定召回能力

3. 权限和隔离能力

在企业场景里，不是所有资料都能被所有人看到。

所以生产系统必须考虑：

• 用户权限
• 数据隔离
• 多租户隔离
• 敏感信息控制

这类问题在 Demo 阶段往往被忽略，但上线以后会立刻变成硬要求。

从系统组成看，这一类能力补的是：

• 身份上下文
• 检索层边界过滤
• 多租户隔离
• 审计和合规约束

4. 评测和可观测性

Demo 常靠主观感觉判断效果，但生产系统不能只靠“看起来还行”。

它需要知道：

• 检索到底好不好
• 回答是不是忠于材料
• 哪一类问题最容易出错
• 问题到底出在检索、上下文还是生成

所以生产系统通常需要：

• 评测集
• 指标监控
• 日志采样
• 错误归因

从系统组成看，这一类能力补的是：

• 评测数据集
• 线上观测指标
• 中间链路记录
• 版本效果对比机制

5. 性能、成本和降级能力

Demo 通常只有少量数据和少量请求，而生产系统必须面对：

• 更大知识库
• 更高并发
• 更严格的响应时间
• 更敏感的调用成本

因此它通常还要补上：

• 缓存
• 超时控制
• 降级策略
• 失败兜底

从系统组成看，这一类能力补的是：

• 响应时间控制
• 成本控制
• 系统稳定性控制
• 异常情况下的服务连续性

6. 更可控的回答策略

Demo 往往只要能回答就行，但真实系统还要考虑：

• 没资料时要不要拒答
• 是否必须引用来源
• 证据不足时怎么提示
• 是否保留传统搜索入口

这些问题本质上都在决定：系统到底是“像个演示”，还是“像个可用产品”。

从系统组成看，这一类能力补的是：

• 回答策略
• 拒答策略
• 引用策略
• 用户交互策略

可以这样理解两者的差别

Demo 更像是在验证：

• 方向对不对
• 技术能不能跑通

而生产系统更像是在回答：

• 用户能不能长期放心使用
• 资料变化后系统会不会失真
• 出问题时能不能定位和回滚

换句话说，这篇里说的“多了哪些能力”，重点是在讲：

生产级 RAG 比 Demo 多了哪些系统模块、运行机制和保障能力。

这和后面那篇“为什么很多 RAG Demo 能跑，但很难稳定上线”角度不一样。那里更强调的是团队为什么容易低估上线难度，以及这种误判是怎么发生的。

一个更实用的判断标准

如果一个系统只有“导入文档 + 检索 + 回答”，它大概率还只是 Demo。

如果它已经开始认真处理：

• 更新
• 权限
• 评测
• 观测
• 成本
• 延迟
• 降级

那它才开始接近生产级 RAG。