JP2018185565A - 対話システム、対話方法及び対話プログラム - Google Patents

Abstract

【課題】ユーザの対話による要求に対して、ユーザに推薦したい候補をユーザが不満に感じない程度に積極的に推薦する。【解決手段】対話システムは、検索対話で参照するデータベースの検索対象の中でユーザに推薦したい候補があり、ユーザとの対話中で得られている条件でデータベースを検索し、その検索結果にユーザに推薦したい候補が含まれていた場合に、検索結果の件数やユーザがそれまでにシステムに伝えた条件の数の少なくとも一つを用いて、ユーザに推薦したい候補を提示する応答の振る舞いを行うか否かを判断することにより、ユーザに推薦したい候補をユーザが不満に感じない程度に積極的に推薦可能となるようにする。【選択図】図１

Description

本発明の実施形態は、対話システム、対話方法及び対話プログラムに関する。

近年、ユーザとの対話によって条件に合致する候補を絞り込んで、最終的にユーザが求めているものを提示する対話システムが普及されつつある。このような検索対話を行う対話システムは、例えばショッピングセンターにおける店舗案内、飲食店の案内、旅行先の案内など様々な場面に適用される。

ところで、上記検索対話による対話システムでは、ユーザとの対話において、絞り込みの条件を聞いたり、ユーザに条件に合う候補を提示したりするなどの振る舞い（システムの動作を意味する）だけでなく、推薦したい候補をユーザに積極的に提示する振る舞いも重要になるケースがある。例えばショッピングセンターの店舗案内において、「開店したばかり」、「セール商品がある」、「新作が出た」などの理由でショッピングセンターの運営者が推薦したい店舗が存在する場合に、推薦候補の積極的な提示は、もともとその店舗に行く予定の無かったユーザが訪れるきっかけとなり、ショッピングセンター全体の売り上げ向上につながるメリットがあると考えられる。

これに対して、従来の対話システムでは、検索結果の件数やユーザの好み、過去の対話履歴などからユーザに対する振る舞いを決定するものがあるが、推薦したい候補が検索結果に入っているか否かに応じてユーザへの振る舞いを制御することはできなかった。

一方、検索結果の中に推薦したい候補が含まれているからといって常に推薦したい候補を積極的に提示すると、ユーザにとって満足度が低くなってしまう可能性が高い。すなわち、積極的に提示された候補に対してユーザが興味を示さなかった場合は、さらに条件を追加して絞り込んでいく対話を行うことになるが、絞り込んだ条件で検索した結果、推薦したい候補が含まれているのであれば、絞り込むたびに推薦したい候補を積極的にユーザに提示することになる。これが繰り返されるとユーザとの対話の流れが悪くなり、ユーザにとって不要な候補を押しつけがましく推薦することになる。その結果、最終的に目的の候補を見つけられたとしても、ユーザは対話による振る舞いに不満を持つと考えられる。

そこで、対話システムでは、推薦したい候補の積極的な提示をユーザが不満に感じない程度に制御する必要がある。これに対して、従来の対話システムでは、推薦したい候補を検索結果の上位に出力することで積極的にユーザに提示する場合もあるが、ユーザが不満に感じないように推薦したい候補をユーザに提示するタイミングを制御することはできなかった。

特開２００２−９９４０４号公報

以上のように、従来の対話システムでは、推薦したい候補が検索結果に入っているか否かに応じてユーザへの振る舞いを制御することはできなかった。また、ユーザが不満に感じないように推薦したい候補をユーザに提示するタイミングを制御することはできなかった。

本実施形態は上記課題に鑑みなされたもので、検索結果にユーザに推薦したい候補が含まれていた場合に、その推薦したい候補をユーザが不満に感じない程度に積極的に提示することのできる対話システム、対話方法および対話プログラムを提供することを目的とする。

一実施形態に係る対話システムは、データベースと、制御部とを備える。データベースには、複数の検索の対象が、推薦候補の対象か否かを示す推薦候補情報と組みにして保存される。制御部は、ユーザとの対話による入力情報に基づいて検索条件を設定し、前記データベースから前記検索条件に合う対象を検索し、前記検索した対象と組となっている前記推薦候補情報から、前記検索した対象の中に推薦候補の対象が含まれるか判断し、前記推薦候補の対象が含まれていないと判断した場合に、前記検索した結果に基づいて前記ユーザに対する動作を決定し、前記推薦候補の対象が含まれていると判断した場合に、前記検索した対象の数または前記ユーザとの対話の入力数の少なくとも一つに基づいて前記推薦候補の対象をユーザに提示する動作の是非を決定し、決定された動作に対応する応答処理を実行する。

本実施形態は、対話システム、対話方法および対話プログラムに係わり、特に検索対話で参照するデータベースの検索対象の中でユーザに推薦したい候補があり、ユーザとの対話中で得られている条件でデータベースを検索し、その検索結果にユーザに推薦したい候補が含まれていた場合に、検索結果の件数やユーザがそれまでにシステムに伝えた条件の数の少なくとも一つを用いて、ユーザに推薦したい候補を提示する動作を行うか否かを判断することにより、ユーザに推薦したい候補をユーザが不満に感じない程度に積極的に推薦可能となるようにした。この結果、ユーザに推薦したい候補をユーザが不満に感じない程度に積極的に推薦することが可能となる。

