Introducing System One Models & Jev

研究动机

• 问题难在哪：作者（RLHF / InstructGPT 的共同发明人之一）的出发点是：“模型聊天早就超越人类了，可自动化在哪里？”真实的业务自动化，本质上是代码里成千上万个模糊 if 判断：这张工单该给哪个部门、这条告警是不是真入侵、这段话算不算退款请求。这类判断要求快（嵌在代码调用链里，延迟会层层叠加）、便宜（要对大数据做 map-reduce）、类型不出错（出错整条 pipeline 就崩），还要知道自己什么时候没把握（95% 能做对但说不出错的是哪 5%，这个任务就没法放手自动化）。
• 现有方法的问题：
  • RLHF 聊天模型的优化目标是“人类评分员更喜欢的文本”，会带来 sycophancy、自信的 hallucination，还有 mode dropping（分布变窄）。
  • RLVR 推理模型只擅长能被程序自动验证的任务（数学、kernel 优化），代价是又慢又贵，智能也不均匀（spiky）；大多数现实判断任务没有 verifier。
  • 用 LLM 输出 JSON：要 parse、validate、retry，照样有 structured-output 和 tool-call 错误；让它口头报一个 confidence，通常过度自信而且前后不一致。
• 核心 insight：作者称之为 “the bitterest lesson”，即优化什么任务，比数据、算力、算法都重要。既然自动化需要的是“state 进去，带校准概率的类型化决策出来”，那就直接用这个接口去训练模型（RLCD），并主动放弃字符串生成。放弃了生成，就换来了并行采样、输出免费、结构上不可能出现类型错误。

核心方法

0. 术语速查（每个抽象词在 Jev 里具体指什么）

1. 接口契约：state + typed questions → 带概率的 typed answers

唯一的 endpoint 是 POST /v1/systemone。请求里放一个 state 和一个 questions 字典，每个问题必须是 Choice、Score、Noul 三种 primitive 之一。答案被限定在调用者给出的选项之内，所以根本不需要从 prose 里 parse，也就谈不上 hallucinate 出一个不存在的选项。所谓 “type-safe”，指的是输出空间在调用前就由 schema 定死了，不是事后检查。

注意 response 里的 usage.output_tokens: 65：虽然说“输出免费”，服务端还是在统计某种输出 token，可能是选项 / 等级标签本身被当作被打分的序列。

直观理解：你可以把 Jev 当作一个“frontier-intelligence function call”，返回值类型是 dict[str, Distribution]，不是 str。

2. 并行采样：state 只编码一次，问题彼此独立

docs 里写的是 “Jev ingests the state once and evaluates every question against it in parallel”，context 预算是“state + 所有问题 ≤ 64k，state + 最长的那个问题 ≤ 32k”。这个预算形状强烈暗示：state 做成共享前缀只编码一次，每个问题作为互不可见的分支分别和 state 交互（问题之间互不当作上下文，官方明确说“不会 context-rot”）。所有选项的概率在同一次查询里一起给出，不做逐 token 自回归解码，所以多加一个问题的边际延迟接近 0，docs 甚至鼓励“speculative fan-out”：可能用得上的问题全部一起问，用不上的由代码丢掉。

flowchart LR
  subgraph LLM["LLM path"]
    P["Prompt"] --> D["Token decode loop"]
    D --> T["Free text"]
    T --> V["Parse and validate"]
    V -->|"fail"| RT["Retry"]
    RT --> D
  end
  subgraph S1["System One path"]
    ST["State"] --> EN["Encode once"]
    QS["Typed questions"] --> EN
    EN --> PS["Parallel scoring"]
    PS --> DIST["Probs per option"]
  end
  V -->|"ok"| CODE["Your code"]
  DIST --> CODE
  CODE -->|"threshold"| BR["Branch or escalate"]
          

3. RLCD：用校准作为训练目标

RLCD 的输出契约：不生成文本，只给决策和概率；概率越高，答对的机会就应该越大。calibration 的定义：

博客和 docs 都没有披露奖励函数、数据来源（只说“数据全部自己造”）、模型结构（只说是 “new model architecture”，并且 “neither small nor an LLM”）。推测：如果奖励用的是 proper scoring rule（log score 或 Brier），那么对“单步决策”做 RL，在数学上接近用交叉熵做监督分类，“RL”这个名字更多是在强调目标，而不是算法。

直观理解：RLHF 让模型学会“说人爱听的话”，RLCD 让模型学会“诚实地报出自己有几成把握”。

4. Confidence：从分布算出的第二个维度

Choice 和 Score 的 confidence 由 probabilities 的集中程度算出，docs 给了一个 K 选项的近似式（全部概率集中在一个选项时为 1，均匀分布时为 0）：

