WO2019244455A1 - 情報処理装置及び情報処理方法 - Google Patents

Abstract

ユーザーの発話を解釈する情報処理装置及び情報処理方を提供する。　情報処理装置は、ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成部と、前記生成部によりインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定部を具備する。インテント又はスロットに関する解釈内容とその解釈内容が適用されるべきコンテキスト情報を解釈知識として記憶しておき、前記判定部は、コンテキスト情報のマッチングに基づいて、ユーザーの発話意図の解釈を判定する。

Description

情報処理装置及び情報処理方法

　本明細書で開示する技術は、ユーザーの発話を解釈する情報処理装置及び情報処理方法に関する。

　近年、音声認識技術並びに機械学習技術などの発展に伴い、情報機器や家電機器などさまざまな電子機器に「音声エージェント」とも呼ばれる発話機能が搭載されるようになってきている。音声エージェントを搭載した電子機器は、ユーザーの発話を解釈して、音声で指示された機器操作を実行したり、機器の状態の報知や使い方の説明などに関する音声ガイダンスを行ったりする。また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）デバイスにはマウスやキーボードといった従来の入力装置が不在であり、文字情報よりも音声情報を用いたユーザーインターフェース（ＵＩ）が有力である。

　ここで、人間はあいまい性を含んだ発話を行うことが多い、という問題がある。例えば、「マイクを再生して」という発話に対しては、以下の（１）～（３）に示すような数通りの解釈が考えられる。

（１）マイクという歌手の曲を再生する（インテント：音楽再生、スロット：［歌手］＝マイク）
（２）マイクというタイトルの映画を再生する（インテント：映画再生、スロット：［映画タイトル］＝マイク）
（３）マイクというＴＶ番組を録画してあるので再生する（インテント：ＴＶ番組再生、スロット：［ＴＶ番組名］＝マイク）

　また、「大崎の天気を教えて」という発話に対しては、日本国内には大崎という名称がつく地名がいくつか存在することに起因して、以下の（１）～（３）に示すような数通りの解釈が考えられる。

（１）鹿児島の大崎町（スロット：［場所］＝鹿児島の大崎町）
（２）宮城県の大崎市（スロット：［場所］＝宮城県の大崎市）
（３）東京都品川区の大崎（スロット：［場所］＝東京都品川区の大崎）

　音声による対話を行うサービスにおいて、あいまい性を含んだユーザーの発話に対してシステムが誤った解釈（若しくは、ユーザーの意図とは異なる解釈）を行うと、ユーザーの期待と異なる応答を返すことになってしまう。ユーザーは、自分の要求が満たされないことが数回続くと、システムに不信を抱くようになり、さらにシステムを利用しなくなってしまう可能性がある。

　例えば、複数のシチュエーションのそれぞれに関連する語彙の集合からなるシチュエーション言語モデルと、語彙の集合である切り替え言語モデルを備え、ユーザーの発話の意図を、上記シチュエーション言語モデルと切り替え言語モデルを参照して解釈し、ユーザーの発話の中に、切り替え言語モデルに含まれるが現在のシチュエーション言語モデルには含まれない語彙がある場合、現在のシチュエーションに代えて当該語彙に対応するシチュエーションに応じた発話を生成する対話方法について提案がなされている（特許文献１を参照のこと）。

　また、複数のモジュールを備えることで、発話の質が異なる発話候補を生成し、ユーザーの発話に対してより適切な発話候補を生成するモジュールから順に発話候補を生成する発話候補生成装置について提案がなされている（特許文献２を参照のこと）。

特開２００９－３６９９８号公報 特開２０１４－２２２４０２号公報

　本明細書で開示する技術の目的は、あいまい性を含んだユーザーの発話をできるだけ正しく解釈できるようにする情報処理装置及び情報処理方法を提供することにある。

　本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、
　ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成部と、
　前記生成部によりインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定部と、
を具備する情報処理装置である。ここで、インテントは、ユーザーが発話により実行を要求するアプリケーション又はサービスであり、スロットは、アプリケーション又はサービスを実行する際の付属情報である。また、コンテキスト情報は、ユーザーの発話時に発話音声以外の状況に関する情報である。

　第１の側面に係る情報処理装置は、ユーザーの発話時のコンテキスト情報を取得する収集部、ユーザーの発話意図に基づいて音声によりユーザーに応答する応答部、前記応答部による応答に対するユーザーからのフィードバック情報を収集する収集部をさらに備える。

　また、第１の側面に係る情報処理装置は、インテント又はスロットに関する解釈内容とその解釈内容が適用されるべきコンテキスト情報を解釈知識として記憶する記憶部をさらに備え、前記判定部は、ユーザーの発話時のコンテキスト情報にマッチする解釈知識に基づいて、ユーザーの発話意図に対する解釈を判定するようになっている。

　また、本明細書で開示する技術の第２の側面は、
　ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成ステップと、
　前記生成ステップにおいてインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定ステップと、
を有する情報処理方法である。

　本明細書で開示する技術によれば、コンテキスト情報（いつ発話したか、だれが発話したかなどの現在の状況）とユーザーフィードバック情報（過去のシステム応答に対するユーザーの反応（要求が満たされたか、そうでなかったかなど）を用いて、あいまい性を含んだユーザーの発話をより正しく解釈することができる情報処理装置及び情報処理方法を提供することができる。

　なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

　本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、音声エージェント機能を搭載した情報処理装置１００の構成例を模式的に示した図である。 図２は、情報処理装置１００が音声エージェントとして動作するためのソフトウェア構成例を模式的に示した図である。 図３は、階層構造にしたコンテキスト情報の例を示した図である。 図４は、情報処理装置１００においてユーザーの発話を入力して音声による応答を行うための処理フローを示した図である。 図５は、発話意図理解機能２０２により実施される処理を詳細に示した図である。 図６は、解釈知識データベースの構成を模式的に示した図である。 図７は、知識獲得スコアテーブルの構成を模式的に示した図である。 図８は、各獲得方法に対して割り当てた知識獲得スコアの一例を示した図である。 図９は、コンテキスト取得処理した結果の例を示した図である。 図１０は、コンテキスト情報を抽象化する方法を説明するための図である。

　以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

　図１には、音声エージェント機能を搭載した情報処理装置１００の構成例を模式的に示している。図示の情報処理装置１００は、制御部１０１と、情報アクセス部１０２と、操作部インターフェース（ＩＦ）１０３と、通信インターフェース（ＩＦ）１０４と、音声入力インターフェース（ＩＦ）１０５と、映像入力インターフェース（ＩＦ）１０６と、音声出力インターフェース（ＩＦ）１０７と、映像出力インターフェース（ＩＦ）１０８を備えている。

