Jev vs LLM：不是替换大战，是组合架构

每篇 Jev 文章下面都会有人问「所以它能取代 LLM 吗」。这个问题在官方发布文里其实已经回答了：Jev 主动放弃了字符串生成能力（“Jev gives up string generation”）。放弃生成换来了低延迟、低成本和类型安全的结构化输出——这是一次明确的取舍，不是全面的超越。

能力对照：两种模型各管一段

一句话总结：LLM 是「写答案的」，Jev 是「做决定的」。把「写答案的」按在每一步都做判断，就是又慢又贵又难审计的 Agent 工作流的由来。

与 JSON Mode / Structured Outputs 的区别

「我让 LLM 只输出 JSON 不就行了？」——能做，但有三个差别：

1. 概率来源：JSON Mode 里模型给出的是一个答案；Jev 返回的是所有选项的概率分布。「returns 0.60 / billing 0.38」这种「第二名也很真」的信号，是设计兜底逻辑的原料。
2. 置信度语义：Jev 的 confidence 由概率分布形状计算，训练目标就是校准。LLM 被 prompt 要求「给出置信度 0-1」时，官方在发布文里直接点名：模型倾向于过度自信且不一致。
3. 成本结构：Jev 输出不计费、输出 token 极少（几个概率数字），而让 LLM 做 CoT 判断通常伴随长输出。

与传统分类器（微调小模型）的区别

微调分类器没有消失的理由：标注数据充足、类别稳定、追求极致成本时，它仍然是最便宜可靠的方案。Jev 改变的是冷启动经济学——不需要训练集，用自然语言写清楚选项与标准即可上线；类别和标准改几行配置就能迭代。官方文档把「把领域规则写进 instructions 与 criteria」作为定制手段，明确说明模型本身不做客户数据的微调。

选型决策树

给某一步工作流选实现时，依次问：

这一步需要生成自由文本（回复、代码、总结）吗？
├─ 是 → LLM（或 LLM + 结构化输出）
└─ 否，答案可以枚举或描述成量表
     ├─ 需要概率来设阈值/兜底/审计吗？
     │    ├─ 是 → Jev（Choice / Score / Noul）
     │    └─ 否，确定性规则够用 → if/else 规则引擎
     └─ 有大量标注数据且类别长期稳定？
          └─ 是 → 微调分类器仍是合理选择

组合架构长什么样

一个典型的高频判断工作流，把 Jev 放在 LLM 之前：

用户输入
  → Jev：意图分类（Choice）+ 复杂度评分（Score）+ 风险判断
      ├─ 低置信度 → 人工队列
      ├─ 简单封闭问题 → 代码/模板直接处理
      ├─ 需要生成回复 → 小模型/LLM（带着已判定的意图走）
      └─ 高风险动作 → 二次确认 + 审计

这个结构的收益都来自「前置判定」：昂贵模型的调用量、开放生成的暴露面、每一步的审计成本同时下降。完整可运行的例子见中文上手教程与客服分流实战；生态里已经有的参考实现（浏览器 Agent、工具路由）见项目导航。

最后重申一次边界：本篇的延迟、成本数字均为官方口径，采用前请用自己的数据实测；「组合架构」是设计建议，不是任何场景的最优解。