JP7169096B2 - 対話システム、対話方法、およびプログラム - Google Patents

Description

本発明は、対話システム、対話方法、およびプログラムに関する。

従来から、ユーザの入力ごとにシステムの応答を出力する入力応答型の対話システムが知られている。典型的には、質問応答システムや最近のＡＩスピーカーなどがこれに当たる。

また、あるタスクの目的を達成するために、あらかじめ決められたシナリオに従って、対話を行うシナリオベースの対話システムが知られている。飛行機のチケット予約や店頭に置かれたロボットなどが来客者から要件を聞き出すための対話システムなどがこれに当たる。

特許文献１は、音声対話において、ユーザの発話が短い単語であった場合でも、意味を汲み取って応答を返す音声対話システムを開示している。特許文献１に記載された音声対話システムは、第１のシステム発話の内容と、ユーザ発話の内容と、第２のシステム発話の内容との３つが１組となった対話シナリオを用意することにより、ユーザ発話の長短に関わらず、１つ前のシステム発話の内容を考慮した自然な応答を返す発明である。

特開２０１８－５４７９０号公報

入力応答対話システムは、ユーザとの対話を継続する際に、文脈的に破綻が起こりやすいという課題があった。また、シナリオベース対話システムは、シナリオで想定されている範囲でしか応答ができない。かつ、対話を長く継続するためには、指数関数的に増大する場合に応じたシナリオを作成しなければならず、実際にはあまり長く対話を生成することができなかった。特許文献１では、対話シナリオの第２のシステム発話が、次の対話シナリオの第１のシステム発話になっていなければならないため、複数の対話シナリオが継続する場合には、システム対話とユーザ発話が交互に繰り返されることになり、文脈が保てなくなりやすい。

そこで、本発明は、システムが生成する発話が意味的、文脈的に破綻しづらい対話システムを提供することを目的とする。

本発明の対話システムは、ユーザへの振り発話及びその出力条件と、前記振り発話に対するユーザ応答の複数の候補と、前記ユーザ応答に基づいてシステムが発する受け発話の複数の候補及びその出力条件とからなる対話プランを複数記憶した対話プラン記憶部と、対話開始時に与えられている情報又は対話の履歴と前記出力条件とに基づいて、前記対話プランを選択し、ユーザとの対話を制御する対話制御部とを備える。

この構成により、ユーザとの対話は、ユーザへの振り発話、ユーザ応答、システムからの受け発話、ユーザへの振り発話、ユーザ応答、システムからの受け発話・・・といった具合に、ユーザ応答をシステムからの発話で挟んだ対話プランが繰り返されるので、文脈的に破綻しづらい対話システムを実現できる。また、対話プランは、対話開始時に与えられている情報又は対話の履歴と出力条件とに基づいて選択されるので、状況や対話の履歴にあった対話プランを選択し、文脈的に破綻しづらい対話システムを実現できる。ここで、対話開始時に与えられている情報とは、例えば、ユーザの嗜好情報や過去の対話履歴の情報である。

本発明の対話システムにおいて、前記対話制御部は、前記振り発話、前記ユーザ応答、又は前記受け発話に基づいて、ユーザとの対話で現れた概念を表す対話基盤化情報を生成し、記憶部に記憶すると共に、記憶された対話基盤化情報を用いてユーザとの対話を制御してもよい。

このようにユーザとの対話で現れた概念を表す対話基盤化情報を記憶し、活用することにより、対話の文脈にあった対話プランの選択や、対話プランの中での発話の決定を行うことができる。対話基盤化情報は、ユーザとの対話が継続している間は更新を行い、ユーザとの対話が途切れたときに、記憶部から削除してもよい。

本発明の対話システムにおいて、前記対話プランには、遷移先の対話プランの候補を示す情報が含まれており、前記対話制御部は、遷移先の対話プランの候補の中に条件に合う対話プランがあるか判定し、前記対話プランの候補の中に条件に合う対話プランがない場合に、他の対話プランの中から遷移先の対話プランを選択してもよい。

このように対話プランに遷移先の対話プランの候補を示す情報が含まれていることで、適切な対話プランに遷移することができる。また、予め遷移先の候補とされた対話プランが条件に合わない場合には、他の対話プランから遷移先の対話プランを選択することで、対話を継続させることができる。

本発明の対話システムにおいて、前記対話制御部は、前記ユーザ応答と正規表現によるマッチングを行うと共に、前記ユーザ応答に含まれる表現に意味を付与した上で指定した意味とマッチングを行ってもよい。また、意味を付与された表現の前後に隣接すべき表現（接頭辞・接尾辞や助詞など）をさらに、正規表現として指定してもよい。

この構成により、ユーザ応答に含まれる所定の正規表現を抽出すると共に、ユーザ応答に含まれる表現に意味を付与するので、単独の語にとどまらず、その単語の周りの語との関係を抽出できる。例えば、ユーザ応答に含まれる「カレー」という表現について、「料理名」という意味を付与することにより、料理名としての「カレー」が抽出される。これと共に、例えば、ユーザ応答における「食った」という表現を、「食べた」という用語の正規表現とマッチングすることにより、「食った」という表現の正規表現である「食べた」を抽出する。これにより、「カレー」を「作った」や「買った」ではなく、「カレー」を「食べた」という文脈を抽出できる。なお、意味を付与する方法としては、（拡張）固有表現の抽出を用いることができる。