　制御部１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０１Ａと、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１０１Ｂと、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１０１Ｃからなり、ＣＰＵ１０１ＡがＲＡＭ１０１Ｃにロードした各種プログラムを実行することによって、情報処理装置１００全体の動作を統括的に制御する。

　情報アクセス部１０２は、ハードディスクなどからなる情報記録装置１１１に格納されている情報を読み出して制御部１０１内のＲＡＭ１０１Ｃにロードし、又は情報記録装置１１１への情報の書き込みを行う。情報記録装置１１１に記録される情報は、ＣＰＵ１０１Ａで実行されるソフトウェアプログラム（オペレーティングシステムやアプリケーションなど）や、プログラム実行時に使用され又はプログラムを実行して生成されるデータなどであり、これらは基本的にはファイルの形式で扱われる。

　操作部インターフェース１０３は、マウスやキーボード、タッチパネルといった操作装置１１２に対してユーザーが行った操作を入力データに変換して、制御部１０１に渡す処理を行う。

　通信インターフェース１０４は、所定の通信プロトコルに従って、インターネットなどのネットワーク経由でのデータ交換を行う。

　音声入力インターフェース１０５は、マイク１１３で収音された音声信号を入力データに変換して、制御部１０１に渡す処理を行う。マイク１１３は、モノラルマイク、又は、ステレオ収音可能なステレオマイクのいずれであってもよい。

　映像入力インターフェース１０６は、カメラ１１４で撮影された動画又は静止画の映像信号を取り込んで、制御部１０１に渡す処理を行う。カメラ１１４は、画角９０度のカメラや、画角３６０度を持つ全周囲カメラ、あるいはステレオカメラや多眼カメラであってもよい。

　音声出力インターフェース１０７は、制御部１０１から出力を指示された音声データを、スピーカー１１５から再生出力するための処理を行う。スピーカー１１５は、ステレオスピーカーやマルチチャンネルスピーカーであってもよい。

　映像出力インターフェース１０８は、制御部１０１から出力を指示された画像データを、表示部１１６の画面に出力するための処理を行う。表示部１１６は、液晶ディスプレイ、有機ＥＬディスプレイ、又はプロジェクタなどからなる。

　なお、各インターフェース装置１０３～１０８は、それぞれ必要に応じて所定のインターフェース規格に則って構成される。また、情報記録装置１１１、操作装置１１２、マイク１１３、カメラ１１４、スピーカー１１５、並びに表示部１１６は、情報処理装置１００に含まれる部品であってもよいし、あるいは情報処理装置１００本体に外付けされる外部機器であってもよい。

　また、情報処理装置１００は、「スマートスピーカー」、「ＡＩスピーカー」、「ＡＩアシスタント」などとも呼ばれる音声エージェント専用のデバイスでもよいし、スマートフォンやタブレット端末のように音声エージェント用アプリケーションが常駐する情報端末や、情報家電やＩｏＴデバイスなどであってもよい。

　図２には、情報処理装置１００が音声エージェントとして動作するための、制御部１０１で実行されるソフトウェアの構成例を模式的に示している。図２に示す例では、音声エージェントとして動作するためのソフトウェアは、音声認識機能２０１と、発話意図理解機能２０２と、アプリケーション／サービス実行機能２０３と、応答生成機能２０４と、音声合成機能２０５と、コンテキスト取得機能２０６と、ユーザーフィードバック収集機能２０７を備えている。以下、各機能モジュール２０１～２０７について説明する。

　音声認識機能２０１は、マイク１１３から入力されるユーザーの問い合わせなどの音声を音声入力インターフェース１０５経由で受け付け、音声認識して、テキストに置き換える機能である。

　発話意図理解機能２０２は、ユーザーの発話を意味解析して、「意図構造」を生成する機能である。ここで言う意図構造とは、インテントとスロットから構成される。本実施形態では、発話意図理解機能２０２は、複数のインテント又は複数のスロットが考えられる場合には、コンテキスト取得機能２０６によって取得されるコンテキスト情報や、ユーザーフィードバック収集機能２０７によって収集されるユーザーフィードバック情報を踏まえて、最も適切な解釈（適切なインテント、スロットの選定）を行う機能も有する。

　アプリケーション／サービス実行機能２０３は、音楽再生や天気確認、商品の注文といった、ユーザーの発話意図に合ったアプリケーションやサービスを実行する機能である。

　応答生成機能２０４は、アプリケーション／サービス実行機能２０３がユーザーの発話意図に合ったアプリケーションやサービスを実行した結果などに基づいて、音声認識機能２０１が受け付けたユーザーの問い合わせに対する応答文を生成する機能である。

　音声合成機能２０５は、応答生成機能２０４により生成された応答文（変換後）から音声を合成する機能である。音声合成機能２０５により合成された音声は、音声出力インターフェース１０７経由でスピーカー１１５から音声出力される。

　コンテキスト取得機能２０６は、ユーザーの発話時に発話音声以外の状況に関するコンテキスト情報を取得する。かかるコンテキスト情報には、ユーザーの発話時間帯や、発話場所、周辺者（発話したときのそばにいた人）、あるいは現在の環境情報が含まれる。なお、情報処理装置１００は、コンテキスト情報を取得するためのセンサ（図１には図示しない）をさらに装備していてもよいし、少なくとも一部のコンテキスト情報を通信インターフェース１０４経由でインターネットから取得するようにしてもよい。センサには、現在時刻を計時する時計や、場所情報を取得する位置センサ（ＧＰＳセンサなど）などが含まれる。また、周辺者は、カメラ１１４でユーザーや周辺者を撮影した画像を顔認識して取得することができる。

　ユーザーフィードバック収集機能２０７は、応答生成機能２０４により生成した応答文を音声合成機能２０５により発話したときの、ユーザーの反応を収集する機能である。例えば、ユーザーが反応して新たに発話したときには、音声認識機能２０１により音声認識し、さらに発話意図理解機能２０２により解析した意図構造に基づいて、ユーザーの反応を収集することができる。

　上述した機能モジュール２０１～２０７は、基本的には、制御部１０１内で、ＲＡＭ１０１Ｃにロードされ、ＣＰＵ１０１Ａにおいて実行されるソフトウェアモジュールである。但し、少なくとも一部の機能モジュールは、情報処理装置１００本体内（例えば、ＲＯＭ１０１Ｂ内）ではなく、通信インターフェース１０４経由で、クラウド上に構築されるエージェントサービスの連携により提供で実行することも可能である。なお、「クラウド（Ｃｌｏｕｄ）」というときは、一般的に、クラウドコンピューティング（Ｃｌｏｕｄ　Ｃｏｍｐｕｔｉｎｇ）を指すものとする。クラウドは、インターネットなどのネットワークを経由してコンピューティングサービスを提供する。

