AI 驱动型 API 的行为 SLA：为非确定性输出编写协议

你的支付服务拥有 99.9% 的可用性 SLA。请求要么成功，要么以文档记录的错误代码失败。当出现故障时，你清楚地知道哪里出了问题。

现在，想象你发布了一个封装了 LLM 的智能发票解析 API。在一个周一早晨，你最大的客户打来电话：“你们的 API 返回了一个有效的 JSON 对象，但在涉及外币的发票中，total_amount 字段的值差了十倍。” 你的服务返回了 HTTP 200。你的可用性仪表板显示绿色。根据每一个传统的 SLA 指标，你都没有违反任何规定。但你确实搞砸了——而且在契约语言中，你甚至找不到词汇来描述到底哪里出了错。

这就是当今大多数 AI API 部署的核心鸿沟。管理你的 API 承诺 的契约为确定性系统而写，而 LLM 并非确定性系统。

为什么传统的 API 契约对 LLM 失效

传统的 API 契约很简单：给定输入，在特定延迟内、特定可用性下产生特定输出。契约是二元的——要么满足，要么违反——且违反会体现为错误。

LLM 违反了所有这三个前提：

非确定性是结构性的，而非 bug。 即使在 temperature 为 0 的情况下，跨硬件和并发执行时，相同的输入也会产生略有不同的输出。OpenAI 已公开承认，“基本确定”是他们能保证的极限。这意味着你无法编写一个声明“始终返回 X”的契约——只能编写一个声明“返回 X 分布中的内容”的契约。

失败通常是无声的。 当 LLM 生成了一个语法有效但在语义上错误的响应时——一个幻觉出的数字、一个分类错误的实体、一个看似合理但错误的条款——不会触发任何错误。HTTP 200 会正常进入消费者的收件箱。传统的监控看到的是一个健康的 API；而消费者看到的却是损坏的数据。

行为包络（Behavioral envelope）在无通知的情况下发生偏移。 提供商的模型更新可能会改变响应风格、冗长程度、拒绝行为和输出结构，而无需任何 API 版本升级。当 OpenAI 将 GPT-5.1 的默认推理设置从“中（medium）”更改为“无（none）”以获得更快的响应时，那些依赖该推理深度的系统，其背后的行为契约就被悄无声息地打破了。

解决方案不是假装 LLM 是确定性的，而是构建一种新型契约，在承认 AI 输出的概率特性的同时，仍为消费者提供有意义的依赖基础。

行为级 SLA 的四大支柱

行为级 SLA 从四个维度定义了消费者可以可靠地从 AI 驱动的 API 中获得什么：

1. 格式保证

这是最容易处理的维度。现代 LLM 提供商现在支持约束解码（constrained decoding）——一种在生成时屏蔽无效 token 的技术，使得违反 schema 在结构上变得不可能。OpenAI 带有 strict: true 的结构化输出、Anthropic 的结构化输出（2025 年 11 月发布）以及 Google Gemini 的 response_schema，在正确使用时都能保证 100% 符合 JSON schema。

因此，你的行为级 SLA 可以包含硬性的格式保证：“此端点始终返回符合以下 schema 的 JSON 对象。字段类型得到保证。不会出现未知字段。” 这是一个你可以遵守的承诺，消费者可以据此构建解析器，而不必防御性地处理畸形响应。

关键提醒：约束解码保证的是**句法（syntactic）一致性，而非语义（semantic）**正确性。一个有效的 JSON 对象完全可能包含错误的数值。格式保证是必要的，但并不充分。

2. 延迟承诺

LLM API 的延迟是双模态的：首标记时间 (TTFT) 衡量生成开始的速度，而总生成时间取决于输出长度。行为级 SLA 需要指定这两者，因为某些消费者比完成速度更在意响应速度。

实际的承诺如下所示：“对于 4,000 token 以下的输入，TTFT p95 < 800ms。对于 500 token 以下的输出，总响应时间 p95 < 4s。” 这些数字需要来自实际的生产测量，而不仅仅是供应商的保证——2026 年各提供商的实测可用性在 99.3% 到 99.8% 之间，其延迟波动幅度远大于其宣传数据。

跟踪你自己的 p50/p95/p99，而不是依赖提供商的仪表板。行为延迟漂移——即你的 API 在几周内缓慢变慢——不会出现在提供商的状态页面上。

3. 拒绝率与内容策略预算

当你的 API 封装了具有内容策略的 LLM 时，一部分合法的生产请求将被拒绝。这不是 bug，但必须在契约中进行量化。

拒绝预算如下所示：“对于符合文档化输入 schema 的输入，此端点的测定拒绝率 < 2%。拒绝时始终返回 422 状态码及机器可读的原因代码。” 这使消费者能够围绕已知的分布构建重试逻辑、后备路径和容量规划。

将拒绝率作为时间序列进行跟踪。提供商的安全微调更改可能会显著改变你的拒绝基准，而无需任何 API 版本更改——如果消费者不知道基准，他们就无法检测到这种变化。

4. 幻觉预算

这是最难定义的维度，但也是最需要承认的一个维度。幻觉预算是一份明确的声明，承认一定比例的输出会在文档记录的范围内出现语义错误。

对于结构化数据提取端点：“在我们的验证基准测试中，数值字段的测量准确率为 97.3%。实体识别在测试集上的 F1 分数达到 94.1%。这些数值会随着每次模型更新重新评估，并发布在我们的发行说明中。”

发布幻觉预算可以起到三个作用：它迫使你实际测量准确率；它与消费者建立诚实的预期；它创建了一种问责机制——当你的准确率下降时，你有一个公开的数值可以进行对比。

为非确定性行为进行版本管理

AI API 设计中最深层的工程问题是行为包络（Behavioral Envelopes）的语义化版本管理。当输出分布发生偏移时，什么才算破坏性变更？

