05 · 把模型选型变成路由与评估问题

定位：研究归纳与示例审查。 仓库的任务分类、模型档位和路由逻辑位于 Markdown 教程中，没有独立部署的路由服务。本文不引用历史价格或示例能力分数作为当前选型依据。

“所有任务都用最强模型”容易浪费资源，“所有任务都用最便宜模型”容易把风险推迟到人工返工。真正需要解决的不是选出一个永远最好的模型，而是为不同任务建立可解释的决策。

claude-demo 的路由研究给出了任务分类、质量门槛、上下文、模态与价格的组合思路。进一步检查示例，可以发现一个更重要的工程结论：路由器首先是约束系统，其次才是价格排序器。

一、先描述任务，而不是先填模型名单

一个任务不应该只用“聊天”或“代码”两个标签表示。至少还需要考虑：

• 输入与预期输出规模，包括工具返回内容可能增加的上下文。
• 输入输出模态，以及是否需要结构化结果或外部工具。
• 可接受的错误类型：措辞不佳、格式错误、业务错误和高风险错误并不等价。
• 延迟预算、数据敏感性、部署区域与供应方可用性。
• 是否有可以自动判定质量的测试、答案或验证器。

原始最小示例用关键词与文本长度分类，这适合演示控制流，但不是可靠的任务理解器。中文“跨文件重构”和英文 refactor 的写法差异就可能改变分类。即使结构更复杂，也要用真实任务集检查误分类，而不是依赖少数漂亮例子。

二、硬约束与质量门槛需要分开

可以把候选过程分成两步：先剔除不满足上下文、模态、数据治理和可用性要求的模型，再检查剩余模型是否达到该任务的质量要求。

硬约束不能因为价格便宜就降低。例如任务必须读取图片，而候选模型只接受文本；或者数据不允许离开本地，却选中了远程接口。这样的模型不是“性价比差”，而是根本不合格。

质量也不是某个全局分数。一项模型在通用基准上的分数，不能直接保证项目中的代码修改、中文契约理解或透明图片处理判断。质量门槛应尽量来自代表性任务和清晰的通过标准。

三、一个反例：提高门槛不能挽救空候选集

原始较完整示例每次都遍历同一个模型集合，以质量阈值、上下文和模态筛选；候选为空时，将档位向更高质量阈值移动。

这个策略存在集合关系上的问题：如果模型池和其他条件不变，提高质量阈值得到的一定是原候选集的子集。原集合已经为空，子集不可能突然出现模型。

满足更高阈值的候选 ⊆ 满足较低阈值的候选

因此，“升档”只有在真正扩大候选池、调用另一条服务路线或改变任务分解时，才可能挽救失败。仅提高阈值不是回退机制。

这个例子适合在技术分享中强调：不要被函数名、注释和“预期输出”说服，要检查集合如何变化、失败状态有没有出口。原始最小示例还在候选为空后直接取首项，说明空集是需要独立测试的正式状态。

四、质量回退与服务回退不是同一件事

以下流程是从研究中提炼的建议架构，不是仓库现有服务：

flowchart TD Task["任务与风险描述"] --> Capability["能力及数据约束过滤"] Capability --> Available{"有合格候选？"} Available -- "否" --> Stop["明确失败、重新分解或人工接管"] Available -- "是" --> Select["在质量达标者中比较成本与延迟"] Select --> Execute["执行请求"] Execute --> Service{"服务调用成功？"} Service -- "否" --> Retry["有上限且考虑幂等性的服务回退"] Service -- "是" --> Validate["结果验证"] Validate --> Accept{"满足任务要求？"} Accept -- "是" --> Done["交付与记录"] Accept -- "否" --> Escalate["有限质量升级或人工复核"]

服务回退处理超时、限流和供应方故障；质量回退处理答案或产物没有达到要求。两者的重试理由、次数和审计记录都应该不同。对于已经调用过写工具的任务，重新生成答案还可能重复外部操作，不能直接整体重放。

图 05：服务失败与质量失败具有不同原因和回退策略。该图是建议架构，不表示仓库已部署路由服务；涉及写操作时还必须控制幂等与重复副作用。

五、成本模型不能只看输入单价

可从以下账本开始：

任务总成本 = 输入计费 + 输出计费 + 缓存相关计费
             + 工具和检索成本 + 重试成本 + 人工复核成本

原始教程已经考虑任务输入输出比例及缓存读取，这比只按输入价格排序更合理。但固定采用“输入一半、输出一半”的最小示例不能代表所有业务。摘要任务、代码生成任务和多轮工具任务的分布可能完全不同。

缓存是否可用、如何计费、有效期如何计算，都应以实际服务契约为准。一次调用便宜，如果频繁失败或需要大量人工修复，也可能具有更高的交付成本。

六、评估应绑定真正的交付结果

训练与评估资料可以帮助区分知识测验、任务质量和对齐目标。工程路由更应关注端到端结果：代码是否通过目标测试，JSON 是否满足结构与业务约束，引用是否能定位到证据，图片是否符合交付规格。

建议建立包含以下类别的离线任务集：

类别	检查重点
常规任务	基础正确率与正常成本
边界任务	长输入、空输入、模态缺失、无候选
语言变体	中文、英文和同义改写是否被错误分流
服务异常	限流、超时、错误返回与取消
业务风险	越权、无依据回答、不可逆操作

固定任务集、评估规则、模型配置与采样方式后，再比较通过率、尾部延迟、成本和人工接管比例。路由修改也应做回归，避免为了降低平均成本而损伤关键任务。

结语

模型路由不是一张“能力分数除以价格”的排行榜。它是把任务要求、系统约束、验证器和失败出口连接起来的决策系统。只有这条链可以解释和复核，选型才不会随模型榜单变化而不断推倒重来。