JP3611533B2 - 対話型情報提供装置、対話型情報提供処理方法、プログラムおよび記録媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、対話型情報提供サービスの技術分野に係わり、詳しくは、利用者が情報の問い合せを意味する文を文字列または音声として入力するとき、該問合せの内容を確認するための確認文を文字列または音声として利用者に対して出力し、確認文に対して利用者側が承認を意味する文を文字列または音声として入力する場合には、利用者が承認した問合せ内容を記録し、利用者が確認の否認を意味する文を文字列または音声として入力する場合には、利用者が新たな情報の問合せを意味する文を文字列または音声として入力するのを待ち、この利用者側と情報提供側の対話の中で、利用者の問い合わせの種別が一意に決まった後で、利用者により承認された問い合せの内容にしたがって情報を提供するための応答文を文字列あるいは音声として利用者に対し出力する対話型情報提供装置において、利用者の不満度を軽減する技術に関するものである。
【０００２】
【従来の技術】
音声対話装置で代表されるように、対話型情報提供サービスでは、一般に次のような対話手順をとる。たとえば、気象情報、テレビ番組表、スケジュール表、交通機関の時刻表、といった様々な情報を蓄積したデータベースがあるとき、データベースに蓄積された情報についての問い合わせを意味する文を、利用者が計算機端末のキーボード、マウス、音声認識装置、あるいは、これらの組み合わせを介して、文字列または音声として入力すると、情報提供側は、まず、利用者の問い合わせ内容を確認するための文節列を、計算機端末のディスプレイ、プリンタ、タイプライタ、音声合成装置、あるいは、これらの組み合わせを介して、利用者に対し出力する。利用者が確認の承認を意味する文を文字列または音声として入力する場合には、情報提供側は、利用者が承認した問い合せ内容を記憶する。利用者が確認の否認を意味する文も文字列あるいは音声として入力する場合には、情報提供側は、利用者がさらなる問い合せを意味する文を入力するのを待つ。これを何度か繰り返し、利用者に提供すべき情報種別が一意に決定できた後、情報提供側は、利用者に承認された問い合わせ内容に従って情報を提供するための応答文を文字列あるいは音声として出力する。
【０００３】
この種の対話型情報提供サービスにおいて、第一の従来技術としては、利用者側の問合せの内容を確認するために、利用者が入力する問合せの内容を全て確認するという方法がある。また、第二の従来技術としては、利用者が入力した文から生成された問い合せの内容が正しいものであると仮定したときに、利用者に提供する情報種別が一意に決定できる場合に、生成された問い合せの内容の全てあるいは一部を確認し、利用者側が確認を承認し、情報提供側が承認された問合せ内容にしたがって応答文を出力するという対話手順において、情報提供側が出力する確認文と応答文の個数の総和を極小にするように、利用者に対して確認する内容を決定するという方法がある。なお、第一の従来技術、第二の従来技術のいずれにおいても、利用者の問い合わせ内容は、属性と値の組の集合として表現される。
【０００４】
【発明が解決しようとする課題】
第一の従来技術では、利用者より入力された文を分析して、利用者の問い合せ内容を表す属性と値の組の集合を生成すると、その問合せ内容を構成する属性
（項目）のすべての確認を求めるための文を出力する。この従来技術では、利用者が入力した文から問合せの内容を生成する際の誤認識などに伴う利用者不満度を増大させるという問題がある。これについて説明する。
【０００５】
利用者が文字列または音声として入力した文から問合せの内容を生成する際には、文字列または音声の誤認識などに伴う理由により、利用者が意図する問合せの内容とは異なる問合せの内容が生成される場合がある。その場合には、情報提供側が確認のために出力する文の内容は、利用者が意図する問い合わせの内容と異なる。利用者は否認を意味する文を入力することになるので、利用者が問い合せている情報は利用者に対し出力されない。利用者側は、再度問合せの内容を入力し、情報提供側から再度確認を要求されることになり、利用者の不満度が増大する。
【０００６】
利用者の不満度の増大を避けるためには、情報提供側が出力する確認文の個数を削減する必要がある。このため、第二の従来技術では、利用者が入力した文から生成された問い合せの内容が正しいものであると仮定したときに、利用者に提供する情報種別が一意に決定できる場合に、生成された問い合せの内容に含まれる属性のすべてあるいは一部を確認し、利用者側が確認を承認し、利用者側により承認された問合せ内容にしたがって応答文を出力するという一連の対話手順の中で、確認文と応答文の個数の総和を最小になるように、利用者に対し確認すべき属性を決定する。
【０００７】
対話手順において出力される確認文と応答文の個数の総和を対話手順の対話コストとよぶ。応答文の個数も考慮に入れるのは、応答文の個数が増えても、利用者の不満足度が高まる可能性があるからである。
【０００８】
第二の従来技術は、利用者が入力した文から生成された問い合せ内容が正しいものであると仮定したときに、利用者に提供する情報種別が一意に決定できる場合に適用するという制限があり、その仮定が成立しない場合には、第二の従来技術を適用できず、第一の従来技術を適用せざるをえず、やはり利用者の不満度を増大させるという問題が生じる。
【０００９】
以下に、第一の従来技術、第二の従来技術の問題点について具体例で説明する。例として、気象情報に関する情報提供サービスを考える。利用者側に対し提供できる情報の種別は、ある場所と時間の天気と、ある場所に発表されている警報の２つであるとする。利用者の問い合せの内容は、場所、情報種別という２つの属性（項目）によって表されるとする。場所という属性は、神奈川県、香川県といった都道府県名を値としてとり、情報種別は、天気、警報という値をとるとする。
【００１０】
今、情報提供側が、データベース内のデータとして「現在どこにも警報は発表されていない」というデータを保持している状況を想定する。このとき、利用者が、「神奈川県の警報について教えてください」という問い合せを意味する文を入力し、情報提供側は、誤認識などの理由により、利用者の問い合わせの内容が、「香川県の警報について教えてください」という内容であると誤って認識したとする。生成される問い合せの内容は、場所という属性の値が香川県であり、情報種別という属性が警報であるという属性と値の組の集合となる。この属性と値の組の集合は、次のように書かれる。
｛＜場所，香川県＞，＜情報種別，警報＞｝
【００１１】
この場合、第一の従来技術では、情報提供側は、利用者の文から生成された問い合わせ内容に含まれるすべての属性を確認するために、「香川県の警報ですか？」という確認のための文を出力する。利用者側は、意図する問合せの内容と確認の内容が異なるので、否認を意味する文「いいえ」を入力し、あらためて、問合せを行う文「神奈川県の警報です」という文を入力しなければならない。続いて、情報提供側は、新たに利用者側の問い合わせの内容を生成する。今度は、利用者側の問い合わせ内容を正しく生成することができたとすると、情報提供側は、「神奈川県の警報ですか？」と確認文を出力する。利用者側は、承認を意味する文「はい」を入力し、情報提供側は、「神奈川県に警報は発表されていません」と応答文を１個出力する。情報提供側は、「香川県の警報ですか？」という確認文と、「神奈川県の警報ですか？」という確認文と、「神奈川県に警報は発表されていません」という応答文の、合計３個の文を出力することになる。利用者側からすると、確認を２度も要求されることになり、不満足度が高まる。
【００１２】
第二の従来技術は、問い合せ内容に含まれる属性のうち、どの属性を確認すべきかを決定する。今想定している例だと、以下に示すように、問い合せの内容に含まれる属性は、香川県という場所と警報という情報種別の２つの属性である。｛＜場所，香川県＞，＜情報種別，警報＞｝
操り返しになるが、この問い合せ内容は、誤認識により、利用者が意図する神奈川県の警報について知りたいという問い合せ内容とは異なっている。
【００１３】
まず、問い合せ内容を確認し、利用者の承認が入力され、応答するという対話手順をすべて生成し、確認文と応答文の個数の総和、すなわち対話コストが極小となる対話手順を選ぶ。ここでは、利用者側の承認が入力されるまで場所と情報種別という２つの属性を両方ともに確認し、その後、利用者が承認した場所に警報は出ていませんという内容の１個の応答文を生成するという対話手順Ａと、利用者側の承認が入力されるまで場所と情報種別という１つの属性を確認し、その後、どこにも警報は出ていませんという内容の１個の応答文を生成する対話手順Ｂについて考える。
【００１４】
第二の従来技術においては、属性を確認するときに、利用者が承認するまで出力される確認文の個数を推定する必要がある。利用者が承認するまで出力される確認文の個数は、属性の値を認識する精度などに依存する。各属性の値は、誤認識により、利用者が意図する問い合せとは異なっている可能性があるので、確認する属性が増えれば増えるほど、利用者に確認を否認される可能性が高まり、それだけ確認文の個数は増えるのである。ここでは、確認文の個数は、確認する属性の数の２倍であると推定されると仮定する。
【００１５】
手順Ａでは、最初、「香川県の警報ですか」という確認文が出力される。利用者は、意図する問合せの内容と確認の内容が異なるので、確認を否認し、問合せを再度行うことになる。場所と情報種別という２個の属性を利用者から承認が入力されるまで確認する際に出力される確認文の個数は、４個と推定される。情報提供側が承認すると、「神奈川県の警報ですか」と確認文を出力し、利用者はこの確認を承認し、「神奈川県に警報は出ていません」という応答文が１個出力される。対話コストは、確認文と応答文の個数の総和の５となる。
【００１６】
手順Ｂでは、最初、「警報ですか」という確認文が出力される。情報種別という１個の属性を利用者からの承認が入力されるまで確認する際に出力される確認文の個数は、２個と推定される。利用者は確認を承認すると、「どこにも警報は出ていません」という１個の応答文が生成されることになる。対話コストは、確認文と応答文の個数の総和の３となる。
【００１７】
結局、対話コストが小さい手順Ｂが選択され、情報提供側は、情報種別という属性のみを確認するために、「警報ですか」という確認文を出力することになる。
【００１８】
このように、第二の従来技術は、第一の従来技術の問題点を解決できる場合があるが、利用者が入力した文から生成された問い合せの内容が正しいものであると仮定したときに、利用者に提供する情報種別が一意に決定できる場合に適用するという制限があり、その仮定が成立しない場合には、第二の従来技術を適用できず、第一の従来技術を適用せざるをえず、利用者の不満度を増大させるという問題が生じる。
【００１９】
たとえば、情報提供側が、データベース内のデータとして、「現在どこにも警報は発表されていない」というデータを保持しているという状況を想定する。利用者が、「神奈川県の警報ついて教えてください」という問合せを意味する文を入力し、情報提供側は、誤認識などの理由により、「神奈川県」を「香川県」と誤認識し、「警報」を全くに認識できなかったとする。問い合わせの内容が、「香川県について教えてください」という内容であると誤って認識したとする。生成された問い合せ内容は、以下のようになる。
｛＜場所，香川県＞｝
【００２０】
この問い合せ内容が正しいと仮定したときに、利用者側に提供できる情報種別は、天気と警報の２つがあり、一つに決定できない。したがった、第二の従来技術は適用できない。第一の従来技術を適用せざるをえず、「香川県ですか」という確認文が出力される。既に説明したように、これは利用者が意図した問い合せの内容とは異なるので、利用者は再度問い合せの内容を入力し、情報提供側から再度確認を要求されることになり、利用者の不満度は増大する。
【００２１】
第二の従来技術が、問い合せ内容から判断したとき、提供すべき情報種別が複数個存在する場合に適用できないのは、情報種別ごとの対話手順の間で確認文と応答文の個数を比較する方法を備えていないからである。しかし、提供すべき情報種別が複数個ありえる場合でも、各情報種別の確率を計算し、情報種別ごとに確認文と応答文の個数の総和が極小になるような対話手順を決定し、各情報種別の確率を考慮して、確認文と応答文の個数の総和をできるだけ小さくするように、確認すべき属性を選択することができる場合がある。次に、その例を考える。
【００２２】
今想定している状況では、情報種別は警報か天気のいずれかである。情報種別の確率は等確率であると考え、警報という情報種別の確率が０．５であり、天気という情報種別の確率が０．５であるとする。
【００２３】
次に、提供情報種別ごとに、対話コストが極小となる対話手順を決定し、その対話手順をその情報種別に関する最適対話手順とよび、その対話コストをその情報種別に関する最適コストとよぶ。
【００２４】
情報種別が警報であるときを考える。警報であるという想定の下では、情報種別が一つに決まっているから、従来の第二の技術を使うことができる。確認文の個数と応答文の個数を極小にする対話手順は、情報種別を確認して、利用者が承認してから、応答を出力するという対話手順Ｂである。対話手順Ｂの対話コストは３である。警報という情報種別に関する最適対話手順は対話手順Ｂであり、最適コストは３となる。
【００２５】
情報種別が天気であるときを考える。このとき、問い合せ内容を確認して、利用者の承認を待って、応答するというすべての対話手順を生成し、対話コストが極小の対話手順を選ぶ。ここでは、対話手順として、利用者の承認が入力されるまで場所を確認し、次に、利用者の承認が入力されるまで情報種別を確認し、次に応答するという対話手順Ｃと、利用者の承認が入力されるまで情報種別を確認し、次に、利用者の承認が入力されるまで場所を確認し、次に、応答するという対話手順Ｄを考える。いずれの対話手順においても、確認文の個数は、４個と推定される。応答文は、ある場所のある時間の天気は何であるという文１個によって生成されるとする。対話コストは、いずれの対話手順でも５である。天気という情報種別に関する最適対話手順は、対話手順Ｃと対話手順Ｄであり、最適コストは５である。
【００２６】
次に、提供情報種別の確率を考慮して、確認文と応答文の個数の総和をできるだけ小さくするように、確認すべき属性を決定する。そのために、問い合せ内容を構成する各属性に関して、情報種別ごとにその属性を最初に確認したと仮定したときの極小対話コストをもつ対話手順を計算する。その対話手順を属性の確認のための準最適対話手順とよび、対話コストを属性の確認のための準最適コストとよぶ。属性の確認のための準最適コストから最適コストを差し引いたもの数を属性の確認による損失とよぶ。属性の確認による損失は、その属性を最初に確認するとなると、最適コストに比較して、どれだけのコストを余計にかけることになるかを示している。各提供情報種別の確率を考慮して、属性の確認による損失の期待値をできるだけ小さくするような属性を先に確認するようにすれば、できるかぎり最適コストに近い対話コストをもつ対話手順を選択することとなる。
【００２７】
たとえば、確認すべき属性として、情報種別と場所という属性について考える。第一に、情報種別を確認すると仮定する。警報という提供情報種別に関しては、情報種別の確認のための準最適対話手順は、対話手順Ｂとなる。情報種別の確認のための準最適コストは３であり、情報種別の確認による損失は０である。天気という提供情報種別に関しては、情報種別の確認のための準最適対話手順は、対話手順Ｄとなり、情報種別の確認のための準最適コストは５となる。情報種別の確認による損失は０である。各提供情報種別の確率は等確率であるので、情報種別の確認による損失の期待値は０となる。
【００２８】
第二に、場所という属性を確認すると仮定する。警報という提供情報種別に関しては、場所の確認のための準最適対話手順は、対話手順Ａとなる。場所の確認のための準最適コストは５であり、場所の確認による損失は２である。天気という提供情報種別に関しては、場所の確認のための準最適対話手順は、対話手順Ｃとなり、場所の確認のための準最適コストは５となる。場所の確認による損失は０である。各提供情報種別の確率は等確率であるので、場所の確認による損失の期待値は１となる。
【００２９】
したがって、生成された問い合せ内容が、「香川県について教えてください」という内容であるならば、「警報それとも天気ですか」といった確認文によって、情報種別という属性を最初に確認することが、対話コストをできるだけ小さくすることになる。
【００３０】
実際、場所を先に確認したとすると、場所を確認するために数個の確認文を出力した後、情報種別を確認して、情報種別が警報であると分かった場合、場所の確認のために出力した確認文は無駄であったことになる。なぜなら、警報であるなら、場所の確認をしてもしなくても、応答文の個数は同じであり、それならば、場所の確認をしないほうが対話コストを小さくすることができるからである。一方、情報種別を先に確認しても、情報種別が警報であろうと、天気であろうと、情報種別の確認は無駄にならず、利用者の不満足度は増大しない。
【００３１】
こういった属性の確認による損失の期待値を最小にするような属性が存在するにもかかわらず、従来技術では、問い合せ内容から判断したとき、提供すべき情報種別が複数個存在する場合には、問い合せ内容に含まれるすべての属性を確認し、属性の確認による損失の期待値を最小にするような属性を使えば避けることができるはずの利用者不満足度の増大を避けることができないという問題があった。
【００３２】
また、利用者が承認した問い合わせ内容にしたがって、提供情報種別が一意に決まっている場合には、その最適対話手順が確認を含まないものであるなら、確認を行わないで応答文を出力することが、最も対話コストを小さくすることになるので、最適対話手順にしたがって応答文を出力すればよい。従来技術では、この点について考慮されていない。
【００３３】
本発明は、対話型情報提供装置において、上述のような従来技術の問題点に鑑みてなされたもので、その目的は、従来技術では、問い合せ内容に含まれるすべての属性を確認する場合であっても、属性の確認による期待損失を極小にするような属性を優先して確認することにより、誤認識などによって生じる利用者に対し出力される確認文と応答文の個数の増大に伴う利用者の不満足度の増大を避けることを可能とすることにある。
【００３４】
【課題を解決するための手段】
本発明による対話型情報提供装置では、
利用者からの情報の問い合せ、確認の承認、確認の否認を受け取る手段、
利用者側が情報の問い合せを意味する文を入力する場合は、その文の内容と文が入力された時点で記録されている問い合せ内容から判断して、利用者の問い合わせ内容を表す属性と値の組の集合を生成し、その属性と値の組の集合を利用者の問い合わせ内容として記録し、属性の確認を求める確認文に対し利用者が確認の承認を意味する文を入力する場合は、その属性を利用者により承認された問い合せ内容として記録する手段、
利用者の問い合わせの内容と利用者により承認されている問い合せ内容から判断して、利用者に提供することが可能なすべての情報の種別を提供情報種別として決定するとともに、提供情報種別の確率を計算する手段、
提供情報種別の各々に関して、利用者によって承認されていない問い合せの内容を構成する属性の全て或いは一部の確認を求め、利用者が確認を承認した後に、利用者側により承認されている問合せの内容にしたがって、データベースに蓄積された情報を提供するという対話手順と、確認を行わないで、該問い合せの内容にしたがって、データベースに蓄積された情報を提供するという対話手順を生成する手段、
各々の対話手順に関して、対話手順に含まれる確認文と応答文の個数の総和を推定し、推定された総和を対話コストとして計算する手段、
提供情報種別の各々に関して、極小の対話コストをもつ対話手順を選択し、その極小の対話コストをもつ対話手順を最適対話手順とし、その極小の対話コストを最適コストとする手段、
提供情報種別の各々に関して、すべての対話手順の中から、指定された属性の確認を最初に求める対話手順を選び出し、その対話手順の中で極小の対話コストをもつ対話手順を選び、その属性の確認のための準最適対話手順とし、その極小の対話コストをその属性の確認のための準最適コストとする手段、
提供情報種別の各々に関して、指定された属性の確認のための準最適コストから最適コストを減じ、その減算の結果の数をその属性の確認による損失とする手段、
提供情報種別の各々に関する属性の確認による損失から、提供情報種別の確率を考慮して、属性の確認による損失の期待値を計算し、その期待値を属性の確認による期待損失とする手段、
利用者に承認されていない問い合せの内容に含まれる属性の各々に関して、各属性の確認による期待損失を比較し、極小の期待損失をもつ属性を選択し、該属性を確認属性として決定する手段、
前記決定された確認属性の確認を求めるための確認文を利用者側に対し出力する手段、
などを有することを特徴とする。最適コスト対話手順として、確認を行わないで応答文を出力する対話手順が存在するならば、確認を行うことが必要ないものと判断して、その対話手順にしたがって、応答文を出力し、さもなければ、確認属性の確認を求める確認文を利用者に対し出力する。
【００３５】
本発明では、利用者が情報の問い合せを意味する文を文字列または音声として入力するときに、利用者によって承認されていない問い合せの内容を構成する属性の全て或いは一部の確認を求め、利用者が確認を承認した後に、利用者側により承認されている問合せの内容にしたがって、データベースに蓄積された情報を提供するという対話手順において、対話手順に含まれる確認文と応答文の個数の総和を対話コストとして計算し、提供情報種別の各々に関して、極小となる対話コストを最適対話コストとして計算し、提供情報種別の各々に関して、利用者によって承認されていない問い合せ内容に含まれる各属性を最初に確認する場合の極小対話コストをその属性の確認のための準最適対話コストとして計算し、提供情報種別の各々に関して、各属性の確認のための準最適対話コストから最適コストを減じた数を、その属性の確認による損失として計算し、提供情報種別の確率を考慮して、各属性の確認による損失の期待値を属性の確認による期待損失として計算し、期待損失が極小となるような属性を優先して確認することにより、誤認識などによって生じる利用者に対し出力される確認文と応答文の個数の増大に伴う利用者の不満足度の増大を避けることが可能となる。
【００３６】
【発明の実施の形態】
以下、発明の一実施の形態について図面により詳細に説明する。
図１は、本発明による対話型情報提供装置の構成例を示す。本対話型情報提供装置は、文入力部１０、文理解部２０、提供情報種別決定部３０、対話手順生成部４０、データベース５０、対話コスト計算部６０、最適対話手順決定部７０、準最適対話手順決定部８０、損失計算部９０、期待損失計算部１００、確認属性決定部１１０、文出力部１２０、制御部１３０により構成される。データベース５０には、利用者に提供する情報が蓄積されている。また、文入力部１０と文出力部１２０は通信回線などにより、利用者の端末と接続されるが、図１では省略してある。なお、一般には、本対話型情報提供装置は、いわゆるコンピュータシステムを利用して構築されるものである。
【００３７】
文入力部１０は、利用者が計算機端末のキーボード、マウス、音声認識装置、或いは、これらの組み合わせを介して、文字列または音声として入力する、情報の問い合せまたは確認の承認または確認の否認を意味する文を取り込む。
【００３８】
文理解部２０は、利用者側が情報の問い合せを意味する文を入力する場合は、その文の内容と文が入力された時点で記録されている問い合せ内容から判断して、利用者の問い合わせ内容を表す属性と値の組の集合を生成し、その属性と値の組の集合を利用者の問い合わせ内容として記録し、提供情報種別決定部３０と対話手順生成部４０と制御部１３０に転送する。また、文理解部２０は、属性の確認を求める確認文に対し利用者が確認の承認を意味する文を入力すると、その属性を利用者により承認された問い合せ内容として記録し、提供情報種別決定部３０と対話手順生成部４０と制御部１３０に転送する。また、利用者が確認文に対し確認の否認を意味する文を入力すると、制御部１３０に否認信号を送る。
【００３９】
提供情報種別決定部３０は、文理解部２０から転送される利用者の問い合わせの内容と利用者により承認されている問い合せ内容から判断して、利用者に提供することが可能なすべての情報の種別を提供情報種別として決定し、さらに提供情報種別の確率を計算する。提供情報種別決定部３０は、決定した提供情報種別を対話手順生成部４０に転送し、提供情報種別と提供情報種別の確率を制御部１３０に転送する。
【００４０】
対話手順生成部４０は、提供情報種別決定部３０から転送された提供情報種別の各々に関して、文理解部２０から転送された利用者の問い合わせ内容や利用者に承服された問い合わせ内容をもとに、利用者によって承認されていない問い合せの内容を構成する属性の全て或いは一部の確認を求め、利用者が確認を承認した後に、利用者側により承認されている問合せの内容にしたがって、データベース５０に蓄積された情報を提供するといつ対話手順と、確認を行わないで、該問い合せの内容にしたがって、データベース５０に蓄積された情報を提供するという対話手順を生成し、生成した対話手順をコスト計算部６０に転送する。
【００４１】
対話コスト計算部６０は、対話手順生成部４０から転送された各々の対話手順に関して、対話手順に含まれる確認文と応答文の個数の総和を推定し、推定された総和を対話コストとして生成する。対話コスト計算部６０は、対話コストと対話手順を最適対話手順決定部７０と準最適対話手順決定部８０に転送する。
【００４２】
最適対話手順決定部７０は、制御部１３０の命令にしたがって、提供情報種別の各々に関して、対話コスト計算部６０から転送されたすべての対話手順と対話コストを用いて、極小の対話コストをもつ対話手順を選択し、その極小の対話コストをもつ対話手順を最適対話手順として生成し、その極小の対話コストを最適コストとして生成する。最適対話手順決定部７０は、提供情報種別の各々に関して、生成した最適対話手順と最適コストを損失計算部９０に転送し、最適対話手順を制御部１３０に転送する。
【００４３】
準最適対話手順決定部８０は、制御部１３０の命令にしたがって、提供情報種別の各々に関して、対話コスト計算部６０から転送されたすべての対話手順の中から、制御部１３０が指定する属性の確認を最初に求める対話手順を選び出し、その対話手順の中で極小の対話コストをもつ対話手順を選び、その属性の確認のための準最適対話手順として生成し、その極小の対話コストをその属性の確認のための準最適コストとして生成する。準最適対話手順決定部８０は、提供情報種別の各々に関して、その属性の確認のための準最適対話手順と準最適コストを損失計算部９０に転送する。
【００４４】
損失計算部９０は、制御部１３０の命令にしたがって、提供情報種別の各々に関して、制御部１３０が指定する属性の確認による損失を計算するために、準最適対話手順決定部８０から転送される属性の確認のための準最適コストから最適対話手順決定部７０から転送される最適コストを減じ、その減算の結果の数をその属性の確認による損失として期待損失計算部１００に転送する。
【００４５】
期待損失計算部１００は、制御部１３０の命令にしたがって、提供情報種別の各々に関して、損失計算部１９０から転送される属性の確認による損失から、提供情報種別の確率を考慮して、属性の確認による損失の期待値を計算し、その期待値を属性の確認による期待損失として確認属性決定部１１０に転送する。
【００４６】
確認属性決定部１１０は、期待損失計算部１００から転送される各属性の確認による期待損失を比較し、期待損失が極小となるような属性を選択し、確認属性として文出力部１２０に転送する。
【００４７】
文出力部１２０は、制御部１３０から確認指令を受け取る場合には、確認属性決定部１１０から転送される確認属性の確認を求める確認文を利用者に対し出力し、制御部１３０から応答指令を受け取る場合には、制御手段１３０から転送される対話手順にしたがって、応答文を利用者に対し出力する。
【００４８】
制御部１３０は、文理解部２０から転送される利用者の問い合わせ内容と利用者により承認された問い合せ内容、提供情報種別決定部３０から転送される提供情報種別と提供情報種別の確率、最適対話手順決定部７０から転送される最適対話手順を記憶している。制御部１３０は、１０〜１２０の各部の動作を以下のように制御する。
（１） 文理解部２０から否認信号が送信されてきた場合は、文入力部１０が利用者からの情報の問い合せの入力を待つように、文入力部１０を制御する。
（２） 提供情報種別の各々に関して、最適対話手順決定部７０が最適対話手順と最適コストを生成するように、最適対話手順決定部７０を制御する。
（３） 提供情報種別の各々に関して、準最適対話手順決定部８０が、利用者に承認されていない問い合せ内容に含まれる各属性に関して、その属性の確認のための準最適対話手順と準最適コストを計算するように、準最適対話手順決定部８０を制御する。
（４） 提供情報種別の各々に関して、損失計算部９０が、利用者に承認されていない問い合せ内容に含まれる各属性に関して、その属性の確認による損失を計算するように、損失計算部９０を制御する。
（５） 期待損失計算部１００が、利用者に承認されていない問い合せ内容に含まれる各属性に関して、その属性の確認による損失の期待値を計算するように、期待損失計算部１００を制御する。
（６） 提供情報種別が一意に決まっており、最適対話手順が、確認を行わないで応答を行う対話手順であるという条件が成立するならば、文出力部１２０にその最適対話手順を転送し、文出力部１２０が応答指令を送信するように制御する。その条件が成立しないならば、文出力部１２０に確認指令を送信するように制御する。
【００４９】
図２に本対話型情報提供装置の処理フローチャートを示す。図２において、ステップ２０１〜２１１の各処理は、図１の１０〜１２０の各部の機能に対応する。ここで、図１の１０〜１２０の各部の機能（図２の２０１〜２１１の各ステップの処理）をコンピュータに実行させるためのプログラムは、フロッピーやＣＤ−ＲＯＭ、その他、コンピュータで読み取り可能な記録媒体に記録して提供することが可能である。このような記録媒体に記録されたプログラムをコンピュータにロードすることにより、図１の各部の所期の機能が達成される。
【００５０】
以下に、具体例とともに本発明の実施例の詳細な動作について説明する。
たとえば、気象情報に関する情報提供サービスを考える。可能な提供情報種別は、天気と警報の２つであるとする。利用者の問い合せの内容は、場所、情報種別という２つの属性によって表されるとする。場所という属性は、神奈川県、香川県といった都道府県名を値としてとり、情報種別は、天気、警報という値をとるとする。また、データベース５０に「警報はどこにも出ていない」というデータが記憶されているという状況を想定する。
【００５１】
利用者が、次のような情報の問い合せを意味する文を入力したとする。
「神奈川県の警報について教えてください」
文入力部１０は利用者からの入力文は取り込み、文理解部２０に送る。文理解部２０は、利用者の問い合わせの内容を生成する。いま、誤認識などの理由により、「神奈川県」は「香川県」と誤って認識され、「警報」は全く認識されなかったとする。この場合、文理解剖１１０が生成する問い合せの内容は、次のようになる。
｛＜場所，香川県＞｝
【００５２】
この時点では、利用者が承認している属性は存在しない。提供情報種別決定部３０は、この問い合せ内容から判断して、提供情報種別として警報と天気の２つを生成する。それぞれの提供情報種別の確率は等確率であると仮定し、警報の確率が０．５、天気の確率が０．５であるとする。
【００５３】
この時点で利用者により承認されていない属性は、場所、情報種別である。対話手順生成部４０は、警報と天気という２つの提供情報種別のそれぞれに関して、すべての対話手順を生成する。
ここでは、警報という提供情報種別に関しては、２つの対話手順、対話手順Ａと対話手順Ｂが生成されたとする。対話手順Ａは、利用者側の承認が入力されるまで場所と情報種別という２つの属性を両方ともに確認し、その後、利用者が承認した場所に警報は出ていませんという内容の１個の応答文を生成するという対話手順である。対話手順Ｂは、利用者側の承認が入力されるまで場所と情報種別という１つの属性を確認し、その後、どこにも警報は出ていませんという内容の１個の応答文を生成する対話手順である。
天気という提供情報種別に関しては、２つの対話手順、対話手順Ｃと対話手順Ｄが生成されたとする。対話手順Ｃは、利用者の承認が入力されるまで場所を確認し、次に、利用者の承認が入力されるまで情報種別を確認し、次に応答するという対話手順である。対話手順Ｄは、利用者の承認が入力されるまで情報種別を確認し、次に、利用者の承認が入力されるまで場所を確認し、次に、応答するという対話手順である。
【００５４】
対話コスト計算部６０は、対話手順Ａ、Ｂ、Ｃ、Ｄの対話コストを計算する。対話コストを計算するに際して、ここでは、確認文の個数は、確認する属性の数の２倍であると推定されると仮定する。
対話手順Ａでは、場所と情報種別という２個の属性を利用者から承認が入力されるまで確認する際に出力される確認文の個数は、４個と推定される。情報提供側が承認すると、「神奈川県の警報ですか」と確認文を出力し、利用者はこの確認を承認し、「神奈川県に警報は出ていません」という応答文が１個出力される。対話コストは、確認文と応答文の個数の総和の５となる。
対話手順Ｂでは、最初、「警報ですか」という確認文が出力される。情報種別という１個の属性を利用者からの承認が入力されるまで確認する際に出力される確認文の個数は、２個と推定される。利用者は確認を承認すると、「どこにも警報は出ていません」という１個の応答文が生成されることになる。対話コストは、確認文と応答文の個数の総和の３となる。
対話手順Ｃ、Ｄでは、１個の属性を確認することを２回行うわけだから、確認文の個数は、４個の推定される。応答文は、ある場所のある時間の天気は何であるという文１個によって生成されるとする。対話コストは、確認文と応答文の個数の総和の５となる。
【００５５】
次に、最適対話手順決定部７０が、警報と天気という２つの提供情報種別のそれぞれに関して、最適対話手順と最適コストを決定する。警報という提供情報種別に関しては、最適対話手順は対話手順Ｂであり、最適コストは３となる。天気という提供情報種別に関しては、最適対話手順は対話手順ＣとＤであり、最適コストは５となる。
【００５６】
次に、制御部１３０は、利用者が承認していない属性のそれぞれに関して、属性の確認のための準最適対話手順と準最適コストを提供情報種別ごとに計算するように、準最適対話手順計算部８０に命じる。利用者が承認していない属性属性は、情報種別と場所という２つの属性である。
第一に、情報種別という属性を確認するための準最適対話手順についての処理を示す。警報という提供情報種別に関しては、情報種別を確認するための最適対話手順Ｂであり、準最適コストは３となる。天気という提供情報種別に関しては、情報種別を確認するための最適対話手順Ｄであり、準最適コストは５となる。
【００５７】
第二に、場所という属性を確認するための準最適対話手順についての処理を示す。警報という提供情報種別に関しては、場所を確認するための最適対話手順Ａであり、準最適コストは５となる。天気という提供情報種別に関しては、場所を確認するための最適対話手順Ｃであり、準最適コストは５となる。
【００５８】
次に、損失計算部９０は、属性の確認による損失を提供情報種別ごとに計算する。
第一に、情報種別という属性の確認による損失の計算を示す。情報種別の確認による損失は、警報という提供情報種別に関しては、準最適コストの３から最適コストの３を減じて、０となる。天気という提供情報種別に関しては、準最適コストの５から最適コストの５を減じて、０となる。
第二に、場所という属性の確認による損失の計算を示す。場所の確認による損失は、警報という提供情報種別に関しては、準最適コストの５から最適コストの３を減じて、２となる。天気という提供情報種別に関しては、準最適コストの５から最適コストの５を減じて、０となる。
【００５９】
次に、期待損失計算部１００は、提供情報種別の確率を考慮して、各属性の確認による損失の期待値を計算する。警報、天気という２つの提供情報種別の確率は、ともに０．５である。したがって、情報種別という属性による期待損失は０となり、場所という属性の確認による期待損失は１となる。
【００６０】
次に、確認属性決定部１１０は、期待損失がより小さくなる情報種別という属性を確認属性として決定する。文出力部１２０は、「警報ですか」とか、「天気それとも警報ですか」という確認文を出力する。
【００６１】
情報種別という属性の確認による期待損失は、場所という属性の確認による期待損失よりも小さいので、「香川県ですか」といった場所の確認を要求するための確認文を出力するよりも、「天気それとも警報ですか」といった情報種別の確認を要求するための確認文を出力するほうが、対話コストを小さく保つことができ、利用者に対し確認文と応答文の個数の増大に伴う利用者の不満度の増大を避けることができる。
【００６２】
以上、本発明の一実施の形態について説明したが、本発明は、上記の実施例に限定されることなく、種々の変更あるいは応用が可能であることは云うまでもない。
【００６３】
【発明の効果】
以上説明したように、本発明の対話型情報提供サービスによれば、利用者が情報の問い合せを意味する文を文字列または音声として入力するときに、利用者によって承認されていない問い合せ内容に含まれる各属性に関して、属性の確認による期待損失を計算し、期待損失が極小になるような属性を優先して確認することにより、誤認識などによって生じる利用者に対し出力される確認文と応答文の個数の増大に伴う利用者の不満足度の増大を避けることが可能となる。
【図面の簡単な説明】
【図１】本発明の装置構成例を示すブロック図である。
【図２】本発明の一実施例の処理フローチャートである。
【符号の説明】
１０ 文入力部
２０ 文理解部
３０ 提供情報種別決定部
４０ 対話手順生成部
５０ データベース
６０ 対話コスト計算部
７０ 最適対話手順決定部
８０ 準最適対話手順決定部
９０ 損失計算部
１００ 期待損失計算部
１１０ 確認属性決定部
１２０ 文出力部
１３０ 制御部

