JP4156563B2 - 単語列認識装置 - Google Patents

Description

本発明は、例えば音声認識に代表される様々な信号の認識結果候補群が離散的な単語列の集合として得られる場合に、適正な単語列を認識することのできる単語列認識装置に関するものである。

従来より、例えば人間から発せられた音声を入力し、辞書データと比較して一致度合の高い複数の単語列候補を出力する認識装置が知られており、例えばその認識装置を用いて使用者の発話内容を認識し、認識結果に応じて機器を動作させる制御システムなどに適用されている。例えば、使用者が音声コマンドとして予め定められた言葉を発話すると、その言葉に対応した情報検索動作などを行う自動車用ナビゲーション装置などが実用化されている。

ところで、現状の音声認識には連続単語認識とワードスポッティングという２つの手法がある。前者の認識手法によれば、例えば「おかざき、○○○○○（店名）、らーめん」といった単語毎の認識が可能であるが、実際には誤認識を避けて通ることはできない。そのため、現行のナビゲーション装置などでは、認識結果として複数の候補を持ち、最初にその内の１つをトークバックしてユーザに確認を求めることがなされている。ユーザは自分が発話した内容と違っていれば、認識結果が違っている旨を装置に伝える。すると、装置側は別の認識結果を提示して再度ユーザの確認を求める。認識結果の候補を多数準備して次々に提示していけば、最終的にはユーザが意図した内容の認識結果となることは可能であるが、候補の中には、全く意味をなさない内容のものも含まれる可能性があり、上述した最終的に適切な候補に至るまでに長時間要してしまうことも考えられる。

また、後者のワードスポッティング手法は、例えば「えーと、おかざきの○○○○○（店名）でらーめんくいたいなあ」という日常語的な音声入力から「おかざき、○○○○○（店名）、らーめん、くいたい」というキーワードを抽出できるという点で近年急速に注目されている音声認識技術である。しかしながら、当該手法の場合には、ラティスと呼ばれるその出力（時区間情報と確率情報を持った単語集合）から生成される単語列候補の数は非常に多く、意味を持つ小数の単語列に絞られることは稀である。また、当該手法における現在の認識語彙数は１００語程度であるが、将来的には１０００語以上に増大することが見込まれ、その結果として発生するラティスから生成される単語列は膨大な数に上ると考えられる。したがって、上述した連続単語列認識手法の場合で述べたのと同様の（むしろ、より顕著な）問題が存在する。

また、現状の音声認識技術では、雑音や音声環境の変動などに基づく誤認識時において、正常な対話への復帰が困難であった。例えば地名を入力したい場合に、意図せず駅名中から選択するモードに入ってしまうと、それ以外の地名を適切に認識してもらえなくなる。誤認識を少なくするために絞り込みができる辞書構造にしておくことは、ある意味では好ましく、多くの単語認識手法において用いられているが、上述したように意図しない認識モードに陥ってしまうと、それ以降の所望の入力ができなくなる可能性がある。そして、そのモードからエスケープする操作を知らないと正常な対話への復帰が困難となり、ユーザは途方に暮れてしまうこともありえる。

本発明は、こうした問題に鑑みなされたものであり、誤認識に起因し、例えば利用者の意図しない認識モードに陥って復帰ができず利用者が途方に暮れてしまう、といった不都合を防止可能な単語列認識装置を提供することを目的とする。

上記目的を達成するため、多段階処理を提案する。

（１）多段階処理
請求項１記載の単語列認識装置は、多段階処理手段が、単語列出力手段から出力された単語列を構成する単語の内、所定の属性を持つ単語に基づいて話題を確定し、続いて、その確定した話題に基づく語彙に限定した認識用辞書データを再構成し、その再構成した認識用辞書データに基づいて他の単語を認識するという処理を必要なだけ繰り返し実行する。

例えば、現状のワードスポッティング手法では１回の処理に対する認識語彙数は１００語程度であり、連続単語認識の辞書のような大規模化は困難である。一方、実用的に見た場合、特定の話題（例えば「食事に行く」など）にフォーカスする際には、例えば１００語程度でも対応可能である。したがって、話題を的確に認識し、誤認識の際は話題の不連続性を検出し、これらに応じてワードスポッティングの語彙を切り替えていけばよい。そこで、多段階処理を行う。このようにすれば、利用者が途方に暮れてしまわないような単語列の認識を、小語彙で達成できるようになり、上述のワードスポッティング手法を採用した場合の不都合を解消できる。

そして、多段階処理手段が最初に話題を確定するために扱う単語属性は、要求内容を示す属性である。利用者の発話はたいていのコンテンツ検索の場合、『場所』『施設名』『要求対象』『要求キーワード』からなるか、その並び替え、あるいは省略形で基本形が構成されると考えられる。この内、一般的には何が要求であるかを把握することが好ましい。それは、要求を把握するために想定する要求キーワードが、場所や施設名などに比較して少ない数でもよいからである。なお、要求キーワード以外の『場所』、『施設名』又は『要求対象』を、最初に話題を確定するための単語属性として扱うことを否定するものではないことを付言しておく。

ところで、話題に基づく語彙に限定した認識用辞書データを再構成する上では、より適切な語彙を選ぶことが重要になってくる。そこで、請求項１記載の単語列認識装置においては、以下のような工夫をした。

つまり、さらに、認識対象の要求を推定する要求推定手段を備え、話題、時間・位置、ユーザの置かれた環境・状況、ユーザの状態・要求、ユーザ発話・エージェント発話・制御出力という属性の組で構成される対話ベクトルおよびその集まりである対話データベースの中でユーザ発話を位置づけ、そのユーザ発話に関して、現在の話題に連関する話題に対応する語彙、文脈の連続性という観点から定まる語彙、前記要求推定手段にて推定した要求という観点から定まる語彙についても考慮すると共に、不連続的に発生する予測不可能な緊急事態や警告対象となる事態に対応する語彙として予め設定した語彙を含めることとした。このようにすることで、誤認識に起因して利用者が途方に暮れてしまう、といった不都合を防止することができる。
現在の話題に連関する話題に対応する語彙の一例を挙げれば、ショッピングという話題に対して、駐車場（手段）、レストラン（付随する行動）、バーゲン（よくある付帯事象）などの語彙が該当する。

また、文脈の連続性という観点から定まる語彙について説明する。例えばある話題（ショッピングなど）で閉じた認識語彙の範囲で対話が継続すると考えて、このような話題の連続性という制約のもとで認識用辞書データの再構成をするのである。また、発話と応答の組合せを発話対あるいは対話ユニットと呼ぶこととすると、この対話ユニット内の妥当性という制約のものでの再構成、つまり発話に対して妥当な応答の範囲で認識用辞書データを再構成してもよい。さらには、対話ユニット間における接続性についても考慮することが考えられる。

また、要求推定手段にて推定した要求という観点から定まる語彙について説明する。これは、認識対象から直接入力（音声認識であれば利用者からの発話）されたものではなく、利用者の置かれている環境や状況あるいはユーザプロファイルなどを基に利用者の要求を推定し、利用者の次の発話として想定される内容に対応できるように認識用辞書データの再構成を行うのである。

また、不連続的に発生する予測不可能な緊急事態や警告対象となる事態に対応する語彙として予め設定した語彙について説明する。その一例として、単語列認識装置が車両に搭載されている場合を想定する。例えばカーナビゲーションシステムに組み込まれている場合などである。この際、突然の運転状況の変化などがここでいう「不連続的に発生する予測不可能な緊急事態や警告の対象となる事態」に相当する。例えば対話の最中に先行車が急停止したので急ブレーキをかけた場合、おもわず利用者が「あー、危なかった。」といってしまう状況は容易に考えられる。そのため、車両に搭載するのであれば、このような「危ない」という意味の語彙も含めておく。

請求項１記載の単語列認識装置では 多段階処理手段が最初に話題を確定するために扱う単語属性が要求内容を示す属性である点が発明特定事項αとなっていたが、請求項２記載の単語列認識装置では、その発明特定事項αに代えて、話題を確定するために扱う所定の属性を持つ単語が複数存在する場合は、構文位置に基づいていずれか１の単語を選択するという発明特定事項βを備えている。例えば要求キーワードを探す場合であれば、構文全体として見た場合に、その構文における要求が何であるかを示す要求キーワードが存在する可能性の高い位置というものが決まってくるからである。これは、自然言語として、例えば文法、意味、常識などを加味すれば自ずと定まる。

