RLCD 解读：为什么 TypeSafe 训练 Jev 对自信保持诚实，而不是追求被喜欢

Jev 1.13（typesafe/jev-1.13）的训练方法，被其开发方称为"校准决策强化学习"——RLCD——而这个缩略语是 TypeSafe 自创的说法，并非你本应早已熟知的行业术语。发布帖中对此直言不讳：该公司打造了"一种全新的模型架构、一个可实现最高效率的并行采样器，以及一种我们称之为校准决策强化学习（RLCD）的训练方法"。对于一个过去只有两种答案的问题而言，这是第三种答案，而它之所以存在，是因为大多数团队第一次尝试把语言模型放进某项决策时都会遇到的一种错配。在谈到这一点之前，有两个日期很重要，因为本页并非一篇发布稿。TypeSafe 自己是在 2026-09-15 发布该模型的，这落在此博客所覆盖的七天窗口之外，因此这里任何内容都不应被解读为把 Jev 当作新东西来宣传。那个有明确日期的事件是 2026-09-24，当天 OrcaRouter 将 typesafe/jev-1.13 加入了它自己的目录，并为它开放了模型卡——这是 Jev 首次可以通过第三方网关调用，而不再只能经由 TypeSafe 自己的端点。这正是本页所依托的变化，其实际意义在于：下面这项技术如今已是你用自己可能早已持有的密钥就能在代码中尝试的东西，而不再只是你读到的一个研究构想。

接下来讲的是概念，而不是模型。本页前三分之一的内容，讲的是 RLCD 被设计出来所针对的两种训练方法，因为只有当任务不再是一场对话、而变成一种判断时，RLCD 才能被理解为对这两种方法所做之事的一种修补。如果你已经知道 RLHF 和 RLVR 优化的目标是什么，那么你想看的是第三节，在那里，TypeSafe 自己的三向表会完成这项工作。

RLHF针对的是一个人更偏好的答案

基于人类反馈的强化学习，是让预训练语言模型变成助手的方法。TypeSafe 自己的入门指南直言不讳地说明了这一目标，在一张标题为 RLHF 的卡片中写道：它“将预训练模型变成了聊天机器人。它训练模型生成人们更偏好的回复。”InstructGPT 和 ChatGPT 就是用它训练出来的，而这份入门指南还补充了一个细节，这个细节在这里之所以相关，是出于另一个原因——该方法由 Diogo Almeida 共同发明，他是 TypeSafe 的联合创始人，也是 Jev 发布帖的作者。该公司并不是在否定这一方法；毕竟公司是由帮助构建该方法的人创立的。它是在主张，这一目标对某项特定任务来说并不正确。

要看清这种错配，最直接的方法是问：奖励信号实际衡量的到底是什么。在 RLHF 下，它衡量的是评分者对两个候选回复的偏好。当产品是一段对话时，这是一个极好的代理指标，因为对话的成功标准确实就是一个人是否觉得回复好。而当产品是一个决策时，它就是一个失效的代理指标，因为那里的成功标准是所声明的置信度是否与现实相符，而一个比较两段看似合理的文字的评分者，根本无法看出一个校准良好的 0.6 和一个听起来很自信的 0.95 之间的区别。两个答案可能同样受偏好，但在一款软件应当在多大程度上信任它们这一点上，却可能天差地别。

TypeSafe 在入门指南中命名的故障模式直接源于这一点：

• 谄媚——模型学会生成评分者想听到的内容，这与真实的目标不同。

• 听起来自信的幻觉——流畅性和确定性即使毫无依据，也会受到偏好机制的奖励。

• 模式丢弃——偏好优化会收窄输出分布，“偏向某种特定风格，例如指令遵循，同时降低其他可能输出的概率。”模式丢弃是经典模式崩溃失败的轻微版本，这种失败困扰着生成对抗网络：生成器会收敛到某一个输出，并不断欺骗判别器。

这份入门读物自身的警告段落，才是值得保留的那句话：“一个输出可能对人有吸引力，却不足以可靠到用于无人值守的自动化。人类偏好和机器可信度是不同的优化目标。”这并不是对 RLHF 作为一种方法的批评。它指出的只是：一个经过偏好训练的模型，从未被问过自动化需要它回答的那个问题——当它声称自己有把握时，它究竟有多经常是对的。

RLVR 优化的是程序可检查的输出——而决策很少有这样的输出

带可验证奖励的强化学习是第二种改造，也正是推理模型背后的那一种。TypeSafe 的入门指南描述了它带来的结果：模型“擅长数学等任务，但速度更慢、成本更高”。其机制是一个检查器。如果一项任务有一个程序可以测试的答案——单元测试、证明检查器、数值答案——那么无需向人类询问任何东西就能计算出奖励，并且模型可以大规模地基于这一信号进行训练。它行之有效，也正是推理模型恰好在存在廉价自动验证的领域变得擅长的原因。

