JP3576116B2

JP3576116B2 - 音声対話装置、音声対話処理方法、音声対話処理プログラムおよびその記録媒体

Info

Publication number: JP3576116B2
Application number: JP2001082632A
Authority: JP
Inventors: 宜仁安田; 浩二堂坂; 清明相川
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2001-03-22
Filing date: 2001-03-22
Publication date: 2004-10-13
Anticipated expiration: 2021-03-22
Also published as: JP2002278589A

Description

【０００１】
【発明の属する技術分野】
本発明は、音声対話装置に関し、詳しくは、音声によるやりとりによってユーザの要求を確認し、ユーザの要求を処理するにあたり、ユーザとのやりとりの回数（ターン数）を少なくする技術に関する。
【０００２】
【従来の技術】
音声対話装置では、通常、ユーザの発話内容は音声認識を経て理解され、ユーザの要求内容を決定していく。しかしながら、音声認識には限界があり、認識結果には誤りが含まれている可能性がある。したがって、音声対話装置がユーザの要求内容を確定するためには、音声認識結果だけに頼らずに、装置が理解した発話内容をユーザに確認する必要がある。
【０００３】
また、音声対話装置が受け付け可能な語彙・言い回しとユーザの発話に齟齬がある場合などには、装置に伝わった範囲の情報では、仮にすべてを確認し終えたとしても、ユーザの要求内容がはっきりしない場合がある。こういった場合には、音声対話装置はユーザに対して情報を要求することが必要となる。
【０００４】
このような音声対話装置からの確認や情報の要求によって発生する装置とユーザとの間の一連のやりとりは確認対話と呼ばれる。処理できる内容（タスク）が変われば、確認対象も変わる。タスクが変更された場合でも、対話のやりとりの回数を増やさずに確認を行う方法が必要である。
【０００５】
従来、タスクが変更された場合でも、対話のやりとりの回数を増やさずに動作する音声対話装置では、受け付け可能な要求が１つに限定されていた。
【０００６】
また、他の従来技術としては、少ない手間で対話を行い、複数の要求を受けつけるものがあった。しかし、タスクが変更された場合に人手により規則を記述する必要があり、タスクが変更された場合に自動的に対話のやりとりの回数（ターン数）を増やさないような確認手順に適応できるものではなかった。
【０００７】
【発明が解決しようとする課題】
このように、従来の技術でタスクが変更された場合でも、ユーザの手間を増やさずに確認を行うためには、予め処理できるユーザの要求内容の種類を１つに定めておく必要があった。しかし、実際にはこういった制約があると実用的ではない。
【０００８】
例えばビデオ管理を音声対話装置を用いて行う場合には、少なくとも「予約」、「予約の変更」、「予約の確認」程度は行えなければならない。これらだけでもすでに３つの要求を受けつけることができなければならないことになる。受け付け可能な要求が複数になった場合には、要求によって確認する内容が異なってくるので、事前に決めておいた手順で確認するわけにはいかない。
【０００９】
また、複数の要求を受け付け可能で少ない手間で対話を行える従来技術は、タスクを変更した場合には人手で規則を記述する必要があった。
【００１０】
本発明の目的は、これら従来技術の制限をなくし、複数の処理内容を受けつけることができる音声対話装置において、タスクが変更された場合であっても、少ない対話のターン数で、利用者の要求を把握できるタスク適応型高率対話処理を実現することにある。
【００１１】
【課題を解決するための手段】
本発明による音声対話装置は、装置で扱えるすべて要求の種類について、ユーザ要求を特定のものに仮定した場合のユーザ要求確認終了までの期待ターン数と、各時点における装置の理解状態に対するユーザ要求の確率分布を利用して、対話終了までの期待ターン数ができるだけ小さくなるように装置の行動を決定することを主要な特徴とするものである。
【００１２】
音声対話装置の理解状態は属性（項目名、「曜日」「場所」「面会相手」など）と値（「月曜日」「第三会議室」「山田課長」など）およびその値の確からしさの集合で表わされているとし、このときの属性のことをスロットと呼ぶ。ユーザ要求確認終了までの期待ターン数を得るために、特定スロット群を確認するための期待ターン数を推定する。このターン数はスロット認識率という特定のスロット群について確認をしている際の音声認識率を利用して求まる。
【００１３】
たとえ確率の高いユーザ要求があったとしても、その確認のために必要なターン数が膨大であるのであれば、多少確率が低くても短いターン数で確認をし終えることのできる要求があるのであれば、まずその要求についての確認を行うことは、たとえ結果的にユーザの要求が異なっていたとしても、対話終了までの期待ターン数は短くすることができる場合がある。本発明では、各ユーザ要求の確率と各ユーザ要求までのターン数の期待値を使って、すべての確認順序の中で、もっとも期待ターン数が小さくなるような確認内容を選択できる。さらに、本発明では、タスクが変わった場合でも、設計者は新たに規則を記述する必要はない。
【００１４】
【発明の実施の形態】
以下、本発明の一実施例について図面により具体的に説明する。
図１は、本発明にかかる音声対話装置の一実施例の機能ブロック図を示す。本音声対話装置はタスク仕様データベース１００、音声認識部１１０、言語理解部１２０、ユーザ要求内容確率分布推定部１３０、スロット認識率推定部１４０、特定ユーザ要求確定までの期待ターン数推定部１５０、確認内容決定部１６０、出力部１７０などにより構成される。なお、実際には、本音声対話装置は、ＣＰＵやメモリ装置、入出力装置等の、いわゆるコンピュータシステムにより実現されるものである。
【００１５】
通常、音声対話装置では１つのタスクで受け付けることのできるユーザの要求は複数ある。例えば、スケジュール管理を行う音声対話装置であれば、スケジュールの追加、変更、確認といった複数のユーザ要求が最低でも必要である。本音声対話装置でも、複数のユーザ要求の種類があるタスクを取り扱うことができる。
【００１６】
図２は本音声対話装置の処理フローチャートを示したものである。図２により本音声対話装置の全体的な処理の流れを説明する。なお、ステップ２３０はステップ２５０の次でもよい。
【００１７】
タスク仕様データベース１００には、装置が現存処理することができるタスク仕様が記述格納されている。タスクの仕様は大きく二つの情報群からなる。一つ目は、装置で扱うことのできるユーザ要求の種類と、各ユーザ要求で必要な項目（スロット）とそのスロットに入り得る語彙の値域であり、二つ目は語彙の依存関係である。このタスク仕様データベース１００の具体的記述例については後述する。
【００１８】
音声対話装置は、人（ユーザ）と音声による会話をしながら特定の仕事（タスク）を実行する。音声認識部１１０は、ユーザの要求等を表わす音声を入力し（ステップ２００）、音声認識して文字列に変換する（ステップ２１０）。言語理解部１２０は、音声認識部１１０によって得られた文字列を装置の理解状態に変換する（ステップ２２０）。理解状態は属性（項目名）と値および値の確からしさの集合で表わされ、このときの属性のことをスロットと呼ぶことにする。
【００１９】
ユーザ要求内容確率分布推定部１３０は、言語理解部１２０によって得られた理解状態を用いてユーザ要求の確率分布を推定する（ステップ２３０）。ここでは、タスク仕様データベース１００に記述されたタスク仕様の各ユーザ要求と理解状態との関連度を算出して近似的に確率値とする。
【００２０】
スロット認識率推定部１４０は、タスク仕様データベース１００から、言語理解部１２０によって得られた理解状態の確認対象（スロット）の語彙を入力して、音声認識部１１０の現確認最中での期待される認識率を推定する（ステップ２４０）。この推定された認識率のことをスロット認識率と呼ぶことにする。特定ユーザ要求確定までの期待ターン数推定部１５０は、言語理解部１２０から理解状態、スロット認識率推定部１４０からスロット認識率を入力として、タスク仕様データベース１００のタスク仕様をもとに、装置が扱えるすべてのユーザ要求種類について、ユーザ要求を特定のものと仮定した場合のそれぞれの期待ターン数を推定する（ステップ２５０）。
【００２１】
確認内容決定部２００は、ユーザ要求内容確率分布推定部１３０からのユーザ要求の確率分布（現理解状態と各ユーザ要求の関連度）と期待ターン数推定部１５０からの各ユーザ要求確認終了までの期待ターン数を入力として、装置の次の確認内容を決定する（ステップ２６０）。出力部１７０は、確認内容決定部１６０で決定された確認内容（確認／要求）を音声に変換して出力する（ステップ２７０）。
【００２２】
上記ステップ２００〜２７０を、ユーザと会話しながら所望の回数繰り返して特定の仕事（タスク）が終了となるが、本音声対話装置では、各時点における理解状態に対するユーザ要求の確率分布と各ユーザ要求確認終了までの期待ターン数を用いて次の確認／要求を決定しているため、対話終了までのターン数が小さくなる。
【００２３】
なお、図２に示すような処理手順をコンピュータに実行させるためのプログラムは、フロッピーやＣＤ−ＲＯＭ、その他、コンピュータで読み取り可能な記録媒体に記録して提供することが可能である。このような記録媒体に記録されたプログラムをコンピュータにロードすることにより、図１の各部の所期の機能が達成される。
【００２４】
次に、本音声対話装置の各構成について詳述する。
〔音声認識部１１０〕
ユーザは音声によって本音声対話装置へ要求内容を伝達する。ユーザからの音声は、音声認識部１１０によって文字列に変換される。この音声認識部１１０は既存の物を利用することができる。
【００２５】
〔言語理解部１２０〕
音声認識部１１０より得られた文字列は、言語理解部１２０によって理解状態に変換される。この言語理解部１２０も既存の物を利用することができる。理解状態に必要な値の確からしさは、例えばＨＭＭベースの音声認識器の音響スコアなどを使うことができる。
【００２６】
〔ユーザ要求内容確率分布推定部〕
ユーザ要求内容確率分布推定部１３０では、ある時点での装置の理解状態を用いて、ユ−ザ要求の確率分布を推定する。
実際に確率分布を得ることは困難なため、ここでは、タスク仕様データベース１００のタスク仕様をもとに、タスク（装置）で取り扱うことができる各ユーザ要求と理解状態との関連度を定め、近似的に確率値とする方法を考える。
【００２７】
いま、理解状態のスロットｓ_ｉの値をｖ_ｉと表し、その値の確からしさをｃ_ｉとする。装置が確認を終えたスロットの確からしきは１とする。確認対象となっているユーザ要求Ｇ_ｊにおいて必要なスロットの数をＮ_Ｇｊとする。スロットの値ｖ_ｉが値域となりうるユーザ要求の数をＭ_ｖｉとしたとき、その時点で理解状態Ｓとユーザ要求Ｇｊとの関連度Ｒｅｌ（Ｓ，Ｇ_ｊ）を、以下のように定める。
Ｇ_ｊの値域として認められている値が入っているｖｉについて、
【数１】