請求項１記載の単語列認識装置では 多段階処理手段が最初に話題を確定するために扱う単語属性が要求内容を示す属性である点が発明特定事項αとなっていたが、請求項３記載の単語列認識装置では、その発明特定事項αに代えて、話題を確定するために扱う所定の属性を持つ単語は、所定レベル以上の尤度を備えている場合にのみ採用するという発明特定事項γを備えている。例えば、最初に話題を確定するための単語属性としては「要求キーワード」が好ましいことを述べたが、尤度が低い場合にあえて要求キーワードにこだわる必要もない。その場合には、他の単語属性で尤度が相対的に高いものがあれば、それを採用する方が好ましいこともある。

また、上述した単語列認識装置における多段階処理手段の実行する処理をコンピュータシステムにて実現する機能は、例えば、コンピュータシステム側で起動するプログラムとして備えることができる。このようなプログラムの場合、例えば、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができる。この他、ＲＯＭやバックアップＲＡＭをコンピュータ読み取り可能な記録媒体として前記プログラムを記録しておき、このＲＯＭあるいはバックアップＲＡＭをコンピュータシステムに組み込んで用いても良い。

以下、本発明の実施形態について、図面を用いて説明する。
まず図１は、実施形態の単語列認識装置について機能に着目して概念的に示したブロック図である。

ユーザインタフェースを介して入力された、音声に代表される信号は、音声認識部あるいはその他の信号系認識部において所定の認識処理がなされ、単語列候補を出力する。音声認識部は音声認識及び単語列生成の機能を備えており、認識辞書（認識語彙辞書）を用いて、ある発話に相当する音声入力に対する認識を行い、認識辞書に登録されている単語の集まりとして単語列候補を得る。これがここでいう音声認識機能であるが、この時点では候補となる単語が同一時刻に複数個示される可能性がある。その後、単語列生成機能を用いることで、音声認識機能によって得た単語に基づき時区間的に重なりのない単語列を複数個生成し、対話管理手段へ出力する。この際、単語列に付随して尤度も出力される。このように、１つの音声発話に対する音声認識結果は、通常、尤度情報を伴った候補が複数個存在することとなり、音声認識においては「湧き出し」と呼ばれる。

そして、この尤度情報を伴った単語列候補について、対話管理手段は文脈や意味的制約情報を適用して認識し、辞書構成手段を用いて、認識辞書を動的に更新する。さらに、対話管理手段は、画面制御手段を介して表示系に対する表示制御を行ったり、音声出力系、機器制御系に対する制御を行う。

以上は、機能に着目して単語列認識装置を概念的に示したブロック図であったが、次に、単語列認識装置を車載の制御システムに適用した場合の構成を示すブロック図である図２を参照して説明する。本制御システムは、自動車（車両）に搭載されて、ユーザとしての車両の乗員（主に、運転者）と音声にて対話しながら、その車両に搭載された様々な機器を制御するシステムである。

図２に示すように、本実施形態の制御システムは、制御装置１と、使用者が各種の指令やデータなどを外部操作によって入力するための入力装置３と、音声を入力するためのマイクロフォン５と、音声を出力するためのスピーカ７と、画像を表示するためのディスプレイ（表示装置）８と、車両の現在位置（現在地）の検出や経路案内などを行う周知のナビゲーション装置９と、車内の空調を制御するエアコン装置１３と、カセットテープレコーダ，ＣＤ（コンパクトディスク）プレーヤ，ＭＤ（ミニディスク）プレーヤ，ラジオ，及びテレビなどからなるオーディオ装置１５と、周知のＶＩＣＳ（Vehicle Information and Communication System）の放送端末や、インターネットとの接続窓口であるインターネット放送端末との間で無線によりデータ通信を行う通信装置１７と、車速や加減速状態などの車両運転状態，車両内外の温度，及び雨滴の有無などを検出するための各種センサ１９と、車両のドアロック，窓ガラス（パワーウィンドウ），エンジン，及びブレーキ装置などを制御する他の制御装置（図示省略）とが接続されて構成されている。

尚、ナビゲーション装置９は、車両の現在位置を検出するための周知のＧＰＳ装置や、地図データ，地名データ，施設名データなどの経路案内用データを記憶したＣＤ−ＲＯＭ、そのＣＤ−ＲＯＭからデータを読み出すためのＣＤ−ＲＯＭドライブ、及び、使用者が指令を入力するための操作キーなどを備えている。そして、ナビゲーション装置９は、例えば、使用者から操作キーを介して、目的地と目的地までの経路案内を指示する指令とが入力されると、車両の現在位置と目的地へ至るのに最適な経路とを含む道路地図を、ディスプレイ８に表示させて経路案内を行う。また、ディスプレイ８には、ナビゲーション装置９によって経路案内用の道路地図が表示されるだけでなく、情報検索用メニューなどの様々な画像が表示され、さらに、オーディオ装置１５がテレビのモードに設定されると、そのオーディオ装置１５に備えられたテレビチューナにより受信されたテレビの受信画像が表示される。

そして、制御装置１は、ＣＰＵ，ＲＯＭ，及びＲＡＭなどからなるマイクロコンピュータを中心に構成されたシステム制御部２１と、システム制御部２１に入力装置３からの指令やデータを入力するインタフェース（Ｉ／Ｆ）２３と、マイクロフォン５から入力された音声信号をデジタルデータに変換してシステム制御部２１に入力する音声入力部２５と、システム制御部２１から出力されたテキストデータをアナログの音声信号に変換してスピーカ７に出力し、スピーカ７を鳴動させる音声合成部２７と、ディスプレイ８への表示画面の制御を行う画面制御部２８と、上記ナビゲーション装置９，エアコン装置１３，オーディオ装置１５，通信装置１７，各種センサ１９，及び他の制御装置とシステム制御部２１とをデータ通信可能に接続する機器制御インタフェース（機器制御Ｉ／Ｆ）２９とを備えている。

また、制御装置１には、通信装置１７によりインターネットから所望の情報を検索及び取得するために、インターネットのアドレス（インターネットアドレス）を記憶するインターネットアドレスデータベース３１と、検索制御部３３とが備えられている。そして、システム制御部２１が、検索制御部３３へ検索内容（コンテンツ）を表す検索キーワードを出力すると、検索制御部３３は、機器制御Ｉ／Ｆ２９を介し通信装置１７を動作させて、インターネット放送端末から上記検索キーワードに対応した情報を検索し、その検索結果をシステム制御部２１へ入力させる。また、インターネットアドレスデータベース３１には、検索制御部３３によって過去に用いられたインターネットアドレスが、システム制御部２１からの指令によって記憶され、検索制御部３３は、システム制御部２１から過去に入力した検索キーワードと同じ検索キーワードを受けると、インターネットアドレスデータベース３１内のインターネットアドレスを再利用する。

一方、制御装置１は、マイクロフォン５及び音声入力部２５を介して入力される音声信号から、使用者が発話した言葉としてのキーワード（以下、発話キーワードともいう）を認識して取得するために、使用者が発話すると想定され且つ当該制御装置１が認識すべき複数の認識語彙を予め記憶した認識語彙記憶部３４を備えている。つまり、この認識語彙記憶部３４に記憶されている認識語彙群が、当該制御装置１の認識語彙データベースとなっている。

またさらに、制御装置１は、スピーカ７から出力する発話（以下、エージェント発話ともいう）の内容（即ち、スピーカ７の動作内容）とスピーカ７以外の他の機器Ｍの動作内容とを設定するため、及び、使用者の要求と使用者の精神的或いは肉体的な状態とを推定するためのデータを記憶する手段として、対話データベースを記憶する対話データ記憶部３５と、要求・状態推定用データを記憶する要求・状態推定用データ記憶部３６と、使用者の複数人分の個人情報（以下、ユーザプロファイルともいう）を記憶するユーザプロファイル記憶部３７とを備えている。尚、この対話データ記憶部３５，要求・状態推定用データ記憶部３６，及びユーザプロファイル記憶部３７と、前述したインターネットアドレスデータベース３１は、データの読み出しと書き込みとが可能な不揮発性メモリによって構成されている。