第１の実施形態に係る対話システムの構成を示すブロック図。 第１の実施形態に係る対話システムの動作を示すフローチャート。 第１の実施形態において、推薦候補情報管理部が付加された対話システムの構成を示すブロック図。 第１の実施形態に係る対話システムの動作例で参照するデータベースを示す図。 第１の実施形態に係る対話システムの第１の動作例を示す図。 第１の実施形態に係る対話システムの第２の動作例を示す図。 第１の実施形態に係る対話システムの第３の動作例を示す図。 第２の実施形態に係る対話システムの構成を示すブロック図。 第２の実施形態に係る対話システムの動作を示すフローチャート。 第２の実施形態に係る対話システムの動作例で参照するデータベースを示す図。 第２の実施形態に係る対話システムの第１の動作例を示す図。 第２の実施形態に係る対話システムの第２の動作例を示す図。 図１及び図８に示した対話システムに適用可能なコンピュータ装置の基本的な構成を示すブロック図。

以下、本発明に係る実施形態について、図面を参照して説明する。
（第１の実施形態）
図１は、本発明の第１の実施形態に係わる対話システムを示すブロック図である。
この第１の実施形態に係る対話システム１００は、発話理解部１０１と、検索部１０２と、推薦判断部１０４を含む対話制御部（true-false）１０３と、応答生成部１０５と、検索データベース（true-false）（以下、ＤＢ）１０６とを備える。

発話理解部１０１は、ユーザによって入力された文章（以下、入力文）を解析してユーザの意図、検索条件を推定する。推定した検索条件は、検索部１０２に送られ、同時にユーザの意図に関する情報と共に対話制御部１０４に送られる。
ここで、上記入力文は、ユーザの発話を音声認識しテキストに変換して入力するが、ユーザがキーボードを操作して入力する場合など、他の入力処理が行われたものでもよい。

また、上記「ユーザの意図」を表現する形としては、発話タグとスロットの組が挙げられる。発話タグは、その入力文において、ユーザがシステムに対して伝えている大まかな振る舞いをタグとして表現したもので、例えば情報を伝達している（Inform）、情報を確認している（Confirm）、システムの質問に対して肯定（Affirm）・否定（Negate）している、などが挙げられる。もう少し具体的に「レストランを探したい（Inform-search-restaurant）」、「ホテルを探したい（Inform-search-hotel）」といった内容をタグ化してもよい。スロットは入力文内に含まれる対話の処理に必要な情報のことで、［スロット名（値の属性）＝値］の形で表現される。例えば「安いバッグが買いたい」という入力文の場合、［値段＝安め］、［商品＝バッグ］というスロットが抽出される。発話タグやスロットを推定する手法としては、キーワードマッチングによる推定の他、形態素解析をした結果を特徴量として用いて、予め学習しておいたモデルで統計的に推定するようにしてもよい。統計的手法には、最大エントロピー法、ニューラルネットワークなど様々な手法が適用できる。

また、上記「検索条件」を表現する形としては、検索ＤＢ１０６のスキーマにも依存するが、例えばスロットと同様に、［条件（値の属性）＝値］の形が挙げられる。推定する際は、以前に入力された検索条件も記録しておき、特にその条件に関して言及がない場合は値を引き継ぐ、消すように入力された場合は値を消去するなどの処理が必要である。検索条件の推定もキーワードマッチングや統計的手法による条件値抽出と上記のような引き継ぎ処理をルールで記述し組み合わせる方法、条件値抽出と引き継ぎ処理をまとめて統計的手法によって推定する方法などが考えられる。

また、ユーザの入力文は、発話、キーボードによる直接入力の他、ＧＵＩ（Graphical User Interface）のタッチ情報などの操作情報であってもよい。その際は、操作情報からユーザの意図や検索条件を推定する処理が必要となる。この推定は、一般的にルールベースで行われる。

検索部１０２は、発話理解部１０１で得られた検索条件に基づいて検索ＤＢ１０６を検索する。検索ＤＢ１０６には、予め複数の検索対象が推薦候補の対象か否かを示す推薦候補情報と組みにして保存されている。検索ＤＢ１０６で用いるＤＢの種類や検索部１０２の検索方法に特に制限はなく、種々の形態で実現してもよい。検索結果は対話制御部１０３に送られる。

対話制御部１０３は、検索部１０２で得られた検索結果に基づいてユーザに対する処理動作である「振る舞い」を決定する。この「振る舞い」とは、ユーザとの対話における応答などの処理動作をタグやスロットなどの形で表現したもので、例えばRequest（商品）（希望する商品をユーザに確認する）、Offer（店舗名＝Ａストア）（Ａストアをユーザの希望する店舗として提示する）などと表現される。振る舞いの決定方法については後述する。決定された振る舞いは応答生成部１０５に送られる。

ここで、対話制御部１０３は、推薦判断部１０４において、検索部１０２で検索された対象に付与されている推薦候補情報を参照して、検索結果の中にユーザに推薦したい候補が含まれているか否かを判断する。この判断で、推薦したい候補が含まれていなかった場合には、検索結果に基づいてユーザに対する振る舞いを決定する。また、推薦したい候補が含まれていた場合には、検索結果の件数やユーザが対話中に入力した検索条件の数の少なくとも１つを用いて、ユーザに推薦したい候補を提示する振る舞いを行うか否かを判断する。この判断は、対話制御部１０３で振る舞いを決定している際に、同時にまたは振る舞いの決定に組み込まれる形で行われる。判断方法については後述する。

