为什么注释指南失败
大多数注释项目都是从一个简短的文档开始的——有时是一个段落，有时是一个幻灯片——试图描述正确的注释是什么样子的。注释者在入职期间读过一次，就不再读了，然后在遇到意外情况时即兴发挥。
其结果是标签不一致，并大规模加剧。一个模糊的边缘情况，由 10 个注释者对 100,000 张图像进行不同的处理，会产生一个数据集，该数据集向模型传授关于模型最需要正确处理的确切场景的错误信息。
各个项目的失败模式是一致的：没有错误的示例（只有正确的示例），没有边缘情况的决策树，在项目中规则更改时没有版本控制，并且在注释者不同意时没有升级路径。解决这些问题并不困难——它只需要使用应用于任何其他生产规范的相同工程学科来处理注释指南。
第 1 部分：任务定义和范围
在任何标签说明之前，指南必须回答注释者会默默询问的两个问题：这些数据最终用于什么，以及完整的注释是什么样的？
任务定义不需要解释整个人工智能系统。它需要为注释者提供足够的上下文来做出一致的判断。与只知道自己正在绘制矩形的注释者相比，了解边界框将为仓库机器人训练对象检测器的注释者将对部分可见的对象做出不同且更好的决策。
- 用一句话陈述最终用例：“这些注释将训练一个模型来检测 ADAS 系统人行横道上的行人。”
- 定义注释单元：什么构成一个完整的注释？单个图像？视频帧？文档页？
- 定义范围内和范围外的内容：“注释框架内可见范围超过 50% 的所有行人。不要注释人体模型、雕像或倒影中的人物。”
- 说明最低完整性要求：在什么情况下返回的图像或项目没有注释（损坏的文件、无法识别的内容）？
第 2 部分：具有精确定义的标签分类法
每个标签类都需要一个没有解释空间的定义。目标是让两个注释者独立阅读指南，以对任何给定项目达成相同的标签决策。
精确的定义需要对每个类别进行正向（包括什么）和负向（排除什么）规范。仅依赖肯定的定义可以保证边缘情况的不一致。
- 使用视觉类卡：每个标签类一张卡，包含类名称、定义、纳入标准、排除标准和 3-5 个示例图像。
- 明确定义类边界：如果将产品状况注释为“新的/类似新的/二手的/损坏的”，请尽可能使用数字标准准确定义符合每个级别的条件。
- 在分类中包括故意的困难案例：在生产开始之前识别 5-10 个最常混淆的类对，并添加明确的消歧规则。
- 避免定性语言：“光线充足的图像”不是一个定义。 “拍摄对象的面部完全可见且阴影覆盖面部区域 30% 以上的图像”。
第 3 部分：视觉示例 – 正面和负面
没有视觉示例的文本定义不足以完成任何涉及图像、视频或空间数据的注释任务。人类视觉系统处理示例的速度比文本描述更快、更准确，并且两种模式一起产生比单独使用任何一种模式更好的一致性。
最重要的例子是反例——看起来应该以某种方式标记但实际上不应该这样的图像。注释者从正确拒绝的边缘情况中学到的东西比从直接的正面例子中学到的东西更多。
- 每类设置的最小视觉示例：3 个清晰的正面示例，2 个边缘正面示例（包括解释），2 个清晰的反面示例，1 个边缘负面示例（不包括解释）。
- 显示图像上渲染的注释，而不仅仅是原始图像 - 注释者需要看到预期的输出，而不仅仅是输入。
- 尽可能使用您的实际数据作为示例。库存图像向注释者介绍库存图像，而不是他们实际遇到的数据分布。
- 当注释者出现新的边缘情况时更新示例 - 示例集应该在整个项目中不断增长，而不是从第一天起就保持静态。
组件 4：边缘情况决策树
任何注释指南中最有价值的组成部分是边缘案例决策树。它也是最常被省略的组件。如果没有它，注释者会做出单独的判断，从而在整个团队中产生不一致的结果。
构建决策树需要在生产开始之前主动识别不明确的场景。与 3-5 个注释者一起运行 50-100 个项目的小型预试点，识别注释者不同意的每个案例，并将每个分歧添加到决策树中并做出已解决的裁决。
- 结构决策为二元分叉：“对象是否部分被遮挡？如果是 → 可见度超过 50%？如果是 → 注释。如果否 → 跳过。”
- 对于医学或法律注释，包括“咨询领域专家”分支，而不是要求注释者做出临床或法律判断。
- 为决策树节点分配唯一的 ID，以便注释者可以毫无歧义地引用和讨论特定规则（“根据规则 DT-14，这应该被排除”）。
- 将决策树的版本与主要指南文档分开，以便可以跟踪更改并将其传达给团队，而无需重新发布完整的文档。
第五部分：质量标准和自检协议
注释指南应包括注释者在提交每批之前遵循的明确的自检协议。自检清单将质量从注释者完成的事情（QA 审查）转变为注释者完成的事情（首过质量）。
自检不需要详尽无遗——每批的时间不应超过两分钟。其目的是在最常见的错误类型复合之前捕获它们。
- 类完整性：是否已标记每个所需类的所有实例，包括小的或部分可见的实例？
- 属性覆盖：如果需要多属性标注，是否每个标注对象都填写了所有必需的属性？
- 边界精度：对于边界框或多边形，边界是否遵循实际对象边缘而不是粗略近似？
- 与最近项目的一致性：当前项目是否遵循与前 10 个项目相同的约定？如果没有，为什么不呢？
- 标记了不确定的项目：是否有任何需要判断的项目被标记为进行 QA 审查而不是默默地解决？
组件 6：版本控制和更改通信协议
生产项目的注释指南是动态文档。数据分布发生变化，模型反馈揭示了系统性标签错误，客户在更好地理解数据时改进了需求。如果没有版本控制协议，指南更改会导致无声的不一致，而事后几乎不可能进行调试。
每个注释项目都应将指南视为版本化文档，与软件 API 具有相同的严格性。重大更改（任何影响过去注释的不同标记方式的内容）需要迁移计划，而不仅仅是更新通知。
- 语义版本控制：主要版本（1.0 → 2.0），用于需要重新注释的重大更改；次要版本 (1.0 → 1.1) 用于澄清或不更改现有标签的新示例。
- 更改日志：为每个版本维护一个更改日志条目，列出更改的内容、原因以及受影响的标签类。
- 注释者通知协议：所有注释者必须确认收到新版本，然后才能恢复受影响任务类型的生产工作。
- 追溯影响评估：对于每个主要版本变更，评估哪些先前完成的批次需要重新注释，并将成本包含在变更单中。
与 IAA 试点验证您的指南
在启动任何生产注释运行之前，请通过注释者间协议 (IAA) 试点验证指南。让 3-5 名注释者使用当前指南独立标记同一组 200-300 个项目，然后使用 Cohen 的 Kappa 或 Krippendorff 的 Alpha 衡量一致性。
Kappa 分数低于 0.75 表明该指南对于生产来说还不够精确。确定配对一致性最低的特定项目——这些是您的指导差距。解决它们，更新指南，然后重新运行试点。在所有关键标签类别的 Kappa 超过 0.80 之前，不应开始生产。
此过程使项目启动时间增加 3-5 天。通常可以节省项目中期 3-6 周的返工时间。
