Hugging Face为决策模型制定统一接口，Transformers与llama.cpp新增 /v1/systemone端点
Hugging Face在博客中介绍“决策模型”：输入上下文和若干带预设答案的问题，直接返回每个答案的概率分布，不生成文本。Transformers新增DecisionPipeline等类并支持本地 /v1/systemone服务，llama.cpp也支持同一端点。
AI解读：Hugging Face博客提出“决策模型”这一接口约定：模型接收state（字符串、结构化JSON，或受支持的多模态输入）和若干命名问题，返回带类型的决策结果与概率，而不是逐token生成文本。
问题有三种基本类型：choice在多个选项上给出概率分布；score在有序刻度上返回概率分布的期望值；noul（源自Bernoulli）返回一个命题为真的概率。choice与score还会返回confidence，按选项数量对最大概率做归一化。
博客称，相比提示LLM输出JSON，决策模型不会违反给定schema，也不需要约束解码（如Outlines、XGrammar）的额外开销，因为答案集合由应用预先给定。文章同时说明，Transformers的该接口也兼容自回归语言模型：它构造提示、在一次前向传播中读取答案标签的logit并做softmax，输出token数为 0。
博客举例使用的模型为autotrust/GEV-26B-Decide与ggml-org/Kev-4B-GGUF；文中数值（如“被重复扣款”分派到billing的 0.998 概率、urgency得分 1.7）均为示例输出，不是公开评测结果。
博客把决策模型与固定标签分类器、零样本分类（如facebook/bart-large-mnli）对比：决策模型可在推理时定义标签、支持多个不同类型的命名问题，并原生支持有序评分与是/否判断。文章称该领域“年轻且快速变化”，各模型内部实现并不统一。
Hugging Face在博客中介绍“决策模型”（decision model）及其在Hugging Face生态中的接入方式。按文中定义，决策模型接收输入上下文（state）和一组带预设答案的问题，直接返回每个答案的概率分布，而不生成文本。
Transformers已新增DecisionPipeline、AutoModelForDecision和DecisionConfig，并支持 /v1/systemone端点；llama.cpp也支持同一端点，可加载Hub上的GGUF决策模型。
接口怎么用：state加问题，返回概率
博客给出的基本接口是：State + Questions + Allowed Answers → Decisions + Probabilities。state可以是字符串或结构化JSON，受支持的全模态模型还可接受其他模态；questions是若干命名问题，每个问题指定类型和选项。
问题分三种基本类型。choice在若干选项中给出概率分布，取概率最大者为结果；score在有序刻度上返回概率分布的期望值，例如低/中/高三档得到 1.7，博客强调这不代表模型选了“介于中与高之间”的虚构档位；noul返回命题为真的概率，博客称其名字来自Bernoulli。
choice和score还会返回confidence，计算方式是用最大概率相对均匀分布做归一化：均匀分布时confidence为 0，全部集中在一个选项时为 1。因此胜出概率 0.99 的三选一问题，confidence显示为 0.98。
- state：字符串、结构化JSON或受支持模型的其他模态输入
- choice：多个选项上的概率分布
- score：有序刻度上的概率分布期望值
- noul：命题为真的概率（Bernoulli参数）
- confidence：对最大概率按选项数归一化后的集中度
对LLM输出JSON的替代说法
博客列出用提示让LLM返回JSON做分类、路由的几个问题：模型不保证遵守要求的schema，可能产生无效JSON、意外键或选项外的答案；Outlines、XGrammar等约束解码能限制可生成的token，但带来额外计算开销；应用只需要在预设答案中选择时，自回归生成整个回复是不必要的工作。
博客同时说明，Transformers的该接口也适用于兼容的自回归语言模型：它构造决策提示，在一次批量前向传播中评估答案标签的logit并应用softmax，不生成回复文本。博客示例响应中output_tokens为 0，因此不训练新模型也能试用这一接口。
与分类模型的差别
博客对比了固定标签分类器和零样本分类。固定标签分类器的输出类别固化在分类头中，新增部门需要改头、收集数据并重训；零样本分类（示例用facebook/bart-large-mnli，基于自然语言推理）可在推理时提供候选标签，标签集变化后直接重跑。
博客称决策模型在零样本分类的基础上扩展：同一个state可挂多个带名字、类型不同的问题（choice、score、noul），接口以概率分布为中心。文章也明确，决策模型的优势不在于发明了运行时定义标签或概率分类，而在于把这些能力组织成一致的接口。
在Hugging Face与llama.cpp中的接入
在Transformers中，可用pipeline("decision", model=...) 创建DecisionPipeline，也可通过AutoModelForDecision和DecisionConfig读取配置与模型；安装serving依赖后运行transformers serve，即可向本地 8000 端口的 /v1/systemone发送请求。
llama.cpp方面，博客称可用llama serve -hf ggml-org/Kev-4B-GGUF从Hub加载GGUF决策模型，默认端口 9931，向http://localhost:9931/v1/systemone发送同样的state和questions；模型由服务端选定时可省略请求中的model字段。
博客将统一接口的目标描述为“约定一致接口、不强制一致实现”：推理引擎、Hub打包与训练工具只需对接一次公共原语。文中明确当前各决策模型内部做法不同（联合打分整个schema的头部、挂在LLM骨干上的独立读出、面向边缘与多模态的变体等），该领域仍处于早期。
- Transformers：DecisionPipeline、AutoModelForDecision、DecisionConfig、/v1/systemone
- llama.cpp：同一 /v1/systemone API，默认端口 9931
- 示例模型：autotrust/GEV-26B-Decide、ggml-org/Kev-4B-GGUF