応答生成部１０５は、対話制御部１０３で決定された振る舞いに基づいてユーザに提示する応答文を生成する。応答文の生成方法としては、振る舞いそれぞれに対応する応答文を予め用意しておく方法、一部空欄のある応答文を用意しておき、振る舞いのスロットに含まれる単語をその空欄に当て嵌めて応答文を完成させる方法、振る舞いに対応する応答文を事前に大量に集めておき、統計的手法によって応答文生成モデルを学習し、そのモデルによって対話制御部１０３で得られた振る舞いに対する応答文を生成する手法などが考えられる。応答文の他にも検索結果などの情報を生成してユーザに提示してもよい。また、応答文を音声合成することによって、音声でユーザに提示してもよい。

次に、図２を用いて、第１の実施形態に係る対話システムの動作について説明する。図２は、第１の実施形態に係る対話システムの動作を示すフローチャートである。
まず、対話システムは、発話理解部１０１において、ユーザからの入力文を解析し、ユーザの意図や検索条件を推定する（ステップＳ１０１）。次に、検索部１０２において、ステップＳ１０１で得られた検索条件に基づいて検索ＤＢ１０６を検索する（ステップＳ１０２）。次に、対話制御部１０３において、検索結果の中にユーザに推薦したい候補が含まれているかを判定する（ステップＳ１０３）。

ここで、推薦したい候補であるという情報（以下、推薦候補情報）は、検索ＤＢ１０６に予め含まれるようにしてもよいし、検索した後の検索結果の候補に対して検索部１０２や対話制御部１０３で付与するようにしてもよい。また、推薦したい候補とする基準は、管理者が予め定めておくようにしてもよいし、検索結果の候補に含まれる情報と経過時間や今までユーザから入力された検索条件などに応じて動的に決めるようにしてもよい。例えばショッピングセンターにおいてタイムセールがある店舗は、タイムセールの時間帯だけ推薦したい候補としておくなどが考えられる。他にも、例えば旅行案内では、ユーザが希望した旅行日程で割引プランがある旅行プラン、お祭りなどその時期限定のイベントがある旅行先などを推薦したい候補としておくなども考えられる。

検索ＤＢ１０６に推薦候補情報を予め含めておく場合には、管理者による修正や時間が経過することによる推薦したい候補の変更を可能とする必要がある。この場合、図３に示すように推薦候補情報管理部１０７を用意しておき、検索処理とは非同期で、推薦候補情報管理部１０７によって、検索ＤＢ１０６に保存される検索対象の推薦候補情報あるいは検索結果の任意の候補の推薦候補情報を変更できるようにしておくと、推薦候補の管理を柔軟に対処することが可能になる。

ステップＳ１０３において、検索結果に推薦したい候補が含まれていない場合（Ｎｏ）、対話制御部１０３では、推薦したい候補を提示する振る舞いを振る舞いの候補に含めない状態で振る舞いの決定を行う（ステップＳ１０４）。
ここで、振る舞いの決定方法としては、対話状態という対話の進行状況を表す情報を用意し、対話状態とユーザの意図などからどの振る舞いを行うかをルールベースで決定する方法がまず考えられる。ただし、この方法は対話状態とユーザの意図などからどの振る舞いを行うかのルールを作成するのにコストがかかる上、そのルールによる振る舞いが最適であるか否かの保証がなされない。特に発話理解部１０１で統計的手法によって入力文の解析が行われ、ユーザの意図や検索条件、ひいては対話状態も確率的に出力されるようになった場合、その確率値を加味してルールを作成するのは非常に困難である。そのため、近年統計的に振る舞いを決定する方法が存在する。

統計的な手法としては、強化学習が挙げられる。強化学習では、対話がユーザの要望した通りに動作したか否かに応じて正や負の報酬を与えるようにしておき、発話理解部１０１や検索部１０２で得られたある入力文の解析結果、検索結果のときにどの振る舞いを選択すると最終的にどれくらい報酬がもらえそうかを試行錯誤によって学習する。実際に、対話を行う際は、学習して得られた振る舞い決定モデルを用いて、ある入力文の解析結果、検索結果のときに最終的に一番報酬がもらえそうな振る舞いを選択する。これにより、管理者がルールを作成するコストを解消し、また設計した報酬の下での最適な振る舞いが行える。どの振る舞いがよいかを決定する際に、入力特徴量として用いる入力文の解析結果、検索結果の情報としては、例えばユーザの意図とその確率値、検索条件で埋まっている条件や埋まっていない条件、埋まっている条件の値の確率値、検索結果の件数など、種々の情報を利用可能である。

報酬の与え方は、具体的にはユーザの最終的な目的が達成されたときだけ大きい正の報酬を与え、それ以外は小さい負の報酬を与える方法がある。これに加え、検索結果の提示をしたときに検索結果が多いほど大きい負の報酬を与えるようにしてもよい。これにより、検索結果が多いときは検索結果を提示する振る舞いを抑えることができる。

ステップＳ１０３において、検索結果に推薦したい候補が含まれている場合（Ｙｅｓ）、推薦判断部１０４を含む対話制御部１０３では、推薦したい候補を提示する振る舞いも振る舞いの候補に含めた状態で、どの振る舞いがよいかの振る舞い決定を行う（ステップＳ１０５）。この際、推薦したい候補を提示する振る舞いを、通常の検索条件に合う候補を提示する振る舞いと差し替える形で振る舞い決定の候補にしてもよいし、共存する形にしてもよい。

ステップＳ１０５において、推薦したい候補を提示する振る舞いを行うかどうか判断する際に、ユーザが不満を感じないようにするためには、推薦したい候補を提示するタイミングがユーザにとってまだ条件の絞り込みをしたいとは強くは思わないタイミングであることが重要である。そこで、推薦したい候補を提示する振る舞いを行うかどうかの判断には、検索結果の件数またはユーザが入力した検索条件の数の少なくとも１つを利用する。これは、ある程度の件数まで絞り込まれたとき、またはある程度条件を伝えたときは、ユーザはこれ以上絞り込もうと思わないことが多いためである。

