AI 应用的 SLA 为什么越来越难写:因为你在给一个会说谎的系统做稳定性承诺

     传统软件的 SLA 是在写一份合同，AI 应用的 SLA 更像在写一份天气预报——你知道大概率会怎样，但你无法保证每一次。这个区别，正在让很多工程团队在生产环境里碰壁。   

     有一类问题，表面看起来是技术问题，实质上是认知问题。AI 应用的 SLA 怎么定，就是这类问题的典型。大多数团队在第一次碰壁之前，都会低估它的难度——不是因为他们技术不行，而是因为他们用了一套错误的参照系。   

     从「确定性系统」到「概率性系统」，工程师的世界观要换一遍   

     传统软件工程有一个基本假设：相同的输入，给出相同的输出。这个假设如此根深蒂固，以至于整个工程体系——单元测试、回归测试、版本管理、监控告警——都建立在它之上。你写一个排序函数，跑一遍测试，通了就是通了，明天还是通的。   

     AI 系统打破了这个假设。相同的输入，不保证相同的输出。温度参数、上下文长度、模型版本的悄悄更新、底层推理框架的细微变化——任何一个因素都可能让结果漂移。这不是 bug，这是特性。但问题是，整个工程体系还没有为「特性」级别的不确定性准备好配套工具。   

●这就是 AI 应用 SLA 难写的根本原因：你在给一个概率系统做确定性承诺。   

     demo 能跑通，和系统能上线，中间隔着一个峡谷   

     很多团队踩的第一个坑，是把「demo 能跑通」当成「工程化能力」。这两件事之间的距离，比大多数人想象的要大得多。   

     一个 demo 只需要在理想样本上表现好。一个生产系统需要在脏数据、极端输入、上下游超时、权限越界、并发压力下依然守住边界。更麻烦的是，AI 系统的失败往往不是崩溃，而是「悄悄给出了一个错误结果」。传统系统报错，你能看见；AI 系统给出一个看起来合理但实际上有问题的答案，可能在业务链路里走了好几步才被发现——错误被放大，代价被延迟。   

     4   

     AI 系统工程上的关键分层：模型层、编排层、数据层、治理层   

     理解 AI 系统的工程复杂度，有一个有用的框架：把它拆成四层。模型层决定能力边界，编排层决定任务如何拆解与调用，数据层决定系统能看到什么，治理层决定出了错如何追踪、如何回滚、如何限制权限。接 API 只是触碰了模型层的皮毛，真正的工程工作从编排层开始，在治理层见真章。   

     真正拖慢上线的，不是模型，是验证机制   

     问过几个做过 AI 应用落地的工程师，他们几乎都提到同一件事：最初以为难点在模型调优，后来发现真正拖时间的是验证体系没建起来。   

     这很好理解。传统系统的验证相对简单——你知道正确答案长什么样，写断言就行。AI 系统的验证要复杂得多：正确答案本身可能是模糊的，不同评测维度之间可能相互矛盾，而且今天通过的评测，不代表下周模型悄悄更新之后还能通过。没有持续验证，系统今天可用不代表下周还可用。这不是危言耸听，而是很多团队已经经历过的真实情况。   

「

     判断一个 AI 系统是否成熟，不要先看它最好的结果，要看它最差的时候能守住什么边界。   

」

     失败是常态，工程护栏才是核心资产   

     生产级 AI 系统有一个反直觉的设计原则：不要假设系统会成功，要假设它会失败，然后设计好失败的处理方式。   

     这意味着什么？意味着熔断逻辑要提前写，不是等故障出现了再补。意味着哪些结果不能直接输出给下游，要在架构设计阶段就想清楚。意味着每一个关键操作都要留痕，不是为了审计，而是为了在出问题时能重放、能对比、能定位。这些东西看起来不性感，但它们才是让模型能力变成生产能力的真正载体。   

     有一个判断工程成熟度的简单问题：如果系统今晚出了问题，你能在一小时内定位到根因吗？如果答案是「不确定」，那 SLA 大概率还不具备承诺的基础。可观测性不是锦上添花，它是上线资格的前提条件。   

     AI 工程的门槛并没有因为工具变多而降低，只是门槛的形状变了——从「会不会搭系统」变成了「能不能在不稳定里维护稳定」。前者是一次性的技术挑战，后者是持续性的工程纪律。前者你学会了就会了，后者需要团队在每一次上线决策里都保持清醒。   

     ✦ 小结   

     AI 应用的 SLA 难写，不是因为技术不够成熟，而是因为我们在用为确定性系统设计的工程思维，去驾驭一个本质上概率性的东西。解法不是消灭不确定性，而是建立足够好的工程护栏——评测基线、持续验证、可观测性、失败处理——让波动在业务层面可控。谁先把这套东西建起来，谁的系统才算真正具备上线资格。