本発明の対話システムは、ユーザの嗜好情報を記憶した嗜好情報記憶部を有し、前記対話制御部は、前記嗜好情報に基づいて前記対話プランの選択および対話の制御を行ってもよい。前記対話制御部は、前記ユーザ応答に基づいて前記嗜好情報記憶部に記憶された嗜好情報を更新してもよい。このようにユーザの嗜好情報を記憶しておくことにより、ユーザの好みの対話を提供できる。

本発明の対話システムは、話題の遷移を表すモデルを記憶した話題モデル記憶部と、前記対話制御部は、ユーザとの対話に基づいて現在の話題を特定し、前記モデルと前記ユーザ応答に基づいて、次に遷移する話題を決定してもよい。このように話題の遷移を表すモデルを用いることにより、話題を急激に変更することなく、対話プランを適切に選択することができる。

本発明の対話システムにおいて、前記対話プラン記憶部には、所定時間にわたって前記ユーザ応答を検出できないときのつなぎ発話を含む対話プランを記憶しており、前記対話プラン制御部は、所定時間にわたって前記ユーザ応答を検出できないときに、前記つなぎ発話を出力し、前記ユーザ応答を待ってもよい。

この構成により、ユーザからの応答が検出できないときには、つなぎ発話によってユーザからの応答を促し、ユーザからの応答を待つことができる。なお、つなぎ発話は、ユーザへの振り発話の内容から、より答えやすい内容に変更した発話を行ってもよい。例えば、オープン質問をクローズド質問に変える等である。

本発明の対話システムは、外部にある知識ベースに基づく情報提供を行うサーバに対してアクセスする通信部と、前記対話制御部は、前記知識ベースから取得した情報に基づいて、対話プランの選択および対話の制御を行ってもよい。このように外部にある知識ベースなどを有するサービスを利用することにより、例えば、ある表現の連想表現や意味推論などを活用でき、文脈を保った対話を継続できる可能性が高まる。

本発明の対話方法は、ユーザへの振り発話及びその出力条件と、前記振り発話に対するユーザ応答の複数の候補と、前記ユーザ応答に基づいて発する受け発話の複数の候補及びその出力条件とからなる対話プランを複数記憶した対話プラン記憶部を備えた対話システムによって、ユーザとの対話を制御する方法であって、前記対話システムは、対話開始時に与えられている情報又は対話の履歴と前記出力条件とに基づいて、前記対話プランを選択し、ユーザとの対話を制御する。

本発明の対話プログラムは、ユーザへの振り発話及びその出力条件と、前記振り発話に対するユーザ応答の複数の候補と、前記ユーザ応答に基づいて発する受け発話の複数の候補及びその出力条件とからなる対話プランを複数記憶した対話プラン記憶部を備えた対話システムによって、ユーザとの対話を制御するためのプログラムであって、コンピュータに、対話開始時に与えられている情報又は対話の履歴と前記出力条件とに基づいて、前記対話プランを選択させ、ユーザとの対話を制御させる。

本発明によれば、文脈的な破綻が起こりにくい対話を実現できる。

対話システムの構成を示す図である。 対話制御部の構成を示す図である。 対話プランの概要を示す図である。 振り発話の例を示す図である。 ユーザ応答の例を示す図である。 受け発話の例を示す図である。 無音のユーザ応答の例を示す図である。 無音応答に対する受け発話の例を示す図である。 （ａ）対話基盤化データの例を示す図である。（ｂ）対話基盤化データの例を示す図である。 （ａ）制限ボルツマンマシンのモデルを示す図である。（ｂ）制限ボルツマンマシンの入出力例を示す図である。 ユーザ嗜好データの例を示す図である。 （ａ）話題モデルの例を示す図である。（ｂ）話題モデルを使って対話プランを選択する例を示す図である。 知識ベースの例を示す図である。 対話システムの動作を示す図である。 ユーザからのユーザ応答を検出する動作を示す図である。 遷移先プランを決定する動作を示す図である。 機能がネットワーク上で分散された対話システムの構成を示す図である。

以下、本発明の実施の形態の対話システムについて、図面を参照して説明する。
図１は、実施の形態に係る対話システム１の構成を示す図である。対話システム１は、ユーザからの発話を入力する入力部１１と、入力された発話内容を解析する音声解析部１２と、ユーザとの対話を制御する対話制御部１３と、ユーザに対して発話を出力する出力部１４とを有する。

また、対話制御部１３は、対話プランデータベース（以下、「対話プランＤＢ」という）２１と、対話基盤化データ記憶部２２と、ユーザ嗜好データ記憶部２３と、話題モデル記憶部２４と、対話履歴データ記憶部２５とを有している。対話プランＤＢ２１には、複数の対話プランが記憶されている。１つの対話プランは、対話システム１からユーザに話を振る振り発話と、振り発話に対するユーザ応答と、ユーザ応答を受けて対話システム１からユーザに発する受け発話とで構成される。１つの対話プランにおいて、ユーザ応答と受け発話は１通りではなく、複数のユーザ応答と、複数の受け発話が含まれている。

