解读 81 · 策略影响评估:什么时候必须重训
解读对象:
microduck-replica/docs/换舵机重训全流程.md§1(影响面判定表)、§4(重训 9 个 ONNX:方法与优先级)、§6(测试金字塔 L2)
需要的前置:解读 58(为什么官方 ONNX 作废)· 解读 70(辨识→重训的最短路径)
"换舵机就得重训 9 个策略"——这句话最贵的部分不是"重训",是"9 个"。全流程手册给了三件工具,把这句话从口号变成可评估的工程决策:先用判定表判要不要,再用 L2 评估量化退化多少,最后按优先级排先训谁。
1. 判定表:只有动力学层判"死刑"
§1 把换舵机的影响拆成四层:①几何(外形/孔位)→ 改打印件与 MJCF;②电气(电压窗/堵转电流)→ 供电架构重做;③通信(协议/波特率/ID)→ 运行时写新控制器;④动力学(力矩、速度、回差、摩擦、PD 特性)→ "执行器模型重辨识 + 策略必须重训(官方 ONNX 作废)"。前三层再麻烦都是"适配",写代码、改结构件能解决;只有第④层动的是策略的生存条件——策略学到的是"这台具体机器会怎样动"(训练参数调整指南 §11.6 的表述,解读 58 已展开)。
文档也给了豁免条件:"四层全兼容才谈得上'不改模型直接用'——当前市场没有这样的便宜货"。所以判定表的真实用法是反过来的:不是纠结要不要重训,而是逐层列出"哪些要改",把第④层的重训成本提前算进采购决策(构建日志 09-07 那条记录就是范例:省钱与代价同条记账)。
2. L2 评估:让"退化多少"变成数字
重训之前还有一个便宜的办法先看损失:测试金字塔的 L2 仿真评估——"新执行器模型下:旧策略跑 100 迭代评估 → 量化退化幅度(预期大,作为基线证据)"。做法是把新舵机的辨识参数填进 MJCF,让旧策略在新身体上跑,用仿真五指标(reward/fell_over/误差/std)记录它摔得多惨。这份"惨"不是废料:它是重训后对照的退化基线——构建日志 09-07 明说,expC 续训 2199 迭代的 checkpoint(reward 0.80→12.77)就转任这个角色。评估工具 rl-series/scripts/eval_imu_robustness.py 一类脚本可复用。
3. 九个技能,三档算力,三信号
§4.1 先分清 9 个 ONNX 是什么:9 个技能各自独立训练一次(同一套配方、不同任务配置),每个仅 ~775 KiB。优先级:alpha_walking(任务 Mjlab-Velocity-Flat-MicroDuck)第一个训;alpha_stand/alpha_sitstand 第二(站立是安全兜底);ground_pick、ball_kick 左右脚、roller/roller_crouch、roulade 按需。注意原文标注:任务↔策略文件名的映射为推断,以导出产物与运行时清单核对为准。
§4.2 给三档算力:调试档本机 CPU(--env.scene.num-envs 64 --agent.max_iterations 100,实测约 4 分钟/百迭代,构建日志 exp001 实证);正式档 GPU(4096 环境,数小时~天/技能,无卡用官方内置 --hf-jobs);批量档 ×9。判断"训够了"不看迭代数,看三信号:fell_over 稳定低位、error_vel 平台化、mean_std 收敛。量级参考:官方配方上限 4096 环境 × 5 万迭代,走路通常数千迭代、10⁷–10⁸ 步出现(expC 正在实证 CPU 量级的下限)。
§4.3 是导出后的最后一道门:每次导出跑 rl-series/scripts/inspect_onnx.py,确认 obs[1,61] / actions[1,14];9 个文件命名对齐运行时清单(alpha_* / ball_kick_* / roller* / roulade),放进更新包结构即可被 updaterd 分发。
你带走的收获
- "要不要重训"由判定表第④层(动力学)决定;前三层是适配,不构成作废。
- 影响可以量化:L2 用旧策略在新模型上跑 100 迭代,退化基线既是证据也是对照。
- 9 个技能分开训,顺序 = 核心(走路)→ 兜底(站立/坐站)→ 按需(特技)。
- 训够的判据是三信号,不是迭代数;导出后必过 inspect_onnx 的 61/14 维度门。
- 算力三档按目的选:调管道用 CPU 冒烟,出部署件才上 GPU。