一篇看懂 Laya 的 RLCD：置信度校准才是它敢叫板 Jev 的底气

一篇看懂 Laya 的 RLCD：置信度校准才是它敢叫板 Jev 的底气

【免费下载链接】layaNon-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100+ languages, with a router that picks the right checkpoint per request.项目地址: https://gitcode.com/gh_mirrors/lay/laya

2026 年的开源圈里，"System 1 决策模型"这个品类被 Jev 一炮带火，随后 Laya 以 Apache 2.0 全开源、33ms 级单次前向推理、三套 checkpoint 自动路由的姿态正面应战。社区热议大多停在"快"字上——421M 参数、T4 上 32.8ms、比 Jev 快 6-7 倍——但真正让这场对标变得有技术含量、也最有争议的，其实是另一个指标：ECE（Expected Calibration Error，期望校准误差）。

在 Laya 的仓库里，校准不是训练之后顺手做的后处理，而是写进训练目标、渗透到推理解码和弃权门控的完整链路。它的全部底气，来自一种名为RLCD（Reinforcement Learning against strictly proper scoring rules，基于严格适当评分规则的强化学习）的对比决策训练范式。本文结合仓库源码拆开看这三层：RLCD 怎么训练、三原语怎么在单次前向里落地、以及 ECE 为什么是护城河争议的真正焦点。

RLCD：用"分布"做监督，而不是用"标签"

绝大多数分类模型训练时拿到的监督是硬标签：一个样本属于 A，就只给 A 以 1 的概率。Laya 的训练目标不是这样。按照 docs/finetune.md 的描述，RLCD 训练在基准数据的 gold 分布上，而非硬标签上——每个样本携带的是教师模型分配给每个选项的概率向量，损失的两半都读取这个分布。

训练循环在 laya/train.py 里被实现为一个可共享的模块，其中rlcd_loss是核心：

def rlcd_loss(logits, target, mask, qtype, sigma, samples=4, w_sph=0.75, w_rps=1.0): # 对 detached logits 加零均值高斯噪声（sigma 缩放的采样）， # 每个样本用 proper_reward 打分，归一化优势加权高斯对数密度，加上软交叉熵

这个目标由两项组成（laya/train.py 的模块文档）：

• 策略梯度项：GRPO 风格，对每个样本取 4 个加噪 logit 投影，探索噪声从 0.4 线性退火到 0.1，用严格适当评分规则对每个加噪样本打分，再以归一化优势加权；
• 软交叉熵项：全权重地拟合目标分布本身。

关键在于"严格适当"三个字。所谓 proper scoring rule，是指模型如果把真实分布作为预测报告出来，就能取得最优期望分数——撒谎不会得到更多回报。Laya 的奖励函数proper_reward（laya/common.py）把三种规则叠加在一起：

def proper_reward(q, target, qtype, mask, w_sph=0.5, w_rps=1.0, log_floor=-9.21): log_score = (target * logq).sum(-1) # 对数评分 sph = (target * q).sum(-1) / q.norm(-1) # 球面评分 r = log_score + w_sph * sph # score 类型额外扣减排序概率评分（RPS） rps = (((cdf_q - cdf_t) ** 2) * mask).sum(-1) / (k - 1) r = r - w_rps * rps * is_score

对数评分惩罚过度自信的极端分布，球面评分天然与温度缩放兼容，排序概率评分（RPS）则专门约束序数型输出——它按累计分布函数之差计算，对"顺序错误"比"单个桶错"更敏感。三者叠加，本质上是把"报告的分布要诚实"作为优化目标本身，而不是作为事后约束。这与社区对 Jev 的分析不谋而合：Jev 真正的技术壁垒不在推理速度或架构，而在于 RLCD 训练实现的置信度校准能力——社区 48 小时密集复刻接口范式容易，复现高精度校准却需要私有数据管线与持续标定方法论，这正是开源圈反复讨论、也最难抄走的部分。

三原语 × 单次前向：没有生成，就没有幻觉

RLCD 训练出来的模型要回答什么问题？Laya 把决策压缩为三个原语，README 的 Quickstart 给出了直观形态（README.md）：

