JP2019079034A - 自己学習自然言語理解を伴うダイアログ・システム - Google Patents

Abstract

【課題】ユーザ対システムの実際のダイアログ・ログから自然言語理解（ＮＬＵ）モデルを学習することができるダイアログ・システムを提供する。【解決手段】ダイアログ・システム１０００は、タッチ・パッド１０１０およびキーボード１０２０などの入力インターフェースを利用して、ユーザ入力を受け取る。マイクロフォン１０３０が、ユーザ・スピーチを受信する。自動スピーチ・レコグナイザ（ＡＳＲ）１０４０は、マイクロフォンによって入手されたユーザ発話のサウンド信号をテキストへ変換する。音響モデル１０５０および言語モデル１０６０は、ＡＳＲにおいて利用されるデータを含む。【選択図】図１

Description

本開示は、全般的にはダイアログ・システムに関連しており、より具体的には、ユーザ対システムの実際のダイアログ・ログから自然言語理解（ＮＬＵ）モデルを学習することができるダイアログ・システムに関連している。

関連した技術分野の実施態様は、有限状態トランスデューサを利用するＮＬＵアルゴリズムを含み、ＮＬＵモデルは、ＮＬＵ結果上でのユーザ応答を使用することによって自動的に更新および改善される（すなわち、自己学習ＮＬＵ）。併せて、関連した技術分野の実施態様は、「ダイアログ途絶」ディテクタを利用することによって保持されるダイアログ・システムを含むことができる。ダイアログ途絶ディテクタは、ユーザがダイアログ・システムとの会話を進めることができない状況を検知する。ダイアログ途絶ディテクタはまた、ダイアログ途絶の理由を識別し、その理由は、ＮＬＵエラー、自動スピーチ認識（ＡＳＲ）エラー、ダイアログ制御エラーなどを含み得る。識別された理由は、ダイアログ・ログに付加される。関連した技術分野の実施態様では、人間の保守管理者が、関心のあるダイアログ・ログを選ぶことができ、それは、人間対システムの将来の会話におけるダイアログ途絶を回避するために、ダイアログ・システムに関連しているＮＬＵモデルまたはその他のプログラム／データを改善することができる。

関連した技術分野では、自動的にＮＬＵエラーを検知するダイアログ・システムがある。ダイアログ・システムがＮＬＵエラーを検知した場合には、システムは、ＮＬＵ結果が正しいかどうかをユーザに確認する発話を出力する。ＮＬＵ結果が間違っていることをユーザが示した場合には、システムは、ユーザを人間のオペレータとつなぎ、それによってユーザは、人間のオペレータと直接対話して、ユーザのタスクを達成することができる。

ダイアログ・システムは、ダイアログ・システム内に格納されている限られた知識に起因して、ダイアログ・システムにおけるＮＬＵモジュールがユーザ発話を理解することに失敗する状況に直面する場合がある。たとえダイアログ・システムが、実際のユーザ応答を利用することによって自動的に自分のＮＬＵモジュールを更新することができるとしても、限られたユーザ応答および限られた知識から正しいＮＬＵ結果をダイアログ・システムが知ることは、やはり困難である。

サーバが利用される場合には、ダイアログ・システム（すなわちクライアント側）よりも豊かな知識が提供されて、ユーザ発話およびユーザ・フィードバック上でのさらに正確なＮＬＵプロセスを達成することが可能である。加えて、サーバは、サーバに接続している多くのダイアログ・システムからユーザ・フィードバックおよびダイアログ・ログを収集することができる。したがって、そのような実施態様は、そのようなさまざまな情報を利用することによってＮＬＵを改善することができる。

したがって、サーバは、特に自己学習ＮＬＵが組み込まれることになる場合には、クライアント側のダイアログ・システムにおいて進行中のダイアログを補助することができる。しかしながら、クライアント側およびサーバ側でダイアログ・システム同士を統合することは簡単ではない。本明細書において記述されている例示的な実施態様は、下記のような制限に対処する。

１）ダイアログ・システムがクラウド・サーバにアクセスする際のタイミング制御。サーバは、ダイアログ・システムよりも多くの知識を有しており、したがってサーバは、ダイアログ・システムと比べて、正しいＮＬＵ結果を提供する可能性がより高い。しかしながら、ユーザが何かを言うたびにダイアログ・システムがサーバにアクセスする場合には、ネットワーク・スピードの限界に起因して、ユーザ発話からシステム発話までの応答時間がより長くなる。より長い応答時間は、会話上でのユーザの不満を引き起こす。この制限に対処するために、例示的な実施態様は、ダイアログ・システムがサーバに質問を行うべきである最適なタイミングを、ダイアログ・システム内のダイアログ履歴（ダイアログ・ログ）およびＮＬＵ結果に基づいて特定する。

２）サーバから送信された更新情報を使用することによってダイアログ・システム上のＮＬＵ知識を更新すること。クラウド・サーバは、多くのダイアログ・システムから入手された大規模なダイアログ履歴を管理する。したがって、サーバにおいて生成されたＮＬＵ更新に関する情報は、ダイアログ・システムのＮＬＵ精度を改善することができる。しかしながら、特定のユーザたちに関しては、ＮＬＵ精度の劣化が生じる可能性がある。サーバからのＮＬＵ更新情報は、特定のユーザたちが好んでいるダイアログ・システムにおけるＮＬＵルールを上書きする可能性があるので、ダイアログ・システムは、そのような特定のユーザたちがダイアログ・システムに対して前に述べていたユーザ発話を急に理解できなくなる可能性があり、それはユーザ経験における劣化である。例示的な実施態様は、サーバによって提供されるＮＬＵ更新情報を利用することによってＮＬＵ精度を改善しながら、そのようなＮＬＵの劣化を回避する。

３）ユーザ・フィードバックの不確実性を管理すること。実際の人間対マシンの会話中に入手されるユーザ・フィードバックは、ＮＬＵモデルを改善するための有用な情報を含む。しかしながらユーザ・フィードバックは、不適切なフィードバックを含むこともあり、そうした不適切なフィードバックは、有用ではないか、またはＮＬＵ精度という形式での劣化を引き起こす。したがってユーザ・フィードバック情報は、確実性の度合いという点から評価されるべきである。例示的な実施態様は、ユーザ・フィードバックの信頼性を推定し、そのようなユーザ・フィードバックをＮＬＵモデルの改善のためにどのようにして利用するかを特定する。

本開示の態様は、ユーザ入力を受け取るためのテキスト入力方法およびサーバと通信するように構成されている第１の自然言語理解（ＮＬＵ）モデルと共に構成され、ユーザ入力は、ユーザによってタイプされたテキスト入力またはユーザ・スピーチから入手された自動スピーチ認識（ＡＳＲ）出力のうちの少なくとも１つを含む、クライアント・デバイスと、第２のＮＬＵモデルを管理するサーバとを含むダイアログ・システムのための方法を含むことができ、第１のＮＬＵモデルと第２のＮＬＵモデルとは異なる。この方法は、第１のＮＬＵモデルを適用することからクライアント・デバイスにおける入力ダイアログのＮＬＵ結果を特定するステップと、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果の確信性スコアがしきい値を満たしていない場合、入力ダイアログ上で第２のＮＬＵモデルを使用することによってＮＬＵプロセスを実行するためにサーバにアクセスすることをクライアント・デバイスに行わせるステップと、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果の確信性スコアがしきい値を満たしている場合、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果に基づくアクションをクライアント・デバイスに実行させるステップとを含むことができる。

本開示の態様は、ユーザ入力を受け取るためのテキスト入力方法およびサーバとの間で通信するように構成されている第１の自然言語理解（ＮＬＵ）モデルと共に構成され、ユーザ入力は、ユーザによってタイプされたテキスト入力またはユーザ・スピーチから入手された自動スピーチ認識（ＡＳＲ）出力のうちの少なくとも１つを含む、クライアント・デバイスと、第２のＮＬＵモデルを管理するサーバとを含むダイアログ・システムのための命令を格納している非一時的コンピュータ可読メディアを含むことができ、第１のＮＬＵモデルと第２のＮＬＵモデルとは異なる。それらの命令は、第１のＮＬＵモデルを適用することからクライアント・デバイスにおける入力ダイアログのＮＬＵ結果を特定するステップと、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果の確信性スコアがしきい値を満たしていない場合、入力ダイアログ上で第２のＮＬＵモデルを使用することによってＮＬＵプロセスを実行するためにサーバにアクセスすることをクライアント・デバイスに行わせるステップと、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果の確信性スコアがしきい値を満たしている場合、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果に基づくアクションをクライアント・デバイスに実行させるステップとを含むことができる。

例示的な一実施態様によるダイアログ・システムのコンポーネントを示す図である。 例示的な一実施態様による、例示的なダイアログ・シナリオを示す図である。 例示的な一実施態様による、サーバのコンポーネントを示す図である。 例示的な一実施態様による、ダイアログ・システムのプロセス・フローを示す図である。 例示的な一実施態様による、ダイアログ・システムのプロセス・フローを示す図である。 例示的な一実施態様による、ＦＳＴベースのＮＬＵの例示的なフローを示す図である。 例示的な一実施態様による、ＦＳＴベースのＮＬＵに関するＮＬＵモデルを示す図である。 例示的な一実施態様による、ＦＳＴベースのＮＬＵに関連している詳細なデータ・フローを示す図である。 例示的な一実施態様による、ＮＬＵ出力を分類するための例示的なフローを示す図である。 例示的な一実施態様による、サーバがクエリされる必要があるかどうかに関する例示的なフローを示す図である。 例示的な一実施態様による、サーバに関する例示的なフローを示す図である。 例示的な一実施態様による、ダイアログ・システムに関する例示的なフローを示す図である。 例示的な一実施態様による、ダイアログ確認の例を示す図である。 例示的な一実施態様による、アップロードされたユーザ応答上での分析のためのサーバに関する例示的なフローを示す図である。 例示的な一実施態様による、モデルを更新するためのフローを示す図である。 例示的な一実施態様によるＮＬＵプロセスに関する例示的なフローを示す図である。 例示的な一実施態様による、ＦＳＴ変換モデルを示す図である。 例示的な一実施態様による、ＲＮＮベースのＮＬＵに関するトレーニング・データを示す図である。 図１８（ａ）は、例示的な一実施態様による、リカレント・ニューラル・ネットワーク（ＲＮＮ）、およびそのＲＮＮが推定を使用することを示す図である。図１８（ｂ）は、例示的な一実施態様による、リカレント・ニューラル・ネットワーク（ＲＮＮ）、およびそのＲＮＮがトレーニングを使用することを示す図である。 例示的な一実施態様による、ＲＮＮへのＮ−ｂｅｓｔ ＡＳＲ入力を達成するための例示的なフローを示す図である。 例示的な一実施態様による、ＲＮＮベースのＮＬＵの例示的なフローを示す図である。 例示的な一実施態様による、ユーザ・フィードバックを使用することによるＮＬＵ更新の例示的なフローを示す図である。 図２２（ａ）は、例示的な一実施態様による、ダイアログ・システムがサーバから更新を受信した場合にダイアログ・システムにおいてＮＬＵモデルを更新する例示的な手順を示す図である。図２２（ｂ）は、例示的な一実施態様による、ダイアログ・システムがサーバから更新を受信した場合にダイアログ・システムにおいてＮＬＵモデルを更新する例示的な手順を示す図である。 例示的な一実施態様による、ＦＳＴベースのＮＬＵおよびＲＮＮベースのＮＬＵがいつ組み合わされるかに関する例示的なフローを示す図である。 例示的な一実施態様による、Ｎ−ｂｅｓｔ ＡＳＲ出力からフィードバック情報をどのようにして生成するかを示す図である。 例示的な一実施態様による、サーバにおいてフィードバック・タプルを使用することによってシードをどのようにして更新するかを示す図である。 例示的な一実施態様による、サーバにおいてフィードバック・トレーニング・データを使用することによってＲＮＮベースのＮＬＵのトレーニング・データを更新するためのフローを示す図である。 例示的な一実施態様による、イントピックＮＬＵおよびアウトオブトピックＮＬＵを組み合わせるＮＬＵアルゴリズムに関するフローを示す図である。 図２８（ａ）は、例示的な一実施態様による、システム・ダイアログ発話システムに関するシステム図である。図２８（ｂ）は、例示的な一実施態様による、システム・ダイアログ発話システムに関するシステム図である。 例示的な一実施態様による、ＲＮＮセルを使用する例示的なエンコーダ／デコーダ・モデルを示す図である。 図３０（ａ）は、例示的な一実施態様による、発話変換のプロセスを示す図である。図３０（ｂ）は、例示的な一実施態様による、発話変換のプロセスを示す図である。 例示的な一実施態様による、トレーニングのための発話対発話コーパスを示す図である。 例示的な一実施態様による、例示的な発話変換モデルを示す図である。 例示的な一実施態様による、ユーザ・ダイアログ行為を予測するための手順を示す図である。 いくつかの例示的な実施態様における使用に適している例示的なコンピュータ・デバイスを伴う例示的なコンピューティング環境を示す図である。 例示的な一実施態様による、ロボットなどのクライアント・デバイスに関する例示的なハードウェア図である。 例示的な一実施態様によるＦＳＴベースのＮＬＵおよびＲＮＮベースのＮＬＵの結果から適切なダイアログ行為を選択するための別の例を示す図である。

以降の詳細な説明は、本出願の図および例示的な実施態様のさらなる詳細を提供する。図間における重複した要素の参照番号および説明は、明確さのために省略されている。この説明を通じて使用されている用語は、例として提供されており、限定的であることを意図されているものではない。たとえば、「自動的な」という用語の使用は、本出願の実施態様を実践する当技術分野における標準的な技術者の所望の実施態様に応じて、その実施態様の特定の側面に対するユーザまたは管理者の制御を含む完全に自動的なまたは半自動的な実施態様を含み得る。選択は、ユーザ・インターフェースまたはその他の入力手段を通じてユーザによって行われることが可能であり、または所望のアルゴリズムを通じて実施されることが可能である。本明細書において記述されている例示的な実施態様は、単独でまたは組合せで利用されることが可能であり、例示的な実施態様の機能は、所望の実施態様に従って任意の手段を通じて実施されることが可能である。

第１の例示的な実施態様では、有限状態トランスデューサ（ＦＳＴ）ベースのＮＬＵを利用するダイアログ・システム構成がある。

（１） ダイアログ・システムおよびクラウド・サーバのコンポーネント

図１は、例示的な一実施態様によるダイアログ・システム１０００のコンポーネントを示している。タッチ・パッド１０１０およびキーボード１０２０などの入力インターフェースを利用して、ユーザ入力を受け取ることができる。マイクロフォン１０３０が、ユーザ・スピーチを受信する。自動スピーチ・レコグナイザ（ＡＳＲ）１０４０は、マイクロフォンによって入手されたユーザ発話のサウンド信号をテキストへ変換する。音響モデル１０５０および言語モデル１０６０は、ＡＳＲにおいて利用されるデータを含む。ダイアログ・システム１０００は、スピーチまたはタイピングからユーザ入力を受け取ることができる。本明細書において記述されている例示的な実施態様では、ユーザ入力のテキストは、基礎をなす入力がスピーチによるかタイピングによるかにかかわらず、「発話」と呼ばれる。自然言語理解モジュール（ＮＬＵ）１０７０は、発話をダイアログ行為へ変換する。ダイアログ行為は、ユーザがダイアログ・システム１０００と通信することによって行いたいことを表す。例示的な一実施態様では、ダイアログ・システムが、ユーザへのレストラン情報ガイダンスのために作成されていると想定する。下記は、ユーザ発話および対応するダイアログ行為のいくつかの例である。

１つの発話は、１つダイアログ行為だけでなく複数のダイアログ行為も有する場合がある。たとえば、ユーザが、「Ｉ ｗａｎｔ ｔｏ ｋｎｏｗ Ｃｈｉｎｅｓｅ ｒｅｓｔａｕｒａｎｔｓ ｉｎ ｔｈｅ ｎｏｒｔｈ（北にある中華レストランを知りたいです）」と述べている場合には、この発話は、ｉｎｆｏｒｍ（ｆｏｏｄ＝ｃｈｉｎｅｓｅ）およびｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）という２つのダイアログ行為を含む。等号から右の部分（すなわち、「ａｒｅａ＝ｎｏｒｔｈ」における「ｎｏｒｔｈ」）は、以降では「値」と呼ばれる。本明細書において記述されている例示的な実施態様では、ダイアログ行為は、事前に定義されていると仮定されるが、本開示は、それに限定されるものではない。たとえば、ダイアログ行為の値は、対応する述べられたワードを値へコピーすること、またはその他の任意の所望の実施態様を使用するその他のワード／値変換方法によって、その対応するワードから得ることができる。

ＮＬＵモデル１０８０は、ＮＬＵを達成するために必要であるデータを含む。ＮＬＵモデルのタイプは、システムが採用するＮＬＵアルゴリズムに基づいて特定される。第１の例示的な実施態様では、ＮＬＵアルゴリズムは、ＦＳＴに基づいている。

ダイアログ制御１０９０は、人間とダイアログ・システムとの間における情報フローを制御する。ダイアログ制御は、自分のダイアログ・フローをダイアログ・シナリオ１１００に沿って制御する。ダイアログ・シナリオの一例が、図２に示されている。ダイアログ・シナリオは、システム・アクション、それぞれのシステム・アクションの後の予想されるダイアログ行為、およびそれぞれのユーザ・ダイアログ行為に対応する状態遷移ルールを含む。図２では、たとえば、システム・アクションは、「Ｈｏｗ ｍａｙ Ｉ ｈｅｌｐ ｙｏｕ？（どのようなご用件でしょうか？）」と言うことであることを１つの状態２０１０が示している。予想されるユーザ・ダイアログ行為は、ｉｎｆｏｒｍ（ａｒｅａ＝ｓｏｕｔｈ）、ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）、ｉｎｆｏｒｍ（ｆｏｏｄ＝Ｃｈｉｎｅｓｅ）などである。ユーザ・ダイアログ行為がｉｎｆｏｒｍ（ａｒｅａ＝ｓｏｕｔｈ）である場合には、ダイアログ状態遷移が、ｉｎｆｏｒｍ（ａｒｅａ＝ｓｏｕｔｈ）というダイアログ行為に対応するアークを介して生じ、次いで状態２０２０に達し、そこではシステム・アクションは、「（Ｎａｍｅ） ｉｓ ａ ｇｏｏｄ ｒｅｓｔａｕｒａｎｔ ｉｎ ｓｏｕｔｈ ａｒｅａ（（名前）が、南のエリアにあるよいレストランです）」と言うことである。（Ｎａｍｅ）は、アプリケーション１１０８およびデータベース１１０９上でレストラン情報検索を行うことによって入手された実際のレストラン名によって置き換えられる。次いで、この状態でのシステム発話が、ダイアログ・システムから出力されることになる。

ダイアログ履歴１０９０は、前のシステム・アクションおよび対応するユーザ発話またはユーザ入力を格納する。ダイアログ履歴１０９０はまた、それぞれのユーザ発話のダイアログ行為、それぞれのシステム発話のダイアログ行為、およびその他の情報を含む。ダイアログ行為プレディクタ１１０７は、ダイアログ履歴を考慮してユーザの予想されるその後のダイアログ行為を予測する。ダイアログ行為プレディクタの詳細については、後ほど記述する。ユーザ・フィードバック１１１０は、ダイアログ・システムから提供されるＮＬＵ結果が正しいか否かを確認するためにダイアログ・システムによって導き出される確認ダイアログに対するユーザ発話を格納する。ＮＬＵトレーナ１１７０は、ユーザ・フィードバックを使用することによってＮＬＵモデルをトレーニングし、次いでそれをＮＬＵモデルに格納する。

スピーチ・シンセサイザ１１２０は、システム発話からスピーチ信号を作成する。作成されたスピーチ信号は、ダイアログ・システムのスピーカ機器から再生されることになり、次いでユーザは、そのシステム発話を聴くことができる。アクション・メーカー１１３０は、スピーチ・シンセサイザと比べると、ダイアログ・システムのその他の任意のアクションを作成し、それらのアクションは、ロボットのジェスチャ、ロボットの動き、表示されることになる画像または図面を含む。ロボット１１４０、仮想エージェント１１５０、およびディスプレイ１１６０は、ユーザに情報を提供するためのダイアログ・システムの出力デバイスである。

ユーザ識別子１１７５は、ダイアログ・システムと通信するユーザを識別する。このユーザ識別は、音声ベースの個人識別、顔画像識別、指紋識別、指静脈識別などのような知られている技術を使用することによって行うことができる。所望の実施態様に応じて、ユーザは、個人の無線周波数識別子（ＲＦＩＤ）タグを有することができ、ユーザは、それをロボットまたはその他のデバイスからのセンサ上に置き、それによってシステムは、ユーザを識別することができる。加えて、スマートフォン上で機能する仮想エージェントを介してダイアログが行われる場合には、スマートフォンの所有者情報を利用してユーザを識別することができる。ユーザ・プロフィール１１８０は、ダイアログ・システム上でのそれぞれのユーザの好みを含む。１つのユーザ発話が、別々のユーザにとって別々の意味（別々のダイアログ行為）を有する場合がある。その場合、ＮＬＵモデルは、ユーザ識別結果に基づいて変更されるべきである。したがってユーザ・プロフィールは、それぞれのユーザにとって最適なＮＬＵモデルを含む。ユーザ識別子がユーザを識別すると、次いでシステムは、識別されたユーザが好むＮＬＵモデルを変更する。

