只输出选项和概率的模型：判别层的接口契约与阈值工程

只输出选项和概率的模型：判别层的接口契约与阈值工程

最近在整理公司内部那套工单自动分流的链路，顺手把一类新模型放进去试了一遍。这类模型不写一个字，只回一个选项、一个档位或者一个概率。刚开始我以为它不过是"便宜版分类器"，跑了两周之后发现，它在系统里的位置、该盯的指标、出问题的姿势，跟分类器和大模型都不一样。这篇把这两周的结论整理一下，偏架构和工程，不涉及模型内部原理。

一、先说它在链路里站哪个位置

我们现有的做法，你应该也熟悉：

• 输入进来先过规则；
• 规则兜不住就丢给大模型，让它按 schema 吐一段 JSON；
• 外面再包一层解析 + 字段校验，格式不对就重试；
• 重试几次还不行，降级到人工。

这条链路有个别扭的地方：判断任务只需要一个标签加一个分数，我们却先让模型写了一整段话，再从话里把标签抠出来。

判断型模型就是把这一步砍掉。它的输出空间是锁死的------你给选项，它只能从你给的选项里挑；你给刻度，它只能在刻度上定位；你给一个命题，它只返回这个命题为真的概率。没有自由文本，就没有解析层，也没有重试层。

按分层来看，它属于判别层，不属于生成层：

• 判别层往下游输出路由结果、风险等级、审核队列归属；
• 生成层负责解释、摘要、回复草稿。

这两层的指标、SLA、失败处理方式都不一样，混在一层里会很难维护。

二、接口只有三种形状

它对外暴露的问题类型只有三种，先把契约钉死，后面所有设计都围绕这个来。

1. 枚举选择

从给定选项里挑一个，选项上限大概在 255 个。工单该归到哪个部门、日志该判成哪类异常，都是这一类。

关键点是答案被锁在你给的集合里，它不可能返回一个你没定义过的值。这一点对下游很有价值------不需要写"未知值兜底"分支，因为值域是封闭的。

2. 有序打分

在一把有序刻度上定位，通常两到十档，也允许落在两档之间。严重程度、情绪强弱、置信分档都用它。

注意它是序数而不是连续值。别拿它当回归输出算平均值，那样没有意义。

3. 布尔 + 概率

给一个陈述句，返回它为真的概率。这里有个坑：它没有单独的置信度字段，概率本身就是那个数。

我看到有不少二手资料把它描述成 Bool，只取 0/1。这样写适配层会直接报错------返回的其实是一个浮点数。如果你只想要布尔，阈值得自己定，别指望接口给你。

三种类型可以在一次请求里并行求值：同一段材料上挂多个问题，互相隔离，多问几个几乎不增加响应时间。所以别一个一个问，那是纯浪费。

下面是一次调用的形态，大概长这样：

resp = judge(
    evidence=doc,                      # 一段待判断的材料
    questions=[
        {"id": "dept",  "type": "choice", "options": ["售前", "售后", "财务", "unknown"],
         "text": "该工单应路由到哪个部门？"},
        {"id": "risk",  "type": "score",  "range": [0, 9],
         "anchors": {"0": "无害", "9": "高危"},
         "text": "这封邮件的社会工程风险等级？"},
        {"id": "phish", "type": "bool",
         "text": "这封邮件属于钓鱼邮件"},
    ],
)

for q in resp.questions:
    print(q.id, q.answer, q.probability)

返回值可以直接拿去分叉，中间没有解析这一步。所以它的失败模式只剩一种：返回一个错的值。 没有"JSON 拼坏了"这种错误，这是省掉一整套工程的地方。

顺带说一句，结构化输出本来就没有"幻觉"的空间。以前那种"零幻觉"的说法在这里不成立------它省掉的是解析与重试的工程成本，跟模型判断得准不准是两件事。别把工程收益当模型能力。

三、和左右两个邻居的边界

