多模型切换：按任务配约束

周一早上我先跑两个模型：一个便宜的做工单分类，一个贵的做退款邮件起草。不是因为我偏爱哪个，而是这两件事的验收方式完全不同。分类错了，规则能立刻发现；邮件写歪了，要人来读，返工成本高得多。多模型切换这件事，绕不开一个朴素问题：这一次的错，谁来发现，多久能发现。

先定验收方式，再定模型

我现在的顺序是：先写验收标准，再挑模型。

从发票里抽字段，我会要求 JSON 结构和固定字段，数值、日期逐项校验。模型只负责猜，规则负责判。这种任务我通常用便宜、快的模型，加一层解析和一次重试；它错得明显，修起来也便宜。

代码重构不一样。验收是编译和测试，模型必须看到调用链和周边文件。我会给它更大的上下文，宁可用贵模型一次过，因为来回试错更贵。

长文摘要又不一样。验收只能靠我自己读一遍，没法自动判。这时我会限制输出长度，要求它保留小标题和数字，优先稳定，而不是优先便宜。

这解释了一个反直觉现象：同一个模型，在 A 任务上划算，在 B 任务上不划算。不一定是能力波动，更多是验收成本不同。我把验收成本粗分三档：自动可判、半自动可判、只能人读。自动可判的任务，我优先便宜和快；只能人读的任务，我优先稳定和可解释，哪怕慢一点。

我的四条切换线

第一条是输出约束。要 JSON、要固定字段、要符合 schema，我先看模型是否支持结构化输出或函数调用；如果不支持，就在外面套解析器和重试，不靠硬 prompt 去赌。

第二条是上下文长度。长上下文不是把文档全塞进去就完事。我通常把材料切成必读块和检索块：必读块放前面，检索块按需拼进去。超过窗口就换长上下文模型；但如果只是找一句话，我反而用检索加小模型，不让大模型读完整本。

第三条是失败模式。有些模型错得很显眼，有些错得很安静。分类任务里，安静的错误最贵；写草稿时，显眼的错误反而好处理。我会给每个模型记一个错法，不是只记准确率。准确率差不多的两个模型，错法可能完全不同。

第四条是延迟和账单。我不追求绝对值，按任务设预算：交互式补全通常要秒级，后台批处理可以分钟级。超过预算就降级或者拆任务。拆任务有时比换模型有效，比如先抽出实体，再让模型写回复，而不是让一个模型从头做到尾。

这四条不是打分表，更像排除法。多数时候先被排除的是不合适，不是不够聪明。

一张小路由表和它的回退

我的路由表没有几十个模型，只有四五个槽位：快速分类、通用对话、长文处理、代码修改、离线兜底。每个槽位写清楚首选、备选和升级条件。

ROUTES = {
    'classify': {
        'primary': 'fast-small',
        'fallback': 'general-mid',
        'escalate_if': ['parse_error', 'low_confidence'],
        'max_retries': 1,
        'budget_ms': 1500,
    },
    'draft_email': {
        'primary': 'general-large',
        'fallback': 'general-mid',
        'escalate_if': ['human_reject', 'missing_policy'],
        'max_retries': 0,
        'budget_ms': 20000,
    },
    'code_patch': {
        'primary': 'code-large',
        'fallback': 'general-large',
        'escalate_if': ['tests_fail', 'diff_too_large'],
        'max_retries': 2,
        'budget_ms': 60000,
    },
}

真正跑的时候，我只看三个信号：解析失败、置信度低、人工退回。前两个能自动触发，第三个要记录原因。升级不是无脑换最大模型，而是换约束更匹配的模型：JSON 解析失败，先换结构化输出能力强的；测试失败，先换代码模型，不是换通用大模型。

回退也要设计。贵模型超时，回退到中等模型；中等模型还失败，就停下来进人工队列，不让它无限重试。重试会放大账单，也会把错误掩盖成延迟。

切换之后留下什么

每次切换我会记四样东西：任务类型、触发原因、模型槽位、人工是否返工。只记 token 和耗时没用，那些数字解释不了为什么换。

我还会维护一组二十来条的小样本，覆盖常见输入和两个边界案例。换模型前先跑一遍，不追求统计显著，只求别把已经修好的坑踩回去。这个做法很土，但比看榜单可靠。

有一点我还没定论：同一任务是否应该长期固定一个模型。固定下来容易调 prompt，也容易形成路径依赖；频繁切换能压成本，但会让评测变复杂。我目前的折中是，槽位固定，模型名可换，换之前必须过那组小样本。

如果你现在所有任务都走同一个模型，我建议先找一件错了能自动发现的事，把它切到便宜模型上，记录一周的返工率。不要一次换整套工作流。先让一个槽位跑通，再谈多模型。