図３は、例示的な一実施態様による、サーバ３０００のコンポーネントを示している。サーバは、１つまたは複数のダイアログ・システム３１４０（すなわちダイアログ・システム１０００）と接続している。ＡＳＲ３０１０、音響モデル３０５０、および言語モデル３０６０は、ユーザ・スピーチを認識するための、およびスピーチをテキストへ変換するためのコンポーネントである。ＡＳＲおよび関連したモデル（３０１０、３０５０、３０６０）は、ダイアログ・システムからサーバ３０００へアップロードされたユーザ・スピーチを認識するために使用することができる。ＮＬＵ３０２０およびＮＬＵモデル３０７０は、ユーザ発話からダイアログ行為を入手するように構成されている。ダイアログ・シナリオ３０８０は、図２に示されているような、ダイアログ行為と、次のダイアログ状態およびシステム・アクションとの間におけるルールを含む。ダイアログ履歴３０９０は、サーバに接続している１つまたは複数のダイアログ・システムから入手された、ユーザとダイアログ・システムとの間におけるダイアログ履歴を格納する。ユーザ・フィードバック３１００は、ＮＬＵ結果が正しいことを確認するためのシステム発話に対するユーザ応答を含む。ユーザ・フィードバック３１００は、１つまたは複数のダイアログ・システム３１４０において入手されたユーザ・フィードバックを含む。ユーザ識別子３１１２は、アップロードされた情報（ユーザ・フィードバックおよびダイアログ履歴）に関連しているユーザを、ユーザ・プロフィール３１１０内の情報を使用することを用いて識別する。ユーザ・フィードバックおよびダイアログ履歴上のそれぞれのデータは、誰がダイアログ・システムと話したかを示すユーザ情報を有する上でよりよいと思われる。ダイアログ・システムまたはサーバの両方またはどちらかが、ユーザ識別子を有することができる。ユーザ・プロフィール３１１０はまた、それぞれのユーザ・フィードバックが信頼できるか否かを特定するための情報を含む。ユーザ・プロフィール３１１０は、ユーザの確信値、それぞれのユーザの会話の頻度などを含む。ＮＬＵトレーナ３０４０は、１つまたは複数のダイアログ・システムから収集されたユーザ・フィードバック３１００を使用することによってＮＬＵモデル３０７０をトレーニングして更新する。ダイアログ行為プレディクタ３０３０は、ダイアログ履歴を考慮して、次に来ると予想されるユーザの次のダイアログ行為を予測する。未特定ユーザ発話３１２０は、発話の意図（すなわちダイアログ行為）に関する自動的な識別に失敗したユーザ発話を格納する。３１２０における格納されたユーザ発話は、人間のシステム保守管理者によってチェックされることが可能であり、そしてチェッキング結果は、ダイアログ・システム（ＮＬＵモデル、ダイアログ・シナリオ、およびその他の任意のコンポーネント）を改善するために利用されることになる。

（２）システムのプロセス

図４（ａ）および図４（ｂ）は、例示的な一実施態様による、ダイアログ・システムのプロセス・フローを示している。このフローは、マイクロフォンまたはタイピング機器を介したユーザ発話を待つこと（４０１０）で開始する。次いで、入力がスピーチである場合には、そのスピーチは、テキストへ変換するためにＡＳＲへ入力される（４０２０）。入力がタイピングである場合には、ＡＳＲプロセス４０２０を省くことができる。発話テキストは、ＮＬＵ結果を得るためにＮＬＵへ送信される（４０３０）。ダイアログ・システムのプロセス・フローについては、本明細書ではその他の図に関連してさらに記述する。

第１の例示的な実施態様では、ＦＳＴベースのＮＬＵが利用される。いくつかのＮＬＵアルゴリズムが、発話テキストを受信し、ダイアログ行為と、それぞれのダイアログ行為を表す対応するフレーズとを出力する。ＮＬＵがそのような情報を出力する限り、任意のＮＬＵアルゴリズムが、本発明を達成するために適用可能であり得る（たとえば、リカレント・ニューラル・ネットワーク（ＲＮＮ）、条件付き確率場（ＣＲＦ）、ワード・マッチング、形態素マッチング、手作りのルールによるＮＬＵ）。その他の例示的な実施態様（たとえば、ＲＮＮベースのＮＬＵアルゴリズム）も、本明細書において記述されている。加えて、本明細書における例は、１つの発話が１つだけのダイアログ行為を有すると想定しているが、ユーザ発話におけるすべてのワードが同じダイアログ行為を有することも理にかなっている。その場合、発話分類タスクが得意であるＮＬＵアルゴリズムを適用することもできる（サポート・ベクター・マシン（ＳＶＭ）、ロジスティック回帰、スタックト・ニューラル・ネットワークなど）。

図５は、例示的な一実施態様による、ＦＳＴベースのＮＬＵの例示的なフローを示している。図６は、例示的な一実施態様による、ＦＳＴベースのＮＬＵに関するＮＬＵモデルを示している。図７は、例示的な一実施態様による、ＦＳＴベースのＮＬＵに関連している詳細なデータ・フローを示している。

ＮＬＵモデル（図６）は、シード６０１０およびセマンティック空間６０７０を含む。シード６０１０は、ダイアログ行為６０２０および「チャンク」６０３０を示すテーブルである。したがって、テーブル内のそれぞれの行は、「ダイアログ行為／チャンク・ペア」と呼ばれる。例示的な実施態様では、シード６０１０は、はじめに人間の開発者によって開発され、次いで、本明細書において記述されているようなユーザとのシステム会話経験に基づいて新たな／更新されたダイアログ行為／チャンク・ペアを学習する自動的な自己学習アルゴリズムをＮＬＵ上に組み込むことによって改善され豊かにされる。チャンクは、対応するダイアログ行為をユーザが示す際にユーザによって述べられると予想される、ユーザの発話の部分的なワードまたは全体的なワードである。セマンティック空間６０７０は、２つのワード／フレーズのペアが、それらの２つのワード／フレーズが類似の意味を有する場合に互いにさらに近いポイントに配置される空間を記述している。セマンティック空間は、知られているワード埋め込み技術、センテンス埋め込み技術、ワード意味データベースから得られたワード意味情報、シソーラスを使用することによって、または所望の実施態様に従ってその他の方法を通じて構築することができる。

図５のフローでは、はじめに、このフローは、ユーザ識別結果、現在のダイアログ・タスク、および現在のダイアログ履歴にとって適切であるＮＬＵモデルをロードする（５００５）。ユーザ識別結果は、ダイアログ・システムと話しているそれぞれのユーザに適しているＮＬＵモデルを選択する助けになる。ダイアログ行為の種類は、タスクのタイプに応じて変更される。たとえば、ダイアログ・システムがレストラン予約タスクを対象としている場合には、ユーザは、レストランのフード・タイプを知らせるためのワード（たとえば、ｉｎｆｏｒｍ（ｆｏｏｄ＝．．．）というダイアログ行為）を述べる可能性がある。しかしながら、ダイアログ・システムが航空機チケット予約タスクを対象としている場合には、ｉｎｆｏｒｍ（ｆｏｏｄ＝．．．）というダイアログ行為は、ユーザから述べられそうもないであろう。したがって、例示的な実施態様は、タスクの種類に応じて、ロードされることになるＮＬＵモデルを変更する。

加えて、たとえシステムが１つだけのタスクを対象としていても、ユーザが述べる可能性があるダイアログ行為が、ダイアログ状態またはダイアログ履歴に応じて変更されることになる場合があり得る。さらに、それぞれのユーザは、ＮＬＵ上に自分自身の痕跡を有する。たとえば、あるユーザは通常、否定のダイアログ行為を表すために「ｎａｙ（いや）」と言うが、その他のユーザは、「ｒａｔｈｅｒ ｔｈａｎ（〜よりもむしろ）」という意味を表すために「ｎａｙ（いや）」を使用し、否定のダイアログ行為を表すためにそれを言うことはないかもしれない。その場合、ＮＬＵモデルは、それぞれのユーザ向けにカスタマイズされるべきであり、すなわちダイアログ・システムは、それぞれのユーザごとに別々のＮＬＵモデルを用意する。したがって、ダイアログ・システムが複数の種類のＮＬＵモデルを有すると想定すると、このシステムの例示的な実施態様は、ユーザ識別結果、現在のダイアログ・タスク、およびダイアログ履歴に基づいて、最も適切なＮＬＵモデルをロードすることができる。さらに、そのような例示的な実施態様は、ＮＬＵモデルの数が１つだけである場合に実現することができる。

次いでユーザ発話は、有限状態トランスデューサ（発話ＦＳＴ）へ変換されることになる（５０１０）。図７は、発話７０１０の発話ＦＳＴ７０２０の一例を示している。１つのアークが、発話における１つのチャンクを示している。ＦＳＴのアークは、発話における任意の数のワードのすべての組合せを含む。ダイアログ・システムの計算上の限界に起因して、１つのアークに関するワードの最大数を制限するために制約を設定することができる。次いで、発話におけるすべてのチャンクを見るために反復が開始する（５０２０）。着目されているチャンクがシード内に含まれている（５０３０）（ｙｅｓ）場合には、そのチャンクは、対応するダイアログ行為およびその関連性値６０４０と結び付けられる（５０４０）。関連性値６０４０は、チャンクとダイアログ行為との間における関係がどれぐらい強いかを示す。ＦＳＴ５０１０において、「ｎｏｒｔｈ ａｒｅａ」というチャンクは、「ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）」というダイアログ行為と結び付けられる。なぜなら、シード内の「ｎｏｒｔｈ ａｒｅａ」というチャンクは、「ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）」というダイアログ行為との間で０．９という関連性値を有するからである。ＦＳＴ内の対応するチャンクは、関連性値に基づいて特定された重みを有することになる。この例示的な実施態様では、シード内の元の関連性値（すなわち０．９）にチャンク内のワードの数（すなわち２）を乗じることによって、重み値が採用される。関連性値にチャンク内のワードの数を乗じることを通じて、より長いワードから入手されたダイアログ行為は、より短いワードから入手されたダイアログ行為に比べて、より確信を持てる。乗算された値は、ＦＳＴの重みとみなすことができる。加えて、ＡＳＲは、それぞれの認識されたワードの確信値を出力する。したがって、チャンクの重みは、チャンク内のワードのＡＳＲ確信値に応じて調整されることになる。後ほど説明するが、ＦＳＴ内で最短経路探索を行うことによって、最も確信を持てるダイアログ行為が得られることになり、その最短経路探索では、より低い累積重みを有するＦＳＴ経路が抽出されることになる。その理由から、関連性値の負の値が、アークの重みとしてＦＳＴへ供給される。ＦＳＴに関する最短経路探索またはその他の任意の計算方法が、示されている。

ＦＳＴ内のチャンクがシード内のいずれのチャンクとも異なる場合には、ＮＬＵは、セマンティック空間においてＦＳＴ内のチャンクに十分に近いシード内のチャンクを見つけ出すことを試みる（５０５０）。十分さの判断は、しきい値基準によって行うことができ、セマンティック空間内の２つのチャンクの間における距離（類似性）が、事前に定義されたしきい値よりも小さい（大きい）場合には、その距離は十分であると判断される。そのようなチャンクが見つかった（５０６０）（ｙｅｓ）場合には、ＮＬＵは、ＦＳＴ内のチャンクを、ＦＳＴ内のチャンクに十分に近いシード内のチャンクのダイアログ行為および関連性値と結び付ける。たとえば、「ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ（東洋料理）」というフレーズが、シード内の「ａｓｉａｎ ｏｒｉｅｎｔａｌ ｆｏｏｄ（アジア東洋フード）」というチャンクに近いと想定されたい（７０３０）。「ａｓｉａｎ ｏｒｉｅｎｔａｌ ｆｏｏｄ」というチャンクは、「ｉｎｆｏｒｍ（ｆｏｏｄ＝ａｓｉａｎ ｏｒｉｅｎｔａｌ）」という関連のあるダイアログ行為を有する。次いで、ＦＳＴ内の「ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ」というアークは、対応するダイアログ行為を有し、それは、「ｉｎｆｏｒｍ（ｆｏｏｄ＝ａｓｉａｎ ｏｒｉｅｎｔａｌ）」である。この場合、このアークの重みは、シード内の関連性値、セマンティック空間内での「ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ」と「ａｓｉａｎ ｏｒｉｅｎｔａｌ ｆｏｏｄ」との間における距離（類似性）、チャンク内のワードの数など、いくつかの手掛かりによって特定される。

ＦＳＴ内のすべてのチャンクに関してこれらのプロセスを行った後に、ＦＳＴにおいて最短経路探索が実行される（５０７０）。最後に、ＮＬＵは、最短経路から入手されたダイアログ行為を出力する（５０８０）。この例（最短経路探索７０４０、ダイアログ行為出力７０５０）では、ｉｎｆｏｒｍ（ｆｏｏｄ＝ａｓｉａｎ ｏｒｉｅｎｔａｌ）およびｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）という２つのダイアログ行為が出力される。加えて、それぞれのダイアログ行為を導き出すチャンク、およびそれぞれのダイアログ行為のスコア（重みの正の値に等しい）が入手される。ダイアログ行為のスコアは、ダイアログ行為の確信性に関する度合いを示す。

最短経路探索は基本的に、重みの合計が最小化される１つの経路のみを出力する。あるいは、その他のいずれの経路よりも小さい累積重みを有する複数の経路を見つけ出す最短経路探索も、適用可能である。

図４（ａ）におけるフローへ戻ると、上述の方法によってＮＬＵ結果を得た後に、ダイアログ・システムは、入手されたダイアログ行為を、「確信を持てる」、「確認する必要がある」、または「破棄する」に分類する（４０３２）。この分類は、図８に示されている手順に沿って行われることになる。

図８は、例示的な一実施態様による、ＮＬＵ出力を分類するための例示的なフローを示している。はじめに、このフローは、ＮＬＵによって入手されたすべてのダイアログ行為をチェックする（８０１０）。この分類手順は、特定のためのいくつかの基準を含む。したがって、基準のモードに応じて別々のプロセスを実行することができる（８０２０）。第１のモードでは、ダイアログ行為は、そのスコアに基づいて分類される。スコアが、「確信を持てる」に関する事前に定義されたしきい値よりも大きい場合には（８０３０）、それは、「確信を持てる」として分類される（８０６０）。そうでなければ、スコアが、「確認する必要がある」に関する事前に定義されたしきい値よりも大きい場合には（８０４０）、それは、「確認する必要がある」として分類される（８０７０）。そうでなければ、ダイアログ行為は、「破棄する」として分類される（８０５０）。

別のモードでは、ユーザとシステムとの会話においてダイアログ途絶に関する判断がある。ダイアログ途絶を検知するためのいくつかの方法がある。たとえば、前のユーザ発話と同じ発話をユーザが言った場合、それが意味しているのは、システムが理解できなかった意図されている発話をユーザが有しており、したがってユーザはその発話を何回か繰り返したことである。したがって、そのような反復の発話が検知された場合には、ダイアログ途絶が生じていると判断することができる。加えて、ダイアログ途絶の検知を達成するために、任意の所望の実施態様を利用することができる。ダイアログ途絶が検知された場合には（８０８０）、ダイアログ行為は、「確認する必要がある」として分類される。（８０７０）そうでない場合には、ダイアログ行為は、「確信を持てる」として分類される（８０６０）。ダイアログ途絶の検知を利用する方法は、ダイアログ行為のスコアを利用する第１のモードに対する利点を有している。スコアは、不適切な値を示す場合があり、スコアが高くなっているが、ＮＬＵモデルの貧弱な精度に起因してダイアログ行為が実際には間違っている場合がある。したがって、ダイアログ途絶の検知を使用する方法は、第１の方法の欠点を補う。

別のモードでは、例示的な実施態様は、ダイアログ行為の「ソース」、すなわち、シードまたはセマンティック空間に基づく。上述のように、シードは、はじめは人間の開発者によって作成される。加えて、たとえ自動的にシードを更新する自己学習方法をダイアログ・システムが使用していても、シードは、少なくとも１回はユーザによって確認されたダイアログ行為／チャンク・ペアのみを含む。したがって、ダイアログ行為がシードから導き出された場合には、そのダイアログ行為は、十分な確信性を有すると考えられる。その一方で、セマンティック空間から得られるダイアログ行為は、確信を持てる度合いが低いと特定される。なぜなら、これらは、まだユーザによって確認されていないからである。したがって、ダイアログ行為がシードから得られている場合には（８１１０）、そのダイアログ行為は、「確信を持てる」と判断され（８０６０）、そうでない場合には、そのダイアログ行為は、「確認する必要がある」と判断される（８０７０）。

さらに、図８のそのような判断は、単独で、または任意の組合せで実施されるモードのうちのいずれかに基づくことが可能である。

図４（ａ）へ戻ると、ダイアログ行為が分類された後に、システムは、サーバが利用可能であるか否かを判断する（４０３３）。サーバが利用可能である（ｙｅｓ）場合には、フローは４０３４へ進み、そこでシステムは、サーバにアクセスすることが必要であるか否かを判断する。この判断の詳細は、図９に関連して提供される。

図９は、例示的な一実施態様による、サーバがクエリされる必要があるかどうかに関する例示的なフローを示している。サーバにアクセスすることに関するこの判断も、２つのモードを有する（９０１０）。第１のモードでは、例示的な実施態様は、ダイアログ行為スコア上でしきい値を使用する。システムは、すべてのダイアログ行為を参照し（９０２０）、しきい値よりも低いスコアを有しているダイアログ行為を破棄する（９０３０、９０４０）。前のプロセスも、しきい値に基づくそのような破棄プロセス（たとえば８０５０）を有しているが、この場合、サーバは、ダイアログ・システムよりも正確なＮＬＵを有することを期待されている。前の破棄プロセスが行われた時点（８０５０）において、ダイアログ・システムは、サーバが利用可能であるか否かを知らない。しかしながら、この時点（９０４０）において、ダイアログ・システムは、サーバが利用可能であることを既に知っている。したがってダイアログ・システムは、「少し確信を持てない」と特定されているダイアログ行為に関してさらに正確なダイアログ行為推定を実施することになる。したがって例示的な実施態様では、９０４０におけるしきい値は、８０５０よりも大きい。次いで、ダイアログ行為のうちの少なくとも１つが破棄されている場合には、システムは、サーバにアクセスすることが「必要とされている」と判断する（９０５０、９０６０、９０７０）。

第２のモードでは、システムは、発話テキストを解析し、それを１つまたは複数のフレーズに分割する（９０８０）。この解析は、所望の実施態様に従って、当技術分野において知られている任意のパーサによって行うことができる。たとえば、「Ｃｈｉｎｅｓｅ ｆｏｏｄ ｉｎ ｔｈｅ ｎｏｒｔｈ ｐａｒｔ ｔｈａｎｋ ｙｏｕ（北の部分にある中華フードです。ありがとうございます）」という発話が解析される場合には、その発話は、「Ｃｈｉｎｅｓｅ ｆｏｏｄ」、「ｉｎ」、「ｔｈｅ ｎｏｒｔｈ ｐａｒｔ」、「ｔｈａｎｋ」、および「ｙｏｕ」というフレーズに分割される。

次にシステムは、いずれの割り振られたダイアログ行為も有していないフレーズを抽出する（９０９０、９１００、９１１０、９１２０）。次いでシステムは、現在のダイアログ状態においてユーザが言う可能性があるダイアログ行為のうちのすべてを列挙する（９１３０）。このプロセスは、ダイアログ・シナリオを参照することによって図１における１１０７においてダイアログ行為プレディクタによって行われる。ダイアログ・シナリオにおけるそれぞれのダイアログ状態は、いくつかのアーク（すなわちダイアログ状態遷移）を有する。それぞれのアークはまた、対応するダイアログ状態遷移が生じるという状況を示すダイアログ行為を有する。したがって、これらのアークをチェックすることによって、システムは、次にユーザによって述べられる可能性があるすべてのダイアログ行為を列挙することができる。加えて、生のダイアログ行為の代わりに、分類されたダイアログ行為を利用することもできる。たとえば、ダイアログ状態では、続いて起こるダイアログ行為を、ｉｎｆｏｒｍ（ａｒｅａ＝ｓｏｕｔｈ）、ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）、ｉｎｆｏｒｍ（ａｒｅａ＝ｗｅｓｔ）、ｉｎｆｏｒｍ（ａｒｅａ＝ｅａｓｔ）、ｉｎｆｏｒｍ（ｆｏｏｄ＝ｃｈｉｎｅｓｅ）、ｉｎｆｏｒｍ（ｆｏｏｄ＝ａｍｅｒｉｃａｎ）、ｉｎｆｏｒｍ（ｐｒｉｃｅｒａｎｇｅ＝ｃｈｅａｐ）、ｉｎｆｏｒｍ（ｐｒｉｃｅｒａｎｇｅ＝ｍｏｄｅｒａｔｅ）、ｉｎｆｏｒｍ（ｐｒｉｃｅｒａｎｇｅ＝ｅｘｐｅｎｓｉｖｅ）、およびｔｈａｎｋｙｏｕ（）として想定することができる。この場合、システムは、これらのダイアログ行為を、ｉｎｆｏｒｍ（ａｒｅａ＝^＊）、ｉｎｆｏｒｍ（ｆｏｏｄ＝^＊）、ｉｎｆｏｒｍ（ｐｒｉｃｅｒａｎｇｅ＝^＊）、およびｔｈａｎｋｙｏｕ（）へ分類することができる。次いでシステムは、ダイアログ行為を有していないフレーズの数をチェックする（９１４０）。その数がしきい値未満である（ｙｅｓ）場合には、システムは、サーバにアクセスする「必要はない」と判断する（９１７０）。そうでない場合には、システムは、９１４５へ進んで、ユーザによって述べられると予想されているが実際には述べられていないダイアログ行為の数をチェックする。その数がしきい値未満である（ｙｅｓ）場合には、システムは、サーバにアクセスする「必要はない」と判断する（９１５０、９１７０）。そうでない（ｎｏ）場合には、システムは、サーバにアクセスする「必要がある」と判断する（９１６０）。

