Jev 与 System One Models：把 AI 变成代码里的一个判断 Jev and System One Models: turning AI into a decision inside your code

01为什么写这篇Why this note exists

我在做文档识别与流程自动化的过程中反复遇到同一个卡点：规则的边界太清楚，模型的输出又太自由。 Working on document understanding and process automation, I kept hitting the same wall: hand-written rules are too brittle, while model output is too free-form.

用规则写「什么算 A 类单据」，遇到版式变化就失效；用 LLM 读，判断质量更好，但它返回一段文本，还是要解析、校验、处理它偶尔越界的情况——而且慢、贵、结果不稳定。中间那一格（判断带不确定性，但输出必须严格结构化）一直缺一个合适的接口。 Rules break when the layout changes. An LLM reads better, but returns text: it still has to be parsed and validated, it sometimes goes out of range, and it is slow, costly and inconsistent. The middle cell — a judgement that carries uncertainty but returns strictly structured output — had no good interface.

Jev 声称要填的就是这一格。这篇文章的目的不是替它背书，而是把「它到底提供什么、边界在哪、该怎么判断要不要用」讲清楚。 Jev claims to fill exactly that cell. This note is not an endorsement: it tries to pin down what it actually offers, where its boundaries are, and how to decide whether to use it.

阅读建议：第 2 到第 4 节是"是什么、不是什么、长什么样"，可以当作概念梳理读；第 6 节（校准）与第 7 节（成本）是技术核心，决定它在真实流程里能不能用；第 10 节之后是我的判断与待验证清单。如果只读两节，读第 3 节和第 6 节——分别回答"别把它当成什么"和"凭什么信它的概率"。 How to read it: sections 2–4 cover what it is, what it is not and what a call looks like; sections 6 and 7 are the technical core — calibration and cost — that decide whether it survives contact with a real pipeline; sections 10 onwards are my view and open questions.

02它是什么What it is

官方定义（原文）：Jev 是一个 System One Model——「a new class of frontier models built to make fast, structured decisions that software can use directly」，一句话版本是「a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out」。[1] Official definition: Jev is a System One Model — "a new class of frontier models built to make fast, structured decisions that software can use directly", summarised as "a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out".[1]

配套的技术主张有三条：新的模型架构、并行采样器（parallel sampler）、以及一套新的训练方法 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）。官方把它的定位放在既有两代之后：RLHF 优化人类偏好产出对话模型，RLVR 用可验证奖励产出推理模型，RLCD 则直接以「带校准概率的决策」为训练目标。[1] Three technical claims accompany it: a new architecture, a parallel sampler, and a new training method, RLCD — Reinforcement Learning for Calibrated Decisions. The vendor places it after two earlier generations: RLHF optimised human preference into chat models, RLVR used verifiable rewards into reasoning models, and RLCD trains directly for calibrated decisions.[1]

压成三句话记住：① 输入是"状态"而不是"对话"——你给它一段程序状态，它不需要像聊天那样理解上下文；② 输出是"决策 + 概率"而不是"文字"——取值空间由你事先定义；③ 训练目标是"让概率值得信"，而不是"让人类觉得回答得好"。这三点合起来，才是"接口"在这里的意思。 Three sentences to remember: the input is state rather than a conversation; the output is a decision plus a probability rather than text; the training target is that the probability deserves trust. Together, that is what "interface" means here.

03它不是什么What it is not

这一节比上一节重要。新产品发布时，误读通常发生在边界上。 This section matters more than the previous one: misreadings usually happen at the boundaries.

• 不是分类算法。分类是它的一种用法，但「逻辑回归 / 随机森林」意义上的分类器输出是标签，附加概率需要另行校准；Jev 的定义里，输出空间前置、概率校准、不生成字符串是三件事一起的。[1] Not a classification algorithm. Classification is one use. A logistic regression or random forest outputs a label and needs separate calibration; here, a predefined output space, calibrated probability and no string generation come as a package.[1]
• 不是聊天模型。官方明确说它放弃字符串生成，因此不适用于写文案、写代码、开放式问答、需要推理链的任务。拿它去聊天，等于放弃了它的全部优势。[1] Not a chat model. The vendor explicitly gives up string generation, so writing, coding, open-ended Q&A and chain-of-thought tasks are out. Using it for chat discards everything it is good at.[1]
• 不是你训练出来的自有模型。它是通过 API 调用的托管模型（早期访问）；可以调阈值、可以定义输出空间，但「用你的数据重训一遍」不在当前描述内。[1] Not a model you train yourself. It is a hosted, API-accessed model in early access: you tune thresholds and define the output space, but retraining on your own data is not part of the current description.[1]
• 不是「万能判断器」。它做判断，不做检索、不算数、不查数据库；事实类输入仍然要由你的系统先准备好。 Not a universal oracle. It makes judgements; it does not retrieve, compute or query databases. Your system still has to prepare the facts.

