タイプミスや表現についてのアドバイスをいただきましたので修正しました。ありがとうございました。
#この記事で伝えたいこと
・Watson Knowledge Studio(WKS)でアノテーションを設定する作業手順のイメージ
・公開されているWKSのDocumentを前提に、日付抽出のための機械学習モデルを作成してWatson Natural Language Understanding(NLU)にデプロイすることにより、「Eメールに含まれる待ち合わせ日時を教えて！」という問い合わせを実現させることを意図した試行錯誤の経験
・単調なアノテーション作業が精神的に辛かったので、負担軽減のアプローチを考えてみたこと
#作業環境について
・Lenovo Thinkpad T440s、Win.7、Firefox 59.0.2(64ビット)、curl 7.59.0
#初めに
・WKSは、テキストアノテーション、およびテキストアノテーターの作成を行うWatson製品です。アノテーションとは、データに注釈となる情報をメタデータとして追加したり、そのようにして追加されたメタデータのことです。個人的な解釈としては、文章のニュアンス、意味、関係を理解した機械学習モデルを開発するためのツールです。
・WKSにおける「教師付きデータの作成作業」とは、モデルの元ネタとなるテキストファイル中の単語にアノテーションを追加していくことです。
・アノテーションの追加とは、文中の単語に属性を追加することであり、例えば"2018年4月14日"という単語には"DATE"という属性を割り当てることです。作業自体が苦痛で大変です(主観的な解釈と主観的な印象ですが)。
・WKSで機械学習モデルを作成し、Natural Language Understandings(NLU)に登録することで、NLUに対して、例えば、「この文章におけるDATEの属性をもつ単語を抽出してください」という問い合わせが可能になります。
・実際の作業では"DATE"という属性そのものを作成する必要があるのですが、WKSではテンプレートとなるべき属性が事前に準備されています。今回は、これを利用しています。
・"DATE"という属性とは、WKSではMentionと言われるアノテーションになります。その他にRelation、Coreferenceがありますが、この記事では扱いません。また、Mention自体も、Subtype、Role、などなどの詳細な構成がありますが、この記事では扱っていません。
#作業概要
・この作業では、WKSで日付抽出のための機械学習モデルを作成してNLUにデプロイすることにより、「Eメールに含まれる待ち合わせ日時を教えて！」という問い合わせを実現させることを意図していました。過去形なのは、このモデルが実際に有用か？、という疑問が解消されなかったからですが、この記事の目的は、WKSによる機械学習の手順を共有することですので、本来の意図は二の次です。全体的な流れは以下です。
1. 待ち合わせ日時を含む100件以上のメールを用意する
2. 最初に数十件程度でモデルを作成する
3. そのモデルにより残りのメールに対してプレアノテーションを実施し、その後に真面目にアノテーションする
4. Train and Evaluateする
5. NLUにデプロイするし、curlでNLUにクエリーを発行するし、そして、回答を得る
#作業の前に
二の次と言いつつ、ここでは機械学習モデルの有用性の判断について触れておきます。
WKSでは、Machine learning model creation workflowに記載されている手順に従って、Ground truth creation cycleという改善プロセスでmodelを作って、訓練して、評価を繰り返します。いつまで繰り返すかというと、WKSのConfusion Matrixに記載されているF1 scoreが、満足できるレベルになるまでです。
なお、F1 scoreはprecisionとrecallの調和平均となってます(precisionもrecallも割合なので加重平均ではなく調和平均です、中学生レベルの教養ですが、きれいサッパリ忘れてました)。定義はさておき、要は「このEメールに含まれる待ち合わせ日時を教えて！」というQueryに対して、得られた回答がどれくらいの割合で正しいのか？、を示す指標です。
話を戻します。満足できるレベルのF1 scoreは、モデルの用途に依存すると考えています。今回のような「メールを、人間がちょっとの手間をかけて読めば、待ち合わせ日時が含まれているならば、簡単に特定できる」とか「スマートスピーカーに音楽を流させる」といった単純な質疑応答では、結論として0.9以上が理想であると考えています。「正解どころか、Queryの定義が正しいかどうかすら怪しく、とにかく関連する情報は何でも欲しい」ような作業、例えば、「機械が正常動作しないが、原因も対応方法も不明、症状に関連する情報を探すしかない」とか「法律的なトラブルで、判例を探したり、反論を検討したい」といった複雑な質疑応答では、とりあえず、0.6以上であれば許容できるのではないでしょうか？
以下、ユーザーの立場での気持ちを表に整理してみました。要は、単純な作業ほど、期待されるF1 scoreの値は高くなる、ということを伝えたいのです。
| F1 score | 単純な作業 | 複雑な作業 |
|---|---|---|
| 0.5以下 | 10回質問すると(対応を依頼すると)、5回正しい回答を得る(対応を得る)。2回続けて正しい回答を得られなかったら、自分でやったほうが確実だ、そんな難しい作業じゃないし。 | 単純な文字列検索と同程度。わざわざ、AIとして投資・開発するメリットが見えない |
| 0.6~0.8 | 10回質問すると(対応を依頼すると)、6~8回正しい回答を得る(対応を得る)。2回続けて正しい回答を得られなかったら、自分でやったほうが確実だ、そんな難しい作業じゃないし。 | 単純な文字列検索よりは良い。わざわざ、AIとして投資・開発するメリットがある。 |
| 0.9~1 | 10回質問すると(対応を依頼すると)、ほぼ毎回、正しい回答を得る(対応を得る)。時々、ダメな場合があるが許容できる | エクセレント！ |
今回のケースでは、DATEのF1 scoreは、約150件のメールをアノテーションし0.78まで到達しましたが、有用性の観点では疑問です。また、「今から」、「明日」などの日時指定の扱いも課題となりました(これらの相対的な日時を意味する単語に対してDATEという属性を割り当ててることは可能ですが、ユーザーが必要なのはyyyy/mm/dd形式などの絶対的な日時なので、機械学習による抽出後に、現在日時などから推定する必要があり、WKS＋NLUでは完結しない、という課題がありました)。さらに追加で数百件のメールをアノテーションすれば、満足できるレベルのF1 scoreになったかもしれませんが、工数は有限で、作業期間は決まっているため、プロジェクトは終了となりました。
余談ですが、上記の表の単純な作業の場合の説明は、昨今、流行しているAIスピーカーに音楽の演奏や照明のON/OFFを依頼した時の経験に基づいています。照明OFFを音声で依頼する場合、そもそも、活舌良く「電気消して、トリガー」と発声するか、リモコンを探すか、で前者の方が後者よりも幾分かマシだから選択する程度の動機で前者を選択しているので、2回続けて対応がチンプンカンプンだったら、面倒でも自分の手でリモコンを使ってOFFにします。そして、結果として、よほど気分が良い時以外は、AIスピーカーに照明ON/OFFを頼むことはなくなるでしょう。F1 scoreを高めるためには大量の教師付きデータを準備する必要があるため、この種の簡単なお仕事を確実に実行させることは、それなりに大変だと思います。
次に続きます。