Jev 的爆火并非因为“读懂潜台词”的趣味截图，而是它试图用 RLCD 取代 RLHF，让大模型从“会聊天”转向“能决策”。本文用大白话拆解预训练、RLHF 到 RLCD 的演进，结合客服等场景，客观分析 Jev 的价值、局限与待验证之处。

Jev 最近因为各种“读懂潜台词”的趣味截图爆火，但它真正值得关注的，并不是会不会分析老板和对象，而是它尝试改变大模型的后训练目标。

本文将用大白话讲清从预训练、RLHF到 RLCD 的变化，同时也会从数据和实际应用出发，客观看看 Jev 的价值、局限，以及它为什么仍需更多验证。

最近，我在网上看到了两张特别有意思的图。

一张是情侣聊天。

女生问：“你今天是不是又忘了我跟你说过什么？”

图里的 Jev 没有直接帮男生回复，而是在旁边默默分析：

-她是真的在问“你记不记得”吗？不是，概率 93%

-她更可能是在确认你在不在乎她，概率 72%

-当前危险等级 9 分

另一张更好笑，是老板说：

“有个小需求，做个像淘宝一样的，简单点就行。”

Jev 给出的判断是：

-这个需求真的小吗？不是，概率 98%

-改个按钮：3%

-重写半个项目：97%

哈哈，虽然这两张图明显带着网友二创的夸张效果，但它们确实抓住了 Jev 最有意思的地方：

Jev 不急着帮你“说一句话”，而是先判断现在到底发生了什么，以及接下来应该做什么。

这和我们过去熟悉的 ChatGPT，其实是两个不同方向。

Jev不是另一个更会聊天的GPT

Jev 在 2026 年 9 月 15 日正式发布，是 TypeSafe 推出的第一款所谓“System One Model”。

它的创始人 Diogo Almeida此前在 OpenAI工作，参与过基础 RLHF 和 InstructGPT 相关工作。简单来说，我们今天能够对 ChatGPT 说“帮我写封邮件”，然后它真的老老实实写邮件，这条技术路线背后就有他的参与。2024 年，他离开 OpenAI，开始创办 TypeSafe。(typesafe.ai)

所以，Jev 并不是一个完全脱离 ChatGPT 历史的新故事。

恰恰相反，它更像是一个曾经参与创造 RLHF 的人，几年之后回过头来问：

RLHF 把模型训练得这么会聊天了，但它真的适合直接控制软件吗？

我比较关心后训练，所以我看到 Jev 时，想的是：它到底想把模型训练成什么东西？

要理解这个问题，我们得先从 RLHF （基于人类反馈的强化学习）出现之前讲起。

RLHF之前的GPT

早期的大语言模型，本质上是在做一件看起来非常简单的事：

根据前面的文字，预测下一个词。

比如给它一句：

今天天气很好，我准备去公园……

它可能继续写：

散步、跑步、晒太阳。

模型在海量文本中做了无数次这样的“文字接龙”，慢慢学会了语言、知识、表达方式，甚至一定程度上的推理能力。

但这里有一个问题。

模型学会了续写文字，不等于它学会了听你的话。

你对早期模型说：

帮我写一封请假邮件。

它未必会直接写邮件。

它可能继续生成：

帮我写一封请假邮件，是很多职场人士都会提出的需求……

听起来很奇怪，但从训练目标来看，它并没有做错。

因为它原本接受的训练就是“继续写下去”，而不是“理解用户想做什么，然后完成任务”。

OpenAI 当年也明确提到，GPT-3 的预训练目标主要是预测下一个词，而用户真正想要的是一个能够理解意图、执行指令的助手。

RLHF之后的GPT

RLHF （Reinforcement Learning From Human Feedback ）的全称是“基于人类反馈的强化学习”。

名字听起来很技术，翻译成人话，其实就是：让人类告诉模型，什么样的回答更好。

在经典的 InstructGPT 训练流程中，大致有三步。

第一步，人类先写一些示范答案。

比如用户说：

帮我写一封向领导请假的邮件。

标注人员会写一封相对得体的邮件，让模型学习“这种问题应该怎么回答”。

第二步，让模型针对同一个问题生成多个答案，再由人类进行排序。

例如：

• A 答案简洁、礼貌、信息完整
• B 答案废话很多
• C 答案语气很不合适

人类告诉模型：A 比 B 和 C 更好。

第三步，根据这些人类选择训练一个“奖励系统”，再通过强化学习，让模型越来越倾向于生成大家喜欢的答案。

OpenAI 公开的 InstructGPT 流程正是“人类示范、答案排序、奖励模型、强化学习”这条路线。

这里真正发生的变化，可以分成两层。

RLHF 在训练层做的事情，是把优化目标从“下一个词是什么”，部分转向“人类更喜欢哪个回答”。

而它在产品层带来的变化更直观：

