ダイアログマネージャ

ダイアログマネージャ(DM) は、ダイアログ システム(DS)のコンポーネントであり、会話の状態とフローを管理します。通常は次のようになります。

• DM への入力は人間の発話であり、通常は自然言語理解 (NLU) コンポーネントによってシステム固有の意味表現に変換されます。たとえば、フライト プランニング ダイアログ システムでは、入力は「ORDER(from=TA,to=JER,date=2012-01-01)」のようになります。
• DM は通常、システムに応じて、ダイアログ履歴、最新の未回答の質問など、いくつかの状態変数を維持します。
• DM の出力は、ダイアログ システムの他の部分への指示のリストであり、通常は「TELL(flight-num=123,flight-time=12:34)」などの意味表現で表されます。この意味表現は通常、自然言語生成 (NLG) コンポーネントによって人間の言語に変換されます。

非常に異なる役割を果たすさまざまな DM が存在します。 1 つの DS に複数の DM コンポーネントが存在する場合もあります。

すべての DM に共通する唯一の点は、DS の他の部分 (NLU や NLG コンポーネントなど) が単なるステートレス機能であるのに対し、DM はステートフルであることです。DM の役割は、おおまかに次のグループに分けられます。

1. 入力制御により、人間の発話のコンテキスト依存処理が可能になります。
2. 状態に依存したテキスト生成を可能にする出力制御。
3. 戦略的なフロー制御。ダイアログの各ポイントでダイアログ エージェントが実行すべきアクションを決定します。
4. 戦術的なフロー制御。これは、いくつかの戦術的な会話の決定 (エラー処理、イニシアチブ制御など) を行います。

人間の入力は、コンテキストに応じて意味が異なります。たとえば、旅行計画 DS では次のようになります。

• コンピューター: どこから出発しますか?
  • 人間: テルアビブ。
• コンピューター: どこに到着したいですか?
  • 人間: ガザ。

都市名の意味は、以前に尋ねられた質問によって異なります。DM はその質問を状態変数に保持し、それを使用して「テルアビブ」を「テルアビブから出発したい」に変換したり、「ガザ」を「ガザに到着したい」に変換したりできます。

この関数は、NLU と DM の境界上にあります。Milward (2000) のコンテキスト依存ルールなど、一部のシステムでは NLU に含まれますが、 Mirkovic と Cavedon (2005) のNP 解決モジュールなど、他のシステムでは DM に含まれます。

NLU と DM の間のもう 1 つの機能は、どの入力発話が単一の発話の一部であるかを判断することです。以下は、ジョブ ネゴシエーション ダイアログの例です。

• 私は20,000NISの給料を提示します
• そして車
• 年金の条件は後で決定される

これら 3 つの発話は、実際には 1 つのオファーです。2 番目の発話では、「and」という単語が手がかりになりますが、3 番目の発話では、2 番目の発話の直後に発話されたということだけが手がかりになります。これを理解するには、DM は各発話のタイムスタンプを保持する必要があります。

ダイアログ履歴を記憶することで、コンピュータ出力をより自然なものにすることができます。たとえば、NPCEditor (人間の質問に答えるキャラクターを作成するためのフレームワーク) を使用すると、作成者は質問と回答のペアを定義でき、各質問に対して複数の回答の可能性があります。DM は、すでに使用されている場合を除き、質問に対する最適な回答を選択します。すでに使用されている場合は、2 番目に適切な回答を選択します。

ChatScript (チャッターボットを作成するためのフレームワーク) にも同様の機能が存在します。DS が特定のルールを使用するたびに、DM はこのルールを「使用済み」としてマークし、再度使用されないようにします。

最近の技術支援用の DS ^[要出典]では、高度な機械学習ルールを使用して、アイテムの説明に最適な用語を選択します。たとえば、DM が大人と話していることに気付いた場合は、「左手」などの用語を使用し、子供と話していることに気付いた場合は、「時計を着ける手」などのあまり専門的でない用語を使用します。

この機能は DM と NLG の境界にあります。

DM の主な役割は、ダイアログの各ポイントでダイアログ エージェントが実行すべきアクションを決定することです。

これを実現する簡単な方法は、作成者がダイアログ構造を完全に指定できるようにすることです。たとえば、チュートリアルのダイアログ構造の仕様は次のようになります。

• コンピュータ：「電子にはどのような力が作用しますか？」
  • 人間：「電気の力」。
    • コンピュータ:「正解」
    • [次の質問へ進む]
