选择模型

模型选型是生产决策，不是查排行榜。真正要选择的是一个带版本的线上服务系统：特定模型修订版、供应商或服务构建、提示词、工具、配置、安全控制和回退行为。即使权重不变，换一个提示词模板或工具循环，也可能改变结果。

第一步是写清楚工作负载契约。它说明哪些任务重要、什么结果才算合格、有哪些硬约束，以及质量、成本、延迟、可用性和运营风险的上限。随后，所有具备准入资格的候选系统都在同一份契约下比较。没有适用于所有场景的赢家，只有针对已经声明的工作负载和时间范围，可以用证据辩护的选择。

本章把这个原则落实为一套操作流程。从闭源到开放权重只是一个输入条件，不是决策流程。第 73 章 介绍如何审查一次模型发布，第 47 章 则说明公开分数能够证明什么，又不能证明什么。

选择系统，而不是名称

“Model Pro”之类的家族名称太含糊，无法复现。测试之前，先记录候选系统的准确身份：

• 供应商和模型 ID；如果下载权重，则记录下载权重的制品摘要；
• 端点和区域；
• 提示词模板和消息格式；
• 工具模式和工具循环实现；
• 解码与推理设置，包括预算和停止规则；
• 安全策略和内容过滤器；
• 缓存、批处理、路由器和回退策略；
• 测试采用的速率与容量上限。

把这套配置记为 $m$。任何会改变行为的字段一旦变化，就应视为新的候选系统。即使 API 暴露的名称看起来固定，也要保留带日期的记录，因为线上服务实现、配额和条款都可能在代码仓库之外发生变化。

把模型视为完整系统，并不是新观点。Liang 等人在 2022 年提出、2023 年发表的 HELM，用标准化条件比较不同场景和多项指标下的语言模型 (Liang et al. 2023)。Mitchell 等人在 2019 年提出模型卡，让预定用途、评测条件和局限随模型发布一起交付 (Mitchell et al. 2019)。实践中的延伸很直接：为应用实际调用的线上配置保留一张系统卡。

图 81.1 中的顺序，可以防止漂亮的分数掩盖法律、接口或容量问题，也能防止便宜但不合格的系统进入经济性比较。

排序之前先审查准入资格

把硬性要求写成谓词。对于候选系统 $m$，可以用下面这个简洁的准入门：

$$E(m)=H_{\mathrm{license}}(m) \land H_{\mathrm{data}}(m) \land H_{\mathrm{region}}(m) \land H_{\mathrm{interface}}(m) \land H_{\mathrm{capacity}}(m).$$

这里，$H_{\mathrm{license}}(m)$ 表示法律审查允许预定用途；$H_{\mathrm{data}}(m)$ 表示服务处理与保留方式符合策略；$H_{\mathrm{region}}(m)$ 表示部署和处理位置得到允许；$H_{\mathrm{interface}}(m)$ 表示所需模态、工具和输出形式能够工作；$H_{\mathrm{capacity}}(m)$ 表示满足所需负载和可用性。每个条件都是布尔值，未知不能视为通过。未解决的问题应进入明确的例外流程，而不是在加权评分中变成一个很小的扣分项。准入资格不是加权评分。

如果工作负载有需要，准入门还应覆盖更多要求，例如无障碍要求、安全控制、出口限制、审计证据、赔偿、数据删除或退出路径。

只有“开放”二字，信息仍然不足

审查时应把制品与权限分列记录。一次发布可能只提供权重，却不提供训练数据、训练代码或有用的模型卡。某个代码仓库使用宽松的代码许可证，并不代表权重或数据的适用条款也相同。托管服务还有另一份合同，涉及数据保留、使用客户数据训练、区域、可接受使用、速率限制、弃用和支持。

开放源代码促进会在 2024 年发布的开放源代码人工智能定义，关注系统是否允许使用、研究、修改和分享，以及便于修改的首选形式是否包含所需的数据信息、代码和参数 (Open Source Initiative 2024)。这比“可以下载权重”丰富得多。不能看到“开放”就推断拥有相应权利。应逐项检查准确部署所涉及的制品、许可证和服务协议。这是一套工程审查框架，不构成法律意见。

托管、代管和自托管是不同的部署选择

能否取得制品，与如何部署有关，但两者不是同一件事。可下载权重可以运行在自有机器、租用的加速器或代管端点上。托管 API 可以直接访问，也可以经云市场访问。制品许可证与服务条款彼此独立。比较组织实际可以采用的方案时，要把容量、人员、安全和退出成本都算进去。

用公开证据发现候选模型