検索結果の件数または検索条件の数の少なくとも１つの情報を利用して推薦したい候補を提示する振る舞いを行うかどうかの判断を行う方法としては、閾値を事前に設定しておき、閾値以下の検索件数、または閾値以上の検索条件数になった際に推薦したい候補を提示するといったルールベースによる判断をしてもよい。この判断の方法でも強化学習を活用することができる。ステップＳ１０４で示した強化学習の報酬設定に加え、推薦したい候補がユーザに受け入れられた場合に大きな正の報酬が付与され、受け入れられなかった場合に負の報酬が付与されるように設定しておく。そして、検索件数、検索条件数の少なくとも１つを振る舞いを決定する際の入力特徴量として用いることで、振る舞い決定モデルを学習する。さらに、実際の対話の際も、上述した入力特徴量と振る舞い決定モデルにより各振る舞いの最終的にもらえる報酬期待値を計算し、最終的にもらえる報酬期待値が最も高い振る舞いを選択する。これにより、強化学習を活用した振る舞いの決定処理が実現可能である。なお、振る舞いを決定する際の入力特徴量には、ステップＳ１０４で示した種々の情報を同時に利用してよい。

さらに、強化学習の場合は、ステップＳ１０４とステップＳ１０５の判断を一つの強化学習のモデルで実現可能である。これはステップＳ１０５に示した報酬設定を用い、振る舞いの決定に用いる入力特徴量に検索結果の中に推薦したい候補が含まれているかどうかの情報を追加することによって実現可能である。この場合、図２のステップＳ１０３、Ｓ１０４、Ｓ１０５が一つのステップ「振る舞い決定処理を実施」に統合されることになる。

最後に、応答生成部１０５において、対話制御部１０３で決定された振る舞いに基づいて応答文を生成する（ステップＳ１０６）。この応答文に対してユーザが更に入力文を入力すると、ステップＳ１０１から再び処理を実行することになり、対話が進んでいく。

次に、図４〜図７において、対話システム１００が実際にユーザに不満に感じない程度に積極的に推薦したい候補を提示する動作例を示す。この例は、ショッピングセンターにおいて、対話を通じてユーザが買いたい商品や希望の価格帯などを伝えると、その条件に合うショッピングセンター内の店舗を提示する案内システムを想定している。振る舞いの決定には、強化学習により作られた振る舞い決定モデルを用いることを想定する。

図４は、検索ＤＢ１０６に格納される、推薦候補情報が付与されたショッピングセンターの店舗に関するＤＢを表している。推薦したい店舗は「推薦候補」フィールドの値がtrueとなっている。推薦したい店舗の指定はショッピングセンターの管理者が行うケースがまず考えられる。この際、店舗それぞれに対応するチェックボックスを用意しておく。例えば、チェックボックスにチェックを入力すると、推薦候補の店舗となるなど、ＧＵＩを用いて推薦したい候補の指定を行ってもよい。別のケースとしては、店舗の情報そのものや店舗の情報と時間などを紐づけて推薦したい店舗を決定することも考えられる。例えばセールを行っている期間、時間帯だけその店舗を推薦候補の店舗とする、商品の在庫が多く残っている店舗を推薦候補の店舗とする、などである。これらの店舗の情報の登録はショッピングセンターの管理者が行ってもよいが、各店舗の責任者（店員等）がそれぞれ自分の店舗の情報を登録できるようにしてもよい。また、在庫数の確認は、別途在庫管理システムを用意し、そのシステムが自動的に行うようにしてもよい。セールの中でも、平均割引率がある閾値以上の店舗、在庫数がある閾値以上の店舗だけに推薦したい候補を限定してもよい。その際、閾値の設定はショッピングセンターの管理者が行う、推薦したい候補の数がある一定の数になるよう自動的に調整する、などが考えられる。

図５は、第１の実施形態に係る対話システムの第１の動作例を示しており、（ａ）はシステムとユーザとの対話例、（ｂ）は対話から抽出される条件に基づいて検索した振る舞い決定に用いる情報及び振る舞い決定モデルに基づいて求められる報酬期待値計算結果を示し、（ｃ）は報酬期待値計算結果から条件に合う候補を選択してＧＵＩに表示する例を示している。

この第１の動作例は、対話システムが、ユーザとの対話から抽出した条件に基づいてＤＢの検索を行ったが、ユーザの希望する条件には推薦したい候補が含まれなかった場合（推薦公報の有無＝false）を想定し、ユーザの発話を入力毎に解析し、その解析によって得られた検索条件により検索を行い、その検索結果などから「振る舞い決定に用いる情報」を設定する。そして、この振る舞い決定に用いる情報と振る舞い決定モデルを用いて、各振る舞い（問い合わせ、確認、提示）における最終的に貰える報酬の期待値を計算する。

すなわち、ユーザの最初の２回の発話に対しては、検索件数が多いなどの影響により、ユーザに追加の条件を聞く「問い合わせ」の振る舞いが最も報酬の期待値が大きい。このため、「問い合わせ」を選択して出力する。続くユーザの３回目の発話に対しては、検索条件に合う候補をユーザに提示する「提示」の振る舞いが最も報酬の期待値が大きい。このため、ユーザに「検索条件に合う候補の提示」を応答内容として出力する。