Claims (6)

1. 利用者側が情報の問い合せを意味する文を入力すると、利用者側に対し問い合せの内容の確認を求めるための確認文を出力し、利用者側が確認の承認を意味する文を入力すると、利用者により承認された問合せの内容を記録し、利用者が確認の否認を意味する文を入力する場合には、利用者が新たな情報の問合せを意味する文を入力するのを待ち、利用者に提供すべき情報種別が一意に決定できた後に、利用者により承認された問い合せの内容にしたがって情報を提供するための応答文を利用者側に対し出力する対話型情報提供装置であって、
   利用者側からの情報の問い合せ、確認の承認、確認の否認を受け取る入力手段と、
   利用者側が情報の問い合せを意味する文を入力する場合は、該入力された文の内容と該文が入力された時点で記録されている利用者の問い合せ内容から判断して、利用者の問い合わせ内容を表す属性と値の組の集合を生成し、該属性と値の組の集合を利用者の問い合せ内容として記録し、属性の確認を求める確認文に対し利用者が確認の承認を意味する文を入力すると、該属性を利用者により承認された問い合せ内容として記録する文理解手段と、
   利用者により入力された問い合わせの内容と利用者により承認された問い合せ内容から判断して、利用者に提供することが可能なすべての情報の種別を提供情報種別として決定するとともに、提供情報種別の確率を計算する提供情報種別決定手段と、
   提供情報種別の各々に関して、利用者によって承認されていない問い合せの内容を構成する属性の全て或いは一部の確認を求め、利用者が確認を承認した後に、利用者側により承認されている問合せの内容にしたがって情報を提供するという対話手順と、確認を行わないで、該問い合せの内容にしたがって情報を提供するという対話手順を生成する対話手順生成手段と、
   各々の対話手順に関して、対話手順に含まれる確認文と応答文の個数の総和を推定し、推定された総和を対話コストとして計算する対話コスト計算手段と、
   提供情報種別の各々に関して、極小の対話コストをもつ対話手順を選択し、該極小の対話コストをもつ対話手順を最適対話手順とし、該極小の対話コストを最適コストとする最適対話手順決定手段と、
   提供情報種別の各々に関して、指定された属性の確認を最初に求める対話手順を選び出し、該対話手順の中で極小の対話コストをもつ対話手順を選び、属性の確認のための準最適対話手順とし、該極小の対話コストを属性の確認のための準最適コストとする準最適対話手順決定手段と、
   提供情報種別の各々に関して、前記準最適コストから前記最適コストを減じ、減算結果の数を属性の確認による損失とする損失計算手段と、
   提供情報種別の各々に関する前記属性の確認による損失から、提供情報種別の確率を考慮した損失の期待値を計算し、該期待値を属性の確認による期待損失とする期待損失計算手段と、
   利用者に承認されていない問い合せの内容に含まれる属性の各々に関して、各属性の確認による期待損失を比較し、極小の期待損失をもつ属性を選択し、該属性を確認属性として決定する確認属性決定手段と、
   前記決定された確認属性の確認を求めるための確認文を利用者側に対し出力する出力手段と、
   を有することを特徴とする対話型情報提供装置。