这个局限就在于“可验证”这个词的形态。可验证的奖励需要一个验证器，而验证器要求任务有一个有人能计算出来的正确答案。想想生产系统实际会问的问题。这张支持工单应该转给账单部门还是技术部门？这个退款请求符合政策吗？这笔交易看起来像欺诈吗？每一个在大多数时候都有一个站得住脚的答案，但没有任何一个有一个程序可以核查的答案，而最重要的情形恰恰正是经验丰富的人类意见不一的情形。没有可运行的函数。RLVR没有什么可奖励的，因此它毫无贡献。

诱人的变通做法是，通过给数据集打标签并依据标签进行训练，来制造一个验证器。这让该方法有了可供咀嚼的东西，但它以事关重大的方式改变了目标。标签编码的是一个决策，而不是围绕这个决策的不确定性。一个被训练来复现某个团队在困难案例上的判断的模型，会学会像那些标签一样自信——也就是说，恰好和写下这些标签的人一样过度自信。而且，即使确实存在真正的验证器，也还有第二重缺口。验证器给答案打分，却不给所声明的置信度打分。一个在95%的案例上正确、却对所有这些案例都报告确定性的模型，会拿到满分奖励，但作为自动化流水线中的一个组件，它毫无用处——因为那5%才是流水线唯一需要被告知的部分。TypeSafe 的发布材料从另一个方向说明了同一点：“如果一个模型有95%的时间能完成某项任务，却不说自己何时处于那5%之中，它就无法自动化那项任务。”

RLCD 的作用，以 TypeSafe 自己的表述方式

RLCD 改变的是输出契约，而不是答案质量。入门指南的卡片上写着：“面向校准决策的强化学习训练 TypeSafe 返回决策和经过校准的概率，而不是生成文本。”发布帖的简洁版本是：“校准决策：在 System One 任务上给出认知上诚实的概率的答案。”两者描述的是同一个举措：训练模型时所依据的，是其陈述的概率是否与该答案最终正确的频率相匹配，而不是某个人或某个检查器是否喜欢这个答案。

发布文章将三种方法并排呈现，而其中的对比是对这一理念现有最清晰的表述。请把它当作一组对比来读，而不是一张表格：

• 它优化的目标是什么——RLHF 优化的是人类偏好，“人类评分者更喜欢的文字说明和聊天回复”；RLVR 优化的是“能够以程序化方式验证的输出”；RLCD 优化的是校准，“在 System One 任务上给出具有认识论诚实性的概率的答案。”

• 输入的是什么——较早的两个接收非结构化数据，“重点在于序列消息”；一个经过校准的决策模型接收非结构化数据，“重点在于结构化的程序状态”。

• 输出的是什么——生成的字符串“需要解析 + 验证”，总是“存在 AI 失控的某些风险”，相比之下，类型安全的结构化值中“可能的输出和结构都是预先定义的”，模型“从不犯类型错误”，并且“所有答案都附带经过校准的概率和置信度分数。”

• 它是如何采样的——一次一个词元，每个都以上一个为条件，而不是在单次查询中生成所有输出。这就是第三种方法开销低的机制性原因：无需为解码循环付出代价。

• 成本 — 对比模型的输入 token 每百万从 $0.20 到 $10，输出价格约为输入的五倍；而 Jev 的输入 token 每百万仅需 $0.042，输出计费为零。

• 它的回答速度有多快——前沿模型端到端需要 3 到 329 秒，而它只需 70 毫秒到 500 毫秒，供应商称，在 System One 形态的查询上，这要快 40 倍到 200 倍。

• 关于它对自身置信度的说法——较早的两个“即使被提示给出置信度估计，也往往过度自信且不一致”；RLCD“每次输出都会传达置信度和不确定性”，其中“置信度越高意味着准确率越高”。

最后一行才是真正的产品主张，而且它以其他几行所没有的方式可被证伪。“更高的置信度意味着更高的准确率”是一个关于曲线的陈述：按照模型为其答案赋予的概率将答案分桶，而这些桶正确的比率应大致与这些概率所声称的一致。TypeSafe 的置信度文档用异常具体的数字明确说明了这一约定：

• 被赋予 0.2 概率的结果应大约有 20% 的时间发生。

• 被赋予 0.8 概率的结果，大约应在 80% 的情况下发生。

• 被赋予 1.0 概率的结果应 100% 发生。

然后，用供应商自己的话说，就是那句让这一说法保持诚实的话：“这些比率描述的是成组的预测，而不是对任何单个答案的保证。”这并不是为了法律原因而硬加上去的对冲话术。这正是校准的全部含义。一个校准良好的模型给出0.8时，并不是在承诺这次一定正确；它承诺的是，在它标记为0.8的所有答案中，大约五分之四是正确的。单个答案说明不了任何问题。一周内的一千个答案才能告诉你这条曲线是否真实。

