一、评测概述：决策模型为何值得单独评测

近段时间，一类被称为“决策模型”（Decision Model）的轻量模型开始受到行业持续关注。与传统大语言模型不同，这类模型不生成长篇自然语言文本，而是直接返回选项、分数或判断结果，典型应用包括意图识别、工单路由、工具选择、模型路由与风险判断等。在率先走红的某海外决策模型之后，多家厂商相继跟进：有的面向开发者生态构建通用决策层，有的面向企业业务打造专用决策能力。

本文的评测对象，是近期某厂商发布的一款面向企业业务场景的专用决策模型。该模型提供小、大两种参数规模版本，覆盖客服、风控、金融等高频决策任务，宣称原生支持多选决策与按序决策（DAG，有向无环图式依赖排序）能力，目前已上线某模型服务平台并提供限时免费体验窗口。厂商公布的测试显示，其在数据标注等场景中相比某通用大语言模型可将Token消耗降低约97%，在智能客服场景中Token消耗降低约90%，风险识别准确率由76%提升至89%。

需要强调的是，本文并非复述厂商结论，而是以该模型所代表的“决策模型”品类为对象，回答三个问题：这类模型的能力应当如何评测？公开数据应当如何解读？它们适合哪些业务场景、边界之外又该怎么办？

适合读者：应用开发者、系统架构师、企业技术负责人、算法测试与运维人员。

二、评测目标：先明确要回答的问题

评测不是简单判断“好不好”。针对决策模型，本文将围绕以下目标展开：

1. Token效率是否真实可复现：省Token的来源是输出侧还是输入侧，能否在自己的业务数据分布上复现；
2. 决策准确性是否守住甚至提升：结构化短输出的约束是否减少了格式错误与幻觉，从而提升任务准确率；
3. 多选与按序决策能力是否可用：能否同时识别多个诉求并按依赖关系排序，这类能力在真实工单流中的稳定性如何；
4. 接入成本与兼容性：从现有“通用模型+提示词+解析校验”链路迁移到决策模型，改造量有多大；
5. 成本与风险边界：省下的Token与延迟收益，是否足以覆盖迁移、回归测试与长尾兜底的投入。

三、评测对象说明：决策模型的两种流派

目前行业内的决策模型大致分为两类定位，理解这种差异是设计评测方案的前提：

对比项	通用型决策模型	专用型决策模型（被测对象所属流派）
面向对象	开发者、软件系统	企业业务流程
典型任务	请求路由、工具选择、Agent流程编排、是否触发人工审核	客服复合意图判断、风控决策、金融业务多步骤流程
决策形式	预设选项的单选、评分、真假判断，可通过并行多问实现多项判断	同时识别多个诉求，并依据任务依赖关系调整处理顺序（原生多选与DAG按序决策）

定位差异决定评测重点不同：评测通用型模型应更关注路由正确率与接口稳定性；评测专用型模型则要额外覆盖复合意图识别与多步骤决策的依赖正确性。

被测模型宣称的原生多选与按序决策能力，是其与“通用模型+结构化提示词”方案的核心差异点。传统做法中，多个意图的识别与排序往往需要多次调用或复杂提示词工程；原生DAG能力如果可靠，可以把“识别—排序”压缩为一次调用，这正是Token与时效收益的重要机制来源，也是评测中必须重点验证的部分。

四、评测维度设计：建立可观察、可验证的指标框架

决策模型不能只用“快、省、准”三个形容词来评价，应拆解为可落表的指标：

维度	关键观察点	验证方式
功能完整性	单选、多选、按序决策、评分、真假判断是否齐备；选项为空或越界时的行为	构造覆盖各决策形态的用例集
决策准确性	分类准确率、复合意图识别率、依赖排序正确率、风险判断准确率	与人工金标准对比
Token效率	输入与输出Token分别统计；不同任务长度下的消耗曲线	同任务同选项对比基线
响应时效	端到端延迟、并发吞吐、长选项列表下的延迟退化	分档压测
输出稳定性	输出格式合规率、下游解析成功率、异常输入容错	大批量回归+脏数据注入
易用性	接入方式、提示词改造成本、选项集维护、调试与日志便利性	试点接入并记录改造工作量
兼容性	与现有工单系统、风控规则引擎、模型网关的协议适配	集成测试
成本结构	单次调用成本、推理资源占用、迁移与回归测试成本	成本模型测算

