JP2019502944A - 対話補助 - Google Patents

Abstract

対話補助は、ユーザとの複数ターン制の対話ダイアログを実施し、その対話ダイアログでは、文脈はターン間で維持され、システムは、ダイアログを管理して、ユーザのための推論される目標を達成する。システムは、ユーザとの言語インタフェースと、ユーザからの言語イベントを処理するためのパーサとを含む。システムのダイアログマネージャは、パーサから代替の出力を受信し、動作を選択し、受信した代替の出力に基づいて動作を実行させるように構成される。システムは、ユーザとの対話のダイアログ状態をさらに含み、代替の出力は、現在のダイアログ状態から次のダイアログ状態への代替の移行を表す。システムは、多数のテンプレートのためのストレージをさらに含み、各ダイアログ状態は、テンプレートの１つまたは複数のインスタンスの相互関係の観点から定義される。

Description

関連出願の相互参照
この出願は、２０１５年１１月１２日に出願された、「ＡＮ ＡＴＴＥＮＴＩＶＥ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＡＳＳＩＳＴＡＮＴ」と称する米国仮特許出願第６２／２５４，４３８号明細書の利益を主張する。この出願は、参照により本明細書に組み込まれる。

この発明は、対話補助システムに関し、具体的には、音声を使用してシステムと対話するユーザのための自動補助に関する。

以前の自動ダイアログシステムは、手動で構築されるスロットフィリングアプリケーションに基づいてきた。これらは、通常は、手動で調整され、入力として英語のサブセットのみを受け入れる（これは、以前の自動ダイアログシステムの使用を難しくし、学習を困難にする傾向がある）。そのようなシステムのいくつかは、機械がユーザから会話についての追加情報を収集するモードである混合主導をサポートする。ここ最近では、部分観測マルコフ決定過程（ＰＯＭＤＰ）手法は、システムの状態を把握するために部分隠れマルコフ過程を使用しており、システムは、各時間に複数の状態を把握し、システムは、各時間に最も有力な推測に従って行動する。そのような以前のシステムでは、過程の意味論は、ハンドコーディングされてきたか、または、ダイアログが十分簡単なものである場合は、簡単な確率的過程として符号化されてきた。意味論は、単語および／または文脈の意味または動作と結びつけられている。

電話による補助の分野では、以前の電話アシスタントは、一般に、対話エージェントではなく、代わりに、発声コマンド／応答システムであった。多くのシステムでは、ユーザは、情報または動作の断片を要求することができ、システムは、音声認識装置が正確である場合や、ユーザがシステムの語彙の範囲内で要求を発した場合は、適切に応答する。しかし、一般に、システムは、脆いものであり、言い換えを理解できないものであり、セッションにわたって文脈を保持できないものであり、大抵の場合は、対話セッション内でさえ文脈を保持できないものであった。

一態様では、一般に、対話アシスタントは、ユーザとの複数ターン制の対話ダイアログを実施し、その対話ダイアログでは、文脈はターン間で維持され、システムは、ダイアログを管理して、ユーザのための推論される目標を達成する。システムは、ユーザに言語インタフェースを提供するための第１の統合コンポーネントを含む統合セクションを含む。また、システムは、第１の統合コンポーネントからの言語イベントを処理するためのパーサを含むイベント処理セクションも含む。システムのダイアログマネージャは、イベント処理セクションから代替の出力を受信し、動作を選択し、受信した代替の出力に基づいて動作を実行させるように構成される。システムは、ユーザとの対話のダイアログ状態のためのストレージをさらに含み、イベント処理セクションからの代替の出力は、現在のダイアログ状態から次のダイアログ状態への代替の移行を表す。システムは、多数のテンプレートのためのストレージをさらに含み、各ダイアログ状態は、テンプレートの１つまたは複数のインスタンスの相互関係の観点から定義される。

別の態様では、一般に、対話システムの多数のコンポーネントのパラメータ値を決定するための方法が使用される。システムは、イベントのシーケンスを処理するように構成され、イベントは、言語イベントおよびアプリケーション関連イベントを含み、イベントの処理は、言語イベントを構文解析することと、ダイアログ状態のシーケンスを決定することと、ダイアログ状態のシーケンスに対応するイベントのシーケンスから出力動作のシーケンスを決定することとを含む。方法は、多数のイベントのシーケンスおよび対応する出力動作のシーケンスを収集することを含む。反復は、繰り返される。各反復は、イベントシステムの現在のパラメータ値を使用してイベントのシーケンスを処理することによって、イベントのシーケンスおよび対応する出力動作のシーケンスを処理することを含む。この処理には、イベントのシーケンスからダイアログ状態のシーケンスを決定することが含まれる。出力動作のシーケンスは、ダイアログ状態のシーケンスから決定される。決定された出力動作のシーケンスと収集された出力動作のシーケンスとの比較は、システムの多数のコンポーネントのパラメータ値を更新するために使用される。反復の繰り返しは、伝導の終了に達すると完了する。システムの多数のコンポーネントのパラメータ値は、反復の結果を使用して設定される。

１つまたは複数の実施形態の利点は、ダイアログ状態が定義されるテンプレートの使用が、それらの状態を明示的に指定する必要なく、可能なダイアログ状態の多数のセットの使用を可能にすることである。その上、システムの構造は、機械学習およびニューラルネットワークコンポーネントのパラメータ値（「訓練」）の効率的で効果的な決定を可能にする。

本発明の他の特徴および利点は、以下の説明および請求項から明らかである。

対話補助システムのブロック図である。 カードライブラリを示す図である。 ダイアロググラフを示す図である。

図１は、対話補助システム１００のブロック図であり、対話補助システム１００は、例えば、ユーザによって開始されたタスクを遂行するために、複数ターン制のダイアログでユーザと対話するように構成される。そのようなタスクの一例は、システムの音声対話を通じてピザを注文することであり得る。しかし、システムによって、実質的により広いタスクタイプのセットを処理できることを理解すべきである。

システムは、外部の統合セクション１１０を含む。外部の統合セクション１１０は、一般に、ユーザや、ユーザと関連付けられた（例えば、ユーザによって制御されるかまたはユーザと対話する）外部のアプリケーションまたはシステムとの直接通信インタフェースを提供する。ユーザとの直接通信の形態の１つ（以下で詳細に論じる）は、音声統合コンポーネント１１１を活用する。音声統合コンポーネント１１１は、自動音声認識装置および音声合成器を含む。自動音声認識装置および音声合成器によって、システムは、例えば、電話もしくは他のリモート接続上で、または、ローカルマイクロフォンおよびスピーカ上で、音声によってユーザと直接通信できる。直接通信の他の形態（一般に、各々が、図１には示されていない外部の統合セクション１１０の別個のコンポーネントを備える）は、例えば、直接的なグラフィカルユーザインタフェース（ＧＵＩ）対話であるユーザとのテキストベースの直接通信を提供することができる。外部のインタフェースセクションは、任意選択により、アプリケーション統合コンポーネント１１２を含む。コンポーネント１１２が統合を提供する外部のアプリケーションの例は、Ｅメールアプリケーションまたはウェブブラウザアプリケーションを含む。Ｅメールアプリケーションまたはウェブブラウザアプリケーションによって、例えば、システムは、Ｅメールメッセージを送受信したり、情報の取得または提供を行うためにウェブサイトと対話したりすることができる。

外部の統合セクションのコンポーネント１１１、１１２は、イベントを生成する。イベントは、システム１００を通じて処理される。例えば、音声統合コンポーネント１１１は、ユーザが出した発声の自動演算転写を提供することができる。システムは、イベントインタープリタセクション１２０を含む。イベントインタープリタセクション１２０は、個々のイベントインタープリタ１２１、１２２を含む。その結果、例えば、必須ではないが、イベントインタープリタセクション１２０の各コンポーネントが外部の統合セクション１１０の異なるコンポーネントに対するイベントを処理するという形で、外部の統合セクション１１０の各コンポーネント１１１、１１２は、イベントインタープリタセクションの対応するコンポーネント１２１、１２２にそのイベントを送る。ユーザからの音声ベースの入力の場合、音声統合コンポーネント１１１は、自動音声認識の結果（例えば、言葉の転写、Ｎ最良転写、単語ラティスなど）をイベントインタープリタの意味パーサコンポーネント１２１に送る。