questions = { "department": {"type": "choice", "instructions": "Which department should handle this?", "criteria": {"billing": "invoices, payments, refunds", "technical": "bugs, outages, system errors", "other": "everything else"}}, "urgency": {"type": "score", "instructions": "How urgent is this?", "criteria": ["not urgent", "soon", "blocking"]}, "churn_risk": {"type": "noul", "instructions": "Does the user threaten to cancel or leave?"}, }

• choice：从 K 个候选标签中选一个；
• score：在序数等级上给期望值；
• noul：是非判断，直接输出 P(true)。

三个原语共享同一套序列构造逻辑。build_sequence（laya/common.py）把问题、选项和状态拼成一条固定格式的输入：

[CLS] <type> instructions [SEP] [MASK] opt0 [MASK] opt1 ... [SEP] state [SEP]

每个选项对应一个[MASK]标记位，模型在这些标记位上一并读出所有选项的 logits。注意这里没有 next-token 预测，没有自回归展开——一个请求的 N 个问题在一次前向传播里全部回答完。README 给出测量结果：单问题 33ms、批处理 7.2ms/问题（T4）；BENCHMARKS.md 的 headline 表里，Laya 单问题 p50 为 32.8ms，Jev 的已发布数字是 236-276ms。

无生成的直接红利是：没有 JSON 输出要解析，也就没有解析失败和"编造字段"的幻觉空间。输出本身就是{choice, score, noul, probabilities, confidence, answer_confidence}的结构化字典（解码逻辑见 laya/agent.py 的_decode_answers）。

ECE：为什么校准才是护城河争议的核心

速度是表象。一个"快但自信错了"的决策模型，在工单分流、内容审核这类需要自动化的场景里，比慢一点的模型更危险。Laya 敢把 ECE 摆上台面与 Jev 对表，是因为它把校准当成一条可复现的工程链路，而不是模型附带的光环。

先说 ECE 测的是什么

ece_score（laya/common.py）的实现非常朴素：把置信度分成 15 个桶，对每个桶计算"平均置信度与桶内准确率之差的绝对值"再按样本占比加权。它测的是一个条件性质：在返回置信度 c 的答案里，大约有 c 的比例是对的。

而这个性质的成立是有前提的。仓库里专门区分了两个置信度字段：

• confidence：归一化香农熵置信度（confidence_from_probs），描述分布有多"尖"，但不承诺校准；
• answer_confidence：max(p)，即被报告答案的概率质量，这才是温度缩放拟合的对象，也是所有 ECE 数字的计算基准（laya/common.py 的answer_confidence注释明确写了这一点）。

_decode_answers（laya/agent.py）在推理时也刻意同时输出两个字段，并注释说明只有answer_confidence是"可校准的那一个"——这是给所有想拿置信度做门控的调用者划下的红线。

出厂即"过度自信"，靠温度缩放救回来

仓库的诚实姿态值得注意：两个官方 checkpoint 出厂都是过度自信的。BENCHMARKS.md 的校准表给出温度重拟合前后的对照：

重拟合后 Laya 的 ECE 掉到 0.081，低于 Jev 已发布的 0.246。fit_temperature_map（laya/calibrate.py）按"问题类型 × 选项数"的桶分别拟合温度：类型级标量 +temperature_by_options桶级映射，用 LBFGS 在 log-T 上优化 softmax(z/T) 的 NLL。拟合的温度被 clamp 到[0.5, 5.0]（laya/common.py 的TEMP_MIN/TEMP_MAX），而这个 clamp 本身就是一次历史事故的修复。

仓库注释记录得很直白：出厂配置里choice:11+桶的温度是 0.1006，等价于把 logits 放大 10 倍——0.24 的顶部概率被发布成 0.99，"caller gating on confidence is told a coin flip is a certainty"。没有任何诚实的校准需要这样锐化，于是#42之后加了 clamp。在 51 语言 sweep 的复测里（BENCHMARKS.md），这个 clamp 单独把 macro ECE 从 0.7331 降到 0.5709，且 51 种语言无一例外。

校准的下半场：弃权门控与非参数重校准

