JEV深度解读与使用教程

先说结论

• JEV 不是聊天模型，而是 TypeSafe 的 System One 决策模型：输入文本，返回类型化答案与校准概率，不生成解释和自由文本。官方把这类能力称为“Machine Native Intelligence”，强调结构、可靠、可观测、可测试、快、一致和低成本。（官方 AI primer）
• 训练路径 RLCD 与 RLHF、RLVR 不同：RLHF 优化“人类偏好的文本”，RLVR 优化“可验证奖励”，RLCD 优化“校准决策”。校准意味着概率 0.2 的输出在群体上约 20% 发生，但不保证单条正确。
• 三种 primitive 的返回字段必须记牢：Choice 返回 choice、probabilities、confidence；Score 返回 score、legend、probabilities、confidence，且 Score 的 criteria 是有序数组；Noul 只返回 0~1 的 noul，没有 confidence，也没有 probabilities。
• 工程价值在于把不确定性变成代码可分支的信号：用 confidence 做风险门控，用 noul 做候选重排，用 choice 做路由。但阈值不是官方替你决定的，官方只给了模式和三档风险思路。
• 官方价格：输入 token 每十亿 $42，输出 token 免费；限流为 250,000 tokens/秒与 1,200 请求/分钟，官方明确这些限流会动态调整。一万次判定多少钱，后文给出可复算的推算方法。

1 原理：RLCD 不训练“说得好”，训练“判断得准”

TypeSafe 的 AI primer 把主流训练路径分成三类：

• RLHF：基于人类偏好训练，让模型生成用户更喜欢的回复。它的产物是聊天模型。
• RLVR：基于可验证奖励训练，适合数学等有确定答案的任务，推理更强，但更慢、更贵。
• RLCD：基于“校准决策”的强化学习，训练目标是返回决策和校准概率，而不是生成文本。

官方 AI primer 给出的 RLCD 输出契约很明确：模型不生成文本；它返回决策和概率；概率越高，答案越可能正确；校准使得软件可以直接消费不确定性。

官方原文对校准的解释是：

“Outcomes assigned a probability of 0.2 should occur about 20% of the time. Outcomes assigned a probability of 0.8 should occur about 80% of the time. Outcomes assigned a probability of 1.0 should occur 100% of the time. These rates describe groups of predictions, not a guarantee about any single answer.”

这段话的关键在最后一句：校准说的是群体频率，不是单条保证。它回答的问题是“这类判断有多大概率正确”，而不是“这条判断一定正确”。

AI primer 还解释了为什么 RLHF 不适合直接搬到生产自动化：偏好优化可能奖励谄媚和听起来很自信的幻觉，并且会造成模式掉落，使模型倾向于某一种风格而降低其他输出的概率。TypeSafe 的立场是：人类偏好和机器可信度是两个不同的优化目标；生产自动化需要面向受限决策和校准不确定性重新设计训练目标。

System One 这个名字来自 Daniel Kahneman 的“快慢思考”框架：System 1 是快速、直觉式的，System 2 是缓慢、审慎的。JEV 是第一个 System One 模型，强调“快速、聚焦的判断”，不是慢推理。

2 System One 形态：输入文本，输出字段

官方 System One 页面写明，JEV 目前只接受文本输入，可以处理字符串、JSON 对象和文本数组；图像、音频、视频暂不支持。

它还明确规定：

“System One models do not write replies, produce code, or generate explanations of their reasoning.”

也就是说，它不是聊天工具，也不是推理代理。它只做一件事：根据给定的 state，对定义好的问题给出类型化答案和概率。

三种问题类型由 官方 Primitives 页面定义，字段形状如下：

Primitive	问题类型	返回字段（官方）
Choice	从已知选项里选一个	choice、probabilities、confidence
Score	看一件事落在哪个等级	score、legend、probabilities、confidence
Noul	判断一个断言是否成立	noul，取值 0~1

这里最容易被搞错的点是：Noul 没有 confidence，也没有 probabilities。官方 Confidence 页面补充得也很直接：

“Noul answers don’t carry one.”

