隐性 API 契约：你的 LLM 供应商没有写在文档里的那些事

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

SLA 实际覆盖的范围（以及未覆盖的范围）

仔细阅读任何主流 LLM 供应商的 SLA，你会看到以下保证：

• HTTP 端点可用性（通常为 99.5–99.9%）
• 延迟百分位数（首个 Token 到达时间、每秒 Token 数）
• 速率限制执行（每分钟请求数和 Token 数）
• 响应包装的 JSON 结构正确性——包含 choices、usage 和 finish_reason 的 JSON 外层结构

而你不会看到以下保证：

• 任何具体提示词的输出质量
• 模型更新后的指令遵从保真度
• 响应长度一致性
• 格式稳定性（即便有明确的格式化指令）
• 拒绝边界行为
• 所有条件下 JSON 模式的正确性
• 工具调用 Schema 的遵从情况
• temperature=0 时的确定性输出

供应商可以报告 99.9% 的 API 正常运行时间，同时提供行为已退化的模型。这两者是分开衡量的，而这一区别很少出现在营销材料中。

实际后果：斯坦福大学/加州大学伯克利分校的一项研究追踪了 2023 年仅三个月内 GPT-4 的表现，发现其在质数识别任务上的准确率从 84% 下降至 51%，生成的可直接执行代码比例从 52% 下降至 10%。这些变化均未被公告。API 在整个期间一直正常运行。

工程师依赖但未被文档化的五种行为

Temperature 0 并非确定性的。 工程师通常假设 temperature=0 每次都产生相同输出——事实并非如此。主流供应商只在小字中承认这一点——Anthropic 的文档声明即使在零温度下输出也不会"完全确定"。原因包括：GPU 归约顺序引发的浮点数非确定性、混合专家架构中的批次方差，以及跨服务器池的负载均衡。研究证实，即使在所谓的确定性设置下也存在令人担忧的变异性。如果你的系统围绕确定性 LLM 行为构建工作流，那你的基础假设是错误的。

长上下文在触及限制之前就已降级。 供应商宣传 1M Token 上下文窗口。但他们不发布任何质量曲线，来说明输出在接近该限制时如何降级——或者远在达到该限制之前就如何降级。一项对 18 个前沿模型的研究证实，当相关信息位于上下文中间而非开头或结尾时，多文档检索任务的性能下降超过 30%。这种"中间遗失"效应是 Transformer 注意力机制的结构性产物，而非漏洞，但 API 文档中对此只字未提。

JSON 模式不保证有效的 JSON。 这些具体的失败模式已被从业者充分记录，却未出现在官方文档中：在 max_tokens 处截断会静默产生带有 finish_reason=length 的不完整 JSON；深度嵌套的 Schema 会导致模型跳过必填字段；约束解码在某些 Token 组合上会进入无限循环。一个团队仅通过将每次调用的工具数从五个限制为两个，就将无效函数调用参数率从 12% 降至 2.1%——这是从观察中得来的调优洞察，而非文档指导。

系统提示词对长对话的影响会衰减。 Transformer 对上下文开头和结尾附近的 Token 给予更多注意力权重（首因和近因偏差）。在一个 50 轮对话中第一个位置的系统提示词中的指令，对模型输出的影响，明显小于在两轮对话中第一个位置的相同指令。这影响拒绝边界：模型可能在会话开始时拒绝某个请求，但在大量上下文稀释了系统提示词的影响后才予以回应。这种效应的量级以及其变得显著的对话长度阈值，均未被文档化。

锁定的模型版本并非冻结的。 供应商提供带日期的模型快照以实现可复现性（例如 gpt-4-turbo-2024-04-09）。隐含假设是锁定的标识符意味着锁定的行为。实际上，供应商已在不更改标识符的情况下修改了带日期快照内的行为。2025 年 4 月，当 OpenAI 在没有公告或更新日志条目的情况下推送 GPT-4o 更新时，从业者将这种现象命名为"LLM 漂移"——在版本字符串不变的情况下发生行为变化。一项关于 API 更新中提示词回归的研究发现，58.8% 的提示词-模型组合出现了准确率下降，其中 70.2% 的回归超过 5% 的准确率损失。

静默行为变化如何破坏生产系统

故障模式在各类事故中高度一致：一个应用正常运行数周或数月，然后悄然开始产生错误或格式不符的输出。用户比监控系统更早发现——因为大多数团队对 API 层（错误、延迟、速率限制）进行了埋点，但对行为层（输出质量、格式合规性、指令遵从情况）却没有。

回归研究发现，63.8% 的行为回归发生时，模型对其答案表达了高置信度。模型的确定性并不是行为稳定性的信号。即使整体准确率看起来稳定，个别预测也会从正确翻转为错误——这意味着顶层指标可能掩盖了用户实际遇到的边缘案例中的局部故障。

2025 年 8 月，当 Google 悄然从 Gemini 中移除一个内部处理层时，从业者将其描述为"没有提前通知的糟糕根本性变化"。另一个 bug 报告记录了 UI 显示一个模型版本，而后端静默提供另一个版本，在开发者不知情的情况下消耗配额。