イベントインタープリタセクション１２０のコンポーネントによる処理に役立つシステム１００の一態様は、本明細書では顕著な特徴の情報１１５と呼ばれる情報の維持である。例えば、この情報は、システムが、ユーザの発声を解釈する際、ユーザの入力における暗黙参照を解決する際およびイベントの処理の間の論理条件を解決する際に使用する文脈上の情報を提供する。顕著な特徴の情報の一部は、比較的静的なもの（例えば、ユーザの住所および電話番号を表す）であり得る。そのような情報は、目標を達成するための住所情報を提供するために使用することができ、ユーザから明示的な承認を引き出せる可能性がある。顕著な特徴の情報の一部は、例えば、同じダイアログの以前の入力によって決定されているかまたはダイアログの合成テキスト出力に従って決定されているなど、はるかに一過性のものであり得る。非常に簡単な例では、そのような情報は、「それ」などのユーザの入力における言葉を解決するために使用することができる。顕著な特徴の情報セクション１１５には、外部の統合セクション１１０のコンポーネント、イベントインタープリタセクションのコンポーネントおよびダイアログコントローラ１３０から直接もたらされる場合を含めて、複数の情報源が存在しうる。それらについては以下でさらに詳細に説明する。また、顕著な特徴の情報セクション１１５の情報は、例えば、外部の統合セクションが使用することもできる。例えば、顕著な特徴の情報は、ユーザへのテキストベースまたは音声ベースの出力のためのテキスト生成に役立ち得る。

イベントインタープリタ１２０のコンポーネントが動作する方法にとって重要なシステム１００の別の態様は、カードテンプレートライブラリ１２５で定義される「カード」の使用、および、これらのカードの観点から指定されるダイアログ状態１３５の維持に関連する。以下でさらに詳細に論じられるように、外部の統合セクション１１０からイベントインタープリタセクション１２０によって受信された各イベント１１８、１１９に対し、イベントインタープリタセクションは、１組の提案「計画」１２９を提供する。一般に、計画は、あるダイアログ状態から別のダイアログ状態へ（一般に、現在のダイアログ状態１３５からその現在の状態の変更形態である別の状態へ）の移行を指定する。そのような変更形態は、カードをグラフに追加すること、カードを別のカードと交換することまたはグラフにおいて既存のカードを再配列することを含み得る。それに加えて、計画は、移行と関連付けられた１つまたは複数の動作を指定し、一般に、計画の新しい状態は、それらの動作が実行されていることを指定する。例えば、動作は、電話番号をダイヤルすること、Ｅメールを送信すること、何らかのテキストをユーザに読み聞かせることまたはユーザに質問すること（「Ｅメールの送信先は？」など）をシステムに行わせることができる。一般に、イベントインタープリタセクション１２０は、次の状態に関する最終的な決定を試みない。その決定は、ダイアログコントローラ１３０に委ねられ、ダイアログコントローラ１３０は、提案計画１２９を受信し、計画を選択し、実行すべき１つまたは複数の関連動作を開始する。

イベント１１８、１１９を処理することは、イベントインタープリタセクション１２０が１組の提案計画をダイアログコントローラ１３０に提供することを続行する。また、本質的には、自律的に生成された可能な移行は、現在の入力イベントを考慮することなく、ダイアログ状態のみに基づくため、ダイアログコントローラは、ダイアログ状態１３５からさらなる提案計画を受信することもできる。ダイアログコントローラは、次のダイアログ状態１３５を選択する。選択した次のダイアログ状態と関連付けて、ダイアログコントローラは、次のダイアログ状態をもたらす計画と関連付けられた動作１３９（または、より一般的には、１つまたは複数の動作）も決定し、その計画を達成するように動作コントローラ１４０に指示する。例えば、動作は、タスクの完了に必要なある情報を要求するプロンプトを発行することによってユーザからの入力を求めることであり得る。動作コントローラ１４０は、動作を達成するために、外部の統合セクション１１０のコンポーネントと対話する。例えば、音声統合コンポーネント１１１は、動作コントローラ１４０のコマンドで、テキストを生成し、音声によってユーザに提示するためにそのテキストを合成することができる。一般に、このイベント処理のサイクルは、タスクが完了するまで、ユーザとの複数の対話「ターン」）に対して続く。

システムの態様は、ダイアログのためのすべての可能な構造を事前に決定しておかなければならないわけではないことである。むしろ、ダイアログの構造は、カードテンプレートライブラリ１２５で定義される１組のカードテンプレート（一般に、手動で作成されている）に基づいて、ランタイムの間に決定される。以下でより完全に論じられるように、一般に、カードは、事前に定義されたタイプの出力および多くのフィールド（各々は、事前に定義されたタイプのもの）を有する。これらのフィールドの値は、入力として考えることができ、カードの出力を定義する。

図２を参照すると、カードライブラリ１２５の例は、多くのカードテンプレート２２５を含む。図２に示されるように、４つのカードが示されており、それらは、ピザ注文ドメインに関連する。「ピザの注文」と称する１つのカードは、「ＰｉｚｚａＯｒｄｅｒ」という事前に定義されたタイプの出力を有する。このカードは、４つのフィールドを有し、４つのフィールドは共に、ピザ注文を特徴付けるのに十分な情報を提供する。「Ａｄｄｒｅｓｓ」という事前に定義されたタイプの「住所」フィールドは、注文の配達住所を提供し、「ＣＣＩｎｆｏ」（すなわち、クレジットカード情報）という事前に定義されたタイプの「支払い」フィールドは、注文のクレジットカード支払いの詳細を提供し、「Ｐｉｚｚａ」という事前に定義されたタイプのアイテムのセット（またはシーケンス）である「ピザ」フィールドは、注文自体の詳細を提供し、最後に、「Ｐｈｏｎｅ」（すなわち、電話番号）という事前に定義されたタイプの「電話」フィールドは、注文が来た番号を提供する。

一般に、各データタイプは、そのデータタイプの出力値を提供することができる１つまたは複数のカードを有する。図２に示されるように、「友人の場所」というカードは、「Ｌｏｃａｔｉｏｎ」というタイプの出力を提供する。例えば、ユーザが、彼の友人のＪｏｈｎの家に配達予定のピザを注文する場合は、「友人の場所」というカードを使用して、ユーザが注文しているピザをどこに配達するかを決定することができる。

図３を参照すると、ダイアログ状態１３５は、対話の状態を表すダイアロググラフ３３５で表すことができる。グラフのノードは、カードライブラリ１２５からのカードのインスタンス、および、各々があるカードの出力から他のカードの１つまたは複数の入力まで方向付けられたリンクに対応する。例示的なダイアロググラフ３３５として、グラフのルートノードは、「ピザの注文」というカードのインスタンスである。図３に示される状態では、「ピザの注文」というカードの「住所」の入力は、「場所からの住所」というカードにリンクされ、そのカードの「場所」の入力は、上記で紹介された「友人の場所」というカードのインスタンスにリンクされる。最後に、「友人の場所」というカードの「誰か」の入力は、「人物」というカードにリンクされる。ユーザとシステムとの間の対話の多くの異なる発声または複数のターンはこのダイアロググラフにつながる可能性があるが、発声の１つは、以下の通りであり得る。
ユーザ：「Ｊｏｈｎの家にピザの配達をお願いしたいのですが」
または
ユーザ：「ピザの注文をお願いします」
システム：「どこへ配達しますか？」
ユーザ：「Ｊｏｈｎの所に」
システム：「Ｊｏｈｎの家ですか、それとも、彼のオフィスですか？」
ユーザ：「Ｊｏｈｎの家に」

