Slack のポストからQA情報を抽出してみるタスクの一環で、既存テキストのアノテーションが必要になったのでSageMaker Ground Truth を利用してみました。
動機と操作感の簡単な紹介、そしてアノテーション作業を延々やっていて感じたことなどを書いてみます。
※Ground Truthの使い方についてはあまり解説しません。それについては AWS SageMaker Ground Truthでテキストのラベリングを試してみる | Qiita の記事が詳しいので、そちらをご覧ください。
モチベーション
Slack に書かれた情報をソースの主として、「質問」に対して何かしらのアクションを行う Bot が作れないかと目論んでいました。
現時点でタスクは明確ではないので、とりあえずアノテーションしてみてから考えよう的なスタンスでやってます。PoCのような位置づけです。
Slackの文章は基本的に単発で情報量が少なめかつ表記ゆれなどの汚さがあります。また、QAとは関係のないノイズ情報も多く含まれる特性があります。そうした前提を考慮したとき、アノテーションとして質問／回答であるかのラベリングはやっておいて損はしないだろうと考えました
例えば、過去の類似質問をレコメンドする、という問題設定の場合、「今投稿された内容が質問の意図であるかどうか」や「過去の質問リストとの照合」が必要になりそうです。そうしたときに質問以外のものが混じるのはどう考えても悪影響がありそうだよな、と。
事前タスク
Slack のポストを収集して、それを Ground Truth の入力形式（マニフェストと呼ばれます）に適合するように変換してあげる必要があります。
詳しい仕様はドキュメントの 入力データ | Amazon SageMaker のセクションを確認ください。
レコード数や、1レコード数あたりの文字数に制限がありますのでそこだけ注意。今回はどちらも制限の範疇だったので特に考慮は不要でした。
Ground Truth
QAの判別がもっとも典型的かつ手間が少なそう、と思われたので、ラベルは
- Question
- Answer
- Other
の3つとしました。
次に、ジョブを作ってみました。自分自身をワーカーとしてアサインしています。右上の方に "Labeling portal sign-in URL" というやつがありますが、ワーカーはこのURLからアノテーションツールを利用することになります。Emailで招待することができ、初期パスワードと一緒に勝手にCognitoがメール通知してくれます。
ログインすると、今アサインされているジョブの一覧を確認できます。
"Start working" をクリックするとアノテーション作業を開始できます。
回答選択肢にはキーが割り当てられており、この場合は "Question" なら1を押せば選択状態になります。キーストローク少なめでアノテーションできるのは非常にありがたいですね。
選択したら、 Submit して次のレコードに移ります。（Submit は Shift + Enter で遷移できるようですが、私の環境ではどうも認識されませんでした...）
アノテーションを補助するツールとして最低限求めたいものは揃っている感じがしました。アノテーションツールは偉大ですね。。。ツールのない世界を想像するとゾッとします。データの規模が大きい場合は、自作してでもアノテーションツールを用意するメリットは高いと思います。
Ground Truth を試す前はアプリ開発の勉強がてら自前で作成しようかとも考えていたのですが、いったん機械学習のタスクを先に進めたかったので手間のかからないこちらを採用しました。
やってみて思ったこと
20,000件近くあるポストを全部人力でやるのはしんどすぎますね。もっと便利な方法があればよいのですが、まだ検討していません。
現在アノテーション済みは1,000件ほどに到達しましたが、その時点で思っていることを述べます。
とにかく困るのは「判断の線引き」に尽きると思います。
- 前後のやりとりの文脈が失われる
- 1レコード = ポスト単位で見ているので
- 「回答っぽそうだけど情報量が薄い」情報をどうするのか
- 「回答っぽそうだけどURLのリンクだけが提示されていて文章が極端に少ない」をどう扱うのか
- 質問との対応付けが今はできないので、これだけでは有用な情報にならないのでは？という懸念がある
- 「質問に対する質問者自身のリプ」と思しき内容をどう扱うか
- これは都度判断してます。さらなる質問に繋がる内容ならQuestion、回答情報を補強する内容ならAnswerに分類しています
- QAではないが、「共有情報」として案内されている有用そうな情報はどうするのか
- これの扱いはまだ悩んでます
上記のような課題に対して、考えたことは以下。
- （今思えば当然なのだか）応用タスクを「なんとなく」でしか考えてない状態では良いアノテーションはできない
- がっつりアノテーションに取り組むのは今回が初なので、アノテーション自体の知見を得る意義はあるから中断はしない方針
- ラベリングの線引きを考える上で、1,000件近くもやってると基準が途中でぶれてくる感覚がある
- こちらも、きちんと問題設定してなかったのが悪いなと反省
- 始める前もある程度の指針は想定していたつもりだったが、それでも大量の件数をこなしながら判断の一貫性を保つことは難しい感覚
- 1人でやっててもこの有様なので、複数名でアノテーションする場合はより顕著に解釈ゆれが発生するであろうことは自明で、解くべき問題のIn/Outをある程度明確にすることと、そのためにどのような情報を「有用」と定義するのか。基本思想は共有されてたほうがいいかなとは思う
また、アノテーションタスクのデザインはエンジニアリング要素を含むものだと思いますが、実際のアノテーション作業はそうではありません。私自身、面倒な単調作業は大嫌いなのでなかなかつらいものがあります。動くモデルもまだないので、このタスクがどの程度精度貢献したのか見えないってのも辛みがありますね。
さいごに：アノテーションタスクの外注について思うこと
アノテーションをどうデザインするのかはエンジニアリングの課題ですが、実作業はそうではありません。アノテーションタスクは外注できるのなら外注した方がよいと思います。。
幸い、Ground Truthには簡単な外注機能があります。しかしながら、上で述べたような「グレーゾーン」などの問題はいくらでも発生します。発注してから根本的なタスクデザインが失敗していたことがわかるようでは（コスト的に）まずいですね。
現場のエンジニアが、実際のデータである程度アノテーションしてみるフェーズは一度やっておいた方がよかろうと思いました。グレーゾーンに向き合わないまま発注しても、各作業者にその判断が転嫁されるだけであまりよいことはありません。むしろ「作業者の解釈」という新たなノイズが乗るリスクが高いです。
結局はデータを向き合う、という話に尽きるのですが、ある程度の数を自分でやってみることもかなり重要でしょうというのが私の感想です（特に、使っているデータがそもそもさほど綺麗でない場合は...）。
最終的な応用タスクのデザインを描いたり、グレーゾーンに対してどのように対応指針を描くのか、こうした検討は発注者として事前に理解していたほうが結果的にコスト効果の高い、よいアノテーションができると考えます。
以上です。あと19,000件頑張るぞ。。。。