対話制御部１３は、複数の対話プランを用いてユーザとの対話を行う。対話プランを選択し、選択された対話プランに従って、振り発話→ユーザ応答→受け発話の対話を制御し、その対話プランが終了すると、次の対話プランに遷移して、振り発話→ユーザ応答→受け発話の対話を制御する。これにより、振り発話→ユーザ応答→受け発話→振り発話→ユーザ応答→受け発話→・・・という順序で対話が継続していくことになる。

図２は、対話制御部１３の詳細な構成を示す図である。対話制御部１３は、対話状態を管理する対話状態管理部３０と、対話プランを処理する対話プラン処理部３３と、ユーザ嗜好を処理するユーザ嗜好処理部４２と、対話履歴のログを取得して管理する対話履歴ログ部４３とを有している。

対話状態管理部３０は、基盤化処理部３１とプラン選択部３２を有している。基盤化処理部３１は、ユーザとの対話で得られたデータを対話基盤化データ記憶部２２に記憶する処理を行うと共に、一連の対話が終了したら対話基盤化データ記憶部２２からクリアする処理を行う。プラン選択部３２は、事前に与えられた情報、ユーザの嗜好、対話履歴ログ、対話基盤化データ等に基づいて、次の対話プランを選択する処理を行う。

対話プラン処理部３３は、事前条件判定部３４と、発話生成部３５と、クエリ処理部３６と、ユーザ応答マッチング部３９とを有している。事前条件判定部３４は、振り・ユーザ応答・受け発話の条件をチェックする処理を行う。発話生成部３５は、対話プランに定められた発話フォーマットに値（後述するクエリインデックス）を入れて、発話内容を生成する処理を行う。

クエリ処理部３６は、クエリ文構文解析部３７と、外部サービス連携部３８とを有している。クエリ文構文解析部３７は、クエリ文に書かれた条件を構文解析し、そのクエリ文の中で定義されている定数、及び基盤化データ、外部サービス、ユーザ嗜好データから取得すべき変数、またそれらの間にどのような関係が満たされるべきかを表す一致・不一致、大小関係、包含関係、類似度などによって表現される式へ変換する処理を行う。外部サービス連携部３８は、外部の情報サービスと連携して、知識データ等を取得する処理を行う。クエリ処理部３６は、クエリ文構文解析部３７と外部サービス連携部の処理結果に基づいて、クエリ文の中で要求されている定数、変数の間の関係式を満たす変数の値の組合せがあるかを検索する。

ユーザ応答マッチング部３９は、ユーザ応答の形態素解析を行う形態素解析部４０と、ユーザ応答の意味解析を行う意味解析部４１とを有している。ユーザ応答マッチング部３９は、形態素解析と意味解析の結果を踏まえて、ユーザ応答がどの応答発話に一致するかのマッチングを行う。ユーザ応答マッチング部３９は、マッチングの結果をクエリ処理部３６に渡す。

図３～図６は、対話プランの一例を示す図である。図３は、対話プランの概要を示す図であり、対話プランに含まれる振り発話、ユーザ応答、受け発話が記載されている。図３で示す「プランＩＤ：Ｐ１０１」の対話プランは、ドメインが「グルメ」、サブドメインが「食事」で、プラン名は「お酒に合う＿１」である。プラン概要は、「お酒が合う料理について内容を深堀する振り」である。

この対話プランでは、初期発話の可否は「不可」となっており、ユーザとの対話を開始する際に用いることはできない。この対話プランは、すでにユーザとの対話が行われており、料理名等のキーワードが現れたときに、選択される対話プランである。初期発話が可能な振り発話としては、例えば、「どこへ行くの？」「今晩は何食べる？」等があり、これらの振り発話に対しては、初期発話の可否が「可」が設定される。

また、この対話プランでは、再利用可否が「不可」となっており、ユーザとの一連の対話の中で、この対話プランを２回使用することはできない。再利用可能な振り発話としては、「他に好きな果物は？」「他にはどの国に行ったことがある？」等がある。このような振り発話に対する応答は、一つではないので、複数回尋ねても問題がない。

振り発話の概要は「お酒が合う料理について深堀する振り」であって、発話例としては、「牛筋は、お酒が欲しくなるよね？」「牛筋は、お酒が進むよね？」である。図３に示しているのは例であって、実際には、「牛筋」「お酒」の部分は、ユーザとの対話で現れた文言に置き換わる。詳しくは、図４を参照して説明する。

「ユーザ応答→受け発話」は、振り発話に対するユーザ応答の概要およびその発話例と、ユーザ応答に対する受け発話の概要およびその発話例を示している。ここでも、図３に示しているのは例であって、実際には、文脈にあった発話がなされる。

図４は、「プランＩＤ：Ｐ１０１」の対話プランの振り発話の内容を示す図である。プランの概要は、図３で示したとおり、「お酒が合う料理について内容を深堀する振り」であり、対話行為は、「質問」である。

振り発話の発話フォーマットは、「＜ｓ１＞は、お＜ｓ２＞が欲しくなるよね。」「＜ｓ１＞は、お＜ｓ２＞が進むよね。」であり、その発話例は「牛筋は、お酒が欲しくなるよね。」「牛筋は、お酒が進むよね。」である。発話例は、発話フォーマットだけでは、その内容が分かりづらいことがあるので、具体例を示したものである。つまり、発話例は、対話システム１での処理には必須ではないが、発話例を有することにより、メンテナンス等が容易になる。

