什么才算真正能上线的 AI 系统

很多 AI 系统在 demo 里跑得很顺，上了生产环境就开始出问题。两者之间的差距，不是模型质量的问题，而是系统工程和运营设计的问题。

demo 和生产环境的差距

demo 是为最好的情况设计的。输入是干净的，场景是提前准备好的，数据是整齐的，没有人在看出错的时候会发生什么——因为在 demo 里出错的情况根本不会出现。

生产环境恰恰相反。输入是混乱的、不可预测的。场景的种类比你能提前想到的要多得多。数据会迟到、格式错误、甚至完全缺失。系统会不断出错，而每次出错都需要有人能知道发生了什么、为什么会这样、该怎么修。

一个 demo 跑得通但生产环境跑不住的 AI 系统，失败的原因不是模型不够好，而是围绕模型构建的系统从来没有被设计成能处理真实工作条件的样子。

团队在评估 AI 系统是否可以上线时，通常只问一个问题：它能给出正确的输出吗？

这个问题问错了，至少是问得不完整。输出的正确性很重要，但它只是生产可用性的一个维度。一个系统在测试里输出正确，在生产环境里仍然可能完全不可用—— 如果它无法可靠地回答下面这些问题。

每个语言模型都会给出错误的输出。在 demo 里，一个错误的回答是一个有趣的边缘案例。在生产环境里，一个错误的回答可能把客户路由到错误的团队、批准一个本该被拒绝的请求、或者起草一份包含错误信息的文件。系统需要一套处理这种情况的方案，而不是依赖模型永远不出错。

生产系统依赖外部服务：API、数据库、文档存储、认证系统。任何一个都可能变慢、不可用、或者返回意料之外的数据。系统需要优雅地处理这些失败，而不是把它们悄悄传导进模型的输入或输出里。

如果系统做了一个决定但没有人能解释为什么，这不只是一个调试问题，而是一个运营信任问题。运营人员需要能够查看某个具体案例，了解模型看到了什么输入、做了什么决定、执行了什么动作、最终结果是什么。

有些决定不应该被自主执行—— 要么因为风险太高，要么因为置信度太低，要么因为这个案例超出了系统被设计来处理的范围。系统需要知道什么时候到了这类决定，并做出正确的路由。

生产可用性不是一个单一的功能，而是系统在接触真实工作之前必须具备的一组属性。

系统执行的每一个有意义的动作都应该产生日志记录。不只是成功和失败，而是完整的执行追踪：检索了什么上下文，模型收到了什么，模型返回了什么，执行了什么动作，最终结果是什么。这个追踪记录是让系统可调试、可审计、以及让运营人员真正信任它的基础。

可观测性不是锦上添花，而是运营信任的地基。没有它，运营人员是在盲飞。当出了问题——而且一定会出问题—— 就没有办法理解发生了什么，也没有办法防止它再次发生。

系统应该知道哪些案例它能有把握地处理，哪些案例它处理不了。这需要明确的设计：什么信号表示置信度低，置信度低于阈值时会发生什么，谁或者什么系统会接收到升级的案例。

这和让模型说"我不确定"不是一回事。模型在评估自己的不确定性方面出了名地不可靠。置信度阈值需要被设计进围绕模型的系统里，而不是委托给模型自己去判断。

对于任何一个错误代价显著的工作流程，应该至少有一个节点让人工在系统产生不可逆结果之前复核它的工作。这不是 AI 的局限性，而是一个设计良好的运营系统本来就应该有的属性。

人工介入节点还有第二个作用：它们产生有标注的数据。每一个人工复核的案例，都是一次你能知道系统对不对的机会。这些数据是你用证据而不是猜测来持续改进系统的方式。

系统需要明确的逻辑来处理出错的情况：检测失败而不是静默地吞掉它，决定是重试、升级处理还是停止，带着足够的上下文记录失败以便排查，并让工作流程处于一个已知的状态，而不是一个模糊的中间状态。

一个在中途静默失败的工作流程，往往比一个从来没有启动的工作流程更糟糕，因为它创造了一个需要有人手动识别和清理的不一致状态。

系统应该有一个清晰定义的运营边界：它被设计来处理哪类输入，它被允许执行哪类动作，以及在什么条件下它会停止并路由到人工。没有被明确定义的范围往往会隐性扩张，这就是系统最终开始做它从未被设计来做的决定的原因。

在条件允许的情况下，系统执行的动作应该是可撤销的，系统在两种方式都可行时应该优先选择可撤销的动作。当不可逆是不可避免的，系统在继续执行之前应该要求人工确认。

生产可用性还有一个容易被低估的基础设施维度。一个跑在 notebook 里或者简单 API 封装上的系统不是生产基础设施。生产基础设施意味着：系统能承载它将面临的真实负载，在组件不可用时能优雅降级，有部署和回滚流程，对性能和错误率进行监控，并且有人对它的运营健康状况负责。

这些都是标准的软件工程问题，但在 AI 项目里往往被当作事后的补丁，因为注意力一直放在模型上。模型只是一个组件，系统的其余部分需要用同样的严谨态度来工程化。

在把任何 AI 系统接入真实的业务工作流程之前，它应该能通过一个基本的生产可用性检验。

你能展示两周前某个具体案例的完整执行追踪吗？如果不能，可观测性缺失。

你能展示系统遇到它没有被设计来处理的案例时会发生什么吗？如果它给出一个自信的错误回答，升级逻辑缺失。

你能展示在某个不可逆动作被执行之前人工复核了系统工作的节点吗？如果不能，人工介入节点缺失。

你能展示上一次依赖服务失败时发生了什么吗？如果答案是不知道，失败处理缺失。

你能展示系统被允许和不被允许做什么的明确边界吗？如果没有写在任何地方，范围控制缺失。

如果上面任何一个问题无法被清楚地回答，这个系统还没有准备好上生产。它只是准备好了做 demo。

demo 和生产系统之间的差距，不是靠让模型变得更聪明来弥合的。而是靠用同等的工程严谨性来设计围绕模型的系统—— 就像你对任何会影响真实业务结果的软件所应该做的那样。

这比大多数 AI 项目给自己设定的标准要高。但当系统在真实工作上运行、影响真实决策、被真实的人信任时，这也是唯一真正重要的标准。