アノテーションを終え、ラベルをエクスポートし、ファイルを引き渡します。半年後、誰かがそれでモデルを学習させ、奇妙な結果を得ますが、問題が自分のモデルにあるのかあなたのデータにあるのかを判断できません。誰がアノテーションしたのか、どうサンプリングされたのか、ラベルが何を意味するはずだったのかを、誰も書き残さなかったからです。ラベルは、それを解釈可能にしていた文脈よりも長く生き延びてしまったのです。これは絶えず起こっていますが、プロジェクトが新鮮なうちに書けたはずの文書化によって、ほぼ完全に防げるものです。

データセットの信頼性は、その文書化の質を超えることはありません。データステートメントは、データ収集の根拠、言語とその話者、アノテーターとそのデモグラフィック属性、ガイドライン、想定される用途を記録し、下流の利用者がラベルがどこまで一般化しどこで一般化しないかを判断できるようにします。後回しにせずデータと並行して書けば、そのほとんどはすでに実施したアノテーションプロジェクトから自然と得られます。本稿は、何を文書化すべきか、そしてPotatoの設定がそのかなりの部分をすでにどう捉えているかについてです。

文書化されていないデータが招くコスト

2つの問題が現れ、どちらも後になって高くつきます。

1つ目は再現性の欠如です。サンプリング方法、ガイドラインのバージョン、アノテーターのプールがなければ、誰もあなたのデータセットを再構築できず、それに対する食い違いを説明することもできません。データは、盲目的に信頼するか捨てるかしかないブラックボックスになってしまいます。

2つ目は隠れたバイアスです。偏ったアノテーターのプールから得たラベルで学習したモデルは、そのプールの盲点を受け継ぎます。プールが一度も文書化されていなければ、そのバイアスは本番環境で表面化するまで見えません。これはまさに、文書化のフレームワークが防ぐために生み出された失敗です。データセットの「誰が」と「どのように」を読み取れるようにし、出荷される前にバイアスを見えるようにするのです。

データステートメントが扱うもの

データステートメント（Bender and Friedman, 2018）は、NLPに特化した答えであり、結果がどう一般化しうるか、データがどんなバイアスを帯びているかを利用者が理解できるよう、言語データセットを特徴づけるためのスキーマです。書き残す価値のある項目は次のとおりです。

データ収集の根拠。 データセットに何が含まれ、なぜそうなのか、そして項目がどうサンプリングされたのかを含みます。1つのサブレディットから選んだサンプルは、代表性のある抽出とは別のデータセットであり、その根拠を述べる場所がここです。
言語のバリエーション。 単なる「英語」ではなく、具体的な言語と方言です。あるバリエーションで作られたモデルは、別のバリエーションで失敗しうるからです。
話者のデモグラフィック属性。 元テキストを生み出したのは誰か。
アノテーターのデモグラフィック属性。 ラベルを生み出したのは誰か。主観的タスクではこれが決定的です。アノテーターのプールの構成がラベルを形づくるからであり、これこそそもそもデモグラフィック属性を収集する理由そのものです。
アノテーションガイドライン。 ラベルが作られる際に従った指示です。同じラベル名でも、ガイドラインが異なれば意味が変わります。
想定される用途。 データセットが何のためのものか、そして同じくらい有用なこととして、何のためのものではないか。

データステートメントの構造：データ収集の根拠、言語のバリエーション、話者のデモグラフィック属性、アノテーターのデモグラフィック属性、アノテーションガイドライン、想定される用途の各セクションを持つ文書化カード。それぞれが、下流の利用者が本来なら推測するしかない問いに答える。データステートメントは誰がどのようにを記録し、下流の利用者がラベルの一般化する範囲を判断できるようにする

データシートとモデルカード

隣接する2つのフレームワークがこれを補完します。データセットのためのデータシート（Gebru et al.）は、あらゆる部品がデータシートを添えて出荷されるエレクトロニクス業界からこの発想を借りています。すなわち、あらゆるデータセットは、その動機、構成、収集プロセス、推奨される用途、保守をカバーする文書を添えて出荷されるべきだ、というものです。データステートメントは言語に特化した従兄弟であり、データシートは汎用版で、両者は大きく重なります。

データの下流に位置するのがモデルカード（Mitchell et al., 2019）で、これは学習済みモデルの想定される用途と、デモグラフィックその他のグループ別に分解した性能を文書化します。この3つは連鎖をなします。データシートまたはデータステートメントがデータを文書化し、モデルカードがその上に構築したものを文書化し、そして前者のアノテーターのデモグラフィック属性のセクションが、後者のグループ別評価を解釈可能にします。アノテーションをきちんと文書化すれば、あなたはすでに、説得力あるモデルカードへの道のりを半分まで来ているのです。

公開前チェックリスト

公開する前に、次の問いに答えられることを確認してください。

項目はどのように、どこからサンプリングされたか。
これはどの言語のバリエーションで、元テキストを書いたのは誰か。
誰がアノテーションし、何人が関わり、プールのデモグラフィック構成はどうなっているか。
彼らはどのガイドラインに、どのバージョンで従ったか。
不一致はどう扱われたか。ゴールドラベルへ集約したのか、それとも分布として残したのか。いずれにせよ一致を報告すること。
このデータセットは何のためのもので、何に使うべきでないか。

答えのない問いがあれば、それは公開後ではなく公開前に埋めるべきギャップです。

Potatoでの実践

Potatoでアノテーションを実施することの有用な点は、データステートメントの多くがすでにプロジェクトの成果物として存在していることです。文書化を白紙から始める必要はありません。

設定そのものが文書化です。YAMLはアノテーションスキーム、ラベルの集合、タスクの構造を記録するため、データステートメントの「ラベルは何で、どう定義されたのか」の部分が、データと並んでバージョン管理されます。アノテーションガイドラインに書き込んだ指示とガイドラインは、そのままガイドラインのセクションになります。

デモグラフィック属性はすでに収集されています。事前調査フェーズを実施していれば、アノテーターのデモグラフィック属性がアノテーターごとに保存されています。個別の記録ではなく分布へと集約すれば、それがアノテーターのデモグラフィック属性のセクションとなり、貼り付ける準備が整います。

エクスポートがメタデータを運びます。Potatoのエクスポート形式は、すべてのラベルにアノテーターとタイムスタンプを保持するため、来歴はエクスポートの段階で剥ぎ取られるのではなく、データとともに移動します。

json

{
  "id": "doc_001",
  "annotations": { "sentiment": "positive" },
  "annotator": "user_1",
  "timestamp": "2024-01-15T10:30:00Z"
}

Hubに公開する際は、HuggingFaceへのエクスポートのウォークスルーが示すように、エクスポートの一環としてデータセットカードを生成し、そのセクションを、すでに手元にある設定、ガイドライン、事前調査のデモグラフィック属性から埋めていきます。こうして文書化は別個の執筆作業ではなくなり、アノテーション作業の最後のステップになります。

次に読むもの

アノテーターのデモグラフィック属性を責任を持って収集する。アノテーターのデモグラフィック属性のセクションを正しく仕上げることについて。
不一致はノイズではなくシグナルである。不一致をどう扱ったかを文書化することについて。
効果的なアノテーションガイドラインを書く。これはそのままデータステートメントのガイドラインのセクションを兼ねます。
機械学習のためのアノテーションのエクスポート。ラベルとそのメタデータをきれいに取り出すことについて。