公开基准适合发现候选模型。如果任务、系统和测量过程与实际场景不一致，它们就不能直接支撑生产决策。HELM 的场景与指标框架之所以有价值，正是因为它把这些选择摆在明面上 (Liang et al. 2023)。

阅读任何公开结果时，都应追问四个问题：

1. **构念是否匹配：**基准测量的是产品真正需要的能力，还是一个容易测量的替代指标？
2. **测试框架是否匹配：**提示词、工具、采样、上下文、预算和评分器是否接近生产环境？
3. **不确定性：**题目数量、重复运行、区间和接近的排名，是否报告得足以支撑所声称的差异？
4. **数据来源：**任务何时、如何创建、公开、过滤和评分？

还要确认被测系统究竟是什么。智能体基准通常测量的是模型、执行框架、工具、重试和预算的组合。例如，SWE-bench 测量真实代码仓库中的问题解决能力，而不是孤立的代码补全 (Jimenez et al. 2024)。LiveCodeBench 持续收集较新的竞赛题目，并覆盖多种编程行为 (Jain et al. 2024)。这些设计回答不同的问题，任何一项分数都不能自动迁移到私有工作负载。

人类偏好榜回答的又是另一个问题。Chatbot Arena 根据用户的成对偏好，使用统计排名方法汇总偏好 (Chiang et al. 2024)。它反映特定流量和界面下的总体偏好，不能直接证明事实正确性、策略合规性或工具可靠性。

公开结果与私有测试之间出现可疑差距，值得调查，但不能仅凭差距证明数据污染。任务组合、提示词、工具、预算、评分器和随机性都可能造成差异。应记录各种可能解释，并运行受控测试，而不是从一次比较直接指定原因。

围绕实际工作负载设计评测

内部评测才是决策工具。在查看最终结果之前，先固定评测契约：

• 定义工作负载分层，例如语言、任务类型、难度、风险和输入规模，并给出生产权重；
• 写明验收规则和主要质量指标；
• 指定现有基线与最小实际重要差异；
• 把调优样本与锁定的确认集分开；
• 声明成本、延迟、关键故障和可用性上限；
• 选择精度目标和样本量方案。

对所有候选系统使用同一批案例。供应商负载可能随时间漂移时，应随机安排执行时间；生成具有随机性时，应在生产设置下重复试验。还要保留正确的独立单位。同一段对话中的多个轮次，或同一个问题的多次尝试，都是聚类观测，不能当作互不相关的证据。

对于挑战者 $m$ 和基线 $b$，将独立案例 $i$ 上的配对结果定义为

$$d_i = y_i^{(m)}-y_i^{(b)},$$

其中，$y_i^{(m)}$ 和 $y_i^{(b)}$ 是在固定验收规则下得到的分数。运行比较之前，先选择非劣效界值 $\delta>0$，也就是团队为了换取其他收益，最多愿意接受的质量损失。只有当工作负载加权平均差的置信区间下界大于 $-\delta$ 时，挑战者才通过质量门。如果要声称优效，则要求下界大于零。

这是一条决策规则，不是万能的统计处方。二元配对结果、量表分数、聚类对话和带随机性的重复试验，需要不同的区间估计方法。第 48 章 会进一步介绍这些选择。样本量应根据精度目标、预期配对方差、聚类结构和期望错误率确定。没有站得住脚的万能样本数。即使总体指标通过，也要检查各分层结果和关键故障。

当可执行评分器或规则评分器能够代表验收条件时，应优先采用。必须由人判断时，要盲化候选身份，并随机排列呈现顺序。必须使用 LLM 裁判时，要固定完整配置，用人工标签验证，测量裁判分歧，交换答案顺序，并裁决重要冲突。LLM 裁判可能存在位置偏差 (Wang et al. 2024)。更完整的评测设计见 第 50 章 和 第 52 章。

下面是一份可审查的示例配置：

# eval-contract.yaml：示例字段，不是通用阈值
workload: evals/support-confirmation-v8.jsonl
strata: [language, request_type, risk, input_size]
candidate_systems:
  - config: systems/incumbent-2026-08-01.yaml
  - config: systems/challenger-a-2026-08-01.yaml
primary_metric: accepted_result
comparison:
  design: paired
  repeats_per_case: 3
  noninferiority_margin: declared-before-run
  confidence_method: chosen-for-independent-unit
secondary_limits: [critical_failure_rate, cost_per_accepted_task, p95_latency]
release: [shadow, canary, rollback]

比较每项合格任务的总成本

词元价格只是输入，不是经济结果。分词器、缓存规则、推理词元、输出长度、工具使用、重试次数和合格率都可能不同。应在同一个核算期和工作负载下，测量端到端的每项合格任务的总成本。

