布吉岛 Agent

Appearance

1.3.3 为什么很多 RAG Demo 能跑，但很难稳定上线？ ​

这是 RAG 落地里最常见的现实落差之一。

你可能会看到一个 Demo：

  • 上传几份文档
  • 提几个问题
  • 返回的答案看起来还不错

但真正进入业务环境后，系统却开始频繁暴露问题。原因并不是 Demo 骗人，而是 Demo 和上线系统面对的难度根本不是一个量级。

这篇最想纠正的误解不是“生产系统更复杂”这么抽象，而是：

很多团队会误把 Demo 的局部成功，当成系统已经接近可上线。

真正的问题，往往不是大家没见过上线难度，而是 Demo 太容易制造一种错觉：

  • 看起来能答
  • 偶尔答得还不错
  • 主要链路已经跑通

于是团队会自然地低估后面要补的系统能力。

Demo 的问题规模通常很小 ​

一个 Demo 往往有这些特点：

  • 文档数量少
  • 文档质量比较干净
  • 问题类型有限
  • 没有复杂权限
  • 并发很低
  • 评估方式主要靠人工感觉

在这种条件下，哪怕链路比较粗糙，系统也可能表现得不错。

这也是 Demo 容易“显得成功”的根源。它通常验证的是：

  • 在一批干净样例上能不能工作
  • 在少量标准提问上能不能给出像样结果

但它没有真正验证：

  • 面对脏数据还能不能稳
  • 面对真实用户提问还能不能稳
  • 面对权限和版本约束还能不能稳

线上系统面对的问题复杂得多 ​

一旦系统真的给用户使用，难点会迅速放大。

1. 数据质量变差 ​

真实知识库往往不是精心挑选过的一小批样例，而是：

  • 来源复杂
  • 格式混乱
  • 内容重复
  • 版本不一致
  • 噪声很多

这时，原来 Demo 里看不出来的数据问题，会直接变成检索质量问题和回答质量问题。

2. 用户问题变得不可控 ​

Demo 里的提问常常比较“标准”，但真实用户的问题通常更口语化、更模糊、更多样。

这会带来：

  • 查询理解难度上升
  • 检索稳定性下降
  • 上下文组织难度增加

很多系统一开始看起来效果不错，真正上线后却发现只要用户稍微换一种问法，结果就开始波动。

3. 权限和隔离开始变成硬约束 ​

在演示环境里，资料通常默认都能看。但在真实环境中，不同用户能看到的资料往往不一样。

这时系统必须认真处理：

  • 权限控制
  • 敏感信息保护
  • 多租户隔离

如果这类能力缺失，系统不只是“效果不好”，而是“不能上线”。

4. 评测和归因不能再靠感觉 ​

Demo 阶段，你可以凭肉眼判断“这次回答还不错”。但上线以后，用户量一大，就必须知道：

  • 哪类问题最容易错
  • 错误出在检索还是生成
  • 新版本是变好了还是退化了

如果没有评测和归因机制，系统就会进入一种很被动的状态：

看起来总有问题，但不知道问题到底在哪。

5. 成本、延迟和并发会变成现实压力 ​

Demo 环境里，一次回答慢一点、贵一点通常还能接受。但线上系统需要面对：

  • 高并发请求
  • 更大知识库
  • 更严格的响应时间
  • 更真实的调用成本

这时缓存、降级、超时控制、索引优化和检索优化都会变得很关键。

为什么团队会误判“已经接近上线” ​

这类误判通常不是因为团队不认真，而是因为 Demo 的反馈机制本身就容易失真。

最常见的几个原因是：

1. 只测了少量“标准问题” ​

如果测试问题大多来自开发者自己，通常会更接近：

  • 关键词明确
  • 问法标准
  • 已知答案在哪

这会天然高估系统效果。

2. 只用了少量高质量资料 ​

Demo 里的资料常常是手工挑过的，所以：

  • 噪声少
  • 重复少
  • 版本冲突少

这会掩盖真实知识库里最常见的问题。

3. 没把错误拆层 ​

很多 Demo 只看“最后回答看起来行不行”，但不看：

  • 召回有没有问题
  • 排序有没有问题
  • 上下文构造有没有问题

这样一来，就算偶尔答对了，也不知道是系统真的稳，还是碰巧稳。

4. 没把运行约束算进去 ​

在演示环境里，往往不会认真考虑：

  • 高并发
  • 成本预算
  • 平均延迟
  • 权限边界
  • 失败回滚

这些恰恰是上线后最先暴露的问题。

Demo 能跑，往往只说明“方向成立” ​

一个 Demo 成功了，通常只能说明：

  • 这条链路理论上是可行的
  • 这个场景值得继续投入

它并不自动说明：

  • 数据治理已经足够好
  • 检索已经足够稳
  • 回答已经足够可控
  • 系统已经有能力面对真实用户

所以更准确地说，Demo 的价值是“验证方向”，不是“替代落地”。

更具体一点说，Demo 更像是在回答：

  • 这个场景值不值得继续做？
  • 外部知识接入之后有没有明显价值？
  • 裸模型和 RAG 之间有没有可见差异？

而不是在回答：

  • 这个系统能不能稳定给用户用？
  • 数据更新以后会不会失真？
  • 出现错误时能不能定位、回滚、修复？

为什么很多团队会卡在这里 ​

因为 Demo 阶段看到的是“表面效果”，而真正上线时需要补的是“底层能力”。

从 Demo 到可上线系统，中间最容易被低估的往往就是：

  • 数据治理
  • 权限控制
  • 检索稳定性
  • 评测体系
  • 观测和回滚能力

这些东西不像 Demo 那样直观，但它们才决定系统能不能长期稳定地服务用户。

一个更现实的使用方式 ​

所以看待 Demo，更合理的心态通常是：

  • 把它当方向验证，不当成熟度证明
  • 把它当问题暴露入口，不当上线资格证明

只要团队能用 Demo 尽早发现“这条链路值得做”，它就已经很有价值了。真正危险的，不是 Demo 本身，而是把 Demo 当成了接近成品的信号。