　情報処理装置１００は、主に音声を通じてユーザーと対話を行う音声エージェント機能を有する。すなわち、ユーザーの発話を音声認識機能２０１により認識し、発話意図理解機能２０２によりユーザーの発話の意図を解釈し、アプリケーション／サービス実行機能２０３によりユーザーの意図に合ったアプリケーションやサービスを実行し、応答生成機能２０４によりその実行結果に基づく応答文を生成し、そして、音声合成機能２０５により応答文から音声を合成して、ユーザーに返答する。

　情報処理装置１００が品質の高い対話サービスを提供するには、ユーザーの発話意図を正しく解釈することが不可欠である。発話意図を誤って解釈すると、ユーザーの期待と異なる応答を返すことになり、ユーザーの要求が満たされないからである。ユーザーは、自分の要求が満たされないことが数回続くと、対話サービスに不信を抱き、やがては利用から遠ざかってしまう。

　ここで、発話意図は、インテントとスロットからなる。インテントは、発話におけるユーザーの意図のことである。例えば、音楽再生や天気確認、商品の注文など、実行を要求するアプリケーションやサービスがインテントである。また、スロットは、アプリケーションやサービスを実行するにあたって必要な付属情報である。例えば、（音楽再生における）歌手名や曲名、（天気確認における）地名、（商品の注文における）商品名がスロットである。あるいは、ユーザーが音声エージェントに対して発話する命令文において、述語がインテントに相当し、目的語がスロットに相当する、ということもできる。

　ユーザーの発話において、インテント又はスロットのうち少なくとも一方が複数の候補を考えられる場合がある。例えば、「マイクを再生して」という発話に対して、インテントとスロットの組み合わせの候補が複数存在する場合や、「大崎の天気を教えて」という発話に対して、複数のスロットの候補が存在する場合などである（前述）。インテント又はスロットに複数の候補があることが、ユーザーの発話意図を誤って解釈する主な原因である。

　そこで、本実施形態に係る情報処理装置１００は、コンテキスト取得機能２０６により取得したコンテキスト情報と、ユーザーフィードバック収集機能２０７が収集したユーザーフィードバック情報に基づいて、発話意図理解機能２０２がユーザーの発話に対してより適切な意図の解釈を行うようにしている。

　本明細書において、コンテキスト情報は、ユーザーの発話時に発話音声以外の状況に関する情報を指す。本実施形態では、コンテキスト情報を階層構造にして扱うようにしている。例えば、発話日時を、季節、月、曜日、時間帯などの構造で取得し、記憶する。図３には、階層構造にしたコンテキスト情報の例を示している。図３に示す例では、コンテキスト情報は、発話時間（いつ）、発話場所（どこで）、周辺者（だれが）、発話機器（何を使って）、ムード（どのようなときに）、発話ドメイン（何について）、といった項目からなり、項目毎に階層化されている。階層の上位ほど抽象化され、下位に進むに従って具体化される。図３中で、「発話ドメイン」に関するコンテキスト情報は、インテントの解釈知識には付けないが、スロットの解釈知識にのみ付けるものとする。情報処理装置１００は、これらコンテキスト情報の各項目を、環境センサ（前述）やカメラ１１４を使って検出し、又は、通信インターフェース１０４経由で外部ネットワークから取得できるものとする。

　図４には、情報処理装置１００において、ユーザーの発話を入力して音声による応答を行うための処理フローを示している。

　ユーザーは、マイク１１３を介して情報処理装置１００に音声データを入力する（Ｓ４０１）。また、ユーザーは、キーボードなどの操作装置１１２から、情報処理装置１００にテキストデータを入力する（Ｓ４０２）。

　音声データが入力された場合、音声認識機能２０１によって音声認識され、テキストデータに置き換えられる（Ｓ４０３）。

　次いで、発話意図理解機能２０２は、テキスト形式の入力データに基づいて、ユーザーの発話を意味解析して、１つのインテントと１つのスロットから構成される意図構造を生成する（Ｓ４０４）。

　本実施形態では、発話意図理解機能２０２は、インテント又はスロットのうち少なくとも一方に複数の候補があり、発話意図があいまいな場合には、コンテキスト情報並びにユーザーフィードバック情報に基づいて、最も適切なユーザーの意図を解釈するが、その詳細については後述に譲る。

　次いで、アプリケーション／サービス実行機能２０３は、発話意図理解機能２０２によるユーザーの発話の意図理解結果に基づいて、音楽再生や天気確認、商品の注文といった、ユーザーの意図に合ったアプリケーションやサービスを実行する（Ｓ４０５）。

　次いで、応答生成機能２０４は、アプリケーション／サービス実行機能２０３の実行結果などに基づいて、音声認識機能２０１が受け付けたユーザーの問い合わせに対する応答文を生成する（Ｓ４０６）。

　応答生成機能２０４によって生成される応答文はテキストデータの形式である。音声合成機能２０５によりテキスト形式の応答文は音声データに合成され、その後、スピーカー１１５から音声出力される（Ｓ４０７）。また、応答生成機能２０４によって生成される応答文は、テキストデータのまま、あるいはテキストデータを含む合成画像として、表示部１１６に画面出力されてもよい。

　図５には、図４に示した処理フローのうち、発話意図理解機能２０２により実施される内部処理を詳細に示している。

　発話意図理解機能２０２は、解釈知識を獲得したとき、ユーザーフィードバックがあったとき、及び、ユーザーの発話を解釈するとき、の３系統の処理を実施する。以下では、各系統の処理について説明する。

解釈知識獲得時：
　発話意図理解機能２０２は、解釈知識を獲得したとき、その解釈内容と、獲得したときにコンテキスト情報を対応付けし、さらにその解釈の優劣を示す解釈スコアを付けて、解釈知識データベースに記憶する処理（すなわち、解釈知識獲得処理）を実施する（Ｓ５０１）。

　図６には、複数の解釈知識を記憶する解釈知識データベースの構成を模式的に示している。１つの解釈知識は、インテントやスロットに関する解釈内容と、その解釈内容が適用されるべきコンテキスト情報と、その解釈内容をコンテキスト情報において適用される優先度を表した（若しくは数値化した）解釈スコアからなる。但し、コンテキスト情報には抽象化処理（後述）が施される。解釈内容は、略語や略称を元の長い名称にリンクさせる「リンク知識」を含む。コンテキスト情報は、ユーザーの発話時に発話音声以外の状況に関する情報であり、例えば発話時間や発話したときにそばにいた人（周辺者）などであり、さらに発話場所や発話したときのさまざまな環境情報を含めてもよい。

