切换 API 提供商之前的 AI 模型评估：工作流程清单

切换 AI API 提供商并不是一个模型排行榜式的决策。这是一项生产变更，可能同时改变输出质量、JSON 有效性、工具调用、延迟、速率限制行为、错误处理和总成本。

最安全的方法是将拟议的切换转化为可重复的验收测试。在相同的、尽可能接近生产环境的用例上运行现有方案和候选方案，对完整的工作流程结果进行评分，在看到结果之前定义硬性迁移门槛，并在可随时回滚的路径后逐步暴露候选方案。

本指南为你提供这一流程，包括评分卡、数据集设计、兼容性矩阵、配对测试方法、成本公式、发布阶段以及决策备忘录。

简短答案：使用提供商切换验收测试

在将生产流量迁移之前，要求候选路径通过五项检查：

1. 工作流程质量：它能在具有代表性的输入上以可接受的成功率完成用户任务。
2. 契约兼容性：结构化输出、工具调用、流式传输、错误和结束状态都能与你的应用正常配合。
3. 运行可靠性：延迟、超时、速率限制、重试和并发仍保持在你的服务目标范围内。
4. 经济价值：每个已接受任务的有效成本有所改善，或者仍处于批准的权衡范围内。
5. 安全发布：影子流量和分阶段金丝雀验证表明，离线结果在生产条件下依然成立。

不要因为候选方案赢得了公开基准测试、生成了少数令人印象深刻的回答，或者标称的 token 价格更低，就批准切换。这些信号可以帮助缩小候选范围，但不能证明该提供商能够运行你的工作流程。

从迁移决策开始，而不是从模型列表开始

在构建评估之前，先写下一句决策：

如果 B 在任务成功率上不劣于 A，通过所有契约门槛，满足生产延迟和可靠性预算，并且将每个已接受任务的有效成本降低所需幅度，则将工作流程 X 的路由 A 替换为路由 B。

这句话迫使团队明确范围。某个提供商可能适合信息抽取，但不适合代理式工具使用；也可能适合批量丰富，但不适合交互式助手。不要在真正的决策只关乎一条路由、一个工作负载和一个运行边界时，得出“最好的模型”这种泛化结论。

在评估计划中记录这些输入：

如果集成变更本身仍不确定，请先查看 OpenAI-compatible API gateway migration checklist 再测试模型。共享接口可以减少代码变更，但并不能让模型行为完全一致。

将评估单元定义为完整轨迹

评估单元应与客户实际体验到的内容一致。对于单轮分类器，这可能是一条请求和响应。对于代理，这可能是一整条轨迹，包含多次模型调用、工具调用、重试以及最终答案。

有用的轨迹记录包括：

{
  "case_id": "support-refund-042",
  "segment": "refund-policy",
  "input": {},
  "expected_contract": {},
  "route": "candidate-b",
  "attempts": 1,
  "latency_ms": 1840,
  "input_tokens": 3120,
  "output_tokens": 486,
  "provider_cost_usd": 0.0124,
  "schema_valid": true,
  "tool_sequence_valid": true,
  "task_success": true,
  "failure_class": null
}

这可以避免一个常见的测量错误：只评估最终文本，却忽略了格式错误的参数、重复的工具调用、隐藏的重试，或导致工作流程无法使用的延迟峰值。

构建符合生产形态的测试集

评估集应反映你计划迁移的路径的分布和故障模式。随机挑选一小堆“典型”提示词，通常会掩盖那些会引发事故的案例。

使用六类案例：

1. 高频案例： 负责大部分正常流量的输入。
2. 高价值案例： 错误答案会导致高成本人工纠正或转化流失的任务。
3. 长尾案例： 罕见语言、格式、领域或用户意图。
4. 契约案例： 对 schema、枚举、嵌套对象、工具和流式组装形成压力的输入。
5. 对抗案例： 含糊指令、相互矛盾的证据、提示注入以及不受支持的请求。
6. 运维案例： 大上下文、长输出、并发突发、超时以及提供商侧错误。