いずれの時点においても、ダイアロググラフ３３５は、例えば、複数のカードが１つのカードへの入力値を潜在的に提供するまたは複数のルートカードがあるなど、曖昧なものであり得ることに留意されたい。ダイアログ状態１３５は、カードインスタンスのネスティングと同等に表すことができ、例えば、「ピザの注文」というカードインスタンスの「住所」の入力はネスティングされた「場所からの住所」というカードインスタンスであるなど、１つのカードインスタンスの入力の値は、ネストカードインスタンスとして表される。しかし、１組のカードインスタンスを使用してダイアログ状態を表す特定の方法は決定的なものではないことを理解すべきである。

上記で紹介されるように、音声入力が一例である（テキスト入力に加えて）、システムによる言語入力の処理に移ると、外部の統合セクション１１０は、音声統合コンポーネント１１１を含み、音声統合コンポーネント１１１は、イベントインタープリタセクション１２０の意味パーサ１２１に自動処理音声入力１１８（すなわち、言語入力）を提供する。音声認識装置の出力は、テキスト（または言葉のシーケンスの他の表現）の形態であり、Ｎ最良リストまたは１組の可能な言葉のシーケンスを表すラティスの形態の音声入力の代替の解釈を表し得る。

意味パーサ１２１は、音声認識装置１１０の出力を処理する際に、顕著な特徴の情報１１５およびカードテンプレート１２５を活用する。一般に、ユーザからの各入力発声に対し、パーサは、特定のカードのフィールド値および新しいカードの参照が入力で表されているかどうかを判断する。意味パーサの出力は、ダイアログコントローラ１３０に送られ、ダイアログコントローラ１３０は、その時点で知っている情報（顕著な特徴の情報１１５を含む）に基づいて、ユーザとの対話をどのように導くかを決定する。全体的な目標および従属サブダイアログまたは下位目標を表すダイアロググラフ３３５を維持するのは、ダイアログコントローラ１３０である。

システムの２つの重要な態様は、例えば、明示的な値としてのまたはその出力が値を提供するカードのインスタンス化によるグラフの変数の決定に必要な情報を引き出すために、ユーザとの対話の間にダイアロググラフが構築される方法や、ユーザとの対話を導くためにダイアロググラフがどのように使用されるかである。

ダイアロググラフの構築は、特定のカードにマッピングされるユーザ入力のインスタンスを検出することができる意味パーサのオペレーションにかなり依存する。このプロセスを支援するため、一般に、各カードは、ユーザの入力を解釈する際に意味パーサによって使用される分類子またはトリガ定義（例えば、トリガフレーズのリスト）の指定と関連付けられている。以下でさらに論じられるように、そのような分類子またはトリガフレーズは、例えば、カードライブラリにカードを追加するシステム設計者が、手動で作成することができる。好ましくは、システムは、ユーザ入力と有効な解釈とをペアにする訓練データを活用するプロセスを通じて、分類子を学習する。

一般に、意味パーサ１２１は、意図の表現を生成するためにユーザ発声を解釈し、これらの意図の表現をダイアログコントローラ１３０に送る。ダイアログコントローラ１３０は、上記で紹介されたダイアロググラフ１３５を含むダイアログ状態を維持するために、これらの意図の表現を処理する。一般に、意味パーサは、例えば、エンティティ（例えば、「それ」、「Ｅメール」、「ＤａｎのＥメール」、「Ｄａｎ ＫｌｅｉｎのＥメール」、「ＴＴＳについてのＥメール」など）の参照を解決するために、顕著な特徴の情報１１５を活用してテキスト入力１１８を処理する。意味パーサは、問題のエンティティの現在の顕著な特徴および他の同様の顕著であるエンティティを見て、正しい参照表現を決定する。上記で紹介されるように、パーサは、入力における参照であるカードテンプレートの識別や、入力からおよびそれらの識別されたカードに対する顕著な特徴からの情報の記入も行う。また、パーサは、タスク状態の一部を表す現在のダイアログ状態１３５へのアクセスも有し、ダイアログ状態で既にインスタンス化されたカードに記入する必要があり得る値を提供する。また、パーサは、その情報が新しいカードまたはダイアログ状態で既にインスタンス化されたカードに関係しているかどうかにかかわらず、発声において見られるエンティティで顕著な特徴の情報１１５の更新も行う。

この実施形態における意味パーサ１２１は、ハイパーグラフ重み付け演繹システム（ｈｙｐｅｒｇｒａｐｈ ｗｅｉｇｈｔｅｄ ｄｅｄｕｃｔｉｏｎ ｓｙｓｔｅｍ）である（例えば、Ｐａｕｌｓ，Ａ．Ｄ．，“Ｏｐｔｉｍａｌ Ｓｅａｒｃｈ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｓｔｒｕｃｔｕｒｅｄ Ｐｒｏｂｌｅｍｓ ｉｎ Ｎａｔｕｒａｌ Ｌａｎｇｕａｇｅ Ｐｒｏｃｅｓｓｉｎｇ，“Ｐｈ．Ｄ．Ｔｈｅｓｉｓ，ＥＥＣＳ Ｄｅｐａｒｔｍｅｎｔ，Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃａｌｉｆｏｒｎｉａ，Ｂｅｒｋｅｌｅｙ，２０１２を参照）。そのようなパーサは、「公理」と呼ばれる「アイテム」の初期のセットから始まり、１つまたは複数の目標アイテム（発声の「完全な」解釈を表す）を生成するために、「演繹ルール」を使用して、アイテムを組み合わせてより大きなアイテムにする。意味パーサ１２１は、２種類のアイテムを有する。第１のアイテムは、カードとダイアログマネージャのカードグラフにおけるその場所の両方を説明する「ホーム」アイテムである。別のアイテムは、グラフに場所がないカードである「オーファン」アイテムである。すべてのホームアイテムは、目標アイテムと考えられる。

公理に対し、このパーサは、自動音声認識装置１１０の出力、ダイアロググラフ１３５を含むタスク状態および顕著な特徴１１５からの情報を使用する。現在のタスクグラフのすべてのカード（ホーム）は、公理として生成される。それに加えて、パーサは、ＡＳＲ転写物（またはラティス）を使用して、ある特定のキーワード、キーワードの組合せ、または、他のシステムもしくは辞書により導入される追加の情報（顕著な特徴状態など）によってもたらされるカード（オーファンまたはホーム）を生成する。例えば、「同じメッセージをＪｏｈｎ Ｓｍｉｔｈに送信します」という発声は、「Ｅメール送信」という公理、「テキストメッセージ送信」という公理、「連絡先（Ｊｏｈｎ Ｓｍｉｔｈ）解決」という公理および最も顕著なメッセージを表す公理をもたらす。

演繹ルールに対し、パーサは、次いで、カードを互いに接続することによってアイテムを組み合わせてより大きなアイテムにする方法を考慮する。例えば、パーサは、最も顕著なメッセージを表すカードを取り、その「受信者」というサブカードを「連絡先（Ｊｏｈｎ Ｓｍｉｔｈ）解決」と交換することができる。最も顕著なメッセージがＥメールである場合は、「Ｅメール送信」とリアドレスメッセージを表すアイテムを組み合わせることができ、そうでなければ、「テキストメッセージ送信」とメッセージを組み合わせることができる。

一般に、すべての公理が使用されるという制約も、転写物またはラティスの時間帯におけるすべての言葉が構文解析で使用される公理によって「カバーされる」という制約もないことに留意されたい。例えば、完全に有効な（ただし間違った）構文解析は、上記のように受信者フィールドを交換せずに、単に、「Ｅメール送信（メッセージ＝最も顕著なメッセージ）」であり得る。実際に、パーサによって提案されたすべてのホーム構文解析アイテムは、「完全な」構文解析と見なされる可能性がある。それらの多くは、間違いにすぎない。