比如 3 个选项、分布为 (0.90, 0.06, 0.04)，confidence ≈ (2.7−1)/2 = 0.85。docs 推荐的用法是风险分级阈值：confidence < 0.5 一律转人工；低风险动作（查余额）直接执行；高风险动作（批准转账）要求 > 0.9，否则让用户确认。模型只负责给出答案和把握程度，风险容忍度由代码来编码。

5. 组合方式：原子问题 + 代码里的权重和分支

官方的设计哲学是“每个问题只问一个行家一秒钟就能判断的事”。像“分析这条消息并决定最佳处理方式”这种需要 System 2 的问题，要拆成多个原子问题，再在代码里用权重组合（Composite scoring）。一个答案决定下一步要取什么数据、问什么问题时，才发第二次请求（例如先对 182 个 skill 排序，取 top-3 全文再判一次）。下图是博客公开的 4 个 workflow 里最简单的一个：安全告警处理。

6. 最关键的一句话

放弃字符串生成，把模型重新训练成“对任意文本 state，一次并行给出多个预定义问题的校准概率”的决策函数；类型安全来自结构，速度来自不解码，可靠性来自 calibration + 代码里的阈值。

主要实验结果

作者自己把结论分成两类：容易验证的（速度、价格、不会出类型错误）和更大胆的（智能水平、hallucination 对比）。后者每一项都附了 “Nuance” 免责说明，下面一并列出。

1. Side-by-side demo（video）

• 同一段客户描述、同一组问题，Jev 一次性并行出全部概率，GPT-5.6 Terra（默认 reasoning）逐 token 生成。录制那次两者只有 “Churn likelihood level” 一项不一致，作者认为这题本身就有歧义。
• Nuance：query 被高度简化，key 刻意取成人能看懂的名字；state 是一段短而密的段落。输入越短对 Jev 越有利，作者自己也承认这一点。选 Terra 做对照，是因为它“平均智能最接近 Jev”。

2. Workflow evals：accuracy vs cost

评测协议：假设存在一个正确的计算图（用代码写成的 workflow），所有模型都跑同一个 workflow，不允许改 harness（避免 harness engineering 过拟合）。以 GPT-6 Astra 与 Fable 5.1 概率的平均作为参考答案，比较各模型走完 workflow 后的最终结果与参考是否一致。LLM 都通过 System One LLM adapter 接入，被约束成输出与 Jev API 相同格式的结构化决策（含概率）。另有一组 “prompt” 模式：把整个 workflow 的逻辑写进 prompt，让 LLM 在 CoT 里自己推，效果明显更差。

flowchart LR
  IN["Eval case"] --> WF["Fixed workflow code"]
  WF -->|"questions"| MUT["Model under test"]
  WF -->|"questions"| REF["Avg of Astra and Fable"]
  MUT -->|"probs"| RUN1["Run branches"]
  REF -->|"probs"| RUN2["Run branches"]
  RUN1 --> CMP["Same final action"]
  RUN2 --> CMP
          

博客原图 + 读数表

模型	模式	cost / workflow (USD)	accuracy	相对 Jev 成本
Jev	workflow	≈ 0.0004	≈ 67.8%	1x
GPT-5.6 Luna	workflow	≈ 0.0033	≈ 66.8%	≈ 8x
DeepSeek v4 flash	workflow	≈ 0.006	≈ 64.4%	≈ 15x
Haiku 4.5	workflow	≈ 0.020	≈ 53.6%	≈ 50x
GPT-5.6 Terra	workflow	≈ 0.030	≈ 67.9%	≈ 75x
DeepSeek v4 pro	workflow	≈ 0.041	≈ 65.5%	≈ 100x
GPT-5.6 Sol	workflow	≈ 0.083	≈ 74.2%	≈ 210x
Sonnet 5	workflow	≈ 0.12	≈ 67.8%	≈ 300x
Opus 5	workflow	≈ 0.18	≈ 73.1%	≈ 440x
Opus 5	prompt	≈ 0.34	≈ 64.9%	≈ 850x
GPT-5.6 Sol	prompt	≈ 0.20	≈ 63.5%	≈ 500x

