fast-decisions基准对决：7大模型横评，GLiNER2.5-Decide为何跑赢Qwen3.5等大模型-平芜编程栈

【免费下载链接】fast-decisions

项目地址：https://ai.gitcode.com/hf_mirrors/fastino/fast-decisions

fast-decisions是一个面向"运营决策"的多任务文本分类基准数据集，覆盖客服、银行、医疗、邮件分诊等 17 个真实业务场景。在它的 7 模型横评中，专为该基准打造的 GLiNER2.5-Decide 以 60.2% 的准确率登顶，跑赢了 Qwen3.5-4B 等通用大模型——小模型为何能赢？本文带你一次看懂。🔍

一、fast-decisions 是什么？一句话讲清楚

先说结论：fast-decisions 不是通用能力考试，而是一份"工作场景判断题"。

每一行数据 = 一段真实文本（客服对话、邮件、病历、新闻标题……）+ 产品系统必须做出的决策。比如一封邮件进来，系统需要同时回答四个问题：它属于什么类别？该采取什么行动？是否需要回复？是不是钓鱼邮件？

📌 数据规模：17 个领域文件，每个 100 条（共 1,700 条开发集）；另有每领域 300 条的隐藏测试集用于最终打分。所有人名、账号、金额均为虚构。

它测的不是"模型会不会聊天"，而是**"模型能不能稳定地做对业务决策"**——这正是客服路由、工单分配、邮件分诊等生产系统的核心能力。

二、七大模型横评：完整成绩榜单 📊

以下是官方公布的、在隐藏测试集（17 领域 × 300 例）上以精确匹配计算的准确率排行，所有模型使用相同的文本和候选标签：

排名	模型	平均准确率	定位
🥇 1	GLiNER2.5-Decide	60.2%	英文决策模型（冠军）
🥈 2	GLiNER2 XL (1B)	59.6%	10 亿参数大一号版本
🥉 3	JevK5	57.6%	信息抽取模型
4	GLiNER2.5-multi-Decide	56.7%	多语言版（英文上测试）
5	SemIf (Qwen3.5-4B)	56.4%	40 亿参数大模型
6	GLiFormer large-v1	49.0%	序列标注模型
7	Laya Router	46.6%	路由模型

几个值得玩味的细节：

冠军 GLiNER2.5-Decide 领先 Qwen3.5-4B 约 3.8 个百分点——参数量小得多，业务决策反而更准
第 1 名与第 2 名仅差 0.6%，说明这个基准上的竞争相当激烈
多语言版 GLiNER2.5-multi-Decide 在英文上比英文版低了 3.5 个点，"通用性"与"专精度"存在真实权衡

三、为什么小模型能跑赢 Qwen3.5 等大模型？

这是本文最想讲透的部分。归纳起来有三个原因：

1. 任务是"分类"，不是"推理"

fast-decisions 明确没有推理链、没有开放问答，每行数据只要求从给定候选标签里选出正确答案（单选或多选）。大模型的推理、长文本理解能力在这里用武之地有限，而候选标签受限的分类任务恰好是专用小模型的舒适区。

2. Schema 驱动：模型"知道"答案空间

数据集的每行都携带完整候选标签集（labels字段）。模型不是自由发挥，而是像做选择题一样在固定选项里判断。这种schema-driven（模式驱动）接口让模型可以把全部容量都花在"理解文本 + 匹配选项"上，而不是浪费在生成格式上。

3. 针对性微调的复利效应

GLiNER2.5-Decide 就是为这份基准专门微调的模型。在 17 个业务领域反复训练中，它对"客服用语""银行术语""病历表达"形成了领域记忆。通用大模型什么都懂一点，但对"refund_request 和 cancel_subscription 的边界"这种细粒度业务区分，未必比专才更敏感。

💡 一句话总结：在边界清晰的任务上，专精的小模型 ≈ 甚至 > 泛化的大模型。这正是很多生产系统"小模型守门口、大模型做兜底"的原因。

四、数据长什么样？三分钟看懂 Schema

每行数据是一个 JSON 对象，结构统一且简单：

{ "input": "<自由文本>", "output": { "classifications": [ { "task": "sentiment", "true_label": ["neutral"], "labels": ["negative", "neutral", "positive"], "multi_label": false } ] } }

三个关键点，新手必读：

字段	含义	新手注意
`input`	待分类文本	可能包含`[channel]`、`[body]`等前缀标记
`labels`	该任务的全部候选标签	推理时原样传给模型，别自己删改
`true_label`	金标准答案	永远是字符串列表，单标签也写成`["xxx"]`
`multi_label`	是否多选	`true`时答案可能含多个标签（如餐厅评价同时涉及`food`和`wait`）

一个有意思的例子：在 restaurant_review.jsonl 中，同一条评价要同时输出情感（单选）和涉及方面（多选）——一次调用、多个决策头，这正是"多任务"的含义。

17 个领域一览 🗂️

领域	文件	决策头	典型场景
客服意图	support_intent.jsonl	1	退款？取消订阅？物流延误？
客服主题	support_topic.jsonl	1	计费、账号、技术故障……
文档类型	document_type.jsonl	1	发票、合同、简历识别
评论情感	review_sentiment.jsonl	1	好评、差评还是中性
人工交接	agent_handoff.jsonl	1	何时该转人工客服
邮件分诊	email_triage.jsonl	4	一封邮件四个决策
工单路由	ticket_route.jsonl	3	队列 + 紧急度 + 是否含隐私
产品反馈	product_feedback.jsonl	2	多标签：涉及哪些产品模块
银行意图	banking_intent.jsonl	1	转账、挂失、争议扣款……
诊所请求	clinic_request.jsonl	2	请求类型 + 是否紧急
差旅请求	travel_request.jsonl	1	改签、行李、酒店代金券
新闻主题	news_topic.jsonl	1	头条归到哪个版块
论文领域	paper_field.jsonl	1	生物、化学、计算机……
体育综述	sports_recap.jsonl	3	项目 + 结果 + 是否冷门
餐厅评价	restaurant_review.jsonl	2	多标签方面 + 情感
福利申请	benefits_request.jsonl	2	社保、食品援助等项目识别
影视标签	screen_tags.jsonl	2	多标签类型 + 电影/剧集

可以看到，决策头数量从 1 到 4 不等：大多数领域只需一次判断，而 email_triage.jsonl 这类领域一次要同时做 4 个决策——这对模型的稳定性是更大的考验。

五、如何上手使用？两步加载数据集 🚀

仓库提供 Apache 2.0 许可，数据可直接用于研究与模型训练。用 Hugging Facedatasets库加载即可：

from datasets import load_dataset # 加载单个领域 ds = load_dataset("fastino/fast-decisions", "support_intent", split="train") # 加载全部 17 个领域则循环 load_dataset 后 concatenate 合并

如果你只是想知道"这个领域有哪些任务、标签集合是什么"，直接翻 README.md 的Task heads and label sets一节就有完整清单——这也是推理时必须使用的候选标签集合。

⚠️一个重要的诚实提醒：仓库里这 1,700 行只是开发集（development split）。官方基准分数来自未公开、每领域 300 条的测试集。README 明确提醒：不要用本仓库文件算出的分数当作基准成绩。