発話フォーマットにおいて、＜ｓ１＞＜ｓ２＞はクエリインデックスであり、ユーザとの対話で得られた値やそれに関連する値が入る。

「条件」は、この振り発話が選択されるための条件である。条件には、対話行為についての条件と、対話の内容についての条件がある。対話行為については、直前の対話行為が「意見・感想」を「含む」ことが条件となっている。ここでは、「意見・感想」を「含む」ことが条件であるが、この他にも様々なバリエーションが考えられ、例えば、直前の対話行為に「質問」を「含まない」ことや、「質問」を「含む」ことを条件とすることも可能である。なお、「含まない」ことが条件となる場合には、「質問」だけではなく、複数の対話形態を含まないことを条件とすることも可能である。

対話の内容についての条件としては、この例では、「対話基盤化データに存在する＜料理名＞」「料理知識データベースから取得する＜ｓ１＞と相性が良い関係にある＜酒＞」が規定されている。対話基盤化データについては後述するが、簡単にいうと、ユーザとの対話において現れた概念のデータである。対話基盤化データは、対話基盤化データ記憶部２２に記憶されて管理されている。

「対話基盤化データに存在する＜料理名＞」という条件は、対話基盤化データを参照して、これまでのユーザとの対話の中に、＜料理名＞が含まれていることであり、含まれている場合には、このクエリ文が「真」であると判定され、＜ｓ１＞に＜料理名＞が代入される。対話基盤化データに＜料理名＞が存在しない場合には、このクエリ文の結果が「偽」となり、この振り発話は適用されない。「真」と判定されたクエリ文の個数や割合をスコアで表し、スコアが高い振り発話を選択することとしてもよい。対話基盤化データに複数の料理名が存在する場合には、後続の条件を満たして、かつ、スコアの最も高い振り発話が選択される。

「料理知識サービスから取得する＜ｓ１＞と相性が良い関係にある＜酒＞」という条件は、料理知識サービスから取得した情報に基づいて、＜ｓ１＞で示される料理が＜酒＞と相性が良いことである。料理知識サービスには、料理の相性の良さを示すスコアを有しており、このスコアに基づいて相性を判定する。相性が良い場合には、このクエリ文が「真」であると判定され、＜ｓ２＞に、＜酒＞とそのスコアが代入される。

ユーザがお酒が合う料理を食べた場合には、上記したクエリ文がいずれも「真」となり、この振り発話が選択される可能性が高くなる。「真」と判定されたクエリ文の個数や割合をスコアで表し、スコアが高い振り発話を選択することとしてもよい。なお、図４では、対話基盤化データに記憶されたデータに関する条件を例として説明したが、後述するユーザの嗜好についてのデータをクエリの条件としてもよい。これにより、ユーザの嗜好に合った発話をすることが可能となる。

図４に示す振り発話を発する場合には、発話フォーマットの「＜ｓ１＞は、お＜ｓ２＞が欲しくなるよね。」「＜ｓ１＞は、お＜ｓ２＞が進むよね。」のクエリインデックス＜ｓ１＞に「料理名」、＜ｓ２＞に「酒」を入れる。これにより、ユーザが料理を食べたという発話に対して、「＜料理名＞は、お酒が欲しくなるよね。」または、「＜料理名＞は、お酒が進むよね。」というように、文脈を保った振り発話を行うことができる。なお、「＜料理名＞は、お酒が欲しくなるよね。」と「＜料理名＞は、お酒が進むよね。」のいずれを選択するかは、ランダムに選ぶことができる。

図５は、「プランＩＤ：Ｐ１０１」の対話プランのユーザ応答の候補の一つを示す図である。図５に示すプランの概要は、「肯定的応答」であり、対話行為は「回答」である。図５には、肯定的応答の例を示しているが、「プランＩＤ：Ｐ１０１」は、例えば、「否定的応答」や「無音応答」を、ユーザ応答の候補として有している。ユーザ応答の発話正規表現パターンは、「そうだ｜そうそう｜うん｜合う｜美味しい｜はい｜ＹＥＳ｜その通り｜だよね｜鉄板｜無敵｜間違いない」であり、ユーザからこれらの応答があった場合には、肯定的応答であると解釈される。

「条件」は、この振り発話が選択されるための条件である。条件には、対話行為についての条件と、対話の内容についての条件がある。この内容は、図３で示した振り発話で説明したのと同じである。

「対話基盤化」として、「＜ｓ１＞と＜ｓ２＞が相性の良い関係として追加された基盤化データ」とあるのは、振り発話において「＜ｓ１＞は、お＜ｓ２＞が欲しくなるよね。」と発話したのに対し、ユーザから肯定的応答が得られたことを受けて、＜ｓ１＞と＜ｓ２＞が相性の良い組合せであることの同意が得られたので、＜ｓ１＞と＜ｓ２＞が相性の良い関係であることを対話基盤化データに追加記録する。これにより、対話基盤化データを用いて、対話を適切に継続していくことができる。

