Jev 对比向 LLM 索要 JSON

两种不同的契约

聊天模型生成文本。即便开启 JSON 模式或严格结构化输出，它本质上仍是朝 schema 采样 token — 形状有保证，内容由生成而来。Jev 恰好相反：内容有保证（只能返回你声明过的选项），模型添加的是在你声明的选项之上的概率分布。这是两种不同的契约，失败方式也不同。

• JSON 模式的聊天模型：形状通常正确，但可能冒出一个你没声明的标签（“billingx”而不是“billing”）、归一化方式前后不一，或者把载荷裹进一段散文里。你得自己写解析器、白名单校验和重试循环。
• 决策模型：答案空间就是你发送的 criteria。一个有三个选项的 choice 问题恰好返回这三个之一，外加每个选项的概率。没有任何东西需要解析，因为没有任何东西是生成出来的。

LLM 真正擅长的地方

生成类任务 — 写邮件、总结工单、起草 SQL — 属于聊天模型，没有更窄的东西能替代它们。当你需要的是一个自定义对象（从文档里抽取的字段）而不是一次分支决策时，结构化输出也是合适的。这条流水线保持原样。

接缝就是那行代码：if (await classify(text) === "billing")。这一行需要的不是流畅文本，而是一个带校准概率的有界答案。

置信度问题

向聊天模型要一个置信度数字，它确实会给 — 但那是关于自身流畅度的自我报告，不是对所声明选项的校准概率。两次都报告“85% 确定”的调用可能处于完全不同的体制。决策模型的概率在不同输入之间可比，这才让你可以设一个阈值（“低于 0.8 转人工”），并在几十万次调用中信任它。

一次实操对比

以把意图分类到三个队列为例 — billing、technical、sales。

• 聊天模型方案：一个带标签的 prompt，JSON 模式运行。成本随每次调用都重发的 system prompt 和完整上下文增长。你要用白名单防离群标签，而误路由在被客户投诉之前一直保持沉默。
• 类型化决策方案：一个 choice 问题加三条 criteria 描述。一张短工单约 300–500 输入 token — 1 积分最低消费，Starter 上 $0.0001。误路由表现为高熵的概率分布，可以设阈值拦截，而不是代码默默接受一个错误标签。

在同一个流程里并用两者

• 在创意或理解力是重点的地方，让 LLM 自由生成或抽取。
• 在代码采取行动之前，把狭窄的问题交给 Jev：进哪个队列、走哪档模型、上线还是拦截。
• 不要把任何一方的输出当作法律、医疗或财务决策 — 设好阈值，让高风险路径上始终有人。

大多数生产系统最终两者都用：Jev 负责反复出现的分支，聊天模型负责它独一无二的长处。

失败模式对照

• 自由文本标签漂移：LLM 返回“billing-related”，而你的 switch 只认“billing”。类型化调用按你声明的精确键索引概率，结构上不可能漂移。
• 幻觉字段：JSON 模式可能附加你没要的键。决策模型不会 — 响应 schema 由问题类型固定。
• 静默误路由：一种因为下游代码回退到默认值而蒙混过关的漂移。类型化决策里你可以逐调用记录完整的概率分布，并复查那些双峰的。
• 置信度表演：先解析再断言（“我确信这是 X”）— 粗糙，且未经校准。Jev 的 confidence 伴随每个 choice 和 score 答案，驱动你的人工复核路径。

把基于解析器的分类器迁移过来

迁移是机械的：不再让聊天模型直接给标签，而是把同一套分类放进 choice 问题的 criteria，并沿用 prompt 里原本的措辞。忍住重新描述标签的冲动；现有 prompt 的措辞已经编码了团队心里的区分标准。两周内两边都问，记录一致率 — 当分歧降到 2% 或以下时，看几个分歧案例，结局几乎总是同一种：要么 criteria 措辞本身含糊，要么案例本来就含糊、而旧系统一直在静默误路由。

同一个请求的两种写法

同一个工单，两种契约的样子：

system: Classify the support message into billing, technical
or sales. Reply with {"queue": "..."}. Do not invent labels.
user: Charged twice for order A-104, please refund the duplicate.

{
  "state": "Charged twice for order A-104, please refund the duplicate.",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team handles this?",
      "criteria": {
        "billing":  "Payments, payouts, invoicing, refunds",
        "technical": "Bugs, outages, integrations",
        "sales":    "Pricing, upgrades, new accounts"
      }
    }
  }
}

第一种在顺利时返回 {"queue": "billing"}，不顺利时返回什么都有可能。第二种返回 billing 加上约 0.97 的概率、全部三个选项上的分布和一个 confidence 值 — 而且失败契约每次都一样（一个带 error.code 的错误结构，绝不是听起来合理却错误的答案）。围绕你更愿意调试哪种失败来设计下游代码。