不再让模型为了一个判断,先写一段答案。把“该选什么”从“该怎么写”中拆出来——这份笔记沿着是什么、怎么做、有什么不同三条主线展开。
应用延伸:Ignis 的意图识别与 scale 选择 → 赛道:三周之后的决策模型 →
9 月 21 日之后,Jev 的公开信息多了不少:官方补齐了规格和能力边界,第三方评测陆续出来,同类“决策模型”也接连发布。本轮把这些补进对应章节,绿色标记的就是这次新增的。
- 规格和边界64K / 32K 上下文、限流、中文表现,以及官方承认的 12 条短板
- 真实 SDK 写法原图的 jev.query(...) 是示意;官方是 client.system_one(state, questions)
- 第三方评测准确率普遍低于前沿 LLM;端到端只快 1.7–3.9 倍;混合用法最划算
- 校准的外部证据分类任务 ECE 0.03–0.10,打分任务 0.28;≥0.9 置信段准确率 94–96%
- 提示注入第三方测试中,一句覆盖指令把准确率从 96.5% 打到 26.5%
- 发布后的三周开放后两天暂停注册、Vercel 采用、百亿估值传闻
- 决策模型成了赛道OpenAI、Perplexity、Cloudflare、Liquid 相继跟进,接口趋同
- Ignis 落地提醒选项顺序偏差、中文表现,以及经 Cloudflare Workers AI 调用
把 AI 从聊天框,放进程序里。
第一次看到 Jev 的 side-by-side demo 时,我愣了一下。
整个 UI 里没有一个对话框。输入框左侧是一段结构化程序状态,右侧是 { refund_risk: "medium", confidence: 0.92, churn_likelihood: 1.4 } 这种判定结果,旁边挂着一行小字:每个判断 70–500 毫秒,输出 token 免费。
这是 2026 年 9 月 15 日 TypeSafe AI 上线 System One Model Jev 时放出来的 demo。它跟过去三年的「前沿大模型发布」长得完全不一样——没有写诗、没有 reasoning trace、没有 chat UI。它甚至不打算给你写一句人话。
但你再看一眼就会意识到这种「无聊」才是真正的野心:TypeSafe 把 AI 从聊天机器人,降维成了一个软件可以直接调用的概率函数。
Jev 是什么?
官方一句话定义:
Jev is a frontier model from TypeSafe AI that takes program state plus a set of typed questions and answers all of them in a single parallel pass — returning structured values with calibrated probabilities instead of generated text.
翻译:Jev 接收一段程序状态 + 一组类型化问题,在一次并行前向里把答案全算出来,返回的不是文本而是带校准概率的结构化值。
它跟 LLM 的根本差别不在「更小」或「更快」,而在输出形态。
| 维度 | 聊天 LLM(常见生成式用法) | Jev(官方定位) |
|---|---|---|
| 输出 | 生成文本;也可通过严格约束输出结构化数据 | 在指定答案空间中返回类型化判断 |
| 采样 | 常规自回归解码,逐步生成 token | 并行返回多个问题的答案与概率 |
| 延迟口径 | 原截图引用 3–329 秒,不能代表所有任务 | 官方发布口径为 70–500 ms,不是所有请求的保证 |
| 格式与正确性 | 严格结构化输出可以约束格式;不能保证语义正确 | 类型合法也不代表判断正确 |
| 不确定性 | 自然语言自报置信度,不自动等于校准概率 | 以校准概率为训练目标;Choice / Score 另带 confidence |
「System One」的命名借用了 Kahneman 的快思考 / 慢思考区分。原文所说“软件里约 80% 的判断都属快判断”是一种产品定位与业务假设,不是这里已经验证的普遍统计规律。[1]
Jev 由 Diogo Almeida 带队,他也是 OpenAI RLHF / InstructGPT 论文的共同作者。首轮 4000 万美元由 DCVC 领投。模型名取自经济学家 William Stanley Jevons——每降一个数量级的成本,解锁一个数量级的需求。TypeSafe 想走「煤变蒸汽」那条曲线。
System 1 / System 2:快判断与慢思考
这里的 System 1 / System 2 首先是理解分工的类比,不是两种固定的神经网络结构,也不是“Jev 一定很小、LLM 一定很慢”的证明。TypeSafe 明确将命名灵感指向 Kahneman 的《思考,快与慢》。[1]
看一眼,就有判断
用“认出熟人、看到红灯就停”来理解直觉式、自动化的反应。映射到软件,是分类、选路、判断是否需要重试等边界明确的小任务。
停下来,逐步想清楚
用“计算 17 × 24、写方案、权衡多种约束”来理解需要注意力的分析。映射到软件,是规划、复杂推理、写代码与生成解释。
在 AI 架构中,可以先让决策层处理原子问题,再把不确定或需要复杂推理的部分交给生成模型;代码负责权限、流程和执行。这是前后接力,不是二选一。并不是所有 Agent 都必须采用这一层,也不意味着多加一道分类就一定更快。[2][11]
你可以把它理解成一个更灵活的 if:传统代码在明确定义的规则上求值;Jev 处理规则难写清、但答案范围能限定的语义判断。答案可被代码消费,不代表模型拥有执行权限。
规格补齐了:多长、多快、哪些事做不好
9 月 21 日的版本只写到“文本输入”。现在官方模型页给出了更具体的规格,当前版本为 jev-1.13.0。[13]
| 项目 | 官方说法 | 读的时候注意 |
|---|---|---|
| 上下文 | 每次请求 64K token;其中 state 加上最长的一道问题不超过 32K | Cloudflare 等平台页面写 32,000,对应的是后一个限制;问题越多,总量越接近 64K |
| 输入 | 仅文本:字符串、JSON 对象或文本数组 | 图片、音频、视频要先在别的模块转成文字 |
| 限流 | 100K token/秒、80 请求/秒;官方说会动态调整,可能不经通知变化 | 批量回填要自己排队、退避 |
| 语言 | 以英语为主;包括中日韩在内的其他语言“能处理,但没那么好” | 中文业务要用自己的标注集测 |
| 定制 | 不用客户数据做微调或 LoRA,也不拿客户请求和响应训练 | 想按业务调优,目前只能改问题写法和候选说明 |
| 版本 | jev-latest 与 jev-preview 当前都指向 jev-1.13.0 | 上线时固定写版本号,升级前重测 |
价格不变:输入 $0.042 / MTok,输出免费。[13][22]
官方自己列出的 12 条“锯齿边界”
TypeSafe 在 jev-1.13 的 jaggedness 页面里列出了模型做不好的事。这份清单比宣传数字更值得在接入前读一遍。[17]
| 边界 | 表现 | 官方建议 |
|---|---|---|
| 1 字面理解 | 只回答你写下的问题;限定词、否定和隐含条件都按字面读 | 条件写全,边界情况写进 criteria |
| 2 算术 | 官方原话是“不是计算器” | 计算留在代码里 |
| 3 计数 | 要数的东西越多,错得越多 | 代码逐项循环、逐项提问,再由代码求和 |
| 4 数值表示 | 十六进制、RGB、二进制读不好 | 先在代码里转成有名字的类别 |
| 5 Score 插值 | 两级之间的分数不能当精确数字用 | 只拿 Score 做阈值判断 |
| 6 日期 | 把日期当文本读,排序、时长和区间判断都不可靠 | 用 Choice 抽取年月日,比较交给代码 |
| 7 绕弯与双重否定 | 多跳推理和双重否定会降低准确率 | 问题写直白,按名称指出 state 里的字段 |
| 8 无关内容 | state 里和决策无关的内容越多,越容易被带偏 | 先在代码里过滤,只发必要字段 |
| 9 对抗内容 | 不把 state 当作敌意输入,注入的指令能改变答案 | 标准写明确,上线前专门测(见 07 章安全补充) |
| 10 指令与标准冲突 | instructions 和 criteria 不一致时会混乱 | 两者对齐,不要写 true→no 这类反转 |
| 11 选项顺序 | Choice 的选项顺序会影响结果,偏向排在前面的 | 打乱顺序多问几次,看结果是否一致 |
| 12 生成 | 没有为生成文字训练,硬拼出来的文字慢且不可靠 | 抽取用正则,写文字用生成模型 |
12 条里有 5 条和数字、日期、计数有关。Jev 擅长语义判断,不擅长计算;能用代码确定的部分,先在代码里算好再问它。
为什么砍掉自回归:一次前向,算完所有答案
把自由写作换成软件可消费的结果。
同一份 state 上并行求值多个问题。
公开的是目标,不是完整训练配方。
不能由接口反推成 ModernBERT。
System One 和 System Two 的根本差异:左边是 LLM 的串行解码链,右边是 Jev 的并行扇出,落地处都汇聚成结构化决策。TypeSafe 打的根本不是参数规模战争,而是输出形态战争。
在常规逐 token 自回归解码中,下一个输出依赖已经选出的前文,所以输出越长,通常串行解码步骤越多。这里讨论的是常见实现;推测解码等优化可以让一次大模型验证接受多个 token,不能把“一 token 一次大模型前向”写成绝对定律。[7][8][15]
Jev 把这一刀砍掉。TypeSafe 自研的 parallel sampler,在一次前向里同时把整组问题的全部概率分布算出来。这意味着两件事:
一次问 1 个 Choice 和一次问 10 个 Choice,延迟几乎没差别。
模型输出空间在调用前就被 Schema 锁死(例如 { refund_risk: ["low", "medium", "high"] })。模型只在这些离散选项里分配概率,根本不存在「说人话」的路径。
TypeSafe 把这套设计哲学写得很直白:
Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.
把这句话翻译成工程语言:Jev 不是一个聊天对象,它是一个带概率返回值的远程函数。代码 await 一下,拿到的是可以直接喂给下游 if-else 的对象,不需要 regex 解析字符串。
预先限定答案空间,可以从构造上排除空间之外的值。TypeSafe 将其描述为类型安全保证。它限制的是返回结果的类型,不是判断必然正确、请求永不超时或下游操作永远安全。[1][2]
为了对比 LLM 在生产环境里的「格式抽风」有多频繁,TypeSafe 给了一张图:
原文第 5 页的说明对应这张错误率图;图片位于第 13 页。阅读版已将图文对应排列,原始顺序可在原图对照中查看。
原截图给出的对比数字是:Jev / luna / terra / sol 的结构化输出错误率为 0%,sonnet 5 为 13.2%,haiku 4.5 为 46.5%;工具调用错误率从 Jev 的 0%、opus 5 的 0.67% 到 sol 的 17.0%。这些是原图引用的特定口径,不宜推广成所有模型、所有配置的错误率。严格结构化输出配置与普通文本生成也应分开比较。[14]
为什么生成要一步一步,而判断能一起算?
1. 慢在生成时的依赖,不是 Transformer 不能并行
自回归建模把输出序列的概率拆成条件概率的连乘。这里的单位是 token,不一定等于一个汉字或一个英文单词。
生成第 t 个 token 时,要先知道前 t−1 个 token 实际选了什么。KV cache保存历史位置的键和值,避免重复计算,但不能提前知道尚未采样的未来 token。训练时目标序列已知,可以用因果掩码同时计算不同位置的预测;输入已知时的并行,和自由生成时的串行依赖并不矛盾。[7][8]
要求模型输出 {"risk":"medium"},改变的是输出格式;在常规自回归实现中,它仍然逐步生成构成这个结果的 token。严格 Schema 约束会限制合法输出,但不自动取消解码循环。[14]
2. parallel sampler 改的是问题,不是强行并行未来文字
以退款风险为例,先给出 [low, medium, high] 三个候选。决策接口关心的是候选对应的概率,不是拼写出 medium。为了理解这种范式,可以用下面的抽象示意:
“表示 → 打分 → softmax”是理解分类器的常见方式,不是 TypeSafe 公开的逐层架构图。官方确认了同一请求中各问题对同一 state 并行、隔离求值;仅凭这些描述,不能断言内部恰好使用几个分类头、何种注意力掩码,或状态物理上只编码一次。[3][6]
也要区分两种“独立”:不同问题不读取本次请求里其他问题的答案,不等于所有问题在统计上独立。一个 Choice 内部的选项概率还要共同归一化,更不能说选项完全互不相关。[3]
3. 多问题并行,不代表任意工作流都只需一次请求
若“是否退款”和“用户是否急迫”都能从已有 state 判断,可以一起问。如果必须先查明某个实体,再根据它查数据库、构造新的候选集,那么后一个判断仍需等待前一步。官方文档也明确区分了这种真实依赖。[3]
| 维度 | 常规聊天生成 | 并行决策接口 |
|---|---|---|
| 输出空间 | 开放词表上的变长序列 | 预设候选、等级或真假概率 |
| 主要依赖 | 下一个 token 依赖已生成前文 | 同批问题分别依赖提供的 state |
| 新增输出 | 通常增加串行解码步骤 | 可并行增加问题,但仍占计算、输入和输出带宽 |
| 端到端时间 | 网络 + 输入处理 + 解码 + 序列化 | 网络 + 状态求值 + 答案计算 + 序列化 |
上表是机制层面的解释,不是延迟实测。官方“加问题几乎不变慢”的描述,也不能外推成任意输入长度、问题数量与负载下的严格 O(1)。[3][8][15]
瓶颈往往是自回归生成带来的串行依赖;Jev 选择换一种输出任务,而不是证明 Transformer 天生只能串行。
RLCD:决策对错 + 置信度诚实度
聊到「为什么 Jev 的概率可信」,必须看 TypeSafe 自创的 RLCD(Reinforcement Learning for Calibrated Decisions)。
| 对象 | 主要优化或约束 | 不能自动保证 |
|---|---|---|
| RLHF | 人类对回答的偏好 | 概率校准、事实正确性与业务安全 |
| RLVR | 来自程序或环境的可验证奖励 | 任意开放任务都存在可靠验证器 |
| 经典分类器 | 任务标签与预测分布 | 新任务泛化;也并非天生不能做校准 |
| JSON / Schema 模式 | 输出语法或结构约束,属于接口与解码层 | 概率校准;这本身不是一种训练算法 |
| Jev 的 RLCD | 官方强调类型化决策与校准概率 | 每次正确;本次所查文档没有完整训练配方 |
训练目标和输出约束是不同维度,不能视为互斥的五种模型。[1][4][6][14]
RLCD 的关键不在「又多了一种对齐方法」,而在它把「模型自称多自信」变成了优化目标的一部分。TypeSafe 写得很直接:
Calibration is a group property: it does not guarantee any single answer is correct. Jev can still be wrong.
校准可以这样理解:在足够多、可比较的预测里,报出 80% 概率的一组事件,应当约有 80% 发生。这是群体性质,不是某一个答案必然正确。原截图进一步写成“RLCD 优化批次级 Brier score”,但本次查阅的官方介绍没有给出足以确认这一具体训练损失的公式。[4]
真正应该分开的,是格式约束、决策准确性、概率校准和任务泛化。严格 Schema 能约束输出;分类器也可以返回并校准概率。Jev 的产品目标是把动态问题、类型化接口与校准概率整合起来,而不是首次发明分类或置信度。[3][4][6][14]
原文用层级图对比训练范式:RLHF 顶在「人类偏好」,RLVR 顶在「可验证答案」,RLCD 单独用陶土橙描边,强调它优化的目标——「决策对不对」+「置信度诚不诚实」。
两种 RLCD:同名,不同义
两篇材料用了同一个缩写,但不是同一训练方法。学术论文的准确标题是 Reinforcement Learning from Contrastive Distillation,不是省略了词尾的 “Contrast Distillation”。作者包括 Kevin Yang、Dan Klein、Asli Celikyilmaz、Nanyun Peng 和 Yuandong Tian。[9]
| 维度 | 学术 RLCD(2023) | Jev 官方 RLCD(2026) |
|---|---|---|
| 全称 | Reinforcement Learning from Contrastive Distillation | Reinforcement Learning for Calibrated Decisions |
| 核心目标 | 减少对人工偏好标注的依赖,进行语言模型对齐 | 让类型化决策同时提供经过校准的概率 |
| 主要思路 | 对同一输入使用正向 / 反向提示生成回答对;用偏好对训练偏好模型,再做强化学习 | 官方说明决策与校准目标;未在所查文档中给出完整奖励函数、优化器和训练流程 |
| 输出与用途 | 改善遵守自然语言原则的生成模型 | 供软件调用的 Choice / Score / Noul 判断 |
| 不能推出 | 不是 Jev 的公开训练论文 | 不能借 2023 年论文补齐 Jev 未披露的实现 |
来源分别是原论文与 TypeSafe 官方训练说明。[4][9]
学术 RLCD 是“构造偏好数据并进行对齐”的方法;Jev 的 RLCD 是“校准决策”的官方训练名称。名字相同,目标与证据不能混用。
训练方向已知,训练配方不要猜成事实
可以用一个教学例子理解概率为什么要进入评价:某组 100 个案例中,事件实际发生了 80 次。一直报 p = 0.8,比一直报 p = 0.99 更符合这组数据的发生频率。二元 Brier 分数是一种常见概率误差写法:
这里 y 是 0 或 1;分数越小,平均概率误差越小。这个例子的两种常量预测分别得到 0.16 与 0.1961。这些数字是公式演示,不是 Jev 的测评或训练记录。只追求校准也不够:在类别各半的数据中始终报 0.5,可能“校准”,却几乎没有区分能力。
因此,应当分开检查:分类 / 决策准确性、概率校准程度,以及在给定自动执行阈值下的实际错误率与覆盖率。TypeSafe 披露了“面向校准决策”的目标,但不能据此补写出它必然使用 PPO、DPO、某个 Brier 奖励、某个模型规模或固定训练数据配方。[4][5]
Choice / Score / Noul:把 API 砍到三个动词
Jev 的 API 极其克制——整个 API 只有三种问题类型。
Choice
从一组选项里挑一个
最多 255 项,返回选中项、每个选项的概率,以及一个 confidence。
Score
在量表上评分
用有顺序、带描述的等级定义量表,返回位置分数及各等级概率。分数可以落在相邻等级之间。“2–10 级”描述等级数量,不等于得分固定在 2 到 10 之间。
Noul
Yes / No 的概率化版本
返回一个 0–1 概率。
Choice 的实战要点:显式塞一个 other 选项,让模型能说「这些都不对」,避免硬猜。
TypeSafe 在文档里把 Jev 形容为「a smart if-statement」——能处理自然语言输入、但输出类型安全的智能 if。一个工单来了,一通请求里同时问:
ChoiceScoreNoul三件事在 70–500 毫秒里一次性返回,延迟几乎不随问题数量增长。下游代码就能直接拿这些类型化字段做分流:
results = jev.query([
Choice("team", ["billing", "tech", "sales"],
allow_other=True),
Score("frustration", levels=[1, 10],
anchors={1: "calm", 10: "furious"}),
Noul("refund_asked")
])
if (results.team == "billing"
and results.frustration > 7
and results.refund_asked > 0.8):
auto_escalate(results)
elif results.confidence < 0.7:
route_to_human(results)原文伪代码:保留跨页示例,不是经过验证的 SDK 调用。实际响应按问题分别返回;不要假设存在整批共享的 results.confidence。下方补充真实字段关系。
原图概括了 Choice、Score、Noul 三种问题。图中的 { choice, score, noul, confidence } 可看作概念示意,不是三种答案共有的统一返回对象;具体字段见下方官方接口补充。
接口补充:概率不是一份通用 confidence
当前文档中,每个问题都有自己的答案。Choice 和 Score 的 confidence 是从各自概率分布计算的统计量;Noul 直接给“是”的概率,没有额外的 confidence 字段。[3][5]
| 类型 | 示例问题 | 返回字段 |
|---|---|---|
| Choice | 应该交给财务、技术还是销售? | choice、probabilities、confidence |
| Score | 这件事有多紧急? | score、legend、probabilities、confidence |
| Noul | 用户是否在要求退款? | noul:命题为真的概率 |
“Noul = 0.5”表示真假接近各半,不是紧急程度中等;“Noul = 0.02”则是强烈倾向于“否”,不是模型只有 2% 的把握。量表评分应选择 Score,并给每个等级清晰的描述。[3][19]
原图的 jev.query(...) 只是示意,官方写法是这样的
官方 Python SDK 包名为 typesafe-sdk,客户端从环境变量 TYPESAFE_API_KEY 读取密钥,默认模型是 jev-latest。和原图相比有三处不同:问题是按名字组织的字典;Choice 的候选写成“选项名 → 说明”;Score 的等级是从低到高排列的说明列表,不是 levels=[1, 10]。[18]
# pip install typesafe-sdk (Python 3.10+)
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient() # 读取 TYPESAFE_API_KEY,默认模型 jev-latest
response = client.system_one(
state="Hi, I've been trying to connect my Stripe account for 3 days "
"and the integration keeps failing. I'm losing sales.",
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
),
"is_urgent": Noul(
instructions="The message conveys urgency or time-sensitivity",
),
},
)
dept = response.answers["department"] # .choice / .probabilities / .confidence
level = response.answers["frustration"] # .score / .legend / .probabilities / .confidence
urgent = response.answers["is_urgent"].noul # 命题为真的概率,没有单独的 confidence代码按官方 Quick start 整理,本页没有用真实密钥运行。
HTTP 层是 POST /v1/systemone,请求体同样只有 model、state、questions 三个字段,每道题带 type(noul / choice / score)。TypeScript SDK 为 @typesafe-ai/sdk,方法名 systemOne。Vercel、Cloudflare 和几个开源实现都沿用了这个形状,见第 11 章。[20][22]
官方核心数字与真实口径
TypeSafe 的 PR 数字很漂亮,但每条都自带 caveat。
| 官方数字(原文) | 字面意思 | 真实口径(原文) |
|---|---|---|
| 70–500 ms | 端到端响应 | 自报,evals 在自家西海岸笔记本上跑 |
| $0.042 / MTok(输入) | 一次成本 | 比 Sonnet 5 / Opus 5 便宜一到两个数量级 |
| 输出免费 | 不要钱 | 官方解释:输出太便宜不值得按 token 计费 |
| 0% 结构化错误率 | 永不格式错 | 数学保证,schema 外的不存在 |
| 193.6× 更快 | 比 LLM 快两个数量级 | 4 个 workflow 自家基准的平均 |
| 444.6× 更便宜 | 比 LLM 便宜两个数量级 | vs GPT-6 Astra;原图展示 $0.06 vs Jev $0.0001 |
| ~68% workflow 准确率 | 系统级准确率 | 4 个 workflow 平均,最高 ~74%,最低 ~40% |
最值得拆开的两条:
193.6× 和 444.6× 怎么算的?
这两个数字来自 TypeSafe 自家发的 4 个 workflow 评测:用 GPT-6 Astra 和 Fable 5.1 的平均概率作为参考答案,所有模型跑同一段工作流。这意味着:
参考答案天然向 OpenAI / Anthropic 倾斜,TypeSafe 自己也承认低估了对 DeepSeek 的相对优势。
这 4 个 workflow 是自家模型能力团队写的,虽然不在训练集里,但「团队写的」本身就有偏差。
评测从西海岸笔记本跑的,不是第三方独立复现。
~68% 不是一个标量
拆开看,最高 ~74%,最低 ~40%。平均落到 68%,并不是说 Jev 在任何任务上都接近 Opus 5——这是分布的事,不是标量的事。
唯一一条「硬」声明是 0% 结构化错误率。Schema 匹配是 Jev 调用合同的一部分,schema 外的内容在输出空间里物理上不存在。TypeSafe 主动开放早期接入接受反例验证。这种「主动设置反例」的态度比「我们 0% 错误」更可信。
左栏是原文列出的数字:延迟、价格、错误率;右栏是引用时必须附带的 caveat:自报、未复现、口径出处。右边那一栏越老实,左边那一栏就越值得引用——把每个数字和它的 caveat 一起带走。
更直观的视觉证据,是 TypeSafe 自己画的帕累托图:
横轴是 cost per workflow(美元,log 尺度),纵轴是 4 个 workflow 的平均准确率。原文将 Jev 标为粉色标记,位置接近低成本一端。
原文给出的解读是:花 444 倍的成本,大约换 5 个百分点的准确率——这是「444.6×」的视觉来源,但 caveat 同样存在:参考答案是 Astra + Fable 平均,workflow 是自家写的。
整理注:第 10 页图注中“不到 0.0001 的成本,680.3 成本上才能跑到 ~73%”一带有可见排版缺失。此处只整理可读部分,未补猜缺失的公式;完整截图仍可对照查看。
性能和复现:不要把不同口径混在一起
你补充材料中的“快 20–200 倍、成本约为 1/40–1/400”,和原文的精确倍数,都应作为特定任务、对照模型、推理设置与测评条件下的口径,而不是每次请求的承诺。输入长短、问题数量、网络位置、重试与是否输出完整概率都会改变端到端结果。[1][3]
“从笔记本运行评测”不等于“模型部署在笔记本上”。客户端在本地发请求,与模型在本地离线推理,是两个不同事实。输出免费也是计费政策,不意味着输出侧计算和网络传输真的没有代价。
这部分补充的是证据边界,不替换原图中的历史数字。APUS 已对应到公开仓库,但其延迟数字仍是项目自报,不作为性能结论引用。
第三方数字出来了:便宜和快基本成立,准不准要看任务
发布时只有 TypeSafe 自家 4 个 workflow 的数字。三周后已经有几组外部测试。它们的样本、对照模型和打分方法都不一样,不能拼成一张排行榜,但方向比较一致。
| 来源(时间) | 做了什么 | 主要结果 |
|---|---|---|
| AI/ML API(9-25) | 3 个任务共 900 例,对比 Opus 5.5、GPT-6 Sol / Luna、Gemini 3.5 Flash、DeepSeek V4 Flash | 77 类意图路由:Jev 78.3%,Opus 5.5 85.7%,GPT-6 Sol 85.3%;内容审核:Jev 81.3%(F1 0.696,三者最高);回答质量评分:Spearman 0.394,低于 Opus 的 0.483 |
| Aman Kumar(9 月,BenchLM 汇总) | 4 个各 300 条的分类数据集 | 4 个里有 3 个超过 GPT-5.6 Luna;77 类银行意图失败;置信度 ≥ 0.9 时准确率 89.9–99.6% |
| jev-phishing-bench | 2,000 封合成钓鱼邮件 | 直接判定 62.6%;把 5 个 Jev 信号交给逻辑回归,在另 1,000 封上 95.0%(作者知道数据的构造方式) |
| JevBench v1.5.4(10-07) | 1,624 个判断(904 公开题 + 720 封存题),按准确、校准、速度、成本合成 | Cygnet 73.70、Winnow-12B Q8 73.23(两者统计上并列第一),Jev 1.13.0 72.13 第三;Jev 的校准子项 88.03 是三者最高 |
| eesel(9-21) | 一个消费品牌的 284 段客服对话 + 100 张工单交叉验证(数据未公开) | 分诊准确 93%;垃圾消息全部拦下、零误报 |
以上为各来源自报,本页未复现。[25][26][27][38]
可以带走的四条结论
速度优势在端到端被摊薄。AI/ML API 的测试里,服务端中位延迟 Jev 0.14 秒、LLM 0.89–2.55 秒(快 6–18 倍);算上网络,端到端是 0.83 秒对 1.41–3.21 秒,只快 1.7–3.9 倍。官方的 193.6× 是自家 workflow 的上限口径。
和贵模型比便宜很多,和便宜模型比差不多。每百万次判断 Jev 约 $47–98;Opus 5.5 约 $1,621–8,243(便宜 84–150 倍),GPT-6 Sol 约 $318–2,321(17–30 倍);对 Gemini Flash、DeepSeek Flash 这类便宜模型,成本大致相当。
准确率普遍低于前沿 LLM,类别多时差得更多。77 类意图路由比 Opus 低 7 个多百分点;回答质量评分是 Jev 排名最差的一类任务。
混合用法最划算。先让 Jev 判,低置信的再交给 LLM,在分类任务上用 Opus 38–45% 的成本拿到和 Opus 相当的准确率。06 章“前置反射弧”的设想,现在有了一组外部数字。
前置反射弧,而不是替代 Coding Agent
Jev 不是 Coding Agent 的对手,它站在 Coding Agent 的正前方。
Claude Code / Codex / OpenCode 这一类 Coding Agent 擅长长链路推理:读仓库、写代码、改 bug、跑测试。每个动作背后通常要消耗一次完整的大模型推理,几秒到几十秒。真实业务的 Agent 流水线里,真正需要这种慢思考的步骤往往不到 10%,剩下 90% 都是「这条工单给谁」「是不是退款请求」「这两段代码有没有重复」这种小判断。
Jev 给的模式是:先让 Jev 廉价、并行、高频地把这些小判断全部跑完,再把置信度高的小决策直接执行,把置信度低的少数案例推给 Coding Agent 或人工。这就是官方说的 confidence-gated routing——按错误代价设置分级阈值:
自动放行、自动路由、自动退款初审
交给 Coding Agent / 强模型复核
转人工或拒绝
每档阈值可按业务风险单独调,不需要整个系统共用一个「准确率」门槛。
原始输入(工单 / PR / 交易)
↓
Jev:路由 / 分类 / 风险分级 / 状态检查
(70–500 ms,廉价)
↓
确定性代码处理能处理的
(if / 表查询 / 数据库写入)
↓
Coding Agent / Sonnet 5 / Opus 5
处理少数复杂分支
↓
人工兜底TypeSafe 给出的官方承诺是「把昂贵的大模型调用压缩 90%+」——前面 90% 的小判断都被 Jev 用 $0.0001 一条的成本吃掉,剩下能进 Coding Agent 的,已经是被 Jev 预筛过的少数疑难。
一个有意思的官方 demo 是 register Doom——让 Jev 实时读 Doom 游戏状态数据结构、每秒做 10 次决策,算出下一步该按什么键的 AI 玩家,每小时成本约 7 美元。这件事有意思的地方不在 Doom,而在于 Jev 的输入是「结构化的程序状态」——它不读图像,只读结构化字段,Doom 状态序列化成 JSON,Jev 在 JSON 上做 System One 决策。
Jev 在 Agent 栈里的位置:第二层——陶土橙高亮的「前置反射弧」。再往上是 Claude Code / Codex / OpenCode,再往上是 Sonnet 5 / Opus 5 / Astra 兜底。右侧「把昂贵的大模型调用压缩 90%+」是这张图最重要的注释——Jev 不抢 Coding Agent 的饭碗,而是把它们从高频小决策里解放出来。
LangChain:把判断接到 Agent 的具体节点
LangChain 已有 TypeSafe 集成文档:TypeSafeClassifier 将 Jev 的判断封装成 Runnable,可与其他步骤组合;文档也列出了模型路由和工具调用风险检查的中间件。它是在 Agent 的决策节点上增加判断层,不是把 Jev 当成聊天模型替换进去。[10]
模型路由工具检查自定义节点这些集成中部分中间件明确处于实验阶段,接口可能变化。实际接入时,应以当前文档为准,不把截图里的简化 jev.query(...) 当作确定可运行的 SDK 代码。[10][18]
“高频原子判断交给决策模型”是一种待评估的系统设计,不等于“所有任务的 90% 都一定能省掉”。决策层带来的额外调用,必须与减少的复杂模型调用一起计算。
“低置信度交给大模型”,网关已经做成了配置项
本章原图画的分级路由,Vercel AI Gateway 现在做成了 decision fallbacks:请求里加一条条件,比如某道 Choice 的 confidence 低于 0.6,就自动换一个模型重跑(文档示例用的是 openai/gpt-6-astra)。响应头会写明是否触发、最终由哪个模型作答。[20][21]
const request = {
model: 'typesafe-ai/jev',
state: 'I was charged twice and cannot sign in.',
questions: {
intent: {
type: 'choice',
instructions: 'Which team should handle this?',
criteria: {
billing: 'Charges and refunds',
account: 'Sign-in and account access',
},
},
},
providerOptions: {
gateway: {
models: [
// intent 的 confidence 低于 0.6 时,用另一个模型重跑
{ model: 'openai/gpt-6-astra',
when: { question: 'intent', confidenceBelow: 0.6 } },
],
},
},
};
const result = await client.systemOne(request);有两项代价要算进去:触发回退时两段都计费;两次调用是串行的,延迟相加。另外,如果最终由语言模型作答,返回的 confidence: 0 和空的 probabilities 表示“没有这个值”,不是“置信度为零”。[20]
同一时期,Vercel 把这类模型统一改称“决策模型”(之前叫 evaluation models),AI SDK 提供 experimental_decide。LangChain 的集成包名为 langchain-typesafe,其中模型路由 ModelRouterMiddleware 和工具风险检查 AutoModeMiddleware 仍标为实验性。[10][21]
置信度即接口:把不确定性显式交给系统
Jev 最让我意外的设计不是快、不是便宜,是它把不确定性当成了一等公民。
仅通过提示词要求“给出 0–1 置信度”,不能证明该数字已经在目标业务上校准。TypeSafe 的训练目标是让概率更能反映不确定性;但这仍需在实际数据与任务分布上评估,不能理解为模型从此不会过度自信。[4][5]
现实意义是:代码可以显式利用不确定性来决定继续、复核或请求澄清。if confidence > 0.9 是路由规则,不是安全证明。阈值还应由错误代价、权限要求与实际验证结果决定。[5]
官方博客里有一个具体例子——一个安全告警的 4 阶段 workflow:
Triage Score
这条告警是不是真的未授权活动?
Disposition Noul
按 Noul 派发到 close / queue / act。
Containment 11 × Noul
跑 11 个独立 Noul 判断当前事件状态。
Playbook Choice
按 Group(Choice)挑对应的处置方案。
原文的工作流说明位于第 13 页,相应工作流截图位于第 5 页。Triage 是 Score,Disposition 是 Noul,Containment 是 11 个独立 Noul,Playbook 是 Choice——一个完整的安全告警自动化决策链,全跑在 Jev 上。底部 ACTION · Close Queue Page 和 QUESTIONS · Bool · Score · Choice 是最小可执行版本。
记录每次调用的输入版本、候选项、概率、阈值和执行结果,可以让路由规则接受审计。概率能说明“程序依据什么分支”,却不能完整解释“模型为什么这样理解”。可追溯的决策记录,不等于完整的因果解释或正确性证明。
confidence-gated routing 的三档漏斗:>0.90 直接执行 → 0.70–0.90 大模型复核 → <0.70 转人工。最底下「可审计边界:机器决定 vs 需人看」是核心信息——置信度不再是一个 UI 数字,而是一个触发不同执行路径的契约。
进一步区分:概率、confidence 与业务正确率
probabilities 是事件或选项的概率分布;confidence 则概括分布的集中程度。官方没有将它定义成一个通用于所有任务的“此答案正确率”。例如最高选项概率、分布熵和返回的 confidence,不能不加区分地直接互换。[5]
在工程上,可以先在验证集里分组检查:超过某阈值的结果中,实际有多少被业务验收;不同语言、任务类别和时间段是否保持稳定。自动执行比例是覆盖率,自动执行部分的错误率是风险,两者要一起看。这比单独展示“整体准确率 68%”更贴近是否能上线的问题。
当结果不够确定时,不必只有“转人工”一种选项:还可以补问用户、获取更多上下文、缩小候选范围,或交给更适合的模型。对高风险操作,置信度再高也不应绕过必须的人类确认或权限检查。[5][11]
校准有了第一批外部数字:分类上大体可信,打分上不行
Hacker News 的讨论里有人给过检验标准:如果 1000 个答案都报 0.9,大约 900 个应该是对的。到 10 月初,TypeSafe 仍没有公布可靠性曲线(reliability diagram)或 ECE,外部测试补上了一部分。[25][26][38]
| 任务 | ECE | 说明 |
|---|---|---|
| 内容审核 | 0.032 | 校准良好(AI/ML API) |
| 77 类意图路由 | 0.096 | 尚可(AI/ML API) |
| 回答质量评分(Score) | 0.284 | 校准差(AI/ML API) |
| 合成钓鱼邮件直接判定 | 0.154 | 单个外部研究 |
| 置信度 ≥ 0.9 的子集 | — | 分类任务准确率 94–96%(AI/ML API);另一组 4 个数据集为 89.9–99.6% |
ECE(expected calibration error)把预测按置信度分桶,比较每桶的平均置信度和实际准确率,越接近 0 越好。上面的数字说明:分类和审核任务的高置信段,可以作为自动放行阈值的候选;打分任务里 Score 的概率还不能直接当风险依据。阈值仍然要在自己的标注数据上定。
从 RLHF 联合发明人到「砍掉字符串」
Diogo Almeida 在 OpenAI 时和团队一起做了 RLHF 和 InstructGPT——也就是 ChatGPT 的学术骨架。他自己的反思很直白:
Models have been superhuman at chat for years, so where is all the automation?
他出走 OpenAI 后隐身两年,TypeSafe AI 拿到 DCVC 领投的 4000 万美元,最终交付的不是「更强的 chat」,而是「砍掉 chat」。
这件事的产业信号是:当前沿大模型的边际叙事空间正在变窄——Anthropic 在 2 万亿估值路上讲「放慢 capability」、OpenAI 在 1.2 万亿下一轮里讲 reasoning 极限、DeepSeek 把 token 价格打到地板——Jev 不是「又一匹更快的马」,而是「我们不要马车」,它直接砍掉「AI 必须会写句子」这个隐含假设。
注意时间点与对照:2026-09-12 Anthropic CEO Dario Amodei 发文呼吁放慢 frontier capability 提升;2026-09-15 TypeSafe 发布 Jev,砍掉自回归;2026-11(计划) Anthropic 推迟到 11 月 IPO。这是同一波 AI 资本叙事的两个方向——safety 资本叙事 vs System One 资本叙事。
对开发者来说,TypeSafe 这条线的真正信号是:System One 这层抽象,可能和 System Two 一样,是一个值得长期下注的方向。Jev 在做的事情,本质上是把 frontier AI 拆成两层:System Two 由 Sonnet 5 / Opus 5 / Astra 继续卷,System One 由 Jev / 未来更多 System One Model 单独成为一个赛道。
Diogo Almeida 的轨迹五个节点:OpenAI 的 RLHF + InstructGPT、ChatGPT 上线后的「chat ≠ 自动化」反思、两年隐身研发、TypeSafe 创立拿到 DCVC $40M,到 2026-09-15 公开 Jev。
最底下「从『聊得更好的模型』转向『软件能直接调用的决策器』」是这张图想传达的产业判断——这不是参数规模的又一轮军备竞赛,而是 AI 范式的一次重新分岔。
发布之后:开放、暂停注册、同行跟进
原截图停在 9 月 15 日。下面按日期补上之后的公开事件。融资和采用数字多为媒体或平台方的说法,不等于已经核实。
- 发布,仅限 waitlist
TypeSafe 出隐身,公布 DCVC 领投的 4000 万美元种子轮(Forbes 报道估值约 2 亿美元)。联合创始人除 Diogo Almeida 外还有 Erik Gafni、Sasha Sheng。
- 上架 Vercel AI Gateway
模型 ID
typesafe-ai/jev。Vercel 称 24 小时内近 13% 的付费团队用了 Jev,是网关史上采用最快的一次发布。 - 取消 waitlist
宣布对所有人开放,新账号附送 5 美元额度(各报道日期在 9-20 到 9-21 之间)。
- 反对的声音
Redis 作者 antirez 在 X 上说 Jev“也许有一些很窄的用途”,但这波热度说明很多人分不清什么重要;Simon Willison 认可决策模型的思路,同时提醒它让 ML 系统更像黑盒。
- 暂停新注册
因需求太大暂停,已有账号照常使用。9-24 的报道仍为暂停;本页没能确认之后是否重开。
- 百亿估值传闻
The Information 报道 TypeSafe 在谈超过 10 亿美元的新一轮融资,估值超过 100 亿美元,约为种子轮的 50 倍。尚未完成,公司未确认。
- 同行跟进
Liquid AI d1(9-29),Perplexity 与 Cloudflare 的决策模型(10-01),OpenAI Decisions API 公测(10-06),见第 11 章。
与聊天 LLM、BERT,有什么不同?
这里不把三者排成“祖师爷 → 进化版”的单线故事,而是比较任务形式、输出接口和训练目标。同样能给一个结果,不代表底层相同;同样用 Transformer,也不代表必须生成文本。
| 维度 | 聊天 LLM | 经典 BERT 分类用法 | Jev |
|---|---|---|---|
| 核心动作 | 按上下文生成下一 token | 编码输入,预测标签 / 分数 | 对提供的问题与答案空间返回判断 |
| 常见输出 | 自然语言、代码,也可严格结构化 | 标签、logits 或概率;本就可由代码直接读取 | Choice / Score / Noul 等类型化答案 |
| 推理形态 | 常规生成存在序列依赖 | 分类通常一次前向 | 官方强调多个问题并行求值 |
| 任务适配 | 通过提示词,或进一步训练适配 | 原始设定通常针对下游任务微调;也可扩展为多任务系统 | 调用时传入问题和标准,面向动态任务接口 |
| 校准 | 不因文字自报“90%”就自动校准 | 可用概率训练和后续校准;不是天生做不到 | 官方把校准决策作为训练方向 |
| 适合承担 | 规划、解释、开放式内容生成 | 已有明确任务与训练数据的理解、分类等任务 | 软件中的窄判断、路由、检查和评分 |
| 公开架构信息 | 取决于具体模型,不能一概而论 | 原论文公开了双向编码器与任务输出层 | 本次所查资料不足以确定层级结构、规模与骨干来源 |
BERT 列指原论文的经典分类设定,不是所有 BERT 衍生模型的能力上限;Jev 列依据官方接口与目标。[2][3][4][6][14]
BERT 早就会“一次前向,输出概率”
BERT 的经典文本分类路径,是用双向 Transformer 得到表示,取 [CLS] 对应的向量,再经过分类层获得预测。它不需要先生成一句“类别是财务”,更不存在必须解析自然语言才能得到分类结果的限制。[6]
所以,与 BERT 比较时真正值得研究的是:问题能否在调用时动态描述、跨任务效果是否足够好、概率在目标业务上是否校准,以及接口与部署成本。“直接输出概率”不是 Jev 才出现的动作。
能不能把 Jev 说成 ModernBERT 的升级版?
和 JSON 模式、严格结构化输出的区别
普通 JSON 模式、严格 Schema 约束和“概率是否可信”是三个不同问题。OpenAI 已公开严格结构化输出的约束机制,因此不宜说“只有 Jev 才能合法地输出结构化值”。Jev 更值得比较的是:它将任务直接定义成有边界的决策,而不是让通用生成模型输出一段承载答案的文本。[14]
别把创新简化成“更小的模型”或“更高级的 BERT”。更准确的研究问题是:动态问题 + 受限答案空间 + 校准目标,能否让软件里的高频判断更经济、更可控?
和 Ignis 的关联:让新 IF 帮忙选 scale
沿用你笔记中的 scale 命名,这里把它理解为 Ignis 中可选择的能力、工具或工作流。场景是:用户可能直接 @某个 scale,也可能只表达“我想做成这样”,但不知道该选哪个能力。后者的意图匹配,正适合拿来验证决策层是否有价值。
“我不知道我要哪个功能,也不知道它能有多好,但我就是想这么做——你看看哪个 scale 更适合我。”
显式选择走规则,模糊意图再交给模型
用户已经明确 @scale 且名称有效、权限允许时,没有必要再让模型猜一次。前端把选择写入结构化字段即可。真正需要语义判断的是未指定能力、描述含糊、多个能力重叠等情况。模型不应无故覆盖用户的明确选择。
| 场景 | 处理设想 | 为什么这样分工 |
|---|---|---|
| 明确 @ 某个 scale | 代码验证存在性、输入条件与权限,再绑定 | 能精确判断的事情交给确定性代码 |
| 只表达目标,不知道功能名 | 给出候选能力说明,让 Choice 选择,同时检测是否都不适合 | 将开放意图转为受限候选上的判断 |
| 需求信息不足 | Noul 检查是否缺少关键条件,优先向用户澄清 | 不把“候选里最像”误当作“已经足够适合” |
| 需要创意方案或复杂编排 | 由生成模型产生方案 / 候选,决策层做局部判断 | Jev 不负责生成创意、提示词或长篇计划 |
把“选哪个”和“是否适合”拆成两道题
Choice 比较的是当前候选里的相对选择;Noul 可以检查某个候选是否绝对满足条件,允许所有候选都不适合。官方能力边界文档也强调了这个区别。对于 Ignis,可保留 other / needs_clarification,避免在错误的候选集合里强行挑一个。[17]
用户需求 + 显式 @scale + 当前任务状态
↓
代码:先校验明确选择、可用能力与权限
↓
尚需判断时:提供候选能力的名称、说明和输入要求
↓
并行提问:
Choice → 哪个 scale 最匹配?
Noul → 是否缺少必要信息?是否存在适合的候选?
Score → 各候选的适配程度(需要排序时)
↓
代码:选择 / 提问澄清 / 交给规划模型 / 请求人工确认
↓
实际执行工具,并记录执行反馈当候选很多时,可以先筛出相关能力,再用完整说明复核。TypeSafe 的 Skill suggestion 示例采用“初筛候选,再读取更完整信息判断”的两阶段方式,可以作为参考;这不代表 Ignis 已采用该实现。[16]
输入什么,比把什么都塞进去更重要
建议给 state 明确命名的字段:用户的原始意图、明确选择、当前任务摘要、可用能力及其说明、相关输入条件。将系统规则与用户内容分开;权限由服务端核查,不能让用户文本中的“忽略权限”改变允许的能力集合。
对图片 / 视频制作任务,决策层可先利用任务文字、资产元数据或经过其他模块取得的文本描述。不要直接把“能为图片工作流做选择”说成“Jev 能看图或生成图”。现有文档限定文本输入。[12]
在 Ignis 里应该验证什么?
对同一批真实需求,对比“现有路由”与“增加决策层”后的正确选择率、澄清率、自动执行覆盖率、错误调用率、端到端延迟与总费用。中文需求、含糊表达、没有合适能力、以及权限不足的情况应分别统计;官方也提示非英语内容需要在自己的数据上评估。[13]
在 Ignis 中,Jev 的候选位置是“帮用户选能力”的判断层,不是生成图片、视频或创意的那一层。先证明这个小判断值得拆出来,再决定是否接入。
新信息对“让新 IF 选 scale”意味着什么
Ignis 的 scale 选择正好踩在几条已知边界上,验证方案里要专门覆盖:[17][13][29]
| 已知问题 | 在 scale 选择里的表现 | 建议做法 |
|---|---|---|
| 选项顺序偏差(官方第 11 条) | 候选列表里排在前面的 scale 更容易被选中 | 同一需求打乱候选顺序问 2–3 次;结果不一致就当低置信,走澄清 |
| 无关内容干扰(第 8 条) | 把所有 scale 说明和整段对话都塞进 state,准确率会下降 | 先用关键词或向量召回缩小到少量候选,只传必要字段 |
| 字面理解(第 1 条) | “做个像 XX 那样的视频”这类隐含意图,容易被按字面处理 | scale 说明写清适用条件和反例;保留 needs_clarification |
| 中文表现(模型页) | 官方明确说中日韩“能处理,但没那么好” | 用 Ignis 的真实中文需求建标注集;同一份数据并行试 Clef 或 pplx-decider |
| 提示注入(07 章补充) | 用户文本可能改变判断 | 权限和可用能力集合由服务端核查,模型只在允许的集合里选 |
调用权限怎么拿
TypeSafe 的新注册在 9-22 暂停了。公司已经有 Cloudflare 账号,Workers AI 的模型目录里列有 typesafe/jev(标注 32,000 上下文、零数据保留,价格与官方相同),Worker 里通过 AI 绑定就能调用;Vercel AI Gateway 是另一条路。下面的写法参照 Cloudflare 文档,本页没有实测。[22][20]
// Cloudflare Worker 内,经 Workers AI 绑定调用(示意)
const res = await env.AI.run('typesafe/jev', {
state: { request: userText, explicit_scale: null, candidates },
questions: {
scale: {
type: 'choice',
instructions: 'Which scale best fits what the user wants to make?',
criteria: {
scale_a: '…', // 每个候选 scale:名称 → 适用条件说明
scale_b: '…',
other: 'None of the listed scales fits',
},
},
needs_clarification: {
type: 'noul',
instructions: 'Key information is missing to pick a scale',
},
},
});示例里的 scale 名称是占位,不对应 Ignis 现有能力。Clef、pplx-decider 等模型的接口与 Jev 兼容,建议把这一层写成可替换的适配器,用同一份中文标注集比较几家的选择准确率、澄清率和成本。
三周之后:“决策模型”成了一个赛道
9 月 21 日写这份笔记时,Jev 还是唯一这么做的前沿模型。三周后,OpenAI、Perplexity、Cloudflare、Liquid AI 都发布了同类产品,开源社区的复现在公开基准上也追平了 Jev。Vercel AI Gateway 把它们单列为一种模态,叫 Decision(决策模型)。[21][28]
| 模型 | 发布方 · 时间 | 权重 | 价格(输入) | 值得注意 |
|---|---|---|---|---|
| Jev 1.13.0 | TypeSafe · 09-15 | 闭源,仅托管 API | $0.042 / MTok,输出免费 | 64K / 32K 上下文,仅文本;新注册暂停中 |
| Decisions API(gpt-6-luna) | OpenAI · 10-06 公测 | 闭源 | $0.10 / MTok,输出免费 | 问题类型叫 predicate / choice / score;官方称比 Responses API 快约 10 倍;目前只支持 gpt-6-luna |
| pplx-decider-v1-27b | Perplexity · 10-01 | 开放,Apache-2.0(基于 Qwen3.8-27B) | $0.04 / MTok,输出免费 | 262K 上下文,可接受图片;Perplexity 自测 11 项面板 85.71% 对 Jev 84.51% |
| Clef / Clef-flash | Cloudflare · 10-01 | 开放,Apache-2.0(Qwen 27B / 9B 基座) | 在 Workers AI 上提供 | 兼容 Jev API,64K 上下文,支持视觉;Cloudflare 自测 BANKING77 macro-F1 94.20 对 Jev 79.74,中位延迟 209 / 39 ms 对 524 ms;另有 RL 微调合作 |
| d1 | Liquid AI · 09-29 | 各来源说法不一 | 有免费档,正式价格未公布 | 声称在 Hugging Face 的 Decision Index 上超过 Jev,且多语言和抗注入更好;方法与准确率未公开 |
| Laya | Convai Innovations · 9 月底 | — | Vercel 上 10-31 前免费 | 可走 TypeSafe 兼容接口 |
| 社区复现 | 多个作者 | 开放 | 自托管 | Cygnet、Winnow-12B(Gemma-4-12B 微调,Q8 能放进 16GB 显卡)在 JevBench 综合分上略高于 Jev;PostHog Jeeves 先推理再判断;local-jev 用小模型兼容 /v1/systemone |
发布方自测的数字没有经过独立复现。[13][22][23][24][27][28][31][32][33][34][39]
三个变化
1. 接口在趋同,护城河在转移
三类问题(OpenAI 把 Noul 叫 predicate)、state + questions 的请求体、每道题各自返回概率,这套形状已经被 Vercel、Cloudflare、OpenRouter 和开源实现直接沿用;Cloudflare 的 Clef 改一下 endpoint 和模型名就能替换 Jev。接口不再是 TypeSafe 独有的东西,竞争转到了准确率、校准质量、多语言、上下文长度和价格上。
2. 价格已经贴地
三家托管服务的输入价都在每百万 token 0.04–0.10 美元,输出都免费。Jev 当初的价格优势是相对聊天模型说的;在决策模型之间,价格已经拉不开差距。
3. 开放权重让“本地跑”变得可行
Perplexity 和 Cloudflare 都放出了 Apache-2.0 权重,Winnow-12B 量化后一张 16GB 显卡就能放下。9-21 版里“APUS 在笔记本上跑类似范式”还只是线索,现在已经有好几个能自托管、按同一接口调用的选择。代价是要自己运维,校准也要自己验证。
Jev 证明了“决策模型”这种形态有人要;三周后它已经是一个赛道。接入时按接口写代码,让模型保持可替换。
参考资料与核验范围
第一轮补充(参考资料 1–19)的核对日期:2026-09-21;10·08 补充(参考资料 20–40)的核对日期:2026-10-08。正文可离线阅读;下列链接用于查阅外部资料。原截图里的商业叙事与全部历史数字并未逐项重做验证。
产品定位、parallel sampler、RLCD 命名与发布评测的限制。
类型化决策、文本输入边界,以及校准不是单次正确性保证。
多问题并行、返回字段、问题之间的依赖与两次请求的边界。
官方对 RLCD 目标的说明;不是完整训练算法或损失函数披露。
confidence 来自概率分布的统计量;Noul 没有单独的 confidence。
双向 Transformer 编码器、[CLS] 分类表示及按任务微调的原始设定。
Transformer 与序列建模、自回归生成和并行计算的基础。
KV cache 复用历史键值,避免重复计算;不预知未来 token。
同名 RLCD 的原论文:对比提示产生偏好对,再训练偏好模型并做强化学习。
TypeSafeClassifier、Runnable,以及模型路由和工具风险中间件。
将请求分派到确定性代码、专用模型或人工处理。
文本、JSON 与状态组织方式;多媒体文件不是直接输入。
模型版本与语言适用边界;中文业务应单独评估。10-08 核对时已列出 64K / 32K 上下文、限流与别名。
JSON 模式与严格 Schema 约束的区别;类型安全并非决策模型独占。
推测解码说明“一 token 一轮大模型前向”不是所有推理实现的绝对规律。
能力推荐的两阶段例子;可作为 Ignis 意图路由的参考,不是 Ignis 实现证明。
官方记录的能力边界;包括 Choice 与 Noul 的区别、复杂任务与文本生成限制。
核对 SDK 调用与请求、响应的真实形状。
评分等级与浮点得分;等级数量不等于输出最小值和最大值。
TypeSafe 兼容接口、TypeScript SDK 写法与 decision fallbacks 的计费和响应头。
Decision 模态、AI SDK experimental_decide、evaluation → decision 改名、OpenAI 兼容接口。
Workers AI 模型 ID typesafe/jev、32,000 上下文、零数据保留与 env.AI.run 示例。
开源决策模型 Clef / Clef-flash,兼容 Jev API;与 Jev 的对比为 Cloudflare 自测。
公测中,仅支持 gpt-6-luna;predicate / choice / score 三类问题,输入 $0.10 / MTok。
3 任务 900 例,对比 Opus 5.5、GPT-6 Sol 等;含服务端 / 端到端延迟拆分与 ECE。
汇总 Aman Kumar 4×300 分类测试与 jev-phishing-bench 等外部测试。
v1.5.4(10-07),1,624 个判断(904 公开 + 720 封存),按准确、校准、速度、成本合成。
决策模型目录:开放 / 托管、基座模型与 JevBench 分数。
提示注入测试数字、数据保留与托管区域、纵深防御建议。
本地 Qwen3.5 单 token logits 打分,复现决策范式;MIT;延迟为项目自报。
兼容 /v1/systemone 的本地服务,研究项目;附 JevBench 公开题对比。
10-01 Decisions API 与 Apache-2.0 权重;Perplexity 自测面板 85.71% 对 84.51%。
9-29 发布;价格、准确率与评测方法未公开。
Convai Innovations 的 Laya,10-31 前免费,可走 TypeSafe 兼容接口。
访问时间线:9-15 waitlist → 9-20 开放 → 9-22 暂停注册。
Vercel 称 24 小时内近 13% 付费团队使用 Jev。
9-24 报道:洽谈超过 10 亿美元融资、估值超过 100 亿美元,未完成、未确认。
客服场景试用数字(数据未公开);指出校准尚未被独立验证。
先推理再判断的开源决策模型;按仓库自报数字解读准确率与延迟的取舍。
社区反应汇总:antirez、Simon Willison 等的评论。
让判断回到判断,
让代码掌握执行。