途絶９１８０は、９１４０における判断の一例を示している。途絶９１８０の上側の例は、発話が「Ｃｈｉｎｅｓｅ ｆｏｏｄ ｉｎ ｔｈｅ ｎｏｒｔｈ ｐａｒｔ」であり、ダイアログ行為を伴わないフレーズは「ｉｎ」だけであることを示している（「ｔｈｅ」というワードも、割り振られたダイアログ行為を有していないが、「ｔｈｅ」は、「ｔｈｅ ｎｏｒｔｈ ｐａｒｔ」というフレーズの一部である）。したがってシステムは、サーバにアクセスする「必要はない」と判断する。途絶９１８０の下側の例では、ダイアログ行為を伴わないフレーズは、「Ｃｈｉｎｅｓｅ ｆｏｏｄ」および「ｉｎ」である。上側の例よりも多くの、ダイアログ行為を伴わないフレーズがある。したがってプロセスは、さらなる調査のために９１４５へ進む。

途絶９１９０は、９１５０における判断の一例を示している。途絶９１９０の上側の例は、発話がｉｎｆｏｒｍ（ｆｏｏｄ＝Ｃｈｉｎｅｓｅ）およびｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）というダイアログ行為を有することである。下側の例は、発話がｉｎｆｏｒｍ（ｆｏｏｄ＝Ｃｈｉｎｅｓｅ）というダイアログ行為のみを有することである。加えて、予想されるダイアログ行為は、ｉｎｆｏｒｍ（ａｒｅａ＝^＊）およびｉｎｆｏｒｍ（ｆｏｏｄ＝^＊）であると想定される。したがって、下側の例には、ｉｎｆｏｒｍ（ａｒｅａ＝^＊）というダイアログ行為が欠けており、したがって、それは、サーバにアクセスする「必要がある」としての判断である。

９１５０における判断は、いくつかの方法によって行うことができる。予想されるダイアログ行為が、ｉｎｆｏｒｍ（ａｒｅａ＝^＊）、ｉｎｆｏｒｍ（ｆｏｏｄ＝^＊）、ｉｎｆｏｒｍ（ｐｒｉｃｅｒａｎｇｅ＝^＊）、およびｔｈａｎｋｙｏｕ（）であると想定されたい。ユーザはしばしば、「ｉｎｆｏｒｍ」ダイアログ行為（ｉｎｆｏｒｍ（ａｒｅａ＝^＊）、ｉｎｆｏｒｍ（ｆｏｏｄ＝^＊）、およびｉｎｆｏｒｍ（ｐｒｉｃｅｒａｎｇｅ＝^＊））のうちの複数のダイアログ行為を有する発話を行うと予想される場合がある。しかしながら、ユーザはしばしば、単に「ｔｈａｎｋ ｙｏｕ（ありがとうございます）」と述べ、これは、単なるｔｈａｎｋｙｏｕ（）という対応するダイアログ行為を有する。したがって、別々のタイプのダイアログ行為に関するいくつかの異なるしきい値を設定することができることも、理にかなっている。たとえば、ユーザ発話がｔｈａｎｋｙｏｕ（）というダイアログ行為を有する場合には、システムは、予想されるダイアログ行為が入手されたと判断することができ、したがってシステムは、９１７０へ進み、サーバにアクセスする「必要はない」と判断する。

９１４０における判断は、いくつかの方法によって行うことができる。フレーズ・レベルの調査だけでなく、ワード・レベルの調査もまた、適用可能である。ワード・レベルの調査を採用する場合には、パーサは必要ではない。加えて、ダイアログ行為を伴わないすべてのワードが機能語である場合には、これらの機能語は、単独のダイアログ行為を有することはほとんどない。したがって、サーバにアクセスする「必要はない」と判断することは、理にかなっている。

図４（ａ）へ戻ると、サーバ・アクセスに関する判断（４０３４）が実施された後に、システムは、サーバにアクセスすることが必要とされていると判断された（４０４０）場合には、４１３０へ進む。ダイアログ・システムは、ユーザ発話（テキスト）、ダイアログ履歴、ユーザがダイアログ・システムとの間で現在行っているダイアログ・タスク、およびユーザ情報を送信する（４１３０、４５００）。ダイアログ・システムは、ユーザ・スピーチ信号をサーバへ送信することもできる。

サーバの手順は、図１０において記述されている。サーバがダイアログ・システムからのアクセスを受信する（１００１０）場合には、サーバは、ダイアログ・システムからのアップロードされた情報を受信する（１００２０、４５００）。アップロードされた情報がユーザ・スピーチ信号を含み、ＡＳＲが必要とされているとサーバが判断した（１００２５）（ｙｅｓ）場合には、サーバは、ＡＳＲを行って、ユーザ・スピーチ信号を発話テキストへ変換する（１００３０）。このＡＳＲ方法は、ダイアログ・システムと同じであることが可能である。さらに、サーバ内の音響モデルおよび言語モデルは、ダイアログ・システム内の音響モデルおよび言語モデルよりも高いＡＳＲ精度を有すると想定されたい。したがって、ダイアログ・システムにおけるＡＳＲが、正しいテキストへ変換することに失敗している状況においてさえ、ＡＳＲは、サーバでは依然として成功裏に行われることが可能である。

次いで（ダイアログ・システムから送信された、またはサーバにおけるＡＳＲによって入手された）発話テキストが、ＮＬＵへ送信される。ＮＬＵは、発話テキストをダイアログ行為へ変換する（１００４０）。ＮＬＵの方法は、ダイアログ・システムと同じである。加えて、サーバ上のＮＬＵモデルは、その精度の点でダイアログ・システムにおけるＮＬＵモデルよりも優れていると想定されたい。したがって、たとえダイアログ・システムにおけるＮＬＵが、正しいダイアログ行為を得ることに失敗したとしても、それは、サーバにおいて成功裏にＮＬＵを行う高い可能性を有する。

ＮＬＵ結果は、ダイアログ・システムへ送信されることになり（１００５０、４５１０）、ダイアログ・システムは、その情報を受信する（４１４０）。その後に、ダイアログ・システムは、矛盾している入手されたダイアログ行為同士を解決する（４１４２）。このプロセスは、図１１に示されている。図１１におけるプロセスでは、ダイアログ・システムは、入手されたすべてのダイアログ行為を参照する（１１０５０）。次いでダイアログ・システムは、発話における１つのワードが複数のダイアログ行為を導き出すかどうかをチェックする（１１０６０、１１０７０）。ダイアログ・システムにおけるＮＬＵ、およびサーバにおけるＮＬＵが、１つの同じワードから別々のダイアログ行為を作成する場合がある。加えて、ＮＬＵが、最短経路探索において複数の経路を出力するように構成されている場合に、同じ場合が起こる。これらの場合、プロセスは、ダイアログ行為のスコアを比較し（１１０８０）、より低いスコアを有するダイアログ行為を削除する（１１０９０）。スコアの比較（１１０８０）は、いくつかの異なる方法で実施することができる。たとえば、サーバにおいて入手されたＮＬＵ結果は、ダイアログ・システムにおいて入手されたＮＬＵ結果よりも高い確信性を有する傾向がある。なぜなら、サーバにおけるＮＬＵモデルは、ダイアログ・システムよりも豊かな知識から作成されたからである。したがって、サーバのＮＬＵスコアは、ダイアログ・システムのＮＬＵスコアに勝るために特定の値を乗じることおよび／または加えることによって増大されることが可能である。その一方で、ダイアログ・システムによって入手されたＮＬＵ結果が、サーバから受信されたＮＬＵ結果よりも信頼できる場合があり得る。なぜなら、ダイアログ・システムにおけるシードは、ユーザとダイアログ・システムとの間における日々のダイアログ履歴に基づいて自動的に更新されることが可能であるからである。そのような状況では、ダイアログ・システムにおけるＮＬＵモデルは、ユーザの個人的な好みに合うように既にカスタマイズされている可能性がある。その場合、ダイアログ・システムにおいて入手されたＮＬＵ結果を優先させることができる。優先させるためのチャンクを知るために、関連性値６０４０、または所望の実施態様に応じたその他のメトリック（たとえば、本明細書において記述されている肯定的なフィードバック６０５０、否定的なフィードバック６０６０、固定フラグ６０６２、および得票数６０６４）を基準として使用することができる。

次いでシステムは、矛盾しているダイアログ行為を互いにチェックする（１１１００）。たとえば、ユーザは、ｉｎｆｏｒｍ（ａｒｅａ＝ｓｏｕｔｈ）およびｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）の両方のダイアログ行為を含む発話を同時に言うことはないかもしれない。なぜなら、それらは相互に排他的であると言えるからである。別の例は、ユーザがａｆｆｉｒｍ（）およびｎｅｇａｔｅ（）という２つのダイアログ行為を同時に表すことはないことであり得る。なぜなら、それらは相互に排他的であると言えるからである。そのようなダイアログ行為同士は、「矛盾している」とみなされる。そのような矛盾しているダイアログ行為が見つかった場合には、それは、これらのダイアログ行為のスコアを比較し（１１１２０）、次いで、より低いスコアを有しているダイアログ行為を削除する（１１１３０）。ダイアログ行為のスコアの比較（１１１３０）ならびにフロー１１０８０のために、いくつかの異なる方法が適用可能であり得る。次いでループは、１１１４０において、１１０６０へ戻って再び反復することになる。

上述の方法によってＮＬＵ結果を得た後に、ダイアログ・システムは、入手されたダイアログ行為を「確信を持てる」、「確認する必要がある」、または「破棄する」に分類する（４１４４）。このプロセスは、基本的に４０３２と同じである。４０３２とは異なる点は、次のとおりである。はじめに、しきい値を４０２３から変更することができる。次に、第４のモードが図４に加えられており、そこでは、サーバにおけるＮＬＵから入手されたすべてのダイアログ行為が、「確認する必要がある」とみなされることになる（８５１０）。ダイアログ行為がサーバから得られた場合には、それがユーザにとって正しいか否かをユーザに確認する方がよい。なぜなら、サーバから入手されたこのＮＬＵ結果をユーザが見るのは初めてだからである。それらのＮＬＵ結果が正しいことがユーザから確認された場合には、そのＮＬＵパターンは、ダイアログ・システム内のＮＬＵモデルに格納されることになり、そしてダイアログ・システム内のＮＬＵは、サーバにアクセスせずに同じＮＬＵ結果を出力することができる。加えて、これらのモードの任意の組合せに基づく判断が適用可能である。

次いで、ダイアログ行為が得られなかった（４０４５）場合には、ダイアログ・システムは、ユーザが言ったことをシステムは理解することができないと言う（４１６０）。

次いで、１つまたは複数の「確認する必要がある」ダイアログ行為がある（４０５０）場合には、システムは、これらのダイアログ行為が正しいか否かを確認するようユーザに依頼する。確認ダイアログの例が、図１２に示されている。ｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）およびｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）という２つのダイアログ行為が見つかり、両方とも確認される必要があると想定されたい。次いで、ダイアログ・システム（すなわち、この図におけるロボット）は、ダイアログ行為が正しいかどうかを確認する（１２０２０）ためのスピーチ出力を行い、ユーザ応答を待つ（４０７０）。この状況において、システムは、ユーザが、肯定する発話（たとえば「ｙｅｓ」）または否定する発話（たとえば「ｎｏ」）を言うと想定する。次いでシステムは、ユーザ応答を、肯定、否定、またはその他として分類する（４０７５）。この分類は、任意の所望の実施態様を通じて、知られている発話分類アルゴリズムを使用することによって行うことができる。分類結果に基づいて、システムは、フィードバック・タプル（１２０３０）を作成する。それらのフィードバック・タプルは、ダイアログ行為（１２０４０）、チャンク（１２０５０）、およびフィードバック（１２０６０）を含むことができる。ユーザ応答が肯定として分類された場合には、ダイアログ行為および対応するチャンクは、肯定的な例とともに格納される（４０９０）。ユーザ応答が否定として分類された場合には、ダイアログ行為および対応するチャンクは、否定的なフィードバックとともに格納される（４１００）。図１２は、ユーザがｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）を否定し、ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）を肯定した場合（１２０３０）を示している。

いくつかの状況では、ユーザ応答は、「その他」として分類されることが可能であり、それは、肯定でも否定でもない。その場合、ユーザ応答（テキスト、スピーチ信号、または両方）は、ダイアログ履歴、現在のダイアログ・タスク、ユーザ情報とともにサーバへ送信されることになる（４１７０、４５２０）。次いでサーバは、アップロードされたユーザ応答上で分析を行う。サーバ・プロセスは、図１３において記述されている。サーバは、ダイアログ・システムからのアクセスを待ち（１３０１０）、次いでダイアログ・システムからの情報を受信する（１３０２０、４５２０）。ダイアログ・システムからアップロードされた情報に基づいて、サーバは、１３１００におけるフローに示されているように、フィードバック情報を生成する（１３０３０）。サーバは、ユーザ応答を、肯定、否定、またはその他として分類し（１３１００）、ダイアログ・システムにおける４０７５でのプロセスと同様に実施されることが可能である。サーバにおける発話分類のための分類アルゴリズムまたはデータは、精度の点でダイアログ・システムにおける分類アルゴリズムまたはデータよりもよい場合がある。したがって、サーバにおける分類は再び利用される。分類結果が肯定または否定である場合には、サーバは、肯定的なフィードバックまたは否定的なフィードバックをそれぞれ有するフィードバック・タプルを作成する（１３１２０、１３１３０）。分類結果がその他である場合には、サーバは、ユーザ応答上でＮＬＵを行う（１３１４０）。このＮＬＵは、確認ダイアログに対するユーザ応答を分析することに特化している。このＮＬＵの例は、２１２００から２１２４０までに示されている。ユーザ発話が「Ｉ ｗａｎｔ ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ（マンダリン料理がほしいです）」であったと想定されたい。ダイアログ・システムが「Ｉｔ ｍｅａｎｓ， ｙｏｕ ｗａｎｔ ｔｏ ｉｎｆｏｒｍ Ａｕｓｔｒａｌｉａｎ ｆｏｏｄ， ｒｉｇｈｔ？（それは、オーストラリア・フードと告げたいという意味ですね？）」と尋ねたときに、ユーザは、「Ｎｏ， Ｉ ｍｅａｎ Ｃｈｉｎｅｓｅ（いいえ、中華という意味です）」と応答した（２１２００、２１２１０）。このユーザ応答は、ダイアログ行為を分析するために解析され、次いでサーバは、「Ｃｈｉｎｅｓｅ」というチャンクがｉｎｆｏｒｍ（ｆｏｏｄ＝ｃｈｉｎｅｓｅ）というダイアログ行為を有していると認識した（２１２２０）。このＮＬＵ結果から、ユーザの元のフレーズ「ｍａｎｄａｒｉｎ Ｃｈｉｎｅｓｅ」は、ｉｎｆｏｒｍ（ｆｏｏｄ＝ｃｈｉｎｅｓｅ）というダイアログ行為を意味していると特定されることが可能である。したがって、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」というチャンク、および肯定的なフィードバックを伴うｉｎｆｏｒｍ（ｆｏｏｄ＝ｃｈｉｎｅｓｅ）というダイアログ行為に関するフィードバック・タプルが作成される。加えて、最初のユーザ発話１２０１０上のＮＬＵ結果は、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」というチャンクが、ｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）というダイアログ行為を有していることであった。したがって、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」というチャンク、および否定的なフィードバックを伴うｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）というダイアログ行為に関する１つのさらなるフィードバック・タプルが作成される（２１２３０）。

これらのプロセスを行った後に、フィードバック・タプルは、ダイアログ・システムへ送信されることになる（１３１５０、１３１６０、１３１７０、１３０４０、４５３０）。

次いでダイアログ・システムは、図４（ｂ）の４１８０に示されているようにサーバからフィードバック情報を受信する。ダイアログ・システムが何らかのＮＬＵ更新を有する場合（すなわち、システムが１つまたは複数のフィードバック・タプルを送信した場合）には、ダイアログ・システムは、自分のＮＬＵモデルを更新する（４２００）。

ＮＬＵモデルを更新する手順が、図１４に示されている。加えて、図６のシードが再び参照される。このシードは、肯定的なフィードバック６０５０、否定的なフィードバック６０６０、固定フラグ６０６２、および得票数６０６４を含む。肯定的なフィードバックおよび否定的なフィードバックは、それぞれフィードバックが肯定的または否定的である処理されたフィードバック・タプルの数を格納する。固定フラグは、ダイアログ行為／チャンク・ペアが自動的なＮＬＵ更新プロセスにおいて変更されるべきでないかを示し、その場合は１となり、そうでない場合は０となる。シードの初期状態では、人間の開発者によって作成されているダイアログ行為／チャンク・ペアは、固定フラグを１に設定されるべきである。なぜなら、これらのダイアログ行為／チャンク・ペアは、十分に確信を持てるものであり、これらの確信を持てるダイアログ行為／チャンク・ペアを使用することによってＮＬＵプロセスを維持するためにそのようなダイアログ行為／チャンク・ペアのパラメータを変更しない方がよいと思われるからである。得票数は、対応するダイアログ行為／チャンク・ペアに関連している入手されたフィードバック・タプルの数を格納する。

この手順は、すべてのフィードバック・タプルを参照する（１４０１０）。次いで、着目されているタプルが、１という固定フラグを伴うシード内に存在するチャンクを有している場合には、それは、いかなる更新プロセスも省く（１４０２０）。更新プロセスが省かれる理由は、チャンクが既に、「強く結び付けられている」ダイアログ行為をシード内に有している場合には、そのチャンクはそのまま保持されるべきであることである。次いで、タプルのダイアログ行為／チャンク・ペアがシード内に見受けられない（１４０３０）場合には、それは、事前に定義された数によって肯定的な／否定的なフィードバックを初期化する。タプル内のフィードバックが肯定的である場合には、それは、肯定的なフィードバックを、事前に定義された値として設定し（通常は、事前に定義された数を１以上として設定する）、否定的なフィードバックを０として設定する（１４０４０、１４０５０）。タプル内のフィードバックが否定的である場合には、それは、否定的なフィードバックを、事前に定義された値として設定し、肯定的なフィードバックを０として設定する（１４０６０）。次いで、得票数が１に設定され、固定フラグが０に設定される（すなわち、固定されない）（１４０７０）。

ダイアログ行為／チャンク・ペアが既にシード内に見受けられる（１４０３０）場合には、タプル内のフィードバックに従って肯定的なフィードバックまたは否定的なフィードバックがインクリメントされる。タプル内のフィードバックが肯定的である場合には、それは、肯定的なフィードバックを、事前に定義された値として設定する（１４０８０、１４０９０、１４１００）。得票数もインクリメントされる（１４１１０）。

次いで、合計フィードバックに対する肯定的なフィードバックの比率によって関連性値が更新される（１４１２０）。関連性値を更新することによって、何回か肯定的に確認されたダイアログ行為／チャンク・ペアは、より大きな関連性値になり、何回か否定的に確認されたペアは、より小さな関連性値を得る。したがって、この手順は、自動的な様式でＮＬＵ精度を改善するための自己学習アルゴリズムを達成する。

関連性値を更新した後に、システムは進んで、ダイアログ行為／チャンク・ペアが固定されるべきか否かを判断する。関連性値が十分に小さいかまたは十分に大きく（１４１３０）、得票数が十分に大きい（１４１４０）場合には、ダイアログ行為／チャンク・ペアは、そのペアが固定されるべきであると判断され、したがって固定フラグは、０から１へ変更される（１４１５０）。この発想は、１つのダイアログ行為／チャンク・ペアが既に何回もユーザにさらされて、ほとんど正しいまたはほとんど間違っていると確認されている場合には、それをユーザにそれ以上確認する必要はないことに基づいている。この発想は、ダイアログ行為を「確認する必要がある」または「確信を持てる」に分類するための新たな基準をもたらす。たとえば、固定フラグが１である場合には、それをユーザにそれ以上確認することは必要ではない。したがってプロセスは、そのダイアログ行為／チャンク・ペアを「確信を持てる」として判断する（図８における８５２０）。「確認する必要がある」ダイアログ行為の判断のためのその他の任意の基準が、関連性値、肯定的なフィードバック、否定的なフィードバック、固定フラグ、およびシード内の得票数を使用することによって適用可能になるであろう。