良い構文解析と悪い構文解析のどちらかを選ぶため、パーサは、事前に指定された機能を使用して、スコアをアイテムに割り当てる。この文書でさらに論じられるように、この機能は、手動で設計することも、線形分類子またはニューラルネットワークを使用して、機械学習で推定することもできる。

意味パーサは、構文解析を生成するため、ユーザの発声の前に決定された現在のダイアログ状態からの情報を発声自体のテキストと組み合わせる。この特徴は、文脈上の解釈を可能にする。パーサは、「メッセージ」という言葉はある文脈では「テキストメッセージ」を意味し、別の文脈では「Ｅメールメッセージ」を意味し得ると正しく推論することができる。文脈を知っていなければ、意味パーサは、どの分析がより正しいかを知るすべがない可能性がある。一度に１つの入力発声のみを通常は処理する以前の意味パーサとは異なり、このシステムの意味パーサは、ユーザの趣旨のいくつかの決定プロセスを知らせるため、顕著な特徴の情報および現在のダイアログ状態を考慮する。現在のシステムでは、意味パーサは、実行しているカードの顕著な特徴、タスクによって示されているそれらのカードおよび他のカードのアイデンティティ、ならびに、ユーザの音声をどのように解釈するかを決定する際のエージェントの出力動作および出力発声を考慮する。

意味パーサ１２１の機能をレビューするため、意味パーサ１２１は、音声統合コンポーネント１１１からのテキスト入力１１８の解釈に基づいて顕著な特徴の情報を使用および更新する。また、意味パーサ１２１は、現在のダイアログ状態１３５を使用し、ダイアログコントローラ１３０に送る情報を生成する。また、その入力を処理する際、意味パーサは、テンプレートライブラリの特定のカードテンプレートと関連付けられたルールまたは他の情報を用いるように構成され、それにより、カードのインスタンスに対応するテキストのインスタンスの検出が可能になり、また、カードによって参照される（すなわち、カードの入力および出力として）既知のデータタイプのインスタンスを構文解析または検出するようにも構成される。従って、カードテンプレートライブラリは、意味パーサまたはシステムの他のコンポーネントの変更を必要とすることなく、システムのドメインを拡張するための方法を提供する。カードの指定の分離および意味パーサの構成により、意味パーサ自体を変更する必要なく、新しいカードを作成することによる新しいタスクへのシステムの拡張が可能になることに留意されたい。

ここでダイアログコントローラ１３０のオペレーションに移ると、ダイアログコントローラの機能は、各イベント入力後、本質的に次に何をするかを決定することである（すなわち、それは「決定者」である）。１組の候補計画（意味パーサ１２１によって提案されたおよび／またはダイアログ状態のカードから自律的に）を考慮すると、ダイアログマネージャは、それらの計画のうちのどれを選択してその動作を実行すべきかを選ぶ。しかし、ダイアログマネージャは、何もしないこと、特定の計画を実行すべきかどうかを尋ねること、数個の計画のうちのどれを実行すべきかをユーザに尋ねることを選べることを理解すべきである。これらの代替案は、「何もしない」というカード、「承認」というカード、「選ぶ」というカードまたは「助けを求める」というカードを使用することによって、計画として策定することもできる。ダイアログマネージャは、これらの代替の計画を候補計画のプールに追加し、他の提案計画と並行してそれらをスコア付けする。

従って、ダイアログマネージャ１３０は、３つの責任を有する。最初に、ダイアログマネージャ１３０は、スコア関数に従って提案計画をランク付けする。次いで、ダイアログマネージャ１３０は、それらの計画のスコアと併せて新しい候補計画を追加する。最後に、ダイアログマネージャ１３０は、最良のスコア計画を選ぶ。計画のスコア関数は、手動で構築されるものでも、機械学習を使用するものでもよい。機械学習アルゴリズムは、構造化サポートベクタマシンなど、いかなる構造化分類子でも、ランキングアルゴリズムでもよい。

ダイアログマネージャ１３０の役割の別の態様は、ダイアログ状態１３５の「焦点」の維持である。上記で論じられるように、ダイアログ状態１３５のダイアロググラフ３３５は、カードのインスタンスの相互接続（または同等のネスティング）によって形成される。ダイアログマネージャは、これらのカードのうちの１つをダイアログの焦点として識別する。この焦点カードは、動作を呼び起こすカードであり得る。焦点の識別は、例えば、意味パーサが動作から生じ得る入力を解釈する際に役立つ。

引き続き言語の入力および出力の事例を考慮すると、ダイアログマネージャによって選択されたある特定の動作は、テキストの生成と、音声出力の場合は、そのテキストの音響バージョンの合成とを伴う。音声統合コンポーネント１１１は、テキスト生成器と、テキスト生成器の出力を受信してオーディオ提示のための出力を提供する音声合成器とを含む。

カード設計者が出力のための言語情報を指定する際、カード設計者は、ストリングを直接記載するよりむしろ、メッセージを説明する簡単な論理形式を使用して言語情報を指定する。次いで、この論理形式は、テキスト生成器によってストリングとしてレンダリングされる。生成メカニズムの中央集権化は、２つの主要な利益を提供する。第１に、カードインプリメンタは、文法のルール、正しい代名詞の使用などについて知る必要はない。第２に、言語の変形例を自動的に導入し、ユーザとシステムとの間の対話をより自然なものにすること（「ＪｏｈｎにＥメールを送信しますか？（「ｗｏｕｌｄ ｙｏｕ ｌｉｋｅ ｔｏ ｓｅｎｄ Ｊｏｈｎ ａｎ ｅｍａｉｌ」、「ｗｏｕｌｄ ｙｏｕ ｌｉｋｅ ｔｏ ｓｅｎｄ ａｎ ｅｍａｉｌ ｔｏ Ｊｏｈｎ？」）」）が簡単である。

論理形式は、論じられているエンティティの特性（例えば、Ｅメールの送信者または件名）またはダイアログのタスク（例えば、システムが、現在のタスクを終了する前に、新しく受信したＥメールを読むべきかどうかを尋ねる）を説明することができる。可能な一実施形態では、論理形式は、トップレベルのダイアログ作用、イベント、エンティティまたは属性としてすべてのノードが指定され、追加のキーが追加の精緻化を提供する（イベントの参加者、エンティティの名前など）、簡単なネオデイヴィッドソン意味論に対応するキー値ペアとして実装される。最後に、現在のダイアログ状態の断片に対応するこの論理形式の一部分（カードまたはエンティティ）は、適切な識別子でタグ付けされる。

例えば、ダイアログエージェントは、以下のように、「パワーラインレポート」という件名でＥメールを送信するというその趣旨を表現することができる。
｛
ｔｙｐｅ：ＩｎｆｏｒｍＩｎｔｅｎｔｉｏｎ
ｂｏｄｙ：｛
ｔｙｐｅ：ｅｖｅｎｔ
ｎａｍｅ：ｓｅｎｄ
ａｇｅｎｔ：ＤｉａｌｏｇｕｅＡｇｅｎｔ
ｉｄ：ｃａｒｄ＃＃＃
ｔｈｅｍｅ：｛
ｔｙｐｅ：ｅｎｔｉｔｙ
ｎａｍｅ：ｅｍａｉｌ
ｓｕｂｊｅｃｔ：ｐｏｗｅｒ ｌｉｎｅ ｒｅｐｏｒｔ
ｉｄ：ｅｍａｉｌ＃＃＃
｝
｝
｜

この論理形式は、多くの方法でレンダリングすることができる。
「パワーラインレポート」という件名でＥメールを送信する
パワーラインレポートについてのＥメールを送信する
パワーラインレポートＥメールを送信する
それを送信する
など。

意味パーサ１２１と同様に、音声統合コンポーネント１１１のテキスト生成器は、顕著な特徴の情報１１５を使用して、論理形式からからテキストをどのように生成するかを決定する。上記の例で見られるように、システムは、他のＥメールと比べて問題のＥメールがどれほど顕著であるかに応じて、様々な程度の特異性で問題のＥメールを説明することができる。

