Hugging Face提出决策模型的统一接口：Transformers新增DecisionPipeline和/v1/systemone端点，llama.cpp用同一API服务，用choice、score、noul三种原语返回概率；文章没有给出准确率、校准或延迟的基准，算例数字前后也不完全一致

2026年11月10日，Hugging Face发表长文《Hugging Face中的决策模型》（Decision Models in Hugging Face），作者是Aritra Roy Gosthipaty、Lysandre、Pedro Cuenca和Tom Aarsen。文章描述了一种不生成文本的模型的通用接口。决策模型读取一个状态（比如一条客户消息），以及一组带类型、带允许答案的问题，然后返回带概率的结构化决策。文章说，模型是给应用本来就认识的答案分配概率，而不是逐个token生成文字。接口被写成“状态 + 问题 + 允许的答案 → 决策 + 概率”。文章说，这个想法由TypeSafe AI以Jev之名提出，称为“System One模型”（系统一模型），社区后来统一叫“决策模型”，因为这个词描述的是模型的角色，而不是某种思维理论。

文章的出发例子是一条客服消息：“我的订阅被扣了两次款。我今天就要退款。”应用想从中得到三件事：该由哪个团队处理、紧急程度、客户是否在要求退款。文章先展示一个让语言模型写出带这些答案的JSON的做法，再提出另一种做法。它列出了让语言模型输出结构化结果的三个问题。模型不保证遵守要求的模式，可能返回无效JSON、意外的键，或允许范围之外的答案。Outlines和XGrammar这类约束解码库能强制语法，但带来额外开销。而且当应用只需要在固定答案中选一个时，生成整段回复是不必要的工作。文章没有给出实测的速度、成本或准确率对比来支持这些点，所以它们是论点，不是结果。

问题有三种类型，称为原语。choice（选择）问题从若干答案中选一个，并给出每个答案的概率。score（评分）问题在有序量表上评估某事，返回级别索引的期望值。第三种因伯努利分布而叫“noul”，用“该陈述为真的概率”回答是非题。对选择和评分问题，结果还带有confidence（置信度）字段。对有K个选项的选择，置信度是最大概率减去1/K，再除以1减1/K，所以均匀分布得0，完全集中得1。在文章的例子中，部门问题返回“billing”，概率0.998，置信度0.997。紧急程度的评分为1.705，置信度0.558，文章解释这是对分布取的期望，而不是介于“中”和“高”之间的某个级别。

文章把决策模型与两种旧做法作了比较。传统分类器的输出类别固定在分类头里，所以新增第四个部门（如法务）可能需要新数据和重新训练。零样本分类在推理时提供标签，文章展示了一个模型对账单、技术支持、销售，以及改动后再加上法务返回分数。文章说，决策模型的优势不在于发明了运行时标签或概率，而在于把这些放进一个接口：对同一状态可以问多个有类型的问题，并原生支持有序评分和是非决策。在文章自己的表里，分类给出各选项的概率，但不能在推理时定义标签，只有决策模型具备多个有类型的问题。

真正影响工具链的是Hugging Face技术栈里的支持。Transformers现在有DecisionPipeline、AutoModelForDecision类和DecisionConfig类。用兼容版本的Transformers运行“transformers serve”，会开放一个/v1/systemone端点，文章展示了一个带三个问题的请求返回三个有类型的答案，用量是148个输入token、0个输出token。llama.cpp通过同一个API提供决策模型服务：例子运行“llama serve -hf ggml-org/Kev-4B-GGUF”，默认服务端口是9931。文章补充说，这个接口也适用于兼容的自回归语言模型：Transformers构造决策提示，在一次批量前向计算中读取答案标签的logits，再做softmax，不生成文本，所以开发者不训练新模型也能试用这个接口。

在发现和训练方面，Hub上有了新的“decision-model”标签。文章说，决策模型不必共用同一个骨干：有些基于ModernBERT这样的编码器，有些基于更大的生成式语言模型。训练方面，决策模型可以用Trainer API微调。文章给了一个故意做得很小的例子：在六条客服消息上，以1e-3的学习率对autotrust/JEV-9B微调30步，对选择类问题用选项上的普通交叉熵。文章说TRL里的一流训练支持即将到来，相关拉取请求huggingface/trl#8040在文章写作时仍未合并。它还指向Unsloth的一份配方：用LoRA和决策评分头微调Qwen这类模型。

读者需要记住文章的几处局限。文章正文没有给出任何一个具名决策模型在准确率、校准或延迟上的基准结果，所以“可靠、校准良好的决策”是文章表达的目标，不是发现；本文没有打开文中链接的图片和页面。它的算例也不完全一致：一个表里紧急程度概率是0.10、0.26、0.72，三者合计1.08，所以这张表不是有效的概率分布，而打印出来的输出是0.0149、0.2648、0.7203；还有一句话提到获胜概率0.80，随后却用0.99计算。有三个选项时，按公式0.80对应置信度0.70，0.99对应0.985，文章印的是0.98。打印值中有两项可以用打印的概率复算：选择置信度(0.99827 − 1/3) ÷ (1 − 1/3) ≈ 0.9974，评分期望0 × 0.0149 + 1 × 0.2648 + 2 × 0.7203 ≈ 1.705，两者都与打印输出一致。文章没有给出评分置信度的公式，所以上文的0.558只是文章报告的数值，本文没有核实。读者应把表里和正文里的数字当作示意。文中提到的模型autotrust/GEV-26B-Decide、ggml-org/Kev-4B-GGUF和autotrust/JEV-9B，本文没有测试，文章除名字外也没有给出许可证或规格。

对于现在用会写JSON的语言模型来做工单分流、风险评分或内容过滤的团队，实际问题很窄：对固定答案返回概率的模型是否适合这个决策，有没有一个对你的语言和领域够好的检查点？文章提供的是一套通用API、一种在普通语言模型上试用的办法，以及一份小型训练配方。它没有提供决策模型优于现有做法的证据，这个比较要在团队自己的数据上做。