• コンピュータ: 「質量にはどのような力が作用しますか?」
  • 人間：「電気の力」。
    • コンピュータ：「不正解です。質量には電荷がありません」。
    • [電気に関するチュートリアルへ]

DM はスクリプト内の現在の位置へのポインタを保持します。位置は人間の入力に応じて更新されます。

作成者がダイアログ構造を指定できる言語やフレームワークは多数あります。たとえば、VoiceXML (音声ダイアログ用に最適化)、AIML、Facade、ChatScript (チャットボット用に最適化)、CDM (Java ベース、デバイス制御ダイアログ用に最適化)、TuTalk (チュートリアル ダイアログ用に最適化) などです。

さらに、ダイアログ構造は、 SCXMLなどの標準言語を使用して、状態チャートとして記述できます。これは、DomainEditor (戦術的な質問キャラクターのフレームワーク) で行われます。

作者が完全なダイアログ構造を記述するのは非常に面倒です。作者がより高い抽象レベルでダイアログを記述できるようにする多くの改善点がありますが、DM の負担は大きくなります。

Ravenclaw (CMU コミュニケータに基づく目標指向ダイアログの DM) を使用すると、作成者は次のような高度なマルチレベルのダイアログ構造を記述できます。

• 部屋予約タスク:
  • ログイン
    • ユーザー名を尋ねる
    • ユーザーのパスワードを尋ねる
  • 部屋の選択
    • 建物の選択
    • 部屋番号の選択
  • 時間選択
  • 仕上げる

Ravenclaw DM はダイアログ モジュールのスタックを保持し、それを使用して人間の入力を処理します。

この構造によりコードの再利用が促進され、たとえばログイン モジュールを他のダイアログで使用できるようになります。

また、動的なダイアログ タスク構築も可能になると主張しています。この構造は事前に固定されているわけではなく、バックエンドから選択された情報に基づいてオンザフライで構築されます。たとえば、航空機の整備員がメンテナンス タスクを実行する際に支援するシステムでは、ダイアログの構造はメンテナンス タスクの構造に依存し、動的に構築されます。

ChatScriptなどのチャットボットのフレームワークでは、トピックを使用して会話の構造を制御できます。作成者は、トピックをキャプチャするルールを作成できます。

• トピック: 子供時代 (子供 男の子 女の子 幼い)
• t: 私は幸せな子供時代を過ごしました。
• t: でも、早く終わってしまいました。
• ...

人間が括弧内の単語の 1 つを言うと、DM はトピックが「子供時代」であることを記憶します。チャットボットは、ボットが会話を制御している限り (ユーザーは「OK」や「そうだね」などと言って受動的に応答します)、「子供時代」というタイトルでストーリーを語り始めます。ユーザーが質問した場合、システムは直接応答するか、いずれにしても話す予定だったストーリーの行を使用することができます。

これにより、作成者はトピックを再利用し、複数の独立したトピックを組み合わせて、よりスマートなチャッターボットを作成することもできます。

ダイアログ システムは、フォームの代わりとしてよく使用されます。たとえば、フライト予約エージェントは、人間がこれらの 4 つのスロットがあるフォームに入力するのと同じように、出発地の時間と場所、目的地の時間と場所を人間に尋ねます。

簡単な解決策は、システム主導型を使用することです。システム主導型では、ダイアログ システムが各情報を順番にユーザーに尋ね、ユーザーはその正確な順序で情報を入力する必要があります。次のダイアログ (David Traum によるプレゼンテーションより) をご覧ください。

• フライト確認システムへようこそ。フライト番号は何ですか?
  • 8月8日、ロサンゼルス発ユナイテッド航空123便
• 出発地はどこですか?
  • ロサンゼルス、8月8日に言ったでしょ
• 申し訳ありませんが、わかりません。出発地はどこですか？
  • 8月8日にロサンゼルスを出発します。
• 出発日はいつですか？
  • 聞いてないよ！8月8日！
• 出発日を教えてください。
  • 8月8日
• ユナイテッド航空123便は8月8日午後2時にロサンゼルスからロンドンに向けて出発することが確認された。

システム主導の反対はユーザー主導であり、ユーザーが主導権を握り、システムはユーザーの指示に応答します。

2 つの方法の一般的な妥協案は混合主導型です。これは、システムが質問することから始めますが、ユーザーが割り込んで対話の方向を変えることができる方法です。システムは、ユーザーがまだ質問されていない詳細について話した場合でも、ユーザーの話を理解します。

しかし、このようなシステムを手動で状態チャートとして記述するのは、人間が最初に出発地を言い、次に目的地を言うか、またはその逆になる可能性があるため、非常に面倒です。それぞれのシステムにおいて、人間が最初に時間を言い、次に場所を言うか、またはその逆になる場合があります。