温度缩放是参数方法，只能整体软化/锐化一个桶；对某些病态桶（比如出厂那个choice:11+）它无能为力。于是仓库补了两层：

• 按桶拟合弃权阈值：fit_abstention_thresholds（laya/calibrate.py）为一个min_confidence在 2 选项和 12 选项的答案上不可移植——它们校准后的置信度处在不同的标尺上（issue #394）——所以按temp_bucket拟合一刀切分，使接受集上误差 ≤ target_error（默认 0.10）。阈值基于校准后的置信度（先缩放再取 max(p)），保证与运行时报告的数字同标尺；
• 直方图分箱重校准：fit_binning_map（laya/calibrate.py）是温度缩放的互补项，把桶内置信度按 15 个等宽 bin 映射到各自的经验准确率，不假设单调性，专门修温度缩放救不了的可靠性曲线。它与温度映射组合而非替代。

这还没完。弃权门控要拿校准当尺子，就得有验证校准的尺子：laya/evals.py里从同一对 (置信度, 是否正确) 派生 Brier、AURC、选择性准确率等选择性分类指标。整条链路是闭环的——训练时用评分规则逼出诚实的分布，推理时用温度/分箱把过度自信拉回，再用 ECE/弃权指标验证门控真的在按置信度工作。

争议的另一面：校准承诺的边界

Laya 自己列出的"诚实极限"（BENCHMARKS.md）说明校准不是免费午餐：

• banking77 是唯一明确输掉的公开数据集（0.425 对 Jev 0.870），且是架构性的：77 个选项共享固定的head_max_len预算，每个选项只剩约 4 个 token，不再可区分——所以建议 choice 保持 20 选项以内；
• 序数 score 是最弱原语（SST-5 上 0.372），RPS 奖励也没有完全救回序数预测；
• 英文 checkpoint 在英语之外会"崩塌且保持自信"：高棉语 0.000 准确率却报出 0.952 的置信度，均值置信度在任意准确率水平都不低于 0.885——这就是为什么路由（语言检测选 checkpoint）必须发生在前向传播之前；
• 中文场景的二元判断尤其过度自信：zh-decision-bench 的复测里noul:2桶原始拟合温度高达 10.23，超过TEMP_MAX5.0——"中文二元判断的过度自信超出了出厂 clamp 的修正范围"。这解释了社区在中文落地时反复遇到的"置信度偏高、是非题不适配"现象：它不是 bug，是校准曲线的真实形状，得在自己的数据上重拟合。

社区对"48 小时复刻"的反思，最终收敛到这个判断：接口范式可以被快速兼容，校准能力不能。任何团队都能在几小时内把 Laya 的{type, instructions, criteria}问答格式抄进自己的 harness，但要训练出一个"报 0.9 就真有九成把握"的模型，依赖的是 RLCD 的数据管线、评分规则设计和持续标定方法论——这些不会体现在任何一行公开代码里。

结论

回到开头的争议：Laya 敢叫板 Jev 的底气，表面上在 32.8ms 的延迟表里，实质上在 ECE 0.081 对 0.246 的对照里。RLCD 的价值不是发明了一种新的损失函数，而是把"校准"从模型产出的附加属性，变成了训练目标的一部分——先用严格适当评分规则逼模型诚实，再用温度缩放、分箱重校准和弃权门控把诚实兑现到生产调用里。

速度可以靠 CUDA graph 和 TileLang 内核堆出来，架构可以靠非自回归前向抄出来，但校准是一条必须自己走完的工程链路：私有数据、评分规则调参、温度/阈值拟合、持续验证。这正是 Laya 作为开源项目最有价值的部分——它没有把"校准好的模型"当黑盒卖给你，而是把整条链路连同它的失败案例一起开源了。敢把过度自信的出厂状态和 Khmer 0.000@0.952 这样的失败写进 BENCHMARKS.md，本身就是对"校准是护城河"这件事最大的尊重。

【免费下载链接】layaNon-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100+ languages, with a router that picks the right checkpoint per request.项目地址: https://gitcode.com/gh_mirrors/lay/laya