ここで、図５に示す例では、振る舞い決定に用いる情報を「推薦候補の有無」、「検索件数」、「入力条件数」としているが、実際は「ユーザの意図」や「検索条件の推定確率」など様々な情報を利用することができる。例えば「検索条件の推定確率」が低い場合は、その推定した条件値が正しいか確認する「確認」の振る舞いが最も報酬期待値が高くなる振る舞い決定モデルを設定することが考えられる。振る舞いの種類も、図５に示す例では、「問い合わせ」「提示」「確認」の３種類であるが、
聞き返しを行う 、
複数の条件値を提示してユーザに選ばせる
などの行動を追加してよい。また、条件に合う候補を提示する段階でその店舗のリストをＧＵＩ上に表示しているが、絞り込みを行っている際もそこまでの検索条件で得られる店舗のリストを表示してもよい。

図６は、第１の実施形態に係る対話補システムの第２の動作例を示しており、（ａ）はシステムとユーザとの対話例、（ｂ）は対話から抽出される条件に基づいて検索した振る舞い決定に用いる情報及び振る舞い決定モデルに基づいて求められる報酬期待値計算結果、（ｃ）は報酬期待値計算結果から条件に合う候補を選択してＧＵＩに表示する例を示している。

この第２の動作例は、対話システムが、ユーザとの対話から抽出した条件に基づいてＤＢの検索を行った結果、ユーザの希望する条件に推薦したい候補が含まれていた場合（推薦公報の有無＝true）を想定し、ユーザの発話を入力毎に解析し、その解析によって得られた検索条件により検索を行い、その検索結果などから「振る舞い決定に用いる情報」を設定する。そして、この振る舞い決定に用いる情報と振る舞い決定モデルを用いて、各振る舞い（問い合わせ、推薦、確認）における最終的に貰える報酬の期待値を計算する。

この例では、ユーザの最初の発話に対しては、検索件数が多いなどの影響により、ユーザに追加の条件を聞く「問い合わせ」の振る舞いが最も報酬の期待値が大きい。このため、「問い合わせ」を選択して出力する。続くユーザの２回目の発話に対しては、検索件数が絞り込まれ、推薦候補の有無がtrueとなっていることから、「推薦」の振る舞いが最も報酬の期待値が大きい。このため、ユーザに「推薦したい候補の提示」を応答内容として出力する。

すなわち、ユーザの希望する条件で検索した結果推薦したい候補が含まれていた場合、振る舞い決定の用いる情報のうち推薦候補の有無に関する情報が変化することにより、報酬期待値の計算結果も変化して振る舞いも変わっている。具体的には、ユーザの２回目の発話を解析して得られた検索条件によって、検索した結果検索件数や入力条件数は図５の２回目の発話のときと変わりないが、ユーザに推薦したい候補が含まれていることにより、「問い合わせ」ではなく「推薦」の振る舞いが最適となっている。このため、条件に合う店舗のリストの提示と共に推薦したい候補を明確に推薦する応答文を出力する。これにより、ユーザに推薦したい候補が含まれているときに提示する振る舞いが、ユーザに推薦したい候補が含まれていないときよりも早めに選択され、積極的にユーザに推薦したい候補を提示する対話が実現できる。また、ユーザの１回目の発話のときのように、あまりにも検索件数が多い場合は推薦したい候補を提示する振る舞いは行わないようになっている。このことから、まだ絞り込みたいとユーザが感じているのに推薦候補が提示されてしまうことでユーザがシステムに対して不満を感じるという問題は解消され、適切なタイミングで推薦したい候補を提示できている。

なお、図６の例のように、推薦したい候補を提示する応答文をユーザに見せる際に、推薦したい店舗がなぜお勧めなのかを合わせて応答文に含めてもよい。このようにすることで、ユーザはよりその店舗に興味を持ち、実際にその店舗へ行く可能性が高くなると考えられる。また、検索結果の中に推薦したい候補が複数含まれている場合、応答文ではそのうちの１つの店舗をまずはユーザに提示してもよいし、全ての店舗をまとめてユーザに提示してもよい。また、例えば「ＢショップとＦストアはタイムセール中、Ｇマートは新装開店のセール中でお勧めですよ」などのように、応答文に推薦したい候補それぞれの店舗にお勧めの理由を添えてユーザに提示してもよい。

ＧＵＩ上で表示する条件に合う店舗のリストに関しても、図６（ｃ）に示すように、推薦したい候補を他の候補よりも先に配置して更に目に付くようなマークをつけたり、または他の候補が表示される場所とは別の目立つ場所に表示したりするようにしてもよい。複数の推薦したい候補があった場合は、その全てにマークをつけるようにしてもよい。このような表示方法は、応答文としてユーザの推薦したい候補を提示するとき以外の「問い合わせ」などの振る舞いをしているときでも、現在の検索条件で得られる検索結果に基づいて行ってもよい。

図７は第１の実施形態に係る対話補システムの第３の動作例を示しており、（ａ）はシステムとユーザとの対話例、（ｂ）は対話から抽出される条件に基づいて検索した振る舞い決定に用いる情報及び振る舞い決定モデルに基づいて求められる報酬期待値計算結果を示し、（ｃ）は報酬期待値計算結果から条件に合う候補を選択してＧＵＩに表示する例を示しており、第１、第２の動作例と同様に、ユーザの発話を入力毎に解析し、その解析によって得られた検索条件により検索を行い、その検索結果などから「振る舞い決定に用いる情報」を設定する。そして、この振る舞い決定に用いる情報と振る舞い決定モデルを用いて、各振る舞い（問い合わせ、推薦、確認）における最終的に貰える報酬の期待値を計算する。