选型的时候，判断型模型卡在两个极端中间，我把它总结成三条：

• 相比传统分类器：分类器的标签空间是写死的，改输出就得动模型，换个问法都得重训。判断型模型换题的成本约等于改一段提示词或换一组选项，不重训。
• 相比生成式大模型：大模型什么都能答，但每一问都要付 token 钱，约束输出还要额外写校验层，延迟也高。判断型模型不生成 token，延迟和单价都低一到两个数量级。
• 它的边界很硬：别指望它写摘要、生成代码、总结文档。它只会判断。

最后那条很关键。它的定价里没有"补贴"这个说法，但也没有"顺带干点别的"这个能力。用之前先问自己：这个任务是不是只要一个标签加一个分。如果不是，它就不合适。

从训练目标上也能看出这种分工------按可优化目标分，大致有这么几类：

• 优化"人类更喜欢哪个回答"的；
• 优化"程序能验证对错"的；
• 优化"模型对自己估计得准不准"的。

判断型模型属于第三类关注的范畴。前两类优化的是答得对不对，第三类优化的是它对自己把握的估计准不准。这正好引出下面这节。

四、估得准和答得对，是两件事

校准的定义只有一句话：在一大堆预测里，模型说 90% 的那些，大约有 90% 是对的。

它衡量的是"模型对自己把握得准不准"，不是"答得对不对"。

这句话很容易被读成一条保证，它不是。校准说的是一组预测的统计性质，单独抽一条出来，它不保证任何东西。一条标着 84% 把握的判断错了，下一条同样标 84% 的照样可能错。区别在于------错了有代价，但不代表系统失控。

由此推出一个设计原则：阈值不该给整个系统定一个，而该每个动作一条，按误判代价来定。

路由一个咨询工单，和批一笔转账，误判代价差几个数量级，本来就不该共用同一个门槛。

它该待的位置也很清楚：放在前面做漏斗。

• 置信度高的那一段直接走自动化，快、便宜、不用等人；
• 置信度低的那一段才升级给大模型或人工。

所以它不是替代大模型，而是把一批本来就要大模型判断的活儿提前分流掉，把最贵的那一层留给真正需要它的部分。

五、同一个模型，四份测评，四个数

这类模型出来没多久，测法还没统一口径。 我在公开场合看到过几份独立的校准测评，数字差得很远，大致是这样几组（越小越好，单位是同一种校准误差）：

• 某份测评自己给出的噪声地板：0.024
• 评审门控、3 路决策场景：0.037
• Agent 工具调用、60 条样本：0.071
• 客服工单、900 条样本：0.107
• 钓鱼邮件、2000 封样本：0.154

这些测评的场景、样本量、问题构造都不一样，横向比其实没多大意义。但它们有个共同点：都同意"把说错的和说对的分得很开"，分歧在于"这个概率到底有多准"。

几个值得注意的现象：

• 有一份评审门控的测评里，置信度门槛定在 0.5 就能自动化掉 98% 的决策，被自动化那批全对，剩下 2% 交人工。
• 但另一份两千封钓鱼邮件的测评发现，每个置信度分档都过于自信，最差的是 0.85～0.95 那一档，宣称 0.90 实际只兑现约六成。那位作者的结论是：没有任何门槛能安全地把这个置信度用于分流。

一份说能自动化 98%，一份说一条都省不了。这不是模型的好坏问题，而是校准跟着数据分布走。换一批数据、改了话术模板、客户群变了、出现新的欺诈手法，上个月还稳的概率门槛全部需要重算，而模型不会告诉你这件事。

还有两个测量层面的坑：

• 样本量差三十倍的数字不能放一起比。 另一份 60 条样本的测评里，有 50 条落在 0.9～1.0 这一档。这种分布本身就不正常，六十几条和两千条得出的结论不是一回事。
• 有人只报一个数，有人报整条分布。 只看单个数字，看不出分档失真，必须看分档曲线。