「遷移先受け発話パターン」は、ユーザ応答に続く、システムからの受け発話の遷移先の候補を規定している。概要としては「手作りに対しての称賛・評価」や「振り発話での料理名→お店を連想した回答」等があり、それぞれに受け発話例が示されている。受け発話例は、上述したとおり、対話システム１の処理には必須ではないが、発話例を有することにより、メンテナンス等が容易になる。複数の遷移先受け発話パターンの候補の中からどの遷移先を選択するかは、各候補の条件と対話基盤化データとのマッチング等により決定する。

図６は、「プランＩＤ：Ｐ１０１」の対話プランの受け発話の候補の一つを示す図である。図６に示す受け発話の概要は、「振り発話での料理名→お酒を連想した回答」であり、対話行為は、「感想・意見応答」である。

この例では、受け発話の「発話フォーマット」として、「それはお＜ｓ２＞が進むね」「日本＜ｓ２＞か赤ワインか迷うわ」「＜ｓ２＞のあてにピッタリだ」の３つがあり、それぞれに発話例が付けられている。

「条件」は、この受け発話が選択されるための条件である。条件には、対話行為についての条件と、対話の内容についての条件がある。対話行為については、直前の対話行為が「回答」を「含む」ことが条件となっている。

対話の内容についての条件としては、この例では、「基盤化データに存在する＜ｓ１＞と＜ｓ２＞が相性が良いという関係」「基盤化データに存在する＜ｓ１＞と＜ｓ２＞であるという関係」が規定されている。これらの条件が「真」であるときに、この受け発話が選択される可能性が高くなる。

「遷移先対話プラン」は、「プランＩＤ：Ｐ１０１」の後に、優先的に遷移すべき対話プランの遷移先プランＩＤを規定している。この例では、「グルメ＿食事＿刺激の強い食べ物＿１」が優先的な遷移先とされている。ここで規定されている遷移先対話プランは、優先的な遷移先であって、対話の状況が遷移先プランの条件に合わない場合には、必ずしも遷移先プランＩＤに遷移するわけではない。その場合には、対話制御部１３は、他の対話プランの中から、条件にあった対話プランを検索し、遷移先として決定する。

図７、図８は、ユーザから所定時間にわたり応答がなかった場合の対話プランの一例を示す図である。図７は、「プランＩＤ：Ｐ１０１」の振り発話に対して応答がなかったときのユーザ応答の例、図８は、その受け発話の例を示す図である。ユーザ応答のフォーマットは、図５で示したユーザ応答の例と同じであり、受け発話のフォーマットは、図６で示した受け発話の例と同じである。

図７を参照して、ユーザ応答について説明する。概要は「無声発話」であり、対話行為は「ノンバーバルリアクション」である。直前の対話行為についての条件はなく、発話正規表現パターンが「沈黙」である場合、すなわち、所定時間の無音が検出されたときに、このユーザ応答が選択される。遷移先受け発話パターンは、「無音発話への受け」である。

図８は、「プランＩＤ：Ｐ１０１」における無音発話への受け発話を示しており、概要は「無応答への受け」、対話行為は「質問」である。発話フォーマットは「え、違う？」「お＜ｓ１＞が欲しくなるでしょ？」である。この受け発話に対する遷移先対話プランは、規定されていない。無音発話への受け発話を出力した場合には、ユーザからの応答を待つステータスを継続し、次の対話プランへの遷移をしないためである。

次に、対話基盤化データ記憶部２２に記憶される対話基盤化データについて説明する。対話基盤化データは、ユーザとの一連の対話の中で現れた概念をその対話の基盤として管理し、対話の文脈を保つために用いられる。

図９（ａ）、及び図９（ｂ）は、対話基盤化データの例を示す図である。図９（ａ）は、ユーザが「カレー〇〇」という料理店に行ったとの発話をしたときの対話基盤化データの例を示す図である。拡張固有表現の抽出により「カレー〇〇」が料理店の名称であることを検出し、また、正規表現パターンマッチングにより、料理店に「行った」ことを検出して、図９（ａ）に示す対話基盤化データが生成される。このように、「カレー〇〇」に行ったことを基盤化しておくことにより、同じ質問を回避することができると共に、カレーに関する対話を行なったりすることができる。

図９（ｂ）は、さらに、ユーザが「カレー」を食べたという発話をしたときの対話基盤化データの例を示す図である。知識ベース２５を参照すると、料理としての「カレー」は辛いことが分かるので、料理に対して「辛い」という味覚を関連付ける。これにより、対話制御部１３は、カレーを食べたというユーザの発話に対して、カレーが「辛い」ということに関連する対話を行うことが可能となる。

なお、料理の味覚に関連する対話を行うだけでなく、味覚に関連してお勧めの料理を推薦できるようにしてもよい。図１０（ａ）は、料理推薦サービスの一例として、制限ボルツマンマシンのモデルを示す図である。入力層に味覚についてのノード、出力層に料理のノードを有し、入力層と出力層との間に一または複数の隠れ層を有している。制限ボルツマンマシンの入力層に味覚のデータを入力することにより、料理名の各ノードの値が求められる。例えば、図１０（ｂ）に示すように、「ヘルシー」「辛い」という値を入力すると、値の高いノードとして「野菜」「カレー」のノードが求められる。

図１１は、ユーザ嗜好データ記憶部２３に記憶されたデータの例を示す図である。図１１に示す例では、ユーザの「趣味」「好きな食べ物」「好きな野球チーム」「好きな国」等のデータが記憶されている。これらのデータは、対話システム１を導入する際に、ユーザに初期設定させてもよいし、ユーザとの対話の中で現れたユーザの嗜好を記憶することとしてもよい。