この第３の動作例は、対話システムが、ユーザとの対話から抽出した条件に基づいてＤＢの検索を行った結果、ユーザの希望する条件に推薦したい候補が含まれていた場合（推薦公報の有無＝true）に、ユーザから入力された検索条件の数の変化に応じてユーザに推薦したい候補を提示するように振る舞いが変化する例を示している。ユーザの１回目の発話で得られた振る舞い決定に用いる情報から計算された報酬期待値が最も高いのは「問い合わせ」の振る舞いになっていたが、その後２回目のユーザ発話によって「検索件数」が変わっていなくとも、今まで入力した検索条件の数（入力条件数）が増えることにより、報酬期待値の計算結果も変化し、推薦したい候補を提示する「推薦」の振る舞いをするようになっている。これにより、ユーザがある程度検索条件をシステムに伝え、もう絞り込みは不要と感じているタイミングで推薦したい候補を積極的に提示することが可能となる。

以上のように、第１の実施形態に係る対話システムによれば、ユーザとの対話中で得られている条件でデータベースを検索した際に、検索結果にユーザに推薦したい候補が含まれていた場合に、検索結果の件数やユーザがそれまでにシステムに伝えた条件の数の少なくとも一つを用いて、ユーザに推薦したい候補を提示する応答の振る舞いを行うかを判断する。これにより、ユーザに推薦したい候補をユーザが不満に感じない程度に積極的に推薦することが可能となる。

（第２の実施形態）
第１の実施形態に係る対話システムでは、検索対象それぞれにユーザに推薦したい候補か否かを示す情報を付与してシステム振る舞いの判断として用いていたが、検索対象それぞれのユーザへの推薦したさの大小をつけるようにすると効果的である。そこで、第２の実施形態に係る対話システムでは、検索対象それぞれにユーザへの推薦したいレベルを表すスコア（以下、推薦スコア）を付与し、そのスコアを用いてユーザに推薦するか否かを判断するものとする。これにより、推薦スコアが高い候補があるほど積極的にユーザに推薦する振る舞いが実現可能となる。

図８は、第２の実施形態に係る対話システムの構成を示すブロック図である。この第２の実施形態に係る対話システム２００は、第１の実施形態と同様に、発話理解部１０１と、検索部１０２と、応答生成部１０５とを備える。推薦判断部２０４を含む対話制御部（score）２０３と、検索ＤＢ（score）２０６は、第１の実施形態の推薦判断部１０４を含む対話制御部１０３と、検索ＤＢ１０６とは異なり、推薦スコアに基づく処理を行う。

すなわち、上記検索ＤＢ２０６は候補それぞれに推薦したさのスコアが含まれている点が検索ＤＢ１０６と異なる。なお、第１の実施形態では、ユーザに推薦したい候補であるという情報を検索部１０２や対話制御部１０３で検索結果に対して付与するという例も示したが、同様にユーザへの推薦スコアを検索部や対話制御部で付与してもよい。その場合、検索ＤＢ２０６は検索ＤＢ１０６と同様となり、検索部で付与する場合に検索部１０２とは異なる検索部２０２で構成することとなる。推薦スコアの付与方法は、第１の実施形態と同様、管理者が定めておいてもよいし、検索結果の候補に含まれる情報と時間や今までユーザから入力された検索条件などに応じて動的に決めてもよい。この際、例えばタイムセール中の割引率が高いものほど推薦スコアを高くするなど、検索結果の候補に含まれる情報によって推薦スコアの大小をつけてもよい。また、これら様々な手法で求めた推薦スコアの重み付け和を実際に使うスコアとしてもよい。

推薦判断部２０４を含む対話制御部２０３では、発話理解部１０１の入力文の解析結果や検索部１０２の検索結果から振る舞いを決定するが、特に検索結果に含まれるユーザへの推薦スコアと、検索結果の件数またはユーザが入力した条件の数の少なくとも１つを用いて推薦スコアが高い候補をユーザに提示する振る舞いをするか否かの判断を行う。

次に、図９を参照して、第２の実施形態に係る対話システムの動作について説明する。なお、図９は、第２の実施形態に係る対話システムの動作を示すフローチャートである。ただし、ステップＳ１０１、Ｓ１０２、Ｓ１０６は第１の実施形態と同様であるため、図２と同じ符号を付して示し、詳細な説明は省略する。

図９において、ステップＳ２０３では、発話理解部１０１の入力文の解析結果や検索部１０２の検索結果を用いて推薦判断部２０４を含む対話制御部２０３で振る舞いを決定するが、特に検索結果に含まれるユーザへの推薦スコアと、検索結果の件数またはユーザが入力した条件の数の少なくとも１つを用いて推薦スコアが高い候補をユーザに提示する振る舞いをするかどうかの判断を行う。

推薦スコアが高い候補をユーザに提示するかどうかの判断方法については、閾値を事前に設定しておき、閾値以上の推薦スコアかつ閾値以下の検索件数、または閾値以上の検索条件数になった際にユーザに推薦したい候補を提示するといったルールベースによる判断をしてもよいが、こちらでも強化学習を活用できる。この場合、ステップＳ１０４の強化学習の報酬設定に加え、提示した候補がユーザに受け入れられた場合に推薦スコアに比例する正の報酬を設定し、受け入れられなかった場合に一定の負の報酬を設定しておき、検索件数、検索条件数の少なくとも１つと検索結果の中で最も大きい推薦スコアを振る舞いの決定の際の入力特徴量として用いて振る舞い決定モデルを学習する。これにより、実際の対話の際も、上述した入力特徴量と振る舞い決定モデルにより、各振る舞いの最終的にもらえる報酬期待値を計算し、最終的にもらえる報酬期待値が最も高い振る舞いを選択することで実現可能である。