2. 請求項１記載の対話型情報提供装置において、最適コスト対話手順として、確認を行わないで応答文を出力する対話手順が存在するならば、確認を行う必要がないと判断して、該対話手順にしたがって応答文を出力することを特徴とする対話型情報提供装置。
3. 利用者側が情報の問い合せを意味する文を入力すると、利用者側に対し問い合せの内容の確認を求めるための確認文を出力し、利用者側が確認の承認を意味する文を入力すると、利用者により承認された問合せの内容を記録し、利用者が確認の否認を意味する文を入力する場合には、利用者が新たな情報の問合せを意味する文を入力するのを待ち、利用者に提供すべき情報種別が一意に決定できた後に、利用者により承認された問い合せの内容にしたがって情報を提供するための応答文を利用者側に対し出力する対話型情報提供処理方法であって、
   利用者側から情報の問い合せを意味する文を入力するステップと、
   入力された情報の問い合わせを意味する文の内容と該文が入力された時点で記録されている利用者の問い合せ内容から判断して、利用者の問い合わせ内容を表す属性と値の組の集合を生成し、該属性と値の組の集合を利用者の問い合せ内容として記録するステップと、
   利用者により入力された問い合わせの内容から、利用者に提供することが可能なすべての情報の種別を提供情報種別として決定するとともに、提供情報種別の確率を計算するステップと、
   提供情報種別の各々に関して、問い合せの内容を構成する属性の全て或いは一部の確認を求め、利用者が確認を承認した後に、問合せの内容にしたがって情報を提供するという対話手順と、確認を行わないで、該問い合せの内容にしたがって情報を提供するという対話手順を生成するステップと、
   各々の対話手順に関して、対話手順に含まれる確認文と応答文の個数の総和を推定し、推定された総和を対話コストとして計算するステップと、
   提供情報種別の各々に関して、極小の対話コストをもつ対話手順を選択し、該極小の対話コストをもつ対話手順を最適対話手順とし、該極小の対話コストを最適コストするステップと、
   提供情報種別の各々に関して、指定された属性の確認を最初に求める対話手順を選び出し、該対話手順の中で極小の対話コストをもつ対話手順を選び、属性の確認のための準最適対話手順とし、該極小の対話コストを属性の確認のための準最適コストとするステップと、
   提供情報種別の各々に関して、前記準最適コストから前記最適コストを減じ、減算結果の数を属性の確認による損失とするステップと、
   提供情報種別の各々に関する前記属性の確認による損失から、提供情報種別の確率を考慮した損失の期待値を計算し、該期待値を属性の確認による期待損失とするステップと、
   問い合せの内容に含まれる属性の各々に関して、各属性の確認による期待損失を比較し、極小の期待損失をもつ属性を選択し、該属性を確認属性として決定するステップと、
   前記決定された確認属性の確認を求めるための確認文を利用者側に対し出力するステップと、
   を有することを特徴とする対話型情報提供処理方法。
4. 請求項３記載の対話型情報提供処理方法において、最適コスト対話手順として、確認を行わないで応答文を出力する対話手順が存在するならば、確認を行う必要がないと判断して、該対話手順にしたがって応答文を出力することを特徴とする対話型情報提供処理方法。
5. 請求項３ないし４記載の対話型情報提供処理方法をコンピュータで実行させるためのプログラム。
6. 請求項３ないし４記載の対話型情報提供処理方法をコンピュータで実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images