同样的三卡片对比也出现在 TypeSafe 自己的文档中，它既是上文比较的来源，也是核对措辞最清楚的地方，而不是只听某个摘要的说法。下面的截图就是该页面当前的样子：三张卡片对应三种后训练方法，其中第三张完整写出了 RLCD。

供应商文档中的另外两个细节，揭示了这种方法对产品的渗透有多深。第一个细节是：置信度是推导出来的，而不是直接生成的——模型会针对你提供的各个选项或层级返回一个完整的概率分布，而置信度值是根据该分布的形状计算出的一个统计量。正因如此，文档才能告诉你这个定义并不承担关键作用——无论哪种情况你都能拿到原始分布，而且如果你自己的统计量更合适，你完全可以自行计算。第二个细节是：RLCD 是唯一塑造权重的东西。TypeSafe 的 models 页面指出：“Jev 不会使用客户数据进行微调或 LoRA 适配。它通过 RLCD 训练以返回经过校准的决策，并且同一套权重服务于每一个账户。”领域适配发生在请求之中——你的状态、你的标准——而不是在每个客户的检查点里。这种方法产生了什么样的校准，每位客户拿到的就是什么样的校准。

为什么校准是让廉价决策模型变得可用的关键

一个经过校准的概率本身并不有趣。当你的代码根据它进行分支的那一刻，它就成了架构，而 TypeSafe 的置信度文档正是将这种模式描述为三个范围，每个范围都会产生不同的系统行为。

• 高置信度 — 自动执行。模型判断明确，你可以在无需人工参与的情况下直接进行。

• 中等置信度——请谨慎处理。模型给出了合理的答案，但并不确定，因此你应先与用户确认、标记以供审查，或收集更多信息，然后再采取行动。

• 低置信度——请勿采取行动。将任务转交给人工、请求澄清，或回退到其他系统，因为模型是在告诉你，它没有足够的信息可供继续。

文档明确指出，边界由你划定，并且应因后果而异：“置信度阈值不是一个数字。同一系统中的不同操作应根据出错后果的不同，在不同层级上设置门槛。”他们的示例将硬性下限设为 0.5——模型报告的任何低于该值的结果都会被直接转交人工，无需进一步检查——然后对破坏性操作施加比只读操作更高的标准。你的代码编码了风险容忍度；模型为其提供诚实的输入。

这种模式正是双模型工作流的全部论据，而且它值得作为一个论据来陈述，而不是列成一份功能清单。假设你想要一条自动化流水线，让它处理有把握的大多数情况，并把其余情况升级交给更大的模型或人来处理。升级的决定总得来自某个地方。如果那个廉价模型对一切都报告 0.98，包括它其实只是在猜的那些情况，那么这个分支就无从检验，你要么把所有事都自动化——包括那些本该升级的调用——要么什么都自动化不了。只有置信度具有信息量的模型，才能让你安全地自动化其中一部分，因为只有它才能告诉你，它在哪一部分上不安全。文档用一句话点明了同样的要点，因其直白而值得引用：“如果一个智能系统——无论是人还是机器——无法表达诚实的不确定性，那么这个系统就不可信。”

对于廉价模型而言，这一点比昂贵模型更为重要，还存在第二个原因，而这个原因正是路由这条脉络与 RLCD 这条脉络其实是同一条脉络的原因。一个每百万输入 token 定价 $0.042、且不收取输出费用的模型，便宜到足以被持续不断地咨询——在 agent 循环的每一轮、在批次中的每一条记录、在每一张工单到达之时。而被持续不断地咨询，恰恰正是模型的错误会不断累积放大的处境，因为在它的输出被付诸行动之前，没有人会去读它。置信度正是让这一切变得安全的因素。廉价则是让升级分支变得可负担的因素，因为那条昂贵的路径只会运行在廉价模型所拒答的那一小部分案例上。这两半缺了任何一半都不成立，而将两者连接起来的路由决策，就是给一个数字设定阈值；RLCD 正是让人有理由相信这个数字的依据。

诚实的界限：校准并不等于正确

关于 RLCD，最重要的一点是它没有声称什么。校准是置信度的一种属性，而不是对答案的保证，供应商在自己的文档中说明了这一点，而不是留给批评者去指出。System One 页面：“System One 模型经过训练以做出校准决策：其概率针对结果进行优化，以反映不确定性。校准是在预测组中进行衡量的；它并不保证单个答案是正确的。”一个模型可以完美校准，但在你的工单上仍然做出错误判断，因为 0.9 意味着十分之九，而这可能是第十个。

