GLiNER2.5-Decide：哪些选择题，不必再让大模型长篇推理？

2026 年 9 月 24 日，Fastino 发布 GLiNER2.5-Decide：一个约 3.4 亿参数、可以在本地 CPU 上运行的结构化决策模型。它接收文本和预先定义的问题、候选答案，返回判断及置信信息；重点不是写文章，而是替软件完成一组有明确选项的判断。官方发布说明

在一个智能体流程里，未必每一步都需要一位会长篇论述的助手。用户发来一张工单，先判断它属于哪个队列、是否紧急、需不需要人工接管，这些步骤往往更像选择题。GLiNER2.5-Decide 瞄准的，就是这一类工作。

它不是缩小的聊天机器人，而是另一种输出方式

通用大模型可以围绕一个问题逐步生成解释、计划和答案。GLiNER2.5-Decide 采用非生成式编码器路线：将文本与问题结构共同编码，对允许的答案给出匹配分数，再在约束条件下选择结果。它不需要先写一段自然语言，再让程序从回答里找出那个标签。官方架构说明

这里的 Schema（结构定义，读音 skee-muh）可以理解为一张明确的答题卡。你事先告诉模型，哪些问题只能单选，哪些允许多选，哪些是有序等级，以及不同答案之间有哪些规则。输入仍可变化，但输出空间是受约束的。

*图：Fastino 的输入输出示意，以识别提示注入为例。图中的分数用于展示输出结构，不是本文实测，也不能当作中文业务中已经校准的概率。*

例如，软件可以让它从“账号问题、网络问题、功能咨询”中选择工单类型，而不是要求它自由写一个部门名称。这样程序拿到的是定义内的结果，更方便后续处理。不过，格式合法只解决了“软件读不读得懂”，没有保证“分得对不对”。

多个判断需要一起成立，而不只是各选最高分

假设有一条工单：“账号异常，无法进入系统；已经连续影响两位同事工作。”下面是用于解释机制的业务设计例子，不是模型实测输出。

如果逐个问题独立选最高分，可能得到互相冲突的结果。官方介绍的联合解码会把相关答案一起考虑，寻找满足规则的高分组合，并返回是否可行的信息。这个机制可以减少“一个字段说需要阻断，另一个字段却允许继续”之类的矛盾。联合约束与解码示例

*图：官方用同一个提示注入例子展示两个判断如何发生冲突，以及规则如何要求它们一致。它说明的是约束关系，不是所有攻击都能被识别的安全保证。*

但规则一致，不等于事实正确。模型可能先把文本理解错，再生成一组内部十分一致的错误判断。规则也可能写得不合理，让系统无法找到合法组合。因此，可行性、分类准确性和业务安全性应该分别检查，不能合并成一个“可信”的开关。

还有一个容易混淆的细节：同一模型可以执行实体、关系和结构化记录抽取，但分类答案本身并不自动返回对应的原文证据位置。需要可追溯依据的业务，应明确请求相关抽取任务，不能假定每个标签都有一段已经验证过的原文支撑。输出类型的区别

本地运行的意义，是让小判断不必每次经过云端

Fastino 以 Apache 2.0 许可开放模型，并明确支持本地、CPU 和隔离网络部署。对明确标签的分类与分流，这给了开发者一种与云端通用模型不同的选择。部署与许可说明

这里的 Routing（路由或分流，读音 roo-ting）不一定是网络路由，也可以指“把这项请求送给谁”。一个合理的候选流程是：简单请求进入固定处理路径，复杂问题送给更强模型，含糊或高风险情况交给人工。小模型承担分流，不负责假装自己能完成后面的全部工作。

这也解释了决策模型与通用大模型为什么不必互相替代。前者把有限选项判断做成低延迟组件，后者仍处理开放问题、复杂说明和长期规划。是否能降低总费用，要看分流本身是否可靠：一次错误升级可能只多花钱，一次错误放行却可能导致后续整条流程返工。

公开分数有参考价值，但不是对所有决策任务的保证

发布方的 fast-decisions 测试集覆盖 17 个领域，每个领域 300 个保留测试样本，共 5100 个。所有模型收到相同文本和候选标签，只有预测标签集合与参考答案完全一致，才计为正确。测试口径

截至本文核对时，数据卡给出的均值如下：

这是发布方设计并报告的测试，不是本站独立测评。9 月 24 日博客使用的发布快照为 GLiNER 60.1%、JevK5 57.5%，与当前数据卡有小幅差异；两组数据不应取平均，也不应画成同一版本的精确排名。博客快照与当前数据卡应分别标注。

*图：9 月 24 日厂商发布快照，保留 60.1% 与 57.5% 的原始数值，不替换为当前数据卡数值。测试由 Fastino 组织；JevK5 是开源复现，图表不能证明对官方 Jev 的领先。*

更重要的是，JevK5 是开源复现，不是 TypeSafe 官方 Jev，这套测试也不是 JevBench。因此这些结果不能改写为“GLiNER 已经击败官方 Jev”，更不能把英文工单分类成绩外推为中文业务准确率。

60.2% 也提醒我们：可解析、有约束的输出，并不等于可以不设复核。测试任务较多、标签定义各不相同，平均值未必代表某一行业；真正部署时，应查看目标类别的混淆情况和错误后果。

有多快，要连同输入长度和机器一起看

官方延迟实验采用两个分类头、共 15 个标签，batch 为 1。对于 64 token 的短文本，端到端 p50 中位延迟如下：

这里统计的是整次短请求，不是每生成一个 token 的速度。它与大模型常见的“每秒多少 token”属于不同单位，不能直接做倍数排名。完整延迟条件

为什么这组短请求中 A100 没有更快？官方解释是预处理与内核启动的固定开销占比较大；输入增至 1024 token 后，A100 的中位延迟为 52.6 毫秒，V100 为 75.6 毫秒。硬件优势是否出现，取决于工作量，而不只取决于显卡名称。

这些数值支持“适合短文本在线判断”的方向，但不能当作普通笔记本或某张家用显卡的速度承诺。业务文本更长、候选标签更多、并发更高，都需要重新测量。

中文用户要先选对版本，再谈效果

当前标准 GLiNER2.5-Decide 是英文模型；另有约 2.87 亿参数的多语言版 GLiNER2.5-multi-Decide。官方将多语言输入指向后者，而不是默认两个版本在各种语言上效果相同。英文模型卡与多语言模型卡

表格里的多语言版 56.7%，仍然是在英文测试集上得到的成绩。中文简称、行业术语、含糊表达、多个诉求混在一句话里，都可能改变分流难度；没有对应测试，就不能填上一个看似精确的中文准确率。

同样，输出一个置信分数，不代表这个分数已在目标业务中校准。程序不应仅凭“分数超过某个值”自动批准付款、删除数据或修改重要配置。更合理的设计是把低置信、冲突和高风险情况分开处理，并让真正的执行权限由独立规则和人工批准控制。

GLiNER2.5-Decide 带来的机会，不是用几亿参数包办所有推理，而是把通用大模型不必亲自处理的一部分选择题，变成一个可控的小组件。选项定义得清楚、错误能被发现、复杂问题有升级路径，它才可能让整个工作流更轻、更快；缺少这些条件，快只是更快地走错分支。