让本地 AI 做选择题：Swift 工具直接返回分类与概率

10 月 29 日，开发者 Mattt 在 Hugging Face 介绍了 AnyDecisionModel：一个让 Swift 应用向模型提问，并取得类型化选项和概率的开源工具包。对做客服工单、内容整理或消息分流的开发者，它提供了一种比解析自由文本更直接的接入方式。本文用工单分类解释它如何工作，以及为什么拿到概率之后，仍要验证错误率。作者介绍

原创概念插画，以三条可选通道和选择器表现分类，不是产品界面或实际推理结果。

[配图建议：一条文字墨流进入选择器，分向三条不同颜色的通道，指针选中其中一条；米白底、蓝红绿配色的纸艺版画风。]

一、应用要的是分类，模型却经常先说一段话

假设你的 Mac 客服工具收到一张工单：“这笔订单扣了两次款，而且我现在登不上账号。”应用需要决定交给账单组还是技术组，还想标记是否紧急。

如果让聊天模型自由回答，它可能写“建议优先转交账务部门，同时排查登录问题”。意思读得懂，程序却还要把这句话转换成固定类别，处理别名、多余解释和格式变化。

AnyDecisionModel 的思路是：先声明允许的答案，再让模型在这些答案之间作出判断。它提供三种常见问题形式：

在 Swift 中，开发者可以让部门枚举遵循 Choosable，返回的 Choice<Department> 就能直接参与程序分支，不必先从一段自然语言里寻找部门名称。项目 README 的接口示例

结构化 JSON、枚举约束同样可以规范生成式模型的输出。这个工具值得关注的地方，是把固定选项、概率分布和 Swift 类型放进同一套接口，方便应用围绕结果安排后续处理。

不过，最前面的工单同时包含两个问题。选项写得再规范，也不会自动决定哪一项更重要。团队仍需定义“扣款问题优先给账单组”，或允许先标记多种问题，再决定主处理组。分类规则清楚，才有评价答案对错的基础。

[配图建议：一张同时包含扣款和登录问题的工单，分别连向问题标签与主处理组，两层结果清楚分开；简洁的编辑信息图。]

二、本地模型怎样回答一道选择题？

作者说明，普通 MLX 后端会为允许的答案安排单 token 标签，再读取模型对这些标签的概率。它不需要先生成一段解释，再从解释里提取类别；一个问题可以通过一次前向计算取得相应标签概率。作者对 MLX 路径的解释

这也解释了一个值得分清的概念：AnyDecisionModel 是应用接口和运行后端的封装，不是一款新训练出来的大模型。它既能使用普通语言模型的下一 token 概率，也支持接入带专门决策头的模型。两条路径得到结果的机制不同，不能因为用了相同 API，就认为模型能力相同。

普通 MLX 路径的选择题最多有 26 个选项。类目很多的业务，还要先确认后端限制和任务拆分方式。MLX 后端限制

对工单工具来说，较自然的设计是把工单正文作为一次会话的固定状态，再分别询问“哪个组处理”“是否紧急”。项目的 DecisionSession 源码将这些问题绑定到同一份状态；后一个问题不会自动读取前一个问题的答案。会话实现

如果业务确实需要“先分类，再根据类别判断处理时限”，应用应明确编排这两个步骤，并把需要的结果交给下一步。不要把相似的会话式调用，误当成已经建立了完整的业务流程。

本地运行还让任务有机会留在自己的设备上完成。但“使用了这个包”不等于“请求一定在本地”：项目也提供远程后端。接入时应记录实际使用哪条路径、是否需要下载权重，以及输入会被送到哪里。接口统一带来便利，执行位置仍需开发者选择。

[配图建议：工单正文放在中央，旁边两个独立问题各自读取正文；另画一条由应用明确传递结果的后续步骤；清晰的流程示意风格。]

三、有概率，更要分清“集中”和“正确”

概率让分类过程多了一层可观察信息，但它很容易被误读。

项目中，本地选择题和评分的 confidence 来自概率分布的熵，反映答案是否集中在少数选项上。它不是“这道题答对的概率”。相关实现与说明都明确区分了这两件事。返回值与置信度定义