我们自己的服务数据在这里是有用的对照，恰恰因为它们是生产环境中模型的测量值，而不是关于该方法能取得什么成果的说法。在截至 2026-09-30 的七天里，针对自该模型被加入目录以来通过 OrcaRouter 的 playground 的流量，Jev 1.13 卡片报告：在 7620 万 token 上错误率为 0.49%，同时首 token 时间 p50 为 151 ms、p95 为 247 ms，以及约每秒 349 个输出 token。关于这个数字，有两点值得直说。它是我们自己的，不是供应商的；而且它是滚动窗口，而不是固定测试集——同一字段在该窗口早些时候的读数为 0.57%，因为它是基于过去七天的实时流量重新计算的，昨天的调用会滚出窗口。它也不是校准测量。错误率告诉你的是在我们的流量上出问题的频率；它并不能告诉你置信度值是否诚实，这是一个不同的问题，需要标注数据才能回答。

供应商在其阈值指南所附的一则说明中给出的也是这条实用建议：“正确的阈值取决于你的业务领域以及模型在你的使用场景下的表现。从保守的阈值开始，用你自己的数据测试，并随着观察到的结果进行调整。”RLCD 是一个关于模型如何被训练的声明。这一声明在你的输入上是否成立，是一个实证问题，而且它是少数无需任何机器学习基础设施就能检验的模型属性之一——取几百个你已经有标签的案例，按模型报告的置信度对答案进行分桶，然后检查各个桶的准确率是否达到它们所声称的水平。如果在你的流量中，0.9 这个桶大约有 90% 的时候是对的，那么这个阈值就是真实有效的，你可以在它之上进行自动化。如果一切都聚集在 0.9 以上，而准确率却跟不上，那你就学到了比任何头条数字都更有用的东西。

另外两个限制也应一并说明。第一，这个模型没有公开的基准卡可供对照核查其中任何内容——供应商尚未发布，也没有第三方排行榜收录该模型；截至 2026-09-30，它在 Artificial Analysis 上的模型页面返回 404。因此，校准论证依赖的是训练描述、文档中写明的约定，以及你自己测得的结果，而不是一条已发布的曲线。第二，供应商自己的性能声明只是它自己的说法：发布博文坦承，支撑速度和成本标题数据的流程评估由其模型能力团队构建，用来衡量这些评估的参考答案是两个外部模型结果的平均值，而且这些数字“处于真实世界收益的较高端”。它还表示，无法证明其定价没有补贴。这一切都不会削弱训练方法，因为训练方法与速度主张是两回事，但这确实意味着，支持 RLCD 的论据是关于目标设计的论证，而不是已经尘埃落定的实证结果。把它当作一个可以低成本检验的假设，这比大多数训练方法主张留给你的处境要好。

你现在可以用它做什么

这条论证的两个部分在一个地方交汇。RLCD 是决策模型的置信度值得据以分支的理由；你代码里的阈值就是该分支所在之处；而只有当常见路径足够便宜、能在任何地方运行时，升级才负担得起。Jev 1.13 在 OrcaRouter 上可通过 typesafe/jev-1.13 调用——一个 API 接入 200+ 模型，0% 加价，按提供商标价透传，因此供应商降价当天这里就能生效——这意味着高置信度多数路径与生成式升级路径用同一个密钥计费，而不是靠两份供应商合同。你仍然要按它自己的形式调用它，即 POST /v1/systemone、非流式，面向 65,536 token 的上下文，因为那不是 OpenAI 的 chat-completions 路由，也没有被并入 chat 端点。如果你正在把它接起来，供应商 SDK 发布说明里的两条带日期的记录值得了解：版本 0.7.1 于 2026-09-21 发布，新增了与 AI 网关配合使用的示例；版本 0.7.2 于 2026-09-26 发布，为 Python 包新增了 http2 extra。第二条正是那种只会在发布说明里出现的细节——对于一个全部价值主张就是 200 毫秒以内往返的模型来说，拥有一个 HTTP/2 客户端是值得的。

如果你要从这一页中带走一件事，那就带走 RLCD 所回答的问题的形态。它不是“模型能否更聪明”。而是“模型能否在它不够聪明时告诉我，而且告诉得足够频繁、足够准确，以至于我可以把其余部分自动化”。这与该领域过去几年投入研究的两个目标不同，而且是唯一能产生一个你的代码可以据此行动的数字的目标。置信度值就是那个数字。在信任它之前，先在你自己的标签上测试它，并且从一个你如果弄错会感到难堪的阈值开始，而不是从一个你希望自己正确的阈值开始。

最后一块拼图值得与所有内容一同带上，因为它是整个论证所指向的那个数字，而且是测量出来的，不是声称的。下面的卡片是我们自己的 typesafe/jev-1.13 七天服务记录——是线上实际运行的模型，不是训练方法，也不是基准测试。把它看作校准问题的后半部分：置信度告诉你哪些调用需要采取行动，而这个记录告诉你，其余路由决策距离一个你可以放任不管的系统还有多近。