　また、解釈知識に対して解釈スコアを付けるために、知識獲得スコアテーブルが用意される。図７には、知識獲得スコアテーブルの構成を模式的に示している。図示の知識獲得スコアテーブルは、解釈知識を獲得する方法毎に割り当てられた知識獲得スコアの早見表である。ある解釈内容とコンテキスト情報からなる解釈知識を獲得したとき、そのときの獲得方法に応じた知識獲得スコアを知識獲得スコアテーブルから取得して、解釈知識データベース中の該当するエントリの解釈スコアに逐次加算する。例えば、ある特定のコンテキスト情報（発話日時、発話場所など）でインテント「音楽再生」という解釈知識を、獲得方法１により獲得したときには、その解釈知識の解釈スコアを３０点だけ加算する。

ユーザーフィードバックがあったとき：
　情報処理装置１００が実施した応答に対して、ユーザーからのフィードバックがあったとき、ユーザーフィードバック収集機能２０７により収集される（Ｓ５０２）。そして、発話意図理解機能２０２は、ユーザーフィードバック反映処理を実施して（Ｓ５０３）、解釈知識データベースの記憶内容を適宜修正する。

　音声エージェントからの応答に対してユーザーがフィードバックする際の表現方法はさまざまであるが、肯定的又は否定的のいずれかに大別することができる。

　ユーザーから肯定フィードバックがあったとき、ユーザーの発話の意図解釈が正しかったと推定することができる。したがって、このときのユーザーフィードバック反映処理として、解釈知識データベース中の該当する解釈知識の解釈スコアを、所定値だけ増やす。また、その解釈知識を獲得した獲得方法も正しかったと推定することができるので、知識獲得スコアテーブルの該当する知識獲得スコアも、所定値だけ増やす。

　一方、ユーザーから否定フィードバックがあったとき、ユーザーの発話の意図解釈が正しくなかったと推定することができる。したがって、このときのユーザーフィードバック反映処理として、解釈知識データベース中の該当する解釈知識の解釈スコアを、所定値だけ減らす。また、その解釈知識を獲得した獲得方法も正しくなかったと推定することができるので、知識獲得スコアテーブルの該当する知識獲得スコアも、所定値だけ減らす。

ユーザーの発話解釈時：
　マイク１１３からユーザーの発話が入力されたとき、音声認識機能２０１により音声認識されたテキストデータ（発話テキスト）が発話意図理解機能２０２に渡される。発話意図理解機能２０２は、発話テキストが入力されて、ユーザーの発話を解釈するとき、まず、インテントとスロットから構成される意図構造を生成する（Ｓ５０４）。そして、インテント又はスロットのうち少なくとも一方に複数の候補があるかどうかをチェックする（Ｓ５０５）。

　発話の意図を解釈して、単一のインテント及びスロットのみが生成されたときには（Ｓ５０５のＮｏ）、発話意図理解機能２０２は、それを意図理解結果として出力する。その後、アプリケーション／サービス実行機能２０３は、その意図理解結果に合ったアプリケーションやサービスを実行する（Ｓ５０８）。

　一方、インテント又はスロットのうち少なくとも一方に複数の候補がある場合には（Ｓ５０５のＹｅｓ）、コンテキスト取得機能２０６により取得された現在のコンテキストと、解釈知識データベース中の各解釈知識のコンテキスト情報とを比較するコンテキストマッチング処理を実施する（Ｓ５０６）。

　そして、マッチした（若しくは、コンテキスト同士の類似度が所定の閾値を超えた）解釈知識を利用して、単一のインテント及びスロットを意図理解結果として出力する（Ｓ５０７のＹｅｓ）。また、ユーザーの発話時のコンテキスト情報にマッチする解釈知識が複数ある場合には、解釈スコアが最も高いものを選択して、意図理解結果を出力する。その後、アプリケーション／サービス実行機能２０３は、その意図理解結果に合ったアプリケーションやサービスを実行する（Ｓ５０８）。

　コンテキスト情報は階層構造を有している。そこで、Ｓ５０６のコンテキストマッチング処理では、この階層構造を踏まえて、適切な階層レベル同士でコンテキスト情報のマッチングを行う。適切な階層レベル同士でコンテキスト情報のマッチングを行うために、本実施形態では、コンテキスト情報の抽象化を行う。具体的には、コンテキスト取得機能２０６により取得されたコンテキスト情報は、ログデータベースに一旦蓄積され、抽象化処理して（Ｓ５０９）、抽象化した結果を用いてコンテキストマッチング処理を実施する。但し、コンテキスト情報の抽象化処理の詳細については後述に譲る。

　なお、情報処理装置１００の初期状態若しくはサービス開始時点では、基本的には、解釈知識データベースは記憶された解釈知識が空の状態である。このような状態で、ユーザーの発話解釈時に、インテント又はスロットのうち少なくとも一方に複数の候補が存在すると、単一の意図理解に収束できないというコールドスタート問題が発生する。そこで、他の家庭に設置した情報処理装置１００で構築された汎用的な解釈知識データベースを、初期の解釈知識データベースとして利用するようにしてもよい。また、初期の解釈知識データベースにおける各解釈知識の解釈知識スコアを１０分の１の値に圧縮しておけば、使用を開始すればユーザーフィードバック反映処理により解釈スコアが相対的に変化し易くなり、その過程特有の傾向がより強く表出されるようになる。

　続いて、図５に示した発話意図理解機能のうち、「解釈知識獲得時」、「ユーザーフィードバックの収集時」、並びに「解釈時」の各々における挙動について、さらに詳細に説明する。

解釈知識獲得時の挙動：
　発話意図理解機能２０２は、解釈知識を獲得したとき、その解釈内容と、その解釈内容が適用されるべきコンテキスト情報と、その解釈内容をコンテキスト情報において適用される優先度を表した解釈スコアを付けて、図６に示したような解釈知識データベースに記憶する処理を実施する。解釈知識データベースは、インテントやスロットなどの解釈内容と、その解釈をしたときのユーザーの発話日時や発話場所といったコンテキスト情報と、その解釈内容を適用するべき解釈スコアを記憶する。

　解釈知識として獲得した解釈内容は、発話意図のインテントの場合と、発話意図のスロットの場合がある。

　解釈知識として獲得した解釈内容がインテントの場合、どのインテントで解釈するかを、解釈知識として獲得する。例えば、「ｘｘｘを再生して」という発話に対して、「ＭＵＳＩＣ＿ＰＬＡＹ（音楽再生）」、「ＭＯＶＩＥ＿ＰＬＡＹ（映画再生）」、「ＴＶ＿ＰＬＡＹ（テレビ番組再生）」という３通りのインテントを解釈知識として獲得する。