次いで、ダイアログ・システムは、ダイアログ・シナリオを読み取り、次のシステム・アクションおよび次のダイアログ状態を特定する（４１１０）。最後にダイアログ・システムは、アクションを出力し、そのアクションは、スピーチ合成、ロボットの動き、ロボットのアクション、ディスプレイ・スクリーン上での更新などの形態であることが可能である（４１２０）。次いでダイアログ・システムは、次のユーザ発話を待つ。

さらにダイアログ・システムは、確認ダイアログの頻度を制御または調整することができる。図１の確認頻度アジャスタ１２００は、確認頻度を調整するためのユーザ・インターフェース（たとえば、ディスプレイおよびタッチ・パッド）をユーザに提供する。ユーザがそのような確認ダイアログを有したくない場合には、ユーザは、確認頻度アジャスタのユーザ・インターフェースを介して自分の好みを告げることができる。この情報は、確認ダイアログの始動条件に関連しているしきい値を特定するために使用されることになる。

確認ダイアログへのユーザ・フィードバックは、セマンティック空間上でのそれぞれのチャンクの位置を調整するために利用することもできる。２つのチャンクが同じダイアログ行為を有していると特定された場合には、それらのチャンクの位置は、互いにさらに近くへ移動される。そうでなければ、２つのチャンクが別々のダイアログ行為を有していると特定された場合には、それらのチャンクの位置は、互いからさらに遠くへ離れるように移動される。この位置の変更は、非線形座標変換などの任意の所望の実施態様によって実施することができる。

したがって、上述の第１の例示的な実施態様では、ダイアログ・システムは、ＮＬＵモデルを自動的に更新することができ、システムに対する実際のユーザ応答を利用することによってＮＬＵ精度を改善する。上述の第１の例示的な実施態様は、サーバが、クライアントよりも高い精度を伴うＮＬＵを有するダイアログ・システムのクライアント／サーバ構成を含む（クライアントは、第１の例示的な実施態様ではダイアログ・システムとして機能する）。クライアントは、サーバのＮＬＵからの支援が必要とされる場合にのみ、サーバに依頼を行う。したがって、ユーザへのさらに速い応答時間、ならびに改善されたＮＬＵ精度を提供することができる。加えて、クライアントのＮＬＵは、サーバからのＮＬＵ更新を使用することに伴って、改善された精度を有することができる。サーバからの更新情報は基本的に、ユーザがシステムとの間で実際に有したダイアログ履歴に関連している情報に限定される。つまり、サーバからダウンロードされるデータの量は、サーバにおいて生じたすべてのＮＬＵ更新がダウンロードされることになる場合よりも小さい。したがって、第１の例示的な実施態様は、より少ないネットワーク・トラフィックを伴う効果的なＮＬＵ更新を実現する。

第２の例示的な実施態様： 別のタイプのＦＳＴベースのＮＬＵの使用を通じたダイアログ・システム構成

第２の例示的な実施態様は、ＮＬＵの方法を第１の例示的な実施態様から変更している。第２の例示的な実施態様は、ＮＬＵ上のプロセスの詳細（４０３０、１００４０、１３１４０）を第１の例示的な実施態様から変更している。ＮＬＵプロセスは、図１５に示されている。はじめにシステムは、ユーザ識別結果、現在のダイアログ・タスク、およびダイアログ履歴にとって適切であるＮＬＵモデルをロードする（１５００５）。次いで発話が、有限状態トランスデューサ（ＦＳＴ）へ変換される（１５０１０）。

ＦＳＴ変換方法は、図１６に示されている。第２の例示的な実施態様では、発話テキストは、ＡＳＲから入手されることが可能であり、ＡＳＲは、Ｎ−ｂｅｓｔセンテンスを出力し、Ｎ−ｂｅｓｔセンテンスは、ＡＳＲが認識した１つまたは複数のセンテンスを確信性の順に含む。図１６の例を参照すると、ユーザは、「Ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ ｉｎ ｔｈｅ ｎｏｒｔｈ ａｒｅａ」と言っており（１６０１０）、Ｎ−ｂｅｓｔ ＡＳＲセンテンスは、「Ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ ｉｎ ｔｈｅ ｎｏｒｔｈ ａｒｅａ」、「Ｏｒｉｇｉｎ ｃｕｉｓｉｎｅ ｉｎ ｔｈｅ ｎｏｒｔｈ ａｒｅａ」、および「Ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ ｉｎ ａ ｎｏｒｔｈ ａｒｅａ」である（１６０１５）と想定されたい。ＡＳＲセンテンス内のワードまたはセンテンスのそれぞれは、ＡＳＲからの確信値出力を有する。次いで、Ｎ−ｂｅｓｔ ＡＳＲセンテンスは、コンフュージョン・ネットワークへ変換され（１６０２０）、そこでは、それぞれのワードはそれぞれの確信値を有する。コンフュージョン・ネットワークは、所望の実施態様に従って、当技術分野において知られているワード・アラインメント・アルゴリズムを使用することによって作成されることが可能である。例示的な一実施態様では、コンフュージョン・ネットワーク内のそれぞれの「ソーセージ」（同時に現れるワードのセット）は、任意のワード出力を伴うアーク（図１６における「＜ａｒｂ＞」アーク）を有しており、それは、後のＦＳＴ合成プロセスにおけるフレキシブルなマッチングを可能にする。加えて、図１６のようなコンフュージョン・ネットワークが生成されることが可能である限り、その他の任意の方法が適用可能である。次いでコンフュージョン・ネットワークは、ＡＳＲ ＦＳＴとみなされ、そこではそれぞれのアークが、認識されたワードを出力として、および否定的な確信値を重みとして有する。

その一方で、セマンティックＦＳＴ（１６０３０）が、シードから作成される。セマンティックＦＳＴ内の開始ノードから終了ノードへの経路に沿ったそれぞれのアークが、チャンク内のワードを入力として、ダイアログ行為を出力として（最後のアークのみ）、およびダイアログ行為の確信値の負の値を、シード内の関連性値に基づいて特定される重みとして取る。関連性値は、チャンクのワードの数によって除されることになり、次いで、それぞれのワードに対応するそれぞれのアークが、除された関連性値と同じ重みを有する。ダイアログ行為を特定する上で「重要」であるワードのみに重みが供給されることになることも適用可能である。１つの可能な方法は、内容語のみが重みを有することである。重みは、第１の実施形態において記述したようにチャンク内のワードの数のような任意の手掛かりによって調整されることが可能である。加えて、セマンティックＦＳＴは、アークを有しており、そこでは入力が任意のワード（「＜ａｒｂ＞」）であり、出力がヌル（「＜ｅｐｓ＞」）であり、それは、ＡＳＲ ＦＳＴとセマンティックＦＳＴとの間でのＦＳＴ合成プロセスにおけるフレキシブルなマッチを可能にする。セマンティックＦＳＴの作成は通常、ユーザがダイアログ・システムとの会話を開始する前に行われる。

次いでＮＬＵプロセスは、ＡＳＲ ＦＳＴ内のすべてのチャンクをチェックする（１５０２０）。ＡＳＲ ＦＳＴ内のチャンクが、セマンティック空間内のシードの近いチャンクを有している（１５０３０）場合には、シード内の対応するダイアログ行為／チャンク・ペアが、セマンティックＦＳＴに加えられる（１５０４０）。たとえば、ＡＳＲ ＦＳＴ内の「ｏｒｉｅｎｔａｌ ｃｕｉｓｉｎｅ」というチャンクが、セマンティック空間におけるシード内の「Ａｓｉａｎ ｏｒｉｅｎｔａｌ ｆｏｏｄ」というチャンクに近い場合には、経路がセマンティックＦＳＴに加えられ、その経路内のアークは、対応するダイアログ行為、チャンク、および関連性スコアを有する（１６０３５）。

次いでＮＬＵは、ＡＳＲ ＦＳＴとセマンティックＦＳＴとの間におけるＦＳＴ合成を行う（１５０５０）。合成計算の方法は、任意の所望の実施態様に従って実施されることが可能である。ＦＳＴ合成結果の例が、１６０４０に示されている。

次いでＮＬＵは、合成されたＦＳＴ上で最短経路探索を行う（１５０６０、１６０５０）。最後にシステムは、出力されたダイアログ行為（１６０６０）、ならびに対応するスコアおよびチャンク（１５０７０）を得る。

セマンティック空間をセマンティックＦＳＴに組み込むためのいくつかの方法がある。たとえば、ダイアログ・システムがセマンティックＦＳＴを作成する場合に、システムは、シード内の既に知られているチャンクに近い何らかのワード／フレーズを探索することもできる。次いで、見つかったワード／フレーズは、同じダイアログ行為を有する新たなチャンクとしてセマンティックＦＳＴに加えられることが可能である。そのようなチャンクの重みは、セマンティック空間上の距離（類似性）およびその他の任意の所望の実施態様に基づいて特定されることが可能である。そのような実施態様を通じて、１５０４０および１６０３５に示されているように、新たなユーザ発話が来るたびにセマンティックＦＳＴが修正されることになることは必要ではない。この代替形態の１つの欠点は、知られているチャンクに近いチャンクの多くの候補があり、それによってセマンティックＦＳＴのサイズが巨大になることである。この欠点を回避するために、セマンティック空間に加えられることになる新たなチャンクは、多くのユーザから入手されたダイアログ履歴、公に使用されているダイアログ・コーパス、およびその他の任意のテキスト・データ内に現れるワード／フレーズに限定されることが可能である。別の代替形態は、コンセプトは１５０４０と同じであるが、セマンティック空間に対処するためにＦＳＴ合成計算プログラムが修正されることが可能であることである。ＡＳＲ ＦＳＴまたはセマンティックＦＳＴを豊かにするための別の方法は、シソーラスなどのワード意味データベースを利用することである。ＦＳＴ内の１つのワードが別のワードと類似の意味を有していることをワード・データベースが示している場合には、ＮＬＵは、見つかったワードを元のワードと平行に加えることができる。

加えて、第１の例示的な実施態様のＮＬＵにおけるＮ−ｂｅｓｔ ＡＳＲセンテンスが処理されることが可能である。第１の例示的な実施態様において言及されているように、１つのＡＳＲセンテンスがＦＳＴへ変換されることが可能である（７０１０、７０２０）。Ｎ−ｂｅｓｔ ＡＳＲセンテンスが利用可能である場合には、第１の例示的な実施態様と同じ方法を使用することによって、それらのセンテンスのそれぞれが、対応するＡＳＲ ＦＳＴへ変換されることが可能である。次いで、それぞれのＡＳＲセンテンスから入手されたこれらのＦＳＴが集められて、結合計算を使用することによって、または任意の所望の実施態様を通じて１つのＦＳＴを構築することが可能である。

したがって第２の例示的な実施態様は、例示的な代替のＦＳＴベースのＮＬＵアルゴリズムを示している。第１の例示的な実施態様のＮＬＵは、ＡＳＲにおけるワードのすべての組合せを拡張して、ＡＳＲ ＦＳＴを作成する。その一方で、第２の例示的な実施態様のＮＬＵは、この拡張を必要としない。それは、第１の例示的な実施態様よりも短い計算時間および小さいメモリを用いてＮＬＵプロセスを達成することにつながる。

第３の例示的な実施態様： ＲＮＮベースのＮＬＵを使用することを用いたダイアログ・システム構成

第３の例示的な実施態様は、ＮＬＵの方法を前述の例示的な実施態様から変更している。第３の例示的な実施態様は、リカレント・ニューラル・ネットワーク（ＲＮＮ）に基づくＮＬＵアルゴリズムを使用する。

図１７は、例示的な一実施態様による、ＲＮＮベースのＮＬＵに関するトレーニング・データを示している。このトレーニング・データは、センテンス１７０１０、ダイアログ行為１７０２０、およびワードレベル・ダイアログ行為１７０３０を含むことができる。ＲＮＮベースのＮＬＵが使用される場合には、図７に示されているようにトレーニング・データが用意されることが可能である。トレーニング・データを収集するために、開発者は、コーパス収集実験を実施することができ、そのコーパス収集実験では、話者は、自分がダイアログ・システムに何かを尋ねる状況を想像しながら、さまざまなセンテンスを述べる。収集されたセンテンスは次いで、ワード・レベルでそれぞれの発話にダイアログ行為を与えるためにアノテータによって注釈を付けられる。

図１８（ａ）および図１８（ｂ）は、例示的な一実施態様による、リカレント・ニューラル・ネットワーク（ＲＮＮ）、およびそのＲＮＮがトレーニングおよび推定を使用することを示している。ＲＮＮ（１８０１０、１８０４０）内のそれぞれのセルは、所望の実施態様に従って、Ｅｌｍａｎ ＲＮＮ、ＬＳＴＭ（Ｌｏｎｇ ｓｈｏｒｔ−ｔｅｒｍ ｍｅｍｏｒｙ）、ＧＲＵ（Ｇａｔｅｄ ｒｅｃｕｒｒｅｎｔ ｕｎｉｔ）などであることが可能である。

トレーニング・データを使用することによってＲＮＮがトレーニングされる場合には、ワード（１８０５０）および対応するワードレベル・ダイアログ行為（１８０６０）がＲＮＮへ供給される。ＲＮＮへ供給されるダイアログ行為は、ＩＯＢ２（Ｉｎｓｉｄｅ Ｏｕｔｓｉｄｅ Ｂｅｇｉｎｎｉｎｇ ２）タグの形態を有する。次いで、暫定的なＲＮＮパラメータを使用することによって、ワードレベル・ダイアログ行為の推定の対数尤度が計算される。次いで、対数尤度（負の値へ変換された）のすべてが合計される。合計された値は、コスト関数とみなされる。次いで、コスト関数を最小化するようにＲＮＮパラメータが更新される。１８０７０に示されている係数は、マスク値である。通常のＲＮＮトレーニングでは、マスク値は常に１である。しかしながら、トレーニング・データ内のワードレベル・ダイアログ行為のうちのいくつかに関してあるレベルの不確実性があると想定されたい。ダイアログ行為がそのような不確実性を有する場合には、より小さなマスク値を利用して、ＮＬＵモデル上でのそのようなダイアログ行為の影響を低減することができる。

実際のＮＬＵプロセスでは、トレーニングされたＲＮＮが使用される。ユーザ発話のワードがＲＮＮへ供給され（１８０２０）、次いでＲＮＮは、対応するダイアログ行為をＩＯＢ２フォーマットによって出力する（１８０３０）。ＩＯＢ２フォーマットを元のダイアログ行為フォーマットへ変換した後に、推定されたダイアログ行為を得ることができる（１８０８０）。ダイアログ行為を導き出すそれぞれのワードレベルＲＮＮセルの事後確率（ＲＮＮ出力値）から計算することによって、ダイアログ行為のスコアも入手される。複数のＲＮＮセルから１つのダイアログ行為が導き出される場合には、これらのＲＮＮセルからの事後確率出力の間において合計を出すこと、平均を出すこと、最大値を得ること、および／または最小値を得ることによって、ダイアログ行為のスコアが計算されることが可能である。ダイアログ行為のスコアは、入力が内容語であったＲＮＮセルのみの事後確率から計算されることが可能である。ワード入力（１８０２０、１８０５０）に加えて、ＰＯＳタグ（Ｐａｒｔ−ｏｆ−Ｓｐｅｅｃｈ ｔａｇ）などのそれぞれのワードのさらなる情報がＲＮＮへ入力されることも可能である。

セマンティック空間を関与させるためのいくつかの方法がある。１つの可能な方法は、ＲＮＮにおいて埋め込みレイヤを使用することである。ＲＮＮへの入力ワードは典型的に、ワンホット・ベクトルによって表される。ワンホット・ベクトルは、多次元ベクトルであり、それぞれの要素が、それぞれのワードに対応する。このベクトルは、ワードに対応する要素では１の値を有し、その他のすべての要素は、０に設定される。このベクトルは次いで、ワンホット・ベクトルと埋め込みマトリックス（埋め込みレイヤのパラメータ）とを乗じることによって、ワンホット・ベクトルよりも少ない次元を伴う高密度の多次元ベクトルへ圧縮される。この埋め込みプロセスは、セマンティック空間上での射影とほとんど同じ効果を有し、類似の意味を有する２つのワードからの埋め込まれたベクトル同士が、互いに近い位置に置かれる。したがって、埋め込みレイヤを組み込むことによってセマンティック空間を実現することができる。加えて、図１７に示されているトレーニング・データ上で、または大きなテキスト・コーパス上で任意の所望の実施態様を通じて埋め込みレイヤのパラメータを入手することができる。セマンティック空間を関与させるための別の方法は、認識されたワードと類似の意味を有しているワードがＲＮＮの入力に加えられることである。セマンティック空間内のワード間における距離（類似性）を計算することによって類似のワードを見つけ出すために、第１の例示的な実施態様と同じ方法が使用される。１つのＲＮＮセルへの入力として複数のワードを処理するために、「Ｎホット」ベクトルを使用することが適用可能であり、Ｎホット・ベクトルでは、入力ワードに対応するすべての要素は、１という値を有し、その他のすべての要素は、０という値を有する。

Ｎホット・ベクトルの発想はまた、ＲＮＮへのＮ−ｂｅｓｔ ＡＳＲ入力を達成するために適用可能である。図１９は、例示的な一実施態様による、ＲＮＮへのＮ−ｂｅｓｔ ＡＳＲ入力を達成するための例示的なフローを示している。はじめに、ＡＳＲセンテンスを組み込むトレーニング・データが作成される。コーパス収集実験において、話者が、「ｕｈ ｙｅｓ ａ ｃｈｅａｐ ｒｅｓｔａｕｒａｎｔ（あ、はい、安いレストランです）」と言っている（１９０１０）と想定されたい。この発話はＡＳＲへ供給され、Ｎ−ｂｅｓｔ ＡＳＲセンテンスが入手される（１９０２０）。正しい話者発話テキスト（１９０１０）およびＮ−ｂｅｓｔ ＡＳＲセンテンス（１９０２０）から、任意の所望の実施態様に従ってワード・アラインメント方法を使用することによって、ワードレベル・ダイアログ行為を伴うコンフュージョン・ネットワーク（１９０３０）を構築することが可能である。１つのソーセージ（同時のワード・セット； たとえば、「ｕｈ」、「ｈｕｈ」、および「ｏｈ」）が、説明されているＮホット・ベクトル様式によってＲＮＮセルへ供給されることが可能である。加えて、要素の値は、１に設定されないことが可能であり、むしろ、ＡＳＲから出力されたそれぞれのワードの確信値に設定されることが可能である。ダイアログ行為推定段階では、ユーザが実際に言ったことは、知られていない場合がある。しかしながら、ＡＳＲセンテンスは知られており、したがってシステムは、ＡＳＲセンテンスのみからコンフュージョン・ネットワークを構築することができる（１９０４０）。次いでコンフュージョン・ネットワークは、同じ様式によってＲＮＮへ供給される。ＲＮＮベースのＮＬＵのトレーニングおよび推定の両方のためにＡＳＲ Ｎ−ｂｅｓｔセンテンスを使用するという発想は、ＡＳＲセンテンスがワード・エラーを含む場合にＮＬＵ精度を改善する上で効果的であることがある。

図２０は、例示的な一実施態様による、ＲＮＮベースのＮＬＵの例示的なフローを示している。図２０のフローは、ＮＬＵ上のプロセス（４０３０、１００４０、１３１４０）に関する、上述の例示的な実施態様からの逸脱である。はじめにシステムは、ユーザ識別結果、現在のダイアログ・タスク、およびダイアログ履歴にとって適切なＮＬＵモデルをロードする（２０００５）。次いで発話が、コンフュージョン・ネットワークへ変換される（２００１０）。コンフュージョン・ネットワークは、ＲＮＮへ供給され（２００２０）、ＲＮＮからダイアログ行為を入手する（２００３０）。

図１２を参照すると、フィードバック・トレーニング・データ１２０７０が、確認ダイアログに対するユーザ応答から入手されたフィードバック・トレーニング・データを示している。それは、上述の例示的な実施態様において使用されているフィードバック・タプルに相当する。確認ダイアログに対するユーザ応答が受け取られると、ダイアログ行為、ダイアログ行為を導き出したワード、およびユーザからの肯定的な／否定的なフィードバックを使用することによって、フィードバック情報を生成することができる。このフィードバック情報から、フィードバック・トレーニング・データが作成される。フィードバック・トレーニング・データは、ワード１２０８０、タグ１２０９０、および重要度１２１００を含むことができる。タグは、ＩＯＢ２タグ・フォーマットによって示されている対応するワードのダイアログ行為を示している。重要度は、タグとワードとのペアがＲＮＮにどれぐらい影響することになるかの度合いの数値を示している。フィードバック・トレーニング・データは次いで、ＲＮＮのためのトレーニング・データとして使用される。重要度は、コスト関数計算上のそれぞれのＲＮＮセルのマスク値として使用されると想定されたい。１２０７０において、「ｉｎ ｔｈｅ ｎｏｒｔｈ ｐａｒｔ」というフレーズは、そのフレーズが確かにｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）というダイアログ行為を有していると判断されたので、１という重要度を有している。「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」というフレーズは、そうではないので、０．２という重要度を有している。１２０２０に示されているユーザ・フィードバックから、システムは、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」はｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）というダイアログ行為を有していないと判断する。しかしながら、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」というフレーズは、別のダイアログ行為を有している。重要度（すなわちマスク値）が、「Ｏ」タグを伴って１に設定されている場合には、ＲＮＮは、このフレーズがダイアログ行為を有していないことを学習する。「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」というフレーズは、別のダイアログ行為を有している可能性があるので、このトレーニングは不都合である。したがって、これらのワードの重要度は、より小さな値に設定される。重要度を特定するためのこのポリシーに加えて、ワードとダイアログ行為とのペアが前のユーザ・ダイアログ履歴において頻繁に見受けられた場合に、より大きな重要度を提供することができる。そうでなければ、ワードとダイアログ行為とのペアが新しい場合に、そのワードとダイアログ行為とのペアが、間違ったフィードバックに基づいている可能性に起因して、より小さな重要度を割り振ることができる。さらに、否定的なフィードバックからＲＮＮを適切にトレーニングすることができる。たとえば、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」とｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）との間において否定的なユーザ・フィードバックが入手された場合には、所望の実施態様に応じて、その他のニューラル・ネットワーク構造、その他のトレーニング基準、またはその他のコスト関数計算を組み込むことによって、「ｍａｎｄａｒｉｎ ｃｕｉｓｉｎｅ」の入力からｉｎｆｏｒｍ（ｆｏｏｄ＝ａｕｓｔｒａｌｉａｎ）の出力を回避するようにＲＮＮをトレーニングすることができる。