このようにユーザ嗜好データを有していることにより、ユーザが対話しやすい話題を振ることができる。例えば、ユーザが好きなＡＢＣ野球チームが試合に勝ったときには、「ＡＢＣ野球チームは調子が良いですね。」というような振り発話を行うことができる。

図１２（ａ）は、話題モデル記憶部２４に記憶された話題モデルの例を示す図である。話題モデルは、話題の遷移とその遷移確率を表したモデルである。図１２（ａ）に示す例では、話題Ａから話題Ｂへ４０％の確率で遷移し、さらに話題Ｂから話題Ｃへは４０％の確率で遷移する。

なお、話題Ａから話題Ｂへの遷移確率が４０％で、話題Ａから話題Ｄへの遷移確率が３０％で、両者を足しても１００％にならないのは、他の話題へ遷移する可能性があるからである。話題の遷移先やその遷移確率は、初期には、一般的なデータを用いることができるが、ユーザとの対話を重ねるにしたがって、ユーザの話題の選択結果に基づいて、そのユーザ向けにカスタマイズしてもよい。

図１２（ｂ）は、話題モデルを用いて、話題を選択する例を示す図である。左上からみていくと、最初に、話題Ａに類する話題Ａ´の対話がなされている。ここで、話題Ａ´に基づく対話プランが観測され、この対話プランにおけるユーザ応答に基づいて遷移する対話プランが求められる。一方で、話題モデルに基づき、話題Ａ´から話題Ｂに遷移する確率が高いことが分かった場合、話題Ｂに基づいて生成される対話プランを求める。ユーザ応答に基づいて求められた対話プランと話題Ｂに基づいて求められた対話プランが一致するか否かを判定し、対話プランが一致する場合には、話題Ｂに遷移し、対話プランが一致しない場合には、話題Ｂ´に遷移する。

図１に戻って説明する。通信部１５は、外部の情報サービス２６と通信することができる。情報サービス２６は、知識ベース２７と通信部２８とを有している。対話システム１は、通信部１５を介して、情報サービス２６から知識ベース２７に記憶されたデータを取得することができる。

図１３は、知識ベース２７の一例として料理知識データベースの例を示す図である。知識ベース２５には、コモンセンスとして、連想される料理がリンクによって接続されている。そして、それぞれの料理について、具体的な名称（「カレー」「豆腐」）や、味覚のイメージ（「辛い」「濃い」）や、健康のイメージ等がリンクによって接続されている。このような知識ベース２５のデータを用いることで、対話の中で「カレー」という料理名が出てきたときに、「辛い」「濃い」等といったイメージを抽出し、ユーザとの対話に用いることができる。また、図１３には記載していないが、知識ベースは、料理の相性を示すデータを記憶してもよい。

図１４は、対話システム１の動作を示す図である。対話システム１は、まず、対話プランを選択し（Ｓ１０）、選択された対話プランにしたがって振り発話を出力する（Ｓ１１）。対話プランの選択は、ユーザの嗜好情報に基づいて行ってもよいし、現在の状況（例えば、曜日、時間帯、天気、渋滞等）に基づいてもよい。最初に選択される対話プランは、「初期発話可否」が「可」となっている対話プランである。続いて、対話システム１は、振り発話に対するユーザ応答を検出する（Ｓ１２）。

図１５は、ユーザ応答を検出する処理を詳細に示す図である。まず、対話システム１は、ユーザの音声を検出したか否かを判定する（Ｓ２０）。ユーザの音声を検出した場合には、ユーザからの音声がフィラーか否かを判定する（Ｓ２１）。フィラーとは、「えーと」「あの」「まー」といったような繋ぎの発話である。本実施形態では、相槌もフィラーとして扱う。ユーザの音声がフィラーである場合には（Ｓ２１でＹＥＳ）、フィラーを除く音声を検出しない状態が所定時間経過したか否かを判定する（Ｓ２５）。

ユーザの音声がフィラーではない場合には（Ｓ２１でＮＯ）、対話システム１は、検出した音声を解析し、現在の対話プランのいずれかのユーザに応答にマッチするか否かを判定する（Ｓ２２）。ユーザの音声がユーザ応答である場合には（Ｓ２２でＹＥＳ）、検出したユーザ応答を、図１４に示すフローにリターンする（Ｓ２３）。ユーザの音声がユーザ応答ではないと判定された場合（Ｓ２２でＮＯ）、現在の対話プランとは異なる別の処理を実行する。例えば、食事に関する振り発話をしたところ、対話プランとは関係のない「エアコンつけて」のように操作指示が入力された場合には、その対話プランとは別に、機器の操作を実行する。

ユーザからの音声を検出しない場合（Ｓ２０でＮＯ）、音声を検出しない状態が所定時間経過したか否かを判定する（Ｓ２４）。所定時間が経過していないときには（Ｓ２４でＮＯ）、ユーザの音声を検出するか否かの判定の処理に戻り（Ｓ２０）、ユーザからの音声の入力を待つ。ユーザからの音声を検出しない状態が所定時間経過したときには（Ｓ２４でＹＥＳ）、対話システム１は、繋ぎ発話を出力する（Ｓ２５）。

