decider 如何用强化学习提升概率校准：v8 到 v10 的 RL 训练全流程拆解-开发者社区

【免费下载链接】decider

A family of System One-style models fine-tuned from Qwen3.5, designed for one-pass typed decisions with calibrated probabilities.

项目地址：https://gitcode.com/gh_mirrors/decide/decider

点击查看免费下载

decider 是一组从 Qwen3.5 微调而来的 System One 风格模型家族，核心能力是单次前向、带校准概率的类型化决策（one-pass typed decisions）。本文完整拆解 v10 是如何在 v8 权重之上，通过384 步校准感知强化学习（calibration-aware RL）训练的：奖励只来自结果、六道门禁把关、浏览器任务采样成功率从 83.0% 提升到 93.2%、belief 超额 nats 近乎减半。

🎯 v10 要解决的问题：为什么用"校准感知"的强化学习

v8 是 Hub 上经过监督训练的强大检查点，但它的输出分布还可以更准：在已知概率规律的环境里，模型对自身下一步结果预测的置信度，与"精确后验"之间仍有 0.473 nats 的 gap。

v10 的思路不是加一个策略头，而是直接训练对外服务的那个分布本身——单次前向、答案槽位的字母 logits、按存储温度 1.30 做 softmax。所有损失项都在这条服务分布上计算，rollout 每次前向只打一分，因此训练开始时 PPO 的比率恰好是 1。这一设计说明见 docs/RL.md。

关键原则：全程没有任何 gold 标签进入训练。两个外部评测集（102 行 TypeSafe 工作流、5,252 行 OpenJev 夹具）只用于报告，从不参与奖励、门禁或检查点选择。

🧪 训练环境与"只看结果"的奖励设计

RL 在四类环境里进行，每轮迭代的规模、结果奖励和配套的 belief 问题如下：

环境	每轮规模	结果奖励	belief 问题（对精确规律打分）
实时 MiniWoB++ 点击任务（16 个训练任务）	4 任务 × 4 重复，至多 12 次点击	任务自带 checker 报成功 +1，否则 −1	这次点击会带来什么：成功 / 失败 / 继续
4×4 扫雷（精确解）	4 棋盘 × 4 重复	赢 +1，输 −1	每个未翻开格子是雷还是安全，对比精确后验
5×5 打滑网格	2 棋盘 × 4 重复	到达目标	采样走法实际落在哪，对比转移规律
已知成分的抽袋博弈	2 棋盘 × 4 重复	游戏获胜	下一次抽出什么，对比袋中成分

几个细节值得注意（docs/RL.md）：

22 个浏览器任务里有6 个从未被奖励（click-checkboxes-transfer、click-tab-2-hard、click-collapsible-2、click-dialog-2 等），只用于验证——而它们恰恰是提升最大的；
MiniWoB++ 的 episode 计时器在每次 reset 后关闭，否则模型的前向时间会把 10 秒的回合拖超时；
页面元素以文本列出并直接充当选项，模型对每个元素给出概率。

🧠 四个损失项：actor、belief、渲染一致性、retention

这是整个配方的核心，四项系数各有分工（docs/RL.md）：

损失项	系数	作用
Actor	0.1	对采样动作的服务概率做 PPO 裁剪代理损失（clip 0.2），用终端回报 + 4 次重复间的 leave-one-replicate-out 基线
Belief	0.2	用同一一次性格式问"接下来会发生什么"，按 log score 对精确规律打分——这是恰当评分规则，只有说出真实概率才会最小化；选项按两种顺序读取并平均字母 logits，消除顺序偏置
渲染一致性	1.0	把服务答案（state-first 布局、给定顺序，detach）与另外三种渲染（逆序、schema-first、schema-first 逆序）做 KL，让两种布局、两种顺序在权重移动时保持一致
Retention	0.7	每步回放 8 行监督数据，计算 KL(v8 ‖ student)；若 8 行均值 > 0.01 nats 或单行 > 0.05 nats，该步丢弃 actor 与 belief、清零优化器一阶动量、只施加这一项——全部 576 步中有 94 步走了这条保护路径

优化器设置：AdamW，BF16 权重配 FP32 master，betas 0.9 / 0.95，weight decay 0.01，峰值学习率1e-6（16 步 warmup，576 步余弦调度），梯度范数裁剪 1.0。每轮产生 96 个采样转移，分 12 个 batch（每个 8 行）训练。

⚙️ 六道门禁：v10 是怎么被选出来的

