Jev：当 AI 不再生成文本，而是做决策

2026 年 9 月 15 日，TypeSafe AI 发布了 Jev——一个不生成文本、只做类型化决策的模型。它的创始人是 ChatGPT 的联合发明人，他说"ChatGPT 时代是一个奇怪的弯路"。

一、一个 ChatGPT 创始人的"背叛"

Diogo Almeida 坦言："ChatGPT 伤了我的心。"

他是 OpenAI 后训练团队的核心成员，参与了 GPT-4、ChatGPT 和 InstructGPT 的开发，RLHF（从人类反馈中强化学习）的联合发明者。可以说，现代对话式 AI 的整套范式，他都是亲历者。

但他在 TechCrunch 的采访中说了一句让人意外的话：ChatGPT 时代是一个"weird detour"（奇怪的弯路）——整个行业偏离了 AI 最初应有的方向。

2024 年，Almeida 离开 OpenAI，创办了 TypeSafe AI，总部旧金山。2026 年 9 月 15 日，他们发布了第一个公开模型——Jev。

Jev 不是 LLM。它不生成文本。它是一种全新类别的 AI 模型，TypeSafe AI 称之为 System One Model。

二、问题：LLM 在做什么不该做的事

路由的荒谬

假设你有一个客服 Agent，用户发来一条消息："我要退款。"

当前的做法是：

# 用 GPT-4 做意图识别
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{
        "role": "system",
        "content": "你是一个意图分类器。根据用户消息，判断意图类别。"
    }, {
        "role": "user",
        "content": "我要退款"
    }]
)
# response.choices[0].message.content = "意图：退款请求\n置信度：高"
# 然后你用正则从文本中提取出 "退款请求" ...

这个调用消耗了 2-4 秒、约 $0.01-0.05，GPT-4o 做了"生成文本→文本被截断→你用正则解析"这一整套荒诞的操作。它本质上只是在做一个 if/else 判断，却动用了整个互联网上最大的文本生成引擎。

这不是优化问题，是架构错误。

数据

2026 年的真实场景中，LLM 路由/分类的成本和延迟已经成为生产瓶颈：

• 路由延迟：每次 2-4 秒，在高并发场景下不可接受
• 路由成本：$0.01-0.05/次，日均百万次路由 = $10K-50K/月
• 结构化输出错误率：Claude Haiku 4.5 高达 45.5%，GPT-5.6 Sol 17.0%（TypeSafe 官方数据）
• 幻觉风险：LLM 可能返回不存在的工具名或分类

TrueFoundry 在 2026 年 6 月的分析指出，企业级应用中模型路由已经成为成本和质量的核心博弈点：便宜模型（Claude Haiku 4.5 ~$1/M token）和前沿模型（~$10-15/M token）之间有 5-15 倍的价格差。

三、Jev 的回答：System One Model

TypeSafe AI 的解法是：不要让 LLM 做决策，让一个专门的模型来做。

什么是 System One Model

这个名字来自 Kahneman 的《思考，快与慢》：

Jev 的核心特性：

1. 不生成文本。它接收程序状态（state）和一组类型化问题（questions），在一次前向传播中并行回答所有问题
2. 输出是结构化的。Choice（选择）、Score（打分）、Noul（布尔）三种原语，直接返回 Python 值
3. 输出有校准的置信度。不是"我觉得是 A"，而是"A 的概率是 0.87，B 是 0.11，C 是 0.02"
4. 输出 token 免费。因为没有 decode 循环（不自回归生成），输出不按 token 计费

API 示例

from typesafe_sdk import TypeSafeClient, choice, score, noul

client = TypeSafeClient()

