11.1.1 一个能上线的 RAG 系统除了主链路，还需要哪些工程能力？

先给结论：生产级 RAG 除了主链路，还至少需要四类能力：可控性、可观测性、可回退性和可进化性。它们决定了系统能不能稳定上线，而不是“能不能答对几题”。

很多系统在 Demo 阶段看起来很顺，但一上线就开始暴露问题，最常见的不是模型本身，而是下面这些能力缺失：

• 出错了却不知道问题在哪
• 线上波动了却无法回溯
• 发现风险却无法快速回退
• 新版本上线后没有稳定验证

一、可控性能力

这是最容易被忽略的一类，但也是生产系统的底线。

可控性通常至少包含：

• 权限与租户隔离
  必须保证检索和生成都在权限范围内生效

• 版本与时效控制
  避免新旧规则混用，确保回答基于当前有效文档

• 安全与合规边界
  资料不足时拒答，敏感内容不外泄

这些能力决定了系统能不能“放心给用户用”。

二、可观测性能力

没有观测就没有定位能力。生产系统必须能回答下面这些问题：

• 这次失败是召回问题还是生成问题
• 哪些问题类型正在退化
• 哪个环节延迟开始升高

典型的观测能力包括：

• 链路级日志（query、召回、重排、上下文、生成）
• 指标统计（分桶错误、召回命中、忠实性）
• 失败案例留存和回溯

没有这些，系统就只能“看起来坏了”，却不知道为什么坏。

三、可回退性能力

生产系统必须有可回退路径，否则任何优化尝试都会变成高风险操作。

典型回退能力包括：

• 版本回滚
  可以快速切回上一版索引或策略

• 多路兜底
  例如回退到纯检索、纯搜索、或者只返回证据

• 配置开关
  让关键策略可以快速关闭或降级

没有回退能力，系统就很难稳定迭代。

四、可进化性能力

这类能力决定系统能不能持续进化，而不是“上线后就冻结”。

典型包括：

• 评测集持续更新
  把线上失败样本回流进评测集

• 实验与回归验证
  每次优化都能复现、可对比

• 模型与检索策略的可替换性
  避免系统被锁死在单一路径

没有进化能力，系统即使上线也很容易原地停滞。

一份更实用的“生产能力清单”

如果你要做一个能上线的 RAG 系统，至少应该能回答这些问题：

• 权限和租户边界是否贯穿检索与生成？
• 新旧文档版本是否能严格区分？
• 线上问题能否快速回溯到召回结果？
• 出现退化时能否快速回滚？
• 是否有稳定评测集和回归验证？
• 是否能在不重构系统的前提下调整策略？

如果这些问题回答不了，系统就很难称为“生产级”。

一个最小能力结构示意

production_capabilities = {
    "control": ["permission_filter", "versioning", "safety_guardrails"],
    "observability": ["trace_logs", "bucket_metrics", "failure_review"],
    "rollback": ["index_versioning", "config_flags", "fallback_modes"],
    "evolution": ["eval_loop", "experiment_tracking", "strategy_swap"]
}

这个示意的重点不是字段名，而是让你把能力按类别组织起来。

一句话总结

能上线的 RAG 系统，核心不是主链路多复杂，而是是否具备可控、可观测、可回退和可进化这些工程能力。它们决定系统能不能真正稳定运行。