そのため、ダイアログ作成者が正確な順序を指定せずに、必要な情報だけを述べることができる DM があります。たとえば、作成者は次のように記述できます。

• 旅行 = {出発地、出発時刻、目的地、目的地時刻}

DM は、どのスロットがすでに埋まっているか、どのスロットがまだ空いているかを把握し、会話を進めて不足している情報を収集します。たとえば、DM は最初に人間に出発地について質問しますが、人間が目的地を追加した場合、DM はその情報を保存し、再度質問することはありません。

このような DS はMITで開発されました。たとえば、Wheels (中古車広告の検索用)、Jupiter (天気予報の取得用) などです。

シンプルな DM は、スロットの埋め方を 2 進法で処理します。つまり、スロットが「埋められている」か「空」かのどちらかです。より高度な DM は、グラウンディングの度合い、つまり、ユーザーの発言を本当に理解したかどうかの確信度も追跡します。つまり、「最近紹介された」、「再度紹介された」、「認識された」、「繰り返された」などです。また、作成者が、情報ごとに、理解する必要がある度合いを指定できるようにすることもできます。たとえば、機密情報には高い度合いが必要です。DM はこの情報を使用して、対話の進行を制御します。たとえば、人間が機密性の高い主題について何かを言った場合、理解したかどうか確信が持てない場合、DM は確認の質問をします。Roque と Traum (2008) を参照してください。

Trindiプロジェクトで開発された TrindiKit DS を使用すると、複雑な情報状態を定義し、この状態を処理する一般的なルールを記述できます。ルールの例を次に示します。

統合する回答:
  前提条件: (「人間が現在議論中の質問に適切な回答をした場合...」)
    in(SHARED.LM、回答(usr、A))
    fst(SHARED.QUD, Q)
    関連する回答(Q, A)
  効果: (「...次に、それを議論中の質問から削除し、共有の基盤に追加します」)
    ポップ(SHARED.QUD)
    減らす(Q, A, P)
    追加(SHARED.COM, P)

DM は、入力と状態に応じて、どのルールが適用可能かを決定し、それを適用して新しい状態を取得します。

これは、ダイアログ理論に基づいて、ダイアログ管理ルールの一般的なルールを再利用するために作成者に役立つ可能性があります。TrindiKit で開発された DS には、GoDiS、MIDAS、EDIS、SRI Autorate などがあります。

情報状態アプローチは、後に Siridus ( Wayback Machineで 2012-03-23 にアーカイブ)や Dipper ツールキットなどのプロジェクトで開発されました。

情報状態ベースのダイアログ マネージャーのもう 1 つの例は、FLoReS です。これは、命題情報状態を使用して現在の状態をエンコードし、マルコフ決定プロセスを使用して次のアクションを選択します。このダイアログ マネージャーは、jmNL ソフトウェアに実装されています。

このアプローチを一般化すると、作成者がエージェントの目標を定義し、DM がその目標を達成するための計画を立てるようになります。計画は操作で構成されます。各発話行為は操作です。各操作には、前提条件と事後条件(効果) があります。例:

知らせる(話し手、聞き手、述語):
  前提条件: Knows(Speaker,Predicate) AND Wants(Speaker,Inform(Speaker,Hearer,Predicate))
  効果: 知っている(聞き手、述語)
  本文: 信じる(聞き手、望む(話し手、知っている(聞き手、述語)))

会話は、SOAR (強み、機会、願望、結果) などの一般的なプランナーを使用して進めることができます。プランナーは現在の状態を維持し、指定された操作を使用して目標を達成するための計画を構築しようとします。

同様のアプローチはSASO-ST ^[1]（マルチエージェント交渉トレーニング用DS）でも採用されています。SOARを使用すると、複雑な感情モデルや社会モデルを組み込むことができます。たとえば、エージェントは人間の行動に基づいて、人間と協力するか、回避するか、攻撃するかを決定できます。

同様のアプローチがTRIPS ^[2]（マルチエージェント協調問題解決のためのDS）でも採用されています。TRIPSでは、ダイアログ管理をいくつかのモジュールに分割しています。

• 参照マネージャー- 単語 (例: 「女性」) が与えられた場合、それが世界のどのオブジェクトを参照するかを決定します (例: 「WOM1234」)。
• タスク マネージャー- ユーザーが達成しようとしている問題解決行為を識別します (新しい目標の作成、既存の目標の拡張など)。
• 通訳マネージャー- 最初の 2 つを呼び出すことに加えて、「最新の質問に応答する」などの談話義務も識別します。
• 行動エージェント- ユーザーが望む目標を達成する方法を決定します。エージェントは、実際の計画を実行するタスク固有のエージェントをいくつか採用します。