response = client.system_one(
    state={
        "user_message": "我连续三天打不开 Stripe，急死了",
        "customer_tier": "enterprise",
        "account_age_months": 24,
    },
    questions={
        "department": choice(
            "哪个部门处理这条工单",
            {
                "billing": "支付、订阅、账单相关问题",
                "technical": "Bug、集成、API 问题",
                "sales": "定价、升级、账户咨询",
                "retention": "客户流失风险、挽留",
            }
        ),
        "frustration_level": score(
            "用户愤怒程度",
            ["冷静陈述事实", "不满但克制", "明显不满", "非常愤怒"],
        ),
        "is_urgent": noul("用户表达了紧迫性或业务影响"),
        "escalate_to_human": noul("需要人工介入而非自动处理"),
    },
)

# 直接获取结构化结果，无需解析文本
dept = response.answers["department"].choice          # "technical"
frustration = response.answers["frustration_level"].score  # 1.35
urgent = response.answers["is_urgent"].noul              # True
escalate = response.answers["escalate_to_human"].noul    # True
confidence = response.answers["department"].confidence    # 0.596

# 置信度驱动的自动化
if confidence >= 0.85:
    auto_assign(dept)
elif confidence >= 0.5:
    suggest_to_human([dept, ...])
else:
    fallback_to_llm(user_message)

关键差异：并行 vs 串行

传统 LLM 处理上面的请求，需要生成一段包含所有判断的文本，或者分 4 次调用。Jev 一次性并行回答所有问题，延迟不随问题数量线性增长。

这在需要同时判断"分类 + 紧急度 + 是否需要人工 + 安全风险"的场景中，优势非常明显。

四、训练方法：RLCD

三种训练范式

什么是"校准"

"校准"是一个严格的统计概念，不是模糊的"准确"。

如果 Jev 在 1000 个它说"80% 置信度"的判断中，有约 800 个是正确的，那它就是校准的。这是气象预报领域的标准评估方式——如果天气预报说"80% 概率下雨"，那么在所有预报 80% 概率下雨的日子里，确实应该有约 80% 下雨。

TypeSafe 的创新在于：把模型训练目标从"生成正确答案"转向"准确表达不确定性"。 一个知道自己不确定的模型，比一个盲目自信的模型更有用——因为你的代码可以设阈值、做 fallback。

⚠️ RLCD 的信任成本

截至目前（2026 年 9 月 20 日），TypeSafe 尚未发表正式论文。

这包括：
- RLCD 的损失函数设计
- Reward model 的构造方法
- 校准的具体实现（温度缩放？ECE 最小化？）
- 训练数据的规模和来源
- 与 DPO、RLHF 的具体对比实验

Diogo Almeida 在 AI Engineer World's Fair 2026 上做了演讲"What's Next After RLHF?"，但内容更多是方向性的，技术细节不充分。

这是使用 Jev 时最大的 trust gap。你需要信任 TypeSafe 的声称，因为目前没有第三方可审计的证据。

五、基准评测：到底准不准

TypeSafe 官方评测

TypeSafe 发布了一个包含 4 个工作流、711 个 case 的对比测试。所有模型使用相同的代码工作流，准确率通过与 GPT-6 Astra + Fable 5.1 的平均预测对比来衡量。

第三方独立测试

Every（独立科技媒体）
- 任务：文档信息提取
- 结果：Jev 25x faster, 580x cheaper than Claude Fable 5.1
- 延迟：0.35s vs 8.83s per passage

LangChain（官方合作评测）
- 任务：将 Jev 作为 agent evaluator（替代 LLM-as-judge）
- 结论：可用于构建更紧密的 agent 开发反馈循环
- 有 GitHub 仓库可复现

MindStudio（独立实测）
- Prompt injection 防御：在伪造指令的攻击下，Jev 成功守住分类（退款概率 3%，未被干扰）
- 信息提取：从包含新旧两个地址的邮件中，正确提取新地址
- 局限：如果候选列表里没有正确答案，Jev 无法发明

⚠️ 评测的五个关键 Caveat