図１４に戻って、対話システム１の動作について説明する。対話システム１は、振り発話に対するユーザ応答を検出すると、対話基盤化データを更新し（Ｓ１３）、ユーザ嗜好データを更新する（Ｓ１４）。これらの処理は、対話基盤化データを更新可能な場合、ユーザ嗜好データを更新可能な場合に行い、ユーザ応答に基づいてこれらのデータを更新できない場合には、つまり、新しい概念が出てきていない場合には、データの更新は行わないで、次の処理に進む。

対話システム１は、ユーザ応答に基づいて、受け発話を選択し、出力する（Ｓ１５）。続いて、対話システム１は、遷移先の対話プランを決定する（Ｓ１６）。

図１６は、遷移先の対話プランを決定する処理を詳細に示す図である。対話プランの受け発話の中に優先遷移先の対話プランがあるか否かを判定する（Ｓ３０）。優先遷移先の対話プランがある場合には（Ｓ３０でＹＥＳ）、対話基盤化データやユーザ嗜好データが優先遷移先の対話プランの条件に合うか否かを判定し、優先遷移先から対話プランの選択が可能かどうかを判定する（Ｓ３１）。ここでは、対話プランへ遷移した場合に、その振り発話の生成条件がすべて満たされているかに基づいて判定を行う。優先遷移先から対話プランを選択可能と判定された場合には（Ｓ３１でＹＥＳ）、優先遷移先から対話プランを選択する（Ｓ３２）。

受け発話の中に優先遷移先がない場合（Ｓ３０でＮＯ）、あるいは、優先遷移先から対話プランを選択できない場合には（Ｓ３１でＮＯ）、他の対話プランの条件に基づいてマッチングを行い（Ｓ３３）、遷移先の対話プランを決定する。なお、図１６を用いて説明した遷移先の対話プランを決定する処理を受け発話の選択（Ｓ１５）と同時に行ってもよい。すなわち、遷移先の対話プランが見つかる可能性の高さを受け発話の選択の考慮要素としてもよい。これにより、破綻のない対話を長く継続できる。

図１４に戻って説明する。遷移先プランの決定の処理（Ｓ１６）において、遷移先の対話プランが見つかった場合には（Ｓ１７でＹＥＳ）、当該対話プランに基づいて、振り発話を出力し（Ｓ１１）、その後は、上記した処理と同じ処理を繰り返す。

次に、遷移先プランが見つからなかった場合（Ｓ１７でＮＯ）について説明する。遷移先プランが見つからない場合とは、遷移先プランＩＤが「Ｅｎｄ」になっているとき、あるいは、いずれの対話プランについてもマッチングの度合いが所定の基準を満たさない場合である。この場合は、対話基盤化データ記憶部２２に記憶されている対話基盤化データに基づいて対話履歴ログのデータを更新し、対話基盤化データ記憶部２２に記憶されたデータをクリアし（Ｓ１８）、ユーザとの対話を終了する。なお、この際に、対話基盤化データをマイニングしてユーザ嗜好情報を抽出し、ユーザ嗜好データ記憶部のデータ２３を更新してもよい。

以上、本実施の形態の対話システム１の構成について説明したが、上記した対話システム１のハードウェアの例は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスク、ディスプレイ、キーボード、マウス、通信インターフェース等を備えたコンピュータである。上記した各機能を実現するモジュールを有するプログラムをＲＡＭまたはＲＯＭに格納しておき、ＣＰＵによって当該プログラムを実行することによって、上記した対話システム１が実現される。このようなプログラムも本発明の範囲に含まれる。

本実施の形態の対話システム１は、振り発話、ユーザ応答、受け発話からなる対話プランを遷移させて、ユーザとの対話を行うので、ユーザからの応答をある程度限定させ、文脈的に破綻しづらい対話を実現できる。

最初に選ばれる対話プラン、あるいは遷移先の対話プランは、対話開始時に与えられている情報や対話の履歴を出力条件とマッチングさせることにより選択されるので、状況や対話の履歴にあった対話を実現することができる。

また、本実施の形態の対話システム１は、ユーザとの対話で現れた概念を表す対話基盤化データを記憶しておき、対話の制御に活用することにより、対話の文脈にあった対話プランの選択や、対話プランの中での発話の決定を行うことができる。

本実施の形態の対話システム１は、ユーザ応答に対して、正規表現によるマッチングと、拡張固有表現の抽出とを行うので、文脈の中で拡張固有表現がどのように用いられているかを抽出できる。

以上、本発明の対話システムについて、実施の形態を挙げて詳細に説明したが、本発明の対話システムは上記した実施の形態に限定されるものではない。

上記した実施の形態では、ユーザ応答を検出するステップＳ１２において、フィラーをユーザ応答から除外する処理を行う例を説明したが、ユーザの発話が、答えが一意に決まる静的な質問である場合には、ユーザ応答から除外してもよい。答えが一意に決まる静的な質問とは、例えば、ウェブ上の辞書に定義が記載されている質問である。例えば、システムが発した言葉の定義が分からないときに、ユーザが「〇〇ってどういう意味？」という静的な質問をしたときには、対話のステータスはそのままにして、質問に対する答えを返すことにより、対話を円滑に進めることができる。

