AI 不必什么都会说：蚂蚁把「判断」单独做成模型，一张工单省下 90% 的 Token

过去两年，企业接 AI 的默认动作是「上一个会说话的模型」：写文案、总结会议、生成周报。但真正跑在业务系统里的调用，绝大多数并不需要一段漂亮的文字——它们需要的是一个判断：这条咨询是催单还是投诉、这张工单该派给售后还是物流、这笔订单要不要人工复核、这个客户的话术里有没有违规承诺。

这些任务的共同点是选项有限、要求稳定、调用频次极高。用通用大模型做，链路是「先生成一段结构化文本，再由程序解析、校验、兜底」，任何一步格式抖动都要重试。蚂蚁数科在 10 月 22 日发布的 LingDT-Decision-1.0，切的就是这段浪费：不做生成，直接给判断。

这个思路并不新鲜，Jev 走红之后，微软、Perplexity、Cloudflare 等都推出了同类模型。LingDT 的差异在于场景收窄——它不追求做一个通用决策层，而是盯着客服、风控、金融这三类「复合决策 + 多步骤流程」的活儿。

为什么是现在？因为企业算清了一笔账：一个每天处理两万条咨询的客服中心，如果每条都由模型生成三百字，输出端的账单会随咨询量线性增长；而其中九成的判断，本来只需要在五个选项里选一个。当 AI 从「演示」走进「每天跑几万次」，成本与延迟就成了比文采更硬的指标。

传统大模型的输出是一串 token，决策模型的输出是一个选项、一个分数或一个是非判断。听起来只是格式差别，实际影响的是整条工程链路：业务系统不需要再写解析器去猜模型的意图，也不需要为重试设计复杂的兜底逻辑，拿到结果就能直接进下一个节点。

LingDT-Decision-1.0 支持判断、单选、分类、评级四类基础能力，覆盖了企业里最常见的判定形态。它的上下文窗口为 64K，足够塞进一段对话历史、一张工单的完整字段和一份候选选项表。

更关键的是成本结构。通用模型按输出 token 计费，判断类任务的输出往往只有几个字，但模型为了「想清楚」会先生成几百字推理；决策模型把这段推理压到最小，账单自然就下来了。官方给出的数字是：处理同样任务，Token 消耗比大语言模型低 90% 以上，响应时效最高提升 10 倍。

官方举的例子很日常：客户发来一句「这个订单已经三天了还没发货，请尽快处理」。人看一眼就懂，但要让系统自动处理，得连续做四个判断——问题类型是催单、退款还是投诉；工单紧急度要不要优先；归属部门是仓储、物流还是客服；风险上是否需要人工接管。

这四道题如果交给通用模型，通常会得到一段「您好，关于您反馈的发货问题……」的回复，然后由另一套规则去猜它到底想表达什么。决策模型则直接返回四个选项，系统拿着结果就能派单、计时、升级。

实测数据也围着这条链路：在智能客服场景中对比 Qwen-3.7-flash，Token 消耗降低约 90%，处理时效提升约 1 倍，风险识别准确率从 76% 提升到 89%；在数据标注场景对比 DeepSeek-V4-flash，Token 降低约 97%，时效提升约 10 倍。

这四道题的价值不在难度，而在频次。按每条判断省下 20 秒、一天两万条计算，累计约 111 个小时——这部分时间过去被分散在每个坐席的日常里，看不见，也从来没被计入成本。决策模型真正卖的，是把这些碎片时间收拢成一条可计量的账。

真正让这套模型和「分类器」区分开的，是原生多选与按序决策。企业里的请求很少是单一意图，更常见的是「我要退款、关闭续费、补开发票，但不要注销账号」——单选模型只能抓主诉求，很容易漏掉后面几项，然后引发第二次投诉。

原生多选让一次判断可以同时命中多个候选，适配多标签识别、复合意图和工具组合；按序决策（DAG）则进一步处理依赖关系：退款要先核验、关闭续费可以立即执行、发票要等退款结果出来再开。这个顺序不是模型随手排的，而是按任务之间的依赖关系推出来的。

这两件事听起来像产品功能，实际是架构问题。多数企业的工单系统里，「类型」「优先级」「归属部门」是三个独立字段，由三套规则分别赋值；一旦遇到复合诉求，规则之间就开始打架。要让决策模型发挥作用，得先把这些字段的候选集和依赖关系梳理清楚。

