北京
把每个请求都发给最强的模型，答案质量确实稳，但账单也最贵——那些便宜模型本来就能答对的请求，你按旗舰价付了钱。按关键词或任务类型写死的路由规则便宜一些，可流量结构一变，规则就得重写。
置信度分级路由卡在两者中间。让模型给自己的答案打个分，再按这个分数决定去向：高分留在便宜模型上，低分转给更强的模型。OpenRouter 这份指南把它拆成了五步。
这个分数是什么，不是什么
分数是模型的自述。它和答案的其余部分由同一个过程生成，因此带着同样的不确定性。两个相同的分数，并不保证同样的正确概率。同一个 0.85，换个提示词、换个模型，都不能直接互换，它也不是经过校准的概率值。
能用的是排序，前提是你验证过。拿一批自己的请求跑一遍便宜模型，给答案打分，再按分数分组。如果低分档的答案确实比高分档错得更多，这个排序就可以用于路由——哪怕绝对数值不可信。你要找的不是"等于 90% 正确率"的那个分数，而是排序里那条分界线：线以上可以直接交付，线以下需要再调一次。
别指望从自由文本里读出不确定性。模型不确定时，没有任何规则要求它在行文里含糊其辞，也不存在一份固定的"犹豫词"词表供你解析。
第一步：用结构化输出拿到数值型置信度
让模型把置信度作为 schema 校验过的响应字段返回。传入 response_format，类型为 json_schema，同时要求一个答案和一个 0 到 1 之间的数值型置信度。这样每个响应都带着一个路由代码可以直接读取的数字，无论回答的是哪个模型。判断要不要升级，变成了比较数字，而不是解析语言。
schema 把 0 到 1 的范围写在字段描述里，而不是用 minimum 和 maximum 关键字。Anthropic 的结构化输出文档把数值约束列为不支持，所以描述写法才是跨供应商通用的那种。strict: true 会要求有原生严格模式的供应商精确执行 schema，但执行力度因供应商而异，有些只把它当作强提示而非保证，所以路由之前先校验解析出来的 JSON。
依赖它之前还有两项检查。其一，结构化输出支持是按供应商端点设置的，不是按模型——同一个模型可能由支持和不支持的供应商同时提供。在模型页筛选出至少有一个支持端点的模型，并在模型页的 Providers 区域查看 structured_outputs 参数。其二，在供应商偏好里设置 require_parameters: true，这样请求只会被路由到支持其中全部参数的端点。没有这个标志，response_format 只是软性偏好：模型有支持端点时会路由过去，但若一个模型的端点全都不支持，请求照样发出，参数被忽略。
第二步：从自己的错误率里定出起始阈值
阈值来自测量你自己的流量，不是从指南里抄一个数字。用上面的 schema 把一批有代表性的请求跑过便宜模型，记录置信度分数和每个答案是否正确，在错误率开始爬升的地方设下截断点。线以上的请求由便宜模型解决，线以下的升级到更强模型。
起步时偏保守。一开始过度升级、之后再放宽阈值，代价是钱；升级不足，代价是交付了自信的错误答案。
举个算例。假设你把 200 个有代表性的请求跑过便宜模型，按分数档分组统计。错误率在 0.70 以下急剧攀升，那么 0.7 就是候选截断点。阈值取 0.7，会升级它下面的两个档，占请求量的 14%，其余 86% 由便宜模型解决。
在这个样本里，便宜模型的整体错误率略低于 10%。升级最底部的 14%，能把保留下来的答案错误率压到约 4%，代价是大约每七个请求多打一次电话。在自己的流量上跑这件事的意义，是找到你自己的截断点，而不是采纳 0.7。
第三步到第五步：调阈值、写路由、上线后继续调
阈值要在准确率、成本和延迟三者之间反复调。低置信度请求的路由逻辑写在你的代码里，而不是交给模型自己决定。上线之后还要持续监控并重新调参——流量分布会变，今天合适的截断点，过一阵未必还合适。
指南最后列了一节常见错误。整套流程的落点很朴素：先量出自己的错误率曲线，再让数字决定哪些请求值得多花一次调用。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