各論理形式に対し、テキスト生成器は、１組の候補発声を生成する（明示的にまたは構文森として実現される）。これらの候補は、再帰的に生成される。論理形式（またはその断片）を考慮すると、テキスト生成器は、ストリングとして論理形式全体をレンダリングするためのルールまたはテンプレートを使用してその一部を実現するためのルールを有することができ、次いで、各サブパートを独立して実現することによって完了する。

これらのルールは、手動で記載することも、構造化言語資源と非構造化言語資源の両方から自動的に取り出すこともできる。例として、所定のいかなるイベントに対しても、テキスト生成器は、ＯｎｔｏＮｏｔｅｓコーパスからのデータならびに論理形式の自然言語表現を選ぶためのオープンウェブおよび人間の注釈者からのデータ集合体を使用する。ＯｎｔｏＮｏｔｅｓコーパスは、各動詞をその論証とリンクし、システムの実施形態は、それらの論証とペアになった動詞のレンダリングを提供するために情報を使用することができる。

１組の候補発声を考慮すると、テキスト生成器は、スコア関数を使用して各発声を重み付けし、各発声のスコアに比例して各発声からサンプリングする。意味パーサのように、この機能は、手動で設計することも、線形分類子またはニューラルネットワークを使用する機械学習によって推定することもできる。

自動音声認識および音声合成は必要ではないことを除き、音声入力の処理および音声出力の提供の説明は、テキストベースの入力および出力に適用可能である。その上、対応するイベントインタープリタ１２２によるアプリケーション統合コンポーネント１１２からのイベントの処理は、ダイアログ状態１３５の既存のカードに値を記入することによってまたはアプリケーションイベントと関連付けられたカードのインスタンスを導入する状態変化を伴う計画を提案することによって、提案されたダイアログ状態の変化を直接供給することができる。

上記で説明される様々なコンポーネントによって実装される手順は、完全に手動で構成しなければならないわけではない。むしろ、多くのコンポーネントは、トリガ段階とカードテンプレートとの関連付けまたはユーザへの出力の論理形式など、手動で構成された態様を有し得るが、システムのオペレーションの多くは、代替案の比較的限られたセットからのランク付けおよび選択を伴う。これらの代替案のランク付けおよび選択は、ユーザとシステムとの間の対話の代表的なデータを使用する自動技法を使用するように構成されていてもよい。

一般に、機械学習（ＭＬ）または人工ニューラルネットワーク（ＡＮＮ）の使用の様々な公知の技法は、システムの様々なコンポーネント（例えば、パーセプトロン、フィードフォワードシステム、畳み込みニューラルネットワーク、長期・短期メモリシステム、注意システム、サポートベクタマシンまたは他の訓練アルゴリズムなどの構造分類子またはランキングアルゴリズム、交差エントロピー、尤度、確率、誤差率または他の尺度などの最適化関数）によって使用される。非常に一般的には、訓練システムは、システムのすべての入力、出力および中間状態を取り、音声統合コンポーネント１１１の音声認識装置およびテキスト生成器の性能、意味パーサ１２１の性能、ならびに、ダイアログマネージャ１３０の性能を最適化する。最適化は、交差エントロピー、尤度、確率、誤差率または他の尺度の関数であり得る。

ＭＬおよびＡＮＮ技法の使用の一態様は、所望の成果を表す「訓練データ」の必要性である。例えば、ダイアログマネージャの事例では、この訓練データは、意味パーサによって提案された計画に基づく選択すべき望ましい計画の表示を含み得る。システムがそのような訓練データを決定する方法の１つは、「ウィザードオブオズ」（ＷｏＺ）モードである。このモードでは、ユーザは、システムに何でも自由に尋ねることができ、ヒューマンエージェントは、彼の力を最大限まで出して、システムへの返答を形成する（またはいくつかのサービスが利用可能ではないと応答する）。このモードは、データ収集や、プロトコルに組み込まれた自動または手動補助による後の最適化への支援を意図する。

「ヒューマンオペレータ」モードでは、人間は、システムへの返答を形成せず、むしろ、システムによって識別されたオプションから選択を行う。例えば、ヒューマンオペレータには、音声統合コンポーネントによって決定されたトップの自動転写物を提示することができ、ヒューマンオペレータは、「最良」のものを選択することができる。同様に、意味パーサによって提案された計画の中から、ヒューマンオペレータは、入力および現在のダイアログ状態を考慮して、最も適切なものを選択することができる。ヒューマンオペレータの選択は、記録され、かつ、ヒューマンオペレータなしの完全自動モードでの自動オペレーションのための自動選択またはスコア特徴を訓練するために使用される。

ヒューマンオペレータモードと完全自動モードとの中間として、混合自動／ヒューマンモードは、選択およびスコア付けまたは代替案を実行し、いくつかの事例では、人の介入なしで進行する。しかし、自動手順に不確実性または曖昧さがあることを自動選択またはスコア付けが示す場合（例えば、複数のオプションが同様のスコアを有するため）は、ヒューマンオペレータは、ヒューマンオペレータモードと同様に、決定を行うことが求められる。これらの決定は、ＭＬコンポーネントおよびＡＮＮコンポーネントの今後の訓練のための訓練データを増大するために使用される。

訓練データの別の供給源は、システムにおける中間データの人間の注釈からもたらされる。例えば、ヒューマンエキスパートは、手動で意味構文解析の正しい構文解析に注釈を付け、同じ構文解析を生成するようにパーサを訓練することができる（恐らくは、部分的な信用を可能にするために、構文解析における間違ったサブカードの数を最小化するなどの損失関数を使用して）。

一般に、中間データの注釈は必要ではない。例えば、意味パーサによる構文解析出力は、実行された場合に（例えばダイアログマネージャによって選ばれた計画として）ヒューマンエージェントの挙動と整合するであろう構文解析を見つけることによって決定しなければならない「潜在的変数」として扱われる。例えば、そのような手法のための訓練データは、ユーザの発声およびイベント（例えば発声または新しいＥメールの到着）のシーケンスを含みうる。出力は、それらのイベントに対応する動作のシーケンスである。ＥＭアルゴリズムなどの教師なし訓練アルゴリズム（例えば、Ａ．Ｐ．Ｄｅｍｐｓｔｅｒ，Ｎ．Ｍ．Ｌａｉｒｄ，ａｎｄ Ｄ．Ｂ．Ｒｕｂｉｎ．“Ｍａｘｉｍｕｍ Ｌｉｋｅｌｉｈｏｏｄ ｆｒｏｍ Ｉｎｃｏｍｐｌｅｔｅ Ｄａｔａ Ｖｉａ ｔｈｅ ＥＭ Ａｌｇｏｒｉｔｈｍ，”Ｊｏｕｒｎａｌ ｏｆ ｔｈｅ Ｒｏｙａｌ Ｓｔａｔｉｓｔｉｃａｌ Ｓｏｃｉｅｔｙ：Ｓｅｒｉｅｓ Ｂ，３９（１）：１−３８，Ｎｏｖｅｍｂｅｒ １９７７を参照）は、どの構文解析（ならびにダイアログマネージャおよび動作コントローラ出力）が正しい出力のシーケンスを生成することができるかを推論するために使用することができる。一般に、別個のパラメータは、音声統合コンポーネント１１１、意味パーサ１２１およびダイアログマネージャ１３０などの各コンポーネントに対してこのような方法によって訓練される。

そのような訓練アルゴリズムの重要なコンポーネントは、「説明のつかない」ヒューマンオペレータ生成出力および動作（すなわち、システムが利用可能な構文解析または動作によって生成することができない出力）を処理する能力である。このような出力は、特別な構文解析および動作を提供することによって説明することができる。特別な構文解析および動作は、可能ないかなる出力も説明することができるが、訓練の間のその使用には通常の構文解析および動作が好まれるように重いペナルティが科される。