とする。
【００２８】
〔スロット認識率推定部１４０〕
本音声対話装置は、対話の局面に応じて必要な語彙を切り換える。例えば、装置がユーザに対して「何曜日の予定ですか？」と問合せたとする。この場合に認識することが必要となる語彙は、「月曜日」「火曜日」など曜日に言及する語彙と、「はい」「いいえ」など対話を進める上で一般的に必要となる語彙である。一方、「何曜日にどこで打ちあわせですか？」と問合せたとする。この場合に必要と思われる語彙は前述の語彙に加えて「第三会議室」「応接室」など場所に言及する語彙が必要となる。一般に語彙数が増えると音声認識部１１０での認識誤りの可能性が増える。
【００２９】
スロット認識率推定部１４０では、装置が確認対象としているスロット（複数でも良い）が与えられた場合に、確認の最中で期待される音声認識率を推定する。この推定された認識率のことを「スロット認識率」と呼ぶ。
【００３０】
ある語彙数ｎ_ｂのときの認識率ｒ_ｂは分かっているとする。対象スロット群に入り得る語彙数はｎ_ｂであるとする。ここでは、この条件下で、スロット認識率ｒを推定するような方法を２つ挙げる。
【００３１】
（方法１）
認識誤り率は、語彙数の平方根に比例するという経験則が知られている。この経験則を利用し、
【数２】

