把能力花在失败代价高的地方
模型选择要在质量、延迟、上下文和成本之间分配资源，不能照着产品排名做决定。
类型： Learn 语言： Python 前置要求： 选择能承载工作的最小载体、缓存、速率限制与成本优化预计时间： 约 90 分钟
学习目标
- 无需背诵价格表，也能估算 token 成本和工作流成本。
- 根据实测质量、延迟和后果选择模型。
- 解释采样的非确定性，以及为什么发布结论需要重复评估。
- 只有核验当前模型和平台后，才选择 speed、effort 与 thinking 设置。
- 区分模型失败与 prompt、上下文、来源和工作流失败。
- 把路由、缓存、批处理和输出限制作为相互独立的优化手段。
问题所在
某支持团队把每个请求都路由到能力最强的模型。第一个月看似很成功：质量很高，但响应时间不稳定，账单是预估的四倍。
经理于是把所有请求都切到最快的模型。成本降了下来，但升级摘要开始漏掉例外情况，复杂退款案例也收到了自信却不完整的建议。
两种设计都把模型名称当成政策，却都没有描述实际工作。
生产决策要从失败代价出发。内部头脑风暴里出现一个错别字，代价很低；退款决策漏掉一条例外，代价就高得多。模型、prompt、上下文、来源质量和审核流程都应体现这种差异。
核心概念
Token 是工作负载的计量单位
模型处理的是 token，不是页数或单词数。输入 token 包括指令、对话历史、提供的文档、工具定义和检索到的内容。输出 token 包括回复；根据产品或 API 的不同，还可能包括当前定价中描述的推理相关计算或其他计费单位。
规划时，拆成四个部分：
total input = stable instructions + task input + retrieved knowledge + prior turns
total output = requested answer + structured metadata不要把所有输入藏进一个数字里。稳定指令可能受益于缓存；检索知识可以裁剪；先前轮次可以总结或丢弃；任务输入通常无法移除。
先用变量，再填实时价格
价格会变，长期有效的公式不会：
request cost = input_tokens / 1,000,000 x input_rate
+ output_tokens / 1,000,000 x output_rate
+ tool or feature charges对于工作流：
workflow cost = request cost x requests per case x cases per month
+ review cost
+ failure and rework cost审核和返工也有成本。便宜模型若让人工修正时间翻倍，反而可能是更贵的选择。
来看一份仅供说明、并非当前价格的费率表。模型 A 的输入费率为 1 个单位，输出为 5 个单位；模型 B 分别为 3 和 15。每个案例使用 20,000 个输入 token 和 2,000 个输出 token，模型 B 每次调用的成本是模型 A 的三倍。如果模型 A 能通过 98% 的分流案例，而且能识别困难案例，就把常规工作路由到 A，把其余不确定案例升级。如果无法安全识别困难案例，路由设计就还不完整。
用门槛衡量质量，别凭感觉
测试模型前，先定义最低可接受结果。可用维度包括：
- 必需事实齐全。
- 没有缺乏支持的主张。
- 遵循指令。
- 输出 schema 有效。
- 延迟低于工作流上限。
- 人工修正时间低于门槛。
- 安全与隐私控制不受破坏。
最佳模型，是以足够余量通过每项必需门槛的最便宜方案。只看平均质量不够：一个模型可能整体得分很高，却在每个后果严重的边缘案例上失败。
采样每次从概率分布中选择
语言模型生成每个 token 时，面对的是一组可能后续内容的概率分布。采样从该分布中做选择。对于接受 temperature 设置的模型，temperature 会改变分布的集中程度，但不会让模型推理变成确定性函数。
Anthropic API 官方文档明确指出，即使 temperature 为零，也不是完全确定的。相同请求通过第一方 API 和合作云仍可能产生不同结果。固定模型 ID 可以稳定模型权重，但 Anthropic 的模型版本文档也说明，路由、安全分类器和采样逻辑等服务基础设施仍可能变化。
这会改变什么才算证据：
- 一次回复通过，只能证明这一次回复通过了。
- 单一平均值会掩盖尾部失败和多次运行之间的差异。
- 确定性验证器可以检查 schema 和算术，却无法让生成变得确定。
- 在同一个版本化任务上重复试验，才能揭示最低质量、方差、严重失败和尾部延迟。
- 模型、prompt、工具、平台或服务模式发生变化，都需要重新比较。
小型学习练习中，每种配置至少独立运行三次。生产环境的样本量应根据观察到的风险和方差决定，不能把这个最低数当作标准。分别比较各风险切片，并优先采用“关键案例最低质量”“p95 延迟”这类门槛。漂亮的平均值可能掩盖严重失败。
采样控制本身也是可能变化的产品事实。截至 2026 年 8 月 9 日，Anthropic 当前 Messages 指南称，Claude 4.7 及后续版本会拒绝非默认的 temperature、top_p 或 top_k 值。较旧且仍受支持的模型可能继续接受其中部分参数。未核对当前模型和平台文档前，不要从旧请求复制采样设置。
诊断失败层级
输出薄弱时，先问失败来自哪一层：
- 需求失败： 从未定义成功标准。
- 来源失败： 必需事实缺失或已过时。
- 上下文失败： 相关证据被埋没、截断，或与冲突材料混在一起。
- prompt 失败： 指令或输出标准不清楚。
- 模型失败： 输入和标准都没有问题，但模型能力仍然不足。
- 工作流失败： 缺少审核、升级机制或工具行为。
升级模型主要对第五层有效。它也许能暂时掩盖其他问题，却会让系统更难调试。
延迟由多个部分组成
用户感受到的延迟包括：
- 首次出现可见输出前的时间。
- 流式数据块之间的时间。
- 总生成时间。
- 工具与检索时间。
- 人工批准时间。
能力更强的模型可能单次调用更慢，但能减少重试；小模型可能响应很快，却制造更多循环。要测量完整工作流。
根据可观察约束路由
一个简单的路由策略可以把工作分成三条通道：
| 通道 | 示例 | 策略 |
|---|---|---|
| 常规 | 格式化给定更新 | 快速模型，严格模板 |
| 模糊 | 比较相互冲突的笔记 | 均衡模型，要求来源 |
| 有后果 | 建议是否批准例外 | 强模型加必需审核 |
分类器本身也会失败。尽可能使用确定性信号，例如文档长度、任务类型、敏感度标签、请求的操作或用户明确选择。记录路由决策，并审计错误路由。
flowchart LR
A["Classify task and consequence"] --> B["Try smallest qualified model"]
B --> C{"Meets measured gate?"}
C -->|"Yes"| D["Return for normal review"]
C -->|"No"| E["Diagnose failure layer"]
E --> F{"Capability failure?"}
F -->|"Yes"| G["Escalate model or thinking mode"]
F -->|"No"| H["Repair source, prompt, context, or workflow"]缓存、批处理和限制解决不同问题
Prompt caching 在当前模型和平台支持时，可以降低重复处理稳定 prompt 前缀的成本和延迟。它不会让过时指令变正确。
Semantic caching 为足够相似的请求复用先前结果。它需要新鲜度策略，不适合个性化、快速变化或后果严重的工作。
Batch processing 用响应时间换成本和吞吐量。它适合夜间分类或批量提取等离线工作，不适合让用户等待的交互式工作。
输出限制 可以避免回复无谓拉长，设得低于任务需求时也会截断工作。要求最短的有效输出，并验证完整性。
上下文裁剪 在无关输入产生费用、干扰模型之前将其移除。增加上下文不会自动增加知识。
配置是带日期的组合
模型选择只是配置手段之一：
| 手段 | 改变什么 | 测量什么 |
|---|---|---|
| 模型 | 基础能力、价格、支持的功能和生命周期 | 各风险切片的质量、成本、延迟、兼容性 |
| Speed | 支持快速模式时的服务速度，通常需要支付溢价 | 每秒输出 token 数、首 token 时间、p95 延迟、可接受结果成本 |
| Effort | 在支持时，模型分配给文本、thinking 和工具使用的工作量与 token 开销 | 质量、工具调用次数、输出 token、延迟、成本 |
| Thinking | 在支持时，模型是否以及如何分配显式推理 | 困难案例质量、thinking token、总输出、延迟、成本 |
| Prompt 与输出合约 | 指令、证据边界、格式和要求的长度 | 指令遵循、schema 有效性、修正时间 |
| 采样 | 仍接受随机性控制的模型生成行为 | 结果差异、严重失败、风格多样性 |
截至 2026 年 8 月 9 日，官方模型概览列出的准确 Claude API ID 是 claude-sonnet-5 和 claude-opus-5。Sonnet 5 默认启用 adaptive thinking，也允许禁用 thinking，并支持产物中使用的 low 和 high effort 值。Opus 5 支持 adaptive thinking 和产物中使用的 medium effort 值。
Fast mode 的适用范围更窄。当前官方文档只列出 Opus 5 和 Opus 4.8，不包括 Sonnet 5；该功能仅限 Claude API，包括 Managed Agents，不支持合作平台。它处于研究预览阶段，需要相应访问权限、speed: "fast" 以及 anthropic-beta: fast-mode-2026-02-01 请求头。它使用相同模型提供更快推理和溢价计费，并不承诺更高智能。可用性、支持范围和价格都可能独立变化。
不要把永久兼容性矩阵写进路由代码或学习笔记。每次实验前：
- 记录准确模型 ID 和平台。
- 打开当前官方页面，核对模型支持、thinking、effort、speed 和价格。
- 为每项待测配置标记
docs-supported或docs-unsupported，并记录日期与来源。文档支持并不能证明你的账号拥有预览访问权限。 - 不要试验不支持的组合，也不要假设它会静默降级。
- 针对相同任务集和门槛，重复运行受支持的配置。
平台允许时，每次只改变一个手段。如果支持范围迫使你同时更换模型和 speed，应把它称为路由替代方案；这类结果无法单独归因于 speed。
考试换算分数不是百分比
截至 2026 年 8 月 9 日，Anthropic 认证 FAQ 称，成绩采用 100 到 1,000 的换算分数，最低合格分数为 720。换算用于校准难度可能不同的考试版本。
因此，720 绝不表示原始合格线是 72% 的正确率。本课程的测验与模拟百分比是原始练习分数，不能换算成官方分数，也无法预测考试结果。
动手构建
为每周运营工作流创建一个包含十个案例的模型选择基准测试。
- 四个常规格式化和分类案例。
- 三个模糊的综合案例。
- 两个来源相互冲突的案例。
- 一个必须升级给人工处理的后果严重案例。
运行任何模型前，先定义评分标准：
{
"required_facts": 4,
"unsupported_claims_allowed": 0,
"format_valid": true,
"latency_seconds_max": 20,
"human_correction_minutes_max": 3,
"consequential_case_must_escalate": true
}先测试最小的可行模型家族。记录输入与输出 token、延迟、评分和修正时间。只升级失败案例。将路由工作流与所有十个案例都使用大模型的方案进行比较。
报告必须回答：
- 哪些案例可以安全使用小模型？
- 哪项可观察信号会把案例向上路由？
- 哪些失败并非模型失败？
- 在假设业务量下，路由能节省多少成本？
- 路由器不确定时怎么办？
然后为一个模糊或后果严重的案例创建 mode-trials 产物：
- 查看结果前，先定义最低质量、最大 p95 延迟、最大平均成本和最少重复运行次数。
- 提出至少三种改变 speed、effort 或 thinking 的配置。
- 在当前官方文档中核验每个准确模型与平台组合。保留一个文档明确不支持的组合，作为被拒绝选项。
- 每个受支持配置都使用相同的 prompt、来源、工具和评分标准，至少运行三次。
- 记录每次运行的质量、延迟、成本和结果指纹。
- 根据原始运行数据核对最低质量、p95 延迟和平均成本。
- 选择通过所有门槛且成本最低的受支持配置。
所提供的产物会在一个模型上比较 low 与 high effort、adaptive 与 disabled thinking、standard 与 fast 服务，以及一个不受支持的 fast 组合。其中 standard speed 是省略请求字段时采用的标准化实验标签；fast 配置另行记录所需预览访问权限、请求字段和 beta 请求头。这是带日期的示例，不是可复用的兼容性表，也不能证明账号拥有相应权限。
交互实验
使用风险图调整后果、不确定性、可逆性和审核强度。它会在你优化 token 开销前，显现误判为通过的隐性成本。
02-responsible-ai-risk实践实验
运行十案例路由基准测试。让一个后果严重的案例跳过审核、复制案例 ID，或错误填写路由成本，观察确定性验证如何失败。然后删掉一次重复模式运行、修改核对后的 p95 值、尝试文档明确不支持的模式，或选择成本不达标的配置。修复证据，门槛保持不变。
交付产物
outputs/model-routing-benchmark.json 保存了覆盖常规、模糊、来源冲突和后果严重工作的十案例路由合约，其中包括实测门槛、选定通道、token 估算、审核时间，以及路由与全部案例使用大模型的对比。
outputs/mode-trials.json 是应用配置产物，记录当前文档证据、speed、effort、thinking、fast mode 请求前置条件、重复质量、p95 延迟、平均成本、不受支持的组合、选定模式和重新运行触发条件。
这些支持声明来自带日期的官方文档，状态统一使用 docs-supported。它们未通过 live request 核验，因此没有标为 live-request-verified。质量、延迟和成本值是练习用说明数据，不是供应商调用或基准测试结果。请用自己任务集与账号的重复运行结果替换它们。
验证
不调用供应商即可验证基准测试：
cd certifications/claude/lessons/02-model-selection-and-token-economics/code
python3 main.py
python3 -m unittest discover tests -v验证器会保留原有基准测试检查，并单独验证模式试验。它要求：当前官方支持证据、明确的说明性测量标签、fast mode 请求前置条件、每种 docs-supported 模式至少三次重复运行、可观察的结果指纹、核对后的汇总、一个未尝试的 docs-unsupported 选项，以及选择通过门槛且成本最低的配置。它没有硬编码任何未来模型支持何种模式的结论。
综合项目关联
测验考查路由、失败层级诊断和成本推理。把验证后的基准测试用作第 29 至 32 课总结项目中的模型选择证据，再用自己的代表性案例结果替换说明性测量。
上手使用
使用这句决策说明：
For [task class], choose [model family or mode] because it clears [quality gate]
across [repeated runs] within [p95 latency and mean cost limit]. Escalate when
[observable condition], and require [review rule] when [consequence threshold].
Model, platform, speed, effort, and thinking support checked in official docs on [date].如果理由只有“它更聪明”，说明决策还没有做完。
运行基准测试前，查阅实时模型概览和定价页面。把准确模型标识符保存在基准测试结果中，永久政策里不要写死。这样可以防止模型别名变化悄悄使证据失效。
把不受支持的配置留在决策记录中，不要放进生产请求。拒绝理由能解释为什么没有测试某个诱人模式，也为未来重新核验提供明确触发点。
考试决策模式
- 在花钱购买更多能力前，先修复缺失的标准、来源和上下文。
- 使用通过代表性质量门槛的最小模型。
- 不要只算 token 价格，还要计入人工修正与失败成本。
- 使用可观察信号，把后果严重或模糊的工作向上路由。
- 只有工作流能接受延迟完成时才使用批处理。
- 只有新鲜度与隔离条件允许时，才缓存稳定且可复用的材料。
- 把模型功能、价格和限制视为带日期的事实。
- 对概率性评估重复试验；低 temperature 或固定模型 ID 都不能保证输出一致。
- 把 speed、effort 和 thinking 当作需要实测的配置选择。
- 把 720 视为认证换算分数，绝不能当成原始百分比。
常见坑
- 根据模型家族名气选型，忽略任务基准测试。
- 只用一个简单样例比较模型。
- 只报告平均质量，隐藏关键案例失败。
- 把每个糟糕输出都称为模型限制。
- 不断增加上下文，让成本与干扰一同上升。
- 底层来源变化后仍复用缓存输出。
- 在成本模型中漏掉审核时间。
- 使用不透明分类器路由，而且没有审计轨迹。
- 因为一次运行通过或 temperature 较低，就宣称 prompt 是确定性的。
- 从不同模型或平台复制 speed、effort、thinking 或采样设置。
- 对不受支持的模式静默降级，没有关闭失败并记录不兼容性。
- 只比较平均延迟，隐藏违反用户目标的尾部延迟。
- 把考试 720 的换算门槛转成 72% 的原始目标。
练习
- 用符号表达式计算一个包含 50,000 个案例和两个模型档位的工作流月度成本。
- 为支持工作流写出三个确定性路由信号。
- 把五种失败分别诊断为需求、来源、上下文、prompt、模型或工作流问题。
- 找出一项应使用批处理的任务，以及一项必须保持交互式的任务。
- 在官方文档中核验一项当前 thinking 功能，并记录模型、平台和日期。
- 将一种配置运行三次，保留结果指纹，并解释单次运行会掩盖什么。
- 在官方文档中找出一个当前不受支持的模式组合，记录下来但不要发送请求。
关键术语
| 术语 | 含义 |
|---|---|
| Token 经济性 | 输入、输出、请求量、模型费率与工作流成本之间的关系 |
| 质量门槛 | 候选配置必须通过的可测量阈值 |
| 路由 | 根据任务信号选择模型或执行通道 |
| 升级 | 把不确定或后果严重的工作交给更强能力或人工审核 |
| Prompt caching | 为稳定 prompt 材料复用供应商侧计算 |
| 返工成本 | 修正不合格输出所需的人工或机器工作量 |
| 采样 | 从模型概率分布中选择生成 token |
| 模式试验 | 针对一组准确模型、平台、speed、effort 和 thinking 配置开展的重复、带日期评估 |
| 尾部延迟 | p95 等高百分位延迟指标，用于暴露平均值掩盖的慢请求 |
| 换算分数 | 用于校准不同考试版本的转换后结果，不是原始正确率 |