Score 的 criteria 不是随便写几个标签，而是一个有序数组，从低到高排列。官方 Primitives 页面把 Score 的 criteria 描述为“an ordered list of levels for a Score”。工程上这很重要，因为分数是带方向性的：0 是低，2 是高，顺序错会导致语义错位。

Choice 适合“没有天然顺序”的选项，比如路由到哪个部门、文档类型分类；Score 适合“有光谱、有等级”的问题，比如用户挫败程度、风险等级；Noul 适合“是否满足某个条件”的二元问题，但返回的是连续概率，而不是只能给一个布尔值。

3 接口、模型名、SDK 与 Agent skill

根据官方 Quick start 和 Models 页，调用入口是：

POST https://api.typesafe.ai/v1/systemone

请求中的 model 字段选择模型。官方 Models 页写，jev-latest 是 SDK 默认值，当前指向 jev-1.13.0；jev-preview 当前也指向同一个版本。响应里的 model 字段会返回实际处理请求的版本化 ID，方便你记录每一次判定来自哪个版本。

Python SDK 的安装和调用方式，官方 Quick start 给了示例。下面是我根据官方示例改写的代码，重点展示三种 primitive 的字段读取，不是官方逐字示例：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # 默认模型 jev-latest，读取 TYPESAFE_API_KEY

state = "用户：连续三天绑定 Stripe 都失败，正在损失订单，请尽快处理。"

response = client.system_one(
    state=state,
    questions={
        "department": Choice(
            instructions="哪个团队更适合处理这条消息？",
            criteria={
                "billing": "支付或订阅问题",
                "technical": "集成或系统故障",
                "sales": "价格或账户问题",
            },
        ),
        "frustration": Score(
            instructions="用户有多懊恼？",
            criteria=[
                "平静，只陈述事实",
                "懊恼但克制",
                "非常愤怒，带强烈措辞",
            ],
        ),
        "is_urgent": Noul(
            instructions="消息是否表达时间紧迫性？",
        ),
    },
)

print(response.answers["department"].choice)   # choice 返回字符串
print(response.answers["frustration"].score)   # score 返回数值
print(response.answers["is_urgent"].noul)      # noul 返回 0~1 的值

JavaScript SDK 同样存在，官方 Models 页面给出了类似 import { TypeSafeClient } from "@typesafe-ai/sdk" 的用法。控制台入口是 Playground 和 API keys 页面，Quick start 有直接链接。

Agent skill 方面，官方 Quick start 提供了两种安装路径：Claude Code 插件市场，或者 npx skills add typesafe-ai/skills --skill typesafe-ai。安装后可以提示编码代理“理解 TypeSafe API 结构并用它构建项目”。我的判断是，Agent skill 更适合让编码代理在不熟悉的项目里快速接入 Jev，而不是替代 OpenAPI 参考文档。

4 工程用法：Patterns 与 Cookbooks 各管什么

官方文档把 Jev 的用法分成 Patterns 和 Cookbooks。本次我读到的正文有限，因此把能核实的写出来，核不出的单独标注。

官方实践	解决什么问题	本次读到的一手来源
Speculative fan-out	在一个请求里打包很多问题，让 Jev 并行评估，适合需要同时判断多个维度的场景	官方 Models 页提到“See Speculative fan-out for packing many questions into one request”
Confidence-gated routing	用 confidence 把决策分成可自动处理、需谨慎、不应自动执行几档，实现风险门控	官方 Confidence 页
Composite scoring	把宽泛判断拆成原子问题，再在代码里组合这些分数或概率	官方 Models 页提到“Decompose broad judgments into atomic questions and combine the outputs in code. See Composite scoring”
Intent routing	官方导航中存在该 Pattern，但本次未读到其页面正文，具体定义未能核实	未能核实

官方 Cookbook	解决什么问题	本次读到的一手来源
Guardrails for LLMs	对进入和离开 LLM app 的每条消息做一次性安全检查，用 Noul 检测多项危害，用 Score 评估严重度，然后根据阈值 pass/review/block/route	官方 Guardrails cookbook
Re-ranking	先用 BM25 等方法召回候选短名单，再用 Noul 对每个 query-candidate 对独立打分，按 noul 从高到低排序，提升 top-1/top-10 精度	官方 Re-ranking cookbook
Citation check	官方 Cookbooks 列表中有此标题，本次未读到正文，具体用途未能核实	未能核实
Function calling	同上	未能核实
Skill suggestion	同上	未能核实