音声統合コンポーネントのテキスト生成部分を訓練するための一手法は、ヒューマンエキスパートを利用する。シューマンエキスパートは、システムによって生成されたサンプル論理形式に対応するテキストを提供する。テキスト生成器は、入力として論理形式を考慮し、例えば生成テキストのＢＬＥＵ（ｈｔｔｐ：／／ａｃｌｗｅｂ．ｏｒｇ／ａｎｔｈｏｌｏｇｙ／Ｐ／Ｐ０２／Ｐ０２−１０４０．ｐｄｆ）スコアを最大化するなどの損失関数を使用して、それらの出力を生成するように訓練される。

意味パーサは、出力計画をスコア付けまたは選択するためのアイテムの多くの特徴を使用する。これらは、以下を含む。
１．作成された新しいカードのタイプおよび何枚作成されたか。
２．テキスト入力に応じたトリガ言葉の確率（顕著な特徴を説明するために再度スコア付けされた後である可能性がある）。
３．カードおよびエンティティの顕著な特徴。
４．既存のカードに対して変更は何回行われたか。
５．「実は」（ユーザが何かを変更することを希望することを示す）または「また〜も」（ユーザが何かを追加することを希望することを示す）のような、談話における有益な言葉の存在。
６．入力発声のいくつの言葉が使用されるか。
７．いくつの言葉が複数回使用されるか。
８．組み合わされた２つのアイテムに対して、それらのトリガ言葉（もしあれば）が入力発声においてどれだけ離れているか。
９．以前の動作において調整された可能性がある、ヒーローエージェント対話（本明細書の他の場所で提示されるデータ収集についての議論を指す）から収集されたデータにおいて構文解析がどれだけ頻繁に起こるかによって構文解析をスコア付けする動作モデル。説明される実施形態では、動作モデルは、言葉ではなく動作に対するｎグラム言語モデルである。

システムは、直接または間接監視を使用して訓練することができる。直接監視では、システムは、候補計画（正しい計画を含む）およびダイアログ文脈のリストという形態で訓練データを受信し、正しい計画を選択するように訓練される。

このデータを収集するための方法の１つは、ヒューマンオペレータモードを用いることである。ヒューマンオペレータモードでは、システムは、計画のランク付けされたリストを継続的に提案し、人間は、候補のうちの１つを選択したりすべての候補を拒否したりすることができる。同様に、混合モードでは、システムは、信頼度閾値（数個の計画が同様のスコアを有する際など）または別のメカニズムに基づいて助けを求めるためにヒューマンエージェントに従うことを選択することができる。人間の選択は、訓練データとして記憶することができる。

また、ダイアログマネージャは、意味パーサの訓練に対して説明されるものと同じ潜在的変数手法を使用する間接監視を考慮して、訓練され得る。別には、さらに一層間接的な形態の監視は、ヒューマンオペレータの直接の介入なしで、エンドユーザ対話から学習することである。このモードでは、システムは、強化学習エージェントとして動作し、正しい動作または間違った動作を実行したキュー（「報酬」）を探す。このとき、システムは、再び間違いを犯す可能性を低くするためにスコア関数の重みを更新する。これらのキューは、ユーザによって明示的に提供されたり（例えば、事前に指定されたキーフレーズを言うこと、電話を振ることまたはボタンを押すことによって）、あるいは、ユーザの音声の音響特性によってユーザのフラストレーションレベルを測定するなどの方法によって暗黙的に提供されたりする。学習アルゴリズムは、Ｑ学習、深層Ｑネットワークまたは時間差学習など、いかなる強化学習アルゴリズムでもあり得る。

上記で説明される訓練のための手法に加えて、ユーザとの対話から収集されたデータ（トレースデータと呼ばれる）からのオフラインの統合方法またはダイアログが進行中の間のオンラインの統合方法で、システムのコンポーネントを訓練することが可能である。トレースデータから訓練する際、システムは、入力としていかなる注釈も含む完全なまたは進行中の通話記録を取り、その予測を通話記録によって提示されたものと同じものにするためにその重みを更新する。この項目の目的のため、記録は、以下を含み得る。
１．利用可能な場合はラティスまたはｋ最良リストを含む、ユーザの音声の音声認識転写物。
２．ヒューマンエージェントが音声出力を提供する場合は、エージェントに対する音声認識転写物。
３．アプリケーションイベント（例えば、グラフィカルインタフェース、ＤＯＭ（文書オブジェクトモデル）イベント、ＨＴＴＰ要求などにおけるアイテムの選択）ならびにアプリケーションおよびデバイスからのメタデータ捕捉（例えば、時間、場所、車両速度など）を含む、アプリケーションイベント。
５．事実の後にエージェントまたは他の注釈者によって追加された文字通りの注釈または構造化された注釈。

このデータはすべて時間的に整列され、各イベントは、その開始時刻および終了時刻を伴う。訓練は、例えば、教師なし学習技法または強化学習技法を使用して、トレースデータを予測するようにシステムを構成する。一つの手法は、生成的確率モデルに基づく。

図１に戻ると、訓練は、外部の統合セクション１１０のコンポーネントによって生成されたイベント１１８、１１９のシーケンス、および、それらのイベントに応答してダイアログコントローラ１３０によって生成することができる結果として得られた正しい動作１３９であると考えることができる。意味パーサ１２１において構文解析をランク付けするためのパラメータまたはダイアログコントローラ１３０によって計画をランク付けするためのパラメータなどの構成可能なパラメータは、ダイアログ状態の進化の注釈またはイベントの処理の他の内部の態様を必ずしも必要とすることなく、イベントおよび動作に最も適合するように最適化される。いくつかの例では、イベントインタープリタ１２０およびダイアログコントローラのコンポーネントのパラメータを最適化することに加えて、イベントから生成されたイベントというよりむしろ、オリジナルの入力音声などのオリジナルの入力となるように動作とペアにされたイベントを考慮することによって、音声統合コンポーネント１１１（例えば、自動音声認識およびテキスト／音声合成）のパラメータも最適化することができる。

一般に、訓練のための手法は、訓練の例の集合体である入力を使用することを伴う。各訓練の例は、ブレット付きのリストで説明されるイベントのシーケンスおよび任意のメタデータである。訓練の例の集合体に対応するカードライブラリも使用される。訓練予定のすべてのモデル（例えば、パーサ、エージェント／ダイアログマネージャ、テキスト生成、自動音声認識または合成）に対するパラメータは、例えばパラメータのランダムまたはゼロ数値ベクトルとして、最初に初期化される。いくつかの事例では、パラメータは、「いつも承認ばかりしない」または「パーサは文章内のほとんどの言葉を使用すべきである」などの態様を指定するなど、デフォルト条件で知らされる値に初期化されうる。

次いで、パラメータの値の収束または反復回数の限度などの停止条件に至るまで、様々なコンポーネントのパラメータの決定が反復して実行される。各訓練の例（または１組の訓練の例の「ミニバッチ」）に対し、入力イベントは、現在のパラメータを使用して処理され、最良の重み付け実行追跡が選ばれる。その最良の追跡と関連付けられた各決定に対し、現在のモデルパラメータを用いて選ばれた選択が最良の選択より劣っている場合は、パラメータは、学習レートおよび選ばれた選択と最良の選択との差に従って漸増する。

最良の重み付け実行追跡の決定は、ビーム探索、粒子フィルタリング、Ａ^＊、または、現在のモデルパラメータを用いる他の関連技法を使用する。これは、その例に対する重み付け実行追跡の１組の集合体の出力をもたらす。重みは、各決定からおよび各誤差関数演算からの集計スコアの総和である。追跡の各ステップは、システムが行わなければならない１組の「決定」（決定は、構文解析、計画、生成テキストなどを含む）を含む、。各決定は、実際に選ばれた選択と共に、選択を行うことと関連付けられた使用される特徴を説明するベクトルの集合体である（これは、ｈｔｔｐ：／／ｗｗｗ．ａｃｌｗｅｂ．ｏｒｇ／ａｎｔｈｏｌｏｇｙ／Ｎ１０−１０８３と同様である）。