なお、振る舞いを決定する際の入力特徴量には、ステップＳ１０４で示した種々の情報に加え、検索結果中に推薦スコアの平均や分散、上位Ｎ個の推薦スコアなどを同時に利用してよい。こうすることにより、推薦スコアが高い候補が検索結果に含まれているほど、積極的にユーザに推薦スコアが高い候補を提示するようシステムが動作するようになる。

次に図１０乃至図１２において、対話システム２００が実際に推薦スコアが高いほど積極的にユーザに推薦したい候補を提示する対話例を示す。この例では、第１の実施形態と同様に、ショッピングセンター案内システムを想定する。
図１０は、ユーザへの推薦スコアが付与されたショッピングセンターのＤＢを示している。推薦したい候補ほど推薦スコアが高くなっている。この推薦スコアの指定方法も、第１の実施形態と同様にショッピングセンターの管理者が付与する、店舗の情報そのものや店舗の情報と時間などを紐づけて自動的に付与するといった方法の他、これら様々な方法で得られたスコアの重み付け和を取る方法も考えられる。ショッピングセンターの管理者が人手で付与する場合、各店舗に推薦スコアを数値でそのまま付与するインタフェースの他、「大」「中」「小」のような予め用意した何段階かの優先度を候補それぞれに付与するインタフェースも考えられる。管理者がその優先度で付与したのち、後処理によってスコアに変換してＤＢに登録すればよい。ＤＢでも優先度のまま登録しておき、振る舞いの決定の際の入力特徴量として用いるまでに検索部１０２や対話制御部２０３でスコアに変換するようにしてもよい。店舗の情報などから自動的にスコアを計算する際は、ショッピングセンターの管理者が条件に合う店舗（例えば現在タイムセールを行っている店舗）に付与、または重み付け和によるスコアを決めるようなインタフェースを用意してもよい。

図１１、図１２は、第２の実施形態に係る対話システムにおいて、図１０のＤＢに登録されている推薦スコアを用いた際の第１、第２の動作例である。図１１と図１２では対話中にユーザが入力した条件によって検索した結果の件数やユーザが入力した条件の数は同じだが、検索結果に含まれている最大の推薦スコアが異なっている。そして、そのスコアが大きい図１２の対話の方が早いタイミングで推薦したさのスコアが高い店舗をユーザに提示している。このように推薦スコアが高い候補ほどより積極的にユーザに提示する動作が実現できる。

なお、図１１の例の最後の応答文は、検索結果の中で最も推薦スコアが高かった店舗をお勧めとしてユーザに伝えているが、それほど推薦したさのスコアが高くない場合はお勧めする応答文にせず、通常の検索結果を提示する応答文を出すようにしてもよい。この実現のためには、ある閾値以下のスコアしかなかった場合は検索結果を提示する応答文にする方法がある。また、推薦した店舗をユーザが受け入れられなかった場合に通常の検索結果を提示する応答文で提示した店舗を、ユーザが受け入れられなかった場合に比べてより負の報酬を与えるよう設計して強化学習を行う方法も考えられる。この方法によれば、推薦してユーザが受け入れた場合にもらえる正の報酬を考慮しても推薦しない方がよいとなる推薦スコアの境界線を学習することができる。

条件に合う店舗のリストをＧＵＩ上で表示する際には、推薦したさのスコアが高い方から並べて最もスコアが高い候補に目に付くようなマークをつけたり、または他の候補が表示される場所とは別の目立つ場所に表示したりするなどしてもよい。最もスコアが高い候補だけでなく、最も高いスコアに近いスコアを持つ候補にもマークを付けたり目立つ場所に表示したりしてもよい。マークの大きさや色をスコアの大小によって変化させてもよい。

このように、第２の実施形態に係る対話システムによれば、ユーザとの対話中で得られている条件でデータベースを検索した結果に含まれるユーザに推薦したさのスコアと、検索結果の件数またはユーザがそれまでにシステムに伝えた条件の数の少なくとも一つを用いてユーザに推薦スコアが高い候補を提示する応答の振る舞いを行うか否かを判断する。これにより、推薦スコアが大きい候補が検索結果に含まれているほどより積極的にユーザに推薦スコアが大きい候補を推薦することが可能となる。

なお、上記第１、第２の実施形態に係る対話システム１００，２００は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、第１の実施形態の発話理解部１０１と、検索部１０２と、推薦判断部１０４を含む対話制御部（true-false）１０３と、応答生成部１０５と、検索ＤＢ（true-false）１０６、第２の実施形態の発話理解部１０１と、検索部１０２と、推薦判断部２０４を含む対話制御部（score）２０３と、応答生成部１０５と、検索ＤＢ（score）２０６は、いずれも上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。

このような支援装置を含む対話システムに適用可能なコンピュータ装置は、図１３に示すように、ＣＰＵ（Central Processing Unit）３０１などの制御装置と、ＲＯＭ（Read Only Memory）３０２やＲＡＭ（Random Access Memory）３０３などの記憶装置と、マイクロホン、操作入力装置、表示装置等が接続される入出力Ｉ／Ｆ３０４と、ネットワークに接続して通信を行う通信Ｉ／Ｆ３０５と、各部を接続するバス３０６を備えている。上記のプログラムをコンピュータ装置に予めインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、それぞれの処理機能は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスク若しくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