四个常见误解，逐个拆开

• "这不就是个分类器吗？"分类只是它的一种形状。真正的差别有三处：输出空间由你事先定义（不是模型自由发挥）、每个答案自带校准概率、以及不生成任何自由文本。把它当分类器用，等于放弃了后两项。 "Isn't this just a classifier?" Classification is one shape. The differences: you define the output space, every answer carries a calibrated probability, and no free text is generated.
• "不幻觉，所以可以全自动。"不幻觉不等于不出错。它不会编造取值之外的标签，但依然可能判断错——把 A 类判成 B 类，只是它会告诉你自己有多确定。能不能全自动，取决于错误代价，而不是概率好不好看。 "No hallucination means full automation." It can still judge wrongly; it just reports how confident it is. Full automation is a question of the cost of error.
• "便宜就能替代 LLM。"两者解决的是不同问题：LLM 负责写出来与开放式推理，决策层负责做判断并给出置信度。真实系统里通常是 LLM 处理文档与解释，决策层负责阈值与路由。 "Cheaper means it replaces LLMs." They solve different problems: LLMs write and reason openly; a decision layer judges and quantifies confidence. Real systems use both.
• "阈值设成 0.9 就安全了。"阈值不是安全参数，而是业务参数：调高会减少错误，同时把更多个案推给人工。要盯的是"复核率"与"漏检率"两条线的组合，而不是单一阈值。 "A 0.9 threshold makes it safe." It is a business parameter: raising it cuts errors and pushes cases to humans. Monitor the pair — review rate and miss rate.

04一次调用长什么样What one call looks like

把一次调用摊开，只有四步：把状态（文本、残缺字段、程序状态）交给模型 → 模型返回一组类型化的决策，每个都带概率 → 你在代码里设阈值决定谁自动执行 → 低置信度的走人工，并留下记录。 One call, four steps: hand over the state (text, partial fields, program state); the model returns typed decisions each carrying a probability; your code applies a threshold to decide what runs automatically; low-confidence cases go to a human, with a record kept.

05为什么快两个数量级Why it is two orders of magnitude faster

现有 LLM 是自回归的：一个 token 一个 token 地生成，每个都依赖前一个，时间和费用随输出长度线性累加。官方称 System One Models 用并行采样——在一次查询里同时产生全部输出，所以不随「输出个数」累积延迟。[1] Existing LLMs are autoregressive: one token at a time, each conditioned on the last, so time and cost accumulate with output length. System One Models instead use a parallel sampler: all outputs are produced within a single query, so latency does not accumulate with the number of outputs.[1]

06校准：为什么「有概率」比「更准」重要Calibration: why a probability beats accuracy

官方对这件事的表述很直接：如果一个模型有 95% 的情况下能做对，但从不说自己什么时候处在错的 5% 里，那么这个任务就没法被自动化。[1] The vendor puts it plainly: if a model does a task correctly 95% of the time but never signals which 5% it is wrong on, that task cannot be automated.[1]

「校准」的含义是：模型说 0.9 的那一批判断里，实际对的比例接近 90%。做不到这一点，概率只是一个数字，不能作为阈值依据。校准的常用检验工具是可靠性曲线——横轴是模型声称的置信度，纵轴是实际正确率，理想情况是 45° 对角线。 Calibration means: among judgements rated 0.9, roughly 90% are actually right. Without it, a probability is just a number and cannot carry a threshold. The standard check is a reliability diagram — claimed confidence on the x-axis, observed accuracy on the y-axis, the diagonal being perfect.

07成本与延迟怎么算Cost and latency, and how to check them

官方价格口径：输入 $0.042 / MTok（即每十亿输入 token 42 美元），输出不计费；延迟 70–500 ms。对照的现有 LLM 区间是输入 $0.20–10 / MTok、输出约为输入价的 5 倍，端到端 3–329 秒。[1] Vendor pricing: $0.042 / MTok input (i.e. $42 per billion input tokens) with output free, at 70–500 ms. The comparison range for existing LLMs is $0.20–10 / MTok input, output about 5x the input price, and 3–329 s end to end.[1]

为了让这两组数字可比较，我做了最简单的换算：假设每次决策消耗 1,000 个输入 token，那么 1,000 次决策正好用掉 1 MTok，可以直接用单价读——LLM 是 $0.20–10.00，Jev 是 $0.042。这个换算剔除了输出 token（对 Jev 恰好是 0，对 LLM 是偏保守的算法），假设是本文的，不是官方的。 To make the two comparable I applied the simplest possible conversion: assume 1,000 input tokens per decision, so 1,000 decisions consume exactly 1 MTok and the unit price can be read directly — $0.20–10.00 for LLMs, $0.042 for Jev. Output tokens are excluded (exactly zero for Jev, and conservative for LLMs). The assumption is mine, not the vendor's.

