系统一 vs 通用 LLM 对比

核心差异：输出空间是否封闭

Jev 与通用 LLM 最根本的区别不在参数量或训练数据，而在输出的可能性空间：

通用 LLM：输出空间是全部自然语言（实际上是词表上的任意序列）。它什么都能说，因此也什么都可能说错。
Jev：输出空间由你在请求里预先定义。你问的是“billing / technical / account / other 选哪个”，它就只可能返回这四个标签之一。

这一个差异，推导出了下面所有的工程后果。

横向对比

维度	Jev（系统一）	通用 LLM（系统二）
端到端延迟	70ms – 500ms	3 秒 – 300+ 秒
解码方式	非自回归并行采样（一次前向出结果）	自回归逐 token 生成
输出形态	强类型封闭集：`choice` / `noul` / `score`	自由文本 / JSON 字符串
解析成本	零——直接是结构化对象	需要解析、校验、重试
输入价格	$0.042 / 百万 Token	$0.20 – $10 / 百万 Token
输出价格	$0（免费）	约为输入价格的 5 倍
失败模式	概率偏斜（可观测，可设阈值降级）	JSON 破损、幻觉、跑题、截断
可观测性	每次都有概率分布，可做置信度监控	通常只有一个黑箱字符串
上下文窗口	面向短而密集的状态描述优化	支持超长上下文与文档
擅长	分类、路由、打分、抽取、分支判断	生成、写作、翻译、多步推理、代码

价格与延迟数据来自 TypeSafe 官方发布博客（https://typesafe.ai/blog/introducing-system-one-models-and-jev）。官方给出的对比是：在 System One 形态的任务上，Jev 相比前沿模型快 193.6 倍、便宜 444.6 倍。

什么任务该交给谁

交给 Jev（系统一）——特征是“答案空间可以用有限选项穷举”

✅ 分类：这条工单属于哪个部门？
✅ 路由：这个请求该交给哪个 Agent / 哪个模型？
✅ 打分：这个 Lead 的意向度是多少？这个客户的流失风险有多高？
✅ 抽取：从这句话里能不能提取出“退款”意图？（用 noul）
✅ 守门：这条消息是垃圾吗？这个工具调用有风险吗？
✅ 分支：手写 if-else 太脆、但又不值得上大模型的判断点

一句话概括官方的说法：当一个判断用模糊规则表达、而用硬编码 if-else 又太脆时，就该用 Jev。

交给通用 LLM（系统二）——特征是“答案需要被生成出来”

✅ 撰写客户回复邮件
✅ 总结一份长文档
✅ 多步骤推理与规划
✅ 生成代码、翻译、创意写作
✅ 需要理解超长上下文的深度分析

决策流程图

这个任务的输出能预先穷举吗？
   │
   ├─ 不能 ──► 通用 LLM（系统二）
   │
   └─ 能
       │
       ├─ 是/否（二值）──────────────► Jev: noul()
       ├─ 有限标签里选一个 ──────────► Jev: choice()
       └─ 沿有序档位打分 ────────────► Jev: score()

补充判据：即使输出能穷举，如果调用频率极低（比如一天 10 次），用通用 LLM 也无妨——Jev 的收益主要来自高频场景，因为它的成本是压倒性的，而且是延迟敏感的。

黄金架构：Jev 当守门员，LLM 当专家

两者不是替代关系，而是流水线关系。最经典的落地模式：

                       ┌──────────────────────────────┐
   用户输入 ──────────► │  【系统一】Jev  70ms          │
                       │  noul: 是垃圾/闲聊吗？         │
                       └───────────┬──────────────────┘
                                   │
                     noul >= 0.8 ──┴── noul < 0.8
                          │                  │
                    直接丢弃/归档       ┌────▼─────────────────────┐
                    （零 LLM 成本）     │ 【系统一】Jev  70ms       │
                                       │ choice: 属于哪个类目？    │
                                       │ score:  紧急度多少？      │
                                       └────┬─────────────────────┘
                                            │
                            confidence < 0.85│confidence >= 0.85
                                     ┌──────┴──────┐
                                     │             │
                              ┌──────▼─────┐  ┌────▼──────────────┐
                              │ 转人工复核  │  │ 【系统二】通用 LLM │
                              └────────────┘  │ 生成回复 / 深度处理 │
                                              └───────────────────┘

这个架构为什么有效

成本坍缩：Jev 的输出 Token 免费，输入便宜两个数量级。把 100% 的流量先过一遍 Jev，边际成本几乎为零。
延迟坍缩：70ms 的守门意味着用户几乎感知不到前置判断，而 90% 的简单请求在这条线内就被确定性处理完了。
可靠性提升：通用 LLM 只在“确实需要它”的时候才被唤起，其出错面被大幅收窄——而它前面的 Jev 层因为输出封闭，几乎不可能出错。
可观测：Jev 每次返回的概率分布是天然的监控指标。分类置信度整体下滑 = 数据分布漂移，你可以立刻发现。

什么时候“不该”用 Jev

诚实地讲，Jev 并非万能：

❌ 需要生成内容的场景——它不生成自然语言，只做选择。
❌ 输出空间无法穷举的场景——如“抽取所有实体”这种开放抽取。
❌ 极低频调用——收益不足以抵消接入成本。
❌ 需要长链推理的场景——那是系统二的主场。
❌ 需要超长上下文的场景——Jev 针对短而密集的 state 描述优化，几万字的文档理解请交给通用 LLM。

下一步

Choice / Noul / Score 原理 —— 掌握三种原子操作的细节