可调 effort 之后：同一个模型档位是成本开关也是质量开关
一、先看账单会得出错误结论
据公开报道，有厂商发布了一款轻量型号，是该系列中第一个支持可调节 effort 设置的型号，厂商同时下调了价格并称平均运行成本下降，定位在智能体任务与日常办公流程上。型号名、价格变动和厂商自己的表述都只作背景转述，不是本文的判断依据；effort 在内部究竟对应什么机制（是否等价于思考预算、是否改变工具调用策略），外界无法从公告里推出来，本文也不做推断。
真正改变事情的是”一个连续可调的档位”这个接口形态。过去在多个模型之间选，选择是离散的，选完就固定；现在同一个模型内部可以调，就出现了默认调到最低的动力——账单立刻好看，评审时也好解释。问题在于质量下降不是均匀的：它在不同任务类型上差得很远，而账单是均匀地省。
最先出问题的是两类任务。一类是长文档与长上下文：低档更容易漏掉远处约束、把前文设定遗忘、在多个可选方案里挑一个明显不对的，而这类错误在抽样检查里看不出来，因为短输入的用例全都正常。另一类是多工具、多步骤的智能体链路：低档更容易出现参数拼错、忘记校验上一步返回、在失败后原样重试，单步看起来都成功，整条链路的结果是错的。这两类恰好是企业交付里最贵的一部分活，所以拿”平均消耗下降”来推”整体可用”是不成立的。
只看账单还有第二个陷阱：省下的推理成本和返工成本不在同一张表上，返工往往落在人的一侧，以工时和投诉的形式出现，不进模型账单。
二、定档要两轴一起看，不是一刀切
我们的做法是先列任务清单，再按两条轴分档：这条链路出错的代价有多大，以及多花一些能把错误补回来多少。两轴合起来才决定档位，任何单轴都会带偏。
| 业务场景类型 | 出错代价 | 补回代价 | 首次定档 | 附加要求 |
|---|---|---|---|---|
| 高频低风险短任务（改写、抽取字段、格式化） | 低，用户当场能看出来 | 低，重跑一次即可 | 低档起步 | 留抽样人审，防止错误形态漂移 |
| 长文档理解与摘要 | 中到高，遗漏不易被发现 | 中，需要整段重跑 | 中档起步 | 用例集里必含跨段落约束的题目 |
| 多工具智能体链路（查库、调用接口、写回） | 高，错一步下游全错 | 高，需要回滚状态 | 中高档起步 | 每一步校验返回码，失败即升档重试 |
| 对外发送的内容与承诺 | 很高，且不可撤回 | 极高 | 高档并留人工确认 | 确认动作与档位绑定，不许配置层关掉 |
| 内部检索式问答 | 中，答错会被追问 | 低 | 低档起步、答不上来升档 | 记录升档触发原因 |
| 代码改动与配置变更 | 高，测试通不代表逻辑对 | 高 | 中档起步，失败样本升档 | 失败后原样重试两次即强制升档 |
这张表是起点不是结论。定档必须靠回归结果改：低档在某一类用例上开始出现失败，这一类就要往上挪；挪上去之后如果失败率没有明显改善，说明问题不在档位，而在提示、上下文或者任务本身，这时候继续加档位只是烧钱。
高频低风险给低档、高风险低频给高档并保留人工确认，这条原则的价值在于把省下的钱花在真需要质量的地方，而不是全线降到最低。
三、档位切换的工程要求
档位一旦可调，就变成了配置项，而配置项需要按生产配置来管，不能靠调用点随手写。
- 配置来源唯一：档位只能从一份受版本控制的配置里读，业务代码里不允许出现硬编码档位；来源写死在代码里，出问题时无法回答”当时线上是什么档”。
- 生效时间明确：改档位要记录提交时间、生效时间与影响范围，灰度期间同时保留新旧两组，便于对比与回滚。
- 会话内不许变：同一会话中途不许改档。中途切换会让上下文风格、格式约定与工具策略一起变，用户感知为”答着答着变了一个人”，排查时也无法区分是档位变化还是模型退化。实现上把档位与会话 ID 绑定，会话创建时快照，整个会话生命周期只读。
- 日志落实际值而不是配置名：这是最容易漏的一条。配置里写的是”标准档”，日志必须记录这次请求实际生效的档位取值、模型版本标识、以及由谁或什么规则决定的。配置名会被改名或重新映射，只记名字等于没记。
- 兜底规则要显式：超时、限流、参数不合法时按什么档位重试，必须写死在配置里并单独打点，否则这些隐藏路径会把成本账完全带偏。
四、按档回归：看的是失败点，不是平均分
我们固定的做法是一套按场景分组的用例集，逐档跑，读的是”哪些用例在低档开始失败”。平均分是最没用的指标，它会把”两类任务全崩、其余全对”抹成一个不错的数字。
用例集的定义要求：
- 按场景分组，每组够跑出问题的小样本量，宁可每组少而典型，不要一大池子混测。
- 每组必须包含至少一条”远处约束”题（答案依赖上下文靠前的信息）与一条”多步校验”题（需要工具返回码判断），这两类是低档最先塌的。
- 每题写判据而不是写标准答案文本：判据可以是字段级断言、必须包含的实体、必须调用的工具序列，避免用人工主观打分。
- 用例集有防污染纪律：进入回归集的题目要登记来源，出现泄漏（题目进了公开语料或者内部文档）时立刻标记并换题，同时保留换题记录，否则跨批次不可比。
- 逐档跑的输出形态固定成一张表：场景组、档位、通过率、失败样本标识、失败形态分类。看的是失败出现在哪一档哪一组，形成一条”档位—失败”的边界线。
拿到边界线以后，定档才有依据：某一业务场景定在低档，必须能指出它在低档没有失败样本，或者失败样本的代价可以接受。指不出来就不算定档，只是默认。
五、观测指标与端到端时间的账
上线后至少盯这几项：单任务成本（按场景组算，不按总额算）、重试率、低档升到高档的比例、用户投诉量与返工量、端到端完成时间。
低档快但容易返工，这件事要和延迟预算对着算。单请求时间只是链路耗时的一段，用户关心的是从提问到拿到可用结果的时间。低档省下的那一点，如果被一次重试和一轮人工修正全部吃掉还倒贴，端到端反而更慢。所以我们要求把端到端时间按场景组分档统计，同时统计”一次通过占比”。当低档的一次通过占比明显低于高档，而端到端时间没有优势时，降档在这类任务上就是亏的，即使账单上看着省。
- 重试率与升档比例要一起看：升档比例高说明首轮判定过于自信，需要把该类任务定档上调。
- 返工量必须有归属：谁改的、改了几轮，这是判断档位是否真的省钱的关键数据，缺了它就只剩账单。
- 投诉按场景分类回填到用例集，作为下轮回归的新样本，让用例集随真实失败持续补充，而不是定一次用一年。
六、版本快照、档位映射与合同口径
供应商这一侧有两个坑要靠记录来防。
第一个是改名与含义漂移。档位名相同不代表含义相同：模型版本升级后，同名档位对应的实际行为可能整体往上或往下挪。应对办法是留版本快照与档位映射表——每一次回归都记录模型版本标识、档位取值、通过率与成本，模型版本变动时先在原用例集上重跑，再决定映射关系是否沿用。这张表同时是解释成本波动的证据：账单变了，先看是不是版本换了导致同档含义变了。
第二个是合同口径。服务等级里要不要写模型档位，我们的取舍是写行为不写型号：合同里承诺可测的行为指标（一次通过占比、端到端时间分位值、需要人工确认的动作清单），把档位与映射表作为内部实现与举证材料保留调整空间；同时明确供应商侧版本变更、档位含义变化时我们要在约定时限内复测并同步客户。把”永远使用某高档位”写进合同，等于把一个会漂移的技术参数当作法律承诺，后面无论怎么调都是被动。
对客户方我们也建议反过来用这条纪律：验收时要求交付方提供档位映射记录与按档回归的失败清单，而不是接受一句”已配置为最高档”。这两样东西在洹拓的交付验收包里是标配，因为它们能证明档位是定出来的，不是默认落下来的。