とする。
【００３２】
（方法２）
一つの単語の尤度に対して、別の単語の尤度がその尤度を越える確率がｐのとき、ｎ個の単語の全てがその尤度を越えない確率は、（１−ｐ）のｎ剰である。語彙がｎ_ｂのときの認識率をｒ_ｂとしたので、
【数３】

が成り立つはずなので、ｎ語の時の認識率を
【数４】

とする。
【００３３】
〔特定ユーザ要求確定までの期待ターン数推定部１５０〕
特定ユーザ要求確定までの期待ターン数推定部１５０では、装置で扱えるユーザ要求種類について、ユーザ要求の推定を正確に行えたと仮定した場合の、その特定のユーザ要求についての確認を終了するまでの期待ターン数を推定する。
この状況を、スケジュール管理を行う音声対話装置の例でたとえれば、ユーザはスケジュールの確認やその他のことではなくスケジュールの追加を行いたいのだ、ということが正確に判明している時点で、曜日やスケジュールの内容などを音声対話装置が把握するまでにかかるターン数を推定することに相当する。
【００３４】
そのために、まず、スロット認識率が与えられた場合の、一回の確認／要求完了するまでの期待ターン数を推定する方法を考える。
ユーザは音声対話装置からの確認に対しては、最低でもＹｅｓ／Ｎｏ相当を装置伝えるとし、しかもＹｅｓ／Ｎｏは装置に必ず正確に伝わると仮定すれば、スロット認識率がｒのときに、確認／要求に必要な期待ターン数を以下のように求めることができる。
確認が終了するまでに必要な期待ターン数ｔ_ｃｏｎｆ
【数５】