1. 准确率 ≠ 正确性：67.8% 是与 GPT-5.6 等模型预测的一致性，不是与人类 ground truth 的对比。你不知道"标准答案"本身对不对
2. Vendor bias：workflow 由 TypeSafe 自己的团队编写，他们自己也承认"this setup leans toward OpenAI and Anthropic"
3. 没有大规模独立复现：截至发稿，没有第三方在生产环境中的完整复现报告
4. 评测集规模：711 个 case 在 ML 评测中算很小的规模
5. RLCD 无论文：训练方法不可审计，"校准"声称需要独立验证

六、竞争格局：Jev 不是唯一选择

Jev 的定位不是"更好的 LLM"，而是"更好的路由器"。在这个赛道上，它有几类竞争对手：

6.1 小模型蒸馏路由

用蒸馏后的小模型（GPT-4o-mini、Claude Haiku、SmolLM3-3B）做分类，比 Jev 更透明：

6.2 基于 Embedding 的路由

把用户输入编码为向量，与预定义分类的参考向量做相似度匹配：

# 伪代码
embedding = get_embedding(user_input)
similarities = [cosine_sim(embedding, ref) for ref in category_embeddings]
category = categories[argmax(similarities)]

优势：无 API 调用、可本地部署、完全确定性。劣势：需要维护 embedding 模型、语义理解不如生成式模型。

6.3 LLM 路由网关

TrueFoundry、Braintrust、OpenRouter（被 Stripe 以 $7.5-8B 收购）等提供模型路由网关：

• 基于请求复杂度自动选择模型
• 支持 A/B 测试和质量评估
• 成本可视化和预算控制

Jev 的差异化

Jev 的独特之处在于：它不是"用 LLM 做路由"，而是"用一个完全不同的模型做路由"。这在理论上更干净——路由器不需要知道如何生成文本，只需要知道如何做决策。

七、在 1000 个 Skill 中的实战方案

问题

当 Agent 系统拥有 1000 个 skill 时，每次用户请求都需要回答："这个请求应该用哪个 skill？"

当前方案（LLM 路由）：
- 每次 2-4s + $0.01-0.05
- 日均百万次路由 = $10K-50K/月
- 存在幻觉风险（返回不存在的 skill 名）

方案：两层 Jev 路由

由于 Jev 单次 Choice 最多 255 个选项，1000 个 skill 需要分层：

用户请求
  │
  ▼
┌──────────────────────────┐
│ Level 1: 大类分类（~20类） │  ← 150-300ms, $0.0002
│ "data" / "code" / "file"  │
│ / "web" / "system" / ...  │
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│ Level 2: 子类精选         │  ← 150-300ms, $0.0002
│ 在选定大类内匹配具体 skill │
│ (~30-80 个候选)           │
└──────────┬───────────────┘
           │
      ┌────┴────┐
      │ ≥ 0.85? │
      └────┬────┘
           │
  ┌────────┼────────┐
  │ Yes    │ Medium │ < 0.5
  ▼        ▼        ▼
直接执行  LLM候选   LLM全量
  │        │        │
  ▼        ▼        ▼
结果     结果      结果

大类定义

CATEGORIES = {
    "code":         "编程、代码生成、调试、脚本执行、Git 操作",
    "data":         "数据查询、报表、分析、Excel/CSV 处理",
    "file":         "文件读写、文档处理、PDF/Word/PPT",
    "web":          "网页浏览、搜索、抓取、URL 访问",
    "system":       "系统管理、进程、磁盘、网络、SSH",
    "communication":"邮件、消息、通知、飞书/钉钉/Slack",
    "media":        "图片、视频、音频处理、截图",
    "agent":        "多 Agent 协作、子任务派发",
    "schedule":     "定时任务、日程管理、cron",
    "memory":       "知识管理、搜索、笔记、recall",
    "deploy":       "部署、Docker、CI/CD、K8s",
    "security":     "安全扫描、权限管理、审计",
    "ai":           "模型调用、embedding、推理",
    "integration":  "第三方 API 集成",
    "utility":      "格式化、转换、计算、杂项",
}

Level 1 路由