　また、解釈知識として獲得した解釈内容がスロットの場合、どのスロットで解釈するかを、解釈知識として獲得する。例えば、インテントが「音楽再生」と解釈されたときに、「アイ」というスロットについて、「佐藤アイ」、「山田アイ」、「田中アイ」という３通りの解釈知識を獲得し、以下のように解釈スコアを付与する。

佐藤アイ：１２７点、山田アイ：４３点、田中アイ：１９点

　また、上記のようにインテント又はスロットの解釈知識を獲得したときに、どういう状況の場合にその解釈知識が適用されるか、すなわちコンテキスト情報を対応付ける。その解釈内容を獲得したときのユーザーの発話日時や発話場所といったコンテキスト情報を、コンテキスト取得機能により取得することができる。図３を参照しながら説明したように、コンテキスト情報は階層構造になっている。この階層構造を踏まえて、適切な階層レベル同士でコンテキスト情報のマッチングを行うために、コンテキスト情報の抽象化を行う。そして、抽象化した結果を用いてコンテキストマッチング処理を実施する。但し、コンテキスト情報の抽象化処理の詳細については後述に譲る。

　解釈スコアは、その解釈内容を適用する優先度を表す値である。例えば、あるコンテキストにおいて「アイ」というスロットの解釈として「佐藤アイ」、「山田アイ」、「田中アイ」という３通りがあり、各々の解釈スコアが１２７点、４３点、１９点であるとするとも、最もスコアが高い「佐藤アイ」が優先的に適用される。この場合、「アイ」→「佐藤アイ」とリンクさせる解釈内容を解釈知識（リンク知識）として獲得することになる。

　発話意図理解機能２０２は、解釈知識を獲得する度に、解釈知識データベースを更新する。

　解釈知識を獲得する方法はさまざまである。解釈知識を獲得する獲得方法に応じて、解釈知識データベースを更新する際にその解釈知識の解釈スコアを加算する。例えば、確からしさの高い獲得方法（その方法で獲得した解釈知識は確からしい）の場合には、大きな値を解釈スコアに加算するが、確からしさの低い獲得方法（その方法で獲得した解釈知識の確からしさは低い）の場合には、小さい値を解釈スコアに加算する。以下では６種類の獲得方法１～６について説明する。

（１）獲得方法１：一般常識による判定型
　世の中の一般常識に基づいて、複数のインテント又はスロットの候補の中から最も適切なものを判定する方法である。例えば、世の中の一般共通認識として「アイ」と言えば誰のことなのかを、インターネット上のさまざまな情報に基づいて人気度をランキングして、そのランキング結果に基づいて最も適切なインテント又はスロットを複数候補の中から判定する。

　また、インテント又はスロットの各候補の人気度を定期的に集計して、その結果に基づいて解釈知識データベースを更新する。

　この獲得方法１により得られる解釈知識は、万人共通になり、マイナーな嗜好のユーザーにとっては誤った解釈になってしまう可能性がある。例えば、世の中のほとんどの人が「アイ」と言えば「佐藤アイ」を意味するのに対し、あるユーザーが一人だけ「田中アイ」を推すような場合には、この獲得方法１では、このような特殊なユーザー向けの解釈知識を得ることはできない。

（２）獲得方法２：全候補提示及び選択型
　複数のインテント又はスロットの候補を提示して、ユーザーに選択してもらう方法である。例えば、「アイ」というスロットの解釈として「佐藤アイ」、「山田アイ」、「田中アイ」という３通りを提示して、ユーザーに選択してもらう。例えば、世の中では音楽再生というインテントに対して「アイ」と言えば「佐藤アイ」という解釈が圧倒的であったとしても、ユーザーが「田中アイ」を選択したら、「アイ」→「田中アイ」とリンクさせる解釈内容を解釈知識として獲得して、解釈知識データベースに記憶する。そして、次回以降にユーザーが「アイの曲をかけて」と発話したら、その発話から生成されたスロット「アイ」からリンク知識に基づいて「田中アイ」を選択し、田中アイの曲をかける。

　この獲得方法２によれば、マイナーな思考のユーザーにも確実に対応して解釈知識データベースを構築することができるが、ユーザーの手間がかかるという問題がある。

（３）獲得方法３：ユーザー教示型
　ユーザーが教示した内容に基づいて解釈知識を獲得する方法である。例えば、ユーザーが「アイと言ったら田中アイだよ」と教示してくれたら、「アイ」→「田中アイ」とリンクさせる解釈知識（リンク知識）を解釈知識データベースに記憶する。そして、次回以降にユーザーが「アイの曲をかけて」と発話したら、スロットとして「田中アイ」を選択し、田中アイの曲をかける。

　この獲得方法３によれば、ユーザーが直接教示してくれるので確度はあるが、解釈知識データベースを構築するのにユーザーの手間がかかるという問題がある。

（４）獲得方法４：初回限定発話型
　ユーザーが（初回に）「田中アイの曲をかけて」と発話したら、「アイ」→「田中アイ」というリンク知識を解釈知識データベースに記憶する。そして、次回以降にユーザーが「アイの曲をかけて」と発話したら、スロットとして「田中アイ」を選択し、田中アイの曲をかける。

　人間同士の会話でも、インテント又はスロットに複数の候補があり、勘違いされるおそれがあると思ったら、初回は略称「アイ」のようにあいまいな言い方を避けて「田中アイの曲をかけて」と発話し、２回目以降は略称を使って「アイの曲をかけて」と発話することがある。獲得方法４は、このような人間の会話の習性に依拠するものである。

　ユーザーにとっては、日常の会話と同じ感覚で発話すればよいので、受け入れ易い。但し、すべてのユーザーが、初回はあいまい性を避けて限定的な言い方で発話するとは限らない。初回はあいまいな言い方を避ける習性のないユーザーにとっては、気を遣う獲得方法であり、あるいは気を遣わないユーザーだとなかなか解釈知識が蓄積されないという問題がある。

（５）獲得方法５：属性情報利用判定型
　ユーザーの属性情報を利用して、複数のインテント又はスロットの候補の中から最も適切なものを判定する方法である。例えば、「大崎の天気を教えて」という発話に対しては、日本国内には大崎という名称がつく地名がいくつか存在することに起因して、以下の３通りの解釈が考えられる。

　鹿児島の大崎町
　宮城県の大崎市
　東京都品川区の大崎

　このような場合、属性情報としてユーザーの現在地の緯度経度に最も近い「大崎」と判定して、その天気を提示する。