共同模式：供应商更新模型以改善总体基准测试结果、降低计算成本或调整安全姿态。这些变化中的任何一个都可能改变你的应用所依赖的行为特征。API 保持正常运行，而你的应用在静默降级。

针对行为声明编写集成测试

传统软件测试方法不适用于 LLM API。断言精确输出相等性的测试套件在任何非确定性系统上都会立即失败。但另一个极端——完全不进行自动化测试——则让行为回归只能靠用户投诉来发现。

正确的模型是行为测试套件：一组精心挑选的提示词，配以结构性断言和 LLM 评分的质量检查。

结构性断言测试那些无论随机变异如何都应成立的属性：

• finish_reason 不为 length（输出未被截断）
• JSON 输出根据目标 Schema 验证通过（必填字段存在，类型正确）
• 响应长度在预期范围内
• 特定必须出现的字符串出现在输出中
• 特定禁止出现的字符串不出现

这些是确定性检查，不需要对"正确性"作出判断——它们要么通过，要么失败。

LLM 作为评判者的断言处理那些不存在单一正确答案的语义属性。使用一个独立的、稳定的、锁定版本的模型作为自动评估器，运行基于评分标准的评估：忠实度、相关性、语气、指令遵从情况。关键是将评判模型与被测模型分开，并根据固定的评分标准运行。

基线比较将这些整合在一起。针对当前生产模型配置运行完整测试套件并存储总体分数。当供应商宣布新模型版本时——或当你怀疑存在静默行为漂移时——在将生产流量路由到新配置之前，针对新配置运行相同套件并对比结果差异。

这与数据库迁移测试的规范相同：在针对预发布环境运行迁移并确认应用断言仍然成立之前，你不会将迁移推送到生产环境。对于 LLM，"迁移"是任何模型更新，"预发布环境"就是你的行为测试套件。

实现此工作流程的工具：promptfoo（开源，支持 CI/CD 集成）、DeepEval 和 LangSmith。promptfoo 专门支持基线比较——在变更前运行，进行变更，再次运行，然后对比回归情况。

在生产环境中监控漂移

行为集成测试在部署时运行。持续监控捕获供应商在你的部署之间更改行为的情况。

核心埋点：随时间跟踪输出特征作为时间序列指标，而不仅仅是单次请求错误。具体来说：

• 每次响应的 Token 数 —— 长度漂移是行为变化的早期信号。研究发现模型版本间响应长度有 23% 的变异，其中一个格式化任务在更新版本中 Token 数增加了 65%，而模型同时忽略了格式要求。
• 格式合规率 —— 通过 JSON Schema 验证或包含必要结构元素的响应比例
• 指令遵从分数 —— 由第二个 LLM 对生产流量的样本进行评分
• 金丝雀提示词套件 —— 一组固定的黄金提示词按计划针对生产端点运行，输出嵌入向量跟踪与基线的余弦漂移

对这些时间序列应用统计过程控制。CUSUM（累积和）检验和贝叶斯变点检测在达到投诉阈值之前就能发现阶跃变化和渐进漂移。检测目标是 24 小时内 5% 的指标下降，而不是三周后用户工单反映的 30% 下降。

目标是让行为漂移成为一个可靠性事件，具备与延迟峰值相同的可观测性——被你的监控系统捕获并告警，而不是由用户报告。

与供应商谈判的内容

隐性契约在一定程度上是市场失灵的产物：供应商不在行为稳定性保证上竞争，因为大多数买家不要求这一点。这为了解该要求什么的从业者创造了谈判空间。

谈判企业合同时：

• 至少 90 天的弃用通知期，针对模型版本。一些供应商自愿提供这一点；将其写入合同。
• 生产工作负载的版本锁定选项。你希望能够在更新版本成为默认版本后，仍然使用特定的模型标识符。
• 模型更新的行为更新日志。并非所有供应商都发布这一内容，但有些在企业层级提供——而提出请求本身就创造了问责机制。
• 模型可用性与 API 端点可用性的独立 SLA 衡量。供应商应能够独立于 HTTP 正常运行时间指标告知你模型降级率。

这些内容在现成的 API 计划中均非标准配置。但在企业规模下，这些都是可以谈判的，而且它们都能缩小隐性契约的暴露面。

根本性的视角转变

传统 API 可靠性工程是让你的系统对供应商中断具备弹性。LLM 可靠性工程是让你的系统对供应商的常态具备弹性——即一个正在运行、响应正常的 API，可能正在产生与上个月微妙不同的输出。

这要求将模型的行为特征视为可变依赖项，而非固定依赖项。你的提示词就是集成代码。你期望的输出格式就是行为契约。你的监控应该跟踪这些契约在生产环境中是否得到遵守，而不仅仅是 HTTP 端点是否在响应。

构建出弹性 LLM 应用的工程师，不是那些拥有最聪明提示词的人。而是那些对自己无法控制的事情进行埋点的人。