对数据集进行分层，使每个重要细分都拥有足够的示例可单独检查。一个候选方案在总体上看起来可接受，却可能在某一种语言、某一个工具或某一个客户层级上失败。

保留三层数据集：

• 开发集： 用于改进提示词和验证器的可见案例。
• 决策集： 留出案例，用于批准或拒绝迁移。
• 生产审计集： 上线后抽样获得的新案例，用于检测漂移。

不要反复用决策集进行调优。一旦团队看到了它的失败并修改了系统，这些案例实际上就已经变成了开发数据。

冻结测试条件

只有当现有方案和候选方案接收等效工作时，成对比较才有用。冻结或记录：

• 系统和开发者指令。
• 用户输入和附件。
• 工具定义和 JSON Schema。
• 温度、最大输出、在支持时的 seed，以及推理设置。
• 检索结果和文档顺序。
• 区域、API 版本、模型标识符和提供商路由。
• 重试策略、超时和并发。
• 评估时间戳和价格来源。

如果某条路由因为提供商要求而使用了不同的提示词，请为两种提示词都做版本控制，并将该差异视为迁移包的一部分。业务决策针对的是新系统，而不是脱离其集成环境的抽象模型。

让每个案例都通过两条路由运行。当人工对主观输出进行评分时，随机化或盲化展示顺序，以免评审受到提供商名称的影响。

在加权分数之前设定硬性门槛

加权分数有助于权衡取舍，但它不应允许廉价模型弥补关键合同失败。

首先定义不可妥协的门槛。示例门槛可能包括：

• 不得未经授权执行工具。
• 输出中不得包含密钥或受限数据。
• 必需的 JSON 能够解析并通过生产 Schema 验证。
• 所需语言必须保持在其最低任务成功阈值之上。
• 超时和服务器错误率保持在批准预算范围内。
• 客户端能够正确处理流式终止和提供商错误。
• 在生产暴露之前测试回滚路径。

阈值必须来自你的产品风险和当前基线。下面的数字只是示例评分卡，并非通用建议：

在最终运行之前公布权重和门槛。结果出来后再修改它们，会让评估变成辩解。

在使用模型评审器之前，先对客观目标进行检查

尽可能使用确定性验证器：

• JSON 解析和 JSON Schema 验证。
• 精确或归一化的字段匹配。
• 数值容差检查。
• 引文和 URL 验证。
• 允许的工具和参数验证。
• 工具顺序和最大步骤检查。
• 代码编译、单元测试和沙箱执行。
• 策略规则和禁用内容检测器。
• 检索证据覆盖率。

对于无法简化为确定性检查的标准，例如清晰度、语气、综合能力，或回答是否遵循细微指令，应使用人工评审或基于模型的评分器。

在使用模型评分器时：

1. 给它一个包含可观察通过条件的窄范围评分标准。
2. 用人工评分样本对其进行校准。
3. 在可能的情况下隐藏提供商身份。
4. 保留评分器提示词、模型版本和原始理由。
5. 将分歧和边界案例交给人工评审。

OpenAI 的评估指南建议使用任务特定评估和持续评估，而 Anthropic 也建议定义可观察的成功标准并围绕这些标准构建评估。实际含义很简单：你的评分标准应该描述你需要的工作流程结果，而不是泛泛的智能。

比较成对结果和不确定性

仅看平均分可能会掩盖不稳定性。由于两条路线处理的是相同案例，应逐个案例进行比较。

对于二元任务成功，创建一个成对表：

这两组分歧尤其有用。在批准切换之前，先人工审查并分类根本原因。

为了得到可用于决策的结果，请围绕任务成功率、成本和延迟的差异报告置信区间。基于 case ID 的 bootstrap 是一种实用方法，因为它可以在不假设每个指标都服从正态分布的情况下保留配对结构。

当候选方案带来明确收益时，例如更低的成本或更好的区域可用性，并且产品可以容忍一个有界的小幅质量差异时，请使用非劣效规则。在测试前先定义允许的边际。只有当置信区间没有跨过不可接受的回归边界时，才予以批准。

同时也要按分段检查结果。整体通过不应掩盖某个合同案例、语言、工具或高价值工作流的失败。

