アルパカのメモ

Adaptive Dialog とは

calendar_today

はじめに

参考：

ボットとユーザーの会話は Dialog を使って実装するが、会話の複雑さが上がるほど中断とか分岐とか考慮しなくてはいけないことが増え、実装が大変になる。 それを解決するために新しく追加されたのが Adaptive Dialog らしい。 いままでの Dialog の実装方法と異なり、「宣言的」に定義できるのが特徴で、ソースコードでも実装できるが json ファイルに定義することもできる。 また、Bot Framework Composer も、この Adaptive Dialog の考え方を元にしているようにみえる。

前提条件

  • 現在.NET版のBot Framework SDKでのみ使用可能。
  • Bot Framework V4 SDK の Dialog の基礎知識
  • Bot Framework V4 SDK の Prompt の基礎知識

Adaptive Dialog の構造

Trigger

参考：

Adaptive Dialog には、Trigger と言われるイベントハンドラのリストを定義する。 Trigger には Condition (条件) と Action (処理) を定義する。 Trigger のリストを上から順にたどっていって、Condition が合っていると Action が実行され、それ以降の Action は実行されない。 なので、リストの最後には、どの条件にも引っかからなかった場合の処理を用意しておくのが良いっぽい。 下記サンプルの OnUnknownIntent の部分がそれにあたる。

public RootDialog() : base(nameof(RootDialog))
{
    Triggers = new List<OnCondition>
    {
        new OnConversationUpdateActivity()
        {
            Actions = WelcomeUserSteps()
        },
        new OnUnknownIntent
        {
            Actions =
            {
                new SendActivity("Hi, we are up and running!!"),
            }
        },
    };
}

Action

Action は、Trigger の条件が合致したときに行う処理を定義する。 それぞれのステップをメソッドで定義する Waterfall Dialog とは違い、Adaptive dialog の Action は Dialog クラスを拡張したもののリストである。 これにより Adaptive Dialog をより強力で柔軟にしつつ、中断や分岐などの管理を容易にする。

Bot Framework SDKは、たくさんのビルトインActionを提供している。例えば、メモリの生成、ダイアログ管理、会話フローの制御などである。 Actionは拡張可能で、自分のカスタム Action を作成できる。

Actionの詳細は、Actions in adaptive dialogs を参照。

Input

Input は Adaptive Dialog 用の Prompt である。Input は、ユーザーへ情報をリクエスト＆検証するために、Adaptive Dialog で使える特別なActionである。 すべての Input クラスは、下記の機能がある。

  • ユーザーへプロンプトする前に、その情報をボットがすでに持っているかどうかをチェックする。
  • 入力が想定通りの形式である場合に、指定されたプロパティへ値を保存する。
  • 制約を使える。最小、最大など。

Inputの詳細は、Asking for user input using adaptive dialogs を参照。

Inputs in adaptive dialogs - reference guide - Bot Service | Microsoft Docs

Generator

Language Generator は、ボットからのメッセージをテンプレート化したものである。 いくつかの候補からランダムで発言したり、条件式などを指定できる。

Recognizer

Recognizerは、ユーザーの発話からインテント(意図)を取り出すのに使う。 例えば、LUIS を使ってインテントが見つかるかどうか検証したり、QnA Maker に答えられる質問かどうかを検証したりする。 Recognizer が発話から意図を見つけると、トリガーの OnIntent が発生する。

Recognizer には下記の種類がある：

  • RegexRecognizer - 正規表現を使い、ユーザーの入力からインテントを見つける。コード上で設定が済むので、LUISを使うほどでもない場合はこれを使うと良い。
  • LUIS recognizer - LUIS を使い、ユーザーの入力からインテントを見つける。Azure の同サービスが必要。
  • QnA Maker recognizer - QnA Maker を使い、ユーザーの入力が QnA Maker に答えられる質問かどうかを検証する。Azureの同サービスが必要。
  • Multi-language recognizer - 言語ごとに Recognizer を指定できる。
  • CrossTrained recognizer set - 複数の Recognizer の設定を学習し、会話の中断などを制御しやすくする。
  • RecognizerSet - 複数の Recognizer を使うときに使う。

メモリのスコープと State の管理

参考：

Adaptive Dialog では、State への読み書きも簡易になっている。State にはいくつかのスコープがあり、User State であれば user.xxxx といった具合にアクセスできる。 以下にスコープの一覧を示す：

  • User scope (user) - 会話に参加したユーザーごと。
  • Conversation scope (conversation) - 会話ごと。
  • Dialog scope (dialog) - ダイアログごと。そのダイアログのが終わるとメモリが消えるかもしれない(未確認)。
  • Turn scope (turn) - ターンごと。
  • Settings scope (settings) - 設定値。appsettings.json とかの設定値を取得できる。コード上で書き込むことは少ないと思われる。
  • This scope (this) - その Action クラスのプロパティを取得できる。Input アクションを使用するときによく使ったりするらしい。
  • Class scope (class) - アクティブなダイアログのプロパティを取得できる。

Declarative assets

Adaptive Dialog を拡張して、自分でカスタマイズしたdialogクラスを作成できるが、それとは別に、JSONファイルを作って Adaptive dialogを拡張できる。 ソースコードは必要なく、両方のアプローチを一つのボットに入れられる。

Using declarative assets