図２１は、例示的な一実施態様による、ユーザ・フィードバックを使用することによるＮＬＵ更新の手順を示している。図２１のフローは、上述の例示的な実施態様における４２００のプロセスを変更している。

はじめにシステムは、精度劣化をチェックするためのテスト・データを生成する（２１００５）。ダイアログ・システムは、ダイアログ履歴を有しており、そこには、前の発話（テキスト）およびＮＬＵ結果が格納されている。ダイアログ・システムはまた、ユーザ・フィードバック情報を有している。したがって、発話およびそれらの発話の正しいダイアログ行為を抽出することが可能であり、抽出されたデータは、「テスト・データ」として使用される。

それぞれの発話が、人間のシステム保守管理者による手動でタグ付けされたワードレベル・ダイアログ行為を含む場合に、テスト・データを使用することができる。テスト・データ内の発話は、確認ダイアログにおいて入手された発話だけでなく、ほとんどのユーザがダイアログ・システムに対して述べる標準的な発話、および所望の実施態様によるその他の任意のテスト・データも含むことができる。ダイアログ履歴におけるすべての発話をテスト・データとして参照することも、適用可能である。

システムは、フィードバック・トレーニング・データのすべてを参照する（２１０１０）。次いで、フィードバック・トレーニング・データのそれぞれが精緻化される（２１０２０）。この精緻化プロセスは、フィードバック・トレーニング・データに含まれているワードとダイアログ行為との間における関係をチェックする。その関係が前のフィードバックと矛盾している場合には、ダイアログ行為が、前のフィードバック・データと矛盾しないように編集される。

次いでシステムは、データがＲＮＮのトレーニング・データに加えられる際に、そのデータが精度劣化を引き起こすかをテスト・データ上でチェックする。劣化を特定するための簡単な方法は、データがトレーニング・データに加えられる際にＲＮＮモデルをトレーニングし、次いでテスト・データ上でＮＬＵ精度を評価することである。前のＲＮＮモデルがダイアログ行為を正しく入手しているが、新たなＲＮＮモデルが正しいダイアログ行為を得ることに失敗しているテスト・データがある場合には、劣化が生じていると特定される。テスト・データ内のそのような劣化した発話の数がしきい値よりも大きい（ｙｅｓ）場合には、そのデータは、フィードバック・トレーニング・データから除去される。そうでない（ｎｏ）場合には、そのフィードバック・トレーニング・データは、ＲＮＮトレーニング・データに加えられる（２１０３０、２１０４０）。ＲＮＮトレーニングが、劣化を見つけ出すのに時間がかかる場合には、劣化を引き起こすデータを見つけ出すためのその他のＮＬＵアルゴリズム（たとえばＣＲＦ）を使用することも可能である。最後に、加えられたフィードバック・トレーニング・データを含むトレーニング・データを使用することによって、ＲＮＮ ＮＬＵモデルがトレーニングされる（２１０５０）。前のＮＬＵモデルは、２１０５０においてトレーニングされた新たなＲＮＮモデルによって上書きされる。

図２１におけるフィードバック・トレーニング・データ２１０４０は、ユーザ・フィードバック発話がサーバへ送信されてサーバにおいて分析された場合にサーバにおいて生成されるフィードバック情報を示している。内容およびコンセプトは、ダイアログ・システムにおいて行われるフィードバック分析におけるフィードバック・トレーニング・データと同じである。

この第３の例示的な実施態様では、ＮＬＵのためにＲＮＮベースのアルゴリズムが使用される場合に、自己学習ＮＬＵが利用される。ＲＮＮは、トレーニング・センテンスが利用可能である限り、十分なＮＬＵ精度を達成することができる。したがって、そのような例示的な実施態様は、ユーザ・フィードバックを使用することによってＮＬＵを改善するための可能性である。

第４の例示的な実施態様： ＦＳＴベースのＮＬＵとＲＮＮベースのＮＬＵのハイブリッドを用いたダイアログ・システム構成

第４の例示的な実施態様では、ＦＳＴベースのＮＬＵとＲＮＮベースのＮＬＵが組み合わされる。アルゴリズムが、図２３に示されている。それは、ＮＬＵ上のプロセスの詳細（４０３０、１００４０、１３１４０）を上述の例示的な実施態様から変更している。はじめに、それは、ユーザ識別結果、現在のダイアログ・タスク、およびダイアログ履歴にとって適切であるＮＬＵモデルをロードする（２３００５）。次いで、上述の例示的な実施態様によってＦＳＴベースのＮＬＵが行われる（２３０１０、２３０２０）。次いで、上述の例示的な実施態様によってＲＮＮベースのＮＬＵが行われる（２３０３０、２３０４０）。ＦＳＴベースのＮＬＵおよびＲＮＮベースのＮＬＵの両方を行った後に、入手されたダイアログ行為が、矛盾しているダイアログ行為同士を解決するように処理される（２３０４５）。このプロセスは、図１１と同じであるが、ＦＳＴベースの実施態様とＲＮＮベースの実施態様との間において比較可能なスコアを作成するために、スコア調整プロセスが組み込まれている。

図３６は、例示的な一実施態様によるＦＳＴベースのＮＬＵおよびＲＮＮベースのＮＬＵの結果から適切なダイアログ行為を選択するための別の例を示している。このダイアログ行為選択プロセスでは、ＲＮＮ（３６０１０）が利用され、それらのＲＮＮは、どのＮＬＵが、より確信を持てるダイアログ行為を出力するかを示す確信値を出力するようにトレーニングされる。このＲＮＮは、センテンス、正しいダイアログ行為、ＲＮＮベースのＮＬＵ出力、およびＦＳＴベースのＮＬＵ出力を含むデータを使用することによってトレーニングされることが可能である。判断（３６０６０）は、より確信を持てると判断される判断結果の一例を示している。それらの判断結果に続いて、より確信を持てるダイアログ行為が出力されることになる（３６０７０、３６０８０）。それぞれのＲＮＮセル（３６０１０）は、ワード（３６０２０）、ＲＮＮベースのＮＬＵからのダイアログ行為出力３６０４０、およびＦＳＴベースのＮＬＵからのダイアログ行為出力（３６０５０）を受け取る。それは、ＰＯＳタグ（３６０３０）などのワードに関連しているさらなる情報を受け取ることもできる。この実施態様を利用して、いかなる種類のＮＬＵ結果も統合することができる。たとえば、図１１は、クライアント側のＮＬＵとサーバ側のＮＬＵとの間におけるＮＬＵ結果同士の矛盾を解決するための方法を示している。図１１の代わりに、図３６に示されているダイアログ行為選択アルゴリズムを適用することができ、そこでは、ＲＮＮ（３６０１０）が、クライアント側のＮＬＵおよびサーバ側のＮＬＵの結果をＲＮＮ入力として取る（３６０４０、３６０５０）。

ＦＳＴベースのＮＬＵとＲＮＮベースのＮＬＵを統合するための別の方法は、それぞれのＲＮＮがＦＳＴベースのＮＬＵの結果を受け取る構成においてＲＮＮベースのＮＬＵモデルをトレーニングすることである。図１８では、それぞれのＲＮＮ（１８０１０、１８０４０）が、ワード入力を受け取る（１８０２０、１８０５０）。これに加えて、ＦＳＴベースのＮＬＵによって入手されたそれぞれの対応するワードのダイアログ行為をＲＮＮ（１８０１０、１８０４０）へ入力することができる。

ハイブリッドＮＬＵに加えて、ダイアログ・システムおよびサーバが、別々のＮＬＵアルゴリズムを使用することも可能である。たとえば、ＦＳＴベースのＮＬＵは、ダイアログ・システム（クライアント）に適していると思われる。なぜなら、ＦＳＴベースのＮＬＵは、十分なＮＬＵ精度を実現するのにシード内の少ないダイアログ行為／チャンク・ペアで済むからである。その一方で、ＲＮＮベースのＮＬＵは、サーバに適していると思われる。なぜなら、ＲＮＮベースのＮＬＵは、大量のトレーニング・データを必要とするからである。そのようなトレーニング・データは、サーバによって入手可能である。なぜならサーバは、多くのダイアログ・システムに接続されており、それによってサーバは、さまざまなダイアログ・システムから多くのユーザ・フィードバックを得ることができるからである。

ＲＮＮベースのＮＬＵのためのトレーニング・データを収集するためには、実際のユーザ・ログを使用することが役立つことがある。しかしながら、実際のユーザ・ログは、「歪んだ」データを含む場合があり、いくつかのダイアログ行為は、ユーザの実際の発話において非常に頻繁に見受けられる場合があるが、ダイアログ行為のうちのほとんどは、数回しか見受けられない場合がある。最終的に、いくつかのダイアログ行為は、ユーザ・ログにおいて対応する発話を有さない場合がある。したがって、そのようなユーザ・ログがＲＮＮベースのＮＬＵのトレーニング・データとして使用されている限り、トレーニングされたＲＮＮベースのＮＬＵは、トレーニング・データ内で生じていないダイアログ行為を認識することが完全に不可能である。その一方で、ＦＳＴベースのＮＬＵは、生じると想定されるすべてのダイアログ行為を認識するように開発されることが可能であるが、ＦＳＴベースのＮＬＵの全体的な精度は、ＲＮＮベースのＮＬＵよりも低くなる傾向がある。この観点から、ＲＮＮベースのＮＬＵとＦＳＴベースのＮＬＵを統合するための１つの可能な方法は、次のとおりである。１つのワードが、ＲＮＮベースのＮＬＵとＦＳＴベースのＮＬＵとの間において別々のダイアログ行為を有していると想定されたい。したがって、ＦＳＴベースのＮＬＵによって得られたダイアログ行為が、ＲＮＮベースのＮＬＵのトレーニング・データ内に存在しない場合には、ＦＳＴベースのＮＬＵのダイアログ行為が、統合結果として出力される、というルールを設定することができる。加えて、そのようなダイアログ行為は、ＦＳＴベースのＮＬＵの低い精度に起因して、正しくない場合がある。したがって、このルールによって出力されたダイアログ行為のすべては、以降のプロセス（４１４４）において、「確認する必要がある」として分類されることが可能である。

さらに、サーバによって作成されたＮＬＵ更新情報は、ダイアログ・システム上で機能するＮＬＵアルゴリズム上での指示を含むことができる。一例は、ＮＬＵ更新情報が、どのＮＬＵアルゴリズムがダイアログ・システムにおいて使用されるべきであるかの指示を有することである。別の例は、ＮＬＵ更新が、ダイアログ・システムのＮＬＵアルゴリズムを更新するためのパッチ・プログラムを有することである。

ＦＳＴベースのＮＬＵとＲＮＮベースのＮＬＵのハイブリッドを使用することによって、ダイアログ・システムは、図２４に示されているように、フィードバック・タプル（２４０４０）およびフィードバック・トレーニング・データ（２４０８０）の両方を入手することができる。ワードとダイアログ行為との間における関係が、フィードバック・タプルとフィードバック・トレーニング・データとの間において異なる場合がある。この相違を利用して、より正確なユーザ・フィードバックを得ることができる。たとえば、１つのワードが、フィードバック・タプルとフィードバック・トレーニング・データとの間において同じダイアログ行為を有する場合には、そのダイアログ行為は、高い確信性レベルを有することができる。その一方で、１つのワードが、フィードバック・タプルとフィードバック・トレーニング・データとの間において別々のダイアログ行為を有する場合には、ダイアログ・システムは、そのような別々のダイアログ行為の中から、より高い確信性を有している１つのダイアログ行為を選ぶことができる。高い確信性のダイアログ行為を選ぶために、所望の実施態様に従って、ダイアログ行為のスコア、ダイアログ履歴に対するフィードバック情報の整合性、およびその他の任意の情報を利用することができる。

この例示的な実施態様におけるハイブリッドＮＬＵは、別々のＮＬＵアルゴリズムのメリットおよびデメリットを補う。ＦＳＴベースのＮＬＵは基本的に、たとえシード内のダイアログ行為／チャンク・ペアの数が限られていても、高い精度を達成する。しかしながら、大量のトレーニング・データが利用可能である場合には、ＲＮＮベースのＮＬＵは、ＦＳＴベースのＮＬＵの精度に勝ることが可能である。したがって、両方のＮＬＵアルゴリズムのハイブリッド構成を使用することによって、トレーニング・データが少ないか多いかにかかわらず、一貫して高い精度を得ることができる。

第５の例示的な実施態様： Ｎ−ｂｅｓｔ ＡＳＲ出力を組み込んだ自己学習ＮＬＵ

第５の例示的な実施態様では、ＮＬＵを更新するために、Ｎ−ｂｅｓｔ ＡＳＲ出力が利用される。図２４は、Ｎ−ｂｅｓｔ ＡＳＲ出力からフィードバック情報（すなわち、フィードバック・タプル、フィードバック・トレーニング・データ）をどのようにして生成するかを示している。

Ｎ−ｂｅｓｔ ＡＳＲセンテンス２４０１０から、上述の例示的な実施態様において言及されているようにＦＳＴベースのアルゴリズムまたはＲＮＮベースのアルゴリズムのいずれかによって２４０２０でＮＬＵが行われることになる。次いで、２４０３０において確認ダイアログが行われる。

フィードバック・タプルを作成する場合（すなわち、ＦＳＴベースのＮＬＵが使用される場合には）、ＡＳＲ出力および対応するダイアログ行為のコンフュージョン・ネットワークを入手することができる（２４０２２）。たとえば、ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）というダイアログ行為を有しているコンフュージョン・ネットワークの一部分（２４０２５）が、「ｉｎ」、「ｔｈｅ」、「ｎｏｒｔｈ」、および「ｎｏｓｅ」というワードを含んでいる。この部分はまた、どのワード同士が互いに接続されているかを示すアークを有している。コンフュージョン・ネットワークのこの部分から、すべての生成されるフレーズ、すなわち、「ｉｎ ｔｈｅ ｎｏｒｔｈ」、「ｉｎ ｔｈｅ ｎｏｓｅ」、「ｉｎ ｎｏｒｔｈ」、および「ｉｎ ｎｏｓｅ」が拡張されることが可能である。この例では、ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ）というダイアログ行為が、ユーザによって肯定的なフィードバックを供給される。したがってダイアログ・システムは、２４０２０に示されているように、これらのフレーズ（すなわちチャンク）を、対応するダイアログ行為（すなわち、ｉｎｆｏｒｍ（ａｒｅａ＝ｎｏｒｔｈ））およびフィードバック・タイプ（すなわち肯定的）を伴うフィードバック・タプルとして取る。

フィードバック・トレーニング・データを作成する場合（すなわち、ＲＮＮベースのＮＬＵが使用される場合には）、コンフュージョン・ネットワークおよび対応するダイアログ行為（２４０２２）を利用することができる。図１８の方法によるＲＮＮのトレーニング・データ（１８０４０、１８０５０、１８０６０、１８０７０）のために、コンフュージョン・ネットワークおよびワードレベル・ダイアログ行為２４０２５を使用することができる。したがって、２４０８０に示されているようにフィードバック・トレーニング・データが用意される場合には、Ｎ−ｂｅｓｔ ＡＳＲ出力を考慮に入れながら、ＲＮＮのトレーニング・データのためのユーザ・フィードバックを使用することができる。値２４１２０は、ＡＳＲから入手されたワード確信値を示している。これらの値は、上述の例示的な実施態様において記述されているように、ＲＮＮへの入力ワードのＮホット・ベクトルの要素値として利用されることが可能である。重要度２４１１０も、ＡＳＲのワード確信値によって特定されることが可能である。図２４は、それぞれの重要度が、対応する認識されたワード内の最大ワード確信値２４１２０と同じ値に設定される一例を示している。加えて、上述の例示的な実施態様と同じポリシーによって重要度を特定することができる。

この第５の例示的な実施態様では、実際の使用においてダイアログ履歴のＮ−ｂｅｓｔ ＡＳＲ出力を使用することによるＮＬＵ更新方法が示されている。ＡＳＲ出力において現れるワード・エラーの特徴は、所望の実施態様に従って、環境ノイズのレベル、音響環境、ユーザ・スピーチの特徴などに応じて変更されることが可能である。この例示的な実施態様では、実際の現場において生じるＡＳＲワード・エラーの特徴が、自動的にＮＬＵモデルへ取り込まれ組み込まれることが可能である。したがって、この例示的な実施態様は、実際の現場におけるＮＬＵ精度を自動的に改善する。

第６の例示的な実施態様： サーバにおける自己学習ＮＬＵ

この例示的な実施態様では、ユーザ・フィードバックを使用することによるサーバにおける自動的なＮＬＵ更新方法が記述されている。

ダイアログ・システムは、ユーザとダイアログ・システムとの間における確認ダイアログにおいて入手されたユーザ・フィードバック（フィードバック・タプル、フィードバック・トレーニング・データ）を格納する。ダイアログ・システムにおいて入手された情報（すなわち、ダイアログ履歴、ユーザ・フィードバック、およびユーザ・プロフィール）は、サーバへアップロードされる。サーバは、図３に示されているように、少なくとも１つまたは複数のダイアログ・システムに接続されている。したがってサーバは、さまざまなダイアログ・システムにわたる多くのユーザ・フィードバックを格納することができる。サーバ内のユーザ・フィードバックを使用することによって、ＮＬＵモデルを更新することができる。

図２５は、例示的な一実施態様による、サーバにおいてフィードバック・タプルを使用することによってシードをどのようにして更新するかを示している。この手順は、図１４に示されているダイアログ・システムにおいてシードを更新することに類似している。図１４との相違は、それぞれのタプルのタプル・スコアを計算すること（２５０１５； Ｍｉ）であり、タプル・スコアは、肯定的なフィードバックおよび否定的なフィードバック（２５０５０、２５０６０、２５０９０、２５１００）、ならびに得票数（２５０７０、２５１１０）を更新するために使用される。

タプル・スコアは、タプルがより確信を持てる場合にさらに高くなる値である。タプル・スコアを計算するために、それぞれのユーザ上の評価を取って、ユーザ確信性を特定することになる。ユーザ確信性は、下記の基準に基づいて計算されることが可能である。
− ユーザ履歴から特定されたダイアログの頻度（それがより頻繁である場合には、このユーザの確信性はより高くなるであろう）
− その他のユーザとの間でのユーザ・フィードバックの整合性（ユーザ・フィードバックのうちのほとんどが、その他のユーザとは異なる場合には、このユーザの確信性は低くなる）
− 個々のユーザに関するユーザ・フィードバックの整合性（ユーザ・フィードバックが前の確認ダイアログに対して整合していない場合には、このユーザの確信性は低くなる）
− ユーザ発話上のパラ言語情報（ユーザ・スピーチ上のパラ言語情報、たとえば、調子、声量、無音区間が異常として分類される場合には、このユーザの確信性は低くなる）

タプル・スコアはまた、タプルそのものの確信性によって特定される。計算方法は、下記のとおりである。
− その他のフィードバックとの間でのフィードバックの整合性（着目されているフィードバックが、その他のフィードバックのうちのほとんどとの間で不整合である場合には、このタプルの確信性はより低くなるであろう）

さらに、ユーザ確信性は刻々と変わり得る。ユーザ確信性は、その瞬間におけるダイアログ行動から特定されることになる。加えて、ユーザ確信性は、ダイアログが行われる時間、ダイアログ・タスクの種類、ユーザの環境などによって特定されることが可能である。

このタプル・スコアは、所望の実施態様に従って、手動で特定されることが可能である。タプル確信性を提供するための手動の実施態様では、人間のオペレータが、サーバ内のダイアログ履歴をチェックし、次いでオペレータは、タプル・スコアの値を決定する。

ダイアログを有するユーザは、上述の例示的な実施態様において言及されているように、ユーザ識別子によって特定される。しかしながら、ユーザを識別することができないこともあり得る。そのような状況では、ユーザ確信性の代わりに、ダイアログ・システムの確信性を使用することができる。ダイアログ・システムの確信性は、ユーザ確信性が計算される場合の様式と同じ様式を使用することによって、１つの特定のダイアログ・システムからのすべてのアップロードされた情報から計算されることになる。

タプル・スコアを計算するためのこれらの基準は、上述の範囲に限定されない。

