P3-9.9 如何区分实际目标与代理目标¶
Section ID:
P3-9.9Version:v2026.09.20
P3-9.8区分了模型分数与复核安排策略。还需要确认模型擅长预测的值是否就是我们真正想知道的结果。即使建立模型是为了减少故障，如果训练答案是复核请求，模型直接学习预测的也是请求，而非故障本身。这样用来替代所需结果的列称为代理目标。
区分减少故障、预测故障与复核请求¶
| 层次 | 本例的问题 | 所需记录 |
|---|---|---|
| 最终目的 | 希望减少运行中的故障 | 实际故障、运行条件、干预措施与比较依据 |
| 希望直接预测的结果 | 预测时点之后七天内是否发生故障？ | 明确观察窗口的故障及维修记录 |
| 当前可观察的代理值 | 负责人是否提出额外复核请求？ | 请求决定、负责人、时间及判断标准 |
“减少故障”是运行成效目标，failure_within_7d 是要预测的结果列，review_requested 则是人的中间判断。有请求不等于已确认故障，没有请求也不等于没有故障。把三种问题合并成一个名称，就难以看清模型究竟做好了什么。
后续结果到达后，重新查看同样的三个对象¶
以下虚构设备 A、B、C 仅用于本节。每个样本表示一台设备在 2026-09-01 10:00 KST 的状态，输入限于当时可用的信息。现在考虑把当天 10:20 记录的复核请求作为代理标签。review_requested=1 表示有请求；0 表示负责人已完成本次判断，并明确记录不提出请求。记录缺失或未复核不能填成 0。
真正需要的结果遵循 P3-9.7 的 failure-v1 定义：设备自身异常使计划动作未能完成，并在维修记录中确认原因，排除计划停机。结果窗口为9 月 1 日 10:00 及之后、9 月 8 日 10:00 之前。最初，三个对象在此窗口内的结果都尚未确认。
| 设备 | 9 月 1 日 10:20 的 review_requested | 后来确认的 failure_within_7d | 已确认的经过 |
|---|---|---|---|
| A | 1 | 0 | 9 月 1 日 10:30 调整设置；追踪完整窗口后确认没有故障 |
| B | 0 | 1 | 无额外干预；9 月 4 日发生故障，经维修确认 |
| C | 1 | 1 | 无额外干预；9 月 5 日发生故障，经维修确认 |
假设后续结果列在 9 月 8 日 11:00 关联进来，且本教学表中三个设备的观察与确认都没有遗漏。若只追踪有请求的 A、C，就会漏掉 B 的故障。要检查代理值是否适当，也需要确认有请求和无请求两类对象的后续结果。
A 有请求但没有观察到故障，B 没有请求却发生了故障。也不能仅凭 A 的 0 就认定请求没有必要。表中没有“不调整设置时的结果”，所以也无法仅凭此例确认调整阻止了故障。这与 P3-8.7 区分观测结果和干预效果的理由相同。
全部猜对代理值，不等于全部预测对故障¶
假设某个虚构模型正确预测了全部三个请求标签：1、0、1。相对于请求的准确率是 3 / 3 = 100%。但若仅把同样的输出改名为故障预测，与实际结果 0、1、1 一致的只有 C，因此是 1 / 3 ≈ 33.3%。
这是用三行构造的反例，不是模型性能估计，也不是普遍比例。它说明，即使输出不变，选用什么作为答案，也会改变评估的含义。准确预测故障和通过干预减少故障同样是不同成果，因此仅凭请求预测分数无法证明故障减少。
如果直接目的是预测复核工作量或分配负责人，review_requested 可以成为该问题正式的目标。用它代替故障时，才称为代理目标。更早得到这个值，本身不足以说明它是适当的替代项。
把可观测代理值连接到实际目标¶
flowchart TD
A["最终目的：减少故障"]
B["希望预测的结果：七天内故障"]
C["当前代理值：复核请求"]
D["当前模型：预测请求标签"]
E["两类请求状态对象的后续故障与干预记录"]
F["检查请求与故障不一致及观察条件"]
G["通过单独的比较依据检验故障减少成效"]
A --> B
C --> D
B --> E
C --> F
E --> F
A --> G
E --> G
连线表示问题与确认资料的关系，不表示请求导致故障。后续结果到达后，不覆盖原始请求标签，而是按设备 ID 和预测时点关联单独的故障结果列。请求判断标准和实际故障定义也应分别保留。
把“代理值的局限”转化为待检查记录¶
| 交接备注 | 本例应记录的内容 |
|---|---|
business_goal | 减少运行中的故障 |
| 希望直接预测的结果 | failure_within_7d、failure-v1，包含起点、不包含终点的七天 |
proxy_target 与 proxy_reason | review_requested；请求记录较早可得，而故障结果尚未确认 |
proxy_gap | A 请求 1、故障 0；B 请求 0、故障 1。请求标准与干预可能影响两者关系 |
| 需要补充确认的记录 | 有请求与无请求两组的故障及维修记录、观察是否完成、干预类型与时刻、请求标准版本 |
review_owner | 指定对照请求标准与后续结果的负责人；实际交接时填写姓名和角色 |
如果标签来自“输入中的下降率越过某个阈值就记为 1”的规则，那么用这些输入学习该标签的模型首先是在复现规则。也应先考虑能否直接应用规则。即使规则复现分数很高，没有独立确认的故障记录，也不能作为故障预测的依据。
练习：如果请求为 0 的 B，其后续故障记录尚未到达，能否把故障结果填为 0？能否因为模型猜对了全部请求，就报告“所有故障都预测对了”？
解答：B 的故障结果应保持未确认。请求 0 不能替代故障 0。当前能报告的是请求标签预测得多准确；若要评估故障预测，则需要不受请求状态限制、独立确认的后续结果。P3-9.10 将继续讨论迟到的结果与观察尚未完成的状态。
检查清单¶
- 能否分别写出最终目的、希望直接预测的结果和当前学习的代理列？
- 能否解释为什么同样的 1、0、1 对请求是 3/3 一致，对故障却只有 1/3 一致？
- 能否确定检查代理值所需的后续结果及干预记录，并避免把结果未确认改为 0？
来源与参考资料¶
- Google, Machine Learning Glossary,
label,derived label,proxy labels。用于确认术语依据：在监督学习中，标签是一个样本的答案或结果部分；当实际标签不存在时，应谨慎选择代理标签。 https://developers.google.com/machine-learning/glossary / 确认日: 2026-07-20