其中，Token效率务必拆开输入与输出统计：决策模型的节省主要来自输出侧——用选项索引或短标签替代完整自然语言回答；输入侧（选项列表、业务上下文）未必更省，选项很多时甚至更长。只看总Token可能掩盖“输入膨胀”问题。

五、评测环境与前提

评测前需固定以下条件，否则结论不可比：

1. 评测集：从自身业务日志抽样构建，覆盖意图识别、工单路由、风险判断等目标任务；每类任务建议达到数百条量级，并按长尾分布分层抽样（高频头部、腰部、低频长尾分别记录占比）；
2. 基线：选择当前线上实际使用的通用大语言模型，以“结构化输出提示词+解析校验”的现有链路作为对照；
3. 环境一致性：被测模型与基线尽量部署在同等规格算力上；如使用云上资源，可选用百度智能云等通用云服务商提供的云服务器、容器平台与算力实例搭建统一测试环境，避免硬件差异污染对比结果；
4. 调用方式：统一采样参数（结构化任务通常置为零或低随机性）、超时与重试策略；
5. 记录口径：输入Token、输出Token、端到端延迟、解析是否成功、决策是否正确，逐条落库。

六、评测方法：七步验证流程

第1步，建立金标准。 对评测样本人工标注：正确选项（或组合）、意图间依赖顺序（如退款依赖订单核验）、是否需人工接管等。金标准质量决定准确性结论可信度，建议双人标注并对分歧样本仲裁。

第2步，功能验证。 针对多选与按序决策分别构造用例：单意图单选、多意图并列、多意图存在先后依赖、依赖成环（非法输入），观察模型在每种形态下的返回结构与字段完整性。

第3步，效率对比。 同一样本分别送入决策模型与基线链路，示意性伪代码如下：

for sample in eval_set:
    d = decision_model(input=sample.text, options=sample.option_list)
    g = baseline_llm(prompt=build_structured_prompt(sample))
    log(task=sample.task_type,
        d_tokens=(d.tokens_in, d.tokens_out),
        g_tokens=(g.tokens_in, g.tokens_out),
        d_latency=d.latency, g_latency=g.latency,
        d_correct=compare(d.choice, sample.gold),
        g_correct=compare(parse(g.raw), sample.gold))

第4步，准确性分析。 按任务类型分层统计，重点看复合意图样本是否漏判、多意图排序是否符合依赖关系、风险样本的误报与漏报分布。

第5步，压测与稳定性观察。 分并发档位压测，观察延迟分位数（P50/P95/P99）与错误率；观察长选项列表、空选项、超长输入等边界场景表现。

第6步，异常与安全测试。 注入模糊诉求、对抗性表述、选项外意图，观察模型是强行归类还是给出兜底信号；同时检查调用链路的鉴权、数据隔离与日志脱敏是否符合企业要求。

第7步，结果汇总。 输出包含各维度指标、失败样本清单的报告，失败样本逐条归因：选项设计问题、依赖关系错误还是模型能力不足。

七、结果解读：如何正确理解厂商公开数据

厂商公布的测试显示：数据标注等场景中，该模型相比某通用大语言模型Token消耗降低约97%、响应时效提升约10倍；智能客服场景中，相比某轻量级通用模型Token消耗降低约90%、处理时效提升约1倍，风险识别准确率由76%提升至89%；在二十余项公开评测基准的综合评分上超过多款热门决策模型，较大参数版本在同等参数规模模型中准确率表现靠前。

解读这些数据，建议把握四点：