08一个具体场景：单据分拣与路由A concrete case: document sorting and routing

下面这个流程纯粹是示意：我不引用任何真实业务数据，数字都是编的，只用来说明「决策层插在哪一步、阈值怎么起作用」。 The flow below is purely illustrative: no real business data, invented numbers, only there to show where a decision layer sits and how thresholds work.

设想一批版式不统一的单据：OCR 会带进噪声，字段有时缺、有时串行。传统做法是写一堆规则来判定类型与完整性；这里的做法是在规范化之后插一层决策：这属于哪一类（分类）、这个字段值能不能采信（打分）、缺的字段是不是必须退回补件（分支），每一项都带概率。 Take a pile of inconsistently formatted documents: OCR brings noise, fields are sometimes missing or misaligned. The conventional answer is a pile of rules. The alternative inserts a decision layer after normalisation: which category is this, is this field value trustworthy, and must it be sent back for more material — each with a probability.

阈值 0.9 到底意味着什么

设想每月 1,000 份材料进来，阈值设 0.9：假设约 70% 的个案概率超过阈值，就是 700 份自动落库、300 份进人工复核。如果"0.9"真的意味着九成正确，那么自动落库的那 700 份里约有 70 份是错的；若把阈值加到 0.95，可能只剩 400 份自动、约 20 份错，代价是人工量从 300 涨到 600。于是问题不再是"模型准不准"，而变成一个纯粹的算术题：你更愿意承担 50 份错单，还是多花 300 次人工？这也解释了为什么校准如此关键——如果模型说 0.9 而实际只有 0.7 对，上面每一个数字都要重算。 Take 1,000 documents a month at a 0.9 threshold: if 70% clear it, 700 post automatically and 300 go to review. If 0.9 truly means 90% accurate, about 70 of those 700 are wrong. Raise it to 0.95 and perhaps 400 post automatically with 20 errors, at the cost of 600 reviews. The question stops being "is the model accurate" and becomes arithmetic: fifty wrong postings, or three hundred extra reviews? That is why calibration decides everything here.

09三者对比Three-way comparison

10局限与反方观点Limits and the case against

这一节我尽量站到对面去写。目前关于 Jev 的全部公开信息都来自一家公司自己的叙述，而官方在同一篇里已经把该被质疑的地方标了出来——这点值得肯定，但也不能因此免除验证义务。 I have tried to argue the other side here. All public information on Jev comes from the company itself, and to its credit the vendor flags where scepticism is due — which does not remove the need to verify.

• 评测口径由卖方定义。官方承认：评测 workflow 由其模型能力团队构造，可能存在偏差；参考答案取 GPT-6 Astra 与 Fable 5.1 的平均，偏向 OpenAI 与 Anthropic，官方估计这反而低估了自家表现；LLM 一侧的数字来自 OpenRouter，复杂查询可能被路由到更强的模型。[1] The vendor defines the yardstick. The vendor acknowledges the workflows were built by its own capability team; the reference answer is the average of GPT-6 Astra and Fable 5.1, biased toward OpenAI and Anthropic (which the vendor says understates its own results); and the LLM-side numbers come from OpenRouter, where complex queries may be routed to stronger models.[1]
• 「零幻觉、零类型错误」是机制推论，不是独立实测。官方明说那一项数字不是经验值。机制上说得通（不生成自由文本，就不存在越界生成），但它衡量的是失败模式的空间，不等于准确率。[1] "Zero hallucination, zero type errors" is a structural argument, not an independent measurement. The vendor states the figure is not empirical. The mechanism is plausible — no free text means nothing to go out of range — but it bounds a failure mode rather than establishing accuracy.[1]
• 价格可持续性未经验证。官方自己写了「我们无法证明它没有补贴」；早期访问阶段的价格未必是长期价格。[1] Price sustainability is unproven. The vendor writes that it cannot prove the pricing is not subsidised; early-access pricing need not be long-term pricing.[1]
• 服务与合规细节未知。官方提到评测多数在西海岸的笔记本上跑（服务当前所在区域）；训练数据来源、是否用于训练、私有部署、数据留存都未在这两篇材料里说明。[1] Service and compliance details are unknown. The vendor notes evals were mostly run from laptops on the West Coast, where the service currently sits. Training data provenance, opt-out, on-premise deployment and retention are not covered in these two pieces.[1]
• 能力边界仍然模糊。官方 FAQ 自己列了六个待展开的问题：为什么需要新的训练算法、适合哪些用例、它是否只是个更小的 LLM、公开基准表现如何、训练数据从哪来、结果为何可能。 Capability boundaries remain open. The vendor's own FAQ lists six questions it has not yet answered: why a new training algorithm was needed, which use cases fit, whether it is just a smaller LLM, how it performs on public benchmarks, where the training data comes from, and how the results are possible.[1]