比较有价值的是那种"公开发布 + 可复现"的测评：头几天就有人跑出结果，而且比自己写得更细。有人直接指出模型"只是部分地完成了判断"，也有人把几天前的粗略估计拿回来重算。

这类公开的自我修正，比任何单个数字都有用。 所以在别人的数据上记一个 0.037 意义不大，真正的做法是在自己的数据上跑一遍。

六、落地会绊倒你的四个点

这部分是踩过才知道的。

1. 它不会弃权

强制二选一的时候，它不会说"不知道"，只会挑一个相对最不坏的。所以在选项设计里，你自己必须留一个 unknown 或者 needs_review 的出口，别指望它主动说"这个我拿不准"。

2. 选项顺序会造成偏序

同一个模型、同一批题，只把选项前后顺序换一下，准确率能从 72% 掉到 21%。这个偏序在小参数模型上尤其明显。结论很简单：选项顺序要固定，并且写进版本管理，不要随手改。

3. 版本会静默漂移

模型一动，校准就跟着漂，所有阈值同时失效。麻烦在于这不是系统级报错------只是各个分档的比例悄悄变了，不报警也不告警，你只能在指标上慢慢看出来。

做法有两条：

• 钉死带版本号的模型 ID，别用浮动别名；
• 把每次返回里带的版本号记进日志。

4. 阈值必须先看数据再定

在自己的标注样本上画一条"置信度 → 准确率"的曲线，再决定门槛压在哪。先拍一个阈值、再去找数据支持它，是这个环节最常见的自欺。

还有一条不算"坑"，但得提前知道：它不解释，不给任何理由。 需要审计或者问责的场景，必须再叠一个生成模型专门写说明，别指望它自己交代。

七、验收看的是曲线，不是单点准确率

很多人验收时只报一个准确率，这在判别层是没有意义的。

该看的是一条曲线：

• 横轴是置信度门槛；
• 一条线是门槛以上能自动化的样本比例；
• 另一条线是这批样本的准确率。

门槛往上拉，自动化比例下降、准确率上升。两个数字要一起看，才知道这条业务线能不能切出一块自动化。

举个具体例子。有一个从公开脱敏的客服历史里抽出来的数据集，整体命中率只有 0.598，很平庸。但是把门槛提到 0.8，能自动处理掉 34% 的样本，这一批里的精度是 0.92。

整体平庸，不妨碍切出一块可靠的自动化区间。反过来也成立：在可接受的风险下，它能替你干掉多少活，这才是验收要回答的问题。

部署形态上，这类模型适合自托管。目前已有 Apache-2.0 的完整实现，四亿参数级别、单张 T4 上三十毫秒一次、数据不出网。有两个互不相干的复现都得出同一句话：能力来自微调，不来自权重------直接用基座权重，准确率低到接近"永远输出最常见那一类"。好在它便宜，单卡把一批数据过一遍，几分钟、不到一块钱，跑一次校准的成本远低于接错一次的成本。

最后一句话总结部署原则：它该嵌在流水线里做判断，不该让它往外写字。

八、划线的人、留的记录

"这个判断做错一次要赔多少"，这不是技术参数。

这条线本质上是一次业务授权：划下去就等于说"这类事以后不用每次都问人了"。所以它该由承担这个后果的人来画，不是由调参的人顺手定一个。

配套要留的记录有三样，缺一样半年后就会说不清：

• 门槛画在哪个值；
• 当时用的是哪个模型版本；
• 这个门槛是在哪批数据上量出来的。

少了这三样，没人说得清为什么是这个数，也就没人敢动它。

小结

过去我们担心模型编造不存在的东西。到了判断这件事，风险换了个形状：它的答案永远"合法"，只是有时候不对；而且它会顺带告诉你自己有几成把握。

真正要盯的不是那个标签，而是那个概率值不值得信。而"值不值得信"这件事，从来不会写在文档里，只能在自己的数据上量出来。