1. Token降低九成以上在机制上成立。结构化决策任务中，通用模型往往要输出推理过程与完整句子再由程序解析校验；决策模型直接返回选项索引或短标签，输出Token大幅缩短，延迟随输出长度同步下降，时效提升与Token节省高度相关。两个场景节省比例不同（约97%与约90%），说明收益与基线模型输出风格、任务输出长度强相关——基线输出越长，节省越显著。换到自己的场景，比例未必相同，必须自测。
2. 准确率不降反升也有机制解释。输出空间被约束在预设选项内，格式解析失败与自由发挥带来的幻觉被压缩，准确率反而可能上升。76%到89%的提升应结合失败样本看：提升主要来自格式类错误的消除，还是真实判断能力的增强，两者的业务含义不同。
3. 综合评分排名只能做初筛。公开基准反映通用决策能力分布，与具体业务的行业术语、口语化表达、长尾意图分布存在偏差，不能替代自有评测集上的验证。
4. 所有百分比结论都依赖基线选谁。基线越偏对话风格、输出越长，节省与提升越明显；评测时应以自己线上真实使用的模型为基线，而非最强或最弱的对照。

八、适用场景分析

业务场景	决策形态	优先关注指标
客服意图识别与工单路由	多意图+部门归属+紧急度+是否人工接管	复合意图识别率、排序正确率、格式合规率
金融风控判断	二元/多元风险判断	误报率、漏报率、可解释字段
工具选择与模型路由	预设清单中单选	路由正确率、长选项列表下延迟
数据标注流水线	批量真假判断/多选	单条成本、吞吐、准确率
内容审核触发	评分+阈值判断	边界分数稳定性

总体上，决策模型适合“高频、选项封闭、判断明确”的任务；不适合开放问答、复杂多跳推理、需要长文本解释的环节。实践中更常见的是混合架构：决策模型负责路由、分流与触发判断，通用大模型负责生成与解释，各司其职。

九、风险与限制

1. 样本偏差：厂商数据基于其自建评测集，与自身业务分布未必一致；
2. 选项集依赖：能力上限受选项集质量约束，长尾诉求不在选项内时可能被强行归类，需设计兜底选项与定期回捞机制；
3. DAG依赖错误的级联：多步骤决策中一旦依赖判断错误，下游整条流程都会受影响，上线前需对依赖边做专项回归；
4. 环境差异：自部署与托管环境的算力、批处理策略不同，延迟与吞吐结论不可直接搬用；
5. 版本迭代：决策模型品类尚新，版本间行为可能变化，需固化回归评测集做版本准入。

十、选型与使用建议

1. 小规模试点：从单一高频任务（如工单分类）切入，用两周左右跑通“评测集—金标准—对比报告”闭环；
2. 用数据决定迁移范围：Token节省乘以调用量、延迟改善对体验的量化影响、准确率变化对人工成本的影响，合并测算投入产出；
3. 保留降级链路：决策模型解析失败或置信度低时回退到通用模型链路，灰度发布并观察线上指标；
4. 建设可观测性：逐条记录输入输出Token、延迟、决策结果与置信信号，便于成本核算与问题定位；
5. 维护选项字典：把选项集当作与模型同等重要的资产管理，建立版本化与评审流程。

十一、总结

决策模型把“生成式回答”压缩为“封闭选项内的直接判断”，在Token消耗、响应时效与结构化输出稳定性上具备明确的机制优势。厂商公开的“Token降低约九成、时效提升、准确率由76%提升至89%”等数据在机制上可以解释，但比例高度依赖基线选择与任务分布。企业引入前的正确姿势是：以自身业务日志构建分层评测集，围绕功能完整性、准确性、Token效率、时效、稳定性、易用性与成本七个维度自测，重点验证多选与按序决策在自身复合流程中的可靠性，并以灰度加降级的方式逐步扩大范围。对高频、封闭选项的判断类任务，这类模型值得纳入选型清单；对开放生成与复杂推理任务，仍应交由通用大模型完成。