以前，我们是在调用一个文字生成器。

后来，我们开始感觉自己在和一个助手对话。

它会按照要求修改语气，会输出指定格式，会拒绝部分危险请求，也会结合上下文继续交流。

从 InstructGPT 到 ChatGPT，真正重要的不只是模型参数变多了，而是模型终于学会了：

用户说这句话，究竟是想让我干什么。

RLHF很适合聊天但不一定适合自动化

RLHF 已经非常成功了。

今天的写作助手、聊天机器人、AI 客服、编程助手和各种 Copilot 产品，背后都离不开“让模型更符合人类意图”这条路线。

但它也有一个天然限制：人类喜欢的回答，不一定等于软件可以放心执行的判断。

举个例子。

一位电商客户说：

鞋子尺码发错了，而且我的银行卡好像还被扣了两次。我不知道应该换货还是退款。

一个聊天模型可能会回答：

很抱歉给您带来不便。根据您的描述，建议先联系售后部门处理换货，同时核实重复扣款问题……

这段话读起来很自然，也很有礼貌。

如果是人类客服在看，它没有太大问题。

但假设我们希望软件直接根据模型回答执行操作，问题就来了：

• 这个工单应该发给退换货部门，还是支付部门？
• 用户到底想退款，还是换货？
• 要不要立刻冻结支付？
• 模型有多确定？
• 信息不足时，是继续执行，还是转给人工？

一句“建议联系售后”，对人来说可能够用了，对软件来说却远远不够。

软件需要的不是一篇看起来不错的回答，而是一组可以直接执行的判断。

Jev训练层的核弹级更新——RLCD

TypeSafe 把 Jev 使用的新训练方向称为 RLCD，也就是“面向校准决策的强化学习”。

它和 RLHF 最核心的区别，不是把 H 换成了 CD，而是优化目标发生了变化。

RLHF 更关注：

哪个回答是人类更喜欢的？

RLCD 更关注：

在给定信息下，每个判断成立的概率是多少？模型知道自己有多不确定吗？

Jev 不负责生成一大段话，主要提供三类结果：

• Choice：从几个选项中选择一个
• Score：按照标准打分
• Noul：判断一个说法成立的概率

而且这些问题可以在一次请求中并行处理。TypeSafe 官方建议把复杂任务拆成多个独立的小判断，再由普通代码把判断结果组合起来。

比如刚才的客服问题，可以被拆成：

– 主要问题属于退换货还是支付？

– 是否存在重复扣款？

– 用户是否已经明确要求退款？

– 当前问题的紧急程度是多少？

– 是否需要人工客服介入？

Jev 返回的不是一篇客服回复，而可能是一组类似这样的结果：

– 退换货：61%

– 支付问题：35%

– 其他：4%

– 用户想退款：40%

– 用户想换货：34%

– 用户意图不明确：低置信度

这时候，产品就可以写出非常明确的规则：

• 判断明确时，自动分配工单
• 同时涉及支付问题时，通知支付团队
• 用户意图不明确时，不要猜，继续询问
• 涉及高风险操作时，提高自动执行门槛
• 置信度太低时，直接转人工

这就是 Jev 在应用层想做的事情：

它不直接替软件完成所有工作，而是给软件增加一批“聪明的判断条件”。

TypeSafe 自己把这种能力形容为“智能版的 if 语句”。

RLCD带来的那些百分比到底是什么？

回到开头的聊天截图。

为什么 Jev 总是在输出 72%、91%、98%？

这里涉及一个非常重要的概念，叫作“校准”。

假设一个模型处理了很多相似案例，并且给其中一批案例都打出了 80% 的概率。

如果这个模型的概率是校准的，那么在长期统计中，这批案例应该大约有 80% 判断正确。

也就是说：

– 模型说 20% 的事情，长期来看应该大约两成发生

– 模型说 80% 的事情，长期来看应该大约八成发生

– 如果模型每次都说自己 99% 确定，却经常判断错误，那它就没有被校准好

这里需要注意，80% 并不保证眼前这一次一定正确。

校准描述的是一批预测的统计规律，不是对单次结果的承诺。

它的产品价值在于，软件终于可以根据不确定性采取不同动作。

比如：

• 高置信度，自动执行
• 中等置信度，先让用户确认
• 低置信度，转给人工
• 高风险操作，即使置信度较高也要二次确认

这比单纯让模型说一句“我比较有信心”，更容易进入真实的业务流程。

回归数据训练的角度看Jev

Jev 最值得后训练从业者关注的地方，我觉得其实是数据。

传统 RLHF 的数据运营，主要围绕这些问题展开：

– 用户会向模型提出什么问题？

– 什么样的回答算好回答？

– 两个回答放在一起，人类更喜欢哪个？

– 如何让标注人员保持一致？

– 如何减少有害、虚假和不符合要求的输出？