その他、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１００，２００…対話システム、１０１…発話理解部１０１、１０２…検索部、１０３…対話制御部（true-false）、１０４…推薦判断部、１０５…応答生成部、１０６…検索ＤＢ（true-false）、１０７…推薦候補情報管理部、２０３…対話制御部（score）、２０４…推薦判断部、２０６…検索ＤＢ（score）、３０１…ＣＰＵ、３０２…ＲＯＭ、３０３…ＲＡＭ、３０４…入出力Ｉ／Ｆ、３０５…通信Ｉ／Ｆ、３０６…バス。

Claims (10)

1. 複数の検索の対象を、推薦候補の対象か否かを示す推薦候補情報と組みにして保存するデータベースと、
   ユーザとの対話による入力情報に基づいて検索条件を設定し、前記データベースから前記検索条件に合う対象を検索し、前記検索した対象と組となっている前記推薦候補情報から、前記検索した対象の中に推薦候補の対象が含まれるか判断し、前記推薦候補の対象が含まれていないと判断した場合に、前記検索した結果に基づいて前記ユーザに対する動作を決定し、前記推薦候補の対象が含まれていると判断した場合に、前記検索した対象の数または前記ユーザとの対話の入力数の少なくとも一つに基づいて前記推薦候補の対象をユーザに提示する動作の是非を決定し、決定された動作に対応する応答処理を実行する制御部と
   を具備する対話システム。
2. 前記推薦候補情報は、前記データベースに前記検索の対象を登録または更新する際に付与される請求項１に記載の対話システム。
3. 前記推薦候補の対象は、前記検索の対象そのもの、または前記検索の対象と時間の組み合わせに基づいて決定される請求項１に記載の対話システム。
4. 前記制御部は、前記検索の結果と前記ユーザとの対話による入力情報に基づき、前記検索の結果の対象それぞれについて推薦候補であるかを判断する請求項１に記載の対話システム。
5. 前記制御部は、前記検索の結果の候補の情報、または前記検索の結果の候補の情報と時間との組み合わせに基づき、前記検索の結果の候補それぞれについて推薦候補であるか否かを判断する請求項１に記載の対話システム。
6. 前記制御部は、前記検索の結果の候補の件数または前記ユーザとの対話による入力情報に基づいて設定される検索条件の件数の少なくとも１つと、前記検索の結果に推薦候補が含まれているかの情報を最低限の入力として用い、前記推薦候補が前記ユーザに受け入れられた場合に大きな正の報酬を与え、前記ユーザに受け入れられなかった場合に負の報酬を与える報酬設計をした強化学習を実行して得られる動作決定モデルを備え、この動作決定モデルに基づいて前記動作を決定する請求項１に記載の対話システム。
7. 前記推薦候補情報はスコアで表現され、
   前記制御部は、前記検索の結果の中で最も高いスコアを持つ候補のスコアと前記検索の結果の候補の件数または前記ユーザとの対話による入力情報に基づいて設定される検索条件の数の少なくとも一つを用いて、前記スコアが高いほど積極的に、前記スコアが最も高い候補を前記ユーザに提示する動作を行わせる請求項１に記載の対話システム。
8. 前記制御部は、前記スコアが最も高い候補が前記ユーザに受け入れられた場合に前記スコアに比例した正の報酬を与え、前記ユーザに受け入れられなかった場合に負の報酬を与えるように報酬設計をした強化学習を実行して得られる動作決定モデルを備え、この動作決定モデルに基づいて前記動作を決定する請求項７に記載の対話システム。
9. データベースに複数の検索の対象を、推薦候補の対象か否かを示す推薦候補情報と組みにして保存しておき、
   ユーザとの対話による入力情報に基づいて検索条件を設定し、
   前記データベースから前記検索条件に合う対象を検索し、
   前記検索した対象と組となっている前記推薦候補情報から、前記検索した対象の中に推薦候補の対象が含まれるか判断し、
   前記推薦候補の対象が含まれていないと判断した場合に、前記検索した結果に基づいて前記ユーザに対する動作を決定し、
   前記前記推薦候補の対象が含まれていると判断した場合に、前記検索した対象の数または前記ユーザとの対話の入力数の少なくとも一つに基づいて前記推薦候補の対象をユーザに提示する動作の是非を決定し、
   前記決定された動作に対応する応答処理を実行する対話システムの対話方法。
10. ユーザとの対話に沿って応答処理を実行する対話システムに用いられ、前記対話システムの処理をコンピュータに実行させるための対話プログラムであって、
    前記ユーザとの対話による入力情報に基づいて検索条件を設定するステップと、
    複数の検索の対象が、推薦候補の対象か否かを示す推薦候補情報と組みにして保存されるデータベースから前記検索条件に合う対象を検索するステップと、
    前記検索した対象と組となっている前記推薦候補情報から、前記検索した対象の中に推薦候補の対象が含まれるか判断するステップと、
    前記推薦候補の対象が含まれていないと判断した場合に、前記検索した結果に基づいて前記ユーザに対する動作を決定するステップと、
    前記推薦候補の対象が含まれていると判断した場合に、前記検索した対象の数または前記ユーザとの対話の入力数の少なくとも一つに基づいて前記推薦候補の対象をユーザに提示する動作の是非を決定するステップと、
    前記決定された動作に対応する応答処理を実行するステップと
    を具備する対話システムの対話プログラム。

Images