（６）獲得方法６：履歴による判定型
　ユーザーの履歴情報を利用して、複数のインテント又はスロットの候補の中から最も適切なものを判定する方法である。例えば、ユーザーが「アイの曲をかけて」と発話したとき、インテント「音楽再生」に対する「アイ」というスロットには、「佐藤アイ」、「山田アイ」、「田中アイ」という複数の候補が存在し、あいまい性があるが、そのユーザーには田中アイの曲を頻繁に再生しているという履歴情報があれば、田中アイの曲をかける。

　例えば、情報処理装置１００がスマートフォンやタブレット端末などの情報端末の場合には、ユーザーが使用するアプリケーションのデータ（スケジュール帳やプレイリストなど）に基づいて、ユーザーの履歴情報を取得して、上記の判定に利用することができる。

　この獲得方法６によれば、履歴情報の取得にユーザーの手間がかからないが、高精度で判定することは難しいと思料される。

　既に述べたように、解釈知識を獲得して、解釈知識データベースを更新する際に、獲得方法に応じた知識獲得スコアがその解釈知識の解釈スコアに加算される。例えば、確からしさの高い獲得方法（その方法で獲得した解釈知識は確からしい）には高い知識獲得スコアを割り当て、確からしさの低い獲得方法（その方法で獲得した解釈知識の確からしさは低い）には低い知識獲得スコアを割り当てる。上述した獲得方法１～６に対して割り当てた知識獲得スコアの一例を、図８に示しておく。

　例えば、ユーザーが「アイの曲をかけて」と発話した際に、情報処理装置１００がユーザーに「佐藤アイ」、「山田アイ」、及び「田中アイ」の３つの候補を提示し、ユーザーが「田中アイ」を選択したら、獲得方法２（全候補提示及び選択型）で獲得した解釈知識なので、知識獲得スコア４点が「アイ」→「田中アイ」のリンク知識の解釈スコアに加算される。

ユーザーフィードバックの収集時の挙動：
　情報処理装置１００が実施した応答に対してユーザーからのフィードバックがあったとき、ユーザーフィードバック収集機能２０７によりユーザーフィードバックを収集し、発話意図理解機能２０２は、解釈知識データベースの記憶内容を適宜修正する。

　音声エージェントからの応答に対してユーザーがフィードバックする際の表現方法はさまざまであるが、ユーザーフィードバックが肯定的又は否定的のいずれかに大別することができる。

　音声エージェントが応答を返した直後に、ユーザーから「それだよ」、「ありがとう」といった肯定的な発話を得た場合や、ユーザーが音声エージェントの応答結果を読んだり、ユーザーがアプリケーションを使い始めたりした場合は、ユーザーから肯定フィードバックがあったときである。

　ユーザーから肯定フィードバックがあったとき、ユーザーの発話の意図解釈が正しかったと推定することができる。したがって、このときのユーザーフィードバック反映処理として、解釈知識データベース中の該当する解釈知識の解釈スコアを所定値だけ増やす。

　一方、音声エージェントが応答を返した直後に、ユーザーから「違うよ」、「そうじゃないよ、ｘｘｘだよ」といった否定的な発話を得た場合や、ユーザーが音声エージェントの応答結果を読まなかったり、ユーザーがアプリケーションを使わなかったりした場合は、ユーザーから否定フィードバックがあったときである。

　ユーザーから否定フィードバックがあったとき、ユーザーの発話の意図解釈が正しくなかったと推定することができる。したがって、このときのユーザーフィードバック反映処理として、解釈知識データベース中の該当する解釈知識の解釈スコアを、所定値だけ減らす。

　また、ユーザーからフィードバックがあったときには、肯定的又は否定的のいずれかであったかに応じて、知識獲得スコアテーブルの知識獲得スコアも更新するようにする。

　例えば、ユーザー教示型の獲得方法３によって獲得されたリンク知識は強いものと考えることができる。ユーザーが「アイと言ったら田中アイだよ」と教示してくれたら、「アイ」→「田中アイ」というリンク知識を解釈知識データベースに記憶するとともに、解釈スコアを６点も加算する。しかしながら、「アイ」→「田中アイ」というリンク知識が未来永劫、強いものとは限らず、全候補提示及び選択型の獲得方法２の方を強くしてほしい（前回選んだのだから、今回もそちらを選んでほしい）、というユーザーもあり得る。

　そこで、ユーザーから肯定フィードバックがあったときには、その解釈知識を獲得した獲得方法も正しかったと推定することができるので、知識獲得スコアテーブルの該当する知識獲得スコアも、所定値だけ増やす。逆に、ユーザーから否定フィードバックがあったときには、その解釈知識を獲得した獲得方法も正しくなかったと推定することができるので、知識獲得スコアテーブルの該当する知識獲得スコアも、所定値だけ減らす。

　以上により、ユーザーからのフィードバックを踏まえて、そのユーザーにとって有用な解釈知識が強くなり、また有用な獲得方法がより強くなっていく。

解釈時の挙動：
　マイク１１３からユーザーの発話が入力されたとき、音声認識機能２０１により音声認識されたテキストデータ（発話テキスト）が発話意図理解機能２０２に渡される。発話意図理解機能２０２は、発話テキストが入力されて、ユーザーの発話を解釈するとき、まず、インテントとスロットから構成される意図構造を生成する。そして、インテント又はスロットのうち少なくとも一方に複数の候補があるときには、コンテキスト取得機能２０６により取得された現在のコンテキストと、解釈知識データベース中の各解釈知識のコンテキスト情報とを比較するコンテキストマッチング処理を実施して、最も有効な解釈知識を適用して、その意図理解結果に合ったアプリケーションやサービスを実行する。

　ここで、コンテキストマッチングを行う際に、コンテキストを抽象化処理する。

　例えば、周辺者（発話したときのそばにいた人）について、以下のような階層構造で定義する。

　そして、ある解釈知識が、以下に示すようにそれぞれ階層構造の末端ノードに対して適用されているという状況であるとする。

　このような状況であれば、以下に示すように、コンテキスト情報のある階層の全要素が閾値を超えている解釈知識は１つ上の階層で適用されるようになる。これをコンテキスト情報の「抽象化」と呼ぶ。

　抽象化について、さらに詳細に説明する。コンテキスト情報を以下のように定義したとする。

　コンテキスト収集機能２０６によりコンテキスト情報を取得処理した結果、例えば、図９に示すような知識をログデータベースに獲得していったとする。そして、獲得スコアの合計が所定の閾値に達した解釈内容を解釈知識として獲得して、解釈知識データベースに記憶する。ここで、獲得スコアの閾値を３０点とすると、図９に示す例では、「アイ」→「田中アイ」というリンク解釈に関して、獲得スコアを合算すると、１２／１７　火曜日１９：２８に３１点となって閾値に達した。このとき、「アイ」→「田中アイ」というリンク解釈を獲得したときに収集した複数のコンテキスト情報に関して、以下に示すようないくつかの抽象化の可能性がある。