这里，$s$ 表示工作负载层 $s$，$r$ 表示重复试验 $r$。$w_s$ 是第 $s$ 层的生产权重，$K_{msr}$ 是候选系统 $m$ 实际产生的端到端成本；结果合格时 $A_{msr}=1$，否则为零。于是

$$C_m= \frac{\sum_s w_s\sum_r K_{msr}} {\sum_s w_s\sum_r A_{msr}}.$$

加权合格数量为零时，$C_m$ 没有定义，这正是需要的警告。$K_{msr}$ 背后的成本账应包括输入词元、输出词元、缓存写入与读取、工具调用、重试、网络费用、人工复核和预期事故成本。自主管理服务还要计入加速器、CPU 与内存、存储、闲置容量、运维人力、值班工作和软件。应把每次尝试成本与合格任务成本并列，以免分母变化被隐藏。

同时测量客户端延迟。按工作负载分层和实际请求负载，报告首词元和端到端的 p50、p95 与 p99。诊断时应拆开排队、预填充、解码、工具和重试。级联路由可能降低平均支出，却因为升级请求经历多个阶段而恶化尾延迟。

托管与自托管的成本交叉点

做快速敏感性分析时，假设两个质量等价的方案满足相同的服务目标。在一个核算期内，写成

$$C_h(N)=F_h+Nv_h$$

其中下标 $h$ 表示托管服务，而自托管服务为

$$C_s(N)=F_s+Nv_s$$

$N$ 是该核算期内的合格任务数，$F_h$ 和 $F_s$ 是固定成本，$v_h$ 和 $v_s$ 是每项合格任务的可变成本。所有项必须使用相同货币和相同核算期。当 $v_h>v_s$ 时，线性交叉点为

$$N^*=\frac{F_s-F_h}{v_h-v_s}.$$

只有分子和分母使 $N^*>0$ 时，才存在正的交叉点，否则在线性区间内不存在正的交叉点。真实系统还有容量台阶、需求突增、承诺用量、利用率、迁移成本和价格变化。应按 第 76 章 的方法分别建立低、中、高情景。如果两个方案不满足质量等价，或服务目标不同，这个简化公式就无效。

选择帕累托前沿，而不是单项冠军

通过硬约束门和质量门之后，把剩余候选系统放到帕累托前沿上。如果另一个具备准入资格的系统，在所有与决策相关的指标上都至少不差，并且至少有一项更好，那么前者就被后者支配。删除被支配的候选系统。余下的取舍仍然需要判断：有的团队愿意为更低的关键故障率上界多付钱，另一些团队会为满足数据驻留要求而接受较慢响应。

不要把判断藏进任意设置的归一化权重。应记录取舍、负责人、证据和到期日期。关于学习型级联的研究表明，路由可以改善测得的成本与质量取舍 (Chen et al. 2023; Ong et al. 2024)，但路由器本身也是一个带版本的系统。必须端到端评测策略，包括错误路由、验证器错误、重复工作、回退延迟和外部影响。

通过系统接线维持选择的有效性

如果应用需要可移植性或集中控制，就把供应商特有行为放在供应商适配器后面。网关（gateway），也就是模型调用的路由与策略层，可用于共享密钥、预算、可观测性和路由，因此网关是一种设计选择。它也会增加依赖，无法让不同供应商在语义上完全一致。

所谓 OpenAI 兼容传输通常只覆盖公共子集。工具语义、结构化输出、词元化、缓存、流式传输、多模态输入、推理控制和错误行为仍可能不同。符合策略的回退系统必须遵守相同的数据与区域规则，并由同一份评测契约验证。启用自动故障切换之前，应测试含糊的超时和操作幂等性。详见 第 88 章 和 第 90 章。

如果供应商或制品支持稳定修订版，就固定稳定修订版。否则，记录准确的端点、区域、配置和观测日期，并经常运行哨兵评测。每条追踪记录都应保存所选模型与路由决策，以便把故障归因到实际处理请求的系统。

发布时先使用影子流量，再进行小规模金丝雀发布，并配置自动回滚。按工作负载分层监控合格率、关键故障、尾延迟、支出、容量和供应商错误。提前定义所有重新评测触发条件：模型或提示词变化、价格或条款变化、新的工具模式、工作负载漂移、质量漂移、反复发生的容量故障，或决策记录到期。

最终产物是一份决策记录，其中包括工作负载契约、候选系统身份、准入证据、带不确定性的评测结果、成本账、帕累托取舍、发布负责人、回滚规则和重新评测触发条件。它让模型选择今天可以解释，明天也可以替换。

延伸阅读

以下内容汇集了这套框架及其适用边界的一手资料和存档来源。