Anthropic 的方法提供了一个有用的参考模型。他们将版本分为：

• 快照版本（claude-3-5-sonnet-20241022）：行为冻结，保证稳定，发布后永不更新。
• 滚动别名（claude-sonnet-4-5）：自动升级到最新的改进版本，适合那些认为能力优先于稳定性的团队。

这可以清晰地映射到你自己的 API 设计中。公开两个层面：

稳定的行为端点锁定到特定的模型快照和特定的提示词版本。消费者通过指定版本标识符来选择使用。你承诺不会改变该版本的行为包络。当你弃用它时，你需要提前 90 天通知。

最新端点提供当前最强的能力，但不保证行为冻结。对此应进行明确记录：“此端点使用我们最新的模型和提示词。行为包络可能会随模型更新而改变。对于需要可复现性的生产负载，请使用稳定端点。”

核心洞察在于，行为版本管理必须捕获的不仅仅是模型——它需要考虑到提示词版本、工具可用性（通过 MCP 或函数调用）以及 API 功能标志。即便底层模型权重没有变动，一个改变输出风格的提示词微调也属于行为变更。

监控行为漂移

传统的 API 监控关注错误、延迟峰值和可用性。对于 AI API，你需要第三类监控：行为漂移监控。

行为漂移是指你的 API 继续返回带有有效 JSON 的 HTTP 200 响应，但输出的 分布 发生了对消费者产生影响的偏移。检测这一点需要：

基于嵌入的语义监控。 对生产输出进行采样并将其嵌入（Embedding）。跟踪嵌入分布质心随时间的变化。即使所有结构检查都通过，质心的突然偏移也预示着行为漂移。

LLM 即评审员（LLM-as-judge）评估。 将生产请求-响应对的样本运行在评估模型中，根据你记录的行为契约进行打分。将此分数作为时间序列进行跟踪。在任何消费者投诉之前，分数下降是一个领先指标。

黄金数据集的回归测试。 维护一套精选的输入-输出对，代表规范的正确行为。在每次模型更新或提示词更改时运行此集合。在发行说明中报告通过率。

关于运行时行为契约强制执行的研究发现，实施这一层可以使契约满意率提升 18.7 个百分点，并将静默失败率降低 12.4 个百分点——而每次请求的中位开销仅为 27ms。信号是真实的，成本是可控的。

模型更新的迁移指南

当模型更新改变了你的行为包络时——即使你已经做对了一切——你也需要一个迁移消费者的指南。

在沟通之前对变更进行分类。 并非所有的行为偏移都是破坏性的。一个变得更加简洁的响应是行为变更，但可能不是破坏性的。结构化输出中字段名称的更改则是破坏性的。在压力之下需要应用这些分类之前，先制定内部标准。

先发布，后部署。 行为发行说明应在模型更新进入生产环境前至少两周发布。内容包括：更改了什么、你重新测量的行为指标（幻觉率、拒绝率、延迟）以及哪些消费者最可能受到影响。

监测客户端影响。 如果你有消费者如何使用 API 的遥测数据，请识别哪些消费者调用的端点最容易受到变更影响。主动联系，而不是等待投诉。

提供影子模式期。 在正式切换之前，允许消费者调用影子端点，该端点将旧行为和新行为作为并行字段返回。这让他们在强制迁移之前针对自己的负载进行验证。

分阶段弃用。 在新版本发布后，保留旧的行为快照 90 天。不要在季度业务审查冻结期或高流量期间停止支持（EOL）旧版本。

处理行为迁移表现出色的团队会像对待数据库模式迁移一样对待它们——拥有同样的严谨性、同样的提前通知以及在定义的时间窗内维护向后兼容性的意愿。

你的 API 文档需要包含的内容

大多数 AI API 文档涵盖了身份验证、端点和参数。行为级 SLA 文档则需要额外的部分：

• 行为保证表：针对每个端点，明确保证了四大支柱中的哪些以及具体水平。
• 实测准确率指标：来自你验证基准测试的实际数字，并附带方法论说明。
• 版本矩阵：哪些模型快照、提示词版本和功能标志对应于每个稳定的行为版本。
• 行为变更日志：行为包络（behavioral envelope）每一次变更的记录，并按严重程度分类。
• 已知局限性：准确率数字不适用的情况（特定输入类型、边缘情况、语言）。

编写这些文档会让人感到不适，因为它迫使你发布自己必须负责的数字。这种不适感正是关键所在。如果你无法定义你的 AI API 保证了什么，你的客户就无法在之上安全地构建应用 —— 并且他们会在生产环境中以惨痛的方式发现这一点。

通过透明度建立信任

在 AI API 市场中获胜的公司，不是那些孤立地拥有最高准确率或最低延迟的公司。而是那些能让客户清楚知道自己将获得什么，并能据此进行规划的公司。

Gartner 预计，到 2028 年，60% 的软件工程团队将采用正式的 AI 可观测性实践，高于 2025 年的 18%。麦肯锡 2025 年的调查发现，51% 使用 AI 的组织已经经历过 AI 不准确带来的负面后果。信号很明确：团队正在耗费大量精力去调试那些本应预见到并根据合同进行约束的 AI 故障。

行为级 SLA 不是合规性的勾选框 —— 它们是在 AI 之上构建行为足够可预测、足以令人信服的软件系统的基础。从格式保证（最容易实现的）开始，增加延迟承诺（你自己的测量值，而非供应商仪表盘），诚实地发布拒绝率和准确率基准，并构建在客户发现之前就能检测到漂移的工具。

确定性的 API 合约并未消亡 —— 它只是还不完整。扩展它，AI 驱动的 API 就能成为工程师真正可以用来构建可靠系统的基石。