检查点在 192 / 384 / 576 步保存，用固定种子验证。一个检查点只有同时满足全部六道门禁（均相对 v8 起点）才有资格：

门禁	条件
采样胜率	加权胜率（0.5 浏览器奖励任务 / 0.25 扫雷 / 0.125 网格 / 0.125 抽袋）至少高于 v8 0.02
贪心胜率	同加权，不低于 v8
Belief 超额	对精确规律的平均 log-score gap 至少低于 v8 0.02 nats
通用 NLL	847 行监督验证集的 macro NLL 至多高于 v8 0.005
通用准确率	至多低于 v8 0.002
渲染一致性	256 行上四种渲染的 argmax 一致率至多低于 v8 0.01

四条并行实验臂（两个种子 × 两个 KL 预算）都产出了合格检查点，最终发布的 v10 是种子 9419、KL 预算 0.01 / 0.05、第 384 步（docs/RL.md）。

📈 训练效果：v10 到底改了什么

在同一批行、同一批种子上测量，95% 置信区间如下：

指标（v10 对 v8，同一行）	v8	v10	差异（95% CI）
22 个实时浏览器任务，采样玩法	83.0%	93.2%	+10.2（+5.1 至 +15.9）
其中 6 个从未被奖励的任务	72.9%	91.7%	+18.8（+6.2 至 +31.2）
贪心玩法	90.3%	90.9%	+0.6
Belief 超额（nats）	0.473	0.219	近乎减半
点击结果 log score	−0.349	−0.034	大幅收窄
抽袋博弈胜率	35.2%	41.4%	+6.2（+0.8 至 +12.1）
Mind2Web 元素与动作选择（1,770 行）	81.1%	82.7%	+1.5
TypeSafe 工作流决策（102 行）	78.4%	80.4%	+2.0
847 行 in-task 验证	83.6%	83.2%	−0.4（区间含 0）
OpenJev（5,252 行）	64.1%	63.3%	−0.8

浏览器收益集中在服务分布上：贪心只涨了 0.6 个点，十个点全部在采样玩法里，而从未被奖励的六个任务提升最多——说明模型学到的是可迁移的"预测自己行为后果"的能力，而不是背题。

游戏方面，2B 模型没有搜索，扫雷和井字棋前后都输大多数——变的是概率质量的分布：抽袋博弈里 v10 把 67% 压在最优的袋上（v8 是分散到多个袋上的 7%），多赢 6 个点；打滑网格上 v10 把 90% 放在正确走法（v8 只有 37%）。

校准是 RL 目标直接训练的对象：对每个动作，模型被问"接下来会发生什么"，答案用 log score 对精确规律打分。v10 在精确规律之上只超出0.22 nats（v8 是 0.47），在浏览器里预测自己点击结果的 log score 从 −0.35 收窄到 −0.03。

🔍 没变的部分，以及路上学到的教训

没变的：井字棋 / 网格 / 扫雷胜率、训练任务上的通用准确率、Bespoke 套件上的校准、架构、readout、温度和推理速度。另外 v9 的 terse-bucket 数据不在 v10 里，因为 RL 是从 Hub 上的 v8 权重出发的。

路上学到的（docs/RL.md）——这两次失败直接塑造了上面的配方：

学习率 2e-6 会导致漂移：从第 384 步起，模型在短回放行上 KL 最大漂到 5.8 nats，给出自信的错误答案，没有任何检查点通过全部门禁；把峰值学习率减半到 1e-6 后消失；
渲染一致性项砍半漂移：该损失最初只在一臂运行，就使漂移减半，因此正式进入配方；
等权胜率门禁不可达：2B 模型的网格与抽袋玩法根本不动，门禁最终重新加权、偏向策略确实会动的浏览器环境（等权数字仍被记录但不作门禁）。

📚 延伸阅读

完整配方、门禁与全部测量：docs/RL.md
各版本训练历史长文：docs/HISTORY.md；v10 发布条目：docs/CHANGELOG.md
RL 实际训练的对象——readout 与模型定义，原样 vendored，检查点可直接在本包加载：decider/prompt.py、decider/model.py
游戏环境模块（扫雷、打滑网格、抽袋等）：decider/games/，如 decider/games/envs.py、decider/games/rl.py
复现提醒：RL 训练代码在独立的研究仓库中——它需要实时 Chrome + MiniWoB++、精确游戏环境和四块 GPU 支撑并行实验臂；但训练读出的就是本包中的 readout，因此 v10 检查点无需任何转换即可使用