上記した実施の形態では、対話システム１が単独の装置によって構成される例を挙げて説明したが、対話システム１の機能をネットワーク上で分散して配置してもよい。図１７は、機能がネットワーク上で分散された対話システム１の構成を示す図である。図１７に示す例では、対話システムは、対話クライアント１０、音声認識・合成サービス４０、対話制御サーバ５０によって構成されている。

本発明は、ユーザとの対話を行う対話システムとして有用である。

１ 対話システム
１１ 入力部
１２ 音声解析部
１３ 対話制御部
１４ 出力部
１５ 通信部
２１ 対話プランＤＢ
２２ 対話基盤化データ記憶部
２３ ユーザ嗜好データ記憶部
２４ 話題モデル記憶部
２５ 知識ベース

Claims (10)

1. ユーザへの振り発話及びその出力条件と、前記振り発話に対するユーザ応答の複数の候補と、前記ユーザ応答に基づいて発する受け発話の複数の候補及びその出力条件とからなる対話プランを複数記憶した対話プラン記憶部と、
   対話開始時に与えられている情報又は対話の履歴と前記出力条件とに基づいて、前記対話プランを選択し、ユーザとの対話を制御する対話制御部と、
   を備え、
   前記対話制御部は、前記振り発話、前記ユーザ応答、又は前記受け発話に基づいて、ユーザとの対話で現れた概念を表す対話基盤化情報を生成し、記憶部に一時的に記憶すると共に、記憶された対話基盤化情報を用いてユーザとの対話を制御し、ユーザとの対話が途切れたときに前記対話基盤化情報を記憶部から削除する、
   対話システム。
2. 前記対話プランには、遷移先の対話プランの候補を示す情報が含まれており、
   前記対話制御部は、遷移先の対話プランの候補の中から条件に合う対話プランがあるか判定し、前記対話プランの候補の中に条件に合う対話プランがない場合に、他の対話プランの中から遷移先の対話プランを選択する請求項１に記載の対話システム。
3. 前記対話制御部は、前記ユーザ応答と正規表現によるマッチングを行うと共に、前記ユーザ応答に含まれる表現に前記対話基盤化情報を用いて意味を付与した上で指定した意味とマッチングを行う請求項１または２に記載の対話システム。
4. ユーザの嗜好情報を記憶した嗜好情報記憶部を有し、
   前記対話制御部は、前記嗜好情報に基づいて前記対話プランの選択および対話の制御を行う請求項１乃至３のいずれかに記載の対話システム。
5. 前記対話制御部は、前記ユーザ応答に基づいて前記嗜好情報記憶部に記憶された嗜好情報を更新する請求項４に記載の対話システム。
6. 話題の遷移を表すモデルを記憶した話題モデル記憶部と、
   前記対話制御部は、ユーザとの対話に基づいて現在の話題を特定し、前記モデルと前記ユーザ応答に基づいて、次に遷移する話題を決定する請求項１乃至５のいずれかに記載の対話システム。
7. 前記対話プラン記憶部には、所定時間にわたって前記ユーザ応答を検出できないときのつなぎ発話を含む対話プランを記憶しており、
   前記対話制御部は、所定時間にわたって前記ユーザ応答を検出できないときに、前記つなぎ発話を出力し、前記ユーザ応答を待つ請求項１乃至６のいずれかに記載の対話システム。
8. 外部にある知識ベースに基づく情報提供を行うサーバに対してアクセスする通信部と、
   前記対話制御部は、前記知識ベースから取得した情報に基づいて、対話プランの選択および対話の制御を行う請求項１乃至７のいずれかに記載の対話システム。
9. ユーザへの振り発話及びその出力条件と、前記振り発話に対するユーザ応答の複数の候補と、前記ユーザ応答に基づいて発する受け発話の複数の候補及びその出力条件とからなる対話プランを複数記憶した対話プラン記憶部を備えた対話システムによって、ユーザとの対話を制御する方法であって、
   前記対話システムは、対話開始時に与えられている情報又は対話の履歴と前記出力条件とに基づいて、前記対話プランを選択し、
   前記振り発話、前記ユーザ応答、又は前記受け発話に基づいて、ユーザとの対話で現れた概念を表す対話基盤化情報を生成し、記憶部に一時的に記憶すると共に、記憶された対話基盤化情報を用いてユーザとの対話を制御し、ユーザとの対話が途切れたときに前記対話基盤化情報を記憶部から削除する、
   対話方法。
10. ユーザへの振り発話及びその出力条件と、前記振り発話に対するユーザ応答の複数の候補と、前記ユーザ応答に基づいて発する受け発話の複数の候補及びその出力条件とからなる対話プランを複数記憶した対話プラン記憶部を備えた対話システムによって、ユーザとの対話を制御するためのプログラムであって、コンピュータに、
    対話開始時に与えられている情報又は対話の履歴と前記出力条件とに基づいて、前記対話プランを選択させ、
    前記振り発話、前記ユーザ応答、又は前記受け発話に基づいて、ユーザとの対話で現れた概念を表す対話基盤化情報を生成し、記憶部に一時的に記憶すると共に、記憶された対話基盤化情報を用いてユーザとの対話を制御させ、ユーザとの対話が途切れたときに前記対話基盤化情報を記憶部から削除させる、
    プログラム。
    

Images