要求が終了するまでに必要な期待ターン数ｔ_ｒｅｑ
【数６】

複数のスロットを同時に確認あるいは要求する場合に必要な期待ターン数も同様に考えることができる。
【００３５】
次に、スロット認識率が与えられた場合の、特定ユーザ要求確定までの期待ターン数を推定する方法を考える。
ある時点での音声対話装置の理解状態において、特定のユーザ要求の確定までに必要な行動は、スロットの名前とそのスロットについて必要な行動（確認なのか要求なのか）の対の集合で表すことができる。この必要な行動対の集合が決まった場合の、その中で最小の期待ターンを返す確認の順序を考えることができる。なぜなら、必要な行動の集合のすべての分け方の、すべての順列には期待ターン数を考えることができるからである。この最小の期待ターン数を返すものを、今の状態から必要な行動対の集合を与えたユーザ要求までの期待ターン数とする。
【００３６】
〔確認内容決定部１６０〕
確認内容決定部１６０では、各時点において装置は次にどれとどれを確認／要求すれば良いかを決定する。確認内容決定部１６０からの出力は、スロット名（一般には複数）と確認なのか要求なのかという情報である。
【００３７】
確認内容決定部１６０は、入力として、ユーザ要求の確率分布（各ユーザ要求と理解状態の関連度）と、各ユーザ要求までの期待ターン数を受け付け、対話終了までの期待ターン数を小さくするような確認内容を決定する。入力として、ユーザ要求の確率分布と、各ユーザ要求までの期待ターン数を受け付ける理由は、どんなに確認終了までのターン数が小さなユーザ要求であっても、その可能性が非常に小さいのであれば、そのユーザ要求が正しいかどうかを確認するのは、結局、対話全体のターン数を大きくすることになりかねないからである。
【００３８】
真のユーザの要求がＧ_ｉである確率をｐ_Ｇｉ，Ｇ_ｉまでの期待ターン数をｔ_Ｇｉと表す。装置が仮定したユーザの要求が真のユーザの要求とは異なるということが分かるまでのターン数が、ユーザ要求確定までの期待ターン数と同じであるという仮定を置く。この場合、例えば可能なユーザ要求が２つの装置でＧ_１，Ｇ_２の順に対話をすすめていった場合の対話終了までの期待ターン数は
【数７】

