Jev 的 RLCD:从“说得好”到“概率准”
先说结论
- 官方文档把 TypeSafe 的训练路径定义为 RLCD,即 “Reinforcement learning for calibrated decisions”,它的直接产出是决策和校准概率,而不是生成文本。
- RLHF 把预训练模型变成聊天机器人,RLVR 用可验证奖励训练推理模型但更慢更贵,RLCD 改的是输出契约:不生成文本,只返回决策和概率。
- 校准是有具体语义的:概率 0.2 的结果应约 20% 发生,0.8 约 80%,1.0 应 100%;但这些比率描述的是“一组预测”,不是任何单条答案的保证。
- 官方明确批评 RLHF 会奖励谄媚和自信腔调的幻觉,偏好优化还会导致 mode dropping。
- 中文技术博客所称“Jev 基于 Qwen 基座”,在本次核实的官方文档中没有任何基座模型说明,该说法属社区推测,标为未能核实。
官方把三条训练路径并排
在 AI primer 页面,官方把预训练模型的三种后训练路径并排放在一起:RLHF、RLVR、RLCD。官方给出的原句是:
- RLHF:“Reinforcement learning from human feedback turned pretrained models into chatbots. It trains models to produce responses people prefer.”
- RLVR:“Reinforcement learning with verifiable rewards created reasoning models that are strong at tasks such as mathematics, but slower and more expensive.”
- RLCD:“Reinforcement learning for calibrated decisions trains TypeSafe to return decisions and calibrated probabilities instead of generated text.”
这三句话的意思很明确:RLHF 的目标是让人更喜欢回复,RLVR 的目标是可验证奖励,常见于数学等任务;而 RLCD 根本不优化“像不像人说的话”,它优化的是决策和概率是否可靠。官方还写了一句背景:RLHF 被用于训练 InstructGPT 和 ChatGPT,并且由 TypeSafe 联合创始人 Diogo Almeida 共同发明。这是官方页面的一手信息,不是社区转述。
这里有一个容易误读的点:把 RLHF、RLVR、RLCD 摆在一起,不等于它们是同一种目标的三个版本。RLHF 和 RLVR 仍然是生成式模型的训练路径,而 RLCD 已经换掉了输出契约。官方页面标题也写得很清楚:Why TypeSafe trains decision models with calibrated probabilities instead of optimizing for generated text。
校准到底意味着什么
官方给了校准的具体语义。在 AI primer 中,原文是这样写的(官方数据):
“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.”
这句话必须写进去。它意味着校准不是对单条答案背书,而是一组预测的统计属性。即使一个模型完全校准,某个被赋予 0.8 概率的答案,也不保证它这次就对;而是说在大量概率同为 0.8 的预测里,约 80% 是对的。这个区分对实际工程很重要:你不能因为单次输出的概率是 0.8 就放心自动执行,但你可以基于一组有校准概率的决策来设计可靠的自动化流程。
官方在 Confidence 页面进一步区分了 probability 和 confidence。官方原句是:“confidence is a statistic computed from the probability distribution the answer already gives you.” 意思是 confidence 不是一个独立预测,而是从概率分布中算出来的一个 0 到 1 的汇总值。官方还写了一句:“If an intelligent system, whether human or machine, cannot express honest uncertainty, the system cannot be trusted.” 这句话解释了为什么要让模型能表达“我不知道”:如果系统不能表达不确定,它就无法被信任。
官方对 RLHF 的批评
官方没有把 RLHF 写成万能路径,而是给出明确批评。在 AI primer 中,原文是:
“RLHF teaches a model to say things that people prefer. That objective works well for chatbots, but it can also reward sycophancy and confident-sounding hallucinations.”
这句的意思是:RLHF 奖励的是“人喜欢的表达”,而不是“正确的判断”。一个谄媚、自信、但又落空的回答,可能在人类偏好模型下得分很高。官方还指出偏好优化会造成 mode dropping:“Preference optimization also causes mode dropping: the model learns to favor a particular style, such as instruction following, while reducing the probability of other possible outputs.” 这会导致模型输出风格收窄,不利于需要多样结构化判断的场景。
官方给出的结论是:人类偏好和机器可信度是两个不同的优化目标。聊天机器人可以从“说得好”中获益,但无人值守自动化需要的是“概率说得准”。这不是说 RLHF 无用,而是说它不合适 TypeSafe 想做的生产自动化。
System One 不做解释,是因为 RLCD 改了输出契约
在 System One 页面,官方写了 Jev 的定位:
“Jev is TypeSafe’s flagship model and the first System One model.”
以及:
“System One models do not write replies, produce code, or generate explanations of their reasoning.”
这解释了为什么 Jev 不生成解释:它的训练目标根本不包含生成文本。它不是“更小的 RLHF”,也不是“会说话但被压缩推理链的模型”。RLCD 的输出是结构化决策和概率分布,解释理由不在输出契约里。
这与 How to build with TypeSafe 页面里官方说的设计原则一致:System One 是给软件用的 AI 原语,代码保留控制流,模型只处理非结构化数据中的常识判断。官方原文是:“It provides AI primitives that embed into software, so code remains in control while the model handles common-sense judgments over unstructured data.” 也就是说,模型不是 agent,不自己选择下一步,也不生成代码。因此,把 RLCD 理解成“优化目标从说得好换成概率说得准”,比单纯理解成“RLHF 的轻量版”更准确。
官方还给了两组性能定位信息。System One 页面写:“Most queries complete in about 100 ms.” How to build 页面写:“TypeSafe’s target is a greater than 100× intelligence-to-speed-and-cost ratio.” 这些是官方给的设计目标或性能描述,不是本文实测数据,也无法从当前文档核验测量口径。
一个消费概率的官方示例
Confidence 文档给了一段 Python 示例,展示代码如何根据 confidence 做不同处理。官方示例原文如下:
response = client.system_one(
state=user_message,
questions={
"action": Choice(
instructions="What is the user trying to do?",
criteria={
"check_balance": "View account balance",
"approve_transfer": "Approve the pending withdrawal request",
"support": "Get help with an issue",
},
),
},
)
action = response.answers["action"]
confidence = action.confidence
if confidence < 0.5:
# Model is genuinely unsure. Don't guess.
route_to_human(user_message)
elif action.choice == "check_balance":
# Low stakes. Showing the wrong screen is recoverable.
show_balance(account_id)
elif action.choice == "approve_transfer":
if confidence > 0.9:
# High stakes, high confidence. Proceed with confirmation.
confirm_then_execute(account_id)
else:
# High stakes, moderate confidence. Verify first.
ask_user_to_confirm(account_id)
这段代码是官方 Confidence 页面给出的示例,其中 0.5 和 0.9 是示例阈值,不是官方推荐的固定值。官方随后强调:“Where you draw those boundaries depends on the stakes.” 以及 “The correct threshold values depend on your domain and the performance of the model for your use case. Start with conservative thresholds, test with your own data, and adjust as you observe results.” 因此,看这段示例时不能把 0.5/0.9 当成标准答案,它只是展示“低置信度不猜、低风险动作可自动、高风险动作要确认或升级”这种模式。
我的判断与清单
我的判断是:RLCD 不是“更小的 RLHF”,而是换了一个优化目标。RLHF 优化的是“人喜欢”,RLCD 优化的是“概率与结果一致”。这个区别解释了为什么 Jev 不生成解释:解释是生成文本,而 RLCD 的输出契约里没有生成文本这一项。
如果把 RLCD 当聊天模型用,会明显不对路;但如果要用在自动路由、审核、决策门控、结构化 JSON 输出等场景,校准概率比一段自然语言解释更可操作。
我自己的使用清单是:
- 先确认任务是否需要自然语言解释:如果需要给用户看理由,System One / RLCD 当前不直接提供,可能需要另接推理模型。
- 再确认错误代价是否可以用阈值升级来兜底:低置信度转人工、高置信度自动执行,这套门控适合中等风险场景,不适合一次错误就不可接受的场景。
- 不要把单次 high confidence 当成保证:校准是统计属性,工程上仍需监控预测组的表现。
- 阈值必须基于自己的业务数据和风险偏好做测试,示例里的 0.5/0.9 只是起始参考。
这次没核实的
- 社区称“Jev 基于 Qwen 基座”:本次核对的官方文档中没有出现任何基座模型说明,包括 architecture、init checkpoint、参数规模等。该说法属社区二手信息,官方未披露,未能核实。
- RLCD 的训练细节:官方 primer 只说明训练目标和与 RLHF/RLVR 的区别,没有给出损失函数、数据集、奖励设计、训练步数、评估基准等细节,未能核实。
- Confidence 的具体计算公式:官方 Confidence 页面只说 confidence 从概率分布计算,并提到会另出 cookbook,但当前页面没有给公式,未能核实。
- “100× intelligence-to-speed-and-cost ratio” 的具体测量方法:官方页面当作设计目标提出,但本文无法从当前文档核验其口径,未能核实。
参考来源
评论区
登录后可评论。