告别JSON解析：nobodywho决策模型直接输出概率

在构建LLM应用链时，我们常常需要让模型做一个“选择”：调用哪个检索器、使用哪个工具、内容是否安全。常规做法是让LLM输出JSON，再用Pydantic解析，并加上重试机制——一旦格式错乱，整个流程就可能卡住。nobodywho项目最近推出的决策模型（Decision Models）提供了一种新思路：不生成任何token，而是直接对候选答案打分，返回每个选项的概率和置信度。

传统方案的痛点：解析与重试

大多数链式调用中，“选择”这一步依赖LLM的文本输出，然后通过解析器提取结构化结果。开发者需要处理模型输出不符合schema的情况，通常会增加重试逻辑。这不仅增加了延迟，也让代码变得复杂。更麻烦的是，当选项较多时，模型可能生成模糊或矛盾的答案，解析成功率进一步下降。

nobodywho的贡献者指出，这种模式本质上是在用生成式模型做分类任务，而分类任务并不需要逐token生成文本。（来源：Reddit帖子，作者披露其贡献者身份）

什么是结构化输出与重试机制

让LLM输出JSON再解析，属于“结构化输出”的一种朴素实现：模型仍以逐token方式生成文本，开发者依赖提示词约束其格式，再用Pydantic等库校验字段类型与必填项。由于生成过程具有随机性，格式错误、字段缺失、类型不符时有发生，于是需要“解析失败→重新调用→再解析”的重试循环。重试会成倍增加token消耗与端到端延迟，且在温度较高或选项较多时收敛缓慢。更稳健的做法包括约束解码（constrained decoding）和函数调用（function calling），它们能在解码阶段限制可选token，但仍属于生成范式，输出的是文本而非可直接使用的概率分布。

决策模型如何工作

nobodywho新增的决策模型专门处理这类“选择”步骤。你只需列出所有可能的答案，模型会为每个选项计算一个分数，最终返回一个包含所有选项概率和整体置信度的结果对象。由于不生成token，完全避免了JSON解析和格式校验的环节。

该功能通过Python的Decision或DecisionAsync接口调用，模型在本地运行，无需网络请求。据帖子介绍，底层使用laya模型（449 MB，Apache-2.0许可），可在用户自己的机器上执行。

打分式分类与生成式分类的区别

传统做法把分类伪装成生成：模型先生成“选项A”这样的文本，系统再把它映射回标签。打分式分类则让模型对每个候选答案单独计算一个logit或相似度分数，经softmax归一化后得到概率分布。这样做的好处是：输出空间被限定在候选集合内，不存在“生成候选集之外的乱码”这一失败模式；概率本身携带不确定性信息，可直接用于阈值判断；推理时通常只需一次前向计算，无需自回归逐token解码，延迟更低且更稳定。代价是候选选项必须事先枚举，无法处理开放式答案。

laya模型与本地推理

laya是nobodywho决策模型所依托的小型模型，体积约449 MB，采用Apache-2.0许可，可完全在本地CPU或消费级硬件上运行。相较于动辄数十GB的生成式大模型，这类小模型牺牲了通用生成能力，换取低延迟、零网络依赖和数据不出本机的隐私优势。它本质上是一个句向量/打分模型，通过比较输入与各候选选项的表示来计算匹配程度。需要注意的是，模型体积小意味着其语义覆盖范围有限，在专业领域或多语言场景下的判别质量需要通过实测确认。

适用场景与社区讨论

帖子作者询问社区：“你会把这样的步骤放在链的哪个位置？”这引发了关于决策步骤在复杂工作流中角色的思考。常见的候选位置包括：

• 路由选择：根据用户输入决定使用哪个检索器或工具。
• 安全过滤：判断内容是否适合继续传递。
• 多步推理中的分支：在需要明确分支的链中替代LLM调用。

相比生成式方案，决策模型给出的概率分布让开发者能设置动态阈值，比如当置信度低于某个值时触发人工审核或备用路径。

局限与待验证之处

目前该方案仅支持本地运行，模型体积（449 MB）对于资源受限的环境可能仍有压力。此外，laya模型的具体能力边界、在多语言或复杂语义下的表现，帖子中未提供详细评测。由于是单一来源（Reddit帖子且作者为项目贡献者），实际效果需要更多独立测试验证。

不过，这种“不生成、只打分”的思路为链式调用中的决策步骤提供了一种轻量替代方案，尤其适合需要明确概率输出的场景。项目已在GitHub开源，文档提供了Python接口示例。

仓库地址：https://github.com/nobodywho-ooo/nobodywho

文档：https://docs.nobodywho.ooo/python/decision-models