官方给的评估口径是「决策能力综合指数 = 90% 单选均分 + 10% 多选均分」，单选部分取 13 项开源基准平均，多选部分取 10 项。在这个口径下，27B 版本拿到 84.23，4B 版本 79.24，分别在同尺寸组里排第一。

横向对比更能说明位置：Microsoft-Decision-1 是 81.61，Jev 1.13.0 是 80.20，Fastino/GLiDE 是 83.65，start-lux-27b 是 82.67，Cloudflare Clef-27B 是 82.06。27B 版本领先幅度不算碾压，但确实站在第一梯队。

真正拉开差距的是多选：榜首 66.14 分，次席 51.07 分，中间空了 15 分。这个断层说明多数决策模型仍然停留在「选一个最可能的」，而企业真实业务早就不是单选题。对采购方的启示是，看这类模型别只看综合分，要按自己的任务形态去挑——如果业务里复合诉求多，多选一项的权重应该远高于 10%。

还有一个容易被忽略的口径问题：这些基准的题目分布，和企业真实工单的分布并不一致。公开数据集里语义清晰的短句居多，真实工单里则充满错别字、语音转写错误、夹带截图和一句话跨三个话题的情况。榜单能证明模型的上限，证明不了它在你的长尾数据上的下限。

省下来的钱不是靠「模型更小」，而是靠「不生成」。通用模型处理一条工单，输入可能是 800 token 的对话历史，输出是 300 token 的推理加回复；决策模型同样输入 800 token，输出只有 10 来个 token 的选项编号。按输出计价的部分直接缩了两个数量级。

但这笔账要算全。决策模型不负责解释，所以系统里必须另外留一条「为什么这么判」的链路——要么记录候选集与置信度，要么在关键节点保留人工复核。这部分日志与回放能力，是很多企业上线后才发现缺失的。

第二个要改的是兜底。通用模型答不好时还能给一段模糊的话糊过去，决策模型只会给出一个选项；一旦候选集里没有正确答案，它会非常自信地选错。所以上这类模型之前，先确认业务上存在「其他/转人工」这个出口，并且这个出口的触发率是被监控的。

第三个要改的是路由。最省钱的架构往往不是「全用 27B」，而是「4B 打底、27B 兜疑难」：入口先用 4B 处理八成常规判断，把置信度低、候选冲突、涉及金额的请求转给 27B 或人工。这套分级路由的收益比换模型更大，因为它把昂贵的算力只花在真正需要的地方。

决策模型有一个硬前提：答案必须在你给的选项里。这意味着它的能力上限由业务设计决定，而不是由参数量决定。候选集漏了一个常见类型，模型就会把这类请求硬塞进最接近的选项；候选集里两个选项语义重叠，模型就会在两个之间来回摇摆。

第二个边界是开放问题。客户情绪安抚、方案解释、跨部门协调这类需要生成与共情的工作，决策模型帮不上忙，也不该让它帮。合理的架构是分层：入口用决策模型做分流与判定，真正需要沟通的环节交给生成模型或人。

第三个边界是评测口径。官方的 23 项基准大多来自公开数据集，和某家企业真实的工单分布差别很大。上线前至少要用自己过去三个月的工单跑一遍，看看在长尾类型上的准确率，而不是只看综合分。

第一件事，把「判断」从人脑里搬到纸面。客服主管心里其实有一张表：什么话术对应什么类型、什么情况要升级、哪个部门接哪类单。把这张表写下来，就是候选集与路由规则的雏形。没有这张表，买什么模型都是浪费。

第二件事，让系统留下判定痕迹。工单是谁改的 type、什么时候改的、改之前是什么，这些字段决定了你日后能不能复盘、能不能训练。很多企业的工单系统只有「当前状态」，没有「状态变迁」，一旦出问题就查不清。

第三件事，从高频低风险场景切入。咨询分类、派单路由、满意度回访归类，这些判断错了代价可控；等准确率稳定在可接受区间，再往风控、授信、退款审批这类高价值场景推进。决策模型的价值不在「一步到位」，而在「把每天几千次的判断成本压下来」。

最后是组织配套。模型上线后，客服主管每周要抽一批判错的样本看：是候选集缺了一类、还是规则写得太粗、还是客户表达确实模糊。这件事没人做，模型的效果会在三个月内悄悄退化——不是因为模型变差，而是因为业务变了、话术变了、新品类冒出来了，而候选集还停在原地。