• 定量结论：Jev 在约 $0.0004 / workflow 的位置拿到约 67.8%，和 Terra（贵约 75x）、Sonnet 5（贵约 300x）持平，在将近 2 个数量级的成本范围内独占 Pareto frontier。但绝对准确率最高的是 Sol（约 74%）和 Opus 5（约 73%），比 Jev 高 5–6 个百分点。首页 “193.6x faster, 444.6x cheaper” 就出自这组 eval，作者自己说这是“真实收益的高端”，博客没说明对比的是哪个基线。
• workflow vs prompt：同一个 LLM，把逻辑交给代码（workflow）比让它在 CoT 里自己推（prompt）高 5–10 个百分点，而且更便宜。这其实是整篇文章里最有普遍意义的实证：结构化分解 + 代码控制流，胜过让 LLM 端到端推理。
• Nuance：workflow 不在训练分布里，但由 TypeSafe 模型能力团队编写；参考答案偏向 OpenAI / Anthropic，作者认为 Jev 和 DeepSeek 因此被低估；adapter 让 LLM 输出带概率的决策，比直接输出离散答案更慢、更贵。

3. Hallucination 与 type-safety

• 论点：agent 里偶尔 hallucinate 一个 tool call 只是麻烦，但放进有延迟保证的系统、或者埋在好几层依赖链下面，就是 deal-breaker。
• Nuance（很重要）：LLM 的数字来自 OpenRouter 的统计，复杂请求可能被路由到更强的模型，偏差难免；Jev 的 0% 不是实测，而是“schema matching 在结构上有保证”，所以直接填了 0%。

4. Fun demos

局限与展望

• 已知局限（官方承认或 docs 写明的）：
  • 只接受文本，不支持图像 / 音频 / 视频；英文最好，CJK 等语言准确率更低。
  • state 加最长问题的上限是 32k token；docs 另有 “Jev 1.13 jaggedness” 页面，说明 state 越长准确率越会变化。
  • Choice 最多 255 个候选；同一请求里的问题互相看不到，多步推理只能由代码拆成多次调用。
  • 不生成文字，不能写回复、写代码、解释理由；不能接到 coding agent 后面当 LLM 用。
  • 不接受客户数据微调 / LoRA，领域知识只能写进 state 和 criteria。
  • 价格“可能有补贴”，长期可持续性作者也说要靠时间证明；rate limit 还在动态调整。
• 怀疑者会说它等价于什么：
  • 接口层面：这就是一个 frontier 规模的 zero-shot 分类器 / reward model / cross-encoder。LLM 其实也能做到 0 类型错误和“并行”：读出候选 label 的 next-token logprob（一次 forward 给所有选项打分），加上 prefix caching（如 SGLang RadixAttention）共享 state，或者用 constrained decoding（Outlines、XGrammar）。所以 “0% hallucination”的对比有稻草人成分：它比较的是 Jev 的结构保证和 LLM 走自由文本 / JSON 的实测错误率，而不是和 logit-masked LLM 比。
  • 评测层面：accuracy 衡量的是“与 Astra + Fable 平均的一致率”。如果 Jev 的训练数据（“全部自己造”，未披露）是用 frontier LLM 标注的，那 Jev 本质上就是对 frontier judge 的蒸馏，这个 eval 测的是蒸馏保真度。它有意义，但说明不了“新的智能前沿”。
  • 基线层面：adapter 要求 LLM 用文字报出每个选项的概率（verbalized probability），这种方式本来就校准差、token 开销大，LLM 的成本和准确率都可能被拉低。
  • 可验证性：没有论文，没有架构和训练细节，刻意不跑公开 benchmark；4 个 workflow 由内部团队编写。真正能独立验证的只有速度、价格和 schema 保证。
• 真正新的一点是什么：技术原语（分类头、共享前缀、校准训练）都不新。新的是把“决策函数”作为独立的 frontier 产品类别：一个号称不是 LLM 的模型，专门为“长结构化 state 上的多问题校准判断”端到端训练，定价只算输入（$0.042/MTok），延迟亚秒。如果 calibration 真的成立，confidence-gated routing（按置信度决定自动执行还是升级给人 / 推理模型）就会变成一种便宜的系统设计原语。这一点目前缺少公开的 reliability diagram 或 ECE 证据，是最该追问的地方。
• 研究趋势：这篇文章处在 “LLM-as-judge → reward model → verifier” 这条线的产品化终点，和 harness engineering / 自改进 agent 的思路是互补的。在 agent harness 里，便宜、校准过的 verifier 正是瓶颈：用 Jev 这类 System 1 模型给 agent 的每一步做 guardrail、路由和打分，贵的 System 2 LLM 只在低 confidence 时才调用，这就是一种 System 1 / System 2 的级联。另一个值得记住的实证是 workflow > prompt：把控制流从 CoT 里拿出来写进代码，对 LLM 本身也有 5–10 个百分点的提升，和近期“结构化分解胜过端到端推理”的 harness 研究结论一致。后续值得看的：是否公开 calibration 曲线，是否支持图像 state，255 的基数上限和 32k state 上限能否放开，以及价格在补贴之外能否持续。

FAQ 摘录