使用追踪级失败分类法

每个失败案例都应归入一个主要失败类别。统一的分类法会把评估工作变成工程工作，而不是围绕轶事展开争论。

同时跟踪首次失败和最终追踪结果。即使重试恢复了请求，也仍然会消耗时间和金钱，而反复恢复会演变成生产容量问题。LLM 速率限制指南解释了如何区分 RPM、TPM、排队、重试和回退行为。

将提供商兼容性作为矩阵来测试

OpenAI 兼容端点可以减少迁移工作量，但兼容性并非二元的。请测试你的应用实际使用的精确功能。

例如，Google 的结构化输出文档指出，schema 支持基于 JSON Schema 的一个子集。这就是为什么你应该测试你的实际 schema，而不是假设某个提供商接受的 schema 在所有地方都会表现一致。

计算每个被接受任务的有效成本

token 价格只是迁移经济性的一部分。衡量获得可用结果的完整成本：

每个被接受任务的有效成本 =
  (模型使用成本
   + 重试
   + 回退使用成本
   + 工具和检索成本
   + 评估或审核调用成本
   + 递增基础设施成本)
  / 被接受任务数

同时估算由低置信度或格式错误结果带来的人工审核成本。如果某个候选方案会增加重试、工具循环、审核队列或被拒绝输出，即使 token 更便宜，它也可能更昂贵。

有关当前路由价格，请以 AI API 价格比较 作为起点，然后在决策时确认确切的模型和价格。请将定价时间戳与结果一起保存，因为价格和模型可用性可能会变化。

不仅要报告总体成本，也要按分段报告。长上下文场景、多语言任务、图像输入和 agent trace 可能会与短文本请求得出不同的赢家。

在真实重试策略下对候选方案进行压力测试

离线质量测试通常运行缓慢且是串行的。生产环境不是这样。

在预期并发和峰值并发下重复一部分代表性测试。测量：

• 端到端 trace 延迟的 p50、p95 和 p99。
• 在流式传输重要时，到首个 token 的时间以及完成时间。
• 队列时间与提供商时间的对比。
• 限流响应以及 Retry-After 行为。
• 超时、连接失败和上游 5xx 错误。
• 重试次数和重试恢复率。
• 由重试的工具操作导致的重复副作用。
• 回退频率和最终成功路径。

使用与生产环境计划相同的有界重试行为。无限重试会让成功率看起来很高，但同时违反延迟和成本限制。如果候选方案需要明显不同的重试或队列设置，请将该运维变更纳入迁移决策。

在 Canary 之前先运行影子流量

影子测试会将符合条件的生产输入副本发送给候选方案，而现有方案仍然为用户提供服务。它能揭示真实的提示词分布和提供商行为，同时不让候选输出影响客户。

保护影子路径：

• 除非候选方案的数据控制已获批准，否则排除敏感流量。
• 禁用会产生副作用的工具，或将其路由到 mock。
• 在需要时对受限字段进行脱敏或令牌化处理。
• 限制影子流量和成本上限。
• 保持现有方案与候选方案的 trace ID 关联，以便进行配对分析。
• 不要让影子重试消耗主路径的容量预算。

影子结果应使用与离线决策集相同的验证器和失败分类法进行评估。

分阶段对提供商切换进行 Canary

在离线和影子门禁通过后，向一小部分可观测流量开放。一个实用的顺序是：

1. 内部流量和合成流量。
2. 低风险用户或工作流。
3. 一小部分符合条件的生产流量。
4. 在每个阶段都设定固定观察窗口，逐步扩大。
5. 只有当候选方案始终处于所有护栏内时，才全面上线。

在开始之前定义自动回滚触发条件。示例包括任务成功率回退、schema 失败激增、p95 延迟超标、fallback 率升高、成本超支，或严重策略失败。

切换中途如果会破坏状态，请使用稳定路由，确保同一会话、agent 运行或客户始终停留在同一路由上。在回滚窗口关闭之前，保持现有方案处于预热状态。

关于多提供商可靠性模式，请参见 LLM API fallback routing playbook。

