P3-9.4 复核结果如何从复核备注变成目标标签候选¶
Section ID:
P3-9.4Version:v2026.07.20
即使复核候选队列（review queue）和比较报告（comparison report）先出现，目标标签候选（target candidate）通常也不会被立即给出。最开始留下来的，往往不是整洁的正确标签，而是各种各样的复核结果和复核备注。因此，把目标标签候选读成一开始就给定的答案并不准确，更准确的读法是：它是把复核过程中反复留下来的判断，转成更稳定列之后得到的结果。
为什么一开始只会留下备注¶
一开始留下来的往往不是正常、异常、原因 A、原因 B这样整理好的标签，而更容易先留下像下面这种杂糅的复核备注。
| event_id | review_needed | reviewer_note |
|---|---|---|
| A | 1 | 确认后段急跌模式，下一条也需要确认 |
| B | 0 | 与基线没有明显差异 |
| C | 1 | 重复下降，建议进一步检查 |
这张表对后续判断是有用的，但还不够稳定，不能立刻拿来当学习标签。因为备注长度不同、表达方式不同，有的人会写原因，有的人只会写下一步动作。所以，有复核备注和目标标签已经准备好不是同一句话。
从备注变成标签候选，还需要什么¶
如果复核备注要变成目标标签候选，通常还需要下面这些条件。
| 还需要的东西 | 为什么需要 |
|---|---|
| 能反复指向同一意义的共同规则 | 因为必须把不同人写的不同表达归到同一个判断里 |
| 与样本单位相匹配的记录方式 | 因为要对齐备注到底对应单个事件还是区间摘要 |
| 对空白情况的处理规则 | 因为要决定没有备注的案例怎么放 |
| 以后还能回查的依据列 | 因为需要追踪这个标签为什么会被附上 |
也就是说，要把复核结果变成学习标签，关键不只是有值，而是要先有一套把同样意义留在同一列里的规则。
复核队列和标签候选表的差别¶
复核候选队列的中心是先看什么，而标签候选表的中心是以后想预测什么。即便面对同一个事件列表，表的中心也会不同。
| 产物 | 中心问题 | 先需要的列 |
|---|---|---|
| 复核候选队列 | 人应该先看什么 | priority_score、review_needed、比较依据 |
| 目标标签候选表 | 什么可以成为结果列 | target_candidate、依据备注、特征列 |
例如，在复核队列里，review_needed = 1 可能就够用了。但在目标标签候选表里，更重要的是：review_needed = 1 是在什么条件下被附上的，以及以后能不能按同样规则再附一次。
一步一步变化的过程¶
同一个事件列表通常会按下面顺序变化。
- 先在比较报告里看到变化信号。
- 再在复核候选队列里生成由人先看的顺序。
- 把人留下的复核结果反复积累起来。
- 把经常重复的判断整理成共同列。
- 如果这些列变得相对稳定，再把它们提升成目标标签候选。
这个顺序重要，是因为它说明：目标标签候选不是凭空冒出来的，而是来自复核过程中的重复。
例子：从复核备注生成标签候选¶
最开始，备注可能是下面这样杂乱的。
| event_id | diff | repeatability | review_needed | reviewer_note |
|---|---|---|---|---|
| A | -0.35 | high | 1 | 后段急跌重复，需要复查 |
| B | -0.08 | low | 0 | 仅保留记录 |
| C | -0.31 | high | 1 | 后段急跌重复，建议检查 |
在这种状态下，很难把 reviewer_note 直接当成目标标签来用。相反，可以把重复表达重新整理成更稳定的列。
| event_id | late_drop_repeated | needs_manual_review | note_source |
|---|---|---|---|
| A | 1 | 1 | 后段急跌重复，需要复查 |
| B | 0 | 0 | 仅保留记录 |
| C | 1 | 1 | 后段急跌重复，建议检查 |
第二张表之所以重要，不是因为句子完全消失了，而是因为重复出现的判断被搬到了具有相同意义的列里。如果保留 note_source，以后也还能回过头去追踪这个标签候选为什么会被附上。
哪些列更容易先成为目标标签候选¶
并不是所有复核备注都同样适合作为目标标签候选。
| 更容易先成为候选的东西 | 还比较困难的东西 |
|---|---|
像 review_needed 这样会反复出现的 0/1 判断 | 整段很长的自由叙述备注 |
像 late_drop_repeated 这样能以相近意义反复附上的判断 | 不同人使用不同名字的原因描述 |
像正常/注意这样有相对共同标准的状态 | 没有详细 taxonomy 的原因分类 |
因此，更容易先被结构化的，通常是是否需要复核、是否存在重复告警、简单状态区分这类列。更细的原因分类往往会更晚才稳定。很多时候，target 并不是原本就躺在数据集里的，而是在 comparison report 和 review queue 的过程中，把积累下来的判断重新转成列之后才得到的。也就是说，这里更重要的判断是：它是否还该继续留在自由备注里、能不能提升成共同判断列、以及是否已经重复到足以成为目标标签候选。
用一个小图来看¶
flowchart TD
A[复核队列结果<br/>event_id + review_needed + review note]
A --> B[自由文本备注逐渐累积]
B --> C[共享备注模式<br/>重复出现的 late drop<br/>只记录]
C --> D[目标候选列]
D --> D1[late_drop_repeated]
D --> D2[needs_manual_review]
D --> D3[note_source]
这张图说明，自由备注不会直接变成 target，中间一定会经过把相同意义归并起来这一层。先是复核结果和备注积累起来，然后从备注中整理出反复出现的判断模式，最后才出现像 late_drop_repeated、needs_manual_review 这样的列。这里重要的不是字符串处理技术，而是备注 -> 共同意义 -> 标签候选列的转化结构。因此，target 不应被读成突然被给定的值，而应被读成复核记录被结构化之后的结果。目标标签候选往往不是一开始就给定的答案，而是把复核过程中反复留下的判断转成更稳定列之后得到的结果。
来源与参考资料¶
- Google, Machine Learning Glossary,
label,labeled example。用于确认在监督学习里，标签和已标注样本如何把输入特征与结果列分开。 https://developers.google.com/machine-learning/glossary / 确认日: 2026-07-20 - W3C, PROV-Overview: An Overview of the PROV Family of Documents, provenance, entity, derivation overview。用于确认 provenance 视角：从复核备注到共同意义、再到目标候选列的路径应保持可追踪。 https://www.w3.org/TR/prov-overview/ / 确认日: 2026-07-20