なお、対話データ記憶部３５に記憶される対話データベース、要求・状態推定用データ記憶部３６に記憶される要求・状態推定用データ、ユーザプロファイル記憶部３７に記憶されるユーザプロファイルなどについては、例えば特願平１０−１６２４５７号、特願平１０−１８４８４０号などを参照されたい。

次に、以上のように構成された本実施形態の制御システムにおいて、システム制御部２１で実行される処理の概要を図３を用いて説明する。なお、ここでは、図１で言えば音声認識部にて認識処理を行い、対話管理手段がその認識結果である単語列候補に対して所定の処理を行う「単語列の認識」にかかわる処理について説明する。

処理が開始されると、入力された音声に対して認識処理を行う（Ｓ１０）。そして、Ｓ２０での判断結果に基づき、「入力待ち」であると判断してＳ１０へ戻るか、多段階処理（Ｓ３０）を行うか、認識完了又はタイムアウトであると判断してＳ４０へ移行する。Ｓ３０での多段階処理の詳細については、後述する。

Ｓ４０での対話管理に移行した後は、期待外の応答であるかどうかを判断し（Ｓ５０）、期待外の応答であればＳ６０へ移行し、期待外の応答の種類を判別する。その判別結果に応じて、話題転換の確認（Ｓ７０）、話題転換後の発話（Ｓ８０）、文脈優先の発話（Ｓ９０）のいずれかを実行する。その後、発話処理（Ｓ１８０）を経て、Ｓ１０へ戻る。

一方、Ｓ５０にて期待外の応答ではない（つまり期待に沿った応答である）と判断された場合は、Ｓ１００へ移行する。Ｓ１００での判断処理において、エージェントからの問い返し回数がＮ回を超えたと判断された場合は、ヘルプモード処理を実行する（Ｓ１２０）、また、Ｓ１００での判断処理において、エージェントからの問い返し回数がＫ回（Ｋ＞Ｎ）を超えた場合、又はユーザからのリセット要求があった場合は、Ｓ１７０へ移行して 初期状態に戻る。そして、これら以外の場合、すなわち、エージェントからの問い返し回数がＮ回以下の場合には、Ｓ１１０での判断結果に基づき、ディスプレイ８に選択肢を提示する処理（Ｓ１３０）、通常の発話戦略（Ｓ１４０）、音声メニューモード（Ｓ１５０）又は問い返し（Ｓ１６０）のいずれかの処理を選択的に実行する。これらの詳細については後述する。