図２６は、例示的な一実施態様による、サーバにおいてフィードバック・トレーニング・データを使用することによってＲＮＮベースのＮＬＵのトレーニング・データを更新するためのフローを示している。この手順は、図２１に示されているダイアログ・システムにおいてシードを更新する手順に類似している。図２１との相違は、それぞれのタプルのデータ・スコアの計算（２６０１５； Ｍｉ）を含み、そのスコアは、それぞれのデータの重要度を特定するために使用される（２６０４０）。計算するための方法は、その他の例示的な実施態様において記述されているタプル・スコアを計算するための方法と同じである。

図２５および図２６の方法によるサーバ内の更新されたＮＬＵモデルをそれぞれのダイアログ・システムへダウンロードすることができる。図２２（ａ）および図２２（ｂ）は、例示的な一実施態様による、ダイアログ・システムがサーバから更新を受信した場合にダイアログ・システムにおいてＮＬＵモデルを更新する例示的な手順を示している。

ＦＳＴベースのＮＬＵが使用される場合が、図２２（ａ）の２２０１０〜２２０５０に示されている。はじめにダイアログ・システムは、サーバ内の更新されたシードを受信する（２２０１０）。次いでシステムは、更新されたシード内のすべてのダイアログ行為／チャンク・ペアを参照する（２２０２０）。更新されたシード内のダイアログ行為／チャンク・ペアが、ダイアログ・システム内のダイアログ行為／チャンク・ペアと矛盾している（２２０３０）（ｙｅｓ）場合には、更新された情報内のダイアログ行為／チャンク・ペアは破棄され、ダイアログ・システム内のシードを更新するために使用されない（２２０４０）。更新されたシード内のダイアログ行為／チャンク・ペアが、ダイアログ・システム内のシードと矛盾していない（ｎｏ）場合には、それは、ダイアログ・システムのシード内の新たなダイアログ行為／チャンク・ペアとして使用される（２２０５０）。矛盾検知は、次のように実施することができる。（１）更新されたシード内のダイアログ行為／チャンク・ペアと同じチャンク（ワード）を有しているダイアログ行為／チャンク・ペアがダイアログ・システム内にあるかどうかをチェックし、（２）そのペアが存在する場合には、ダイアログ行為同士が、ダイアログ・システムおよび更新されたシード内のダイアログ行為／チャンク・ペア間において同じであるかどうかをチェックし、（３）ダイアログ行為同士が同じでない場合には、そのペアが矛盾していると判断する。

ダイアログ・システム内のシードがダイアログ・システムのユーザに既に適合されていた可能性がある。言い換えれば、ダイアログ・システムのシード内のダイアログ行為／チャンク・ペアは、ユーザが好むいくつかのＮＬＵルールを含む可能性がある。したがって、ダイアログ・システム内のそのようなタプルが上書きされた場合には、この更新のタイミングから、ユーザの頻繁な発話がダイアログ・システムによって理解されることが不可能になるので、ユーザ経験が衰えることがある。したがってシステムは、ダイアログ・システムのシードに対する更新されたシードの矛盾をチェックする。次いでシステムは、更新されたシード内のダイアログ行為／チャンク・ペアを、そのペアがダイアログ・システムのシードに対して矛盾していない場合にのみ、ダイアログ・システム内のＮＬＵモデルに加える。

ＲＮＮベースのＮＬＵが使用される場合が、図２２（ｂ）に関する２２５１０〜２２５５０に示されている。はじめにダイアログ・システムは、サーバからＮＬＵモデルをダウンロードする（２２５１０）。次いでダイアログ・システムは、２１００５と同じ様式によってテスト・データを生成する（２２５１５）。上述の例示的な実施態様において言及されているように、ダイアログ・システムは、ダイアログ履歴またはその他の任意のデータ・ソースからテスト・データを作成することができる。テスト・データのそれぞれは、発話および正しいワードレベル・ダイアログ行為を含むことができる。ダイアログ履歴内のすべての発話をテスト・データとして参照することができる。

次いでダイアログ・システムは、テスト・データ内のすべての発話を参照し（２２５２０）、ダウンロードされたＮＬＵモデルを使用することによってＮＬＵを実施する（２２５３０）。ＮＬＵ結果が、前のＮＬＵモデルを使用することによって入手された結果とは異なる（２２５４０）（ｙｅｓ）場合には、ダイアログ・システムは、新たなＮＬＵモデルがテスト・データ上で劣化を引き起こすと判断する。そのような劣化を回避するために、ダイアログ・システムは、特別なＮＬＵルールを生成する（２２５５０）。

テスト・データが「Ｉ’ｍ ｇｌａｄ（うれしいです）」という発話を有していて、ダイアログ行為がｔｈａｎｋｙｏｕ（）だったと想定されたい。加えて、前のＮＬＵモデルを使用することを用いたＮＬＵプロセスは、正しいダイアログ行為を入手することができる。「Ｉ’ｍ ｇｌａｄ」という入力は、ｔｈａｎｋｙｏｕ（）というダイアログ行為へ成功裏に変換される。ＮＬＵモデルが、サーバからダウンロードされたＮＬＵモデルによって置き換えられると、ＮＬＵ結果は、「Ｉ’ｍ ｇｌａｄ」という発話上でｔｈａｎｋｙｏｕ（）からｂｙｅ（）へ変わる。このような例では、２２５４０のもとで劣化が生じる。この劣化を回避するために、ダイアログ・システムは、特別なルールをＮＬＵモデルに加える。その特別なルールは、「Ｉ’ｍ ｇｌａｄ」という入力をｔｈａｎｋｙｏｕ（）というダイアログ行為へ変換することである。この特別なルールは、特別なルールを格納しているテーブルを参照することによって機能する。加えて、特別なルールからのＮＬＵ結果は、ＲＮＮベースのアルゴリズムから入手されたＮＬＵ結果を上書きする。この様式では、劣化をなくすことができる。

２２０３０において「矛盾」を、または２２５４０において「劣化」を判断するためのいくつかの代替方法がある。たとえば、ＦＳＴベースのＮＬＵの場合（２２０３０）、矛盾しているダイアログ行為／チャンク・ペアが実際のダイアログにおいて使用された頻度が少ない場合には、そのようなダイアログ行為／チャンク・ペアは、ユーザにとって重要ではないと特定されることが可能である。したがって、そのようなダイアログ行為／チャンク・ペアは、ダウンロードされたシードによって上書きされることが可能である。ＲＮＮベースのＮＬＵの場合（２２５４０）、劣化したテスト・データの発話が実際のダイアログにおいてめったに述べられていない場合には、そのようなテスト・データは、ユーザにとって重要である可能性がある。したがって、そのテスト・データにおける発話は、無視することができる。加えて、「矛盾」または「劣化」が生じた場合には、ユーザは、自分が２２０４０または２２５５０における特別な処置を望んでいることを確かめるよう促されることも可能である。

この例示的な実施態様では、サーバ内のフィードバック情報を使用することによって、ＮＬＵ更新方法が実施される。このような例示的な実施態様は、さまざまなダイアログ・システムから入手された大量のユーザ・フィードバックを使用することによって、効果的にＮＬＵ精度を改善することができる。この実施態様は、ユーザ・フィードバックの不確実性に対処すること、およびユーザ・フィードバックの不確実性を考慮に入れながらユーザ・フィードバックを使用してＮＬＵモデルを更新することも可能である。

この例示的な実施態様はまた、ダイアログ・システムにおけるＮＬＵ上でのユーザの適合を容易にし、サーバによって行われたＮＬＵ更新を使用することによって全体的なＮＬＵ精度を改善する。

第７の例示的な実施態様： イントピックＮＬＵおよびアウトオブトピックＮＬＵを組み合わせるＮＬＵアルゴリズム

第７の例示的な実施態様では、図２７に示されている別のＮＬＵアルゴリズムがある。それは、ＮＬＵ上のプロセスの詳細（４０３０、１００４０、１３１４０）を上述の例示的な実施態様から変更している。

はじめに、このアルゴリズムは、ユーザ識別結果、現在のダイアログ・タスク、およびダイアログ履歴に基づいてＮＬＵモデルをロードする（２７０１０）。次いで、上述の例示的な実施態様における方法、すなわち、ＦＳＴベースのＮＬＵ、ＲＮＮベースのＮＬＵ、または「ノーマルＮＬＵ」と呼ばれるハイブリッドＮＬＵ（２７０２０）のうちのいずれかを使用することによって、ＮＬＵが実施される。

次いでシステムは、「アウト・オブ・トピック」ダイアログのためのＮＬＵを行う（２７０３０）。上述の例示的な実施態様において言及されているノーマルＮＬＵアルゴリズムは、事前に定義されたダイアログ行為があるという発想に基づいている。しかしながら、実際の人間対マシンのダイアログでは、ユーザが述べる可能性があるすべてのダイアログ行為を予測および用意することは不可能であることがある。したがって、ノーマルＮＬＵがダイアログ行為を理解することができない場合に関する発話に対処することができる代替ＮＬＵ方法を用意することができる。

所望の実施態様に従って、アウトオブトピック・ダイアログを保管するための任意の方法を使用することができる。そのような方法は、ユーザ発話の入力を入手し、次いでシステム発話を出力する。所望の実施態様に応じて、ダイアログ行為は、出力される必要がない。

この例示的な実施態様では、図２８（ａ）、図２８（ｂ）、および図２９に示されているように、システム発話選択アルゴリズムが利用される。このシステム発話選択アルゴリズムは、ＲＮＮベースの会話モデルに基づいている。ニューラル・ネットワークのＲＮＮ構造またはその他の構造上のその他の構成も、適用可能である。

このシステム発話選択アルゴリズムは、図２８（ａ）のダイアログ・コーパス２８０１０を使用し、これは、システムとユーザ発話との多数のペアを含む。ダイアログ・コーパス内の会話トピックがターゲット・タスクに関連していることが、より望ましい。しかしながら、ダイアログ・コーパスのトピックがターゲット・タスクのトピックとは異なることも、適用可能である。

ダイアログ・コーパスは、トレーナ２８０２０へ送信される。それは、ダイアログ・コーパスからの会話モデル２８０３０をトレーニングする。この例示的な実施態様では、会話モデルは、図２９に示されているＲＮＮセルを使用してエンコーダ／デコーダ・モデルによって実現されると想定されたい。このモデルは、エンコーダＲＮＮ ２９０１０およびデコーダＲＮＮ ２９０２０を含む。エンコーダＲＮＮは、上述の例示的な実施態様において言及されているワンホット・ベクトルまたはＮホット・ベクトルのフォーマットであることが可能であるユーザ発話のワード（２９０４０）を受け取る。加えて、エンコーダＲＮＮは、さらなる情報２９０３０を受け取ることができ、それは、ダイアログ履歴情報（ユーザ発話、ユーザ・ダイアログ行為、システム発話、およびシステム・ダイアログ行為を含む）、ならびに現在のダイアログ状態における予想されるユーザ・ダイアログ行為を含むことができる。受け取られた生の情報は、その他のＲＮＮまたはその他のニューラル・ネットワークを使用することによって、適切なベクトル表現へ変換されることが可能である。システム・ダイアログ行為は、システム発話を出力することによってダイアログ・システムがユーザに対して表したいことを示すセマンティック表現である。たとえば、「Ｗｈａｔ ｋｉｎｄ ｏｆ ｆｏｏｄ ｗｏｕｌｄ ｙｏｕ ｌｉｋｅ？（どのような食べ物がお好きですか？）」というシステム発話は、ｒｅｑｕｅｓｔ（ｓｌｏｔ＝ｆｏｏｄ）というダイアログ行為を有する。

会話モデルは、２９０３０で言及されているさらなる情報とともにダイアログ・コーパス内の「ユーザ」発話を自分が受け取った場合にダイアログ・コーパス内の「システム」発話を出力するようにトレーニングされる。ダイアログ・コーパス上の注釈が完全ではないので、またはダイアログ・コーパスが、ターゲット・タスクとは異なるタスクから入手されているので、さらなる情報２９０３０が利用可能ではない状況があると想定されたい。その場合、会話モデルは、さらなる情報を伴わずにトレーニングされることが可能である。ダイアログ・コーパスの一部分がさらなる情報を有しており、その他の部分がさらなる情報を有していない場合には、会話モデルは、事前トレーニングおよび微調整という２つのステップでトレーニングされることが可能である。事前トレーニング・ステップでは、モデルが、さらなる情報を伴わないデータを使用することによってトレーニングされる。微調整ステップでは、事前トレーニングされたモデルが、さらなる情報を伴うデータを使用することによってさらにトレーニングされる。

トレーニングされた会話モデルは、システム発話を生成する目的でアウトオブトピックＮＬＵのために使用される。アウトオブトピックＮＬＵの手順は、図２８（ｂ）、２８５１０〜２８５６０に示されている。はじめにダイアログ・システムは、ユーザ発話２８５１０およびダイアログ履歴２８５２０を既に有している。ダイアログ履歴は、対応するシステム・ダイアログ行為およびユーザ・ダイアログ行為（図にはない）を有することができる。これらは、会話モデル２８５４０を使用してセンテンス・ジェネレータ２８５３０へ入力される。センテンス・ジェネレータは、図２９に示されているエンコーダ／デコーダＲＮＮモデルによって実現される。ユーザ発話およびさらなる情報をセンテンス・ジェネレータへ入力することによって、モデルは、デコーダＲＮＮ ２９０２０からセンテンスを生成する。ダイアログ・システムは、生成されたセンテンスをシステム発話として採用することができる。しかしながら、この例示的な実施態様では、システム発話の事前に定義された候補から最も適切なシステム発話を選ぶためにセンテンス・ジェネレータが使用される方法がある。エンコーダ／デコーダＲＮＮを使用するセンテンス生成方法は、エンコーダ／デコーダＲＮＮが生成する出力センテンスを開発者が制御することができないという点で不利な点を有する場合がある。そのような状況は、ダイアログ・システムが不適切なシステム発話を提供する結果をもたらすことがある。したがって、例示的な実施態様は、適切に吟味されている多くのセンテンスから１つのセンテンスを選ぶためのモデルを利用する。システム発話の候補が、２８５５０に示されている。ＲＮＮのネットワーク構造は、図２９に限定されない。たとえば、入力情報２９０３０は、エンコーダＲＮＮ ２９０１０へだけでなく、デコーダＲＮＮ ２９０２０へ入力されることが可能である。

システムが２８５５０からどのセンテンスを選ぶべきかを特定するために、システムは、ユーザ発話およびさらなる情報を所与として２８５５０内のセンテンスのうちの１つをデコーダＲＮＮが生成する場合の確率を計算する。図２９の例は、「Ｍｅ ｔｏｏ！ Ｉｔ’ｓ ｍｙ ｐｌｅａｓｕｒｅ（私もです！ こちらこそ）」というセンテンス（２９０５０）が、０．６という可能性（２９０６０）を有しており、それは、システム発話の候補の中で最大の可能性であることを示している。したがって、「アウトオブトピック」ＮＬＵ２７０３０は、生成されたシステム発話２８５６０を出力し、それは、「Ｍｅ ｔｏｏ！ Ｉｔ’ｓ ｍｙ ｐｌｅａｓｕｒｅ」である。

この瞬間において、ダイアログ・システムは、ノーマルＮＬＵおよびアウトオブトピックＮＬＵの結果を有する。次いでシステムは、どのＮＬＵ結果が採用されるべきであるかを特定する。それは、ＮＬＵ結果のスコアを比較することによって行われる（２７０４０）。ノーマルＮＬＵのスコアは、上述の実施形態における方法によって特定される。アウトオブトピックＮＬＵのスコアは、２９０６０において言及されているセンテンスの生成の確率を使用することによって特定される。アウトオブトピックＮＬＵのスコアは、システム発話のワードの数によって調整されることが可能である。加えて、アウトオブトピックＮＬＵのスコアは、ユーザが現在のダイアログ状態においてアウトオブトピック発話を行う可能性などのいくつかのメトリックを組み込むことによって調整されることが可能である。

次いで、アウトオブトピックＮＬＵ結果のスコアがノーマルＮＬＵ結果のスコアよりも大きい場合には、それは、アウトオブトピックＮＬＵの結果を採用する（２７０６０）。そうでない場合には、それは、ノーマルＮＬＵの結果を採用する（２７０５０）。

アウトオブトピックＮＬＵ結果が採用された場合には、ダイアログ・システムの後続の行動は、次のとおりである。アウトオブトピックＮＬＵの出力は、システム発話である。したがって、ノーマルＮＬＵが出力するダイアログ行為との間での対処プロセスを利用することは必要ではない。たとえば、４０３０におけるＮＬＵがアウトオブトピックＮＬＵ結果を出力するならば、ダイアログ・システムは次いで、４１２０のプロセスへジャンプし、そこでアクションを行う。このプロセスにおいて、ダイアログ・システムは、アウトオブトピックＮＬＵの出力センテンスに対応してスピーチ合成を使用してシステム発話を出力する。

アウトオブトピックＮＬＵ結果が採用された場合には、次のダイアログ状態は、まだ特定されていない。ダイアログ・シナリオ上での次の状態を特定するためのいくつかの代替方法がある。第１に、アウトオブトピックＮＬＵ結果が採用された場合は常にダイアログ状態遷移が生じないことが可能である。第２に、アウトオブトピックＮＬＵ結果が採用された場合にダイアログ・シナリオが次のダイアログ状態の定義を有することも可能である。アウトオブトピックＮＬＵによって採用されるシステム発話に応じて次のダイアログ状態が定義されることも可能である。最後に、適切なダイアログ・コーパスが用意されることが可能である場合には、エンコーダ／デコーダＲＮＮモデルを作成することが可能であり、そのモデルでは、デコーダＲＮＮは、システム発話のワードだけでなく、その他の任意の情報、たとえば、次のダイアログ状態、ユーザの次の予想されるダイアログ行為なども出力する。そのような方法でトレーニングされたＲＮＮモデルを利用することによって、アウトオブトピックＮＬＵ結果が採用された場合にダイアログ・シナリオ上で次の状態が特定されることが可能である。

この例示的な実施態様は、事前に定義されたダイアログ行為を意図しているユーザ発話だけでなく、ユーザによって言われると開発者が予想しなかった意図を示すユーザ発話も理解することができる代替のＮＬＵアルゴリズムを示している。それは、ユーザ発話の多様性およびユーザの意図の多様性に対するシステム発話の堅牢性を改善する。

第８の例示的な実施態様： システム発話変換

第８の例示的な実施態様では、システム発話が変換される。センテンス変換の目的は、ダイアログ・シナリオ内に格納されている固定されたシステム発話からさまざまなシステム発話を生成することである。

図３０（ａ）および図３０（ｂ）は、例示的な一実施態様による、発話変換のプロセスを示している。発話変換を実現するために、発話変換モデル３００３０が、図３０（ａ）に示されている発話対発話コーパス３００１０およびトレーナ３００２０（３０００５）からトレーニングされる。トレーニングのための発話対発話コーパスが、図３１に示されている。発話対発話コーパスは、普通の発話（３１０１０）、システム・ダイアログ行為（３１０２０）、およびリライトされた発話（３１０３０）を含む。普通の発話は、ダイアログ・シナリオにおけるシステム発話と類似の特徴を有する発話である。つまり、普通の発話は通常、簡潔な、明確な、および正式な表現または文法を有している。リライトされたシステム発話は、対応する普通の発話と同じ意味を有するセンテンスを有している。リライトされた発話は、普通の発話よりも多様な表現（たとえば、親しみのある表現、形式張らないワード）を有すると想定される。システム・ダイアログ行為は、対応する普通の発話およびリライトされた発話のダイアログ行為を示す。

発話対発話コーパスを作成するためのいくつかの方法がある。１つの可能な方法は、人間の開発者が、はじめに普通の発話を作成し、次いで普通の発話のうちのそれぞれの代替表現を考えることによって、リライトされた発話を手動で作成することである。別の方法は、はじめに多くのセンテンスが、ダイアログ・コーパス、ウェブ・リソース、またはその他の任意の情報ソースから収集されることである。収集されたセンテンスは、リライトされた発話として使用される。次いで、収集されたセンテンスを簡略化することによって、普通の発話が作成されることになる。センテンスの簡略化は、整数線形計画法アプローチなどの任意の所望の実施態様によって行われることが可能である。

発話変換モデルの詳細が、図３２に示されている。それは、エンコーダ／デコーダＲＮＮモデルによって実施される。エンコーダＲＮＮ ３２０１０は、普通の発話を自分の入力として取る（３２０４０）。それはまた、さらなる情報３２０３０の入力を取り、さらなる情報３２０３０は、ダイアログ履歴情報と、発話対発話コーパス内で指定されているシステム・ダイアログ行為とを含むことができる。その入力を与えられると、ＲＮＮセルは、リライトされた発話（３２０５０）をデコーダＲＮＮ（３２０２０）から出力するようにトレーニングされる。ＲＮＮのネットワーク構造は、図３２に限定されない。たとえば、入力情報３２０３０は、エンコーダＲＮＮ ３２０１０へだけでなく、デコーダＲＮＮ ３２０２０へ入力されることが可能である。さらなる情報３２０３０は、ユーザの顔、姿勢、動き、およびスピーチなどの情報によって推定されたユーザ・ステータスの情報、すなわち、進行中の会話上での関与、感情ステータス、またはユーザの性格を含むことができる。

