面向产业决策的升级：蚂蚁数科LingDT-Decision 首发信息抽取能力

以 Jev 为代表的决策模型仅能够处理单选、判断等问题类型， 然而产业决策过程中除了做选择判断，还需要从上下文中抽取部分信息来综合决策，例如金额，日期等，当前的决策模型暂时无法提供此类问题的解决方案。

针对此类问题， 蚂蚁数科决策模型 LingDT-Decision 对 System One 协议进行拓展，首发信息抽取能力。该模型通过 mid-train、强化学习等技术深度适配产业侧对决策精度和效率的双重需求。

目前，LingDT-Decision 模型的信息抽取性能已经超过同尺寸甚至更大尺寸生成式模型的效果，并且兼具速度优势和推理可靠性。LingDT Decision 模型目前已在蚂蚁数科 DTMaaS平台开放，Slotting 功能可参考 DTMaaS 公开调用示例进行免费体验。

系统需要判断工单派给谁，用 Jev 等决策模型处理上述工单，大致流程： 把客户原话放进 state，再在 questions 里问「这条工单该交给谁」，给出账单、物流、账号三个选项，然后调用请求：

{"state": "订单 A123 多扣了 199 元，退款等了一周还没到。","questions": {"department": {"type": "choice","instructions": "这条工单最适合交给哪个团队处理？", "criteria": { "billing": "扣款、账单或退款问题", "shipping": "物流、包裹或配送问题", "account": "登录或账号设置问题" } } }}

复制代码

{"answers": {"department": {"type": "choice","choice": "billing","probabilities": { "billing": 0.94, "shipping": 0.04, "account": 0.02 },"confidence": 0.91 } }}

复制代码

后台读到 answers.department.choice 是 billing，就可以把工单送进账单队列。

客服点开工单，得先找到客户说的「199 元」，再和扣款记录核对，但退款金额是一个开口的数值类型，难以使用选择、判断或者评分功能来提取。

针对当前 System One 模型的缺陷，LingDT-Decision 在 System One 协议上新增了信息抽取功能，原生支持 extract 题型来处理信息抽取。应用指定要找「多扣金额」，模型可以返回对应的原文片段和位置，客服就能在工单里看到「199 元」被划出来。

思考一个问题，上述 Jev 响应里的三个概率是怎么来的？以 Jev 的开源实现 Kev 来看，整个过程可以拆成几步：

拼接输入 → 基座 Prefill → 取特定 Token 的向量 → 计算目标 token 的概率 → 返回结果，如下图所示：

后面接工单原话， 后面接题目；每个候选的名字和描述用 、 包起来，最后放一个 。注：这里用便于阅读的标签表示特殊 token，实际看不同基座选取不同 token。

<state>订单 A123 多扣了 199 元，退款等了一周还没到。<instruct>这条工单最适合交给哪个团队处理？<opt>billing: 扣款、账单或退款问题</opt><opt>shipping: 物流、包裹或配送问题</opt><opt>account: 登录或账号设置问题</opt><decide>

复制代码

基座模型对编码后的序列做一次前向计算，得到每个 token 位置的隐藏向量。针对 Choice、Score、Noul 问题取三个 和最后一个  位置的向量进行概率计算。首先把决策位 的向量经线性投影得到 q，三个候选结束位向量经同一个候选投影层得到 k₁、k₂、k₃。打分头用 q 和每个 kᵢ 做缩放点积，得到三个分数，然后基于任务的不同，计算每个选项的概率值。

还是以上述工单为例，问题从「交给哪个部门」换成了「多扣了用户多少钱」。前者有三个预设选项，而后者的答案就在客户原话里。LingDT-Decision 沿用了拼接输入 → 基座 Prefill → 取特定 Token 的向量 → 计算目标 token 的概率这条路径，解决信息抽取的问题，如下图所示：

<state> 此处放历史上下文信息<instruct>从下面正文中抽取预定义的实体类型<context>订单 A123 多扣了 199 元，退款等了一周还没到。</context><slot>overcharge_amount：这笔订单中多扣的金额，保留原文单位。</slot><decide>

复制代码

取哪些位置的 token 向量？

Prefill 之后，除了 和 ， 还需要抽标签内部的每个 token 的向量表示，用于后续的概率计算。

抽取头为原文的每个 token 给出三个分数：B 是片段的开头，I 是片段的延续，O 表示不属于这个片段。在同一个 token 的 B、I、O 三个分数之间利用 softmax 计算标签概率。与 Choice 给每个选项分配概率不同，这里概率是针对标签下的原文的每个位置进行计算的。

相比于其他决策模型，LingDT-Decision 目前额外支持信息抽取和多选两种原生能力，并通过 mid-train、强化学习、OPD 等技术实现企业真实应用场景的深度对齐。在 23 项开源评测基准中，LingDT-Decision 模型的综合评分超过了 Microsoft-Decision-1、Jev 1.13 等热门决策模型，其中 27B 的版本在同参数规模的模型中取得最高准确率。

（图注：LingDT Decision 的 4B/27B 版本的优势区域，覆盖了相关尺寸包括 Jev、MS Decision、GLiDE 等决策模型，表现出极强的综合性价比）

选取信息抽取 10 个典型的 bench 进行评测，结果显示，目前 LingDT-Decision 模型的整体性能已经超过同尺寸甚至更大尺寸生成式模型的效果，并且兼具速度优势和推理可靠性。

覆盖 23 项主流开源评测基准的测试结果显示，LingDT-Decision 的 27B 版本综合评分（90%x 单选评分+10%x 多选评分）位居第一，准确率超过 Microsoft-Decision-1、Jev 1.13.0、Fastino/GLiDE 等热门决策模型。

其中，在多选任务上，LingDT-Decision 的 4B 和 27B 版本的准确率表现超过 Microsoft-Decision-1、Jev 1.13.0、Star-lux 等 16 个决策模型，体现出原生多选能力在多标签与组合判定任务中的优势，在单选任务上，位居第一梯队。

以前述工单案例为例，使用 LingDT-Decision 解决抽取类问题，可按下列请求体提交请求：

{ "state": ".....", "questions": { "overcharge": { "type": "extract", "instructions": "抽取这条工单中多扣的金额。", "criteria": { "overcharge_amount": "这笔订单中多扣的金额，保留原文单位。" }, "context": "订单 A123 多扣了 199 元，退款等了一周还没到。" } }}

复制代码

{ "answers": { "overcharge": { "type": "extract", "spans": [ { "type": "overcharge_amount", "text": "199 元", "start": 12, "end": 17 } ] } }}

复制代码

LingDT Decision 模型目前已在蚂蚁数科 DTMaaS平台开放，Slotting 功能可参考 DTMaaS 公开调用示例进行免费体验。