Ｓ１２０〜Ｓ１７０のいずれかの処理が実行された後は、発話処理（Ｓ１８０）を経て、Ｓ１０へ戻る。
以上は、処理の概略的な流れの説明であったので、続いて詳細内容を説明していく。但しここでは、漸進的階層探索、多段階処理、期待外時対応処理、誤認識対応処理という本発明の概念単位の順番に説明することにする。但し、説明の都合上、期待外時対応処理と誤認識対応処理については、[３．誤認識対応処理について］としてまとめ、その中で区別して説明している。
［１．漸進的階層探索について］
［１．１ 概要］
漸進的階層探索は、図３のフローチャート中では、Ｓ１３０の選択肢を提示する処理に相当する。但し、１単語ずつ処理するために他の処理とは時間サイクルが異なるため、事前に漸進的階層探索を実行するモードに設定しておく必要がある。したがって、漸進的階層探索モードに設定されている場合に限り、図３のＳ１３０は実行されることとなる。

［１．２ 具体例］
図４には漸進的階層探索の具体的な画面遷移例を示す。
（１）図４の最初の画面Ｇ１では、デフォルトモードにおいて東海４県の県名が表示されている状態において「愛知県」と発話した結果、愛知県にフォーカスされたことを示している。

そして、制御システム側は、愛知県という単語を認識した時点で「漸進的階層探索」機能を発揮して、次にユーザに期待する発話語彙を即座に画面に提示する。この場合は、画面Ｇ２のように愛知県内の市町村名を表示する。なお、画面Ｇ２では４つの市町村名しか挙げていないが、これは説明を簡単にするためのものである。なお、画面Ｇ２は、利用者が「岡崎」と発話した結果、岡崎にフォーカスされたことを示している。

そして、制御システム側は、岡崎が入力された時点で「漸進的階層探索」機能を発揮して、次にユーザに期待する発話語彙を画面に提示できる状態にしておく。ここで「提示できる状態にしておく」としたのは、実際には、「岡崎で食事したいなあ」のように次の単語が連続して発話されることが多いので、実用上は提示しないからである。提示するのは、岡崎の後に所定時間（例えば１〜２秒）の無音区間があった場合には、ユーザが迷っていると推定し、発話語彙を画面提示する。つまり「岡崎の要求メニュー」である。その内容は、誤認識時に用いる画面Ｇ７の岡崎の要求メニューの内の「もう一度お話下さい」を除いた部分となる。画面Ｇ３が表示された状態で「インド料理がいいね。」と発話されると、画面Ｇ４に示すようにインド料理にフォーカスされ、画面Ｇ５に示すように、「愛知県岡崎市インド料理 検索しています」という表示し、検索が終了すると、画面Ｇ６に示すように、その検索結果を表示する。

一方、画面Ｇ２に示す岡崎が発話された時点で次に発話を期待する語彙以外の語彙が発話された場合には、画面Ｇ７へ移行して「岡崎の要求メニュー」と共に「もう一度お話下さい」という案内を加えた内容を表示する。ここで、「食事」と発話されれば画面Ｇ３へ移行し、「デパートは？」と発話されれば、画面Ｇ８に示すように、該当するデパートを一覧表示する。そして、その内のいずれかが指定されて「△△△の地図」と発話されると、画面Ｇ９に示すように、そのデパートの位置が明確になるように、周辺の地図と共に表示する。

（２）図５も漸進的階層探索の一例である。図５の画面Ｇ１〜Ｇ３は図４にて示した画面内容と同じであるが、デフォルトモードにおいて東海４県の県名が表示されている状態において「東京」と発話すると、画面Ｇ１１へ移行する。この場合、東京といっても東京都のみを指すのではない場合もあるので、東京都周辺を対象としてもよい。

そして、制御システム側は、東京という単語を認識した時点で「漸進的階層探索」機能を発揮して、次にユーザに期待する発話語彙を即座に画面に提示する。この場合は、画面Ｇ１２に示すように東京都内の市区町村名を画面表示する。そして、銀座と発話した時点で銀座にフォーカスする。

そして、制御システム側は、銀座という単語を認識した時点で「漸進的階層探索」機能を発揮して、次にユーザに期待する発話語彙を画面に提示できる状態にしておく。ここで「提示できる状態にしておく」としたのは、上述の画面Ｇ２→Ｇ３へ移行する部分と同様に、実際には、「銀座、○○○ビル」のように次の単語が連続して発話されることが多いので、実用上は提示しないからである。提示するのは、銀座の後に所定時間（例えば１〜２秒）の無音区間があった場合である。画面に提示する発話語彙は、銀座内の地名関連情報である。例えば地名そのものでもよいし、使い勝手の面から言えば、○○○ビルや□□デパートのような施設名でもよい。

そして、利用者から例えば○○ビルと発話されると、画面Ｇ１３に示すように、その○○○ビルの位置が明確になるように、周辺の地図と共に表示する。
［１．３ 効果］
例えば「岡崎で食事したいなあ、インド料理がいいね」という発話が利用者からなされた場合、ワードスポッティングによる音声認識手法の出力結果は、「岡崎、食事、インド料理」という単語列になる。従来の音声認識手法では、これら３つが揃った段階で認識に対応するシステム側の処理が開示されていたが、本手法によれば、「岡崎」が入力された時点で、次に利用者に入力を期待する発話語彙を即座に提示できるため、利用者はとまどうことなく発話できるようになる。これによって、誤認識の原因となる認識辞書外の語彙を利用者が発話してしまうことを未然に防止できる。
［２．多段階処理について］
［２．１ 概要］
（１）現状のワードスポッティング手法では１回の処理に対する認識語彙数は１００語程度であり、連続単語認識の辞書のような大規模化は困難である。一方、実用的に見た場合、車室内において発生すると想定される特定の話題（例えば「食事に行く」など）にフォーカスする際には、例えば１００語程度でも対応可能である。したがって、話題を的確に認識し、誤認識の際は話題の不連続性を検出し、これらに応じてワードスポッティングの語彙を切り替えていけばよい。そこで、多段階処理を行う。

図６には、「よこはまのちゅうかがいでしゅうまいでもくいたいなあ」という発話がなされた場合に行う多段階処理の一例を示した。なお、本発話例では、以下のような単語属性に分類できるものとする。

よこはまの ちゅうかがいで しゅうまいでも くいたいなあ
（場所） （施設名） （要求対象） （要求キーワード）
したがって、まず、何が要求であるかを把握するため、第１段階では「くいたい」という要求キーワードをスポッティングし、話題を確定する。

そして、第２段階では、第１段階で確定させた話題から語彙を限定し、辞書を切り替える。すなわち、この場合には、目的地をベースとしたレストラン名と関連する料理名で１００語の大半を構成する。これは、「くいたい」という要求キーワードから食事の要求であることが判るため、単語列を構成する他の単語はレストラン名や料理名となっていると予想できるからである。これにより、「ちゅうかがい」や「しゅうまい」などが認識語彙としてヒットし易い辞書を構成することができる。

（２）なお、図６では第１段階の処理として要求キーワードをスポッティングして話題を確定しているが、それ以外の施設名や場所、あるいは要求対象をスポッティングして話題を確定してもよい。但し、現実的には、ワードスポッティングの語彙数は現状では１００語程度であるので、その程度の語彙でまかなうことを鑑みると、要求キーワードでの話題確定が好ましい。

（３）また、図６で示した具体例は、１の単語列を構成する単語の属性という観点からｎ次元の軸を設定したが、さらに時間軸に沿った関連性を考慮しても良い。つまり、文脈という観点も加味して話題を確定するのである。

［２．２ ユーザ発話の基本構成］
ユーザの発話はたいていのコンテンツ検索の場合、『場所』『施設名』『要求対象』『要求キーワード』からなるか、その並び替え、あるいは省略形で基本形が構成されると考えられる。語順が変わる場合には要求キーワードが音声信号中のどこに存在するかは不明であるが、例えば本願出願人が特願平１１−２０３４９号にて提案したような適正単語列の推定手法を用いることにより、構文的な制約に基づいて複数の候補に対して優先順序を定めることはできる。

［２．３ 認識辞書の構成］
認識辞書は図２に示す認識語彙記憶部３４に記憶されている認識語彙データベースから動的に構成し得るものとする。認識語彙データベースは、システムで扱う現実の話題に対応して予め各カテゴリ毎の語彙クラスタに分割しておく（図７参照）。なお、この各カテゴリ毎の語彙クラスタはクラスタ辞書と呼ばれる。また、カテゴリには例えば下記のような種類がある。

（１）各種コマンド
・ナビコマンド
・スケジュール帳
・アドレス帳
・電話
（２）要求キーワード（要求ＫＷ）
（３）施設名
１）レストラン名
・料理名
・雰囲気
・値段
２）スキー場名
３）ゴルフ場名
４）デパート名
５）遊園地名
６）公園名
７）映画館名
８）温泉
（４）イベント名
（５）検索結果
（６）地名
（７）鉄道駅名
（８）基本的な対話語彙
・肯定、否定
・問い合わせ
・説明、状況通知、確認、……
これらの構成語彙にはデータベースの要素となる固有名詞のみならず、対話上の同義語（はらへった、ごはんたべたい、ｅｔｃ）も含まれる。この各々からここでは１回のワードスポッティングの語彙即ち、目的地をべースとしたレストラン名と関連する料理名（ここではユーザプロファイルも参照する）で１００語の大半を構成する。これをもとに『中華街』や『しゅうまい』などが認識語彙としてヒットする。

［２．４ 単語間のネットワーク］
辞書の基本構造は上記の階層表現に準じて定義するが、その他の意味的関係などのネットワーク関係は随時、ユーザやデータベース供給者から提供される。例えば、ユーザ発話は下記のような属性の組（対話べクトルと呼ぶ）の集まりである対話データベース（図８）の中で位置づけられる。

（話題、時間・位置、環境・状況、状態・要求、ユーザ発話、エージェント発話、制御出力）
対話ベクトルは無数に存在しうるが、あらゆるベクトル値を取るわけではなく、人間と機械との間の実際的なコミュニケーションの単位として、意味のある有限個のまとまりにクラスタリングできる。そこには単語の意味的な分類、文法的制約、話題の連続性、物理的・常識的制約、事象の連続性などが用いられる。したがって、
（Ａ）あるユーザ発話を構成する単語列に用いられる語彙の範囲
（Ｂ）現在の発話から次の発話に至る際の語彙の制約
は対話ベクトルが張る空間を構成する主要因となる（話題、時間・位置、環境・状況、状態・要求）に大きく影響される。

そこで、あるユーザ発話における単語が他の単語に対してどういうネットワーク構造になるかは下記の要因で決定する。
（１）クラスタ辞書間の関係
（２）単語間の関係
（３）話題間の関係
（４）文脈の連続性
（５）ユーザの特性や状況
（６）アプリケーション間
以上の関係に基づいてある単語Ｗ１から別の単語Ｗ２が活性化され、これを次のユーザ発話に対する認識辞書の語彙に加える。さらに、認識結果に付随する尤度値ＬＦＫを高めるように音声認識モジュールのパラメータを調整する。ここで、（１）クラスタ辞書間の関係、（２）単語間の関係、（３）話題間の関係、（４）文脈の連続性、（５）ユーザの特性や状況に関して補足説明する。

［２．４．１ クラスタ辞書間の関係］
基本的には、上述した［２．３］辞書の構成で述べた関係に準ずる。
（例）施設→スキー場→おんたけスキー場
［２．４．２ 単語間の意味的関係］
［２．４．２．１ 包含関係］
（例）中華料理→シュウマイ、ラーメン、ギョーザ、……
（例）スポーツ→テニス、スキー、スイミング、ジョギング、……
［２．４．２．２ 連想関係］
（１）同一分類のオブジェクトを連想する場合
（例）うどん→麺類＋ラーメン
（２）シーンの構成要素を連想する場合
（例）ゲレンデ→スキー→リフト、スノーボード、ゴーグル、……
（例）ゴルフ→ゴルフ場→ホール、キャデイ、フェアウェイ、クラブ……
（例）海辺→海水浴→水着、ビーチパラソル、青い空、白い雲、……
（３）シーンに関連する興味の対象を連想する場合
（例）スキー→ゲレンデ、雪質、リフト……
（例）ゴルフ→天気、経路、費用、スコア、……
（４）季節から代表的なシーンを連想する場合
（例）夏→プール、海水浴、かき氷、セミ、クーラー、……
（５）要求キーワード間に基づく連想
（例）はらへった→レストラン
［２．４．３ 話題間の関係］
現在の話題に連関した話題のキーワードを活性化することにより、認識語彙を設定することができる。その連関のカテゴリは手段、付随する行動、よくある付帯事象、などがある。

（例）ショッピング
→駐車場（手段）、レストラン（付随する行動）、バーゲン（付帯事象）……
［２．４．４ 文脈の連続性］
［２．４．４．１ 話題の連続性］
通常の自然な対話に見られるように、ある話題（たとえばショッピングなど）で閉じた認識語彙の範囲で対話が継続することが考えられる。このような話題の連続性という制約のもとで認識語彙を設定することができる。

［２．４．４．２ 発話−応答の妥当性］
車室内に代表される対話環境では、ある発話内容（ユーザもしくはエージェントによる）は、｛呼びかけ、申告、通知、教示、解説、指示、依頼、警告、督促、問い合わせ｝のいずれかに分類できると考えることができる。一方、この発話に対する応答は、｛応答、確認、保留、判断、回答、その他応答｝に分類できる。この発話と応答の組み合わせを発話対、あるいは対話ユニットと呼ぶ。この対話ユニットに基づいて話題の内容によらず、文脈の論理的な連続性を定義することができる。図９中に「○」で示した部分は対話ユニットとして成立する発話−応答の組み合わせを示す。この対話ユニットをもとにしてエージェントは次のユーザ発話に含まれる認識語彙を予想して設定することができる。

以下、発話内容と、この発話に対する応答の具体例について説明する。なお、ユーザの発話については「…」で示し、エージェントの発話については『…』で示す。
（１）呼びかけ
一般的な意味での呼びかけや挨拶などがこれに含まれる。

（例）
呼びかけ：「おい、ＸＹＺ。」
返事 ：『はい、何ですか。』
（例）
呼びかけ：『おはようございます、今日はいい天気ですね。』
返事 ：「ああ、おはよう。」
（２）申告
（例）
申告：「今日は家族とドライブ。」
確認：『御家族とドライブですね。』
（３）通知
（例）
通知 ：『およそｌｋｍ先、渋滞です。』
無応答：「」、又は
確認 ：「わかった。」
（例）
通知：『私の名前はＸＹＺです。』
確認：「ＯＫ。」、「よろしく。」
（４）教示
（例）
教示：「今、雨が降ってきた。」
確認：『“現在、雨が降っている”というメッセージを確認しました。』
（５）解説
（例）
解説 ：『操作方法がわからないときはへルプといってください。』
無応答：「」
（６）指示
（例）
指示：『ユーザパスワードをしゃべってください。』
確認：「わかった。 ｘｘｘｘｘ」
（７）依頼
（例）
依頼：『そろそろガソリンが少なくなってきました。次の交差点のガソリン
スタンドで給油していただけませんか？』
保留：「いや、あとにしよう。」
（８）警告
（例）
警告：『１０ｋｍ先、○○トンネルで事故発生。次のインターで降りてくだ
さい。』
判断：「わかった、そうしよう。」
（９）督促
（例）
督促：『ユーザ名がまだ登録されていません。すぐに登録してください。』
確認：「わかった。」
（１０）問い合わせ
問い合わせには次の４種類がある。

１）合意要請
（例）：『御出にならないので電話接続を中止します。よろしいですか？』
２）選択要請
（例）問い合わせ：『Ａですか？ Ｂですか？』
回答 ：「Ａです。」
３）問い合わせ
場所、時間、情報など特定データの問い合わせをするユニットである。

（例）問い合わせ：「○○○○スキー場の積雪情報はどうなっている？」
（例）問い合わせ：『これからどちらへいかれますか？』
４）話題の確認
文脈から外れた突然の話題遷移が発生したことをユーザに確認する。

（例）
：「１２時に岡崎にいく。」「ねむい。」
問い合わせ：『”ねむい”と聞こえましたけど、岡崎の話はどうなりま
したか？』
［２．４・４・３ 対話ユニット間の接続性］
上記の対話ユニット内の呼応関係のみならず、対話ユニット間の接続（話題の遷移や呼び出し、終了を含む）の妥当性に関する制約も認識語彙の設定において考慮することができる。

［２．４．５ ユーザの特性や状況］
ユーザ発話に付随するユーザの環境・状況・要求・状態、ユーザプロファイルに基づいて次のユーザ発話に対応できる認識辞書を設定する。この場合、必ずしも上述の文脈の連続性が保たれるとは限らない。

（１）自然な要求推定
例えば本願出願人が特願平１０−１８４８４０号にて提案したような要求推定装置に基づくと共に、図２に示す要求・状態推定用データ記憶部３６に記憶された要求・状態推定用データを参照し、ユーザの環境・状況・要求・状態、ユーザプロファイルから次の認識語彙を限定する。

（２）突然の運転状況の変化
不連続的に発生する予測不可能な緊急事態や警告の対象となる事態に際して、文脈の連続性を一時停止し、事態に必要な話題を割り込ませるべく認識語彙辞書を設定する。

（例）
エージェント：これからどうなさいますか？』
ユーザ ：「○○駅前で買い物」
エージェント：『到着時刻は１１時ごろです。駐車場はどこにしますか？』
（先行車が急停止したので急ブレーキをかけた）
ユーザ ：「あー、危なかった。」
エージェント：『危なかったですね、安全運転にこころがけてください。お疲
れならば休みますか？』
（３）システムの機能移行
機能が切り替わったときにシステムが発話し、必要な対話を開始するべく認識語彙を設定する。

［２・５ 多段階処理の具体例］
多段階処理の具体例を、図１０，１１のフローチャートを参照して説明する。
ここでは、まず使用頻度の高いローカル情報を優先するかどうかを判断して（Ｓ２１０）、認識処理を２つにわける。なお、分岐条件はこれ以外にも考えられ、対話戦略に依存する。

ローカル優先の場合は（Ｓ２１０：ＹＥＳ）、代表的な場所、施設名、要求キーワード、要求関連属性でＮ語の辞書を構成し、ワードスポッティングをかけ（Ｓ２２０）、要求キーワードの尤度を構文評価で補正する（Ｓ２３０）。そして、キーワード属性の重み付けによって尤度を補正し（Ｓ２４０）、単語列の順序付け（Ｓ２５０）を行う。その後、認識完了した音声区間を次回の認識対象から外し（Ｓ３６０）、全音声区間を認識完了していなければ（Ｓ３７０：ＮＯ）、不足する属性の語彙を追加して辞書更新の準備をしてから（Ｓ３８０）、Ｓ２１０へ戻る。

なお、この場合はＳ２２０〜Ｓ２５０がローカル優先の場合の処理であり、この処理は「多段階処理」ではない。そして、このローカル優先の場合の処理によれば、１回の認識ですべての音声区間を処理可能であり、認識時間も少ないが、検索対象が例えば１００語に収まるように限られるため、日常的な要求から外れた発話の場合は誤認識になる確率が高くなる。

一方、ローカル優先でない場合、すなわち要求を優先する場合は（Ｓ２１０：ＮＯ）、まず、１回目の認識か否かを判断し（Ｓ２６０）、１回目の認識であれば（Ｓ２６０：ＹＥＳ）、認識属性を要求キーワードに設定して（Ｓ２７０）、Ｓ２８０へ移行する。２回目以降の認識であれば（Ｓ２６０：ＮＯ）、Ｓ２７０の処理は実行せずＳ２８０へ移行する。Ｓ２８０では、認識属性のキーワードを多く含む単語セットを構成し、その構成された単語セットを用いてワードスポッティングを実行する（Ｓ２９０）。

その後、要求キーワードの尤度が所定値（ここでは一例として０．６とする。）以上かどうかを判断し（Ｓ３００）、要求キーワードが０．６以上の尤度を持っていれば（Ｓ３００：ＹＥＳ）、Ｓ３１０へ移行する。Ｓ３１０では、同一属性の単語が複数ある場合は構文位置を優先する。つまり、これで要求キーワードに基づく要求が確定し、続くＳ３２０においては、ヒットしたキーワードに対応する属性を次回の認識語彙に設定する。その後は、認識完了した音声区間を次回の認識対象から外し（Ｓ３６０）、全音声区間を認識完了していなければ（Ｓ３７０：ＮＯ）、不足する属性の語彙を追加して辞書更新の準備をしてから（Ｓ３８０）、Ｓ２１０へ戻る。

一方、要求キーワードの尤度が０．６未満の場合は（Ｓ３００：ＮＯ）、Ｓ３３０へ移行し、他の属性で尤度が０．６以上の単語があるか否かを判断する。そして、尤度が０．６以上の単語があれば（Ｓ３３０：ＹＥＳ）、その中で最も尤度が高い単語を認識属性とし、その認識属性のキーワードを多く含む単語セットを構成してワードスポッティングを実行する（Ｓ３４０）。しかし、尤度が０．６以上の単語がなければ（Ｓ３３０：ＮＯ）、場所、施設名、要求関連属性でＮ語の辞書を構成し、ワードスポッティングを実行する（Ｓ３５０）。Ｓ３４０，Ｓ３５０の処理後は、認識完了した音声区間を次回の認識対象から外し（Ｓ３６０）、上述したとおり、全音声区間を認識完了していなければ（Ｓ３７０：ＮＯ）、不足する属性の語彙を追加して辞書更新の準備をしてから（Ｓ３８０）、Ｓ２１０へ戻る。

一方、全音声区間を認識完了していれば（Ｓ３７０：ＹＥＳ）、単語列の推定をし（図１１のＳ３９０）、エコーバックして（Ｓ４００）、不足条件を問い合わせる発話を行う（Ｓ４１０）。その後、ユーザの応答が否定的発話（例えば、違う、そうじゃない、など）かどうかを判断し、否定的発話でなければ（Ｓ４２０：ＮＯ）、不足する属性の語彙を追加して辞書更新の準備をしてから（Ｓ４３０）、図１０のＳ２１０へ戻る。一方、否定的発話であれば（Ｓ４２０：ＹＥＳ）、Ｓ４４０〜Ｓ４７０の誤認識対応処理を実行する。

具体的には、Ｓ４４０にてモード設定に基づいて分岐し、連続単語認識に切り替えてユーザに発話方法を指示するか（Ｓ４５０）、ヘルプモードとして要求キーワードを入れるようユーザに指示する（Ｓ４６０）、漸進的階層探索として認識可能な語彙を表示するか（Ｓ４７０）、のいずれかを実行する。その後は、不足する属性の語彙を追加して辞書更新の準備をしてから（Ｓ４８０）、図１０のＳ２１０へ戻る。

このような処理を、例えば「えーと、あんじょうでらーめんをくいたい」といったユーザ発話音声に対して実行した場合について説明する。まず、音声区間から要求キーワード（くいたい、など）を優先的に検出する。このために、認識語彙も要求キーワードを多く含む（要求の種類や同一要求に対する同義語・類義語・連想語を充実させる）構成にする。しかし、この要求優先の場合、１回のワードスポッティングでは認識が完了しない。したがって、図６に示したように要求キーワードが確定（食事関連）した後に次の施設名や要求対象をそれぞれ１回のワードスポッティングに対応させて認識を繰り返し、すべての音声区間を認識終了した時点で単語列推定を駆動させて単語列認識結果を絞り込む。なお、この単語列認識結果の絞り込みの詳細については、例えば特願平１１−２０３４９号を参照されたい。

これをもとにシステムは「あんじょうでらーめんをたべるんですね」といったエコーバックの発話を行い（Ｓ４００）、論理的発話戦略の駆動により不足条件を問い合わせる発話（Ｓ４１０）として「あんじょうには３けんらーめんやがあります。みせはどこにしますか？」と発話する。これに対してユーザは、まったく異なる発話「○○でれいぞうこをかいたい」と発していたとすると、上述のエコーバック結果に対しては否定的応答（「ぜんぜん違う」など）を発話する（Ｓ４２０：ＹＥＳ）。したがってその場合は誤認識対応処理（Ｓ４４０〜Ｓ４７０）が駆動される。

一方、否定的応答がなされない場合（Ｓ４２０：ＮＯ）、ユーザとの問で正しく対話がなされているとエージェントは解釈し、次にユーザが発話すると期待されるキーワード群（いっけんめ」、「すしやにかえて」など）を認識語彙辞書に設定して（Ｓ４３０）、ユーザの発話を待つ。

[３．誤認識対応処理について］
音声認識部から出力される認識語彙の尤度判定と語彙限定、ユーザからのへルプ要求、画面表示の支援に基づく入力の簡単化（スイッチ操作の併用）、不足条件の判定、サービス内容の有機的連関付けなどに基づきへルプ、選択肢の提示、初期化、問いかけを駆動する。

［３．１ 誤認識の検出］
エージェントがユーザ発話を認識できていない状況は誤認識であり、以下のケースがある。

１）どの認識辞書にもない言葉をユーザが発話
２）他の辞書にはあるが、現在使っている辞書にない言葉をユーザが発話
３）ユーザ以外の話者の発話内容に応答し、ユーザの意図に反してモード移行
このような状況は、エージェントの応答に対してユーザが「ちがう」、「わかってないね」、「全然だめ」といった発話をすることで検出される。この場合、下記のいずれかの対話内容をユーザの状況に応じて選択する。

（１）音声メニューモード
（２）選択肢を出す
なお、例えば「ちがう」などの発話がユーザからＫ回以上繰り返されたときは初期状態
に戻る。Ｋは例えば５とする。

［３．１．１ 期待外の応答であることの検出
認識語に付随する尤度のしきい値処理に基づき、尤度が低い場合は音声認識の信頼度が低いため認識語彙以外の発話がなされたとして、［誤認識の可能性有り］と判定する。

［３．２ 話題転換の検出］
ユーザ発話がエージェントの期待から外れているかどうかはそれまでの文脈に沿っているかどうか、即ちある話題の中で予想される発話かどうかで判定する。予想される発話は「２．４単語間のネットワーク」で示した単語間の関係をもとにして導出され、これに対応する語彙を認識辞書に設定する。これを便宜上ケースＡと呼ぶ。それ以外の場合は、予想されない発話であり、それを構成する単語は下記のように分類できる。

（Ｂ１）認識語彙辞書に登録されていない単語
（Ｂ２）認識語彙辞書に登録されているが、違う話題の単語
（Ｂ２ａ）現在の認識語彙範囲に含まれている単語
（Ｂ２ｂ）現在の認識語彙範囲に含まれていない単語
このうち、（Ｂ１）と（Ｂ２ｂ）は通常のワードスポッティングでは認識され得ないため、不用語とみなされるかあるいは信号処理的に近いとみなされる他の認識可能語彙に置き換えられて出力される。これらは後述の誤認認処理で対応する。

一方、（Ａ）と（Ｂ２ａ）については以下の３つの処理形態で対応する。
（１）文脈優先処理［（Ａ）の場合］
出力された複数の認識候補（ラティス）間に尤度の差異があまり認められない（分散が小さい）とき、文脈に沿った認識候補が優先して選ばれる。

（２）突然の話題の遷移（話題転換）［（Ｂ２ａ）の場合］
出力した認識候補が１個であり、ある一定しきい値以上の尤度を持つ場合、この話題に突然遷移したことを認める。

（３）突然の話題の遷移の確認［（Ｂ２ａ）の場合］
出力した認識候補が１個であるが、ある一定しきい値以上には満たない尤度を持つ場合、この話題に突然遷移したのかどうかを確認するため、ユーザに問い合わせる。

［３．２．１ 話題転換の検出］
現在の話題とは異なる要求キーワードが認識された場合には話題が転換した可能性があるとみなす。

［３．２．２ 話題転換の確認］
上記に基づき、システムはユーザに対して話題が転換したことを確認する問いかけの発話を生成する。

（例）
エージェント『□□駅前には３件のラーメン屋があります。』
ユーザ 「東京の○○さんに電話をかける」
エージェント『電話をかけますか？』
ユーザ 「うん。東京の○○さんに」
エージェント『東京の○○さんに電話をかけます』
［３．２．３ 話題転換の発話］
話題が転換したことを宣言する発話を生成する（上記例参照）。

［３．３ 文脈優先の発話］
それまでの話題Ｔ(ｎ)（ｎ：発話対の通し番号）が継続していると仮定し、次回のエージェント発話もその話題に基づいて生成する。従って、今回のユーザ発話の解釈結果Ｕ(ｎ)が話題Ｔ(ｎ)に関連しない語彙であっても、それに即応せずに、話題Ｔ(ｎ)からの文脈に沿って発話内容に限定処理を加える。

（例）
エージェント『○○駅前には３件のラーメン屋があります。』
・・・・・・・・・・・・・・・・・・・｛Ｔ(ｎ)＝食事｝
ユーザ 「あっ、電話かけなきゃ。」
・・・・・・・・・・・・・・・・・・・｛「電話」が認識され
ればＴｎｅｗ＝電話だが話題を更新しない｝
エージェント『どのラーメン屋にしますか？』
・・・・・・・・・・・・・・｛Ｔ(n+1) ＝Ｔ(ｎ)＝食事｝
ユーザ 「えーと、□□」
エージェント『□□へのルートを表示します。』
なお、上述した話題転換と、ここで説明した文脈優先は相反する応答だが、例えば、その条件判断はＵ(ｎ)の尤度情報ＬＦＫやＵ(ｎ)で示される話題Ｔnew の連続出現回数Ｎtnewなどを用いる。即ち、Ｎtnew＞２且つＬＦＫ＞０．４ならば話題はＴ(n-1) からＴ(ｎ)＝Ｔnew に移行し、それ以外の場合はＵ(ｎ)から得られたＴnew は棄却し、Ｔ(ｎ)＝Ｔ(n-1) とする、といった条件分岐を用いる。

［３．４ ヘルプモード］
起こりやすい誤認識の例、代表的な要求キーワード、などの選択肢を表示したり音声で発話する。

（例）
・電話をかける場合は、「でんわをかける」で電話番号画面を表示し、相手先の電話番号を入力してください。登録されている相手先（例えば○○さん）の場合は「でんわをかける、○○」でも結構です。

・次のどれですか？もういちど発話してください。｛食事（レストラン、ごはん、おなかすいた）、スケジュール帳、アドレス帳（住所録、電話帳）、地図（経路案内、ドライブアシスタント）｝
・かっこ内の同義語でもう一度発話してください。

・地図表示の場合は、経路案内から道路図を選択したほうが確実です。
・目的地は市町村をつけて発話した方が正確です。（例 かりや→かりやし）
［３．５ 選択肢の提示］
選択肢提示は既に説明した漸進的階層探索に相当する。

［３．６ 通常の発話戦略］
認識結果（認識語、尤度）をもとに誤認識が検出されなかった場合は通常の発話戦略が適用される。この通常の発話戦略の内容は本発明の主眼とするところではないので、ここでは詳細については言及しない。

［３．７ 対話管理の適応化］
［３．７．１ 環境・状況への適応］
時間（季節、日時、時刻［朝昼夜］）、空間（自車位置、地域［都道府県、市町村］）、環境（道路環境［高速、一般道、トンネルなど］、道路状態［路面凍結、滑り易い、他］、交通環境［高速道路、速度制限など］、地理環境［海が近い、山の中、街中、駅前、など］）、車外状況（天候、交通状況［渋滞など］、車外周辺状況［追い越し車あり、など］）、車内状況（運転状態、乗車状態、移動目的、話題）などに応じて、話題の選定や対話管理、適切なメッセージの伝達などを行うことができる。なお、これらは表示系にも反映される。

［３．７．２ スケジュールへの適応］
（１）ドライブスケジュール
ユーザの設定した目的地や経由地に基づき、ドライブスケジュールを作成し、各イベントの意味（食事、ショッピング、観光など）と場所・時間に基づいて、話題の決定や対話管理、さらにはドライブスケジュールの空白部分について提案することができる。

（２）個人スケジュール
ＰＤＡやＰＣ用のインタフェースを介してＰＤＡやＰＣ上の個人スケジュールデータをダウンロードし、それに基づいて話題の決定や対話管理、さらには個人スケジュールの空白部分について提案することができる。

［３．７．３ ユーザが応答の意味を理解できないとき］
ユーザが「どういう意味」、「よくわからん」といった発話をしたとき、ユーザはエージェント応答の意味を理解できていないと判断し、次のいずれかの処理を行う。

（１）ヘルプ機能
（２）メニュー選択
（３）音声メニュー
［３．７．４ エージェントがユーザ要求に対応できないとき］
ユーザ発話を正常に認識できても、以下のような場合ではエージェントがユーザの要求に対応できないときがある。これらについてはその状況を音声メッセージで伝達する。

１）検索結果がない（該当データベースがない）
２）該当する機器がない、故障中あるいは準備されていない（電話が接続されていない、など）
３）操作対象となる機器の動作範囲を超えた制御命令が出されたとき
［３．８ 音声メニューモード］
例えば本願出願人が特願平１０−１７７６６７号にて提案したような機器操作モードに移行する。各操作モードにおいて必要なコマンドは必ず優先的に認識語彙辞書に加え、認識の尤度を高める。

［３．９ 問い返し］
問い返しは下記のようにいくつかの場合が考えられ、問い返す場合にはその内容に沿った語彙に限定した認識辞書が設定される。

（１）エージェントが正しく話題を認識しているにもかかわらず、それに沿ったユーザ発話がなされなかった場合、話題確認のための問い返しを発することにより、それ以後の誤認識を回避する。

（例）
エージェント『□□駅前には３件のラーメン屋があります。』
ユーザ 「東京の○○さんに電話をかける」
エージェント『電話をかけますか？』
（２）エージェントが話題を間違えて認識し、ちがう話題のもとで不足条件を問い合わせた場合、ユーザからの問い返し又は否定的発言（「ちがうよ」や「そうじゃない」など）により、正しい話題が何であるかを問い返す。これにより、それ以後の誤認識に歯止めをかける。

（例）
ユーザ 「東京の○○さんに電話をかける。」
エージェント『□□駅付近のレストランを表示します。どれにしますか？』
ユーザ 「そうじやない、電話をかける」
エージェント『電話ですか、食事ですか？』
ユーザ 「でんわ」
これは、すでにレストラン検索依頼が出ており、その検索をしている最中にユーザが電話をかけるという割り込み要求を行った場合である。２つの用件（電話か食事か）の優先順位を問い返した例と言える。

（３）エージェントが正しく話題を認識し、文脈上必要な条件が不足していることを確認した上で問い返す。これにより、文脈に沿った正しい対話が展開され、問題解決を促進する。

（例１）
ユーザ 「東京の○○さんに電話をかける。」
エージェント『東京の○○さんに電話をかけるんですね。それは○○◇◇さん
ですか、それとも○○△△さんですか？』
ユーザ 「○○◇◇さん」
エージェント『○○◇◇さんに電話をかけます』
（例２）
ユーザ 「東京の○○さんに電話をかける」
エージェント『□□駅付近のレストランを表示します。どれにしますか？」
ユーザ 「あとにして。先に電話をかける。」
エージェント『東京の○○◇◇さんに電話をかけます．よろしいですね。」
ユーザ 「うん、そうして」
ここで説明した（例１）の場合は、エージェントが正しく認識し、電話をかけるという問題解決に向けて不足している条件を問い合わせた例である。

また、（例２の）場合には、ユーザが電請をかける意図がそれまでの対話の経過やスケジュールなどでわかっているならば、その電話の用件（○○さんと食事する）で必要な情報を事前に検索することが可能になる。つまり、気を回して自主的にレストラン検索を行い、問い返した例と言える。

［３．１０ 初期化］
ユーザからの問い返しがＫ回（Ｋ＞Ｎ）を超える場合、初期状態あるいはトップのメニュー画面に戻る。

以上説明したように、本実施形態の制御システムによれば、漸進的階層探索、多段階処理、期待外時対応処理、誤認識対応処理を行うが、それぞれの処理によって以下の効果がある。

まず、漸進的階層探索の場合には、上述した「岡崎で食事したいなあ、インド料理がいいね」という発話を例に取れば、ワードスポッティングによる音声認識手法の出力結果が「岡崎、食事、インド料理」という単語列であった場合、従来の音声認識手法では、これ
ら３つが揃った段階で認識に対応するシステム側の処理が開示されているのに対し、本手法によれば、「岡崎」が入力された時点で、次に利用者に入力を期待する発話語彙を即座に提示できる。そのため、利用者はとまどうことなく発話できるようになる。これによって、誤認識の原因となる認識辞書外の語彙を利用者が発話してしまうことを未然に防止できる。

また、多段階処理の場合には、単語列を構成する要求キーワードなどを軸として、単語列を構成する単語間の意味的な制約を利用して認識辞書を動的且つ小規模に構成することにより、適切な認識を行う。これによって、利用者の意図しない誤認識が発生しないようにできる。

また、期待外時対応処理においては、対話中における利用者からの発話が文脈に沿った期待通りの内容ではない場合に、話題が転換されたのかどうかを確認するための問いかけを行う話題転換確認処理、話題が転換されたことを宣言する話題転換宣言処理、それまでの話題が継続していると仮定して文脈に沿った対応を行う文脈優先対応処理のいずれかを行う。一方、誤認識対応処理においては、対話中における利用者からの発話が所定の否定的内容であった場合に、正しい話題が何であるかを確認するための問い返す問い返し処理や、要求する内容に対応したキーワードを含める指示を利用者が視覚又は聴覚にて認識可能なように提示するヘルプモード処理や、初期状態に戻る初期化処理などを実行する。このようにすることで、誤認識に起因して利用者が途方に暮れてしまう、といった不都合を防止することができる。

さらに、本実施形態の場合には、これら漸進的階層探索、多段階処理、期待外時対応処理、誤認識対応処理が組み合わされているため、さらに効果的である。
ところで、本実施形態においては、例えば自動車に搭載されて、ユーザとしての車両の乗員（主に、運転者）と音声にて対話しながら、その車両に搭載された様々な機器を制御するシステムとして説明したが、図１の概念図に示すように、その他の信号系認識部にて認識した結果としての単語列候補に対しても同様の処理が可能である。例えば、認識対象者によって入力された手書き文字列を辞書データと比較し、一致度合の高い複数の単語列候補を出力する文字認識装置であってもよい。手書き文字に関してもやはり誤認識が発生し易いため、適正な単語列を推定することは有効性が高い。また、音声認識や文字認識のように、認識装置に入力される時点で直接的に単語列の内容となっているものに限らず、画像認識装置であってもよい。即ち、認識対象を捉えた画像を場面として認識した上で、場面を自然言語化するような認識装置であれば実現できる。具体的には、例えば認識対象者が手話をしている画像から手話パターンを認識し、その手話パターンが表す自然言語的な意味を示す単語列候補を出力するようなものである。手話パターンについても、微妙な指使いによって表す単語が異なるため、手話をする者の個人差などによって、やはり誤認識は発生する。したがって、やはりこの場合も、誤認識が含まれる可能性の高い手話パターンの認識装置においても、上述した各種処理を実行することで、誤認識を防止したり、あるいは誤認識が発生した後の適切な対処を行うことができ、誤認識に起因して利用者が途方に暮れてしまう、といった不都合を防止することができる。

以上、本発明の一実施形態について説明したが、本発明は、上記実施形態に限定されるものではなく、種々の形態を採り得ることは言うまでもない。
例えば、図３の処理概要を示すフローチャートにおいては、多段階処理（Ｓ３０）が先に行われ、その後の誤認識対応処理の中で漸進的階層探索（Ｓ１３０が相当する）が実行されているが、そのような順番には限定されない。

また、上記実施形態の場合には、漸進的階層探索、多段階処理、期待外時対応処理、誤認識対応処理が組み合わされていたが、これらは単独で実施しても効果はある。但し、上述したように、組み合わせて実施すればさらに効果的である。その際、４つの処理を全て組み合わせなくてはならないわけではなく、２つ以上の処理の組み合わせであればよい。

実施形態の単語列認識装置について機能に着目して概念的に示したブロック図である。 単語列認識装置を車載の制御システムに適用した場合の構成を示すブロック図である。 システム制御部で実行される処理の概要を示すフローチャートである。 漸進的階層探索の具体的な画面遷移例を示す説明図である。 漸進的階層探索の具体的な画面遷移例を示す説明図である。 多段階処理の概要を示す説明図である。 辞書の動的構成の概要を示す説明図である。 対話データベース表の構成を示す説明図である。 対話ユニットとして成立する発話−応答の組み合わせを示す説明図である。 多段階処理の前半を示すフローチャートである。 多段階処理の後半を示すフローチャートである。

符号の説明

１…制御装置、３…入力装置、５…マイクロフォン、７…スピーカ、８…ディスプレイ、９…ナビゲーション装置、１１…表示装置、１３…エアコン装置、１５…オーディオ装置、１７…通信装置、２１…システム制御部、２５…音声入力部、２７…音声合成部、２８…画面制御部、２９…機器制御Ｉ／Ｆ、３１…インターネットアドレスデータベース、３３…検索制御部、３４…認識語彙記憶部、３５…対話データ記憶部、３６…要求・状態推定用データ記憶部、３７…ユーザプロファイル記憶部。

Claims (3)

1. 認識対象の動作内容が反映された情報を入力し、認識用辞書データと比較した一致度合いの高い単語列の候補を出力する単語列出力手段と、
   その単語列出力手段から出力された単語列を構成する単語の内、所定の属性を持つ単語に基づいて話題を確定し、続いて、その確定した話題に基づく語彙に限定した前記認識用辞書データを再構成し、その再構成した認識用辞書データに基づいて他の単語を認識するという処理を必要なだけ繰り返し実行する多段階処理手段と
   を備え、
   前記多段階処理手段が最初に前記話題を確定するために扱う単語属性は、要求内容を示す属性であり、
   さらに、認識対象の要求を推定する要求推定手段を備え、
   前記話題に基づく語彙に限定した認識用辞書データを再構成する際には、
   話題、時間・位置、ユーザの置かれた環境・状況、ユーザの状態・要求、ユーザ発話・エージェント発話・制御出力という属性の組で構成される対話ベクトルおよびその集まりである対話データベースの中でユーザ発話を位置づけ、
   そのユーザ発話に関して、現在の話題に連関する話題に対応する語彙、文脈の連続性という観点から定まる語彙、前記要求推定手段にて推定した要求という観点から定まる語彙についても考慮すると共に、不連続的に発生する予測不可能な緊急事態や警告対象となる事態に対応する語彙として予め設定した語彙を含めることを特徴とする単語列認識装置。
2. 認識対象の動作内容が反映された情報を入力し、認識用辞書データと比較した一致度合いの高い単語列の候補を出力する単語列出力手段と、
   その単語列出力手段から出力された単語列を構成する単語の内、所定の属性を持つ単語に基づいて話題を確定し、続いて、その確定した話題に基づく語彙に限定した前記認識用辞書データを再構成し、その再構成した認識用辞書データに基づいて他の単語を認識するという処理を必要なだけ繰り返し実行する多段階処理手段と
   を備え、
   前記話題を確定するために扱う所定の属性を持つ単語が複数存在する場合は、構文位置に基づいていずれか１の単語を選択し、
   さらに、認識対象の要求を推定する要求推定手段を備え、
   前記話題に基づく語彙に限定した認識用辞書データを再構成する際には、
   話題、時間・位置、ユーザの置かれた環境・状況、ユーザの状態・要求、ユーザ発話・エージェント発話・制御出力という属性の組で構成される対話ベクトルおよびその集まりである対話データベースの中でユーザ発話を位置づけ、
   そのユーザ発話に関して、現在の話題に連関する話題に対応する語彙、文脈の連続性という観点から定まる語彙、前記要求推定手段にて推定した要求という観点から定まる語彙についても考慮すると共に、不連続的に発生する予測不可能な緊急事態や警告対象となる事態に対応する語彙として予め設定した語彙を含めることを特徴とする単語列認識装置。
3. 認識対象の動作内容が反映された情報を入力し、認識用辞書データと比較した一致度合いの高い単語列の候補を出力する単語列出力手段と、
   その単語列出力手段から出力された単語列を構成する単語の内、所定の属性を持つ単語に基づいて話題を確定し、続いて、その確定した話題に基づく語彙に限定した前記認識用辞書データを再構成し、その再構成した認識用辞書データに基づいて他の単語を認識するという処理を必要なだけ繰り返し実行する多段階処理手段と
   を備え、
   前記話題を確定するために扱う所定の属性を持つ単語は、所定レベル以上の尤度を備えている場合にのみ採用し、
   さらに、認識対象の要求を推定する要求推定手段を備え、
   前記話題に基づく語彙に限定した認識用辞書データを再構成する際には、
   話題、時間・位置、ユーザの置かれた環境・状況、ユーザの状態・要求、ユーザ発話・エージェント発話・制御出力という属性の組で構成される対話ベクトルおよびその集まりである対話データベースの中でユーザ発話を位置づけ、
   そのユーザ発話に関して、現在の話題に連関する話題に対応する語彙、文脈の連続性という観点から定まる語彙、前記要求推定手段にて推定した要求という観点から定まる語彙についても考慮すると共に、不連続的に発生する予測不可能な緊急事態や警告対象となる事態に対応する語彙として予め設定した語彙を含めることを特徴とする単語列認識装置。