現実に対応できるアノテーションルーブリックの書き方

ルーブリックはなぜ失敗するのか？

定義が間違っているからではほとんどありません。定義は問題ないがエッジケースが欠けているため、20人のアノテーターが同じ未解決の質問に対して20通りの異なる答えを独自に考え出すからです。

最も一般的な症状は、データの特定の部分が静かに無価値である一方で、全体的には合意スコアが許容範囲に見えることです。集計された合意はこれをうまく隠します。

ルーブリックのどれくらいをエッジケースにすべきか？

ほとんどです。ルーブリックが主に定義で、最後に短い例のセクションがある場合、それはルーブリックではなく用語集です。

生産的な書き方は、仕様が不十分なルーブリックで小規模なパイロットバッチを実行し、アノテーターが曖昧だと指摘したすべてのケースを収集し、それぞれを明確なルールに変えることです。パイロットの目的はデータを生成することではなく、質問を見つけることです。

なぜルーブリックを固定するのか？

基準がバッチの途中で変わると、古い定義の下で正しく完了した作業が遡及的に間違いとなり、どのバージョンでどの項目が判断されたかデータセットからはわからなくなるからです。

固定するということは、バッチが始まるときに有効なバージョンがそのバッチを支配することを意味します。改善は次のバッチに適用されます。すべてのラベルには、それを生成したバージョンが付与されるため、1年後に誰かがなぜ2つの類似した項目が異なるラベルを持っているのかを尋ねたときにデータセットを監査可能にします。

指摘された曖昧さはどのように処理すべきか？

それが何であるかというと、ルーブリックに関する欠陥報告として扱います。推測せずに指摘するアノテーターは、まさに正しいことをしており、それに対して罰せられるべきではありません。

指摘を罰するプラットフォームは、指摘が減り、データが悪化します。なぜなら、曖昧さは消えず、誰にも見えないところで静かに一貫性なく解決されるからです。

良いアノテーションルーブリックとは何ですか？

エッジケースの明確な処理です。アノテーターは明確な例についてはほとんど意見が一致するため、定義が主でエッジケースが少ないルーブリックは一貫性のないラベルを生み出します。

プロジェクトの途中でルーブリックを変更すべきですか？

いいえ。バッチが始まるときに固定し、基準が変わらないようにします。改善は次のバッチに適用します。そうしないと、正しく完了した作業が遡及的に間違いとなります。

アノテーターが曖昧なケースを指摘した場合、どうすべきですか？

それはルーブリックの欠陥として扱い、明確に解決すべきです。指摘を罰すると、曖昧さは地下に押し込まれ、一貫性なく解決されます。