と考えることができ、逆にＧ_２、Ｇ_１の順に対話をすすめていった場合の対話終了までの期待ターン数は、
【数８】

であると考えることができる。
【００３９】
一般に音声対話装置が、複数のユーザ要求を受け付けることができる場合でも、
【数９】

がもっとも小さくなるようなユーザ要求の選択順ａ（１），ａ（２），…ａ（ｎ）を選択する。この選択順の先頭であるＧ_ａ（１）というユーザ要求を仮定した場合に、特定ユーザ要求確定までの期待ターン数推定部１５０が出力する、確認内容を確認内容決定部１６０の出力とする。
【００４０】
〔出力部１７０〕
出力部１７０は、確認内容決定部１６０によって出力されたスロット名と確認／要求の種類を入力として受け取り、音声を出力する。この出力部１７０は、例えば、既存のテンプレートべースの言語生成器と、既存の音声合成器の組み合わせによって実現することができる。
【００４１】
以下に、本音声対話装置における処理の具体例を示す。
ここでは会社の秘書タスクを想定し、ユーザ要求の種類としては「社内便の手配」「社員の呼び出し」「コピー受け付け」「買物内容の確認」が扱えるとし、それぞれに必要な情報は、以下の通りであるとする。
（ｉ）「社内便の配送受け付け」
商品名（社内にあるもの）、目的部署名（全部署）、目的人名（全員）、数量（１−１０）
（ii）「社員の呼び出し」
部署名（関連部署）、人名（関連人員）、日を表す数（１−３０）
（iii）「コピー受け付け」
コピーの対象（書類のどれか）、部数（１−１００）
（iv）「買物内容の確認」
メーカー名（カタログにある全メーカー）、商品名（カタログにある商品）、数量（１−５０）
部署は全体で１００、人名の種類は１０００、商品名の種類は５００、書類名は５０、メーカー名の種類は１００、「はい」「いいえ」などを含む一般的に対話に必要な語彙数を１００とする。また、認識部１１０の基本性能として、語彙数が５００であれば０．８の確率で認識に成功するとする。
【００４２】
〔タスク仕様データベース１００〕
タスク仕様データベース１００には大きく、次の２つの情報が記述してある。
（１）各ユーザ要求で必要なスロットとそのスロットに入り得る語彙の値域
（２）語彙の依存関係
【００４３】
ここでは、（１）の例としては、次のような情報が記述されることになる。
（ｉ）「社内便の配送受け付け」
商品名（社内にあるもの）、目的部署名（全部署）、目的人名（全員）、数量（１−１０）
（ii）「社員の呼び出し」
部署名（関連部署）、人名（関連人員）、日を表す数（１−３０）
（iii）「コピー受け付け」
コピーの対象（書類のどれか）、部数（１−１００）
（iv）「買物内容の確認」
メーカー名（カタログにある全メーカー）、商品名（カタログにある商品）、数量（１−５０）
【００４４】
また、（２）の例としては、次のような情報が記述される。
所属が（営業部）→名前は（杉山、阿部、近藤、岡、鈴木）のいずれか
所属が（企業部）→名前は（阿部、勝野、小林、安藤）のいずれか
所属が（研究部）→名前は（相川、中野、垣添、安藤、鈴木）のいずれか
所属が（総務部）→名前は（中野、小林、鈴木、永井）のいずれか
名前が（杉山）→所属は（営業部）
名前が（阿部）→所属は（営業部、企画部）のいずれか
名前が（近藤）→所属は（営業部）
名前が（岡）→所属は（営業部）
名前が（鈴木）→所属は（営業部、研究部、総務部）のいずれか
名前が（勝野）→所属は（企画部）
名前が（小林）→所属は（企画部、総務部）のいずれか
名前が（安藤）→所属は（企画部、研究部）のいずれか
名前が（相川）→所属は（研究部）
名前が（中野）→所属は（研究部、総務部）のいずれか
名前が（垣添）→所属は（研究部）
名前が（永井）→所属は（総務部）
【００４５】
〔音声認識部１１０〕
音声認識部１１０ではユーザの発生した音声を受け取り、文字列を出力する。今、ユーザは「石元さんに送りたい」と言ったとする。これは適切に認識されるとは限らず、「石元さん、日本通…」と誤まった認識結果（文字列）を出力することがある。
以後の記述は、この誤った出力の場合の動作例を示したものである。
【００４６】
〔言語理解部１２０〕
言語理解部１２０では、認識部１１０からの文字列を入力し、理解状態を出力する。理解状態は（スロット名、値、確からしさの集合）で表わされる。
いま、「石元さん、日本通…」の認識結果、理解部１２０では、
（名前＝石元、確からしさ＝０．８）
（メーカー＝日本通、確からしさ＝０．７）
といった装置の理解状態を出力したとする。
【００４７】
〔ユーザ要求内容確率分布推定部１３０〕
ユーザ要求内容確率分布推定部１３０では、現在の理解状態から推定される、ユーザ要求の確率を算出するが、ここでは、装置で扱える各ユーザ要求と理解状態との関連度を（１）式で算出する。
【００４８】
現在の理解状態は、（名前＝石元、確からしさ＝０．８）および（メーカー＝日本通、確からしさ＝０．７）である。
ユーザ要求「社内便の配送受け付け」で必要なスロット数は商品名、目的部署名、目的人名、数量の４つなので、Ｎ＿｛Ｇ＿ｊ｝＝４となる。
一方、「名前＝石元」という値域が認められるのは社内便と、呼び出しの２つなので、Ｍ＿｛名前＝石元｝＝２となる。
【００４９】
よって、現在の理解状態と社内便との関連度は
Ｒｅｌ｛Ｓ，Ｇ＿｛社内便｝｝＝１／４＊０．８／２＝０．１
となる。同様にして、
Ｒｅｌ｛Ｓ，Ｇ＿｛呼び出し｝｝＝１／３＊０．８／２＝０．１３
Ｒｅｌ｛Ｓ，Ｇ＿｛コピー｝｝＝０
Ｒｅｌ｛Ｓ，Ｇ＿｛買物｝｝＝１／３＊０．７／１＝０．２３
となる。さらに、確率値の和が１になるように各関連度を正規化する。これにより、各ユーザ要求の確率は次のようになる。
「社内便の手配」＝０．２２
「社員の呼び出し」＝０．２８
「コピー受け付け」＝０
「買物内容の確認」＝０．５
【００５０】
〔スロット認識率推定部１４０〕
スロット認識率推定部１４０では、確認対象の語彙が与えられた場合に、音声認識部１１０がどの程度の確率で正しく認識を行えるかどうかを推定する。ここでは、（２）式あるいは（４）式を用いてスロット認識率ｒを算出する。
【００５１】
いま、今理解状態の中に確定した情報がない中で、スロット「名前」を装置が尋ねる場合に必要な語彙数は
１０００（名前）＋（一般的な語彙）＝１１００
となる。
【００５２】
方法（１）を使った場合
ｒ＝１−（１−０．８）＊ｓｑｒｔ（１１００）／ｓｑｒｔ（５００）＝０．７０３
となる。また、方法（２）を使った場合
ｒ＝０．８の（１１００／５００）剰＝０．６１
となる。
【００５３】
〔特定ユーザ要求確定までの期待ターン数推定部１５０〕
ここでは、装置が扱えるすべてのユーザ要求種類について、ユーザ要求の推定を正確に行えたと仮定して、特定ユーザ要求確定までの期待ターン数を算出する。出力はターン数と、その際の行動（確認／要求）である。
【００５４】
例えば、ユーザ要求「社内便配送受け付け」を仮定した場合、現在の理解状態
（名前＝石元、確からしさ＝０．８）
（メーカー＝日本通、確からしさ＝０．７）
から、必要な行動は、
（商品名、要求）（目的部署名、要求）（目的人名、確認）（数量、要求）
となる（メーカーは無視される）。
【００５５】
ここで、情報要求と確認を同時に行えないとすれば、行動の組み合わせは
Ａ．（商品）（部署）（人名）（数量）
Ｂ．（商品部署）（人名）（数量）
Ｃ．（商品数量）（部署）（人名）
Ｄ．（商品）（部署数量）（人名）
Ｅ．（商品部署数量）（人名）
（同じかっこ内の項目を同時に確認する）
の５通りとなる。
【００５６】
さらに、それぞれについて「どの順序で確認あるいは要求を行うのか」が
Ａ．４！＝２４
Ｂ．３！＝６
Ｃ．３！＝６
Ｄ．３！＝６
Ｅ．２！＝２
の４４通りとなる。
これら、４４通りの行動の組合せそれぞれについて、ユーザ要求内容確定までにどれくらいのターン数が必要かどうかを推定する。
【００５７】
例えば、（人名）→（部署数量）→（商品）という行動系列での期待ターン数を考える。
（人名）の部分での期待ターン数は、語彙数（人名の種類＋一般的な語彙）から、スロット認識率推定部１４０によって出力された認識率ｒ＿１から、１／ｒ＿１と推定できる。
（部署数量）の部分での語彙数は、先に（人名）が確定したはずであり、人名が定まっていれば部署は全部署を対象とするのではなく、「石元」という名前の人が所属する部署にだけ語彙を絞ることができる。この時の語彙数から、スロット認識率推定部１４０によって推定された認識率ｒ＿から、（部署数量）を確定するために必要なターン数は、１／ｒ＿２と推定できる。
【００５８】
同様に（商品）の部分での認識率ｒ＿３も、語彙数（商品の数＋一般的な語彙）から推定でき、必要なターン数は１／ｒ＿３と推定できる。
よって、（人名）→（部署数量）→（商品）に必要な期待ターン数は、１／ｒ＿１＋１／ｒ＿２＋１／ｒ＿３となる。
【００５９】
同様の計算を４４通りの組合せすべてについて行う。この中で最も小さい値となる組合せが、この特定要求までの期待ターン数推定部１５０の出力となる。
【００６０】
〔確認内部決定部１６０〕
ここでは、特定ユーザ要求確定までの期待ターン数推定部１５０が出力したターン数と、ユーザ要求内部確率分布推定部１３０が出力した確率分布から、次に装置が何を確認あるいは情報要求するのかを決定する。
【００６１】
いま、特定ユーザ要求確定までの期待ターン数推定部１５０、ユーザ要求内容確率分布推定部１３０の出力として、
「社内便の手配」８ターン、０．２２
「社員の呼び出し」１０ターン、０．２８
「コピー受け付け」１２ターン、０
「買物内容の確認」５ターン、０．５
というターン数と確率分布が得られたとする。
【００６２】
仮に、次の順序で確認をするとする。
１．ユーザの要求内容は「社内便の手配」なのかどうかを８ターンかけて確認。成功すればおしまい。失敗すれば元の理解状態を仮定して２へ。
２．ユーザの要求内容は「社員の呼び出し」なのかどうかを８ターンかけて確認。成功すればおしまい。失敗すれば元の理解状態を仮定して３へ。
３．ユーザの要求内容は「コピー受け付け」なのかどうかを８ターンかけて確認。成功すればおしまい。失敗すれば元の理解状態を仮定して４へ。
４．ユーザの要求内容は「買物内容の確認」以外にありえないので、「買物内容の確認」の要求内容を８ターンかけて確認。
【００６３】
この場合の期待ターンを、
０．２２＊８＋０．２８＊（８＋１０）＋０＊（８＋１０＋１２）＋０．５＊（８＋１０＋１２＋５）
とする。
【００６４】
以上の計算を「社内便の手配」「社員の呼び出し」「コピー受け付け」「買物内容の確認」の順序を入れかえた４！＝２４通り、すべてについて行う。これが最も小さくなるような順序を選び、その際に最初に確認すべきユーザ要求内容について、特定ユーザ要求確定までの期待ターン数推定部１５０が出力した行動を出力する。
【００６５】
行動は、スロット名と要求あるいは確認およびスロット値であり、例えば、「部署、要求、なし」あるいは「人名、確認、石元」などとなる。
【００６６】
〔出力部１７０〕
出力部１７０では、確認内容決定部１６０の出力を入力としてユーザに音声を出力する。
たとえば、「部署、要求、なし」が入力された場合には、「部署名を教えてください」と出力する。また、「人名、確認、石元」が入力された場合には、「お名前は石元さまでよろしいですね？」と出力する。
【００６７】
なお、従来の音声対話装置であれば、予め決められた確認手順を取ることになる。たとえば、
１．理解状態中の未確認のものには１つずつ確認する
という確認手順であれば、「石元さんですね？」と確認することになるし、
２．理解状態中の未確認のものはまとめて確認する
という確認手順であれば、「石元さん、日本通ですね？」と確認することになるし、
３．ユーザの関求内容を特定できるまでは、予め決められた順序でユーザに発話を要請する、
という確認手順であれば、「姓は何ですか？」といったことを聞くことになる。いずれにしても、対話終了までの対話のやりとりの回数の増加はまぬがれないものである。
【００６８】
【発明の効果】
以上説明したように、本発明による音声対話装置を用いると、タスクが変更されても少ない対話のやりとりの回数で確認を行い、対話終了までの対話のやりとりの回数を小さくすることが可能である。
【図面の簡単な説明】
【図１】本発明の音声対話装置の一実施例のブロック図である。
【図２】図１の処理フローチャートである。
【符号の説明】
１００タスク仕様データベース
１１０音声認識部
１２０言語理解部
１３０ユーザ要求内容確率分布推定部
１４０スロット認識率推定部
１５０特定ユーザ要求確定までの期待ターン数推定部
１６０確認内容決定部
１７０出力部