11我的判断My take

12落地前该问的八个问题Eight questions before a pilot

如果要把这类服务接进内部流程，我整理了一份提问清单。每条都附上「为什么要问」，方便直接拿去开会问供应商。 If a service like this is to enter an internal pipeline, here is the list of questions I would bring to the vendor, each with the reason it matters.

1. 校准怎么评估？用可靠性曲线还是单一数字？分箱方式与样本量是多少？——决定「概率能不能拿来设阈值」。[1] How is calibration evaluated? Reliability diagram or a single number; what binning and sample size? This decides whether the probability can carry a threshold.[1]
2. 分布外会怎样？换一批版式、换一个业务线之后，置信度是否可靠地下降？——校准失效通常发生在换场景的时候，不在同分布内。 What happens out of distribution? Does confidence fall reliably when layouts or business lines change? Calibration usually breaks on a change of setting, not within one.
3. 能不能拒答？有没有显式的「我不知道 / 弃权」输出，而不是被迫在给定标签里挑一个？——这决定低置信度个案能不能优雅退出。 Can it abstain? Is there an explicit "I don't know" output rather than being forced to pick a label? This determines whether low-confidence cases can exit gracefully.
4. 输出选项上限多少？官方提到单次支持到 255，更高需两段式。[1]——直接决定一个大问题能不能一次问完。 What is the cardinality limit? The vendor reports up to 255 in one call with a two-stage scheme beyond that.[1] It decides whether a problem fits in one shot.
5. 延迟分布如何？要 p50 / p95 / p99，不要平均值；并确认服务所在区域与你的用户之间的距离。[1] What is the latency distribution? Ask for p50 / p95 / p99 rather than an average, and confirm where the service sits relative to your users.[1]
6. 我们的数据会被用于训练吗？能不能关闭、留存多久、能不能删除？——金融与保险场景里这一条通常先于性能讨论。 Is our data used for training? Can it be turned off, how long is it retained, can it be deleted? In finance and insurance this usually precedes any performance discussion.
7. 能不能私有化 / 区域部署？如果监管不允许把数据发到外部服务，这一条直接决定可行性。 Is private or regional deployment possible? If regulation forbids sending data to an external service, this single answer decides feasibility.
8. 版本与回滚怎么办？模型升级后概率会不会变？能不能固定版本、能不能 A/B 比较？——上线之后真正的风险是「同一个输入，行为悄悄变了」。 How do versions and rollbacks work? Do probabilities shift after an upgrade; can a version be pinned and A/B compared? The real risk in production is silent behavioural change on the same input.

13来源Sources

1. Diogo Almeida. Introducing System One Models & Jev. TypeSafe AI Blog, 2026-09-15. typesafe.ai/blog/introducing-system-one-models-and-jev
   本文引用的定义、四代对照、评测方法与偏差说明、成本与延迟区间、命名来源（Kahneman / Jevons）、Doom 与 Wikiracing 演示、cardinality 上限均出自此文。 Definitions, the four-generation comparison, eval methodology and stated biases, cost and latency ranges, naming (Kahneman / Jevons), the Doom and Wikiracing demos and the cardinality limit all come from this post.
2. TypeSafe AI 官网首页，访问日期 2026-09-25。 typesafe.ai
   193.6× faster / 444.6× cheaper 与 $42 per billion input tokens 的表述出自首页；官方在发布文中说明这组数字来自其挑选的 workflow 评测。 The 193.6x / 444.6x and $42 per billion input tokens statements come from the homepage; the launch post explains they derive from the vendor's chosen workflow evals.
3. Daniel Kahneman. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.
   「System 1 / System 2」命名的出处（官方 FAQ 指明灵感来源）。 Source of the System 1 / System 2 naming, which the vendor's FAQ cites as the inspiration.
4. Jevons paradox. Wikipedia. en.wikipedia.org/wiki/Jevons_paradox
   「效率提升反而增加总消耗」这一经济史背景（模型命名取自 William Stanley Jevons）。 Background on efficiency gains raising total consumption; the model is named after William Stanley Jevons.

14引用本文Cite this note

Aylon (2026). Jev 与 System One Models：把 AI 变成代码里的一个判断. Notes, v1.0. https://aayloo.github.io/notes/jev-system-one-models/

15分享版摘要Shareable summary

Jev 不是「更聪明的分类器」，而是一类新的接口：非结构化状态进，带校准概率的类型化决策出。它放弃了生成字符串——换来的是延迟（70–500 ms）、成本（输入 $0.042/MTok、输出不计费）和类型安全三件事同时改善。

真正的价值不在「更准」，而在能被代码依赖：知道自己在哪些个案上不确定，于是可以设阈值、可以让低置信度走人工、可以审计。官方口径与我的判断，我在文里分开写了。

16更新日志Changelog