　このように複数の抽象化の可能性がある中で、例えば、その階層で、「アイ」→「田中アイ」というリンク解釈が発生した全ケースにおける件数比率が所定の閾値（例えば８０％）以上となった場合に、その階層を採用することで、コンテキスト情報を抽象化する。

　例えば、発話時間「いつ」について、時間帯は、１日を３時間ずつ区切って８つの時間帯を定義すると、「アイ」→「田中アイ」の発生ケースは、１８：００～２１：００で５回、２１：００～２４：００で１回、その他６つの時間帯では０回発生している。１８：００～２１：００で５／６＝８３．３％（＞８０％）の件数比率を占めているので、１８：００～２１：００の時間帯を採用することで、時間帯の階層で抽象化される。

　また、曜日は７種類定義されるが、「アイ」→「田中アイ」の発生ケースは、月曜日で１回、火曜日で３回、水曜日で１回、金曜日で１回、木曜日、土曜日、日曜日は０回発生している。最も発生件数が多い火曜日でも件数比率は３／６＝５０％（＜８０％）なので、曜日の階層では抽象化されない。

　また、周辺者（発話したときのそばにいた人）「だれが」について、家族は発話者の父、母、弟の３人のメンバーがそばにいたとする。家族の個々のメンバーの階層での「アイ」→「田中アイ」の発生ケースは、父で４回、母で２回発生している。父の階層では４／６＝６６．７％（＜８０５）なので、個の階層では抽象化されない。親か子の階層での「アイ」→「田中アイ」の発生ケースは、親で６／６＝１００％（＞８０％）なので、親の階層での抽象化が採用される。

　さらに、発話時間「いつ」と周辺者（発話したときのそばにいた人）「だれが」のすべての組み合わせで、コンテキスト情報を抽象化できるかどうかを検討する必要がある。発話時間「いつ」と周辺者（発話したときのそばにいた人）「だれが」の各組み合わせにおける「アイ」→「田中アイ」の発生件数と件数比率を図１０にまとめた。いつ＝時間帯（１８：００～２１：００）＆周辺者＝父の組み合わせの発生ケースの件数比率は３／６＝５０％（＜８０％）なので、この組み合わせでの抽象化は採用されない。また、いつ＝時間帯（１８：００～２１：００）＆周辺者＝親の組み合わせの発生ケースの件数比率は５／６＝８３．３％（＞８０％）なので、この組み合わせでの抽象化は採用される。また、いつ＝曜日（月曜日）＆周辺者＝父の組み合わせの発生ケースの件数比率は１／６＝１２．５％（＜８０％）なので、この組み合わせでの抽象化は採用されない。

　したがって、「アイ」→「田中アイ」というリンク知識に関して、抽象化して採用されるコンテキスト情報は、以下の通りである。

　上記は、ある１つの家庭において解釈知識を獲得した例である。さらに複数の家庭で獲得した解釈知識を収集してマージすると、以下のように、コンテキスト情報を広く抽象化することができる。

　このようにマージしてコンテキスト情報を広く抽象化した解釈知識を使用することで、情報処理装置１００を購入して音声エージェント機能を初めて使う家庭でも、汎用的な解釈知識を利用してある程度の精度で発話が解釈され、適切な応答が音声エージェントから返ってくる。したがって、コールドスタート問題が解決され、ユーザーの利便性が確保される。また、初期の解釈知識データベースにおける各解釈知識の解釈知識スコアを１０分の１の値に圧縮しておけば、使用を開始すればユーザーフィードバック反映処理により解釈スコアが相対的に変化し易いので、音声エージェントは個別のユーザーにすぐフィットすることができる。

　また、コンテキスト情報のうち、周辺者の階層構造に、以下のように性別などの属性を付けることで、末端ノードを、男性、女性といった抽象レベルに引き上げることもできる。

　最後に、本実施形態に係る発話意図理解機能によってユーザーの発話の意図を解釈する事例について説明する。

事例１：発話内容は同じでコンテキストのムードだけが異なる場合
　日曜日の夜、自宅で、家族全員がいて、家のホームエージェントから、「アイを再生して」と発話された場合、インテントの解釈内容として、ＭＵＳＩＣ＿ＰＬＡＹとＭＯＶＩＥ＿ＰＬＡＹがあり得る。

　ムードが忙しそうなときは、ＢＧＭとして聴きたいから、コンテキスト情報に基づいて、ＭＵＳＩＣ＿ＰＬＡＹが選択される。また、ムードがまったりしたときには、映画でも観ようかなという気分になるので、コンテキスト情報に基づいて、ＭＯＶＩＥ＿ＰＬＡＹが選択される。

事例２：発話内容は同じでコンテキストの周辺者だけが異なる場合
　日曜日の夜、自宅で、家族全員がいて、家のホームエージェントから、「再生して」と発話された場合、インテントの解釈内容として、ＭＵＳＩＣ＿ＰＬＡＹとＭＯＶＩＥ＿ＰＬＡＹがあり得る。

　ママがいるときは、子供にはアニメを見せないので、ＭＵＳＩＣ＿ＰＬＡＹが選択される。また、ママがいないときは、パパは甘く、アニメを見せてもいいので、ＭＯＶＩＥ＿ＰＬＡＹが選択される。

事例３：ユーザーが移動している場合
　新宿という地名は、「東京都新宿区」と「千葉市中央区新宿」の２箇所があるものとする。そして、ユーザーが千葉市の新宿在住で、且つ、職場が東京都の新宿であるとする。

　朝、自宅（千葉市の新宿）で、ユーザーが「新宿の天気は？」と発話した場合、職場に着いたときに雨が降っていないかが気になるので、東京都の新宿の天気が選択される。

　また、昼、職場（東京都の新宿）にて、ユーザーが「新宿の天気は？」と発話した場合、これから帰宅して、自宅の最寄り駅（千葉市の新宿）に着いたときに雨が降っていないかが気になるので、千葉市の新宿の天気が選択される。

　ユーザーの平日の行動パターンはほぼ決まっている。平日の朝なら東京の新宿と解釈し、平日の昼なら千葉市の新宿と解釈して、それぞれユーザーに応答することが適切である。

　以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

　本明細書で開示する技術は、音声エージェント専用のデバイスだけでなく、スマートフォンやタブレット端末などの情報端末、情報家電やＩｏＴデバイスなどのエージェントアプリケーションが常駐するさまざまな機器を設置する際にも適用することができる。また、本明細書で開示する技術の少なくとも一部の機能を、クラウド上に構築されるエージェントサービスの連携により提供で実行することも可能である。

　要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

　なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成部と、
　前記生成部によりインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定部と、
を具備する情報処理装置。
（１－１）ユーザーの発話時のコンテキスト情報を取得する収集部をさらに備える、
上記（１）に記載の情報処理装置。
（１－２）ユーザーの発話意図に基づいて応答する応答部をさらに備える、
上記（１）に記載の情報処理装置。
（１－３）前記応答部は音声によりユーザーに応答する、
上記（１）に記載の情報処理装置。
（１－４）前記応答部による応答に対するユーザーからのフィードバック情報を収集する収集部をさらに備える、
上記（１－２）に記載の情報処理装置。
（２）インテントは、ユーザーが発話により実行を要求するアプリケーション又はサービスであり、
　スロットは、アプリケーション又はサービスを実行する際の付属情報である、
上記（１）に記載の情報処理装置。
（３）コンテキスト情報は、ユーザーの発話時に発話音声以外の状況に関する情報である、
上記（１）又は（２）のいずれかに記載の情報処理装置。
（３－１）コンテキスト情報は、発話時間、発話場所、周辺者、発話機器、ムード、又は発話ドメインのうち少なくとも１つを含む、
上記（３）に記載の情報処理装置。
（４）前記判定部は、さらに発話意図に基づく応答に対するユーザーからのフィードバック情報に基づいて、前記複数の候補のうち最も適切な解釈を判定する、
上記（１）乃至（３）のいずれかに記載の情報処理装置。
（５）インテント又はスロットに関する解釈内容とその解釈内容が適用されるべきコンテキスト情報を解釈知識として記憶する記憶部をさらに備え、
　前記判定部は、ユーザーの発話時のコンテキスト情報にマッチする解釈知識に基づいて、ユーザーの発話意図に対する解釈を判定する、
上記（１）乃至（４）のいずれかに記載の情報処理装置。
（６）前記記憶部は、解釈内容をコンテキスト情報において適用される優先度を表す解釈スコアをさらに記憶し、
　前記判定部は、ユーザーの発話時のコンテキスト情報にマッチする解釈知識のうち解釈スコアが高いものを選択する、
上記（５）に記載の情報処理装置。
（７）解釈知識を獲得した方法に基づいて解釈スコアを決定する、
上記（６）に記載の情報処理装置。
（８）前記判定部により判定した解釈知識に基づく応答に対するユーザーからのフィードバック情報に基づいて、該当する解釈知識の解釈スコアを更新する、
上記（６）又は（７）のいずれかに記載の情報処理装置。
（９）ユーザーから肯定フィードバックがあった場合に、該当する解釈知識の解釈スコアを増やす、
上記（８）に記載の情報処理装置。
（１０）ユーザーから否定フィードバックがあった場合に、該当する解釈知識の解釈スコアを減らす、
上記（８）又は（９）のいずれかに記載の情報処理装置。
（１１）コンテキスト情報は階層構造を有し、
　前記判定部は、前記階層構造を踏まえて、適切な階層レベル同士でコンテキスト情報を比較して、前記判定を行う、
上記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２）ある解釈内容が発生した全ケースにおける件数比率が所定の閾値以上となった階層を採用して、その解釈内容に適用されるべきコンテキスト情報を抽象化する、
上記（１１）に記載の情報処理装置。
（１３）ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成ステップと、
　前記生成ステップにおいてインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定ステップと、
を有する情報処理方法。

　１００…情報処理装置、１０１…制御部、１０１Ａ…ＣＰＵ
　１０１Ｂ…ＲＯＭ、１０１Ｃ…ＲＡＭ、１０２…情報アクセス部
　１０３…操作部インターフェース、１０４…通信インターフェース
　１０５…音声入力インターフェース
　１０６…映像入力インターフェース
　１０７…音声出力インターフェース
　１０８…映像出力インターフェース
　１１１…情報記録装置、１１２…操作装置、１１３…マイク
　１１４…カメラ、１１５…スピーカー、１１６…表示部

Claims (13)

1. 　ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成部と、
   　前記生成部によりインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定部と、
   を具備する情報処理装置。
2. 　インテントは、ユーザーが発話により実行を要求するアプリケーション又はサービスであり、
   　スロットは、アプリケーション又はサービスを実行する際の付属情報である、
   請求項１に記載の情報処理装置。
3. 　コンテキスト情報は、ユーザーの発話時に発話音声以外の状況に関する情報である、
   請求項１に記載の情報処理装置。
4. 　前記判定部は、さらに発話意図に基づく応答に対するユーザーからのフィードバック情報に基づいて、前記複数の候補のうち最も適切な解釈を判定する、
   請求項１に記載の情報処理装置。
5. 　インテント又はスロットに関する解釈内容とその解釈内容が適用されるべきコンテキスト情報を解釈知識として記憶する記憶部をさらに備え、
   　前記判定部は、ユーザーの発話時のコンテキスト情報にマッチする解釈知識に基づいて、ユーザーの発話意図に対する解釈を判定する、
   請求項１に記載の情報処理装置。
6. 　前記記憶部は、解釈内容をコンテキスト情報において適用される優先度を表す解釈スコアをさらに記憶し、
   　前記判定部は、ユーザーの発話時のコンテキスト情報にマッチする解釈知識のうち解釈スコアが高いものを選択する、
   請求項５に記載の情報処理装置。
7. 　解釈知識を獲得した方法に基づいて解釈スコアを決定する、
   請求項６に記載の情報処理装置。
8. 　前記判定部により判定した解釈知識に基づく応答に対するユーザーからのフィードバック情報に基づいて、該当する解釈知識の解釈スコアを更新する、
   請求項６に記載の情報処理装置。
9. 　ユーザーから肯定フィードバックがあった場合に、該当する解釈知識の解釈スコアを増やす、
   請求項８に記載の情報処理装置。
10. 　ユーザーから否定フィードバックがあった場合に、該当する解釈知識の解釈スコアを減らす、
    請求項８に記載の情報処理装置。
11. 　コンテキスト情報は階層構造を有し、
    　前記判定部は、前記階層構造を踏まえて、適切な階層レベル同士でコンテキスト情報を比較して、前記判定を行う、
    請求項１に記載の情報処理装置。
12. 　ある解釈内容が発生した全ケースにおける件数比率が所定の閾値以上となった階層を採用して、コンテキスト情報を抽象化する、
    請求項１１に記載の情報処理装置。
13. 　ユーザーの発話からインテント及びスロットからなる発話意図を生成する生成ステップと、
    　前記生成ステップにおいてインテント又はスロットの少なくとも一方において複数の候補が得られた場合に、ユーザーの発話時のコンテキスト情報に基づいて前記複数の候補のうち最も適切な解釈を判定する判定ステップと、
    を有する情報処理方法。

Images