P3-9.10 如何区分标签确认延迟与观察未完成¶
Section ID:
P3-9.10Version:v2026.09.20
P3-9.9区分了复核请求与实际故障结果。即使把实际故障设为目标，仍会有结果尚未确认的行。仅凭“还没看到故障记录”，不能把训练标签填为 0。需要分别检查观察期间是否结束，以及已收到的记录是否核实完毕。
输入截止时间与结果窗口终点不同¶
本节 A、B、C 是另设的虚构设备样本，与前文同名字母无关。它们都在 2026-09-01 10:00 KST 进行预测。如 P3-9.7 所述，输入使用截至当时可用的信息，后续结果另行收集。
目标是 failure_within_7d。结果窗口为9 月 1 日 10:00 及之后、9 月 8 日 10:00 之前，包含起点、不包含终点。按照 failure-v1，只计入设备自身异常导致计划动作未能完成、且维修记录已确认原因的故障，排除计划停机。
| 要检查的边界 | 本例中的含义 |
|---|---|
输入截止时间 cutoff_at | 9 月 1 日 10:00。之后确认的标签不能放入当时的输入 |
| 结果窗口终点 | 9 月 8 日 10:00。根据故障发生时间判断是否在窗口内 |
| 当前判定时刻 | 记录标签状态时，使用了截至何时已经确认的记录？ |
| 实际追踪范围 | 结果期间观察到了哪里，中间是否存在遗漏？ |
七天等于 7 × 24 = 168 小时。日历到达 9 月 8 日 10 时，与已经核实这段期间的全部记录，是两件不同的事。
C 在 9 月 3 日未确认，9 月 4 日为 1¶
下表列出各判定时刻可知的依据。? 表示结果未确认，不是让模型预测的第三类结果。本节的目标结果是已确认的 0 或 1。
| 样本 | 当前判定时刻 | 当时已知依据 | label_status | 结果值 |
|---|---|---|---|---|
| A | 9 月 3 日 10:00 | 截至此时没有故障记录，其余期间尚未观察 | 观察未完成 | ? |
| B | 9 月 8 日 11:00 | 完整追踪七天且无遗漏，报告与维修记录核实完毕，期间没有故障 | 阴性已确认 | 0 |
| C | 9 月 3 日 10:00 | 已收到 9 月 2 日 14:00 异常报告，但是否符合故障定义仍在核实 | 等待确认 | ? |
| C | 9 月 4 日 15:00 | 维修记录确认 9 月 2 日 14:00 的事件属于目标故障 | 阳性已确认 | 1 |
A 只观察了 48 小时，不能据此说 168 小时内都没有故障。B 的 0 有两个依据：追踪完整、记录核实完毕。不能仅因记录为空就按 B 的情况处理。
C 的故障发生于 9 月 2 日 14:00，确认于 9 月 4 日 15:00。后来确认为故障，不表示 9 月 3 日当时也已有确认标签；应保留当时等待确认的历史状态。反过来，9 月 4 日已经确认窗口内至少发生一次故障，因此无需等满七天即可将 C 确认为 1。这取决于目标是“期间内至少发生一次故障”。
计数为零也需要观察范围¶
P3-5.7的后续事件聚合可以把至少一次故障汇总为 1。但目前收集到的故障记录为零，并不等于整个窗口都没有故障。报告可能尚未到达，追踪也可能存在空缺。
要确认为 0，必须完成规定期间的全部观察，没有追踪遗漏或待处理报告，并通过必要的故障及维修记录确认期间内没有目标故障。即使日期已经过去，依据不足时仍应保留 ?，并写明缺少的记录。这里确认的 0 也只表示这七天没有故障，不表示以后永远不会故障。
分别确认结果与观察是否完成¶
flowchart TD
A[确定该样本的观察期间] --> B{是否已确认期间内发生目标事件?}
B -->|是| C[记录阳性标签 1]
B -->|否| D{全程观察与结果核实是否都已完成?}
D -->|是: 确认未发生| E[记录已确认阴性标签 0]
D -->|否| F[保留待确认或观察未完成状态]
先检查期间内是否已确认目标故障；若尚未确认，再检查完整期间的观察和记录核实是否都已完成。因此 C 可以在窗口结束前成为 1，而 A 不会仅因当前没有故障记录就成为 0。
| 应保留的记录 | 具体内容 |
|---|---|
| 样本与结果定义 | 设备 ID、预测时点、failure-v1、窗口起止及端点包含规则 |
| 发生与确认时刻 | C：failure_occurred_at=2026-09-02 14:00 KST，label_observed_at=2026-09-04 15:00 KST |
| 追踪范围与依据 | A 仅追踪到 9 月 3 日 10 时；B 已完成整个窗口的追踪与记录核实。保留原始记录 ID 和遗漏区间 |
| 状态与未确认原因 | label_status、pending_reason；区分期间未完成与报告等待核实 |
| 确认 0 的依据 | negative_is_complete：B 为真；A 和确认前的 C 为假；阳性已确认的 C 不适用 |
| 判定历史 | 保留每次判定时的状态，并关联后续确认的理由与依据 |
这里将 label_observed_at 定义为确认标签在系统中变得可用的时刻；尚未确认时留空。分开发生和确认时刻，才能在事后构建训练表时，避免把当时未知的结果混入输入。
亲自判断终点与记录遗漏¶
练习：① 如果 B 缺少 9 月 6 日记录，且无法通过其他依据补全，9 月 8 日 11 时还能保留 0 吗？② 故障恰好发生于 9 月 8 日 10 时，是否属于本窗口的阳性？③ 如果 C 的故障直到 9 月 9 日才确认，会变成窗口外故障吗？
解答：① 未能核实完整期间，应保留 ? 和遗漏原因。② 终点不包含，因此不属于本窗口的阳性。但这并不自动得到 0，仍须完整核实终点之前的窗口。③ 发生时刻仍是 9 月 2 日，所以属于窗口内故障；可在 9 月 9 日确认为 1，并保留此前等待确认的状态。
检查清单¶
- 能否用发生与确认时刻解释同一个 C 为什么从
?变为 1？ - 能否区分 A 的故障记录零条与 B 的确认结果 0？
- 能否应用端点包含规则及追踪、核实完成条件，不把未确认填成 0？
来源与参考资料¶
- NIST/SEMATECH，Censoring。用于区分规定的测试期间及期间内的故障记录。本节七天二元标签和确认状态表是教学应用案例。确认日：2026-09-20。
- W3C，PROV-Overview。参考其追踪原始记录、处理、版本及派生关系的观点。确认日：2026-07-20。