ダイアログ・シナリオにおけるセンテンス（３０５１０）を、変換されたシステム発話（３０５５０）へ変換するために、トレーニングされた発話変換モデル（３０５４０）がシステム発話コンバータ（３０５３０）によって使用される。システム発話コンバータ（３０５３０）はまた、システム・ダイアログ行為（３０５１５）、ダイアログ履歴（３０５２０）を入力として受け取る。ダイアログ履歴は、対応するシステム・ダイアログ行為およびユーザ・ダイアログ行為（図では描かれていない）を有することができる。変換されたシステム発話（３０５５０）は次いで、ダイアログ・システムからユーザへ出力される。

発話対発話コーパスが、ターゲット・タスクとは異なるタスクからのダイアログから作成されている場合には、ターゲット・タスク内のダイアログ行為からそれぞれの発話に関する適切なシステム・ダイアログを選ぶことが困難であることがある。１つの代替方法は、一般的なダイアログ行為を使用することである。一般的なダイアログ行為が利用される場合には、自動的な方法で発話上のダイアログ行為を特定することが可能である。そのような一般的なダイアログ行為は、ターゲット・タスクに関して定義されているダイアログ行為とは異なるが、通常のダイアログ制御が基本的に、タスク固有のダイアログ行為を利用し、センテンス・リファイナが基本的に、一般的なダイアログ行為を利用する。つまり、１つのシステム発話が、２つのタイプのダイアログ行為を有することになる。

この例示的な実施態様は、システム発話を変換して表現の品質を改善するための方法を示した。従来のダイアログ・システムのほとんどは、ダイアログ・シナリオ内に登録されている固定されたシステム発話を出力する。システム発話は、固定されたものであり、それによってユーザは、ダイアログ・システムとの会話上に退屈な印象を感じるようになる。この例示的な実施態様は、システム発話の精緻化方法を提供し、ダイアログ・シナリオ内の固定されたシステム発話からのさまざまなシステム発話の作成を容易にする。したがって、そのような例示的な実施態様は、ユーザのためにさらに自然でさらに魅力的な会話を達成する。

第９の例示的な実施態様： ユーザ・ダイアログ行為の予測

この例示的な実施態様では、ダイアログ状態におけるユーザ・ダイアログ行為の予測の代替方法がある。それの元のプロセスが、図９における９１３０に示されている。このプロセスは、以降の例示的な実施態様において記述されている方法によって置き換えられる。

図３３は、例示的な一実施態様による、ユーザ・ダイアログ行為を予測するための手順を示している。この例示的な実施態様におけるダイアログ行為の予測は、マシン学習方法を利用する。はじめに、３３０１０に示されているようにダイアログ・コーパスが用意される。このダイアログ・コーパスは、システム発話、ユーザの発話、および対応するダイアログ行為を含む。システム発話は、「システム」というカテゴリー３３０２０を伴って３３０３０に示されている。ユーザ発話は、「ユーザ」というカテゴリー３３０２０を伴って３３０３０に示されている。それぞれの発話のダイアログ行為は、３３０４０に示されている。このダイアログ・コーパスは、ダイアログ・システムまたはサーバ内に格納されているダイアログ履歴から作成されることが可能である。

ダイアログ行為プレディクタの目的は、ダイアログ履歴を与えられると、ダイアログ行為プレディクタが、ユーザの次のダイアログ行為を予測することである。したがって、ダイアログ行為プレディクタのトレーニング・プロセスは、３３０５０に示されているダイアログ履歴を入力特徴として取り、次いで、ユーザの次のダイアログ行為３３０６０を出力するようにモデルをトレーニングする。

ダイアログ行為プレディクタの形態が、３３０６５に示されている。ダイアログ行為プレディクタは、システム発話エンコーダ３３０７０、ユーザ発話エンコーダ３３０８０、およびダイアログ行為確率カリキュレータ３３０９０を含む。システム発話エンコーダおよびユーザ発話エンコーダは、それぞれシステム発話またはユーザ発話を入力として受け取る。次いで入力発話がエンコードされることになる。これらのエンコーダがＲＮＮによって実施される場合には、エンコーディング・プロセスは、入力情報を、隠されたレイヤの値として保存する。最後に、これらのエンコーダの出力３３１００が、ダイアログ行為確率カリキュレータへ送信される。ダイアログ行為確率カリキュレータは、ユーザ・ダイアログ行為の確率を、それらのダイアログ行為が次に現れる可能性という点から計算する。ダイアログ行為プレディクタのコンポーネントは、さまざまな形態のニューラル・ネットワークによって実施される。

次のユーザ・ダイアログ行為の予測の方法は、マシン学習ベースのアルゴリズムを使用する。したがって、大量のダイアログ・コーパスが用意される場合には、高い精度を伴うダイアログ行為の予測を達成することができる。

図３４は、図１および図３に示されているダイアログ・システムの機能を実施することを容易にされているクライアント・デバイスまたはサーバなど、いくつかの例示的な実施態様における使用に適している例示的なコンピュータ・デバイスを伴う例示的なコンピューティング環境を示している。

コンピューティング環境３４００内のコンピュータ・デバイス３４０５は、１つまたは複数の処理ユニット、コア、またはプロセッサ３４１０、メモリ３４１５（たとえば、ＲＡＭ、ＲＯＭなど）、内蔵ストレージ３４２０（たとえば、磁気、光、ソリッド・ステート・ストレージ、および／もしくは有機）、ならびに／またはＩ／Ｏインターフェース３４２５を含むことができ、それらのいずれも、情報を通信するための通信メカニズムまたはバス３４３０上に結合されること、またはコンピュータ・デバイス３４０５内に埋め込まれることが可能である。

コンピュータ・デバイス３４０５は、入力／ユーザ・インターフェース３４３５および出力デバイス／インターフェース３４４０へ通信可能に結合されることが可能である。入力／ユーザ・インターフェース３４３５および出力デバイス／インターフェース３４４０の一方または両方は、有線またはワイヤレスのインターフェースであることが可能であり、取り外し可能であり得る。入力／ユーザ・インターフェース３４３５は、入力を提供するために使用されることが可能である物理的なまたは仮想の任意のデバイス、コンポーネント、センサ、またはインターフェース（たとえば、ボタン、タッチスクリーン・インターフェース、キーボード、ポインティング／カーソル制御、マイクロフォン、カメラ、点字、モーション・センサ、光学リーダなど）を含むことができる。出力デバイス／インターフェース３４４０は、ディスプレイ、テレビジョン、モニタ、プリンタ、スピーカ、点字などを含むことができる。いくつかの例示的な実施態様では、入力／ユーザ・インターフェース３４３５および出力デバイス／インターフェース３４４０は、コンピュータ・デバイス３４０５に埋め込まれること、または物理的に結合されることが可能である。その他の例示的な実施態様では、その他のコンピュータ・デバイスが、コンピュータ・デバイス３４０５のための入力／ユーザ・インターフェース３４３５および出力デバイス／インターフェース３４４０として機能すること、またはそれらの機能を提供することが可能である。

コンピュータ・デバイス３４０５の例は、高度にモバイルなデバイス（たとえば、スマートフォン、車両およびその他のマシン内のデバイス、人間および動物によって携帯されるデバイスなど）、モバイル・デバイス（たとえば、タブレット、ノート、ラップトップ、パーソナル・コンピュータ、ポータブル・テレビジョン、ラジオなど）、ならびにモビリティ用に設計されていないデバイス（たとえば、デスクトップ・コンピュータ、その他のコンピュータ、インフォメーション・センタ、１つまたは複数のプロセッサが内蔵および／または結合されているテレビジョン、ラジオなど）を含むことができるが、それらには限定されない。

コンピュータ・デバイス３４０５は、同じまたは異なる構成の１つまたは複数のコンピュータ・デバイスを含む、任意の数のネットワーク接続されているコンポーネント、デバイス、およびシステムと通信するために（たとえば、Ｉ／Ｏインターフェース３４２５を介して）外部ストレージ３４４５およびネットワーク３４５０へ通信可能に結合されることが可能である。コンピュータ・デバイス３４０５またはいずれかの接続されているコンピュータ・デバイスは、サーバ、クライアント、シン・サーバ、一般的なマシン、専用マシン、または別のラベルとして機能していること、それらのサービスを提供していること、またはそれらと呼ばれることが可能である。

Ｉ／Ｏインターフェース３４２５は、コンピューティング環境３４００内の少なくともすべての接続されているコンポーネント、デバイス、およびネットワークとの間で情報を通信するために任意の通信またはＩ／Ｏプロトコルまたは標準（たとえば、イーサネット（登録商標）、８０２．１１ｘ、ユニバーサル・システム・バス、ＷｉＭＡＸ、モデム、セルラー・ネットワーク・プロトコルなど）を使用する有線インターフェースおよび／またはワイヤレス・インターフェースを含むことができるが、それらには限定されない。ネットワーク３４５０は、任意のネットワークまたはネットワークの組合せ（たとえば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、電話ネットワーク、セルラー・ネットワーク、衛星ネットワークなど）であることが可能である。

コンピュータ・デバイス３４０５は、一時的なメディアおよび非一時的なメディアを含むコンピュータ使用可能メディアまたはコンピュータ可読メディアを使用すること、および／またはそれらを使用して通信を行うことが可能である。一時的なメディアは、伝送メディア（たとえば、金属ケーブル、光ファイバ）、信号、搬送波などを含む。非一時的なメディアは、磁気メディア（たとえば、ディスクおよびテープ）、光メディア（たとえば、ＣＤ ＲＯＭ、デジタル・ビデオ・ディスク、ブルーレイ・ディスク）、ソリッド・ステート・メディア（たとえば、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、ソリッド・ステート・ストレージ）、ならびにその他の不揮発性のストレージまたはメモリを含む。

コンピュータ・デバイス３４０５は、いくつかの例示的なコンピューティング環境における技術、方法、アプリケーション、プロセス、またはコンピュータ実行可能命令を実施するために使用されることが可能である。コンピュータ実行可能命令は、一時的なメディアから取り出されること、ならびに非一時的なメディア上に格納されることおよびそこから取り出されることが可能である。それらの実行可能命令は、任意のプログラミング言語、スクリプト言語、およびマシン語（たとえば、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、ＪａｖａＳｃｒｉｐｔ（登録商標）、およびその他）のうちの１つまたは複数から生じることが可能である。

プロセッサ３４１０は、ネイティブ環境または仮想環境において、任意のオペレーティング・システム（ＯＳ）（図示せず）のもとで実行することができる。ロジック・ユニット３４６０、アプリケーション・プログラミング・インターフェース（ＡＰＩ）ユニット３４６５、入力ユニット３４７０、出力ユニット３４７５、ならびに、さまざまなユニットが互いに、ＯＳと、およびその他のアプリケーション（図示せず）と通信するためのユニット間通信メカニズム３４９５を含む１つまたは複数のアプリケーションが展開されることが可能である。記述されているユニットおよび要素は、設計、機能、構成、または実施態様において変更されることが可能であり、提供されている説明には限定されない。

いくつかの例示的な実施態様では、情報または実行命令がＡＰＩユニット３４６５によって受け取られた場合に、それは、１つまたは複数のその他のユニット（たとえば、ロジック・ユニット３４６０、入力ユニット３４７０、出力ユニット３４７５）へ通信されることが可能である。いくつかの場合では、ロジック・ユニット３４６０は、ユニット間における情報フローを制御し、上述のいくつかの例示的な実施態様においてＡＰＩユニット３４６５、入力ユニット３４７０、出力ユニット３４７５によって提供されているサービスを指示するように構成されることが可能である。たとえば、１つまたは複数のプロセスまたは実施態様のフローは、ロジック・ユニット３４６０のみによって、またはＡＰＩユニット３４６５とともに制御されることが可能である。入力ユニット３４７０は、例示的な実施態様において記述されている計算のための入力を入手するように構成されることが可能であり、出力ユニット３４７５は、例示的な実施態様において記述されている計算に基づく出力を提供するように構成されることが可能である。

図３５は、例示的な一実施態様による、ロボットなどのクライアント・デバイスに関する例示的なハードウェア図を示している。ロボット３５００を含む実施態様では、ロボット３５００は、スピーチまたはテキスト入力を介してユーザと対話するように構成されることが可能であり、プロセッサ３５０１、メモリ３５０２、通信インターフェース３５０３、カメラ３５０４などの１つまたは複数のセンサ、および１つまたは複数のアクチュエータ３５０５を含むことができる。メモリ３５０２は、本明細書において記述されている流れ図を実行するためにプロセッサ３５０１内にロードされることが可能である命令を格納することができる。通信インターフェース３５０３は、ベースバンド・プロセッサを通じて、図３において記述されているサーバと対話するように構成されることが可能であり、所望の実施態様に応じてスピーチまたは表示されるテキストの形態のダイアログ行為を出力するためのディスプレイまたはスピーカなどのローカル通信インターフェースを提供することもできる。センサ３５０４は、ユーザからのスピーチを、入力ダイアログへ変換される入力として取るためのマイクロフォンを含むことができ、またはテキスト入力を受け取るように構成されているキーボードまたはタッチ・インターフェースなどのその他の入力デバイスを含むことができる。アクチュエータ３５０５は、所望の実施態様に従って出力スピーチまたはテキストに同期化されることが可能であるロボット３５００の部分（たとえば、アーム、脚、ホイールなど）を作動させるように構成されることが可能である。

例示的な実施態様は、図１に示されているダイアログ・システムのためのシステム、コンピュータ可読メディア、および方法を含むことができ、そのダイアログ・システムは、図３４および図３５に示されているようなユーザ入力を受け取るためのテキスト入力方法および図１に示されている、サーバと通信するように構成されている第１の自然言語理解（ＮＬＵ）モデルと共に構成され、ユーザ入力は、ユーザによってタイプされたテキスト入力または図４（ａ）において記述されているユーザ・スピーチから入手された自動スピーチ認識（ＡＳＲ）出力のうちの少なくとも１つを含む、クライアント・デバイスと、図３に示されている第２のＮＬＵモデルを含むサーバとを含み、第１のＮＬＵモデルと第２のＮＬＵモデルとは異なる。そのような方法は、第１のＮＬＵモデルを適用することからクライアント・デバイスにおける入力ダイアログのＮＬＵ結果を特定するステップと、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果の確信性スコアまたは値がしきい値を満たしていない場合、入力ダイアログ上で第２のＮＬＵモデルを使用することによってＮＬＵプロセスを実行するためにサーバにアクセスすることをクライアント・デバイスに行わせるステップと、第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果の確信性スコアまたは値がしきい値を満たしている場合、たとえば図４（ａ）に示されている第１のＮＬＵモデルを適用することから入手されたＮＬＵ結果に基づくアクションをクライアント・デバイスに実行させるステップとを含むことができる。

例示的な実施態様は、第１のＮＬＵモデルを適用することによって入手されたＮＬＵ結果が、入力ダイアログ内のワードの数が別のしきい値を下回っていることから導き出されており、かつＮＬＵ結果が、入力ダイアログのダイアログ状態において予想されるＮＬＵ出力の数よりも少ない場合に関してのみ、ＮＬＵプロセスを実行するためにサーバにアクセスすることをクライアント・デバイスに行わせるステップを含むこともでき、予想されるＮＬＵ出力は、たとえば図４（ａ）および図４（ｂ）に示されている入力ダイアログに関連付けられているダイアログ・シナリオから特定される。

例示的な実施態様は、矛盾を探して、クライアント・デバイスのＮＬＵ結果におけるダイアログ行為を、サーバのＮＬＵ結果において入手されたダイアログ行為と比較するステップと、比較するステップが矛盾を示している場合、図１１に示されている、より低い確信性スコアを有する矛盾しているダイアログ行為を破棄するステップとを含むこともできる。

例示的な実施態様は、第１のしきい値よりも高い確信性スコアまたは値を有しているクライアント・デバイスのＮＬＵ結果を採用するステップと、ＮＬＵ結果が、第１のしきい値よりも低い確信性スコアまたは値、および第２のしきい値よりも高い確信性スコアまたは値を有している場合、ＮＬＵ結果を確認するための確認ダイアログを実施するステップと、ＮＬＵ結果が、第２のしきい値よりも低い確信性スコアまたは値を有している場合、図８に示されているＮＬＵ結果を破棄するステップとを含むこともできる。そのような例示的な実施態様では、確認、採用、および破棄は、ＮＬＵ結果のダイアログ行為がセマンティック空間から得られたかどうか、ダイアログ行為がサーバから入手されたかどうか、およびダイアログ行為とフレーズとのペアが、図８において記述されているダイアログ行為／チャンク情報から参照される真の固定フラグに関連付けられているかどうか、のうちの少なくとも１つに基づいて行われることが可能である。確認ダイアログを実施するステップは、抽出されたダイアログ行為が正しいかどうかをクエリするステップと、それに応答してフィードバック・タプルを作成するステップであって、抽出されたダイアログ行為が正しいというクエリに応答して、ダイアログ行為と、対応するフレーズとを含むペアを肯定的なフィードバックに関連付けるステップと、抽出されたダイアログ行為が正しくないというクエリに応答して、ダイアログ行為と、対応するフレーズとのペアを否定的なフィードバックに関連付けるステップとを含む、ステップと、フィードバック・タプルを利用して、ダイアログ行為／チャンク情報を更新するステップであって、肯定的なフィードバックに関連付けられているフィードバック・タプルに関して、ダイアログ行為／チャンク情報内の肯定的なフィードバック値をインクリメントするステップと、否定的なフィードバックに関連付けられているフィードバック・タプルに関して、ダイアログ行為／チャンク情報内の否定的なフィードバック値をインクリメントするステップとを含む、ステップと、ダイアログ行為／チャンク・ペアに関して偽であることを示す固定フラグに関して、ダイアログ行為／チャンク・ペアの関連性値を、図６、図８、図１１、および図１４に示されている否定的なフィードバック値に対する肯定的なフィードバック値の比率として計算するステップとを含むこともできる。

例示的な実施態様では、ＮＬＵ結果を確認するための確認ダイアログを実施するステップは、別のしきい値を下回る確信性スコアまたは値を有する確認応答に関して、図４（ａ）または図４（ｂ）に示されているサーバ内の第２のＮＬＵモデルを適用することによって確認応答に関してＮＬＵプロセスを実行するようクライアント・デバイスからサーバへ要求するステップを含むことができる。

例示的な実施態様では、ＮＬＵ結果を確認するための確認ダイアログを実施するステップは、クライアントおよびサーバのうちの少なくとも１つから、確認ダイアログへの応答に基づいて確信性スコアまたは値を評価するステップを含むことができ、肯定的なフィードバックおよび否定的なフィードバックのインクリメントの値は、たとえば図６〜図１４に示されている確信性スコアに基づいて特定される。

例示的な実施態様は、サーバにおいて、クライアント・デバイスからのフィードバックを収集するステップと、サーバにおいて、ＮＬＵ更新情報を生成するステップと、ＮＬＵ更新情報をクライアント・デバイスに提供するステップと、ＮＬＵ情報から第１のＮＬＵモデルを更新するステップとを含むこともでき、更新するステップは、更新するステップをクライアント・デバイスにおいて実行し、それによって、第１のＮＬＵモデルに対する矛盾しているＮＬＵ更新をチェックすること、および図２１に示されているＮＬＵ更新情報を適用することからのテスト・データ上でのＮＬＵ精度をチェックすることのうちの少なくとも１つを通じてその精度の劣化が防止されるステップを含む。

例示的な実施態様は、入力ダイアログ上で第２のＮＬＵモデルを使用することによるＮＬＵプロセスの実行に関して、ＮＬＵプロセスから入手されたＮＬＵ結果をサーバからクライアント・デバイスに提供するステップと、提供されたＮＬＵ結果を第１のＮＬＵモデルに登録し、それによって第１のＮＬＵモデルが、図４（ａ）および図４（ｂ）に示されている入力ダイアログに応答してサーバにアクセスすることなく、提供されたＮＬＵ結果を出力するように構成されるステップとを含むこともできる。

例示的な実施態様では、第１のＮＬＵモデルおよび第２のＮＬＵモデルが、有限状態トランスデューサ（ＦＳＴ）ベースのアルゴリズムから生成されることが可能であり、そのアルゴリズムでは、入力ダイアログ内のフレーズがＦＳＴ上にマップされ、ＦＳＴ内のアークが、対応するダイアログ行為、およびダイアログ行為／チャンク・ペア情報に基づく重みに結び付けられ、第１のＮＬＵモデルまたは第２のＮＬＵモデルを適用することから入力ダイアログのＮＬＵ結果を特定するステップは、ＦＳＴ上で最短経路探索を実施するステップと、重みの合計が、図５〜図７、図１１、図１５、および図１６に示されている別のしきい値を下回っている場合最短経路探索の１つまたは複数の経路に沿ってダイアログ行為を出力するステップとを含むことができる。ＦＳＴ内のアークは、入力ダイアログ内のフレーズと、図５〜図７、図１６、および図１７に示されているダイアログ行為／チャンク・ペア情報内の既に知られているフレーズとの間におけるセマンティック距離に基づくダイアログ行為を含む。