生成的確率モデル形成に基づく手法では、学習の目標は、入力において調節された出力の確率を最大化することである。使用するモデルの１つは、隠れマルコフモデル（ＨＭＭ）であり、記録のタイムラインを時間ステップのシーケンスに分割する。各時間ステップでは、システムは、その時刻に（および任意選択によりその時刻になるまで）入力において調節されたイベントの時刻に起こる出力におけるイベントを生成する。期間にわたるイベントの場合は、ちょうど開始時刻または終了時刻にモデリングすることも、イベントが起こるその時間帯に繰り返し起こるものとしてイベントをモデリングすることもできる（あるいは、隠れセミマルコフモデルを使用し、単一の時点というよりむしろ、イベントの開始時刻および終了時刻を予測することができる）。

ＨＭＭの隠れバックボーンの場合は、システムの状態はまさしくダイアログマネージャの状態（すなわち、顕著な特徴リストおよびカード）である。ＨＭＭの移行モデルは、単に、ダイアログマネージャ自体である（すなわち、ユーザ発声に対する音声認識装置出力から発声を構文解析し、電話イベントに反応する）。ＨＭＭは、ダイアログマネージャの状態を使用して各時間ステップにおいてイベントを「生成する」。イベントタイプは、システムによって生成された出力、ダイアログ状態から生成された注釈およびアプリケーションイベントを含む。

テキスト生成器は、発声にわたる分布を生み出し、モデルは、その分布の下で観測された発声の確率を最大化するように訓練される。その上、観測された発声の尤度の演算に実際に使用される分布は、生成器によって出力されたものと全く同じである必要はない。分布は、代わりに、テキスト生成器出力の関数であり得る。具体的には、尤度演算に使用される分布は、例えば「ｕｈｓ」の挿入などを可能にする編集距離トランスデューサを使用することによって、吃音または音声認識アーチファクトに対してよりロバストになるようにすることができる。説明される実施形態では、自動的に推定されたパラメータを有する言葉にわたる編集距離トランスデューサが使用される（ＥＭを介して推定される）。

クリックストリームイベントを生成する分布の形態は、イベントタイプにわたるカード特有の多項分布のように簡単なものであり得る。成功する可能性が高い手法は、イベントタイプにわたる構造化された分布を使用し、例えば、「第１のＥメールを未読にする」および「第３のＥメールを削除する」のようなイベント間の共通性を学習することである。それに加えて、いくつかのイベントは、「ノイズ」分布によって（エージェントが誤ってストレイクリックするかまたはウェブページが何らかの自動バックグラウンドプロセスによって更新される（例えば、新しい広告が出現する））、最もうまく説明することができる。説明される実施形態では、訓練システムは、バックグラウンド「ノイズ」分布と動作および調節環境（すなわち、カード）に関する特徴を有する特徴豊富な記録の線形モデルとの混合分布を使用する。この分布に対するパラメータは、残りのシステムと共同で推定される。

事実上、システムのすべてのコンポーネントは、この手法を使用して訓練することができる。テキスト生成器は、記述およびエージェントの音声から学習する。ダイアログマネージャおよび意味パーサは、その分布が正しいクリックストリームイベントならびに正しい「発言」および「生成」イベントを生成するカードを予測することによって学習する。

上記で述べられるように、上記で説明される訓練手順の特性の１つは、記録されたデータの多くがヒューマンまたは混合ヒューマン／自動データ収集モードで自己注釈付けされることである。すなわち、ユーザの発声およびヒューマンエージェントの発声は、エージェントの動作の記録と共に、メタデータで増大される。この豊富なデータは、システム性能を向上させるため、自動化への新しい経路を見出すため、情報回収タスクをカスタマイズするため、および、ダイアログプロセスを分類するために、様々な機械学習プロセスへの入力として使用される。いくつかの例を以下に続ける。

ユーザからのオーディオデータは、音声認識システムで自動的に認識される。次いで、意味パーサで構文解析され、動作のためにエージェント（人間または機械にかかわらず）に送られる。動作は、データをユーザに送り返すこと、タスクを続行するために必要な情報のいくつかの部分の明確化を依頼すること、または、問題についてユーザに知らせることであり得る。

意味パーサと自動音声認識システムは両方とも、統計機械であり得る。すなわち、意味パーサおよび自動音声認識システムは、特定の成果の確率の演算の結果としての結果を生成し、結果は、それらの結果の正確性の確率と共に作成される。結果は、正しいものでも間違ったものでもあり得、このステータスは、情報を受信した際のユーザの動作によってまたはユーザからの受信音声に従って行動する際のヒューマンアシスタントの動作によって判断される。音声認識および意味構文解析の正確性は、より多くの「正しい」出力を作成し、かつ、「間違った」出力を最小化するようにシステムを調整するために、機械学習アルゴリズムへの入力として使用することができる。ＡＳＲ結果、意味構文解析出力、エージェントの動作および正確性測定はすべてユーザ入力文章の「注釈」である。

ユーザ発声は、入力チャネルとして使用されているデバイスからのメタデータを有する。携帯電話は、ジオロケーション計測、速度データ、加速度データ、温度測定、高度計測、周囲騒音測定、携帯電話アイデンティティ、電話番号、および、通話の間にネットワークに伝達される他のインジケータを有する。これらのデータは、発声のメタデータとして使用することができ、例えば、話し手の可能性のあるアクセントまたは言語は何か、ユーザがトラフィックの対応に忙しいかどうかまたは他の識別特性を示す。また、これらのデータは、ある変数の存在下で特定の応答の確率を調整することができる機械学習アルゴリズムへの生の入力として使用することもできる（例えば、銃の展示会についての質問は、ミシシッピ州よりもマサチューセッツ州の方が少ない）。

より粗いレベルでは、現在のシステムの「カード」は、タスクを完了するために行わなければならないすべてのものを定義する。カードは、他のサブ要素を参照する。例えば、「Ｅメールを書く」というカードは、宛先、差出人、件名およびテキストフィールドを定義するためのサブ要素を有する。機械学習アルゴリズムは、特定のユーザの場合、宛先の値がホワイトハウスであり、差出人がこの特定のユーザであり、件名が議決権であることや、音声認識装置が否定的な言葉よりむしろ肯定的な言葉寄りの姿勢であるべきであることを学習することができる。この事例では、サブカードの値は今のところ、カード自体のメタデータであり、カードを完成させるというシステムの性能を最適化するために使用することができる。

当然ながら、メタデータは、複合注釈として使用することもできる。音声認識テキスト材料はすべて、音声認識装置を最適化するために使用することができる。実際のテキストをより可能性が高いものにすることに加えて、そのような訓練は、未知の言葉（音声認識辞書にはないもの）を識別することおよび音声認識知識ベースに未知の言葉を追加することを試みることができる。

ユーザの全人口にわたってカードと関連付けられた活動を追跡することにより、以前のステップを考慮して、完了すべき次のステップのより良い予測が可能になる。このタイプの予測は、よりふさわしいガイダンスをヒューマンエージェントに提供することができ、十分予想可能な場合は、以前はヒューマンアシスタントによって行われていたシステム活動の自動化を可能にすることができる。

条件およびユーザ人口は変化するため、世界は進化し続けるため、ならびに、システム自体がユーザとアシスタントとの間の対話をどのように最適化するかを学習するため、注意深い補助システムによって提供される活動および注釈の豊富なセットは、時間の経過と共に変化する。各対話のデータの完全な記録により、特定のいかなるデータ要素も注釈として扱うことができる。

