(57)【要約】【課題】  ベクトル情報を含む問合せ記述及びコンテンツ記述を用いて検索を行う情報検索システムにおいて、検索処理の適応化を実現する。【解決手段】  ユーザ端末３のベクトル検索・生成・修正部３４は、ベクトルプロファイル３５、問合せ履歴３６、ユーザモデル３７、ユーザプロファイル３８に基づき、問合せベクトルの生成や修正、最適化を行う。一方、情報センター５のベクトル検索・生成・修正部５４は、ベクトルテーブル５５、検索履歴５６、内容記述データベース５９に基づき、特徴ベクトルの生成や修正、最適化を行う。情報センター５では、問合せベクトルを含む問合せプロファイルがユーザ端末３から送信されると、適応的な検索処理を実行し、コンテンツ評価部６０による評価に従って、コンテンツデータベース６１から適切なコンテンツを検索する。【選択図】  図２
2006228255.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一部がベクトルとして定義される情報である、問合せに対応する問合せ情報、及び、検索対象となるコンテンツに付加される特徴情報を用いて、コンテンツの評価を行うことにより、高速検索を可能にする適応的情報検索システムであって、
前記コンテンツの評価を適応的に行う検索手段を備えていること
を特徴とする適応的情報検索システム。
【請求項２】
請求項１に記載の適応的情報検索システムにおいて、
前記検索手段は、検索時間の指標となる高速化率を計算することにより、検索手法を選択すること
を特徴とする適応的情報検索システム。
【請求項３】
請求項１又は２に記載の適応的情報検索システムにおいて、
前記検索手段は、前記問合せ情報に含まれる問合せベクトルと前記特徴情報に含まれる特徴ベクトルとに基づいて、前記コンテンツを評価すること
を特徴とする適応的情報検索システム。
【請求項４】
請求項３に記載の適応的情報検索システムにおいて、
前記検索手段は、前記問合せ情報に含まれる検索キーワードと前記特徴情報に含まれる特徴キーワードとに基づいて、前記コンテンツを評価すること
を特徴とする適応的情報検索システム。
【請求項５】
請求項４に記載の適応的情報検索システムにおいて、
前記検索手段は、過去の検索履歴に基づいて、前記検索キーワードあるいは前記特徴キーワードを生成可能であること
を特徴とする適応的情報検索システム。
【請求項６】
請求項４又は５に記載の適応的情報検索システムにおいて、
前記検索手段は、前記検索キーワードあるいは前記特徴キーワードに基づき、キーワードの連想を行ってキーワードを拡張すること
を特徴とする適応的情報検索システム。
【請求項７】
請求項４〜６のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、前記検索キーワードや前記特徴キーワードを数値化することにより、前記コンテンツを評価すること
を特徴とする適応的情報検索システム。
【請求項８】
請求項３〜７のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、前記検索キーワードや前記特徴キーワードに基づき、前記問合せベクトル及び前記特徴ベクトルによるコンテンツ評価を変更すること
を特徴とする適応的情報検索システム。
【請求項９】
請求項３〜８のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、コンテンツ評価を、ユーザの個別情報に基づいて変更すること
を特徴とする適応的情報検索システム。
【請求項１０】
請求項３〜９のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、前記問合せベクトル及び前記特徴ベクトルの特定の属性基底について優先的にコンテンツ評価を行うこと
を特徴とする適応的情報検索システム。
【請求項１１】
請求項３〜１０のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、前記特徴ベクトルにて張られる特徴空間のクラス分けに基づいて、前記コンテンツ評価を行うこと
を特徴とする適応的情報検索システム。
【請求項１２】
請求項３〜１１のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、必要に応じて前記問合せベクトルや前記特徴ベクトルを拡張可能であること
を特徴とする適応的情報検索システム。
【請求項１３】
請求項３〜１２のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、問合せ情報に基づいて、前記特徴ベクトルにて張られる特徴空間の構造化や分割を行うこと
を特徴とする適応的情報検索システム。
【請求項１４】
請求項３〜１３のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、問合せ情報に基づいて、前記特徴ベクトルの再配置や移動を行うこと
を特徴とする適応的情報検索システム。
【請求項１５】
請求項３〜１４のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、前記特徴ベクトルの属性値が不定値である場合に、平均値あるいは「０」を用いて、コンテンツを評価すること
を特徴とする適応的情報検索システム。
【請求項１６】
請求項３〜１５のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、コンテンツに対する記述であるコンテンツ記述を適応化すること
を特徴とする適応的情報検索システム。
【請求項１７】
請求項３〜１６のいずれかに記載の適応的情報検索システムにおいて、
前記検索手段は、前記特徴ベクトルで張られる特徴空間へ前記問合せベクトルをマッピングするにあたって、座標系の変更を行うことにより、視点の変更を実現すること
を特徴とする適応的情報検索システム。
【請求項１８】
請求項１７に記載の適応的情報検索システムにおいて、
前記座標系の変更は、ユーザの個人情報に基づいてなされること
を特徴とする適応的情報検索システム。
【請求項１９】
請求項１７又は１８に記載の適応的情報検索システムにおいて、
前記座標系の変更は、ユーザ情報をモデル化したユーザモデルに基づいてなされること
を特徴とする適応的情報検索システム。
【請求項２０】
請求項１〜１９のいずれかに記載の適応的情報検索システムにおいて、
さらに、検索結果に基づいて、格納情報の更新を行う更新手段を備えていること
を特徴とする適応的情報検索システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高速検索エンジンに関し、特に、ユーザ要求を把握して適切なコンテンツを高速に検索する技術に関する。
【背景技術】
【０００２】
近年、インターネットの爆発的普及に伴い、さまざまな高速検索エンジンが用いられている。
現在の情報検索手法は大きく分けて、次の２つに分類される。
【０００３】
全文検索：数単語のキーワードを入力し、この入力されたキーワードを含む文書を検索する。
類似検索：インデックス検索と、入力検索キーとして文書あるいはキーワードを指定し、指定された入力検索キーと類似した文書を検索する
しかしながら、このように、いわゆるキーワードを用いた検索には限界があり、検索結果に不必要な情報が数多くヒットするため、真に必要とする情報を得ることができない。また、曖昧な利用者の要求を把握できない。
【０００４】
これを解決するための手法として、ベクトル空間モデル（ＶＳＭ）を用いたものがある。この手法では、入力文書の単語の有無や出現数を特徴量とし、検索対象データと入力文書の類似度を算出する。ＶＳＭを用いる手法では、特徴ベクトルの算出手法、ベクトル間の距離について盛んに研究が行われており、Cornell 大学のSMART 、City大学のOkapi 、Massachusetts 大学のINQUERY などが知られている。ところがこれらは文書中に含まれる単語の発生頻度を軸としてベクトルを構成したものであり、ある検索キーワードに対する相対関係はわかっても、文書内容の意味的特徴やユーザの検索意図への適合性は評価できない。
【０００５】
そこで、本出願人は、特願２００１−１３６５号で、依存性ベクトルを用いた高速検索手法を提案した。これはコンテンツの意味的特徴に関する各種属性群へのユーザの関心度を依存性として定義しベクトルを構成したものであり、ユーザ要求を定量的に表すことができ、ユーザ適応型の高速検索と類似検索を可能にした。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところが、上述の検索手法においても、次のような点では改良の余地が残される。
それは、主として、
１）問い合せ記述の自動生成及び最適化が困難であること
２）コンテンツ記述の自動生成及び最適化が困難であること
である。
【０００７】
さらに、ユーザ適応型という観点からは、
３）検索処理の適応化
４）システムの学習更新
が望まれる。
【０００８】
本発明は、依存性ベクトルという思想をさらに拡張し、包括的に機能する情報検索システムを提供することを目的とし、特に、検索処理の最適化を目的とする。
【課題を解決するための手段】
【０００９】
本発明の適応的情報検索システムは、問合せに対応する問合せ情報、及び、検索対象となるコンテンツに付加される特徴情報を用いて、コンテンツの評価を行うことにより、高速検索を可能にする適応的情報検索システムである。この適応的情報検索システムは、コンテンツの評価を適応的に行う検索手段を備える。なお、問合せ情報及び特徴情報は、少なくとも一部がベクトルとして定義されている。
【００１０】
問合せ情報は、問合せの特徴を示す問合せベクトルと検索キーワードとを含むものとすることが考えられる。問合せベクトルは、コンテンツの意味的特徴に関する各種属性群へのユーザの関心度を依存性として定義した依存性ベクトルや、その他の属性を示す属性ベクトルで構成することができる。検索キーワードは、ユーザの個別具体的な情報を表現する。このような問合せ情報を用いれば、問合せベクトルによる検索結果を、さらに、検索キーワードで絞り込むといった検索が可能になる。
【００１１】
その他、特徴情報は、コンテンツの特徴を示す特徴ベクトルと特徴キーワードとを含むものとすることができる。
また、検索手段は、検索時間の指標となる高速化率を計算することにより、検索手法を選択する構成を採用することが考えられる（請求項２）。つまり、特徴ベクトルが問合せにヒットした場合の処理時間を考えて高速化率を算出すれば、特徴ベクトルによる検索の有効性を判断することができ、検索手法を選択する指標となる。これによって、適応的に高速性を追求する検索が可能となる。
【００１２】
その他、検索手段は、問合せ情報に含まれる問合せベクトルと特徴情報に含まれる特徴ベクトルとに基づいて、コンテンツを評価することが考えられる（請求項３）。さらに、問合せ情報に含まれる検索キーワードと特徴情報に含まれる特徴キーワードに基づいて、コンテンツを評価することが考えられる（請求項４）。ベクトルに基づくコンテンツ評価は、一例としてベクトルの内積演算で達成できる。これにより、コンテンツ評価の高速性が確保される。ただし、ヒットしたコンテンツが膨大になった場合など、キーワードによる２次的な評価が有効となる。
【００１３】
さらに、検索手段は、過去の検索履歴に基づいて、検索キーワードあるいは特徴キーワードを生成できる構成としてもよい（請求項５）。また、検索手段は、検索キーワードあるいは特徴キーワードに基づき、キーワードの連想を行ってキーワードを拡張するようにしてもよい（請求項６）。このようにすれば、あいまいな問合せからでも、キーワードによるコンテンツ評価を行うことができる。
【００１４】
キーワードによるコンテンツ評価は、検索キーワードや特徴キーワードを数値化することにより実現することが考えられる（請求項７）。このような数値化によって、複数のキーワードに対する定量的な比較が実現できる。
【００１５】
そして、検索手段が、検索キーワードや特徴キーワードに基づき、問合せベクトル及び特徴ベクトルによるコンテンツ評価を変更するようにしてもよい（請求項８）。キーワードによる個別的な評価により、あいまいさを残すベクトル評価を修正するのである。これによって、より適切なコンテンツ評価が可能となる。同様に、検索手段が、ベクトルやキーワードに基づくコンテンツ評価を、ユーザの個別情報に基づいて変更することが考えられる（請求項９）。これは、ユーザの個別情報によって、コンテンツ評価が大きく変わる可能性があるためである。
【００１６】
ところで、検索の高速化という観点からは、検索手段が、問合せベクトル及び特徴ベクトルの特定の属性基底について優先的にコンテンツ評価を行う構成とすることが考えられる（請求項１０）。例えば、ユーザの場所依存性や時間依存性などといった支配的な属性基底について優先的にコンテンツ評価を行うことにより、適切にコンテンツに絞り込みをかけることができる。あるいは、特徴ベクトルにて張られる特徴空間のクラス分けに基づいて、コンテンツ評価を行うことが考えられる（請求項１１）。このクラス分けは、支配的な属性基底における特徴空間の部分空間をクラスとして定義することを意味する。このようにすれば、上述したのと同様に、適切にコンテンツに絞り込みをかけることができる。したがって、これらの構成を採用すれば、より高速な検索を実現することができる。
【００１７】
なお、問合せベクトルも特徴ベクトルも属性基底を動的に決定する構成を採用した場合には、共通の属性基底、すなわち、両方のベクトルの交わり部分が変化する。そこで、検索手段は、必要に応じて問合せベクトルや特徴ベクトルを拡張可能な構成とすることが望ましい（請求項１２）。このようなベクトルの拡張を行えば、一見類似していないベクトルの類似性を判断でき、適応的なコンテンツ検索が可能となる。
【００１８】
なお、検索手段は、問合せ情報に基づいて、特徴ベクトルにて張られる特徴空間の構造化や分割を行うようにするとよい（請求項１３）。また、問合せ情報に基づいて、特徴ベクトルの再配置や移動を行うようにするとよい（請求項１４）。これによって、検索時における特徴ベクトルの修正が実現され、適応的な検索処理が実現される。また、検索手段が、特徴ベクトルの属性値が不定値である場合に、平均値あるいは「０」を用いて、コンテンツを評価するようにすれば（請求項１５）、あいまいさを残した特徴ベクトルを定義することもできる。さらに、検索手段が、コンテンツに対する記述であるコンテンツ記述を適応化するようにしてもよい（請求項１６）。
【００１９】
ところで、ユーザの個人情報に合わせた検索を実現するため、本発明では、次に示すような視点の変更という技術思想を検索に取り入れる。
すなわち、検索手段は、特徴ベクトルで張られる特徴空間へ問合せベクトルをマッピングするにあたって、座標系の変更を行うことにより、視点の変更を実現することが考えられる（請求項１７）。
【００２０】
この座標系の変更は、ユーザの個人情報に基づいてなされるようにしてもよい（請求項１８）。あるいは、ユーザ情報をモデル化したユーザモデルに基づいてなされるようにしてもよい（請求項１９）。
【００２１】
このような問合せベクトルのマッピングを座標系を変更して行うという技術思想によって、ユーザ毎の要求を、ユーザの複数の依存性や属性を示すベクトル全体の変更として包括的に表現することができ、適切に視点を変えて反映させることができるのである。したがって、このような視点変更によって、適応的なコンテンツ検索が可能になる。
【００２２】
以上のように、本発明によれば、適応的な検索を実現することができ、検索処理の最適化という目的が達成される。
なお、上述した適応的情報検索システムには、問合せに対応する問合せ情報を、ユーザ状況に合わせて生成する問合せ情報生成手段を設けることができる。この構成では、問合せ情報生成手段が、問合せベクトルの初期値を決定して、問合せ情報を生成することが考えられる。このとき、問合せ情報生成手段は、問合せベクトルの次元である属性基底を決定して、問合せ情報を生成するようにしてもよい。これによって、問合せベクトルの次元構成が動的なものとなり、より適切な問合せ情報が生成できる。
【００２３】
ここで、属性基底は、予め定められた代表的な属性として、あるいは、所定情報と属性との対応関係を参照して決定すればよい。後者は、例えばアプリケーションやタスク、あるいは、それらをグルーピングしたプロファイルというグループ毎に、代表的な属性を対応付けておき、この対応関係を参照するようにする。また、問合せ情報生成手段が、属性基底を必要に応じて追加するようにしてもよい。
【００２４】
また、問合せ情報生成手段は、取得したキーワードに基づいて、問合せベクトルの初期値を決定することが考えられる。例えば、予め定められた属性基底に対応する初期値を、キーワードに対応させて記憶しておけば、取得したキーワードから問合せベクトルを生成できる。つまり、キーワードに対応する問合せベクトル（代表ベクトル）を予め定めておくのである。このようにすれば、簡単に問合せベクトルを生成することができる。
【００２５】
ただし、同一キーワードであれば当然に同一の問合せベクトルが生成されるため、問合せベクトルの重複を考慮して、初期値を決定することが望ましい。また、複数のキーワードに基づいて初期値を決定できるようにしてもよい。この場合には、各キーワードに対応する初期値の平均値を採用することが一例として考えられる。
【００２６】
このようなキーワードは、対話処理において取得することが考えられる。例えば、対話処理におけるユーザの発話に基づいて取得したり、対話処理で用いられる対話シナリオに基づいて取得したりするという具合である。
【００２７】
さらに、適切な問合せベクトルを生成するという観点から、問合せ情報生成手段は、問合せベクトルを生成した後、さらに、問合せベクトルを修正して、問合せ情報を生成することが望ましい。例えば、過去の問合せ履歴を参照して、問合せベクトルを修正することが考えられる。過去の問合せ履歴を参照すれば、あいまいな情報からでも、適切な問合せベクトルへの修正が可能となる。また、ユーザ情報をモデル化したユーザモデルを参照して、問合せベクトルを修正することが考えられる。ユーザ情報をモデル化してユーザモデルとして用意しておけば、問合せベクトルの初期値を評価することができ、問合せベクトルの適切な修正が可能となる。さらに、ユーザの個別情報を記述したユーザプロファイルを参照して、問合せベクトルを修正してもよい。例えば、ユーザプロファイルに記述されたユーザの嗜好情報を参照して、問合せベクトルを修正することが考えられる。このようにすれば、支配的な属性次元に関する重み付けを修正することができる。
【００２８】
また、問合せ情報は、ユーザの行動を示すユーザ軌道に対応付けて格納することが望ましい。この場合のユーザは、複数のユーザを想定することもできる。これによって、複数ユーザの行動パターンから問合せ履歴を選択することが可能になる。また、問合せ情報は、複数の問合せベクトルからなる問合せ行列として、ユーザ軌道に対応付けて格納してもよい。これによって、問合せベクトルの予測が可能となる。
【００２９】
また、問合せ情報生成手段は、問合せベクトルに対して検索のための最適化を行うようにしてもよい。あるクラスのコンテンツを確実に選択するために、後述する特徴ベクトルのスカラー倍としたり、最適なコンテンツを選択するために、次元を拡張したりすることが考えられる。
【００３０】
以上説明した構成によれば、問合せ記述の自動化及び最適化が図れる。
その他、上述した構成に加えあるいは代え、適応的情報検索システムには、コンテンツに付加される特徴情報を、当該コンテンツに対応させて生成する特徴情報生成手段を設けることが考えられる。
【００３１】
そして、この特徴情報生成手段も、上述した問合せ情報生成手段と同様に構成することができる。
例えば、特徴ベクトルの初期値を決定して特徴情報を生成する構成としたり、属性基底を決定して特徴情報を生成する構成としたりすることが考えられる。属性基底を、予め定められた代表的な属性として、あるいは、所定情報と属性との対応関係を参照して決定する構成や、属性基底を必要に応じて追加する構成が採用できる。
【００３２】
特徴ベクトルの生成に関して言えば、問合せベクトルと同様に、キーワードからその初期値を決定することが考えられ、同一キーワードに基づいて生成されることによる特徴ベクトルの重複を考慮して初期値を決定することが考えられる。また、複数のキーワードに基づいて初期値を決定できるようにしてもよい。
【００３３】
もちろん、問合せベクトルと同様に、対話処理によってキーワードを取得することが考えられる。この場合、対話処理におけるユーザの発話や対話シナリオを利用する構成を採用できる。ただし、特徴ベクトルの場合は、コンテンツに対応するものであるため、コンテンツの内容を示すメタデータからキーワードを取得することも考えられる。
【００３４】
また、問合せベクトルと同様に、特徴情報生成手段は、特徴ベクトルを生成した後、さらに、特徴ベクトルを修正して、特徴情報を生成する構成が考えられる。
特に特徴ベクトルの修正にあっては、下記のような構成が有効である。
【００３５】
特徴情報生成手段は、特徴ベクトルのスケール変更を行って、特徴ベクトルを修正することが考えられる。例えばキーワードに対応する特徴ベクトル（代表ベクトル）を定めた場合、各特徴ベクトルの平均が代表ベクトルに一致するように、スケール変更を行うことが考えられる。
【００３６】
また、特徴情報生成手段は、特徴ベクトルの拡散を行って、特徴ベクトルを修正することが考えられる。この場合、各特徴ベクトルの重心ベクトルが、上述した代表ベクトルに一致するように、特徴ベクトルを分散させるという具合である。
【００３７】
さらに、特徴情報生成手段は、特徴ベクトルの属性基底を追加することにより、特徴ベクトルを修正することが考えられる。
これらの手法によって特徴ベクトルを修正すれば、異なるコンテンツに異なる特徴ベクトルを対応させることができ、検索時の絞り込みに有効に作用する。
【００３８】
また、検索効率を考えた場合、特徴ベクトルを、階層化して格納することが有効である。例えば、コンテンツに対応するメタデータに従った、コンテンツの分割に基づく階層化を行うことが考えられる。また例えば、特徴ベクトルの属性基底の分割に基づく階層化を行うことが考えられる。さらに、特徴ベクトルによって張られる特徴空間の分割に基づく階層化を行うことが考えられる。
【００３９】
これらのような特徴ベクトルの階層化によって、段階的な特徴ベクトルの検索が可能となり、検索処理を一層高速化することができる。
以上に説明した構成によれば、特徴情報に代表されるコンテンツ記述の自動化及び最適化を実現できる。
【００４０】
また、本発明の適応的情報検索システムには、検索結果に基づいて、格納情報の更新を行う更新手段を設けてもよい（請求項２０）。
つまり、検索結果をフィードバックさせることにより、問合せを代表とする格納情報が評価できるのである。したがって、更新手段は、例えば、検索結果を評価することにより、格納情報の更新を行うことが考えられる。
【００４１】
更新手段は、問合せ情報を修正したり、特徴情報を修正したり、検索手法を適合化したり、検索対象を修正したり、ユーザ情報をモデル化したユーザモデルの内部関係や外部との対応関係を修正したり、書き換え不能な記録媒体にあるコンテンツ記述を、書き換え可能な記録媒体に追加したりすることで、適応的な格納情報の更新を行うことが考えられる。
【発明を実施するための最良の形態】
【００４２】
以下、本発明を具体化した一実施例を図面を参照して説明する。
本実施例の検索システムは、図１に示すように、特徴ベクトルと問合せベクトルによる評価に基づき、ユーザが要求するコンテンツを適切にまた迅速に検索することを一つの目的とする。そして、このような検索手法を現実のシステムとして実現するための技術を以下に開示する。ただし、本発明は、以下の実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得ることは言うまでもない。
【００４３】
図２に実施例の検索システムの全体構成を示す。
本システムは、ユーザ端末３と、情報センター５とを備えている。
ユーザ端末３は、外部入出力インタフェース３１、通信制御部３２、対話制御部３３、ベクトル検索・生成・修正部３４、ベクトルプロファイル３５、問合せ履歴３６、ユーザモデル３７、ユーザプロファイル３８、問合せ生成部３９、及び、キーワード連想部４０を有している。
【００４４】
一方、情報センター５は、外部入出力インタフェース５１、通信制御部５２、コンテンツ管理・検索制御部５３、ベクトル検索・生成・修正部５４、ベクトルテーブル５５、検索履歴５６、特徴ベクトルデータベース５７、内容記述検索・生成・修正部５８、内容記述データベース５９、コンテンツ評価部６０、及び、コンテンツデータベース６１を有している。
【００４５】
なお、本実施例では、便宜的にユーザ端末３と情報センター５を通信手段を介して接続される分離したモジュールとして構成しているが、ユーザ端末３と情報センター５の機能を一体に構成し、一つの計算機内に格納することも考えられる。また、ユーザ端末３と情報センター５との間の通信手法は、有線、無線を問わず、一つの回路あるいはソフトウェアにおけるデータ転送であってもよい。無線通信の構成を考えると、ユーザ端末３を自動車内に設置し、ナビゲーション装置の一機能としての検索システムを構成することができる。本実施例では、ユーザ端末３が車両に搭載された場合を適宜例に挙げて説明することにする。
【００４６】
まず最初に、各ブロックの大まかな機能を説明する。
ユーザ端末３の外部入出力インタフェース３１は、ユーザからの発話や映像、テキストの入力及び、音声や映像、テキストによる出力を行うための入出力構成である。
【００４７】
対話制御部３３は、対話制御全体を司り、ベクトル検索・生成・修正部３４などに指令を送出する。
ベクトル検索・生成・修正部３４は、対話制御部３３からのキーワード及び指令により、問合せベクトルの生成及び修正を行う。このとき、ベクトルプロファイル３５や問合せ履歴３６を適宜参照する。また、ユーザモデル３７やユーザプロファイル３８を踏まえた修正も可能である。
【００４８】
ユーザモデル３７は、ユーザ毎の情報をモデル化記述したものであり、ユーザプロファイル３８には、対話制御部３３やユーザモデル３７の処理結果を基にユーザの環境・状況・要求・状態・行動・局面などの現在値及びユーザ嗜好情報などが書き込まれる。
【００４９】
問合せ生成部３９は、問合せベクトルとキーワードからなる問合せプロファイルを生成する。キーワード連想部４０は、この問合せプロファイル生成において、キーワードを拡張する。
【００５０】
通信制御部３２は、生成された問合せプロファイルを情報センターに送ると共に、情報センター５から受け取った検索結果や状態情報を対話制御部３３に伝える。
情報センター５の通信制御部５２は、ユーザ端末３からの問合せプロファイルを、コンテンツ管理・検索制御部５３に伝達する。また、ユーザ端末３に対し、検索結果や状態情報を送信する。
【００５１】
外部入出力インタフェース５１は、外部との間で映像・音声・データなどの入出力を行う機構である。
コンテンツ管理・検索制御部５３は、情報センター５全体の動作を司り、ベクトル検索・生成・修正部５４や、内容記述検索・生成・修正部５８への指令などを行う。
【００５２】
ベクトル検索・生成・修正部５４は、コンテンツ管理・検索制御部５３から受け取った指令、問合せベクトル及び検索履歴５６を基に、特徴ベクトルデータベース５７を検索し、検索結果をコンテンツ管理・検索制御部５３に返す。一方で、コンテンツ新規登録時には外部情報を基に、ベクトルテーブル５５を参照して特徴ベクトルの初期値を生成する。この初期ベクトルは問合せとの整合性や検索履歴５６に基づく学習、システムの更新、及びユーザ情報を踏まえて修正拡張される。
【００５３】
コンテンツ評価部６０は、コンテンツデータベース６１を検索し、この修正拡張後の問合せベクトル及び特徴ベクトルを基に、コンテンツの一次評価を行う。
内容記述データベース５９は、特徴ベクトルの一次評価結果（コンテンツの一次評価結果）が所定の条件を満足したときのみ内容記述検索・生成・修正部５８によって解析され、再度コンテンツ評価部６０において二次評価がなされる。ここで最終的に検索条件を満たした内容記述に対応するコンテンツのみが、コンテンツ管理・検索制御部５３によって、通信制御部５２を介してユーザ端末３へ配信される。
【００５４】
このように構成された本検索システムにおける詳細な動作を以下順に説明していく。ここでは、便宜上、＜１＞→１→（１）→１）というように項目番号を付けて分説する。
＜１＞ユーザ端末３
図３及び図４は、ユーザ端末３にて実行される問合せ生成処理を示すフローチャートである。
【００５５】
最初のステップ（以下、ステップを単に記号Ｓで示す。）１００において、対話入出力が行われる。この処理は、外部入出力インタフェース３１を介して対話制御部３３にてなされるものである。続くＳ１１０にて、検索の話題か否かが判断される（Ｓ１１０）。ここで検索の話題であると判断された場合（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。一方、検索の話題でないと判断された場合（Ｓ１１０：ＮＯ）、Ｓ１００の対話入出力を繰り返す。
【００５６】
Ｓ１２０では、キーワードと属性値の抽出を行う。続くＳ１３０では、過去の問合せを検索する。これらの処理は、ベクトル検索・生成・修正部３４によるものであり、Ｓ１３０の処理は、問合せ履歴３６に基づくものとなる。
【００５７】
次のＳ１４０では、検索実行か否かを判断する。ここで検索実行と判断された場合（Ｓ１４０：ＹＥＳ）、Ｓ１５０へ移行する。一方、検索実行と判断されない場合には（Ｓ１４０：ＮＯ）、Ｓ１００からの処理を繰り返す。
【００５８】
Ｓ１５０では、ベクトルプロファイル３５を選択する。続くＳ１６０では、問合せベクトルの次元構成を決定する。次のＳ１７０ではベクトル表を参照して、Ｓ１８０にて、初期問合せベクトルを生成する。これらの処理は、ベクトル検索・生成・修正部３４によってなされるものである。
【００５９】
次に図４中のＳ１９０へ移行し、以降の処理で、初期問合せベクトルの拡張・修正を行う。
Ｓ１９０では、ユーザプロファイル３８を参照する。また、Ｓ２００では、ユーザモデル３７の処理結果を参照する。そしてさらに、Ｓ２１０にて問合せ行列を参照し、Ｓ２２０で初期問合せベクトルの拡張・修正を行う。
【００６０】
以上が問合せ生成処理の概要であるが、上述した処理に対する理解を深めるため、特徴的な処理を個別具体的に説明する。
１．問合せベクトル
問合せベクトルは、依存性ベクトル及び属性ベクトルで構成される。
【００６１】
依存性ベクトルは、特願２００１−１３６５号に開示したものであり、ユーザ要求を各種項目への依存性として数値化したものである。つまり、依存性ベクトルという概念を導入することにより、ユーザ要求を定量的に表すことができ、属性を直接的に数値化することが困難な情報について絶大な効果を発揮する。
【００６２】
属性ベクトルは、コンテンツの特徴をあらわす各種属性の属性値が記述されたものである。
例えば、飲食店というコンテンツに対する属性として、次に示すような属性を用意することが考えられる。
【００６３】
＜緊急度＞        ９
＜ファミリー度＞  ４
＜人気度＞        ８
＜価格＞          ５
右に記載される数値が属性値の一例である。このような属性を属性ベクトルとして数値化しておけば、コンテンツの特徴をベクトルの距離に反映させて検索することが可能になる。
【００６４】
２．問合せベクトルの初期値生成
上述したように、問合せベクトルは、属性ベクトル及び依存性ベクトルで構成される。したがって、問合せベクトルの構成要素は、属性値及び依存性である。
【００６５】
繰り返すが、属性値とは、要求するコンテンツの具体的な属性（例えば、レストランのファミリー度、人気度、値段の高さ、お洒落度、収容人数、他）を数値化して表したものである。依存性とは、コンテンツの様々な属性に対する関心度（依存性）である。
【００６６】
（１）次元構成の決定（図３中のＳ１６０）
問合せベクトルを生成するには、問合せベクトルを構成する空間を定義する必要がある。
【００６７】
空間を定義する手法として、デフォルト空間の参照や、ベクトル属性基底表の参照が考えられる。ベクトル属性基底表は、ベクトルプロファイル３５として読み込まれる（Ｓ１５０）。
【００６８】
１）デフォルト空間の参照
対象とする情報検索タスクにおいてもっとも使用頻度の高い属性次元を組み合わせて問合せベクトルの空間を定義する。
【００６９】
例えば図５の下段に示すように、計８個の代表的な依存性属性を用いてデフォルト空間を構成する。図５では、属性１〜８が次のように定義されている。
属性１：シーンの場所依存性
属性２：シーンの時間依存性
属性３：シーンに登場する人物への依存性
属性４：シーンのジャンル
属性５：シーンの天気
属性６：コンテンツのサイズへの依存性
属性７：符号化方式への依存性
属性８：コンテンツコストへの依存性
なお、この事例では各属性間に順序関係はないのでどの属性が実際のベクトルの何番目の成分になるかは随意に選択できる。
【００７０】
２）ベクトル属性基底表の参照（図３中のＳ１５０）
ベクトルプロファイル３５としてのベクトル属性基底表を参照し、関連する属性次元を組み合わせて問合せベクトルの空間を定義する。これはベクトルをタイプ分類して関連属性をプロファイル化することに相当する。ベクトル属性基底表は、図６に示す如くである。
【００７１】
例えば、図６中のモバイルプロファイルついて見ると、「ユーザの時間への依存性」、「ユーザの場所への依存性」及び「依存性属性」が「○」となっており、これらを属性基底として選択する。依存性属性は、上述のように計８個の属性として展開することができる。
属性１：ユーザの時間への依存性
属性２：ユーザの場所への依存性
属性３：シーンの場所依存性
属性４：シーンの時間依存性
属性５：シーンに登場する人物への依存性
属性６：シーンのジャンル
属性７：シーンの天気
属性８：コンテンツのサイズへの依存性
属性９：符号化方式への依存性
属性10：コンテンツコストへの依存性
上述のように、予め定められた代表的な空間を「デフォルト空間」と呼び、ベクトルプロファイル３５からベクトル属性基底表を用いて得られる空間を「プロファイル空間」と呼ぶことにする。
【００７２】
そして、このようなデフォルト空間やプロファイル空間に対して、さらに、アプリケーションなどに応じて属性次元を追加することが考えられる。この追加された空間を「オプション空間」と呼ぶ。
【００７３】
なお、以下の説明では、上述した計８個の属性（次元）で定義されるデフォルト空間を、具体例として適宜用いることとし、「代表空間」と記述する。
（２）属性値の決定
属性値を決定することが、すなわち、初期問合せベクトルの生成（図３中のＳ１８０）である。属性値の決定は、キーワード入力、対話処理、ユーザプロファイル３８などに基づいて行う。
【００７４】
１）キーワード入力からの生成
この場合は、図５に示すような代表ベクトル値対応表を参照して、キーワードから初期ベクトルを生成する。
【００７５】
例えば代表空間のベクトル（SPlace, Stime, Actor, Genre, Weather, Csize,
CodSch, Cost ）を考える。すなわち、
Splace ：シーンの場所に対する依存性
Stime ：シーンの時間に対する依存性
Actor ：アクターへの依存性
Genre ：ジャンルへの依存性
Weather ：現在の天気への依存性
Csize ：コンテンツサイズへの依存性
CodSch ：符号化方式への依存性
Cost ：コストへの依存性
である。
【００７６】
このとき、図５に示した代表ベクトル値対応表を用いれば、キーワードとベクトルとを対応付けられる。例えば「渋滞状況」、「混雑」、「観光」、「ビデオメール、ＴＶ電話」は、次に示すように対応付けられる。
渋滞状況              ：FF03E6FA
混雑                  ：FC0806F0
観光                  ：F80E46F0
ビデオメール、ＴＶ電話：1AF506A0
各属性値は、１６進表記で示されており、「０」〜「Ｆ」の１６段階となっている。このようにして、キーワードに対して得られるベクトルを「代表ベクトル」と呼ぶことにする。
【００７７】
このような代表ベクトルは、キーワードが同じであれば当然に同一のものとなってしまう。そこで、代表ベクトルからさらに情報検索に応じたベクトルを生成するためのプロセスが、後述する修正プロセスである。
【００７８】
ところで、代表ベクトル値対応表を用いた場合に、入力されたキーワード群に複数の代表ベクトルが対応することがある。
この場合は、一つの手法として、各キーワードに対応する代表ベクトルの平均値を算出して、それを代表ベクトルとすればよい。次の式に示す如くである。
ｖkw＝（１／Ｎ） Σ ｖ（ｋｗi ）
ここで、ｖ（ｋｗi ）は、キーワードｋｗi に対応する代表ベクトルを示す。また、Σは、ｉ＝１〜Ｎの和記号を示す。
【００７９】
２）対話からの生成
次に、対話からの生成について説明する。対話からの生成には、ユーザ発話からの生成、対話シナリオからの生成がある。
【００８０】
ユーザ発話からの生成は、ユーザ発話中のキーワードを基になされる。ユーザ発話中のキーワードを取得すれば、上述した代表ベクトル対応表を用いて、代表ベクトルを特定することができる。このとき、代表ベクトル対応表を用いる場合に、同義語を考慮することも考えられる。
【００８１】
さらに、代表ベクトル対応表に含まれないキーワードの場合は、要求を推定してキーワードと対応付ける。
例えば、ユーザ発話の中に、次のようなキーワードが含まれていた場合を考える。
要求語：食べたい、見たい
料理名：しゃぶしゃぶ、ラーメン
地名  ：名古屋駅付近
人名  ：聖徳太子、ロボットさん、小泉さん
この場合は、次のようにして属性値を決定する。
【００８２】
「食べたい」（要求語）、「ラーメン」（料理名）などから食事要求が連想される。したがって、キーワード「レストラン検索」を選択することができる。
地名がキーワード中にある場合には、場所依存性が抽出でき、代表空間における場所への依存性が推定でき、ベクトル：FXXXXXXXを対応付けることができる。
【００８３】
人名がキーワード中にある場合には、アクターへの依存性が抽出でき、代表空間における属性３への依存性が推定でき、ベクトル：XXFXXXXXを対応付けることができる。
ただし、ある程度の文脈を理解できるシステムを採用することが望ましい。人名が文中で”呼びかけ”の役割を果たす場合は、その人名を検索キーワードとみなすことができないからである。例えば、「ロボットさん、駐車場の場所を教えて」といった発話の「ロボットさん」は、呼びかけであり、検索キーワードではない。
【００８４】
このようなことを考えると、ユーザ発話の文型、要求語、発話意図などを基に検索キーワードを生成することが考えられる。
ユーザ発話の文型には丁寧語や敬語の表現を抜きにしても、以下のようにさまざまなものがある。これらは問合せの性質のみならず、発話の微妙なニュアンスにも関係する。次に示す如くである。
・ 何ができるの？                            ＜質問＞
・ あついね。                                ＜挨拶、同意を求める＞
・ どうして・・・なの？                      ＜理由を尋ねる＞
・ カーオーディオの使い方を教えてくれない？  ＜依頼＞
・ 食事したいんだけど。                      ＜要望伝達＞
・ レストランを検索して                      ＜指示＞
・ 何かメール来てますか？                    ＜確認、質問＞
これらの場合、左に示す文型から、右に示す発話のニュアンスや意図などが抽出できる。
【００８５】
要求語には、次に示すようなものがある。
｛見たい、食べたい、行きたい、知りたい｝
要求語は、問合せベクトルを生成するにおいて、もっとも支配的な情報を提供する。ただし、異なるタスクでも共用して用いられることがあるので、正確な問合せベクトルを生成するには目的語の認識が必要な場合が多い。もっとも、問合せの背景となる状況がユーザプロファイル３８やユーザモデル３７によって推定可能である場合は、目的語がないあいまいな条件下でも問合せベクトルを生成できる。
【００８６】
例えば、「ニュースを見せて」という場合は、「ニュース」という目的語の認識がタスクを判別する上で重要である。一方、「桜町交差点を見せて」という場合は渋滞検索タスクである可能性が高い。
【００８７】
その他、発話意図が推定できる場合には、発話意図による生成を行ってもよい。上述したように発話意図は文型から類推されることもあるが、他の情報から推定できることもある。
【００８８】
一方で、対話シナリオからの生成を行うこともできる。
タスクの決められた音声対話では、そこで用いている対話シナリオから、現時点のユーザとの対話状況やユーザの発話意図をエージェントが推定することが可能である。このタスク内容、対話状況及び発話意図を用いて問合せベクトルを生成することができる。
【００８９】
３）ユーザプロファイル３８からの生成
次に、ユーザプロファイル３８からの問合せベクトル生成について説明する。
例えば特願２０００−２８５５２１号では、ユーザモデルや要求推定手法に基づいて、ユーザの環境、状況、要求、状態、行動、局面などの動的データを推定する技術を開示した。
【００９０】
このようなユーザ情報に基づけば、ユーザ要求に合致した問合せベクトルを推定することができる。なお、この推定プロセスには対話を含む場合もあるが、まったく対話しないでも自動的に問合せを生成することができる。例えば、次に示すようなプロファイルがあれば、現在地近辺のガソリンスタンドを検索するための問合せベクトルを生成するという具合である。
車両プロファイル中の情報
＜ガソリン残量＞    ＝３リットル
ユーザプロファイル中の情報
＜目的地までの距離＞＝１００ｋｍ
＜現在地＞          ＝北海道旭川市郊外
＜時間＞            ＝平日夜８時
さらに、プロファイル情報と共に対話があれば、曖昧な要求に対して問合せベクトルの補足を行うことができる。例えば次のようなユーザ発話があったとき、ユーザプロファイル中の情報を用いれば、目的地までの経路の内、渋滞しそうな個所をチェックし、渋滞情報検索のための問合せベクトル：FF03E6FAと問合せ属性値（時間、場所）を含む問合せを生成するという具合である。
ユーザ発話
「このさき渋滞してる？」
ユーザプロファイル中の情報
＜現在地＞＝愛知県知立市上重原町
＜目的地＞＝本社（愛知県刈谷市昭和町１丁目）
＜要求＞＝渋滞情報検索、映像表示
＜運転状態＞＝交差点信号待ち停車中
３．ベクトルの修正（図４中のＳ２２０）
（１）過去の履歴の参照
過去の問合せは、問合せ履歴３６の検索によって取得する（Ｓ１３０）。この問合せ履歴３６の問合せベクトルと比較する。ここで、その評価関数は、例えば下記のような距離として定義できる。
L= Lvector ＋Lptime ＋Lcplace
Lvector = dist(Vinit,Vpast)
なお、ここで、各記号の意味は次に示す通りである。
【００９１】
Vinit     ：初期の問合せベクトル
Vpast     ：過去の問合せベクトル
dist(A,B) ：ベクトルＡ，Ｂ間の距離。例えばユークリッド距離、絶対値距離などが考えられる。
【００９２】
Lptime    ：ある周期時間（例えば１年）の範囲内で現在時間とVpast の格納時間の時間差を距離とする。
Lcplace ：場所のカテゴリに関する距離
このＬを検索対象となる過去のベクトルについて計算し、例えば次に示す方法で過去の代表的ベクトルを選択する。
（方法１）Ｌを最小にするようなVpast を選択する。
【００９３】
（方法２）Ｌがある一定の閾値以下となる全ての過去の問合せベクトルを平均する。
ここにある距離の概念は、時間依存性及び場所依存性を考慮するものである。これはユーザの要求が例えば１年や１月、１週間、１日といった周期性を有することに着目し、ベクトル同士の距離だけでなく、このような時間的な距離を導入して問合せベクトルを選択するのである。場所についても同様である。例えば公園や海辺というような休憩場所、レストランや喫茶店というような食事場所、・・・というカテゴリによって場所的な距離を導入することができる。
【００９４】
（２）ユーザモデル３７の利用（図４中のＳ２００）
特願２０００−２８５５２１号では、時間、空間、状況などをユーザモデルとしてモデル化した。本実施例のユーザ端末３も、ユーザモデル３７を有している。このようなユーザモデル３７によって、背景情報を処理すれば、問合せの意味を推定することができる。つまり、典型的な代表値として作成した初期ベクトルを、別の観点であるユーザモデル３７によって評価するのである。
【００９５】
（３）ユーザプロファイル３８の参照（図４中のＳ１９０）
ユーザプロファイル３８に格納されたユーザ嗜好情報を参照して問合せベクトルを修正する。これによって、問合せベクトルの支配的な属性次元に関する重み付け値を修正することができる。
【００９６】
初期の問合せベクトルが、代表空間で与えられているものとする。例えば、ベクトル：（SPlace ,Stime ,Actor ,Genre ,Weather ,Csize ,CodSch ,Cost ）＝（FF03E6FA）が初期ベクトルであるとする。このとき、ユーザプロファイル３８から、使用している端末環境が高性能端末である場合、コンテンツサイズや符号化方式、コンテンツコストにはあまり依存しないというユーザ個別の条件が推定される。そこで、コンテンツのサイズであるCsize 、符号化方式であるCodSch、及び、コンテンツコストであるCostの属性値を小さく抑えることが考えられる。例えば、修正後の問合せベクトルを（FF03E342）とするという具合である。
【００９７】
このように、ベクトル修正の手法としては、過去の問合せベクトルを利用する手法、ユーザプロファイルを利用する手法、及び、ユーザ嗜好情報を利用する手法が考えられる。なお、後述する問合せ行列を格納することにより、問合せ行列によって修正することもできる。
【００９８】
４．問合せプロファイル
（１）問合せプロファイルの構成
問合せプロファイルは、検索キーワードと問合せベクトルで構成される。
【００９９】
検索キーワードとは、検索に用いられる項目群を指す。
例えばキーワード「旅行情報」に対して、次のような項目群を用意する。
＜目的地＞
＜旅行期間＞
＜宿泊地＞
＜宿泊料金＞
＜宿泊人数＞
＜観光スポット＞
＜周辺地図情報＞
＜周辺レストラン＞
＜交通手段＞
このとき、これらの項目群の中で充填された項目を、検索キーワードとして採用することが考えられる。なお、このような項目群をセットで用意した場合、充填されていない項目を決定・獲得することを、検索における最終目標とすることが考えられる。
【０１００】
（２）問合せプロファイルの生成
問合せプロファイルの生成は、上述したような検索キーワード及び問合せベクトルの生成である。問合せプロファイルへの情報の集約を、図７の説明図に示した。
【０１０１】
このとき、本実施例では、情報検索の円滑化という観点から次のようなシステム処理をきっかけとして、問合せプロファイルへの情報集約を行う。
それは、対話処理及び、適応化処理である。
【０１０２】
対話処理では、主として、外部入出力インタフェース３１を介して対話制御部３３によって実現されるものである。これによって、外部から検索に必要なキーワード群を獲得する。
【０１０３】
適応化処理は、ユーザ（個人の特性や対話状況を含む）、端末、システム、ネットワーク、コンテンツなどに対する適応的な処理である。特に対話処理で駆動された適応化処理は、上述した問合せベクトルの生成に関与する。
【０１０４】
このような対話処理や適応化処理をトリガーとして、次に示すような情報変換が行われる。
・キーワードと属性基底との対応付け
・プロファイル名とアプリケーション名及びタスク名の対応付け
・プロファイル名と属性基底の対応付け
・アプリケーション名と属性基底の対応付け
・タスク名と属性基底の対応付け
・キーワードと問合せベクトルの代表値の対応付け
ベクトルプロファイル３５によってベクトル属性基底表を参照することは、既に述べたところである。なお、プロファイル、アプリケーション、タスクという言葉を使用したが、タスクをまとめたものをアプリケーション、アプリケーションやタスクをグルーピングしたものをプロファイルと呼ぶ。これらは、ユーザ端末の機能を、階層化する概念であり、ユーザ端末３の使用状況などが、プロファイル、アプリケーション、タスクという階層化概念で捉えられる。
【０１０５】
ベクトルプロファイル３５には、モバイルプロファイル、車載プロファイル、オフィスプロファイル、編集プロファイル、ホームプロファイルといったものを用意することが考えられる。また、アプリケーションには、レストラン検索、渋滞情報検索、スキー場検索といったものを用意することが考えられる。同様に、タスクには、天気情報検索、ニュース検索、インターネット検索といったものを用意することが考えられる。これらは図６に示したベクトル属性基底表のクラス名に対応する。
【０１０６】
そして、上述したキーワード群は、対話処理だけでなく、このようなプロファイル、アプリケーション、タスクからも取得される。
５．問合せベクトルの格納（問合せ履歴３６）
問合せベクトルあるいは問合せプロファイルは、問合せ履歴３６としてユーザ端末３に格納される。このとき、上述したように、初期問合せベクトルを修正する情報という観点で格納することが望ましい。
【０１０７】
（１）問合せベクトルは、時空間モデルに基づいて格納することで、次に示すようなあいまいな検索を可能にすることができる。つまり、問合せベクトルに時間や場所のキーワードを付加した問合せプロファイルの形式で格納しておくのである。
【０１０８】
例えば、次のような問合せがあった場合を考える。
＜問合せ＞
ユーザ発話    ：「えーと、中津川ＩＣからは渋滞しないかな？」
時間          ：２００１年４月１日（日）７時３０分
場所          ：中央自動車道恵那ＩＣ付近
状況          ：スキー場に移動中
＜問合せプロファイル＞
依存性ベクトル：時間、場所、目的、コスト
属性値ベクトル：時間＝２００１年４月１日（日）７時３０分
場所          ：中央自動車道中津川ＩＣ出口付近
目的          ：渋滞検索
＜検索結果＞
システム発話  ：「日曜日のこの時間帯はあまり混みません」
映像検索結果  ：７時１０分時点の中津川ＩＣ出口付近の映像
このような場合に問合せプロファイルを格納しておけば、例えば１年後に次のような問合せがあった場合に、適切な問合せベクトルを生成することができる。
＜問合せ＞
ユーザ発話    ：「えーと、中津川出てからはどう？」
時間          ：２００２年４月７日（日）７時３０分
場所          ：中央自動車道恵那ＩＣ付近
状況          ：スキー場に移動中
つまり、時間、場所、状況などが類似することにより、約１年前の問合せベクトルが検索され、この問合せベクトルに基づいて適切な初期問合せベクトルの修正を行うことができる。なお、検索結果を含めて問合せプロファイルを記憶しておけば、情報センター５への検索を要求せずに、ユーザ端末３だけで妥当な結果をユーザに通知することができる。
【０１０９】
（２）問合せベクトルのベクトルタイプの定義
問合せベクトルの属性基底が動的に決定されることは既に述べた。問合せベクトルの属性基底を固定的にしないことにより、柔軟な検索が可能になる。
【０１１０】
このとき、属性基底と属性値とを対応させて、問合せプロファイルに記述することが考えられる。しかしながら、この場合には、問合せプロファイルの情報量が多くなってしまう。
【０１１１】
そこで本実施例では、比較的よく使われる検索アプリケーション、例えば渋滞検索、レストラン検索、旅行情報検索、モバイル情報検索などのアプリケーションについて、各アプリケーション毎にベクトルタイプを表現する識別子を設定する。次に示す如くである。
＜ベクトルタイプ＞＜ベクトル値＞
＝渋滞検索，FF03E6FA
ここではベクトルタイプに代表ベクトル値対応表のキーワードを採用したが、このキーワードとは別にベクトルタイプを定義してもよい。
【０１１２】
つまり、ベクトルの属性基底の構成を、ベクトルタイプとして類型化しておくのである。
このようにすれば、問合せプロファイルにおいて逐一属性基底を指定する必要がない。すなわち、問合せプロファイルの情報量を削減することができる。したがって、問合せプロファイルの格納に有利である。また、後述する検索処理においてもベクトルタイプを判定して検索を行うことができる。
【０１１３】
（３）時間や場所、状況などと共に問合せプロファイルという形式で問合せベクトルを格納すると、あいまいな問合せに対する初期問合せベクトルの修正効果が極めて大きくなることは既に述べた。
【０１１４】
ただし、上述の例では、時間や場所をいわゆる時空間の一点として採用していた。これに対して次のような手法を用いることが考えられる。
特願２０００−２８５５２１号では、時間的周期性や空間的類似性について、これらを定量化することを開示している。時間的周期性とは、ユーザの要求が１年、１月、１週間、１日といった周期性を有することに着目したものであり、空間的類似性とは、ユーザのいる場所を複数のカテゴリに分けることで見いだされる類似性に着目したものである。
【０１１５】
このような時間的周期性と空間的類似性に基づき、問合せベクトルを（時間、空間）の座標値以外に1年周期での時間インデックスや空間カテゴリのもとで格納する。
例えば、問合せプロファイルを（日曜日の昼ごろ、公園）というアドレス記述で格納するという具合である。この時間インデックスや空間カテゴリによる格納空間を「時空間メモリ」と呼ぶことにする。
【０１１６】
この時空間メモリには、ユーザのベクトルや軌道を存在させることができる。図８に示す如くである。
このような時空間メモリ上の距離を用いれば、ユーザ行動パターンに基づく問合せベクトルの類似度を判断することができる。
【０１１７】
また、このような時空間メモリには、図８に示すように複数のユーザＡ，Ｂ，Ｃの軌道上に各ユーザＡ，Ｂ，Ｃの問合せプロファイルを格納することも考えられる。これによって、別のユーザの問合せプロファイルを参照して、あいまいな発話によるユーザ要求をより正確に推定することができる。
【０１１８】
例えば図８では、軌道上に示した四角形が格納された問合せプロファイルを示しているが、ユーザＢの問合せＱ１に対して、ユーザＡの問合せプロファイルＰＡ１を用いることができ、ユーザＢの問合せＱ２に対して、ユーザＣの問合せプロファイルＰＢ２を用いることができる。
【０１１９】
このように、周期的時間という概念を導入することにより、過去の別のユーザの履歴を用いて、現在のユーザの未知の属性を補間することができるのである。これによって、問合せ履歴３６に基づく問合せベクトルの適切な修正が可能となる。
【０１２０】
具体的なユーザ履歴の格納形式の一例を説明する。
ユーザとの音声対話において獲得したユーザ発話にタグ（補助情報）を付け、時空間メモリに格納する。
【０１２１】
例えば、「ユーザの発話内容」、（ユーザ名、時間、場所、行動目的、問合せ目的、問合せベクトル）という形式で格納すればよい。ここでは、（  ）内がタグに相当し、ユーザプロファイル（あるいはそれへのポインタ）や依存性ベクトルもタグの内容になりうる。
・「ちかくのスーパー」（花子、2001年 1月 1日、一宮、スキー、周辺検索、FC809AB5）
・「ちかくのコンビニ」（太郎、2001年 3月15日、中津川IC、スキー、周辺検索、FC809392）
・「お花見」（""、2001年 4月 1日、自宅駐車場、行楽、お花見検索、BDA00276）
・「近くの薬局」（""、1998年 8月12日、山梨県清里、旅行、周辺検索、 F5903395）
・「高速出口付近のレストラン」（""、1998年 8月12日 12:30、諏訪IC、旅行、周辺検索、F5903D95）
・「今日のイベント」（太郎、2001年 9月15日、名駅前、ショッピング、イベント検索、F590F395）
・「高速の入り口」（次郎、2000年10月 3日、名古屋IC、コンサート、渋滞検索、FF903305）
・「野球の結果」（太郎、2001年11月 1日 22:10、日進市、帰宅中、ニュース検索、FD9D3305）
・「すいてる道」（""、2001年11月10日、香嵐渓、行楽、渋滞検索、FFF03395）
・「刈谷でとんかつのおいしい店」（""、1999年10月20日 12:00、知立市、テニス、レストラン検索、7590FF95）
（４）ところで、このような時空間メモリ上への問合せベクトルの格納を考えると、同一の時空間範囲に、複数の問合せベクトルが格納されることが考えられる。例えば、ある時空間範囲に、「レストランは？」、「今日のイベントは？」、「近くのショッピングセンターは？」といった問合せに基づく問合せベクトルが格納されるという具合である。
【０１２２】
実際は、一人のユーザが同一時刻に複数の問合せを行うことは、不可能ではないが、少ないと考えられる。つまり、問合せ内容が明確な場合には、時空間範囲の複数の問合せベクトルを考慮することはないとも考えられる。しかし一方で、このような複数の問合せベクトルによって、時空間範囲という情報からユーザの問合せ内容を予測することができる。つまり、ユーザは常に種類の異なる問合せベクトルを複数抱えて時空間軌道を移動していると考えることができるのである。この場合の問合せベクトルは、時空間アドレスに依存することになる。
【０１２３】
そこで、問合せベクトルを組にして時空間メモリに格納しておくことが有効である。これが「問合せ行列」である。
このような問合せ行列を参照することで（図４中のＳ２１０）、問合せ予測が可能となり、適切な問合せベクトルの修正が可能になる。
【０１２４】
６．問合せベクトルの最適化手法
ここでは検索処理を前提とした問合せベクトルの最適化手法について簡単に説明する。なお、この思想は、後述する特徴ベクトルに共通するものであり、詳しい説明は、特徴ベクトルの説明として行う。
【０１２５】
（１）問合せベクトルを代表的な特徴ベクトルのスカラー倍にする
特徴ベクトル群が例えば渋滞情報、レストラン情報など代表的なクラスに分類できる場合、あるクラスCLiに対応する問合せQiは、次に示すように、予めその代表ベクトルCiのスカラー倍としておくことが考えられる。
Qi = K Ci
このようにすれば、コンテンツの評価値はＫが一定のもとで最大となる。すなわち、確実にCLi 中のコンテンツが検索される。ただし、この場合、CLi 中のコンテンツ数が膨大であればさらにその中で検索候補を絞るための工夫が必要になる。
【０１２６】
（２） 問合せベクトルの次元を拡張する
候補となるコンテンツが多数存在するときは、候補群からより最適なコンテンツを選別するために問合せベクトルの次元を拡張し、その拡張した部分ベクトルに対して最適なコンテンツ群を選ぶ。
【０１２７】
＜２＞情報センター５
情報センター５は、コンテンツの特徴を示す特徴ベクトルの生成、さらに、ユーザ端末３からの問合せベクトルを用いた検索に特徴がある。
【０１２８】
＜２−１＞特徴ベクトルの生成
図９及び図１０は、情報センター５にて実行される特徴ベクトル生成処理を示すフローチャートである。
【０１２９】
最初のＳ３００において、対話入出力が行われる。この処理は、外部入出力インターフェース５１を介してコンテンツ管理・検索制御部５３にてなされるものである。続くＳ３１０にて、キーワードと数値の抽出がなされる。次のＳ３２０では、特徴ベクトルの生成を開始するか否かが判断される。ここで生成を開始すると判断された場合（Ｓ３２０：ＹＥＳ）、Ｓ３３０へ移行する。一方、生成を開始しないと判断された場合（Ｓ３２０：ＮＯ）、Ｓ３００からの処理を繰り返す。
【０１３０】
Ｓ３３０では、過去の特徴ベクトルを検索する。過去の特徴ベクトルは、特徴ベクトルデータベース５７から検索する。続くＳ３４０では、ベクトルテーブル５５を選択する。そして次のＳ３５０では次元構成を決定し、Ｓ３６０でベクトル表を参照して、Ｓ３７０にて、初期特徴ベクトルを生成する。これら一連の処理は、ベクトル検索・生成・修正部５４にて実行されるものである。
【０１３１】
次に図１０中のＳ３８０へ移行し、以降の処理で、初期特徴ベクトルの拡張・修正を行う。
Ｓ３８０では、マニュアル操作の参照を行う。続くＳ３９０では、製作者情報を参照する。さらに次のＳ４００では、センター情報を参照する。
【０１３２】
そして続くＳ４１０では、条件分岐を行って、種々の手法で特徴ベクトルを最適化し、Ｓ４５０にて、特徴ベクトルの拡張・修正を行う。条件分岐は、所定の条件とすることが考えられる。例えば、Ｓ４１０からの処理は、特徴ベクトルの拡張・修正が完了していない場合に繰り返されるため、この繰り返し回数で分岐させるようにしてもよい。
【０１３３】
特徴ベクトルを最適化する手法としては、ベクトルのスカラー倍（Ｓ４２０）、ベクトルの拡散（Ｓ４３０）、新次元の追加（Ｓ４４０）がある。これらについては後述する。
Ｓ４６０では、特徴ベクトルの比較評価を行い、次のＳ４７０で、特徴ベクトルの拡張・修正が完了したか否かを判断する。ここで拡張・修正が完了したと判断した場合（Ｓ４７０：ＹＥＳ）、Ｓ４８０へ移行する。一方、拡張・修正が完了していない場合（Ｓ４７０：ＮＯ）、Ｓ４１０からの処理を繰り返す。
【０１３４】
Ｓ４８０では特徴ベクトルデータベース５７への格納を行い、その後、本特徴ベクトル生成処理を終了する。
以上が特徴ベクトル生成処理の概要であるが、上述した処理に対する理解を深めるため、特徴的な処理を個別具体的に説明する。
【０１３５】
情報センター５のコンテンツデータベース６１には、検索対象となる種々のコンテンツが格納される。そして、このコンテンツデータベース６１に格納されたコンテンツ検索のために、コンテンツに対応付けた特徴ベクトルを、特徴ベクトルデータベース５７に格納するのである。このような特徴ベクトルを用意することによって、上述した問合せベクトルによるコンテンツ評価が可能になるからである。例えば、コンテンツの評価値は、問合せベクトルと特徴ベクトルとの内積として定義することができる。
【０１３６】
１．特徴ベクトル
特徴ベクトルは、上述のように問合せベクトルとの関係でコンテンツを評価するためのものであるから、問合せベクトルと同様に、属性基底及び属性値で定義される。ただし、属性基底が動的に決定されるため、問合せベクトルとの整合性の面から修正・拡張することが必要になる。
【０１３７】
２．特徴ベクトルの初期値生成（図９中のＳ３７０）
コンテンツによっては特徴ベクトルが予め付与されているものが存在する。したがって、その場合、その特徴ベクトルを初期値としてそのまま利用する。
【０１３８】
特徴ベクトルの付与されていないコンテンツについては、問合せベクトルの場合と同様に、キーワード入力に基づき（図９中のＳ３１０）、ベクトルテーブル５５を選択して次元構成を決定し（Ｓ３４０，Ｓ３５０）、ベクトル表を参照して代表ベクトルを取得する（Ｓ３６０，Ｓ３７０）。
【０１３９】
問合せベクトルで説明した代表空間に対応する次元構成を前提として、映像名、映像の属性、カテゴリーと特徴ベクトルが対応付けられて定義された様子を図１１に例示した。
この場合も、キーワードから、特徴ベクトルとしての代表ベクトルを特定することができる。このキーワードは、情報センター５の外部入出力インタフェース５１を介してユーザから入力されるものとしてもよい。また、コンテンツに付随するメタデータからキーワードを抽出することもできる。メタデータを用いる場合には、特徴ベクトルの属性値を、このメタデータから特定することもできる。
【０１４０】
ベクトルテーブル５５は、ユーザ端末３のベクトルプロファイル３５に対応するものである。すなわち、次元構成の決定にあたって用いられる。また、代表的な属性基底をデフォルト空間として用意してもよい。前者が問合せベクトルでいうプロファイル空間、後者がデフォルト空間に対応する。そして、次元拡張が可能なことも同様である。これが、問合せベクトルでいうオプション空間に相当する。
【０１４１】
つまり、問合せベクトルと同様に、コンテンツの特徴ベクトルにおいても、アプリケーションに応じたベクトルテーブル５５としてのプロファイルを定義できる。同一プロファイルにおいては原則的に問合せベクトルと特徴ベクトルは次元の定義が一致する必要がある。一致しない場合は、後述するようにベクトルの拡張を行う。なお、同一コンテンツに対して複数のベクトルテーブルが適用されることもありうる。従って、その場合、同一コンテンツが複数の特徴ベクトルを持つことになる。
【０１４２】
特徴ベクトルの属性基底についても、問合せベクトルが動的になっていることに鑑み、本実施例では可変にした。これにより次元の追加という概念が導入でき、問合せベクトルとの適切な比較が可能となる。
【０１４３】
そして本実施例では、特に、特徴ベクトルの属性基底を、次に示すような一般次元と個人次元とで構成する。
一般次元とは、コンテンツの内容に関する一般的記述を行う。異なる端末で共通の特徴ベクトルを解釈できるようにするには規格化が必要になる。
【０１４４】
個人次元とは、コンテンツの内容に関して個人的記述を行う。規格化されたものから選択してもよいが、新規に情報センター５側で作成してもよい。これらは一般次元に対する拡張を意味する。
【０１４５】
さらに、動的に次元を追加する。次元の追加は、問合せベクトルのオプション空間の追加と同様に行うことができる。ただし、ＤＶＤやＣＤなどの読み出しのみ可能なメディアにメタデータが格納されている場合は、ハードディスクなど書きこみ可能なメディアに追加記述データを格納する必要がある。
【０１４６】
３．特徴ベクトルの修正（図１０中のＳ４５０）
コンテンツに対応する特徴ベクトルにおいても、初期ベクトルをそのまま使用するとカテゴリ毎に同一の特徴ベクトルをコンテンツが有することになり、ベクトルの重複や適合性の劣化を生じる。
【０１４７】
そこで特徴ベクトルを最適化する手法が必要になる。本実施例では、次に示すような手法で、特徴ベクトルの最適化を行う。
（１）コンテンツ製作者情報の利用（図１０中のＳ３９０）
製作者情報とは、映像メディアなどのコンテンツの製作者側の情報であり、例えば、時間、場所、製作者、製作コスト、アクターなどの情報であることが考えられる。これらの情報は、コンテンツのメタデータなどを解析して取得することが考えられる。
【０１４８】
（２）センター情報の利用（図１０中のＳ４００）
センター情報とは、検索状況、コンテンツへのアクセス状況、コンテンツの人気度、他のデータの動向などである。これは、検索履歴５６を情報センター５に格納しておくことによって参照可能となる。
【０１４９】
（３）マニュアル操作の利用（図１０中のＳ３８０）
本実施例では、基本的には、メタデータなどを解析して、コンテンツに対応する特徴ベクトルを自動的に生成することを特徴としている。しかし、個別に作業者が情報を付与することができるように、マニュアル操作からも情報を取得するようにした。
【０１５０】
（４）ベクトル間の反発作用の導入（図１０中のＳ４２０〜Ｓ４４０）
ベクトル間の反発作用とは、次に示すような手法を用い、登録済みの特徴ベクトルとの重複を回避するものである。その手法には、キーワードに対応する代表ベクトルのスカラー倍、代表ベクトルを中心としたベクトルの拡散、新次元の追加が考えられる。
【０１５１】
１）ベクトルのスカラー倍（図１０中のＳ４２０）
スカラー倍とは、スケール変更を意味し、図１２に示すように、特徴ベクトルとしての代表ベクトルを中心として、そのベクトル方向にスケール変更を行うことを意味する。ここで、スケール変更を行った特徴ベクトル群の重心ベクトルが代表ベクトルに一致するような制約条件をかけることが考えられる。
【０１５２】
２）ベクトルの拡散（図１０中のＳ４３０）
図１３は、ベクトルの拡散処理を示すフローチャートである。
処理が開始されると、同一キーワードの新規コンテンツを獲得する（Ｓ４３０１）。次に重心をキーワードの代表ベクトルに設定する（Ｓ４３０２）。そして次に偏差を決定し（Ｓ４３０３）、方向を決定して（Ｓ４３０４）、各特徴ベクトルを決定する（Ｓ４３０５）。これは、図１４に示すように、例えば代表ベクトルの終点を中心とする同心円上に、特徴ベクトルの終点が位置するような再配置を行うことと説明できる。一般的には、次に示すような式を満たすように特徴ベクトルを設定する。
Vr(kw) = (1/N) Σ VCi(kw)
ここでＶｒ（ｋｗ）は、キーワードｋｗに対する代表ベクトルであり、ＶＣｉ（ｋｗ）が特徴ベクトルを示している。なお、Σは、ｉ＝１〜Ｎの和記号である。
【０１５３】
すなわち、常に重心ベクトルがキーワードの代表ベクトルに一致するように、キーワードに対応する特徴ベクトル群を配置する。これによって、あたかもベクトル群が拡散したかのようにばらまかれ、各コンテンツを個別に検索することが可能になる。
【０１５４】
３）新次元の追加（図１０中のＳ４４０）
新次元の追加とは、あるキーワードについて定義される特徴ベクトルの属性基底で構成されるベクトル空間では、コンテンツの区別がつきにくい場合、それらのコンテンツを区別する新しい属性を新次元として、属性基底に追加することをいう。
【０１５５】
図１５に示すように、処理が開始されると、同一キーワードの新規コンテンツを獲得する（Ｓ４４０１）。次に新しい次元候補を探索する（Ｓ４４０２）。探索の結果に基づき、各次元の評価を行い（Ｓ４４０３）、新次元を決定して（Ｓ４４０４）、最後に、新次元の属性値を決定する（Ｓ４４０５）。新次元の追加のイメージは、図１６に示す如くである。
【０１５６】
例えば、代表空間の属性基底、（Splace, Stime, Actor, Genre, Weather, Csize, CodSch, Cost ）の下で、特徴ベクトルＶ１，Ｖ２がキーワード”観光情報”に対応して区別できない属性値を持つとする。
V1= (F80E46F0)
V2= (F80E46F0)
このとき、新しい属性として（Uplace, Utime ）を追加して、属性次元＝（Utime, Uplace, Splace, Stime, Actor, Genre, Weather, Csize, CodSch, Cost）の基で、特徴ベクトルＶ１，Ｖ２を次のように設定する。
V1= (FFF80E46F0)
V2= (00F80E46F0)
このような属性値の設定は、作業者自身が行うことも考えられる。しかし、各コンテンツの検索履歴を比較し、問合せベクトルや依存性ベクトル、関連キーワードにまで遡り、異なる属性を抽出して設定すれば、自動的に設定することができる。そのため、情報センター５の検索履歴５６は、問合せプロファイルと検索結果を対応させる形で格納しておく。
【０１５７】
なお、上述の例では、追加した属性次元に対し、一方の特徴ベクトルＶ１に対しては「ＦＦ」を設定し、他方の特徴ベクトルＶ２に対しては「００」を設定した。これに対し、追加した属性次元に対し、不定値や平均値を設定してもよい。
【０１５８】
４．特徴ベクトルの最適化の指標
特徴ベクトルの最適化の指標としては、次のようなものが考えられる。
（１）ある代表的な問合せに対して、時間的に新しいコンテンツの特徴ベクトルの評価値が大きくなるように配置する。例えば、渋滞情報については、最新映像の特徴ベクトルの評価値が最大になるようにする。
【０１５９】
（２）人気度の高いコンテンツの特徴ベクトルの評価値が大きくなるように配置する。
（３）多くの他のコンテンツが集中するような場所にある対象コンテンツを優先的に評価値が大きくなるように配置する。
【０１６０】
５．特徴ベクトルの格納（図１０中のＳ４８０）
このような特徴ベクトルは、特徴ベクトルデータベース５７に、階層化して格納することが考えられる。後述する検索の効率を向上させるためである。例えば、特徴ベクトルによって張られる特徴空間を階層化してラベル付けするという具合である。このようにすれば、コンテンツを所定のまとまりの単位で検索でき、より高速な検索が可能になる。
【０１６１】
階層化には、コンテンツの分割に基づく階層化、特徴ベクトルの分割に基づく階層化、特徴ベクトル空間の分割に基づく階層化がある。
（１）コンテンツの分割に基づく階層化
あるコンテンツに対して、一つの特徴ベクトルを付与することが通常考えられるが、これに対し図１７に示すように、メタデータ中のセグメント（コンテンツを分割する単位）あるいはセグメントの集まりで構成される階層毎に、特徴ベクトルを付与することが考えられる。
【０１６２】
セグメントの集まりという思想を取り入れる場合には、次のようなカテゴリで定義することができる。
１）空間的分割
シーン中の空間座標で分割する。例えばオブジェクトの切り出し・ラベリングがそれに相当する。このオブジェクトの集まりで構成されるセグメント群は階層を構成する。
【０１６３】
２）時間的分割
シーンの時間方向のまとまりで分割する。例えばシーンカットやショット分割で生成される個々のシーンやショット及びその集まりがセグメントに対応する。これらのセグメント群が階層を構成する。
【０１６４】
この場合の特徴ベクトルは各セグメントの要約に対応付けることができるため、要約ベクトルと呼ぶことにする。この要約ベクトルは映像でいえば、各ショットに付加することになるが、検索容易性向上のため、階層の最上位に各ショットの要約ベクトルのリストを持っておいてもよい。図１７中に記号ａで示す如くである。
【０１６５】
（２）特徴ベクトルの分割に基づく階層化
図１８に示すように、あるコンテンツの特徴ベクトルを複数のサブベクトルに分割して記述し、コンテンツ分類の階層化を行うことが考えられる。
【０１６６】
例えば、次のような属性基底を有する特徴ベクトルＶを、サブベクトルＶ０，Ｖ１，Ｖ２，Ｖ３に分解することができる。
V ＝（SPlace, Stime, Actor, Genre, Weather, Csize, CodSch, Cost）
V0＝（Weather）
V1＝（SPlace, Stime）
V2＝（Actor、Genre）
V3＝（Csize, CodSch, Cost）
このように特徴ベクトル自体を分割することにより、階層化を実現しておけば、高速な検索を実現することができる。例えばサブベクトルＶ１について検索をかけることで、まず時間や場所についての検索をかけることができ、より高速に目標コンテンツを絞り込むことができる。
【０１６７】
（３）特徴ベクトル空間の分割に基づく階層化
図１９（ａ）に示すように、特徴空間内の特徴ベクトル群をある属性次元でグループ分けすることができる。つまり、ある属性次元の特徴空間を考えると、この特徴空間内での距離が定義でき、その距離から、包含関係や因果関係が形成されるからである。したがって、図１９（ｂ）に示すような階層を構成することができ、ラベル付けを行うことができる。
【０１６８】
例えば、ユーザの周期時間や場所カテゴリに基づくユーザ軌道を考えるとユーザモデルが生成できる。
１）周期的な時間帯（朝昼晩、春夏秋冬など）ごとに問合せの発生頻度が高い特徴ベクトル群をグループ化する。ここで、時間軸には周期時間（一日、一週間、一月、一年など）を適用する。例えば、図２０に示すように、周期時間の範囲を直方体で示した場合に、終点がその内部に含まれる特徴ベクトルをグルーピングするという具合である。
【０１６９】
２）場所カテゴリ（自宅、高速道路、レストラン、公園、会社、遊園地、スキー場など）に応じて、問合せの発生頻度が高い特徴ベクトル群をグループ化する。
３）局面ごとに問合せの発生頻度が高い特徴ベクトル群を、グループ化する。
【０１７０】
なお、このようにしてグループ分けされた特徴ベクトルの集合であるクラスタは、さらに、問合せの履歴によって情報が与えられて構造化が進行する。この問合せ履歴による構造化については後述する。例えば、クラスタ間の因果関係に基づいた構造化により、さらなる階層化を行うことができる。具体的には、コンテンツの内容的因果関係によるグループ化や、ユーザ行動における因果関係によるグループ化を行う。
【０１７１】
このような因果関係による階層化により、クラスタ間が関係付けされるため、適切な情報検索が可能になる。
＜２−２＞検索
次に、情報センター５でなされる検索手法について説明する。
【０１７２】
本出願人は、特願２００１−１３６５号で、依存性ベクトルを用いた高速検索を提案した。本実施例においても、このようなベクトル検索の技術を採用する。本来、この高速検索手法はベクトルが依存性ベクトルであるかどうかには無関係であり、ベクトル形式に代表される少量データ（あるいはラベル）を用いた簡易判定により、本来解析すべき比較的大量の内容記述データの処理をスキップできることが、その高速性の原理である。
【０１７３】
まず、検索処理の概要を、図２１，２２，２３のフローチャートに基づいて説明する。
最初のＳ５００において、問合せプロファイルを読み込む。続くＳ５１０では、問合せベクトルのタイプを判定する。ベクトルタイプについては上述した通りである。次のＳ５２０では、問合せプロファイル中のキーワードや問合せベクトルの属性値をチェックする。
【０１７４】
Ｓ５２０でのチェック結果に基づき、Ｓ５３０では、キーワードは十分か否かを判断する。ここで、キーワードが十分であると判断された場合（Ｓ５３０：ＹＥＳ）、Ｓ５４０の処理を実行せずにＳ５５０へ移行する。一方、キーワードが十分でないと判断された場合（Ｓ５３０：ＮＯ）、Ｓ５４０にてキーワードの生成・連想・評価を行い、その後、Ｓ５５０へ移行する。
【０１７５】
Ｓ５５０では、視点の変更を行う。視点の変更とは、問合せベクトルを特徴空間上で表現する場合に、ユーザ情報に基づいて、変換処理を行うことを意味する。視点変更の詳細については、本実施例の特徴の一つである。
【０１７６】
続くＳ５６０では、高速化率に基づく検索手法の選択を行う。次のＳ５７０では、評価関数の修正を行う。
続く図２２中のＳ５８０では特徴ベクトルデータベース５７をアクセスし、Ｓ５９０にて特徴ベクトルの次元構成を把握する。そして、次のＳ６００では、ベクトル次元を選択して、Ｓ６１０で、特徴空間のクラスを特定する。このように特定次元のクラスを特定することにより、検索範囲を絞り込むことができる。
【０１７７】
次のＳ６２０では、特徴ベクトルの探索順序の設定を行い、Ｓ６３０にて、特徴ベクトルを取得する。そして、Ｓ６４０において、問合せ属性と特徴属性とを比較する。Ｓ６５０では、成分数が十分か否かを判断し、ここで成分数が十分であると判断された場合（Ｓ６５０：ＹＥＳ）、図２３中のＳ６８０へ移行する。一方、成分数が不十分であると判断された場合（Ｓ６５０：ＮＯ）、Ｓ６６０へ移行する。Ｓ６６０では、問合せベクトルの拡張を行う。また次のＳ６７０では、特徴ベクトルの拡張を行う。その後、図２３中のＳ６８０へ移行する。
【０１７８】
Ｓ６８０では、特徴ベクトルの評価を行う。続くＳ６９０では、評価基準を満足するか否かを判断する。ここで評価基準を満足すると判断した場合（Ｓ６９０：ＹＥＳ）、Ｓ７００へ移行する。一方、評価基準を満足しないと判断した場合（Ｓ６９０：ＮＯ）、図２２中のＳ５８０からの処理を繰り返す。
【０１７９】
Ｓ７００では、特徴属性値の評価を行う。続くＳ７１０では、検索終了か否かを判断する。ここで検索終了であると判断された場合（Ｓ７１０：ＹＥＳ）、Ｓ７２０へ移行する。一方、検索終了でないと判断された場合（Ｓ７１０：ＮＯ）、図２２中のＳ５８０からの処理を繰り返す。
【０１８０】
Ｓ７２０では、特徴空間の分割・構造化を行い、Ｓ７３０で特徴ベクトルの移動・再配置を行って、Ｓ７４０にて、コンテンツ記述を修正する。Ｓ７４０の処理終了後、本検索処理を終了する。
【０１８１】
以上が検索処理の概要であるが、上述した処理に対する理解を深めるため、特徴的な処理を個別具体的に説明する。
１．高速化率に基づく検索処理の適応化
検索の高速性は、ラベルのヒットする割合に大きく左右され、具体的には、高速化率として定量化できる。
【０１８２】
例えば高速化率Ｋは、上述のような検索方式のモデルでは、一例として、次のように表現できる。
Ｋ＝（１＋α）／（α＋β＋γ−βγ）
ただし、α、β、γは、以下のように定義される。
α＝Toc/Tp1
β＝n/N
γ＝Td1/T1
ここで、
n   ：ラベルがヒットするコンテンツ数
N   ：検索対象全体のコンテンツ数
Toc ：１個のメタデータファイルのオープン／クローズに要する時間
Tp1 ：ラベルを含む１個のメタデータの内容全てを解析する時間
Td1 ：ラベルを含む１個のメタデータの中で、ラベルのみを解析する時間
T1 ：ラベルを用いてＮ個のコンテンツ群全体を検索処理する時間
である。
【０１８３】
したがって、問合せとコンテンツラベルの統計的性質に基づいて高速化率を評価した上で検索手法を切り替えることが有効となる。
図２４，２５，２６のフローチャートに検索処理の適応化の一例を示した。
【０１８４】
処理が開始されると、問合せを獲得した後（図２４中のＳ８００）、対象コンテンツ群を設定する（Ｓ８１０）。対象コンテンツ群が特徴ベクトル記述を採用しているならば（Ｓ８２０：ＹＥＳ）、高速化率と予想検索時間を算出する（Ｓ８３０，Ｓ８４０）。そして検索時間に余裕があれば（Ｓ８５０：ＹＥＳ）、図２５中のＳ８６０へ移行する。検索時間に余裕がなければ（Ｓ８５０：ＮＯ）、図２６中のＳ９３０へ移行する。一方で、特徴ベクトル記述を採用していないならば（Ｓ８２０：ＮＯ）、図２５中のＳ８６０へ移行する。
【０１８５】
図２５中のＳ８６０では、対象コンテンツのメタデータを完全解析する。ベクトル評価が適する場合（Ｓ８７０：ＹＥＳ）、メタデータから特徴ベクトルを生成し（Ｓ８８０）、特徴ベクトルを用いたコンテンツ評価を行い（Ｓ８９０）、Ｓ９１０へ移行する。一方、ベクトル評価が適していない場合（Ｓ８７０：ＮＯ）、特徴ベクトル以外でコンテンツ評価を行い（Ｓ９００）、Ｓ９１０へ移行する。
【０１８６】
Ｓ９１０では、検索終了であるか否かを判断する。ここで検索終了であると判断された場合（Ｓ９１０：ＹＥＳ）、最終的な検索結果を選択し（Ｓ９２０）、本検索適応化処理を終了する。一方、検索終了でないと判断された場合（Ｓ９１０：ＮＯ）、次のコンテンツを選択して、Ｓ８６０からの処理を繰り返す。
【０１８７】
図２６中のＳ９３０では、ベクトルプロファイルの指定があれば（Ｓ９３０：ＹＥＳ）、ベクトルプロファイルを選択して（９４０）、Ｓ９５０へ移行する。一方、ベクトルプロファイルの指定がなければ（Ｓ９３０：ＮＯ）、そのままＳ９５０へ移行する。
【０１８８】
Ｓ９５０では、問合せベクトル及び特徴ベクトルの属性基底を設定する。そして評価のための属性数が十分である場合は（Ｓ９６０：ＹＥＳ）、Ｓ９８０へ移行する。一方、評価のための属性数が十分でない場合は（Ｓ９６０：ＮＯ）、未知属性の推定を行い（Ｓ９７０）、Ｓ９８０へ移行する。
【０１８９】
Ｓ９８０では、特徴ベクトルを用いたコンテンツ評価を行う。そして問合せにヒットするか否かを判断する（Ｓ９９０）。問合せにヒットすれば（Ｓ９９０：ＹＥＳ）、メタデータを完全解析・評価し（Ｓ１０００）、Ｓ１０１０へ移行する。一方、問合せにヒットしない場合には（Ｓ９９０：ＮＯ）、Ｓ１０００の処理を実行せず、Ｓ１０１０へ移行する。
【０１９０】
Ｓ１０１０では、検索終了か否かを判断する。ここで検索終了であると判断された場合（Ｓ１０１０：ＹＥＳ）、図２５中のＳ９２０へ移行する。一方、検索終了でないと判断された場合（Ｓ１０１０：ＮＯ）、次のコンテンツを選択して、Ｓ９３０からの処理を繰り返す。
【０１９１】
上述したコンテンツの評価は、コンテンツ記述に含まれる特徴ベクトルと特徴キーワードを問い合せプロファイルの内容と比較評価することで行う。例えば、特徴ベクトルの評価で一次フィルタリングを施し、その後キーワード評価によって絞り込むという検索順序が考えられるが、これに限定されるものではない。
【０１９２】
２．特徴キーワードの生成・連想・評価（図２１中のＳ５４０）
特徴キーワードの評価は検索キーワードとの比較によって行なわれる。特徴キーワードとは、コンテンツに対して付与されるキーワードである。
【０１９３】
その場合の比較手法としては、キーワードを全て数値データに置き換えてから比較する手法、キーワード間の比較評価表を参照して比較する手法、キーワードの連想ネットワーク情報を用いて評価比較する手法などを採用する。
【０１９４】
ある検索キーワードと特徴キーワードとの比較をテーブル参照によって評価値を読み出すことで行う場合を例に挙げて説明する。
例えば、検索キーワードが「スペイン料理」である場合、パエリア（100） 、チューロ（30）、ガスパチョ（40）、パスタ（70）、闘牛（80）という評価値つきデータが読み出されたとする。一方で、コンテンツの特徴キーワード：パエリア、パスタ、闘牛であるならば、コンテンツの評価値を例えば、100+30+80=210 と計算できる。
【０１９５】
なお、問合せプロファイル中に検索キーワードがある場合は、検索キーワードを基に検索を行う。問合せプロファイル中に検索キーワードがない場合は、問合せベクトルのみに基づいて検索を行う。ただし、別の手法として、検索履歴５６として記憶された過去の問合せ状況やユーザプロファイルから検索キーワードを生成するようにしてもよい。
【０１９６】
また、ベクトル検索を最初に行い、ある閾値以上の評価値が得られるコンテンツに対して該当するキーワードを取得してもよい。例えば、１０件のコンテンツがヒットした場合に、その１０件のコンテンツに対応する特徴ベクトルに付随するキーワードの中で上位のものを選択するという具合である。
【０１９７】
さらに、あるキーワードから別のキーワードを連想する構成としてもよい。このような連想の手法には、テーブル法や単語ネットワークを用いる方法がある。
テーブル法では、入力あるいは生成されたキーワードを基に、連想されるキーワードをあらかじめ格納したテーブルを参照し、最終的に例えば１０個の検索キーワード群を作成する。
【０１９８】
単語ネットワークを用いる方法では、単語間の連関を意味するネットワークを用意し、このネットワーク上で入力キーワードを発火点として他のキーワードに至る経路を探索する。この経路の数をスコアとして、スコア値の高いキーワードを選択する。
【０１９９】
図２７に示すように、キーワードＡと同一の辞書または単語クラスタ内の関連キーワードを活性化したり、また、キーワードＡの所属する辞書または単語クラスタ以外の辞書（単語クラスタ）を活性化したりする。このようにすれば、単語ネットワークによって、キーワードＢ，Ｃ，Ｄを連想することができる。
【０２００】
３．検索キーワードに応じたベクトル評価
また、検索キーワードと特徴キーワードとの比較だけでなく、検索キーワードに応じた特徴ベクトルの評価を行うことが考えられる。すなわち、同じ特徴ベクトルであっても検索キーワードの内容に応じて、ベクトルの評価値を変更することが考えられる。
【０２０１】
例えば、属性規定が（Splace, Stime, Actor, Genre, Weather, Csize, CodSch, Cost 
）である場合に、特徴ベクトルＶ１｛木曽三川公園の映像｝がキーワード”観光情報”に対応し、Ｖ１＝(DA0EF6F0)であるとする。
【０２０２】
これに対する問合せプロファイルの問合せベクトル及び検索キーワードが次に示すようなものである場合を考える。
＜問合せベクトル＞
Ｑ＝(FF000000)
＜検索キーワード＞
目的：トイレ休憩
緊急度：１００
現在地：市街地
この場合、目的がトイレ休憩であり、緊急度が高いために、属性基底Splaceに対する重みを2倍にするといったことが考えられる。
【０２０３】
通常は、問合せベクトルと特徴ベクトルの内積は、次に示す如く計算される。
評価値Ｅ＝Ｑ・Ｖ１＝(FF000000) (DA0EF6F0)＝15×13+15×10=345
これに対して、基底属性Splaceの重みを２倍にして、次のように評価値Ｅを算出する。
評価値Ｅ＝2×15×13+15×10=540
４．評価値の変更
特徴ベクトルに対する評価値は、問合せプロファイルのキーワードを用いた重み付けによって調節できることを述べた。
【０２０４】
しかし、アプリケーションや個人の特性によっては検索上特に重要な属性次元を強調したり、切り捨てたりする必要がでてくる。評価値をある属性についての重み付けによって上げることもさることながら、あるユーザの評価上非常に大きなマイナス効果を示すような属性については切り捨てる必要がある。
【０２０５】
例えば、２つのレストランＡ，Ｂの特徴ベクトルが、属性基底（ファミリー度、綺麗度、喫煙者対応度）の下で、次に示すようなものであった場合を考える。
レストランＡの特徴ベクトル：（80,70,90）
レストランＢの特徴ベクトル：（80,60, 0）
これに対して、問合せベクトルが
（ファミリー度、綺麗度）＝（100,60）
である場合、２つのレストランＡ，Ｂは両方とも、上記２つの属性では満足すると見られるが、ユーザの特性として、
喫煙対応度 ≦ 50
を希望するのであれば、レストランＡの評価値を極端に下げる必要がでてくる。例えば、上記条件を満たさない場合、一律に１０段階正規化の評価値を「２」に設定することも考えられる。その結果、問合せに対してはレストランＡよりも低い評価値を持つレストランＢが、より好ましいレストランとして検索される。
【０２０６】
５．検索の高速化手法
本来、特徴ベクトルは少量データであり、全成分を検索処理したとしても高速処理の効果は十分あるが、特許第２７７８４３０号で開示した３次元位置姿勢の巡回一次元探索、あるいは、特開２０００−２２１９９１号での多段階と同じ考えを特徴空間のベクトル探索に適用すれば、さらに高速化をはかることができる。特に、情報検索の場合、問合せにおける（時間、場所）に対する依存性を最優先して判定した後に、即座に（時間、場所）の属性値を評価する方が効率がよいと考えられる。
【０２０７】
６．特徴空間のクラスによる検索（図２２中のＳ６１０）
問合せにおいて、時間及び場所などの主要パラメータに対する依存性が高いことが分かっているならば、特徴空間上でも、その主要パラメータの構成する部分空間をクラス分けすることが考えられる。図２８に示す如くである。この場合、各クラスに属するベクトルにクラス識別子をつけておく。
【０２０８】
このクラス分けにより、例えば、問合せベクトルの時間及び場所への依存性が、次に示すように最高値であれば、
時間に対する依存性＝F
場所に対する依存性＝F
最初から図２８のクラス１の近傍に焦点をしぼって、検索をかけることができる。
【０２０９】
７．ベクトルの拡張（図２２中のＳ６６０，Ｓ６７０）
問合せベクトルとコンテンツ特徴ベクトルの演算によりコンテンツを評価する際に、必ずしもベクトルの次元（属性基底）が整合しない場合がある。問合せベクトルと特徴ベクトルとの関係は、図２９に示すように、３つのケースに分けられる。
【０２１０】
Case-1) 問合せベクトルの成分が、特徴ベクトルで記述する成分に含まれる場合である。
この場合、問合せベクトルの成分の範囲でコンテンツ評価演算を実行できる。
【０２１１】
Case-2) 問合せベクトルと特徴ベクトルの成分の交わりはあるが、ｑのすべての成分が使えるわけではない場合である。
交わりの数が十分多ければ、そのまま評価演算を実行できる。不十分であれば、ベクトルの拡張を行う。
【０２１２】
Case-3) 問合せベクトルと特徴ベクトルの成分上の交わりがまったくない場合である。
この場合は、原則的に低い評価値をつける。ただし、問合せベクトルあるいは特徴ベクトルのベクトルを拡張するようにしてもよい。
【０２１３】
なお、ベクトルの拡張イメージを図３０に示した。また、成分上の交わりは一種のベクトル同士の近さを示す指標とも考えられるため、問合せベクトルと特徴ベクトルの成分の交わりの数をコンテンツ評価値に付加することも考えられる。
【０２１４】
（１）問合せベクトルの拡張（図２２中のＳ６６０）
問合せベクトルに対し、問合せベクトルで不足する成分を推定し、問合せベクトルを拡張する。
【０２１５】
方法１）関連キーワードからの連想による拡張
方法２）同一次元内での近傍ベクトルをサンプルして、そのベクトルの持つ新しい次元を付加していく。
【０２１６】
例えば、旅行情報の問合せベクトル：Ａ＝（a1,a2,a3,a4 ）に対してレストランの問合せベクトルがＢ＝（a1,a2,a3,b1,b2,b3 ）で構成されており、両者の交わりである[a1,a2,a3]に関してのＡとＢの距離ＳＬを計算する。
SL（A,B）＝dist(SA,SB)
SA=(a1(A),a2(A),a3(A))
SB=(a1(B),a2(B),a3(B))
ai(X)：ベクトルXにおける次元aiに関する成分値を示す。
このとき、ある閾値SLthに対して
SL ≦ SLth
を満足するSLの場合にＢは[a1,a2,a3]で張られる空間においてＡと近いとみなし、
Ae＝（a1,a2,a3,a4,b1,b2,b3）
と、新たに、[b1,b2,b3] を拡張して新しい問合せベクトルとする。成分値はＢをそのまま使ってもよい。この中で対象コンテンツの特徴ベクトルｃとの成分交わり数が十分な数になればコンテンツの評価計算を実行する。十分でなければさらにベクトルの拡張を続ける。
【０２１７】
（２）特徴ベクトルの拡張（図２２中のＳ６７０）
特徴ベクトルはコンテンツの特徴を示すものであるため、内容記述（メタデータ）中のキーワードから導出したキーワード群を基に推定する。また、他ユーザも含めたユーザからの問合せ履歴を基に拡張する。
【０２１８】
（３）問合せ履歴による拡張（図２３中のＳ７２０，Ｓ７３０，Ｓ７４０）
ある一連の問合せ行為の履歴（検索キーワード、問合せベクトル、コンテンツの選択結果、評価を含む）を用いて特徴空間にフィードバックを与え、特徴空間の構造化・分割、特徴ベクトルの再配置・移動などを行う。例えば図３１（ａ）に示す如く、公園→食事→買い物という一連の行動における因果関係を学習する。これにより、図３１（ｂ）に示すような「行楽」というラベリングが施せる。
【０２１９】
ただし、これらは許容される検索時間内に収まる範囲で、しかも問合せを行っているユーザに対してのみ行う仮の操作である。したがって、最終的に共通データベースとしての特徴空間を書き換えるかどうかの判断はシステムが行う。なお、データベースそのものを書き換えるという操作は後述する。
【０２２０】
コンテンツの特徴ベクトルを階層化する手法については既に述べた。これに対して、検索時においては、問合せプロファイルが利用できる。
つまり、上述した特徴空間の分割、特徴ベクトルの再配置、特徴ベクトルの移動などについて問合せプロファイルが利用できる。問合せプロファイルには、問合せ情報と共にユーザプロファイルに基づくユーザ情報が記述される。したがって、これらユーザ端末３側の要因を考慮した情報センター５側の最適化を図ることができる。
【０２２１】
８．評価関数の修正（図２１中のＳ５７０）
（１）不定成分を含んだ特徴ベクトルの評価手法
例えば、問合せベクトルＱ及びコンテンツの特徴ベクトルＣが、次のように不定値を含んでいる場合を考える。
Q=（1, 3,2,8,X1）
C=（3,X2,4,2,X3）
この場合、内積演算を用いたコンテンツの評価値Ｅは、次に示す如くとなる。
E=A・B＝1*3 + 3*X1 + 2*4 + 8*2 + X2*X3
ここで、評価値Ｅが具体的な数値になるように、次のいずれかの手法を採用する。いずれの手法を採用するかは、所定の条件判断による。
【０２２２】
１）１０段階の平均としてX1=X2=X3=5と一律におく
２）ｉ番目の成分の平均値Miに置きかえる。即ち、X1=M5、X2=M2、X3=M5とおく。
２）Ｘを含む成分は計算しない。即ち、E=1*3 + 3*0 + 2*4 + 8*2 + 0*0=25と計算する。
【０２２３】
９．コンテンツ記述の適応化（図２３中のＳ７４０）
情報センター５のコンテンツデータベース６１に格納されるコンテンツは、複数のユーザで共通に利用される。したがって、コンテンツ記述は、不変または一意的に記述されることが望ましい。
【０２２４】
（１）固定記述
膨大な数のコンテンツを扱うセンター型のデータベースではコンテンツ作成時にもともとつけられているメタデータ記述は固定であることが望ましい。ただし、あるコンテンツに複数のメタデータ記述がつくことはありうる。例えば、ユーザのタイプ（性別、年齢、目的など）に応じて適切なメタデータを複数用意することが考えられる
（２）記述の修正
コンテンツのユーザ評価結果やシステム変更などに基づいて記述の修正を行う。データベース上の個々のコンテンツに対応するメタデータ（特徴ベクトルを含む）をユーザが書き換えることができない場合でも、ユーザ端末３上の記憶領域（ハードディスクなど）を用いれば、ユーザの特性やプロファイルを利用した個別の特徴ベクトル付与ができる。例えば、あるスポットの渋滞具合、ある銘柄の株価、あるシーン中の人の人数などがそれに相当する。
【０２２５】
（３）適応化
各ユーザへの適応化に必要なデータは情報センター５側にも記憶できるが、プライバシー面を考慮すればユーザ端末３側に記憶する。
【０２２６】
一方、ユーザ端末３に個人のコンテンツを記憶することもできる。例えば、ユーザが記録した観光地のビデオ映像などが、これである。
この場合も、コンテンツ記述を、固定記述と動的記述に分けることができ、動的記述は、書き換え可能な記憶領域に書き込むようにする。このようなコンテンツの適応化は、次の要因を考慮してなされる。個人によってコンテンツに対する価値観や検索特性が異なること、また、あるユーザでも状況に応じて検索特性が変わることである。特に、これらはユーザプロファイル３８などのユーザ記述に基づいて記述が制御されるかあるいは複数の記述の中から適切なものが選択される。
【０２２７】
１０．視点の変更（図２１中のＳ５５０）
（１）視点変更の意義
特徴ベクトルによって張られる空間である特徴空間は、ある視点における特徴空間であると言える。
【０２２８】
このとき、図３２に示すように、ユーザの状況や個人的特性に応じて、特徴空間上での問合せベクトルの原点及び座標系（これをユーザ視点と呼ぶ）を変更する。
すなわち、問い合せベクトルを特徴空間上に位置付ける際に、
１）問い合せの視点の変更
２）個人の特性や状況に応じた尺度変換
という概念を導入する。これらを統一的に表現するために、特徴空間上のベクトルを観測する座標系Ｈを考える。もっとも平均的な視点を初期値に選ぶとＨは特徴空間の座標系Ｃに一致する。座標系Ｈは特徴空間の座標系Ｃに対して回転・原点移動、縮尺変更が施されたものであると考えられ、一般に線形変換Ａにより次に示すように表現できる。
H = A C
非線型な尺度も考えられるが、これは問合せを用いた評価関数の表現で実現できる。Ｃ上の特徴ベクトルをＨで観測する場合、符号の変わる属性値も出てくる可能性がある。その場合の制約としては、次のような手法が考えられる。
【０２２９】
１）コンテンツの評価上支障が出ないように、特徴ベクトルの変換結果を補償する
２） 変換行列Ａに制約を加える
例えば、天候への依存性を記述する属性次元について「晴れ」への依存性が視点変更Ａによって「雨」への依存性に変換されるということは、いかに個人差があるとはいえ、通常では考えにくい。このＨは基本的にはユーザの視点であるのでユーザプロファイル中の状況記述によって決定される。つまり、線形変換Ａを定義する場合、ユーザ個人に依存するものとして定義すればよい。
【０２３０】
（２）ユーザモデル３７による視点変更
図３３は、ユーザモデル３７による視点変更処理のフローチャートである。
処理が開始されると、状態節点から特徴空間上の視点座標系を生成する（Ｓ５５０１）。図３４に示すように、状態節点ＱＡ，ＱＢから、視点ＡやＢを生成する。次に、状態節点から問合せを生成する（Ｓ５５０２）。最後に、問合せを視点座標系にマッピングする（Ｓ５５０３）。図３４中に問合せベクトルのマッピングを２点鎖線で示した。
【０２３１】
図３４では、視点座標系が変更されることにより、個々のユーザからの視点に合わせたベクトル配置に変更されている。
＜３＞システムの更新
システムの更新とは、検索時における瞬時の適応化ではなく、多くの検索履歴を踏まえたユーザ端末３及び情報センター５側の適応化である。
【０２３２】
システム全体の更新処理を、図３５のフローチャートに示した。
まず最初のＳ１１００において、再検索か否かを判断する。ここで再検索であると判断した場合（Ｓ１１００：ＹＥＳ）、問合せの修正を行い（Ｓ１１１０）、検索対象の修正を行い（Ｓ１１２０）、検索モジュールを修正して（Ｓ１１３０）、Ｓ１１４０へ移行する。一方、再検索でないと判断した場合（Ｓ１１００：ＮＯ）、Ｓ１１１０〜Ｓ１１３０の処理を実行せずにＳ１１４０へ移行する。
【０２３３】
Ｓ１１４０ではベクトルの移動・再配置を行う。続くＳ１１５０では、特徴空間の分割・構造化を行う。次のＳ１１６０では、特徴空間のクラス分類を行い、Ｓ１１７０では、コンテンツ記述の修正を行う。そしてＳ１１８０でユーザモデルの修正を行って、本システム更新処理を終了する。
【０２３４】
以上がシステム更新処理の概要であるが、上述した処理に対する理解を深めるため、特徴的な処理を個別具体的に説明する。
１．適合性によるフィードバック
対話を通じた問合せの進展により、ある時点で検索結果の正しさに対するユーザの評価を得ることができる。そこで、現状の検索システムの適合性（relevance ）を下記の要素に対してフィードバックすることが考えられる。
【０２３５】
（１）ユーザ端末３側
１）問い合せの修正
２）コンテンツ記述の追加・修正
３）検索モジュールに送る制御パラメータの修正（評価関数、他）
４）検索エージェントに送る検索対象指示パラメータ（URL 他）の修正
５）ユーザモデル３７の修正
（２）情報センター５側
１）問い合せの処理特性の修正
２）コンテンツ記述の追加・修正
３）検索モジュールの修正（評価関数、他）
４）検索対象の修正
５）ユーザモデルの修正
２．問合せの修正（図３５中のＳ１１１０）
問合せの修正は検索時にも行われるが、検査結果を一度提示した後、再度行われる問合せについてここで述べる。つまり、Ｓ１１００にて肯定判断される場合である。
【０２３６】
（１）ユーザ端末３側
１）キーワードの修正
２）キーワードの重み付け値の修正
３）問合せベクトルの修正
（２）情報センター５側
１）問合せの拡張特性の修正
２）問合せの視点情報の修正
３）問合せベクトルそのものの修正
２．コンテンツ記述の追加・修正（図３５中のＳ１１７０）
ユーザ端末３側ではＨＤ部など書き換え可能な記憶領域に書き込む。例えば、あるレストランの評価や喫茶店の雰囲気などは個人によって受け取り方が異なるため、必ずしも共通のデータベース上に書かれてある紹介とは一致しない。そこで、各ユーザの評価に基づく内容説明を自分の端末に個人用データベースとして書いておくことが考えられる。あるいは、まだ共通データベースに登録されていない新しいスポットに関する情報やテンポラリーな状況（事故発生、工事渋滞、抜け道情報、穴場情報、他など）などもそれに相当する。
【０２３７】
３．検索モジュールの修正（図３５中のＳ１１３０）
検索モジュールについては以下の修正が考えられる。
（１）評価関数の適用基準や評価関数そのものを修正する
（２）意味ネットワークやキーワードテーブルの修正
（３）視点変更の特性を修正する
４．検索対象の修正（図３５中のＳ１１２０）
検索サイトの変更や同一サイトでも検索するデータベースを変更することに相当する。例えば、あるメーカーの製品情報を検索する場合、古いモデルの情報を蓄積したホームページのＵＲＬがそのままになっていることがあるが、それらを新しいモデルの情報を蓄積したホームページのＵＲＬに変更する。
【０２３８】
５．ユーザモデル３７の修正（図３５中のＳ１１８０）
（１）ユーザモデル３７に基づく問合せの発生
図３６は、ユーザモデル３７でも最も簡単な時間モデル、特に１週間における疲労の変化をモデリングした事例を示す。特願２０００−２８５５２１号の提案に基づき、このようなユーザモデル３７が規定する状態空間中のユーザ軌道上のある状態節点からユーザ要求が生まれ、さらにそれがユーザ端末に対する問合せを生成すると考えることができる。例えば図３７に示す如くである。すなわち、ユーザ要求に基づく問合せという形で、ユーザの状態空間からコンテンツの特徴空間へのマッピングが行われる。
【０２３９】
（２）ユーザモデル３７の内部に関する変更
ユーザモデルの特性を変更することは例えば下記のように行われる。
ユーザモデルによるユーザ状態の予測精度の評価値ＥＭを例えば次式で表す。
EM = (1/K) Σ｜Xpi−Xdi｜
ここで、
Xpi ：ユーザモデルに基づくユーザ状態の予測値（ｉ番目の成分に関して）
Xdi ：対話から獲得した状態推定値（ｉ番目の成分に関して）
Σ  ：ｉ＝１〜Ｋの和記号
これに対して、あるしきい値Xth を設定し、
EM＞Xth
ならばユーザモデル３７を修正する。ここで、モデルの修正手段には次の手法が考えられる。
【０２４０】
１）現行のモデルを軸上（例えば時間軸）でシフトする
２）モデルをある軸にそってスケーリングする
３）いくつかのモデルの中から現在と異なるものを選択する
（３）ユーザモデル３７とその外部との間の関係定義に関する変更
ユーザモデルの状態（環境、状況、要求、状態、局面、行動のすべてに相当）と依存性ベクトルの関係定義を変更する。例えば、ある局面｛行楽地の交通渋滞｝において、ユーザによってはナビによる渋滞回避経路の探索よりもテレビ、音楽、ニュース、ラジオなどを操作することの方が優先度が高いこともありうる。そのような場合は依存性ベクトルはそれに整合するように変更される。情報センター５側では、例えばバブル全盛時代に比べて不況下では投資家情報の優先順位を下げるなどの変更がありうる。
【０２４１】
６．読み出しのみのコンテンツに対する検索
ＣＤやＤＶＤなど読み出しのみ可能で変更付加の記憶媒体上のコンテンツに対しては、固定のメタデータが記述されていることが考えられる。それに対する各ユーザの使用履歴に基づくベクトルの学習は他の記憶媒体（ハードディスクや外部記憶）を用いて行う。記憶対象としては以下のものが一例として挙げられる。
【０２４２】
１）問合せベクトル
２）依存性ベクトル
３）コンテンツ検索結果
以上詳述したように、本実施例によれば、包括的に機能する情報検索システムが実現され、問合せ記述の自動生成及び最適化、コンテンツ記述の自動生成及び最適化、さらに、検索処理の最適化、システムの学習更新が可能となる。
【図面の簡単な説明】
【０２４３】
【図１】ベクトルに基づく情報検索を示す説明図である。
【図２】実施例の検索システムの構成を示す説明図である。
【図３】問合せ生成処理の前段部分を示すフローチャートである。
【図４】問合せ生成処理の後段部分を示すフローチャートである。
【図５】代表ベクトル値対応表を例示する説明図である。
【図６】ベクトル属性基底表を例示する説明図である。
【図７】問合せプロファイルへの情報集約を示す説明図である。
【図８】ユーザ軌道を用いた問合せベクトルの修正を示す説明図である。
【図９】特徴ベクトル生成処理の前段部分を示すフローチャートである。
【図１０】特徴ベクトル生成処理の後段部分を示すフローチャートである。
【図１１】特徴ベクトルのテーブルによる特定を示す説明図である。
【図１２】ベクトルのスケール変更を示す説明図である。
【図１３】ベクトルの拡散処理を示すフローチャートである。
【図１４】ベクトルの拡散を示す説明図である。
【図１５】ベクトルへの新次元の追加処理を示すフローチャートである。
【図１６】ベクトルへの新次元の追加を示す説明図である。
【図１７】コンテンツの分割に基づく階層化を示す説明図である。
【図１８】属性基底の分割に基づく階層化を示す説明図である。
【図１９】特徴空間の分割に基づく階層化を示す説明図である。
【図２０】周期時間を考慮したベクトルのグループ化を示す説明図である。
【図２１】検索処理の前段部分を示すフローチャートである。
【図２２】検索処理の中段部分を示すフローチャートである。
【図２３】検索処理の後段部分を示すフローチャートである。
【図２４】検索適応化処理の前段部分を示すフローチャートである。
【図２５】検索適応化処理の中段部分を示すフローチャートである。
【図２６】検索適応化処理の後段部分を示すフローチャートである。
【図２７】単語ネットワークによるキーワードの連想を示す説明図である。
【図２８】特徴空間のクラス分けを示す説明図である。
【図２９】問合せベクトルと特徴ベクトルとの関係を示す説明図である。
【図３０】問合せベクトルや特徴ベクトルの拡張を示す説明図である。
【図３１】問合せからの因果関係の学習を示す説明図である。
【図３２】座標変換によるユーザ視点の変更を示す説明図である。
【図３３】視点変更処理を示すフローチャートである。
【図３４】ユーザモデルに基づく視点変更を示す説明図である。
【図３５】システムの更新処理を示すフローチャートである。
【図３６】ユーザの一週間の疲労モデルを示す説明図である。
【図３７】ユーザモデルからの問合せの発生を示す説明図である。
【符号の説明】
【０２４４】
３…ユーザ端末
３１…外部入出力インタフェース
３２…通信制御部
３３…対話制御部
３４…ベクトル検索・生成・修正部
３５…ベクトルプロファイル
３６…問合せ履歴
３７…ユーザモデル
３８…ユーザプロファイル
３９…問合せ生成部
４０…キーワード連想部
５…情報センター
５１…外部入出力インタフェース
５２…通信制御部
５３…コンテンツ管理・検索制御部
５４…ベクトル検索・生成・修正部
５５…ベクトルテーブル
５６…検索履歴
５７…特徴ベクトルデータベース
５８…内容記述検索・生成・修正部
５９…内容記述データベース
６０…コンテンツ評価部
６１…コンテンツデータベース
【図２】
2006228255.tif 000003
【図３】
2006228255.tif 000004
【図４】
2006228255.tif 000005
【図５】
2006228255.tif 000006
【図６】
2006228255.tif 000007
【図７】
2006228255.tif 000008
【図８】
2006228255.tif 000009
【図９】
2006228255.tif 000010
【図１０】
2006228255.tif 000011
【図１１】
2006228255.tif 000012
【図１２】
2006228255.tif 000013
【図１３】
2006228255.tif 000014
【図１４】
2006228255.tif 000015
【図１５】
2006228255.tif 000016
【図１６】
2006228255.tif 000017
【図１７】
2006228255.tif 000018
【図１８】
2006228255.tif 000019
【図１９】
2006228255.tif 000020
【図２０】
2006228255.tif 000021
【図２１】
2006228255.tif 000022
【図２２】
2006228255.tif 000023
【図２３】
2006228255.tif 000024
【図２４】
2006228255.tif 000025
【図２５】
2006228255.tif 000026
【図２６】
2006228255.tif 000027
【図２７】
2006228255.tif 000028
【図２９】
2006228255.tif 000029
【図３０】
2006228255.tif 000030
【図３１】
2006228255.tif 000031
【図３２】
2006228255.tif 000032
【図３３】
2006228255.tif 000033
【図３４】
2006228255.tif 000034
【図３５】
2006228255.tif 000035
【図３６】
2006228255.tif 000036
【図３７】
2006228255.tif 000037
【図１】
2006228255.tif 000038
【図２８】
2006228255.tif 000039