到了 RLCD，数据团队面对的问题会发生明显变化。

TechCrunch 报道称，Almeida 表示 Jev 使用合成数据训练。不过，TypeSafe 目前并没有公开完整的训练论文、奖励设计和数据生成细节，所以我们还不能确认 RLCD 的具体技术配方。

但从它公开的训练目标倒推，数据工作至少需要解决几件事。

第一，不能只收集“正确答案”，还要收集“边界案例”。

模型不仅要学会简单题，还要见过：

• 信息不足的案例
• 多个选项都合理的案例
• 非常容易混淆的案例
• 低频但高风险的案例
• 正确做法是“不行动”的案例

否则模型可能永远表现得特别自信。

第二，选项本身会成为产品的一部分。

如果客服工单只有“退款”和“换货”两个选项，但用户只是想查询物流，模型再聪明也只能硬选一个。

所以产品团队需要认真设计：

• 选项是否覆盖完整
• 是否需要“其他”或“无法判断”
• 两个类别之间的边界是什么
• 哪些问题应该拆开判断
• 哪些判断必须交给确定性的代码

第三，数据评估要从“回答好不好”，转向“决策能不能用”。

除了准确率，还要观察：

• 模型高置信度时到底有多准
• 哪些业务类型容易过度自信
• 信息不足时能不能表现出犹豫
• 阈值设成多少可以自动执行
• 自动化覆盖率提高后，错误率增加多少
• 数据分布变化后，概率是否仍然可信

到了这一步，后训练已经不只是“把数据交给模型训练”。

它开始和业务规则、产品设计、错误成本、人工流程紧紧绑在一起。

Jev可以落到哪些真实应用

如果 RLHF 主要推动了“人与模型交流”的产品，那么 RLCD 想推动的，是“模型参与软件决策”的产品。

它可能适合下面这些场景。

1）客服工单处理

判断用户意图、情绪、紧急程度和风险，把工单发给对应团队。简单问题自动处理，模糊问题继续追问，高风险问题转人工。

2）安全事件处理

分析一条安全告警是否可能误报、影响是否严重、是否需要关闭账号。高置信度且低风险的情况自动处理，其余情况交给安全人员。

3）AI模型路由

判断一个问题究竟需要昂贵的推理模型，还是普通的小模型就能完成。这样可以在不明显降低效果的情况下控制成本。

4）Agent工具调用

Agent 想发送邮件、删除文件或执行付款之前，先判断这个动作是否符合用户授权，是否存在风险，是否需要再次确认。

5）发票和订单审核

根据合同、订单、收货记录和发票信息，判断应该付款、暂缓还是退回，并把不确定的案例交给财务人员。

TypeSafe 公布的示例工作流也主要集中在客服、安全事件、Agent 运行审核和发票处理等场景。

所以，我不太认为 Jev 是用来替代 ChatGPT 的。

更现实的组合可能是：

– 大语言模型负责理解、规划和生成内容

– Jev 这类模型负责分类、评分和路线判断

– 普通代码负责执行确定性的业务规则

– 人类负责低置信度和高风险案例

模型不需要包办一切。

有时候，一个系统可靠的原因，恰恰是每个部分只做自己擅长的事情。

最后，随笔写写

最近一些营销内容把 Jev 吹得非常夸张，甚至开始使用“零幻觉”“终结大语言模型”之类的说法。

我觉得现阶段还是要冷静。。。。

开头的两张图很有趣，但 Jev 并不会真的读心。

它只能根据输入信息和预设选项做判断。如果上下文不完整、问题设计得不好或者选项本身有缺陷，输出的概率也可能没有意义。 Jev 才刚刚发布，真正的考验并不是网上能做出多少有趣截图，而是当它被接进客服、支付、安全和 Agent 系统后，能不能在成千上万次真实判断中，持续知道自己什么时候正确，什么时候应该闭嘴，什么时候必须把问题交给人。

后训练真正要解决的问题：我们到底希望模型学会什么？

预训练让模型学会了语言。

RLHF 让模型学会了按照人的意图说话。

后来的推理训练，让模型学会解决可以验证的问题。

而 RLCD 想做的，是让模型学会：

– 给出明确判断

– 表达不确定性

– 接受软件的约束

– 在该犹豫的时候犹豫

– 把最终执行权交给代码和业务规则

其次，所谓“零幻觉”需要区分两件事。

Jev 可以保证输出符合预设结构，不会突然在“退款、换货、查询物流”之外编出一个奇怪格式。这解决的是类型和格式问题。但格式永远正确，不代表判断永远正确。

TypeSafe 在官方材料的说明中也承认，其“零幻觉”数据来自结构匹配的保证，并不是对语义正确率的实证证明。校准也不是训练一次就能在所有业务里永久有效。

官方文档同样建议开发者从保守阈值开始，使用自己的数据进行测试，再根据实际结果调整。