図１に示されるシステムは、ユーザに通信補助を提供するためのものを含めて、様々な状況において使用することができる。例えば、外部の統合セクション１１０は、電話システムを統合するコンポーネントを含みうる。それにより、通話受信に関連するイベントは、受信した通話の処理に関連するユーザとのダイアログを開始することができる。システムの使用のための別の状況は、例えば、ユーザによるシステムの呼び出しや、電話システムに結合された音声統合コンポーネントを介してシステムによって処理される電話音声対話を伴う、電話注文または問い合わせへの自動電話応答におけるものである。多くの状況では、アプリケーション統合コンポーネントは、ユーザの代わりに情報を得るかまたは動作（例えば、ピザの注文）を引き起こすために、ウェブベースのサービスとインタフェースを取ることができる。

システムの実装形態は、１つまたは複数のコンピュータを制御する指令（非一時的な機械可読媒体上に格納される）を含むソフトウェアを使用することができる。例えば、図１に示される機能は、単一のコンピュータ上で実行することも、例えばデータネットワーク上で通信する複数のコンピュータ上で分割して実行することもできる。いくつかの複数のコンピュータの実装形態では、あるコンポーネントは、コンピュータでまたはユーザの場所における他のコンピューティングデバイス（例えば、音声統合コンポーネント）でホストすることができる一方で、他のコンポーネントは、ユーザから離れた１つまたは複数の場所におけるサーバコンピュータ上でホストすることができる。上記で説明される訓練の機能は、さらなる他のコンピュータ上でホストすることができ、必ずしもユーザに関与するダイアログの実施に関与する必要はない。単一のユーザの環境下で説明されているが、複数のユーザおよび複数のダイアログを同時にサポートし、ダイアログを独立して効果的に操作するために適切な分離を維持するようにシステムを構成してもよい。いくつかのシステムは、単一のダイアログで、複数のユーザとの対話をサポートすることができる。

前述の説明は、例示することを意図し、本発明の範囲を制限することを意図せず、本発明の範囲は、添付の請求項の範囲によって定義されることを理解されたい。他の実施形態は、以下の請求項の範囲内にある。

Claims (18)

1. ユーザに言語インタフェースを提供するための第１の統合コンポーネントを含む統合セクションと、
   前記第１の統合コンポーネントからの言語イベントを処理するためのパーサを含むイベント処理セクションと、
   前記イベント処理セクションから代替の出力を受信し、動作を選択し、前記受信した代替の出力に基づいて前記動作を実行させるように構成されたダイアログマネージャと
   を含む対話システムであって、
   前記ユーザとの対話のダイアログ状態のためのストレージをさらに含み、前記イベント処理セクションからの前記代替の出力が、現在のダイアログ状態から次のダイアログ状態への代替の移行を表す、対話システムであり、
   複数のテンプレートのためのストレージをさらに含み、各ダイアログ状態が、前記テンプレートの１つまたは複数のインスタンスの相互関係の観点から定義される、対話システム。
2. 前記パーサは、前記代替の出力を決定するために、現在のダイアログ状態および複数の前記テンプレートに従って言語入力を処理するように構成されている、請求項１に記載のシステム。
3. 前記テンプレートは、複数の入力フィールドおよび前記入力フィールドから演算可能な出力を定義する、請求項２に記載のシステム。
4. 前記テンプレートは、複数の動作を指定する、請求項３に記載のシステム。
5. 前記パーサは、前記現在のダイアログ状態の変更形態として前記代替の出力を決定するようにさらに構成されている、請求項２に記載のシステム。
6. 前記現在のダイアログ状態の前記変更形態は、前記現在のダイアログ状態のテンプレートのインスタンスの相互関係の変化、テンプレートのインスタンスの追加または除去、および、テンプレートのインスタンスの入力フィールド値の設定の少なくとも１つを表す、請求項５に記載のシステム。
7. 前記代替の出力の少なくともいくつかの各々は、１つまたは複数の動作と関連付けられ、前記ダイアログマネージャは、前記代替の出力に従って動作を選択するように構成されている、請求項２に記載のシステム。
8. 前記第１の統合コンポーネントは、前記ユーザから音声入力を受信し、前記パーサに対するテキストベースの言語イベントを決定するように構成された自動音声認識装置を含む、請求項１に記載のシステム。
9. 前記統合セクションは、外部のアプリケーションとのインタフェースおよび前記イベント処理セクションにアプリケーション関連イベントを提供するアプリケーション統合コンポーネントをさらに含む、請求項１に記載のシステム。
10. 前記アプリケーション関連イベントは、ユーザインタフェースイベント、コミュニケーションイベントおよびデータアクセスイベントの少なくとも１つを含む、請求項９に記載のシステム。
11. 顕著な情報を記憶するストレージをさらに含み、前記イベント処理セクションによって受信されたイベントの処理に従って前記顕著な情報を更新するように構成され、前記パーサが、前記イベント処理セクションによって処理された以前のイベントから決定された顕著な特徴の情報を使用して言語入力を処理するように構成されている、請求項１に記載のシステム。
12. 前記ダイアログマネージャは、前記代替の出力に従って動作を選択する機械学習コンポーネントを含む、請求項１に記載のシステム。
13. 対話システムの複数のコンポーネントのパラメータ値を決定する方法であって、前記システムはイベントのシーケンスを処理するように構成され、前記イベントは言語イベントおよびアプリケーション関連イベントを含み、前記イベントの処理は、言語イベントを構文解析することと、ダイアログ状態のシーケンスを決定すること、および、前記ダイアログ状態のシーケンスに対応するイベントのシーケンスから出力動作のシーケンスを決定することを含み、
    複数のイベントのシーケンスおよび対応する出力動作のシーケンスを収集するステップと、
    反復を繰り返すステップであって、前記各反復は、
    前記システムの現在のパラメータ値を使用して前記イベントのシーケンスを処理し、かつ、前記イベントのシーケンスからダイアログ状態のシーケンスを決定すると、
    前記ダイアログ状態のシーケンスから出力動作のシーケンスを決定することと、
    前記システムの複数の前記コンポーネントのパラメータ値を更新するために、前記決定された出力動作のシーケンスと前記収集された出力動作のシーケンスとの比較を使用することと、によって、イベントのシーケンスおよび対応する出力動作のシーケンスを処理することを含み、
    伝導の終了に達したとき、前記反復の前記繰り返しを完了するステップと、
    前記反復の結果を使用して、前記システムの複数の前記コンポーネントの前記パラメータ値を設定するステップと
    を含む、方法。
14. 前記言語イベントは、音声発声を含み、前記処理は、前記音声発声のテキストベースの表現を生成する自動音声認識を含む、請求項１３に記載の方法。
15. 前記システムの前記コンポーネントは、自動音声認識装置、パーサ、前記パーサによって提案される動作を選択するダイアログマネージャの少なくとも１つを含む、請求項１３に記載の方法。
16. 前記コンポーネントの前記パラメータは、ニューラルネットワークパラメータおよび／または機械学習パラメータを含む、請求項１５に記載の方法。
17. ユーザの言葉の発声を表す受信データストリングを処理する通信補助システムであって、
    前記ユーザからの前記受信データストリングを処理する自動音声認識システムと、
    前記言葉の発声に応答して前記ユーザの動作可能性を作成するダイアログマネージャと、
    前記動作可能性を前記ユーザに伝達しかつオーディオ出力が生成される出力データストリングを生成するテキスト／音声システムと、
    前記受信データストリングおよび前記対応する出力データストリングを記録し、かつ、対応するメタデータを用いてそれぞれに注釈をつけるデータ記録システムと、
    通信補助システムの性能を向上させるために、前記データ記録システムによって記録された注釈付きデータを使用する機械学習システムと、
    を含む、システム。
18. ユーザの言葉の発声を表すデータストリングを処理する方法であって、
    前記ユーザからの前記受信データストリングに対して音声認識を実行するステップと、
    前記言葉の発声に応答して前記ユーザの動作可能性を作成するステップと、
    前記動作可能性から、前記動作可能性を前記ユーザに伝達しかつオーディオ出力が生成される出力データストリングを生成するステップと、
    向上した性能を得るために、データ記録システムによって記録された注釈付きデータを処理するために機械学習を採用するステップと、
    を含む、方法。

Images