举个假设：系统对一张工单非常确定地选了账单组，但你的业务规则要求账号无法登录时先由技术组接手。模型的分布可以很集中，业务答案仍然错误。只加一句“低置信度交给人工”，会漏掉这种高置信度错误。

下一 token 路径还会记录“允许答案获得的概率总量”。它能帮助发现：归一化后的选项分布看起来很明确，但模型原本把不少概率放在了选项之外。检查这个诊断值，可以补充观察结果，不能据此直接认定回答正确。标签概率处理源码

选项本身也影响问题。假如没有“其他”或“信息不足”，一些不属于现有部门的工单仍可能被分到其中一项。开发者可以考虑增加可回退类别，并写清何时选择它；这样做是否改善结果，要用真实样本验证。

工具提供了进一步检查的办法：

• 校准概率。本地后端支持通过温度等参数调整分布；项目要求将拟合校准的数据与评估数据分开，示例数值也不是通用推荐。校准实现
• 检查选项顺序。普通 MLX 等下一 token 后端可轮换选项位置并汇总概率，但会增加求值次数；这种成本需要一起记录。后端说明
• 观察实际错误。把错误按“分错部门”“漏掉紧急工单”“资料不足却强行分类”分别统计，才能知道人工复核该放在哪一步。

其中最后一项是我的应用建议：先定义错误的代价，再决定阈值。不同后端的置信度计算也可能不同，迁移时应重新评估，不能直接沿用旧阈值。

[配图建议：两张示意工单分别显示“判断集中但分错”和“判断分散需复核”，用文字标签而非虚构测试分数；蓝红双色教学插画。]

四、第一次试用，先跑通一个可核对的分流任务

这个项目适合希望在 Swift 应用中加入有限选项判断的开发者。若你的任务主要是写长文、开放式分析或持续对话，选择题接口只覆盖其中一部分工作。

先核对运行条件。包清单要求 Swift 6.2，并声明 macOS 26、iOS 26 起的平台版本；不同后端还有额外要求。作者的 MLX 示例使用 Apple silicon 与 Metal 工具链，构建任务要求 Xcode 的 Swift 6.4 或更新版本；Core AI 路径则需要 OS 27 环境。包的平台声明，不能代替具体后端的要求。包清单、构建要求

最短的学习入口是作者的示例仓库：其中已有工单路由命令行程序，以及测量准确性、校准、鲁棒性和延迟的工具。示例的 MLX 默认模型首次使用需下载约 2.3 GB 权重；下载体积不能直接视为运行内存。官方示例与评估工具

建议按三步做一个小验证：

1. 固定规则和样本。收集可用于测试的工单，先由业务人员标出正确组别，保留多问题、短句和信息不足的情况。
2. 先做建议分流。让模型给出候选组，保留人工确认；记录完整分布、错误类别和从输入到结果的等待时间。
3. 再评估自动处理范围。使用另一批样本检查阈值，观察减少了多少手工分流，以及引入了哪些误分。

作者示例仓库也提示，部分路由和鲁棒性测试标签未经人工审核。使用公开评估工具很方便，但你的业务验收样本仍应自己核对，不能把示例输出当作上线成绩。

[配图建议：业务标注、模型建议、人工确认、错误回流构成一个小循环，突出先验证再扩大处理范围；轻量产品流程图。]

总结：先把一道业务选择题定义清楚

AnyDecisionModel 的价值，是让 Swift 应用更直接地取得分类、类型和概率。有限选项明确的任务值得尝试；分类规则还没定清的团队，可以先整理样本和人工处理标准。

今天就能做的一步：挑一类工单，写出允许的组别、信息不足时的处理方式，以及什么情况必须复核。然后用同一批样本比较模型建议与人工判断。你最想让本地 AI 接手哪一种分类工作？

[配图建议：一页简洁的分类任务说明，列出选项、回退方式和验收规则，旁边放一枚选择指针；与封面一致的纸艺版画风。]

资料核对日期：2026 年 10 月 30 日（北京时间）。本文依据项目介绍、文档和源码分析，未安装运行模型；封面为原创 AI 概念配图。