Claims

利用者（ユーザ）と音声によるやりとりによってユーザの要求を確認し、ユーザの要求を処理する、ユーザ要求の種類が複数扱える音声対話装置であって、
ユーザの音声を入力し、音声認識して文字列に変換する手段と、
前記文字列を装置内部の理解状態に変換する手段と、
前記理解状態を入力として、現理解状態と装置で扱える各ユーザ要求との関連度を求めることで、ユーザ要求の確率分布を推定する手段と、
前記理解状態の確認対象の語彙を入力し、特定の項目に関しての確認の最中での期待される音声認識率を推定する手段と、
前記理解状態と前記推定された音声認識率を入力として、装置で扱える各ユーザ要求種類について、ユーザ要求を特定のもと仮定した場合の期待ターン数を推定する手段と、
前記推定したユーザ要求の確率分布と期待ターン数を入力として、装置の次の確認あるいは要求を表わす確認内容を決定する手段と、
前記確認内容を音声に変換して出力する手段と、
を有することを特徴とする音声対話装置。
請求項１記載の音声対話装置において、装置が処理することのできるタスクの仕様として、少なくともユーザ要求の種類と各ユーザ要求で必要な項目とその項目に入り得る語彙の値域および語彙の依存関係を記述したデータベースを有することを特徴とする音声対話装置。
音声対話装置が利用者（ユーザ）と音声によるやりとりによってユーザの要求を確認し、ユーザの要求を処理する、ユーザ要求の種類が複数扱える音声対話処理方法であって、
ユーザの音声を入力し、音声認識して文字列に変換するステップと、
前記文字列を装置内部の理解状態に変換するステップと、
前記理解状態を入力として、現理解状態と装置で扱える各ユーザ要求との関連度を求めることで、ユーザ要求の確率分布を推定するステップと、
前記理解状態の確認対象の語彙を入力し、特定の項目に関しての確認の最中での音声認識の認識率を推定するステップと、
前記理解状態と前記推定された音声認識の認識率を入力として、装置で扱える各ユーザ要求種類について、ユーザ要求を特定のもと仮定した場合の期待ターン数を推定するステップと、
前記推定したユーザ要求の確率分布と期待ターン数を入力として、装置の次の確認あるいは要求を表わす確認内容を決定するステップと、
前記確認内容を音声に変換して出力するステップと、
を有することを特徴とする音声対話処理方法。
請求項３記載の音声対話処理方法の処理をコンピュータで実行させるためのプログラム。
請求項３記載の音声対話処理方法の処理をコンピュータで実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。