Guardrails cookbook 的做法值得注意：它不是用一条模糊的“内容是否越界”让模型给结论，而是拆成多个 Noul 问题，例如“是否试图覆盖助手指令”“是否寻求伤害或犯罪帮助”“是否询问诊断或剂量”“是否表达自伤信号”，再用一个有序 Score 问题评估“如果照做，可能造成多大危害”。这样一次请求就得到一组概率和严重度，后续策略用代码控制。

Re-ranking cookbook 给了官方实验数据：在 CLERC 法律检索任务上，BM25 先把 3,565 段法庭意见缩减到每查询 30 个候选，再用 Jev 重排，top-1 准确率从 5% 提升到 18%，top-10 从 38% 提升到 62%。这是官方实验数据，我没有独立复现。

5 成本与限流：官方数据与一万次判定推算

以下是官方 Models 页给出的数据：官方 Models 页

• 价格：Jev 1.13 $42 / Btok（每十亿输入 token），也写作 $0.042 / Mtok。官方写明“Charged per input token. Output tokens are free.”
• 限流：250,000 tokens/秒，以及 1,200 requests/分钟。超出会返回 429 Too Many Requests。
• 官方特别强调：“Rate limits are adjusting dynamically. … the limits above can change without notice.”
• 上下文：64k tokens 每请求；其中 state 加最长问题的预算是 32k tokens。
• 别名：jev-latest 当前指向 jev-1.13.0，jev-preview 也指向同一版本。

一万次判定费用的推算，我按以下方式自己计算，不是官方报价：

费用 = 每次请求输入总 tokens × 10,000 / 1,000,000,000 × $42

假设一个典型判定请求的 state 加一个 Noul 问题，输入约 600 tokens。那么一万次判定：

600 × 10,000 / 1,000,000,000 × $42 ≈ $0.252

如果问题更多、criteria 更长，或者 state 接近几千 tokens，成本会线性上升。因为输出 token 免费，主要变量就是输入。这个推算只用于建立量感，正式预算请用自己的测试请求做 token 统计。

6 什么团队现在就该试：我的判断清单

适合现在试的团队：

1. 有大量重复、低延迟、可结构化判定任务，比如客户工单路由、内容安全筛选、文档类型分类。
2. 需要把不确定性作为流程门控，而不是只看最终答案。例如高风险操作自动执行前再拦一道置信度。
3. 受够了大模型自由文本输出不稳定，愿意自己写组合逻辑，把多个原子判断拼成业务决策。
4. 正在做 RAG 或检索系统，需要在召回之后加一个便宜、快速、可复现的重排层。
5. 需要审计“模型当时到底有多少把握”，因为 Jev 返回的是结构化 fields，便于记录和回查。

暂时不适合的团队：

1. 需要生成式回复、多轮对话、长文写作。Jev 不干这个。
2. 需要多模态输入，或者推理过程解释。官方明确不支持图像、音视频，也不生成解释。
3. 需要一个 Agent 框架替你调度工具和上下文。Jev 是判断层，不是 Agent 框架。

这次没核实的

• JEV 基座模型是否基于 Qwen，官方文档没有披露，我未能核实。中文社区相关说法不在此文引用，也不应作为事实转述。
• Patterns 里的 Intent routing，本次只看到官方导航标题，未读到页面正文，具体定义未能核实。
• Cookbooks 中的 Citation check、Function calling、Skill suggestion，本次只看到官方 Cookbooks 列表标题，未读到正文，具体解决的问题未能核实。
• Re-ranking cookbook 的 5%→18%、38%→62% 是官方实验数据，我没有独立复现，也不代表所有领域都会有同等提升。

参考来源

• 官方 AI primer
• 官方 System One
• 官方 Primitives
• 官方 Confidence
• 官方 Models 页
• 官方 Quick start
• 官方 cookbook: Guardrails for LLMs
• 官方 cookbook: Re-ranking
• 官方 Pattern: Speculative fan-out