別の種類の計画は定理証明です。ダイアログは定理を証明する試みとして説明できます。システムはユーザーと対話して「欠けている公理」を提供し、証明の完成を支援します (これは「後方連鎖」と呼ばれます)。このアプローチは次のように実装されました。

• 文法的枠組み。^[3]
• IPSIM (Interruptible Prolog SIMulator)、Circuit Fixit システム内。^[4]

ダイアログ マネージャーをエキスパート システムに接続して、特定の専門知識で応答できるようになります。

ダイアログの一般的な構造と目標に従うことに加えて、一部の DM は、会話の質に影響を与えるローカルな決定など、戦術的な会話の決定も行います。

ASR モジュールと NLU モジュールは通常、ユーザーを 100% 理解したとは限らず、理解の質を反映した信頼スコアを返します。このような場合、DM は次のことを行うかどうかを決定する必要があります。

• 最も可能性の高い解釈が正しいと仮定して会話を続ける（無確認）。
• 会話を続けますが、「わかりました。レストランに行きたいのですね。具体的にはどこですか?」など、理解していることを示す言葉をいくつか追加します (暗黙の確認)。
• ユーザーが何を言おうとしていたのかを具体的に尋ねます (明示的な確認)。「X のことですかね?」「X とおっしゃいましたか、それとも Y とおっしゃいましたか?」など。
• ユーザーに「理解できませんでした。もう一度言ってください」と伝えます。

「確認なし」を選択すると、ダイアログはより速く進む可能性がありますが、後で修正するのに時間がかかる間違いが発生する可能性があります。

エラー処理は Ravenclaw によって徹底的に研究されており、これにより作成者はダイアログの各部分でエラー処理戦略を手動で制御できます。

一部の DS には、複数の操作モードがあります。デフォルト モードはユーザー主導型で、システムは「ご用件は何ですか?」と尋ね、ユーザーが会話を進めることができます。これは、経験豊富なユーザーに適しています。ただし、ユーザーとシステムの間に誤解が多い場合は、DM が混合主導型またはシステム主導型に切り替えることを決定する場合があります。つまり、ユーザーに明確な質問をして、一度に 1 つの回答を受け入れます。

別の種類の戦術的決定は、Cordillera (TuTalk を使用して構築された物理学の指導用チュートリアル DS) によって行われます。レッスン中の多くの時点で、DM は次のことを決定する必要があります。

• 生徒に何らかの事実を伝えるか、あるいは誘導的な質問をして生徒からその事実を引き出そうとするか。
• 生徒に答えの正当性を説明するよう求めるか、または説明をスキップして続行するかを指定します。

これらの決定は学習の全体的な質に影響を及ぼし、学習前と学習後の試験を比較することで測定できます。

人間の専門家に複雑な決定ルールのセットを書かせる代わりに、強化学習を使用する方が一般的です。ダイアログはマルコフ決定プロセス(MDP) として表されます。これは、各状態で、状態と各アクションから得られる可能性のある報酬に基づいて、DM がアクションを選択するプロセスです。この設定では、ダイアログの作成者は報酬関数のみを定義する必要があります。たとえば、チュートリアル ダイアログでは、報酬は学生の成績の増加です。情報検索ダイアログでは、人間が情報を受け取った場合の報酬は正ですが、ダイアログの各ステップに対する負の報酬もあります。

次に、RL 技術を使用して、各状態でどのような確認を使用すべきかなどのポリシーを学習します。このポリシーは、後で DM によって実際のダイアログで使用されます。

このテーマに関するチュートリアルは、Lemon と Rieser (2009) によって執筆されました。

対話ポリシーを学習する別の方法は、オズの魔法使いの実験を使用して人間を模倣することです。この実験では、人間が隠された部屋に座って、コンピューターに何を言うべきかを指示します。たとえば、Passonneau ら (2011) を参照してください。

• Traum、2008: ダイアログ システムとダイアログ管理へのアプローチ - 講義ノートと参考文献。
• Allen 他、2001 年: 会話型人間とコンピュータの相互作用に向けて。複雑性による DM のレビュー: 有限状態、フレームベース、コンテキスト セット、プランベース、エージェントベース。TRIPS エージェントベース システムの説明。
• ダイアログ管理に関するその他の研究論文