先日参加したYANS2018では、アノテーションツールであるdoccanoの紹介を行いました。doccanoを改善していくためにアノテーションについての意見を色々お聞きしたのですが、やはりさまざまなつらみが浮き上がってきました。
本記事では、YANS2018で寄せられたアノテーションのつらさを体系的にまとめます。これはdoccanoの改善に活かされますが、アノテーションを実施する機会がある方にとっても事前に問題となる箇所を把握できる記事になっていると思います。
アノテーションのプロセス
アノテーションの意見をまとめる観点として、今回はMATTERを使用しました。MATTERとは、Model、Annotate、Train、Test、Evaluate、Reviseの頭文字を取ったものです。このプロセスはNatural Language Annotation for Machine Learningで提示されているプロセスです。アノテーションを行う方は事前に目を通しておくとよいと思います。
- Model: アノテーションデータを使って何をしたいのかというゴールを明確にし、そのために必要なラベル情報を定義する。Modelにおける成果物は、アノテーション仕様書になる。
- Annotate: アノテーション仕様書に則り、アノテーションを行う。Annotateにおける成果物は、もちろんアノテーションデータとなる。
- Train/Test: アノテーションデータを使い機械学習モデルを学習させ、評価メトリクスの計測を行う。
- Evaluate: アノテーションについての問題点を洗い出し、対応策を検討する。
- Revise: Evaluateの結果に基づき、アノテーション仕様書の修正を行う。この後、Modelに戻り再度Annotateを行う。
要は、いわゆるPDCAサイクルを回そうという話です。
アノテーションのしやすさ自体は、ユーザーインタフェースの改善で対応が可能です。しかし、Annotateは上述の通りアノテーションにおける一部分の問題でしかありません。そのため、意見をうかがう際はAnnotate単体だけでなくその周辺のタスクについてもお聞きし、その結果をまとめていきました。
アノテーションにおける課題
ここでは、寄せられた意見の傾向から見てアノテーションに必要な対策を紹介したいと思います。MATTERの観点別に分けた、意見一覧は末尾に掲載しています。
アノテーション定義書には事例を含めるべし
アノテーション定義書には、「xxの場合yy」という定義だけでなく、具体的な事例を掲載しておく方が好ましいです。具体的な事例はアノテーターの判断を助けるだけでなく、それ自体がアノテーターのアノテーション精度を測るための質問に使えたり、チュートリアルを作る場合チュートリアルに使えるためです。個人的な経験からしても、なぜこのようなアノテーションルールが生まれたのか？という根拠となるケースを残しておくことは後で見返す際にも有用です。
アノテーターへの意思伝達を設計せよ
アノテーション定義書が複雑な場合(ルールやページ数など)、それは基本的には読まれないという前提を置いたほうが賢明です。そのため、事前説明会の開催やスライド形式での表示、アノテーション中の参照を可能にするなど、アノテーターへの意思伝達をどう行うのかが重要となります(中には、アノテーターを採用している機関もありました)。これには、アノテーターへの報酬額といったインセンティブ設計も含まれます。
評価に必要な情報は、アノテーション中に計測すべし
アノテーション中に様々なデータを取っておくことで、アノテーションの評価が行いやすくなります。具体的にはアノテーションにかかった時間、アノテーションをつけなおした回数、アノテーションに対する確信度、コメントなどです。こうした情報は、アノテーションデータだけからノイズなどを判断するよりリッチなフィードバックを提供してくれます。アノテーターの評価については、ヒューマンコンピュテーションとクラウドソーシングでも解説がおこなれているため、目を通しておくとよいです。
これらの対策については、doccanoの中でサポートすることも含め検討していく予定です。
寄せられた意見一覧
このセクションでは、MATTERの観点で寄せられた意見をまとめていきます。一部ユーザーインタフェースに関するものもありますが、そのまま掲載しています。
Model
- アノテーションしている最中に修正したくなるため、仕様書に影響があるようなケースについては後で見返せるようにチェックをつけたい。
- アノテーション定義(ルール)からまとめてアノテーションを行いたい(文中にxxとyyが含まれるものは～など)。※これはなるほどなと思いました。また、似た研究が存在します: Training Classifiers with Natural Language Explanations
- PDFデータをアップロードするだけでテキスト化して欲しい。
Annotate
- アノテーションさせる前にトレーニング（チュートリアル）させたい。仕様書の理解を深め質を上げるため。
- アノテーション仕様書はみんな読まないので、ツールチップなどで説明を表示するようにしているが、表示が煩雑になり難しい(特にタグの数が多いと)。
- アノテーション仕様書をスライド形式で出すようにするなど、読みやすく表示できるとよい。
- アノテーションを行う際、アノテーションごとにラベルの位置を変えているので、その機能があるといい。ラベル位置が固定だと、最初のラベルを連打するような行為が見られた。
- 確信度を入力できるようにしたい。判断に迷ったものをあとで見返せるようにするため。
- コメントを残しておきたい
- アノテーターを集めるのが難しい(知り合いに頼むのがせいぜい)
- アノテーターに修正を依頼できるようにしたい
- リアルタイムに質問できるチャット機能などがあれば、アノテーターをサポートしやすいかもしれない。
- たくさんのタグがある場合(20~)UIがつらい。タグに階層関係があることがあるので、それを表現したい。
- 単語間の関係をアノテーションする場合は、表示が煩雑になり難しい。
- 固有表現認識で、1Entityに複数のタグをつけたい場合がある。
- アノテーション対象が動的に変わるケースに対応してほしい(検索結果の評価を行うケースなど)。
- VQA(画像に対する説明記述)に対応してほしい。自然言語単独では応用は難しくなってきている。
Train/Test
- Learning Curveから必要なデータ量を判断できれば良いが、どれだけのデータがあれば学習できるかは事前にはわからない。そのためクラウドソーシングで発注する場合は多めに発注することが多い。
Evaluate
- 業務ユーザーの判断をアノテーション結果とする場合、業務ユーザーの判断はアノテーション定義書に沿って行われるものではない。そのためノイズが多いが、最終的に模倣したいのは業務ユーザーの判断。人の判断か、アノテーション定義を優先すべきなのかが難しい。
- アノテーションにかかった時間などを計測して適当につけたのかどうか判断したい。ただ、アノテーションに慣れたからなのか適当なのかわからない。
- アノテーションにかかった時間、アノテーションをし直した回数などを計測して、アノテーションの正確性計測に役立てたい
- 適当にアノテーションしているか判断したい。最初から適当なケースもあるが、最初は慎重だけど徐々に適当になることもある。
- 特定の質問に正確に答えられたユーザーだけアノテーターとして採用するようにしたい
- 優秀なアノテーターに再度発注したい
- アノテーター同士がアノテーション結果を評価しあう仕組みを導入する
- データを作成する発注以外に、作成されたデータを修正する発注をクラウドソーシングで行うことがある。
- κ統計量など、アノテーションで必ず測る指標は自動で計算してほしい。
その他
- アノテーションではセンシティブなデータを扱うこともあるので、セキュリティ対策も必要
- アノテーターに賃金を支払うシステムなどと連携できるとよい
- モデルの予測結果や、アノテーション済みデータを読み込んで表示したい。
これらの意見が、皆さんの研究で行うアノテーションの改善にも役立てば幸いです。