response = client.system_one(
    state={"user_message": user_input},
    questions={
        "category": choice(
            "用户意图属于哪个大类",
            {cat_id: cat_desc for cat_id, cat_desc in CATEGORIES.items()},
        ),
        "explicit_tool": noul(
            "用户明确指定了要使用的工具或技能名称"
        ),
    },
)

category = response.answers["category"].choice
confidence = response.answers["category"].confidence

# 如果用户直接说了工具名，跳过 Level 2
if response.answers["explicit_tool"].noul:
    exact_match = find_exact_match(user_input, all_skills)
    if exact_match:
        return RouteResult(skill=exact_match, confidence=1.0, path="exact")

Level 2 路由

# 获取该大类下的所有 skill
skills_in_category = [s for s in all_skills if s.category == category]
# 通常 30-80 个，在 255 限制内

response = client.system_one(
    state={
        "user_message": user_input,
        "category": category,
    },
    questions={
        "skill": choice(
            "最适合处理这个请求的技能",
            {s.name: s.description[:100] for s in skills_in_category},
        ),
        "urgency": score(
            "用户请求的紧急程度",
            ["不紧急，可以慢慢来", "一般", "比较紧急", "非常紧急"],
        ),
    },
)

skill_result = response.answers["skill"]

if skill_result.confidence >= 0.85:
    return RouteResult(
        skill=skill_result.choice,
        confidence=skill_result.confidence,
        path="jev_direct",
    )
elif skill_result.confidence >= 0.5:
    top3 = sorted(
        skill_result.probabilities.items(),
        key=lambda x: x[1], reverse=True,
    )[:3]
    return RouteResult(
        candidates=[t[0] for t in top3],
        confidence=skill_result.confidence,
        path="jev_candidates",
    )
else:
    return RouteResult(
        confidence=skill_result.confidence,
        path="llm_fallback",
    )

预期收益

八、诚实的结论

Jev 解决了什么

1. 速度和成本：毫秒级决策、微美分级成本，第三方测试验证了方向
2. 置信度校准：在自动化场景中，"知道自己不确定"比"猜一个答案"有价值得多
3. 零幻觉：不生成自由文本 = 不会编造工具名/分类/数值
4. 并行推理：一次调用回答多个问题，延迟不随问题数线性增长

Jev 没有解决的

1. RLCD 无法审计：没有论文、没有开源实现、训练细节不公开
2. 基准有 bias：准确率是对其他模型预测的一致性，不是 ground truth
3. >255 选项退化：实测超过 ~100 选项时效果开始下降
4. 无可解释性：只给数字不给理由，合规场景不适用
5. 托管 API：不能本地部署，依赖 TypeSafe 服务
6. Waitlist：目前需要申请 API key

务实的建议

• 在非关键路径上做 PoC：用 Jev 做路由的前端过滤层，低置信度时 fallback 到 LLM
• 用置信度阈值做安全网：confidence >= 0.85 自动执行，< 0.85 升级到 LLM
• 关注 RLCD 论文：一旦论文发表，可以评估是否值得自训练一个类似模型
• 同时评估替代方案：小模型蒸馏、embedding 路由、结构化输出 + JSON schema 都是可选项

一句话总结

Jev 不是 LLM 的替代品，是 LLM 的前置过滤层。它擅长的是"快速、便宜、可信赖的分类决策"，把需要创造力和推理的工作留给 LLM。但它的训练方法不可审计，这是目前最大的信任成本。

Diogo Almeida 说："当智能的成本下降，它的使用量应该上升。" Jev 的名字来自经济学家 Jevons 悖论——煤炭效率的提升反而导致了煤炭消费的增加。

如果 RLCD 的声称成立，Jev 可能让 AI 决策的边际成本降到几乎为零。但"如果声称成立"这五个字，才是关键。

本文基于 2026 年 9 月 15-20 日的公开资料整理。TypeSafe AI 的 Jev 仍处于 early access 阶段，定价和功能可能变化。所有基准数据除特别标注外均为 TypeSafe 官方报告（vendor-reported）。