【de:code2018 AI03】AI活用の一歩を踏み出したい皆様に贈るCognitive Service & Bot Framework 初めてみた物語

このセッションはチャットボットを開発した3社の事例紹介です。

こちらがこのセッションの目的とゴールです。

この3つの開発事例が紹介されました。個人的に注目したのは②ですね。自社にも取り入れられる要素がありそうです。

チャットボットと一言で言っても系統が異なるため、各事例がどの分野のチャットボットなのかを示したものになります。

こちらはCongnitive Serviceが提供している機能の一覧です。

元々はMicrosoft Cognitive Serviceという名前でしたが、今回の発表からAzure Cognitive Serviceに変わり、赤文字の機能が新たに追加された。

これがAzureを使用してボットを作成する際に使用可能なフレームワークと、必要な技術です。

Azureでは自然言語解析用のAPIとして2種類提供されています。

まずは最初の事例です。ジブヤクハックとは渋谷区の自治体ハッカソンのことのようです。

この事例では、渋谷ダンジョンと呼ばれている渋谷駅内から出口までの経路案内を目指したものです。特にバリアフリーに対応した出口というのは限られており、さらには最近再開発で通行不可な場所が多いため、脱出するためのアプリを作ることを考えたそうです。

元々やりたかったのは、現在地から目的の場所に行きたいときに一番適切な「出口」まで経路案内することでした。

ただ、3Dでの案内なのか、２Dでの案内なのかとか、現在地と言っても階層が分からなかったりとか、予想以上にいろいろと考えるポイントが多かったようです。

なので、改めて整理をして、バリアフリー化している一番近い出口に絞って考えたそうです。まずは外に出ないことには目的の場所に行けないということで。

AzureのBot Serviceは基本的にブラウザ上でポチポチとやって、テキストを入力することで作成可能です。

今回のボットはQnA Makerを使ったようです。これはキーワードとその答えが自動的にDBにたまっていくので、非常にお手軽です。

実際に今回のアプリケーションにプラスアルファで実装までされたかどうかは聞き取れなかったのですが、画像認識のCustom Visionにも取り組まれているようです。

例えば、区役所にカメラを設置して混雑具合を判断したり、物体検知を使ってごみのポイ捨てを可視化したりすることに使用しようとされているようです。

Machine LearningやDeep Learningを知らなくても作成することが可能だということが分かりました。また、実際に触れることで、リアルな実感がわくため、悩む前に触ってみるべしとのことでした。

2つ目の事例は、HITACHIの新人研修でチャットボットを作成したという話です。

もともとは社内のPoCとしてやろうとしていたようですが、上司から「そんなことをやってお金になるのか？」と費用対効果を求められたため撃沈したので、人材育成を口実にコスト削減も可能なので新人研修でおこなったそうです。

ボットは社内向けとし、勤怠管理システムを対象としたようです。

実際のアーキテクチャがこちらです。

単純にボットを作成するだけでなく、後から精度向上のために会話ログをデータとして保存もしておくようです。キーワードの抽出にはText AnalyticsのAPIを使用しています。

自然言語処理にText Analyticsを使用を使用したのは、QnAでは柔軟性がなく、LUISほどはなくても良いということのようです。

1Sprint2週間のサイクルを5回行い開発を行ったようです。

ただ、実際には3周目ほぼ完成し、残りの2回は精度向上や利用率UPのために費やしたようです。

初版は単純に1つの質問に対して1つの答えを返すというものでした。ただ、これだとユーザが何の登録が出来ないといっているのかわからないため、見当違いな回答をしている可能性があります。

そこで、誤回答も想定し、絞り込みが確実にできない場合は、このように選択肢を与えてユーザを誘導できるよう考えられたようです。

実際の運用では、よくある質問のTOP5で全質問の15％程度をカバーできることが判明したので、まず最初に、ボタンを配置してメニューを作成したようです。

ユーザはどちらかのボタンを押して問い合わせを開始します。

ここからは精度向上のための工夫を行っていったようです。

前回よりもボタンが増えています。

最後の周ではボタンが縦に配置されています。これは横に並べていた場合、ユーザがボタンがあることを認識していなかったケースがあったようです。

確かに、横に並べるより縦に並んでいたほうが見やすいですね。

品質の評価としては2つの軸を設定したようです。

• 会話フローの網羅率
• 正答率

会話フローは全てのフローを実施していることをテストで確認したようです。

正答率については、テスト入力の場合は想定された入力しかしないため高めに設定しており、ユーザ入力についてはこれくらいの正答率があったら「使える」と判断できそうだということで設定されたようです。(ぶっちゃけそこまで明確なものがあるわけではなく、感覚的なもの)

結果としては、どちらも目標値を上回ることができたようです。

会話フローはボットを作成する際にとても有効なものです。このフローを作成し、すべてを網羅するテストを行うことで、実行率100%の確認をしたとのことです。

正答率の向上を行うために、FAQのテーブルで、FAQとキーワードを登録するという作りにしておきます。

そして、1つのFAQに対して、5件のテスト入力文を作成します。

この時、キーワードが1個以上含まれた文を3件、キーワードが全くない文を2件与えます。

与えられた文からキーワードを抽出し、そのキーワードと入力文を検索クエリとします。

.さらには、キーワードには同義語を設定し、読み替えができるように修正します。

この3と4を繰り返すことで正答率を上げていったそうです。

正答率の向上を目指いしていたときに、カタカナは弱いということが分かったようです。なので、同義語とFAQのキーワードに英単語化して登録するということを行ったようです。

1つだけわからなかったのは、キーワードだけでなく、入力文そのものもクエリにいれることで正答率が上がるという部分です。キーワードが大事だと思っているので、これはわかりませんでした。

まとめとして、チャットボットには明確な要件がないことが多いです。また、妥当性は検証するまでわからないことが多く、ユーザがどんなことを入力するのか、すべてを想定することは難しいと思っています。なので、できるだけ早く作り、早く公開して使って貰ってもらうことが重要そうでした。

 

SHARPの開発事例です。

ダイキン工業向けに作成したようです。もともとダイキンがボットに興味があったため、話してみたら作ってみることになったそうです。

分析部分がいくつかありますが、おおむね一般的なチャットボットのアーキテクチャだと思います。

このボットでは、LUISを使用しているようですが、使用するのは最初のみ。

以降はボタンを配置して選択肢を置いておくようにしたようです。

さらに、発話内容をマスタ化して登録しておくことで、正答率を上げようとしているようでした。

一番注目すべきなのは、「1つ戻るボタン」の存在です。

通常チャットボットはシナリオの「先頭」に戻ることは簡単でも「１つだけ」戻るというのは標準でも提供されていません。今回は1から考えて実装したとのことです。

チャットボットが取得したデータはこのようにまとめ、次のアクションを決めるために活用可能なようです。

チャットボット導入後はWEBの利用が2倍に向上したようです。

チャットボットはたくさんのユーザに使っていただき、成長させていくことが大事です。PDCAを回していきましょうということでした。