评估结束后保留路由策略

结果不一定需要是“全部迁移”。许多团队通过有策略地路由，能获得更好的结果：

• 面向复杂或高价值任务的质量优先路由。
• 面向受限抽取和分类的低成本路由。
• 面向交互式建议的低延迟路由。
• 面向数据位置或可用性要求的区域路由。
• 面向限流和故障的 fallback 路由。

这使评估结果可以复用。每条路由都有自己的契约、数据集和运营预算。新的候选方案是为既定任务竞争，而不是变成又一个全平台迁移项目。

Flatkey 提供跨多个模型提供商的统一 OpenAI 兼容访问层，可简化并排测试和路由。它不会消除评估的必要性；它减少了运行评估并保留回滚选项所需的集成工作。请在 Flatkey pricing 上比较当前路由。

提供商切换决策备忘录模板

以一份简短、签署的决策记录结束评估：

附上案例级结果、运行器版本、提示、验证器、原始响应以及价格快照。未来的审阅者应能够复现为何该切换被批准。

AI 模型评估最终清单

在切换 AI API 提供商之前，请确认你已经：

• 定义了精确的工作流和候选路由。
• 记录了现用基线和运行边界。
• 构建了开发集、留出决策集和生产审计集。
• 包含了常见、高价值、长尾、对抗性、契约性和运维性案例。
• 冻结了提示、工具、设置、检索输入和重试策略。
• 运行了现用方案与候选方案的配对测试。
• 在主观评分前应用了确定性验证器。
• 将任何基于模型的评分器与人工进行了校准。
• 提前定义了硬性门槛、权重和非劣效边际。
• 报告了置信区间和细分级结果。
• 一致地对追踪失败进行了分类。
• 测试了模式、工具、流式传输、错误、用量和速率限制。
• 计算了每个已接受任务的有效成本。
• 对预期并发和峰值并发进行了压力测试。
• 完成了隐私、保留、地域和访问控制审查。
• 通过了影子流量和分阶段金丝雀检查。
• 测试了自动回滚并保持现用方案可用。
• 签署并存档了提供商切换决策备忘录。

常见问题

AI 模型评估需要多少测试案例才算足够？

没有统一的数量。应使用足够的案例来覆盖每个关键细分，并缩小迁移决策的不确定性。高风险或低频细分可能需要有意过采样。应报告置信区间，而不要把样本量本身当作证明。

我应该使用公开基准来选择 API 提供商吗？

可以用基准来创建候选名单或了解大致能力，但不要把它们当作迁移门槛。你的提示、工具、模式、延迟预算、重试策略、数据控制和流量构成决定了是否适合生产环境。

一个 OpenAI 兼容的基础 URL 能让不同提供商互换吗？

它可以集中认证并减少客户端改动。但它不能保证参数支持、结构化输出、工具行为、流式事件、限制或模型质量完全一致。请针对你使用的每一条路由测试兼容性矩阵。

切换提供商时最重要的指标是什么？

对于大多数自动化系统，先从端到端工作流成功完成开始。然后再用质量、契约有效性、延迟、可靠性、重试、回退和有效成本来解释这一结果。

我们应该何时重新运行评估？

当模型版本、提供商路由、提示词、工具、检索系统、定价、工作负载分布、风险策略或流量边界发生重大变化时，就重新运行评估。在上线后保留一个更小规模的持续审计，这样回归问题会在下一次计划迁移之前显现出来。

让每次提供商切换都可复现

真正持久的资产不是获胜的模型，而是评估系统：版本化用例、跟踪捕获、验证器、评分器、评分卡、负载测试、发布控制以及决策记录。

有了这套系统，新提供商就变成了一次有边界的实验，而不是高风险的重写。你可以用同一份生产契约来衡量候选方案，逐步放量，并在现实与实验室结果不一致时快速回滚。

来源

• OpenAI：评估最佳实践
• OpenAI：使用 evals
• Anthropic：定义成功标准并构建评估
• Anthropic API：速率限制
• Google Gemini API：结构化输出
• Google Gemini API：函数调用