前回はローカルデバッグの構成を行った後、シンプルな挨拶ダイアログを作成しました。今回は挨拶ダイアログを改良していきます。

自然言語処理を使ったトリガー

正規表現は、メールアドレスのチェックや電話番号のフォーマット確認を行うには強力ですが、ユーザーが入力した文章が挨拶かを判定するにはあまり向きません。

そこで今回は Azure の自然言語処理機能である LUIS を使ってユーザーの意図(インテント)を判定し、ダイアログをトリガーする方法を説明します。

Bot Framework は LUIS と統合されているため、LUIS の使い方を知らなくとも問題ありません。

トリガーの更新

1. メインダイアログより「Recognizer Type」を「Regular Expression」から「LUIS」に変更。

2. Hello トリガーを選択し「Expected responses」を挨拶を捉えてほしい例文を追加。応答の作成と同様、- (ハイフンと半角スペース) で始める。

Composer の設定の更新

1. Azure ポータルより「<ボット名>-luis-Authoring」を開く。

2. Key1 をコピー。

3. Composer の Settings より「Show keys」を有効にし、authorizationKey にコピーしたキーを張り付け。また defaultLanguage を「ja-jp」に変更。

変更の反映

1.「Restart Bot」をクリック。LUIS に変更したことから、LUIS の発行画面が表示される。設定したキーと言語が反映されていることを確認して「OK」をクリック。

2. ステータスが「Publishing..」になるので、終わるまで待つ。

3. LUIS ポータルにログインして、LUIS アプリができていることを確認。表示されない場合は、正しい Azure サブスクリプションとリソースが選択されているか確認。

4. Intents に「Hello」ができていることを確認。

5. 例文が Composer で設定したものが入っていることを確認。

テスト

LINE クライアントよりあいさつを送信。設定したものと微妙に異なっても問題ないことを確認。

期待した通りに動作しない場合は、トリガーに例文を追加してボットを再起動すると LUIS が更新されるため、色々試してください。

精度の設定

LUIS は登録したインテントの中から、ユーザーの入力の意図に近い可能性が高いものを返します。LUIS はインテントと同時に可能性をスコアで返すため、スコアを条件に入れて絞ることができます。

1. メインダイアログより Hello トリガーを選択。Condition に条件を追加。ここではスコアが 0.7 より大きい場合を条件に設定。

#Hello で Hello インテントの結果を取得
#Hello.Score でスコアを取得

2. スコアの結果は LINE では確認できないため、ボットを再起動後、エミュレータを起動。

3. エミュレーターより挨拶を送信し、「LuisV3 Trace」を確認。ここでスコアが確認可能。

より高度なダイアログ

ダイアログの重要な機能として、ユーザーに対して入力を要求する機能があります。

ユーザーに対して質問を送信
回答が期待した型か(文字列か、数字か、日付かなど) を確認
回答が期待した条件を満たしているか確認
期待と異なる場合にリトライの実行
期待した回答であった場合回答の記憶
最後の質問まで進む

ユーザーの回答を記憶する領域として Composer ではいくつかの「記憶領域」が用意されています。ここでは dialog 領域と user 領域を使用します。

dialog 領域: ダイアログが終わるとデータは消える
user: ユーザーに紐づいているためデータは残る

尚、クラウドに発行するとバックエンドとして Cosmos DB が使われるためサービスを再起動してもデータは失われませんが、ローカル開発中はデータはメモリにしかないため、ボットを再起動するたびにデータが無くなる点に留意してください。

ダイアログの更新

挨拶ダイアログに体調を聞く機能を付けてみましょう。

1. HelloDialog の BeginDialog を開く。

2. 挨拶の応答に続いて「＋」をクリック。「Ask a question」より「Number input」を選択。

3.「Bot Asks」に質問を入力。ここでは本日の体温を確認。

4.「User Input」を選択して「Property to fill」に「dialog.bodyTemperature」を設定。これでユーザーの回答が dialog 領域の bodyTemperature プロパティに保存される。

5.「Other」にリトライの条件を入力。

Unrecognized Prompt: 型が違う場合の応答メッセージ
Validation Rules: And 条件となる複数の条件。this.value でユーザーが入力した値を取得
Invalid Prompt: 条件を満たさない場合の応答メッセージ

6. 次に「Create a condition」より「Branch: if/else」を追加。

7. 条件に dialog.bodyTemperature>37.5 を指定。

8. True ブランチに「Ask a question」より「Multiple choice」を追加。

9. 質問を追加。

10.「User Input」で user.healthCondition を指定。

11. プロパティの下にスクロールして、選択肢を追加。また「Include numbers」と「Append choices」のチェックを外す。

エミュレーターでテスト

1. ボットを再起動して、エミュレーターで接続。

2. 挨拶を送信。

3. 条件に合わない値を送信して挙動を確認。

4. 38.5 を送った後、ボットの記憶域に dialog.bodyTemperature が無いことを確認。まだダイアログは続いているが、これ以降で使う場所がないため、削除済。

5. 任意の回答を選択。既にダイアログは終わっているが、user 記憶域にあるデータは残っていることを確認。

LINE でテスト

LINE はモバイルにしかない機能があり、複数選択の既定のオプションの場合、モバイルでしかうまく動作しません。

モバイルから接続して動作を確認。選択肢の表示のされ方を確認すると、オプションが出ます。

他のオプション

Confirm は表示の仕方を何パターンかから指定できます。

それぞれエミュレーターでは異なる表示をサポートしますが、LINE チャンネルが全てをサポートするわけではないので、色々試してください。

まとめ

今回はより高度なトリガーとして自然言語処理に対応したほか、ダイアログではユーザーとの複数回のやり取りをどのように記憶するかについて紹介しました。次回は文字列以外のデータの扱いを見ていきます。

次の記事へ