# K8 · 将辨识结果用于控制与迁移

模型预测更准可能帮助控制器，但预测和控制是不同的结论。本课给出一套公平协议，检验两者的联系，并说明 RL 与域随机化应放在哪里。

主线比较使用同一种已声明的方法，从两个模型分别设计控制器配置，再在同一个隐藏 Oracle 上评估。

## 预测更好不自动等于控制更好 {#failure}

假设辨识后模型的留出轨迹误差更低。如果真实系统上的控制器没有改变，这个离线改进不会改变闭环行为。如果根据辨识模型重新设计控制器，行为可能改变，但设计方法和评估必须受控。

先预测一个案例：跟踪变好，但控制代价或约束违反变差。

## 分开三种评估协议 {#boundary}

使用明确的名称：

| 协议 | 改变什么 | 检验什么 |
|---|---|---|
| 同输入预测 | 只改变模型 | 开环或回放预测 |
| 同控制器闭环 | 真实系统与控制器都不变 | 模型精度本身不会改变控制结果 |
| 基于模型重新设计 | 用同一种方法从初始/辨识模型分别生成配置 | 辨识是否支持下游控制器设计 |

主线使用第三种协议。冻结任务、控制器设计规则、预算、约束、初始条件、扰动和隐藏 Oracle。不能反复看最终 Oracle 分数再调控制器。

## 在设计控制器前冻结数据 {#comparison}

流程是：

```text
采集并划分数据 → 辨识模型 → 冻结模型选择规则 →
对每个模型使用同一控制器设计方法 → 在同一 Oracle 上评估
```

辨识的最终评估不能再用来选择控制器或声称控制器最终性能。如果看过 Oracle 结果后改变设计方法，就应开始新的开发循环并保留新的评估集。

RL 训练以及宽泛或定向域随机化属于扩展。它们加入了策略优化和训练分布选择，必须用自己的协议评估。

## 阅读下游证据 {#evidence}

三种协议定义公平对比应测量什么。只有两条“模型到控制器”路径在相同声明的 Oracle 条件下运行后，它们才成为证据。

把预测指标与跟踪误差、控制代价、约束违反分开报告。尽可能配对初始条件与扰动。控制器跟踪更好但代价更高，是否值得取决于预先声明的任务成本。

证据应展示两条“模型 → 控制器”路径，以及相同的 Oracle 评估条件。不能用一个最终分数掩盖安全裕度或工作范围的变化。

## 想一想 {#exercise}

一份报告说：“辨识后模型的预测误差更低，所以控制变好了。”但控制器配置没有改变。这个结论缺了什么？你会要求怎样的公平对比？

<details markdown="1">
<summary>查看参考思路</summary>

它把预测和下游控制混为一谈。在控制器和物理系统都不变时，只修改离线模型不能改变闭环结果。应要求用同一种设计方法从初始模型和辨识模型生成两个控制器配置，再在同一隐藏 Oracle、配对条件下比较跟踪、代价和约束指标。
</details>

常见误区是从未改变的控制器推断控制变好。如果还不能设计对比，先画出两条“模型到控制器”路径，并在评估前冻结设计规则。当跟踪、代价和约束分别有指标时再继续。

## 这个协议不能证明什么 {#limits}

一次正向的控制对比不能证明硬件迁移、普遍鲁棒性或策略改进。它只覆盖一个任务、一种控制器设计方法和一个 Oracle。RL 重新训练、随机化和部署需要独立的数据来源与评估。

L4 会在整机拟合路线比较之后使用这套受限协议。继续阅读 [L4 · 比较整机拟合路线与控制结果](../l4/index.zh-CN.md)。
