TypeSafe AI 放弃文本生成，把大模型变成软件里的一个类型安全函数调用：非结构化状态进，类型化概率决策出。
Jev 是旧金山 AI 实验室 TypeSafe AI 于 2026 年 9 月 15 日发布的模型，官方称其为首个「System One 模型」（System One Model）。它与 LLM 的根本区别在于：它不生成自然语言文本。你传入一段非结构化状态（state）和一组预先定义好类型的提问（typed questions），它返回结构化的答案——选中项、评级、布尔判断——每项附带校准概率（calibrated probability）与置信度（confidence），可直接被程序消费，无需解析、无需容错。
官方对它的定位一句话：「一个前沿智能的函数调用：非结构化状态进，类型化概率决策出。」（a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out）
| 现有 LLM（System 2） | Jev（System One） | |
|---|---|---|
| 训练范式 | RLHF / RLVR，优化人类偏好或可验证奖励 | RLCD（Reinforcement Learning for Calibrated Decisions），直接优化决策校准 |
| 输入 | 非结构化文本，强调顺序化消息 | 非结构化文本，强调结构化程序状态 |
| 输出 | 自由字符串；需解析+校验，有幻觉与脱轨风险 | 类型安全结构值；输出空间提前定义，类型错误在数学上不可能 |
| 采样 | 自回归，逐 token 串行生成 | 并行：所有输出单次查询同时给出 |
| 速度 | 端到端 3–329 秒 | 70–500ms，同等智能水平下快 40–200 倍 |
| 价格 | 输入 $0.20–10/MTok，输出约为输入 5 倍 | 输入 $0.042/MTok，输出免费 |
| 置信度 | 即使被要求自报置信度也普遍过度自信、前后不一 | 每次输出必附校准置信度；置信度越高，准确率越高 |
| 适用场景 | 人机协同（聊天、副驾、编码代理）、可验证问题、原型 | AI 工作流 / 智能 if 语句、大规模 map-reduce、实时应用、验证与护栏 |
Jev 的故事要从它的缔造者说起。TypeSafe AI 由 Diogo Almeida、Erik Gafni 和 Sasha Sheng 于 2024 年创立。创始人 Almeida 在 OpenAI 工作约四年，是 RLHF / InstructGPT / ChatGPT / GPT-4 背后的研究者之一——也就是说，他亲手参与造出了让模型「善于聊天」的那套方法，然后转身质疑它。
他的驱动问题（driving question）写了四年：
他的判断：RLHF 优化的是人类偏好，产出的是「人喜欢的回复」；但 RLHF 带来 mode dropping、过度自信与不可靠——这些缺陷意味着 LLM 天生需要 human-in-the-loop。TechCrunch 报道中他更直白：ChatGPT 是「瓶子里的闪电」（lightning in a bottle），惊艳但不实用。Forbes 引述：「我们一直在优化去讨好人类，而且已经超人的擅长讨好人类。」
TypeSafe 隐身研发约两年后，随 Jev 一同宣布了 DCVC 领投的 4000 万美元种子轮，估值约 2 亿美元。公司自我定位不是「更好的 LLM」，而是「机器原生智能基础设施」：为软件里的决策而生。
TypeSafe 的世界观建立在一个判断上：「为人类优化的模型」和「为软件优化的模型」是两个物种。过去四年所有前沿模型都在前一条路上狂奔——更长的推理链、更漂亮的 Markdown、更讨喜的语气。但软件需要的智能形态完全不同：它要快（毫秒级）、要可靠（不能幻觉一个函数名）、要可组合（输出能直接进 if 语句）。
这个划分并非 TypeSafe 首创，但把 Kahneman 的双系统理论变成一个商业 API 是他们的手笔。官方还顺手回答了「System 1 不是容易出错吗」的质疑：他们认为通过 RLCD 校准训练，System One 模型可以做得比替代品更可靠——这是他们未来要展开的方向。
「Jev」取自 19 世纪英国经济学家 William Stanley Jevons（杰文斯）。杰文斯悖论说：蒸汽机效率越高、煤耗越低，煤炭总消耗反而越大——因为效率提升开启了更多用途。Almeida 的预期完全同构：智能成本每下降一个数量级，解锁的用例会多几个数量级。Jev 的定价（输入 $0.042/MTok、输出免费）就是照着这个信仰定的。
LLM 的自回归解码是串行的：生成第 N 个 token 必须等第 N-1 个。Jev 的做法完全不同——既然输出空间是提前定义的封闭集合（有限的选项、有限的等级、或 0–1 概率），就不需要「生成」，只需要对每个候选答案同时打分。官方称其采样器「极其高效且硬件感知」（incredibly efficient and hardware-aware），一次查询即完成所有输出的评估。
这带来一个反直觉的工程红利：加问题几乎不增加延迟。文档原话：「每个问题并行、隔离地针对同一段状态评估，一次完成。增加问题几乎不改变响应时间。且问题彼此独立，不会产生 context-rot。」对比 LLM 的 JSON mode：多个判断要么塞进一次长生成（串行+贵+易错），要么多次调用（更贵更慢）。
整个 API 只有三种问题类型，官方称之为 AI primitives（AI 原语），类比软件原语的模块化与可组合：
从预定义集合中选一项：路由、分类、挑选。基数上限 255。
选中项 + 每项概率 + confidence按有序等级量表给状态评级：风险分级、质量打分。
等级 + 每级概率 + confidence「这个命题为真吗？」——将布尔判断压缩为一个 0–1 之间的概率数。最轻量的原语，适合做守卫条件（guard）。
noul ∈ [0,1]（无 confidence 字段）三种原语可在单次 API 调用中混用。这是「原子问题、代码组合」哲学的落点：官方建议把每个问题都拆成「一个受过训练的人扫一眼几秒内能回答」的粒度，然后把加权、组合逻辑留在你的代码里——「优先级变了，改一个系数，而不是重写 prompt」。
TypeSafe 自研的第三块拼图是训练算法 RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习）。三行对比看懂它与主流范式的区别：
| 范式 | 优化目标 | 得到什么 |
|---|---|---|
| RLHF | 人类评分员的偏好 | 讨喜、流畅、服从——以及 mode dropping 与过度自信 |
| RLVR | 可程序验证的奖励 | 数学/代码等可验证任务上的强性能，但覆盖面有限 |
| RLCD | 概率与真实结果的对齐（校准） | 说 90% 就真的约 90% 正确——把「知道自己不知道」训练进权重 |
校准是整个故事的技术枢纽。官方论点是：如果一个模型能做对某任务 95%，但不能指出那做不对的 5%，这个任务就无法被自动化。RLCD 直接把「报出的概率分布与真实结果分布的匹配度」作为优化目标，让置信度成为可被工程依赖的一等信号——你可以围绕它设计阈值：p ≥ 0.95 自动执行，0.6 ≤ p < 0.95 转人工，p < 0.6 直接放弃。
训练数据方面，官方博客 FAQ「Where does our training data come from?」的原话是：
也就是说：Jev 不用互联网爬取语料，训练数据全部为自产合成数据。结合官方 AI primer 里的训练路径图（预训练语言模型分叉出 RLHF / RLVR / RLCD 三条后训练路径），可以推断其底座仍起始于某个预训练语言模型，而 RLCD 阶段的决策-校准数据完全是自造的。架构细节、权重与论文均未公开。外界（TechCrunch 等）推测其可能基于某个开源权重的 LLM 改造——注意这是推测，非官方确认（官方 FAQ 对「Jev 只是个小号 LLM 吗」的回答是：「Jev 既不小，也不是 LLM，所以才在智能 Pareto 曲线之外」）。另外 Jev 不做客户数据微调，同一套权重服务所有账户，领域适配靠 state 与问题设计完成。
所有模型走同一端点 POST /v1/systemone，请求体的 model 字段选择模型。一次典型调用的形态（据官方文档与演示简化）：
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer ts_...
{
"model": "jev-latest",
"state": "客户张三，账号 4 年，月均消费 ¥1,200，
近 30 天登录 2 次，工单抱怨物流慢，合同下月到期。",
"questions": [
{
"id": "churn_level",
"type": "score",
"rubric": ["low", "medium", "high"],
"criteria": "评估客户流失风险等级"
},
{
"id": "right_offer",
"type": "choice",
"options": ["续费折扣", "升级会员", "暂不干预"],
"instructions": "选择挽留策略的最优选项"
},
{
"id": "is_angry",
"type": "noul",
"statement": "该客户当前情绪显著不满"
}
]
}返回（示意，突出结构而非精确字段名）：
{
"results": {
"churn_level": {
"score": "high",
"probabilities": {"low": 0.04, "medium": 0.11, "high": 0.85},
"confidence": 0.91
},
"right_offer": {
"choice": "续费折扣",
"probabilities": {"续费折扣": 0.72, "升级会员": 0.21, "暂不干预": 0.07},
"confidence": 0.88
},
"is_angry": { "noul": 0.87 }
}
}注意三个工程要点：
① 上下文预算 64k：覆盖 state + 所有问题之和；其中 state 单独上限 32k。Jev 把 state 读一次、所有问题并行评估，所以「一次塞几十个问题」是设计内的用法（官方称为 speculative fan-out 模式的基础）。
② 纯文本输入：不接受图片/音频/视频，多模态内容需先转成文本或结构化字段。Doom 演示喂的也是「游戏状态的结构化文本表示」，不是画面。
③ 限流动态调整中：当前 250,000 tokens/s、1,200 req/min，官方坦言因需求过大在动态调整、未来随 GPU 扩容趋稳；企业版可提额。
SDK 方面提供 Python（typesafe_sdk）与 JavaScript（@typesafe-ai/sdk），默认带退避重试并尊重 retry-after 头。
先看官方给出的核心数字：
首页两个最抓眼球的数字来自官方的 workflow evals（工作流评测）。方法论值得从业者细看：不设 ground-truth 分类、不允许调 harness，而是假设存在一个正确的计算图（工作流），以最大最贵的外部模型的平均（GPT-6 Astra 与 Fable 5.1 的均值）作为参考概率，衡量各模型对这个工作流决策的贴合度与开销。Jev 在该评测里「占据了近两个数量级的 Pareto 前沿」。
值得肯定的是：TypeSafe 把这些 nuance 直接写进了发布公告——这在营销普遍注水的行业里相当罕见。另一个可自行验证的点：「无类型错误」是一个可证伪声明，官方放话说「找到一个反例就能推翻」，至今（本页撰写时）未见公开反例。
换算成工程直觉：$42/Btok 意味着处理一份 2KB（约 500 token）的状态 + 20 个问题 ≈ 0.02 美分。官方 Doom 演示每秒 10 次查询、连续运行一小时成本约 $7——「比预想的低」。对比 Claude Fable 5.1，官方称输入单价低 238 倍。当然，早期价格能否长期维持仍待观察（官方称预计降不升）。
发布周最出圈的演示：Jev 玩 1993 年的 Doom。要点不在「会玩游戏」，而在决策频率——传统 LLM 一次响应 3–329 秒，根本无法支撑实时游戏循环；Jev 以约 10 QPS 的频率读取游戏状态（结构化文本，不是画面）、即时输出移动/开火决策，成本 ~$7/小时。官方坦承：非 AI 的规则 bot 可以玩得更好，但这个 demo 展示的是「对状态变化的反应式智能」与「指令遵循」——工程团队还计划开源深入教程并举办 hack 活动。
从维基百科一个页面只靠点击链接到达目标页面。每一步要在数百到上千个链接中选路——这是 Choice 原语最残酷的场景（基数上限 255，超出走两阶段：先打分后选择）。官方结果：Jev 不仅更快，且倾向于用更少的步数到达（智能更高的信号）；而 LLM 关闭推理模式后在此任务上明显变差。此 demo 还展示了「不幻觉」在高基数场景的复利价值：一次幻觉链接就意味着死路。
官方文档沉淀了几种生产级模式，都是围绕置信度做文章：
| 模式 | 做法 | 适用 |
|---|---|---|
| Speculative fan-out | 一次调用打包大量独立问题并行评估 | 特征提取、批量打标——延迟几乎不随问题数增长 |
| Confidence-gated routing | 高置信自动执行，低置信升级到人或更强模型 | 自动化流水线的安全阀 |
| Composite scoring | 多维度 Score 原子化提问，代码里加权合成 | 替代「一 Prompt 评总分」——权重可调、可解释 |
| Intent routing | Choice 在已知意图集合中分类 | 客服路由、告警分级、A/B 分流 |
| Verify / guardrail | Noul 或 Score 校验 LLM 的输出与推理链 | 给现有 LLM 流水线加护栏、检测越狱 |
任何「快 200 倍、便宜 444 倍、零幻觉」的声明都应当被审视。这一节汇总各方（含官方自认）的保留意见——对一个 early access 产品，这些比亮点更重要。
把 Jev 放回技术演进脉络看更清楚：分类头（classifier head）+ LLM 理解力 + RL 校准 + 并行推理的组合，方向上呼应了几个已有趋势——LLM-as-judge、结构化输出（Outlines/JSON mode）、投机采样、以及「小模型做路由大模型做推理」的级联架构。Jev 的独特之处是把这条路线推到极致并产品化为独立 API：专门为「判断」这个负载重新训练和优化整个模型，而不是让通用生成模型兼职。这条路能否成立，取决于「判断」作为独立市场的大小——Jevons 的名字，赌的就是这个。
| Jev 1.13（jev-1.13.0 / 别名 jev-latest） | |
|---|---|
| 端点 | POST /v1/systemone（api.typesafe.ai） |
| 原语 | Choice（基数 ≤255）/ Score / Noul，单次调用可混用 |
| 输入 | 纯文本：字符串 / JSON 对象 / 文本数组；无多模态 |
| 上下文 | 64k/请求（state ≤32k + 全部问题） |
| 价格 | $42/Btok 输入（$0.042/MTok）；输出免费 |
| 限流 | 250k tokens/s · 1,200 req/min（动态调整中，超限 429） |
| SDK | Python typesafe_sdk / JS @typesafe-ai/sdk（默认退避重试） |
| 数据 | 不用客户数据训练；企业可 ZDR |
| 微调 | 无（同一套权重服务所有账户），领域适配靠 state + 问题设计 |
最现实的架构往往是两者并存：Jev 做系统的「脊髓反射」（路由、守卫、打分），LLM 做「大脑皮层」（推理、生成）——这正是官方描述的双模型协作（Dual-Model Orchestration）图景。