こんにちわ。鈴木です。

久しぶりの投稿です。
前回はプロダクトにおけるAI活用というお話でした。
今回は、とあるゲームの事前登録サイトにDialogflowを利用したチャットボットを導入した事例をご紹介します。

先日、発表用にまとめたスライドがあるので、お時間ある方はご覧ください。

 

Dialogflowについて

Dialogflowは、Googleがサポートしている自然言語処理系APIサービスです。

MLベースとルールベースのハイブリットモデルで文章分類と、登録したレスポンスを返すことができます。
意図しない分類がされた場合でも、正しい正解ラベルを紐づけて再学習させることで、APIの精度をあげることができます。

 

他サービス検証

下記が、Dialogflow導入に至る際にサービス検証したグラフです。

• ライブラリなどを利用して一からアルゴリズムを実装する「DL/MLライブラリ」
• ある程度パッケージ内で実装が担保された「NLPモジュール」
• 学習済みのモデルのAPIベースで呼び出せる「APIサービス」

に大きくパターンを分けることができます。

 

この中で、今回Dialogflow導入に至ったのは、下記の理由になります。

導入スピード面

• APIサービスのため学習データ抽出・ラベル分類コストも必要最低限
• 既存のMLライブラリを利用する場合の実装コストが発生しない

料金面

• スタンダード版は無料で利用できる
• 必要に応じて、エンタープライズ版でAPI制限の緩和などが可能

精度面

• 会話データのラベルミスを修正して再学習させることができる
• 内部に多くの拡張機能があり、表現ゆれ解決や外部連携なども可能

 

事前にユーザの会話を予測して、ある程度のインテントとレスポンスを用意する必要はありますが、
独自でモデル実装する際のデータ準備工数と比較したら、かなり削減できていると感じています。

 

システムケーススタディ

今回導入したチャットボットを例に、

• 実際にDialogflowで利用しているシステム紹介
• Dialogflowでカバーできない範囲のクラウド連携部分

をご紹介します。

 

システム構成

ざっくりと今回のチャットボットは
お客様との会話を通してNPCの親密度が上昇して、一定の閾値を超えると事前報酬のシリアルを受け取れるという仕組みでした。

上記の仕様を含めて、今回のAPIはこのようなシステム構成となりました。

先ほどのチャットボット仕様と突き合わせると
Dialogflowで対応した箇所と、AWSで対応した箇所は下記のようになります。

 

Dialogflowのシステム紹介

上のグラフを見ても分かるように、

Dialogflowのサービスで担保できない部分（チャットボットの感情表現・親密度蓄積・報酬hook処理・IP制限など）は、クラウド側に寄せています。
その際に、DialogflowのFulfillment機能や、事前にクラウド側でAPIをラップする処理が重要になっています。

Dialogflowの基本的な機能はスライドのP24-28に紹介しています。

 

会話精度向上に向けて

次に、会話の精度向上に向けた対応を紹介します。

まずチャットボットの会話精度に注力した背景ですが、
サービスの会話継続率を検証した結果、
ユーザーの会話精度が低いと、離脱してしまう確率が3割程度上がってしまうため、
会話精度の改善に力を入れていました。

 

スコア結果

会話精度を10%ごとに集計した結果、精度が100%のものと、精度が悪いものに二極化しているのが分かります。

会話の詳細を見ていくと、
スコアが良かったインテントは、単純な挨拶や単語が多く、
登録したUser Saysとのルールベース合致が多いことが分かりました。

スコアが悪かったインテントは、やや柔軟な会話が要求される場面が多く、
文章全体の意味合いは違いますが、登録したインテントと部分的に一致してしまって分類されているパターンや、
単純にインテントに類似した文章の登録がないパターンが多いことが分かりました。

 

対応内容

今回は、会話精度向上のため主に下記の3つの対応を実施しました。

登録Intentsの拡張

• 殆どの場合は例文の追加で解決できた
• ユーザの会話ログから、頻度の高い例文を新しく追加していく

登録Entitiesの拡張

• 表現ずれの改善のため、Entityにデータを追加していく

TrainingでIntents学習

• 以前の会話やり取りが間違っていた場合には
  DialogflowのTraining機能から正しいIntentsを学習させる

 

注意点としては、下記を見ていました。

登録する例文の基準

• IntentsやEntitiesには登録できる上限があるため
  精度が低い全ての会話を登録できるわけではないこと

優先度の基準

• 例文内容の検討やTrainingによる学習には人的コストがかかるため
  全体のリソースを考慮した優先度を決めておくこと
• ここでは会話精度にフォーカスしたが
  チャットボットの事業目的に会話精度の重要度がどの程度あるか

分析結果と対応した内容はスライドのP32-40に紹介しています。

 

まとめ

メリット・デメリット

Dialogflowでチャットボットを導入してみて、以下のポイントを感じました。

メリット

導入コストの低さ

• 実装コストの削減
  • ML/DLライブラリを利用する場合と比較して、既存のAPIサービスを利用すれば自然言語処理部分の実装コストがほぼかからない
• データ準備の削減
  • 学習データ用のチャットやSNSから大量のログ抽出作業を減らすことができる
  • 合わせて、それぞれの学習データの分類ラベリング作業が削減できる

デメリット

アルゴリズムのブラックボックス化

• 内部の実装がブラックボックス化しやすい

サービス安定性

• フリー版はAPIの停止や、利用上限が設定されているケースがある

 

所感

今回は導入コスト重視のプロジェクトだったこともあり、Dialogflowを利用して正解だったと振り返っています。

一番の大きなメリットとしては、自然言語処理の実装コストと学習データの準備コストが大幅に削減できたことでした。
確かにAPIサービスだと、あるインテントの会話精度が低い場合の前処理の工夫や、特定の文字列が入った場合のモデル調整など、拡張要素部分で痒いところもあるかもしれませんが、今回のプロジェクトの場合は、必要に迫られる場面はありませんでした。

必要に応じて、クラウド側で独自のモデルと組み合わせることもできますし、外部拡張ができるのはありがたいところです。
基盤はAPIサービスで、特定の会話精度が出ないインテントだけラップするような処理が、導入コスト面でも精度面でもいいのかもしれませんね。

今後も機会があれば、導入事例の紹介をしていければと思います。
それでは、Happy Hacking :)