例示的な実施態様では、ダイアログ行為／チャンク・ペア情報は、関連性スコア、肯定的なフィードバック、否定的なフィードバック、得票数、および固定フラグを含むことができ、関連性スコアは、ＦＳＴアーク内の重みを特定するために利用され、肯定的なフィードバックは、確認ダイアログへの肯定的なフィードバック応答に応答してインクリメントされ、否定的なフィードバックは、確認ダイアログへの否定的なフィードバック応答に応答してインクリメントされ、得票数は、フィードバック頻度を格納し、固定フラグは、事前に定義されており、対応するダイアログ行為／チャンク・ペアがさらなるプロセスにおいて修正されることを許可されていないかどうかを示し、得票数が得票数しきい値よりも大きく、関連性値が関連性しきい値よりも高いかまたは図７〜図１４において記述されている関連性しきい値よりも低い場合に偽から真へ変更されるように構成されている。

例示的な実施態様では、第１のＮＬＵモデルおよび第２のＮＬＵモデルは、マシン学習を利用するシーケンス・ラベリング方法を実施するように構成されているトレーニング・アルゴリズムから生成され、第１のＮＬＵモデルおよび第２のＮＬＵモデルは、センテンスと、センテンス内のそれぞれのワードおよび図１７または図２６において記述されているそれぞれのセンテンスのうちの少なくとも１つに関する関連付けられているダイアログ行為とを含むトレーニング・データを使用することによってトレーニングされる。個々のワードおよびセンテンスは、ゼロのダイアログ行為に関連付けられることが可能であり、または１つもしくは複数のダイアログ行為に関連付けられることが可能である。

例示的な実施態様は、抽出されたダイアログ行為が正しいかどうかを促すように構成されている確認ダイアログを提供するステップと、ＮＬＵアルゴリズム・トレーニングのためにトレーニング・データに加えられる、確認ダイアログへの応答に基づくフィードバック・トレーニング・データを作成するステップとをさらに含むことができ、フィードバック・トレーニング・データを作成するステップは、確認ダイアログへの応答が肯定的である場合、対応するフレーズを、抽出されたダイアログ行為でラベル付けするステップと、確認ダイアログへの応答が否定的である場合、対応するフレーズを、図３から図３６までのさまざまな実施態様において記述されている抽出されたダイアログ行為を生成しないようにラベル付けするステップとを含む。

例示的な実施態様では、テキスト入力は、コンフュージョン・ネットワークへ変換されるセンテンス入力の１つまたは複数の候補を含み、この方法は、コンフュージョン・ネットワークを、アークの重みがワードの確信性に基づいて特定される第１のＦＳＴへ変換するステップと、ダイアログ行為／チャンク情報を、ワード入力を受け取ってダイアログ行為を出力する第２のＦＳＴへ変換するステップとをさらに含み、ＮＬＵプロセスは、テキスト入力から得られた第１のＦＳＴと、図２０〜図２４に示されているダイアログ行為／チャンク情報から得られた第２のＦＳＴとを合成するステップを含む。所望の実施態様に応じて、マシン学習アルゴリズムは、ワードの１つまたは複数の候補を含む入力を受け取って図１７および図１８（ａ）から図１８（ｂ）に示されている入力に対応するダイアログ行為を出力するように構成されているリカレント・ニューラル・ネットワーク（ＲＮＮ）であることが可能である。

例示的な実施態様では、第１のＮＬＵモデルおよび第２のＮＬＵモデルは、有限状態トランスデューサ（ＦＳＴ）ベースのアルゴリズムと、図１７から図２６に示されているシーケンス・ラベル付けアルゴリズムとの組合せであるＮＬＵアルゴリズムに関連付けられている。

例示的な実施態様では、第１のＮＬＵモデルおよび第２のＮＬＵモデルのそれぞれは、アウトオブトピックＮＬＵを含み、アウトオブトピックＮＬＵは、ダイアログ・コーパスによってトレーニングされ、ダイアログ履歴情報および入力ダイアログのうちの少なくとも１つを受け取り、システム発話を出力するように構成されており、出力が、第１のＮＬＵモデルおよび第２のＮＬＵモデルにおいて構成されているその他のＮＬＵよりも大きな確信性を有している場合、アウトオブトピックＮＬＵによって出力されたシステム発話が、図４（ａ）、図４（ｂ）、および図２７に示されているように採用される。そのような例示的な実施態様では、アウトオブトピックＮＬＵは、アウトオブトピックＮＬＵモデルからのそれぞれのシステム・センテンスの出力確率に基づいてシステム発話の事前に定義されたリスト内で１つの確信を持てるシステム発話を選ぶように構成されることが可能である。

詳細な説明のいくつかの部分は、コンピュータ内のオペレーションのアルゴリズムおよびシンボル表示という点から提示されている。これらのアルゴリズム記述およびシンボル表示は、データ処理技術分野における技術者たちによって、それらの技術者たちのイノベーションの本質を他の当業者たちに伝達するために使用される手段である。アルゴリズムとは、所望の最終状態または結果へつながる一連の定義されたステップである。例示的な実施態様では、実行されるステップは、具体的な結果を達成するための具体的な量の物理的な操作を必要とする。

特に別段の記載がない限り、論考から明らかなように、この説明を通じて、「処理する」、「算出する」、「計算する」、「特定する」、「表示する」等などの用語を利用している論考は、コンピュータ・システムのレジスタおよびメモリ内の物理的な（電子的な）量として表されているデータを、コンピュータ・システムのメモリまたはレジスタまたはその他の情報ストレージ・デバイス、情報伝送デバイス、または情報表示デバイス内で同様に物理量として表されるその他のデータへと操作および変換する、コンピュータ・システムまたはその他の情報処理デバイスのアクションおよびプロセスを含むことができることがわかる。

例示的な実施態様は、本明細書におけるオペレーションを実行するための装置に関連することも可能である。この装置は、求められている目的のために特別に構築されることが可能であり、または１つもしくは複数のコンピュータ・プログラムによって選択的にアクティブ化もしくは再構成される１つもしくは複数の汎用コンピュータを含むことができる。そのようなコンピュータ・プログラムは、コンピュータ可読ストレージ・メディアまたはコンピュータ可読信号メディアなどのコンピュータ可読メディア内に格納されることが可能である。コンピュータ可読ストレージ・メディアは、有形のメディアを含むことができ、それらの有形のメディアは、光ディスク、磁気ディスク、読み取り専用メモリ、ランダム・アクセス・メモリ、ソリッド・ステート・デバイスおよびドライブ、または、電子情報を格納するのに適しているその他の任意のタイプの有形のまたは非一時的なメディアなどであるが、それらには限定されない。コンピュータ可読信号メディアは、搬送波などのメディアを含むことができる。本明細書において提示されているアルゴリズムおよび表示は、いかなる特定のコンピュータまたはその他の装置にも本質的に関連しているものではない。コンピュータ・プログラムは、所望の実施態様のオペレーションを実行する命令を含む純粋なソフトウェア実施態様を含むことができる。

さまざまな汎用システムが、本明細書における例によるプログラムおよびモジュールとともに使用されることが可能であり、または所望の方法ステップを実行するためのさらに特化している装置を構築することが好都合であると判明する場合もある。加えて、例示的な実施態様は、いずれかの特定のプログラミング言語を参照して記述されているものではない。本明細書において記述されている例示的な実施態様の教示を実施するためにさまざまなプログラミング言語を使用することができることがわかるであろう。プログラミング言語の命令は、１つまたは複数の処理デバイス、たとえば、中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラによって実行されることが可能である。

当技術分野において知られているように、上述のオペレーションは、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアとの何らかの組合せによって実行されることが可能である。例示的な実施態様のさまざまな態様は、回路およびロジック・デバイス（ハードウェア）を使用して実施されることが可能であり、その一方でその他の態様は、マシン可読メディア（ソフトウェア）上に格納されている命令を使用して実施されることが可能であり、それらの命令は、プロセッサによって実行された場合に、本出願の実施態様を実行するための方法をプロセッサに行わせることになる。さらに、本出願のいくつかの例示的な実施態様は、もっぱらハードウェアで実行されることが可能であり、その一方でその他の例示的な実施態様は、もっぱらソフトウェアで実行されることが可能である。その上、記述されているさまざまな機能は、単一のユニットにおいて実行されることが可能であり、または任意の数の方法で複数のコンポーネントにわたって分散されることが可能である。ソフトウェアによって実行される場合には、それらの方法は、コンピュータ可読メディア上に格納されている命令に基づいて汎用コンピュータなどのプロセッサによって実行されることが可能である。所望の場合には、それらの命令は、圧縮および／または暗号化されたフォーマットでメディア上に格納されることが可能である。

その上、本出願のその他の実施態様は、本明細書の考慮および本出願の教示の実践から当業者にとって明らかになるであろう。記述されている例示的な実施態様のさまざまな態様および／またはコンポーネントは、単独でまたは任意の組合せで使用されることが可能である。本明細書および例示的な実施態様は、例としてのみ考慮されることを意図されており、本出願の真の範囲および趣旨は、添付の特許請求の範囲によって示されている。

Claims (20)

1. ユーザ入力を受け取るためのテキスト入力方法およびサーバと通信するように構成されている第１の自然言語理解（ＮＬＵ）モデルと共に構成され、前記ユーザ入力は、前記ユーザによってタイプされたテキスト入力またはユーザ・スピーチから入手された自動スピーチ認識（ＡＳＲ）出力のうちの少なくとも１つを含む、クライアント・デバイスと、第２のＮＬＵモデルを含むサーバとを含むダイアログ・システムのための方法であって、前記第１のＮＬＵモデルと前記第２のＮＬＵモデルとが異なり、前記方法が、
   前記第１のＮＬＵモデルを適用することから前記クライアント・デバイスにおける入力ダイアログのＮＬＵ結果を特定するステップと、
   前記第１のＮＬＵモデルを適用することから入手された前記ＮＬＵ結果の確信性スコアがしきい値を満たしていない場合、前記入力ダイアログ上で前記第２のＮＬＵモデルを使用することによってＮＬＵプロセスを実行するために前記サーバにアクセスすることを前記クライアント・デバイスに行わせるステップと、
   前記第１のＮＬＵモデルを適用することから入手された前記ＮＬＵ結果の前記確信性スコアが前記しきい値を満たしている場合、前記第１のＮＬＵモデルを適用することから入手された前記ＮＬＵ結果に基づくアクションを前記クライアント・デバイスに実行させるステップとを含む方法。
2. 前記ＮＬＵプロセスを実行するために前記サーバにアクセスすることを前記クライアント・デバイスに行わせる前記ステップは、前記第１のＮＬＵモデルを適用することによって入手された前記ＮＬＵ結果が、前記入力ダイアログ内のワードの数が別のしきい値を下回っていることから導き出されており、かつ前記ＮＬＵ結果が、前記入力ダイアログのダイアログ状態において予想されるＮＬＵ出力の数よりも少ない場合に関してのみ実施され、予想される前記ＮＬＵ出力が、前記入力ダイアログに関連付けられているダイアログ・シナリオから特定される、請求項１に記載の方法。
3. 矛盾を探して、前記クライアント・デバイスの前記ＮＬＵ結果におけるダイアログ行為を、前記サーバのＮＬＵ結果において入手されたダイアログ行為と比較するステップと、
   比較する前記ステップが矛盾を示している場合、より低い確信性スコアを有する矛盾しているダイアログ行為を破棄するステップと
   をさらに含む、請求項１に記載の方法。
4. 第１のしきい値よりも高い確信性スコアを有している前記クライアント・デバイスの前記ＮＬＵ結果を採用するステップと、
   前記ＮＬＵ結果が、前記第１のしきい値よりも低い確信性スコア、および第２のしきい値よりも高い確信性スコアを有している場合、前記ＮＬＵ結果を確認するための確認ダイアログを実施するステップと、
   前記ＮＬＵ結果が、前記第２のしきい値よりも低い確信性スコアを有している場合、前記ＮＬＵ結果を破棄するステップと
   をさらに含む、請求項１に記載の方法。
5. 前記確認、前記採用、および前記破棄が、
   前記ＮＬＵ結果のダイアログ行為がセマンティック空間から得られたかどうか、
   前記ダイアログ行為が前記サーバから入手されたかどうか、
   前記ダイアログ行為とフレーズとのペアが、ダイアログ行為／チャンク情報から参照される真の固定フラグに関連付けられているかどうか、のうちの少なくとも１つに基づいて行われる、請求項４に記載の方法。
6. 前記確認ダイアログを実施する前記ステップが、
   抽出されたダイアログ行為が正しいかどうかをクエリするステップと、
   それに応答してフィードバック・タプルを作成するステップであって、
   前記抽出されたダイアログ行為が正しいという前記クエリに応答して、前記ダイアログ行為と、対応するフレーズとを含むペアを肯定的なフィードバックに関連付けるステップと、
   前記抽出されたダイアログ行為が正しくないという前記クエリに応答して、前記ダイアログ行為と前記対応するフレーズとの前記ペアを否定的なフィードバックに関連付けるステップとを含む、ステップと、
   前記フィードバック・タプルを利用して、ダイアログ行為／チャンク情報を更新するステップであって、
   前記肯定的なフィードバックに関連付けられている前記フィードバック・タプルに関して、前記ダイアログ行為／チャンク情報内の肯定的なフィードバック値をインクリメントするステップと、
   否定的なフィードバックに関連付けられている前記フィードバック・タプルに関して、前記ダイアログ行為／チャンク情報内の否定的なフィードバック値をインクリメントするステップとを含む、ステップと、
   ダイアログ行為／チャンク・ペアに関して偽であることを示す固定フラグに関して、前記ダイアログ行為／チャンク・ペアの関連性値を、前記否定的なフィードバック値に対する前記肯定的なフィードバック値の比率として計算するステップとを含む、請求項４に記載の方法。
7. 前記ＮＬＵ結果を確認するための前記確認ダイアログを実施する前記ステップが、
   別のしきい値を下回る確信性スコアを有する確認応答に関して、前記サーバ内の前記第２のＮＬＵモデルを適用することによって前記確認応答に関して前記ＮＬＵプロセスを実行するよう前記クライアント・デバイスから前記サーバへ要求するステップを含む、請求項６に記載の方法。
8. 前記ＮＬＵ結果を確認するための前記確認ダイアログを実施する前記ステップが、
   前記クライアントおよび前記サーバのうちの少なくとも１つから、前記確認ダイアログへの応答に基づいて確信性スコアを評価するステップを含み、
   前記肯定的なフィードバックおよび前記否定的なフィードバックの前記インクリメントの値が、前記確信性スコアに基づいて特定される、請求項６に記載の方法。
9. 前記サーバにおいて、前記クライアント・デバイスからのフィードバックを収集するステップと、
   前記サーバにおいて、ＮＬＵ更新情報を生成するステップと、
   前記ＮＬＵ更新情報を前記クライアント・デバイスに提供するステップと、
   前記ＮＬＵ情報から前記第１のＮＬＵモデルを更新するステップとをさらに含み、更新する前記ステップが、
   更新する前記ステップを前記クライアント・デバイスにおいて実行し、それによって、前記第１のＮＬＵモデルに対する矛盾しているＮＬＵ更新をチェックすること、および前記ＮＬＵ更新情報を適用することからのテスト・データ上でのＮＬＵ精度をチェックすることのうちの少なくとも１つを通じて前記精度の劣化が防止されるステップを含む、
   請求項４に記載の方法。
10. 前記入力ダイアログ上で前記第２のＮＬＵモデルを使用することによる前記ＮＬＵプロセスの前記実行に関して、前記ＮＬＵプロセスから入手された前記ＮＬＵ結果を前記サーバから前記クライアント・デバイスに提供するステップと、
    前記提供されたＮＬＵ結果を前記第１のＮＬＵモデルに登録し、それによって前記第１のＮＬＵモデルが、前記入力ダイアログに応答して前記サーバにアクセスすることなく前記提供されたＮＬＵ結果を出力するように構成されるステップと
    をさらに含む、請求項１に記載の方法。
11. 前記第１のＮＬＵモデルおよび前記第２のＮＬＵモデルが、有限状態トランスデューサ（ＦＳＴ）ベースのアルゴリズムから生成され、前記アルゴリズムでは、前記入力ダイアログ内のフレーズがＦＳＴ上にマップされ、前記ＦＳＴ内のアークが、対応するダイアログ行為、およびダイアログ行為／チャンク・ペア情報に基づく重みに結び付けられ、
    前記第１のＮＬＵモデルまたは前記第２のＮＬＵモデルを適用することから前記入力ダイアログのＮＬＵ結果を特定する前記ステップが、
    前記ＦＳＴ上で最短経路探索を実施するステップと、
    前記重みの合計が別のしきい値を下回っている場合前記最短経路探索の１つまたは複数の経路に沿ってダイアログ行為を出力するステップとを含む、請求項１に記載の方法。
12. 前記ＦＳＴ内の前記アークが、前記入力ダイアログ内のフレーズと、前記ダイアログ行為／チャンク・ペア情報内の既に知られているフレーズとの間におけるセマンティック距離に基づくダイアログ行為を含む、請求項１１に記載の方法。
13. 前記ダイアログ行為／チャンク・ペア情報が、関連性スコア、肯定的なフィードバック、否定的なフィードバック、得票数、および固定フラグを含み、
    前記関連性スコアが、前記ＦＳＴアーク内の前記重みを特定するために利用され、
    前記肯定的なフィードバックが、確認ダイアログへの肯定的なフィードバック応答に応答してインクリメントされ、
    前記否定的なフィードバックが、前記確認ダイアログへの否定的なフィードバック応答に応答してインクリメントされ、
    前記得票数が、フィードバック頻度を格納し、
    前記固定フラグは、事前に定義されており、対応するダイアログ行為／チャンク・ペアがさらなるプロセスにおいて修正されることを許可されていないかどうかを示し、前記得票数が得票数しきい値よりも大きく、前記関連性値が関連性しきい値よりも高いかまたは関連性しきい値よりも低い場合に偽から真へ変更されるように構成されている、
    請求項１１に記載の方法。
14. 前記第１のＮＬＵモデルおよび前記第２のＮＬＵモデルが、マシン学習を利用するシーケンス・ラベリング方法を実施するように構成されているトレーニング・アルゴリズムから生成され、
    前記第１のＮＬＵモデルおよび前記第２のＮＬＵモデルが、センテンスと、前記センテンス内のそれぞれのワードおよびそれぞれのセンテンスのうちの少なくとも１つに関する関連付けられているダイアログ行為とを含むトレーニング・データを使用することによってトレーニングされる、請求項１に記載の方法。
15. 抽出されたダイアログ行為が正しいかどうかを促すように構成されている確認ダイアログを提供するステップと、
    ＮＬＵアルゴリズム・トレーニングのために前記トレーニング・データに加えられる、前記確認ダイアログへの応答に基づくフィードバック・トレーニング・データを作成するステップとをさらに含み、前記フィードバック・トレーニング・データを作成する前記ステップが、
    前記確認ダイアログへの前記応答が肯定的である場合、対応するフレーズを、前記抽出されたダイアログ行為でラベル付けするステップと、
    前記確認ダイアログへの前記応答が否定的である場合、前記対応するフレーズを、前記抽出されたダイアログ行為を生成しないようにラベル付けするステップとを含む、
    請求項１４に記載の方法。
16. 前記テキスト入力が、コンフュージョン・ネットワークへ変換されるセンテンス入力の１つまたは複数の候補を含み、前記方法が、
    前記コンフュージョン・ネットワークを、アークの重みがワードの確信性に基づいて特定される第１のＦＳＴへ変換するステップと、
    ダイアログ行為／チャンク情報を、ワード入力を受け取ってダイアログ行為を出力する第２のＦＳＴへ変換するステップとをさらに含み、
    前記ＮＬＵプロセスが、前記テキスト入力から得られた前記第１のＦＳＴと、前記ダイアログ行為／チャンク情報から得られた前記第２のＦＳＴとを合成するステップを含む、請求項１に記載の方法。
17. 前記マシン学習アルゴリズムが、ワードの１つまたは複数の候補を含む入力を受け取って前記入力に対応するダイアログ行為を出力するように構成されているリカレント・ニューラル・ネットワーク（ＲＮＮ）である、請求項１４に記載の方法。
18. 前記第１のＮＬＵモデルおよび前記第２のＮＬＵモデルが、有限状態トランスデューサ（ＦＳＴ）ベースのアルゴリズムと、シーケンス・ラベル付けアルゴリズムとの組合せであるＮＬＵアルゴリズムに関連付けられている、請求項１に記載の方法。
19. 前記第１のＮＬＵモデルおよび前記第２のＮＬＵモデルのそれぞれが、アウトオブトピックＮＬＵを含み、前記アウトオブトピックＮＬＵが、ダイアログ・コーパスによってトレーニングされ、
    ダイアログ履歴情報および前記入力ダイアログのうちの少なくとも１つを受け取り、
    システム発話を出力するように構成されており、前記出力が、前記第１のＮＬＵモデルおよび前記第２のＮＬＵモデルにおいて構成されているその他のＮＬＵよりも大きな確信性を有している場合、前記アウトオブトピックＮＬＵによって出力された前記システム発話が採用される、請求項１に記載の方法。
20. 前記アウトオブトピックＮＬＵが、前記アウトオブトピックＮＬＵモデルからのそれぞれのシステム・センテンスの出力確率に基づいて前記システム発話の事前に定義されたリスト内で１つの確信を持てるシステム発話を選ぶように構成されている、請求項１９に記載の方法。