(A)第1の実施形態
以下では、本発明の検索システム及び検索プログラムの第1の実施形態について図面を参照しながら詳細に説明する。
第1の実施形態では、ユーザに対して質問を繰り返してユーザの真のニーズや希望を引き出すラダリングを利用した対話型検索システムに本発明を適用した実施形態を例示して説明する。
(A−1)多次元オントロジーの基本概念
第1の実施形態において利用するマッチングテーブルは、語と語の関係を表したネットワーク構造で表現することができるため、オントロジーとみなすことができる。したがって、第1の実施形態では、多次元オントロジーの概念をマッチングテーブルに応用する。
まず、この多次元オントロジーの概念を、図面を参照しながら説明する。
多次元オントロジーとは、多数の意味空間を多次元化して保持し、対話で得られるユーザのデータ又は対象データ/状況に応じて、使用する意味空間を瞬時に切り替えることができるオントロジーをいう。
上述したように、現行のオントロジーは、ある1つの観点からしか語の概念や語と語の関係を表現していないので、現行のオントロジーを対話型検索システムに利用しても、静的なデータしか得られない。
そこで、第1の実施形態では、オントロジーを多次元化して保持できるようし、さらにユーザから引き出した情報が変化するたびに次元間を自動的に移動する仕組みを提案する。
これにより、対話で得られるユーザデータや状況に応じて瞬時に、意味空間を切り替えたり、対話のための情報を切り替えることができ、対話や検索がもつダイナミック性をシステムとして実現できる。また、次元間でデータを継承できるようにすることで、記述性とその省力性(最小限の記述)を同時に実現した。多次元化の最大の特徴である記述したいところだけを詳細に記述することができる。
図2及び図3は、多次元オントロジーの基本概念を説明する説明図である。図2及び図3では、第1の実施形態の対話型検索・解析システム1を職業紹介システムに利用した場合を例示する。
図2及び図3に示すように、多次元オントロジーは、それぞれプロパティが設定されている次元が、優先度に従って位置づけされており、ベースの次元と、ベース以外の特別な次元(以下、サブ次元という)とを有して構成される。
ベースの次元及びサブ次元には、それぞれ様々なオントロジーが定義されている。ベースの次元とは、最も優先度が低い次元であり、サブ次元に定義される全てのクラス及びプロパティが定義されているものである。また、サブ次元は、それぞれ必要なクラス及びプロパティだけが定義されており、条件の数が多いものほど優先度が高くなる。なお、条件の数が同数の場合には、例えば、開発者により予め優先度付けしておく。
例えば、図2及び図3では、ベースの次元を含めて6次元オントロジーを例示する。「業種=IT」のサブ次元、「職種=営業」のサブ次元、「職種=SE」のサブ次元はそれぞれ、条件が1個であり、条件数が同数であるが、「業種=IT」のサブ次元、「職種=営業」のサブ次元、「職種=SE」のサブ次元の順に優先度を高く設定したものとする。
また「職種=営業&&業種=IT(この表記は「職種が営業であり、かつ、業種がITである」ことを示す、以下同様である)」のサブ次元、「職種=SE&&業種=IT」サブ次元はそれぞれ条件が2個であり、条件数が同数であるが、「職種=営業&&業種=IT」のサブ次元、「職種=SE&&業種=IT」の順に優先度を高く設定したものとする。
従って、これらの次元を重ねると、「ベースの次元」は優先度が最も低いので、次元の優先度は、「ベースの次元」→「業種=IT」のサブ次元→「職種=営業」のサブ次元→「職種=SE」のサブ次元→「職種=営業&&業種」のサブ次元→「職種=SE&&業種=IT」サブ次元の順に高くなる。
また、図2及び図3において、各サブ次元上の丸は、各サブ次元で定義されているクラス及びプロパティを示す。
図2は、ユーザから「何も(データを)取得していない時」を示す。この場合、まだ対話が進行していない。このとき、ベース次元に定義されているクラス及びプロパティ(図2には図示しない)を用いて対話進行する。
対話が進行して、ユーザから「業種=IT」とする条件を取得したとする。この場合、図3に示すように、適用される次元は「業種=IT」のサブ次元となり、この「業種=IT」のサブ次元に定義されているクラス及びプロパティを用いた対話に切り替る。
さらに対話が進行して、ユーザから「職業=営業かつ業種=IT」とする条件を取得したとする。この場合、図3に示すように、適用される次元は「職種=営業&&業種=IT」のサブ次元となり、この「職種=営業&&業種=IT」のサブ次元に定義されているクラス及びプロパティを用いた対話に切り替る。
ここで、対話に適用された次元は、「業種=IT」と「職業=営業かつ業種=IT」の2個のサブ次元であり、適用された各サブ次元のクラス及びプロパティは、ベースの次元に上書きされて継承される。このとき、優先度の高いサブ次元のクラス及びプロパティが記憶されるように、優先度が低いサブ次元から順に継承される。つまり、ベースの次元には、「業種=IT」のサブ次元のクラス及びプロパティが記憶されてから、「職業=営業かつ業種=IT」のサブ次元のクラス及びプロパティが上書きされる。
このように多次元オントロジーを用いることにより、次元間でデータを継承することができ、マッチングテーブルにおいても、対象データとユーザデータの対応関係や重要度などの値を次元間で継承することが可能となる。
(A−2)第1の実施形態の構成
以下では、第1の実施形態の対話型検索システムの全体構成について、図1を参照しながら説明する。
図1において、第1の実施形態の対話型検索システム1は、対話管理部10、意図解析部20、ドメイン知識管理部30、マッチング部40、マッチング対象分析部50を少なくとも有して構成される。
対話型検索システム1は、ユーザにデータを提供するデータ提供サーバ80と接続しており、データ提供サーバ80が保持する対象データを取得し、マッチング対象分析部50の拡張対象データ54に格納する。
ユーザは、ブラウザ90を用いてWebサーバ70にアクセスすることで、対話型検索システム1を起動させる。なお、ユーザ側のインターフェースとしては、通信機能を有するPCや携帯端末や専用端末など広く適用することができるが、ユーザが発した音声をテキスト変換する音声合成・認識部等を備えるようにしてもよい。
対話管理部10は、検索を希望するユーザとの間の対話進行を管理するものであり、対話進行を制御する対話制御部11を有する。
対話制御部11は、ドメイン知識管理部30から多次元オントロジーを受け取り、この多次元オントロジーに基づいて、対話進行に係る質問文(システム発話文ともいう)を作成するものである。
また、対話制御部11は、質問文に対するユーザからの回答文(ユーザ発話文ともいう)を意図解析部20に与えてユーザ発話文の内容を解析させるものである。なお、対話制御部11は、ユーザ発話文の解析結果を受け取ると、そのユーザ発話文の解析結果をユーザデータとして、マッチング対象分析部50の拡張ユーザデータ53に格納する。
さらに、対話制御部11は、意図解析部20から意図解析結果を受け取ると、その意図解析結果をドメイン知識管理部30に与えて、対話進行に利用する多次元オントロジーを生成させ、ドメイン知識管理部30からの多次元オントロジーを利用して、次の質問文を決定して対話を進行させる。
また、対話制御部11は、マッチング部40に対してユーザのデータと対象データとのマッチングを指示するものである。このマッチングを指示するタイミングは、例えば、ユーザからのマッチング指示を受けたときや、各質問文に対する回答文が得られたときや、全ての質問項目が終了したときなどと種々のタイミングを設定することができる。
意図解析部20は、対話制御部11から取得した質問文に対してユーザが回答したユーザ発話文を受け取り、ユーザ発話文の内容を解析するものである。また、意図解析部20は、解析した意図解析結果をオントロジー形式にして対話制御部11に与える。さらに、意図解析部20は、多次元意図解析処理として、ドメイン知識辞書の動的切替処理や解析対象文情報による動的切替処理を行うものである。
意図解析部20は、意図解析実行部21、意図解析用辞書22、ドメイン知識辞書マネージャ23を有する。
意図解析実行部21は、意図解析用辞書22を参照して、ユーザ発話文に対して形態素解析を行う形態素解析部211と、意図解析用辞書22を参照して、ユーザ発話文に対して構文解析を行う構文解析部212を有する。
意図解析実行部21は、ユーザ発話文に対して形態素解析や構文解析を行うことで、ドメイン知識DB32のプロパティ定義に定義されるクラスを取得し、取得したクラスをドメイン知識管理部30に与える。
意図解析用辞書22は、ユーザ発話文の内容を解析するための辞書群であり、例えば、形態素辞書(例えば、日本語形態素辞書)、構文辞書(例えば、日本語構文辞書)、ベース次元及び各次元のクラス定義から自動生成されたドメイン知識辞書等が該当する。
ドメイン知識辞書マネージャ23は、ユーザデータ管理から拡張ユーザデータを受け取り、この拡張ユーザデータに応じて、辞書引きする次元別ドメイン辞書の優先順位を並べ替え、その並べ替えた次元別ドメイン辞書を、意図解析辞書22に設定するものである。
また、ドメイン知識辞書マネージャ23は、データ提供サーバ80からの対象データ(対象文情報)の解析結果を意図解析実行部21から受け取り、対象データの内容に応じて、辞書引きする次元別構文辞書の並べ替えを行い、この並べ替えをした次元別構文辞書を、意図解析辞書22に設定するものである。
ドメイン知識辞書マネージャ23は、特徴抽出部231、条件並替部232、辞書設定部233を有する。
特徴抽出部231は、意図解析結果から次元の条件となる値が含まれている場合に、その次元条件の値を抽出するものである。条件並替部232は、特徴抽出部231が抽出した次元条件に対して、所定の優先順位に従って、次元別ドメイン辞書又は次元別構文辞書を並べ替えるものである。また、辞書設定部233は、条件並替部232により並べ替えられた次元別ドメイン辞書又は次元別構文辞書を意図解析用辞書22に設定するものである。
ドメイン知識管理部30は、ドメイン毎の多次元オントロジーを知識とするドメイン知識を管理するものである。ドメイン知識管理部30は、ドメイン知識マネージャ31、ドメイン知識DB32を有する。
ドメイン知識DB32には、多次元オントロジーを構築するためのベース次元及び各次元のプロパティ定義、クラス定義及び推論定義、多次元オントロジーを構成するための次元の条件、及び、次元の条件の優先度を定義する次元優先度定義テーブル、生成された多次元オントロジー、マッチングテーブルを格納するものである。
ドメイン知識マネージャ31は、対話制御部11から意図解析結果を受け取り、意図解析結果から特徴を抽出して、ドメイン知識DB32のプロパティ定義及び次元優先度定義テーブルを参照しながら、多次元オントロジーを生成するものである。ドメイン知識マネージャ31は、生成した多次元オントロジーをドメイン知識DB32に格納するものである。
また、ドメイン知識マネージャ31は、マッチングテーブルを一種のオントロジーとみなし、多次元オントロジーを利用したマッチングテーブル(以下、多次元マッチングテーブルともいう)を生成するものである。マッチング部40は、この多次元マッチングテーブルを参照しながら、マッチング処理を行う。
ドメイン知識管理部30のドメイン知識マネージャ31は、特徴抽出部311、条件照合部312、多次元オントロジー生成部313を有する。
特徴抽出部311は、ユーザ発話文の内容を解析した意図解析結果に、次元の条件となる特徴(次元条件にあたる値)がセットされているか否かを確認し、セットされている場合には、その特徴を抽出するものである。
ここで、ユーザデータ管理部51が管理するユーザデータDB53は、対話制御部11がユーザ発話から得られたユーザ情報を格納するものである。このユーザデータDB53には、ユーザ情報の格納場所(格納位置)を示すユーザデータパスと、ユーザ情報の値を示すユーザデータクラス名とを保持する。
条件照合部312は、特徴抽出部311が抽出した次元の値と次元優先度定義テーブルの内容を照合するものである。
多次元オントロジー生成部313は、次元優先度定義テーブルの優先度に従って、次元別オントロジーを基本オントロジーに重ねて、多次元オントロジー又は多次元マッチングテーブルを生成するものである。
マッチング部40は、ユーザデータ管理部51に格納されるユーザデータと、対象データ管理部50に格納される対象データとのマッチングを行い、ユーザが希望する条件のマッチングを行うものである。
マッチング部40は、対話制御部11から受け取った多次元マッチングテーブルをマッチャー42に与えたり、マッチャー42によりマッチングされた情報を対話制御部11に与えたりするマッチングマネージャ41と、ユーザデータと対象データとのマッチング処理を行うマッチャー42とを有する。
マッチング対象分析部50は、マッチング対象とするユーザデータや対象データを格納するものであり、マッチングしやすい形に拡張し、拡張したユーザデータ及び対象データを格納するものである。マッチング対象分析部50は、ユーザデータ管理部51、対象データ管理部52、拡張ユーザデータ53、拡張対象データ54を有する。
(A−3)第1の実施形態の動作
次に、第1の実施形態の対話型検索システム1における意図解析システムの動作について図面を参照しながら説明する。
(A−3−1)全体動作
まず、対話型検索システム1における全体の流れについて図面を参照しながら説明する。
図4は、対話型検索システム1の全体の流れを示すフローチャートである。
対話型検索システム1を利用するユーザは、ブラウザ90を用いて指定のURLにアクセスし、Webサーバ70を通じて対話型検索システム1を起動する。
対話型検索システム1が起動すると、対話制御部11が、ドメイン知識マネージャ31を通じて、ドメイン知識DB32に格納されるプロパティ定義を参照し、現在のポインタを定義域に持つプロパティで最も優先度が高いプロパティを選択する。
ここで、図5は、プロパティ定義の構成を示す構成図であり、図6は、プロパティ定義の一部をネットワーク形式で示した図である。
図5に示すプロパティ定義は、多次元のベースとなるプロパティ定義の例であり、例えば、「人間」を頂点として、各クラスのプロパティ関係を記述したものである。また、各プロパティが有する対話戦略やシステム発話に関するオプション情報を記述し、システムがどのような質問をどの順番でするかを規定する。
図5において、プロパティ定義は、定義域、プロパティ、値域、オプション情報の項目を有する。また、オプション情報には、必須の質問かどうかを決定する度合いを示す重要度、質問の順序(すなわち対話の流れ)を決定する度合いを示す優先度が設けられている。
さらに、オプション情報には、システム1が生成する基本質問文が定義されている。なお、図5には、オプション情報には、質問文の前に生成するつなぎ文、意図解析結果に基づき生成する各種受け止め文など、システムが円滑に対話を進行するための各種機能が定義されている。
また、オプション情報には、プロパティの種類が記述されており、例えば、グループ、取得対象がある。なお、ここではプロパティの種類を2種類の場合を例示したが、これに限定されることなく、設定することができる。
プロパティの種類が「取得対象」の場合、ドメイン知識マネージャ31は、基本質問文の項目に設定されている基本質問文を対話制御部11に与え、対話制御部11が、これをシステム発話文としてWebサーバ70を通じてユーザ側に送信する。
一方、プロパティの種類が「グループ」の場合、ドメイン知識マネージャ31は、その値域クラスを定義域に持つプロパティを探索して選択する。このとき、この値域クラスを定義域とするプロパティが複数個ある場合、ドメイン知識マネージャ31は、オプション情報の優先度を見て、最も優先度が高いプロパティを選択するようにする。そして、この選択したプロパティが「取得対象」ならば、ドメイン知識マネージャ31は、その基本質問文を対話制御部11に与えて、対話制御部11が、これをシステム発話文としてユーザ側に送信する。
このように、プロパティの種類がグループの場合に、優先度を利用することで、値域クラスを定義域に持つプロパティへの移行を実現することができる。
図6は、図5に示すプロパティ定義の一部をネットワーク形式に展開した構成図である。
図6において、丸はクラス(すなわち、図5の定義域及び値域)を示し、クラスとクラスとの間を結ぶ線はプロパティを示す。
例えば、図6おいて、「人間」を頂点とし、プロパティを「パーソナリティ」とする場合の値域は「パーソナリティ」であり、プロパティを「強み」とする場合の値域は「仕事に活かせる強み」であり、プロパティを「転職をしようと思ったきっかけ」とする場合の値域は「転職理由」であり、プロパティを「仕事の経験」とする場合の値域は「現在の仕事」である。
また、例えば、「パーソナリティ」を定義域とする場合にも、上記と同様に、例えばプロパティを「サイト訪問目的」とする場合の値域は「サイト訪問目的」である等の関係を持つ。また、「パーソナリティ」と「サイト訪問目的」等とはhas partの関係にあり、「サイト訪問目的」とユーザの回答である「適職を知りたい」とはis Aの関係にある。
システム開始時の場合、プロパティ定義では、初期値として選択する定義域が設定されている。図5の第1段目の定義域クラス「人間」に対してポインタが設定されている。
従って、ドメイン知識マネージャ31は、初期のポインタが指す定義域クラス「人間」のプロパティで最も優先度が高い「パーソナリティ」とする場合の値域クラス「パーソナリティ」を見る。
このとき、この値域クラス「パーソナリティ」のプロパティの種類は「グループ」であるから、ドメイン知識マネージャ31は、値域クラス「パーソナリティ」を定義域とするプロパティのうち、優先度が最も高い定義域クラス「パーソナリティ」−プロパティ「サイト訪問目的」−値域クラス「サイト訪問目的」のプロパティに選択する。
そして、ドメイン知識マネージャ31は、このプロパティの基本質問文である「このサイトに来た目的を教えて下さい」を対話制御部11に与えて、対話制御部11がこの基本質問文をシステム発話としてユーザ側に送信する。このようにして、システムからの質問を開始する(ステップS101)。
このシステム発話文を受信したユーザは、例えば「自分の適職が何かを知りたいので」と回答し、これを回答文としてWebサーバ70を通じて対話制御部11に送信する(ステップS102)。
対話制御部11は、ユーザ発話文を受信すると、このユーザ発話文を意図解析部20に与える。意図解析部20では、意図解析実行部21が、意図解析用辞書22を用いて、ユーザ発話文に対して、形態素解析や構文解析を行い、その結果「適職を知りたい」というユーザの意図を解析し、その意図解析結果を対話制御部11に与える(ステップS103)。
このとき、意図解析部20の意図解析結果は、ドメイン知識マネージャ31に与えられ、ドメイン知識マネージャ31により多次元オントロジーが生成され、生成された多次元オントロジーがドメイン知識DB32に記憶される。
対話制御部11は、意図解析部20からの意図解析結果を受け取ると、ドメイン知識マネージャ31に対して次の質問の問い合わせを行い、次の質問を決定する(ステップS104)。
このとき、ドメイン知識マネージャ31は、プロパティ定義を参照し、値域クラス「サイト訪問」の次に優先度が高い、定義域クラス「パーソナリティ」−プロパティ「現在の職種」−値域クラス「職種」に移行して、基本質問文「現在のあなたの職種は何ですか?」を対話制御部11に与え、対話制御部11がこれをシステム発話文として決定してユーザ側に送信する(ステップS105)。
このように、次の質問文の提示とユーザからの回答文の受信とを繰り返し行うことで、システムとユーザとの間の対話が実現される。
なお、検索処理は、対話制御処理(S104)内で処理され、ユーザからの検索要求を対話制御部11が受け取ると、検索結果が表示される(詳細は、A−3−4に記載)。
なお、ステップS104において、次の質問が決定されなかった場合、すなわち全ての質問が終了した場合、システムの動作は終了する。
(A−3−2)ドメイン知識マネージャ処理
次に、ドメイン知識マネージャ31における多次元オントロジーの作成処理の詳細について図面を参照しながら説明する。
ここでの例は、対話制御におけるドメイン知識マネージャ31の処理を説明するものであるが、本動作は、マッチングテーブルをオントロジーとみなして処理する場合も基本動作は同じである。
図7は、ドメイン知識マネージャ31における多次元オントロジーの作成処理の動作を示すフローチャートである。
ドメイン知識マネージャ31は、対話制御部11から意図解析結果を受け取る。また、ドメイン知識マネージャ31は、当該ユーザのユーザデータをユーザデータ管理部51から取得する(ステップS201)。
例えば、対話制御部11からの意図解析結果が、「/人間/パーソナリティ/現在の職種=営業」とする。
また、ユーザデータ管理部51からの当該ユーザのユーザデータが、図8に示す内容であるとする。図8に示すように、ユーザデータは、オントロジー形式で記述されている。図8の場合、当該ユーザのユーザデータとしては、プロパティ「ニックネーム」のクラスがクラス「○ちゃん」であり、同様に、プロパティ「転職活動のステージ」−クラス「履歴書送付」、プロパティ「ライフイベント」−クラス「リストラ・倒産」、プロパティ「現在の業種」−クラス「医薬品」、プロパティ「現在の職種」−クラス「営業」であるとする。
なお、ユーザデータは、説明便宜上のため、ユーザの回答から得られたプロパティに対するクラスをデータとする場合を示すが、例えば、ユーザの回答クラスから推論された新たなクラスをデータとする等、ユーザデータを拡張した内容であってよい。
ドメイン知識マネージャ31の特徴抽出部311が、ユーザデータと、ドメイン知識DB32に登録されている全ての次元の条件と照合し、条件に合う次元条件を抽出する(ステップS202)。つまり、特徴抽出部311は、ユーザデータに全ての次元の条件となる値が含まれているか否かを確認し、条件となる値がある場合には、その次元の条件となる値を抽出する。
例えば、ドメイン知識DB32に格納されている次元の条件として、「/人間/パーソナリティ/現在の職種=営業」、「/人間/パーソナリティ/現在の業種=医薬品」、「/人間/パーソナリティ/ライフイベント=リストラ・倒産&&/人間/パーソナリティ/現在の職種=営業」があるとする。
特徴抽出部311は、上記のような次元の条件とマッチングして、「/人間/パーソナリティ/現在の職種=営業」、「/人間/パーソナリティ/現在の業種=医薬品」、「/人間/パーソナリティ/ライフイベント=リストラ・倒産&&/人間/パーソナリティ/現在の職種=営業」という特徴をユーザデータから抽出する。
次に、条件照合部312は、特徴抽出部311が抽出した次元の条件となる値を、所定の優先度の高い順に並べ替え(ステップS203)、次元の条件となる値の有無を確認して、次元優先度定義テーブルに格納する(ステップS204)。
このとき、例えば、次元の条件の数が多いものを優先度が高くする。また、次元の条件の数が同じ場合には、事前に次元毎の優先度を設定しておき、この優先度に基づいて並べ替えをする。
例えば、特徴抽出部311が抽出した次元の条件の値のうち、「/人間/パーソナリティ/ライフイベント=リストラ・倒産&&/人間/パーソナリティ/現在の職種=営業」は条件数が2個であるから、最も優先度が高い。
次に、「/人間/パーソナリティ/現在の職種=営業」と「/人間/パーソナリティ/現在の業種=医薬品」とは、次元の条件の数が1個であり、同数である。
そこで、条件照合部312は、例えば、図9に示す次元リストを参照して、各次元の条件の値の優先度を確認し、この次元リストに従って各次元の条件の値をソートする。
図9の次元リストでは、上に記述されているものほど優先度が高い。例えば、「/人間/パーソナリティ/ライフイベント」は、「/人間/パーソナリティ/現在の職種」よりも優先度が高い。また、次元を表すパスが同じ場合、「/人間/パーソナリティ/現在の職種=営業」は、「/人間/パーソナリティ/現在の職種=SE」よりも優先度が高い。
従って、「/人間/パーソナリティ/現在の職種=営業」と「/人間/パーソナリティ/現在の業種=医薬品」について、条件照合部312は、「/人間/パーソナリティ/現在の職種=営業」が「/人間/パーソナリティ/現在の業種=医薬品」より優先度が高くなるように並べ替える。
その結果、図10に示すように、「/人間/パーソナリティ/ライフイベント=リストラ・倒産&&/人間/パーソナリティ/現在の職種=営業」、「/人間/パーソナリティ/現在の職種=営業」、「/人間/パーソナリティ/現在の業種=医薬品」の順にソートされる。
次に、多次元オントロジー生成部313は、次元優先度定義テーブルの優先度に従って、次元別オントロジーを基本オントロジーに重ね合わせて多次元オントロジーを生成する(ステップS205)。
図11は、多次元オントロジーの生成処理を説明する説明図である。図11(A)は、ベース次元に定義されている職種クラス及びクラスオプションを示す。図11(B)は、「業種クラス=医薬品」の次元の職種クラス及びクラスオプションの定義を示す。
多次元オントロジー生成部313は、図11(A)のベース次元に定義されている職種クラス及びクラスオプションに対して、図11(B)の「業種=医薬品」の次元の職種クラス及びクラスオプションの内容を上書きする。
このとき、図11(A)のベース次元の職種クラスでは、クラス「職種」−クラス「営業」のオプションの受け止め文が「営業のお仕事をされているんですね。」定義されているが、ステップS205の上書きにより、クラス「職種」−クラス「営業」のオプションの受け止め文が「競争の激しい業界でも営業は大変でしょう。」に書き換えされる。
このように、多次元オントロジーによれば、ベース次元に定義されるクラスオプション定義の内容を変更することができる。これにより、例えばユーザの職種などに応じて適切な受け止め文を出力することができる。
多次元オントロジー生成部313は、生成した多次元オントロジーを対話制御部11に出力する(ステップS206)。なお、この生成された多次元オントロジーは、ドメイン知識DB32に格納される。
(A−3−3)対話型検索処理における対話制御処理
次に、対話型検索処理における対話制御処理ついて、図面を参照しながら詳細に説明する。
対話型検索処理における対話制御処理を行う前提として、ドメイン知識マネージャ31は、データ提供サーバ80から取得した対象データに対して、図7で説明した多次元オントロジー作成処理を行い、対象データの意図を解析し、拡張対象データ54に格納する。
図12は、対話型検索処理における対話制御処理を示すフローチャートである。
まず、意図解析部20において、ユーザ発話文に対する意図解析が行われ、その意図解析結果が対話制御部11に与えられると(ステップS301)、対話制御部11は、意図解析結果を拡張ユーザデータ53に格納する(ステップS302)。
例えば、対話制御部11は、「/人間/パーソナリティ/現在の仕事/経験年数=5年」とする意図解析結果を拡張個人データ53に格納する。
次に、マッチング部20は、マッチング処理を起動する。具体的には、ドメイン知識マネージャ31が多次元マッチングテーブルを生成し、それを用いて、拡張ユーザデータから拡張対象データを検索し、最も検索類似度の高い対象データから順に並べ替える(ステップS303)。
このように、ユーザとの対話を通じて、ユーザから得た全ての情報と、全対象データとの間の類似度を計算し、類似度の高い対象データから順にユーザに提示する。
このとき、ユーザ側からマッチング結果の表示要求を受けた場合(ステップS304)、対話制御部11は、マッチング部40からマッチング結果を受け取り、マッチング結果をユーザ側に送信する(ステップS305)。
一方、ユーザ側からの表示要求がない場合には(ステップS304)、対話制御部11は、マッチング結果の送信を行わず、ステップS306に移行する。
ステップS306では、対話制御部11は、ドメイン知識マネージャ31から多次元オントロジーを受け取り、次の質問(プロパティ)を決定する。そして、対話制御部11は、次の質問文をユーザ側に送信して、処理を終了する(ステップS307)。
(A−3−4)多次元オントロジーを利用したマッチング処理
次に、図12のステップS303における多次元オントロジーを利用したマッチング処理の詳細な動作について図面を参照しながら説明する。
図13は、多次元オントロジーを利用したマッチング処理の動作を示すフローチャートである。ドメイン知識マネージャ31は、マッチングテーブルを一種のオントロジーとみなして、多次元マッチングテーブルを生成する処理である。
まず、マッチング部40は、ドメイン知識マネージャ31に対して、マッチングテーブルの作成要求を行い、ドメイン知識マネージャ31は、マッチングテーブルを一種のオントロジーとみなして、多次元マッチングテーブルを生成する(ステップS401)。
マッチングテーブル作成要求を受けると、ドメイン知識マネージャ31は、拡張ユーザデータ53からユーザデータを全て取得する。
ドメイン知識マネージャ31の動作フローは、図7のS204が存在しないフローで表される。ドメイン知識マネージャ31では、特徴抽出部311が、ユーザデータと全てのマッチングテーブルに登録されている全ての次元の条件とを照合し、条件に合う次元条件を抽出する(S202)。
次に、ドメイン知識マネージャ31では、条件照合部312が、特徴抽出部311により抽出された次元条件を、一定の基準に従って優先度の高いものから順に並べて、次元優先度定義テーブルに格納する(S203)。
そして、多次元オントロジー生成部313が、次元優先度定義テーブルの優先度に従って、次元別マッチングテーブルをベース次元のマッチングテーブルに重ね合わせて、多次元マッチングテーブルを生成し(S205)、マッチング部40に与える(S206)。
例えば、図14は、現在の職種がコックであるニックネーム「○ちゃん」のユーザデータ(ネットワーク形式)である。また、図15は、ベース次元のマッチングテーブルの構成例を示す。
なお、図15(A)は、ベース次元のマッチングテーブルを表形式で示したものであり、図15(B)は、ベース次元のマッチングテーブルをネットワーク形式で示したものである。
図15において、ベース次元のマッチングテーブルは、「ユーザデータ」、「重要度」、「対象データ」を項目とする。項目「ユーザデータ」は、ユーザデータにおけるプロパティ(条件)を示す。項目「対象データ」は、対象データにおけるプロパティ(条件)を示す。項目「重要度」は、マッチングにおけるプロパティに対する重み付けを示す。
図15の例においては、「ユーザデータ=現在の職種」及び「対象データ=経験職種」が対応する関係にあり、その重要度が「0.5」であることを示す。
ユーザデータと対象データとの関係でプロパティ名が異なっているが、これは、転職を募集する企業の募集要項(データ)の条件名(プロパティ名)と、これに対応するユーザから抽出する条件名(プロパティ名)とが異なるからである。
また、特徴抽出部311による特徴抽出の際に参照した次元のマッチングテーブルを図16に示す。
図16のマッチングテーブルは、「/人間/パーソナリティ/現在の職種=コック」次元のマッチングテーブルである。なお、図16(A)は表形式で示したものであり、図16(B)はネットワーク形式で示したものである。
図16に示す次元のマッチングテーブルでは、「現在の職種=コック」であるから、調理に関連する資格を所有していることが重要であるから、所有する資格の重要度が「1.0」と高く定義されている。
従って、多次元オントロジー生成部313は、図15に示すベース次元のマッチングテーブルに、図16に示す次元のマッチングテーブルを上書きする。その結果、図17に示しように、「資格の重要度」が「1.0」に変更された、多次元マッチングテーブルを生成することができる。
また別の例として、図18に示すような、現在の職種が「SE」の「△くん」のユーザデータを取得した場合を説明する。
この場合、特徴抽出部311による特徴抽出の際に参照した次元のマッチングテーブルを図19に示す。
図19のマッチングテーブルは、「/人間/パーソナリティ/現在の職種=SE」次元のマッチングテーブルである。なお、図19(A)は表形式で示したものであり、図19(B)はネットワーク形式で示したものである。
図19に示す次元のマッチングテーブルでは、「現在の職種=コック」であるから、所有する資格は重視されないが、経験年数が重視されるため、所有する資格の重要度が「0.1」と低く定義され、経験年数の重要度が「0.8」と高く定義されている。
従って、多次元オントロジー生成部313は、図15に示すベース次元のマッチングテーブルに、図19に示す次元のマッチングテーブルを上書きする。その結果、図20に示しように、資格の重要度が「0.1」、経験年数の重要度が「0.8」に変更された、多次元マッチングテーブルを生成することができる。
次に、ドメイン知識マネージャ31から多次元マッチングテーブルを受け取ったマッチング部40は、この多次元マッチングテーブルに基づいて、全ての対象データとの類似度を計算する(ステップS402)。
このとき、マッチング部40は、多次元マッチングテーブルを利用したマッチングテーブルに記述されている「重要度」によって重み付けを行って類似度を計算する。
そして、マッチング部40は、類似度の高いものから順に対象データを並べ替えて、これをマッチング結果とする。
例えば、上記の「○ちゃん」の例において、マッチング部40は、図17に示す多次元マッチングテーブルを受け取り、図21(A)の「A社」、「B社」の対象データとの類似度を計算する場合を説明する。
「A社」の条件は「経験業種=コック」、「保有資格=調理師免許」、「経験年数=1年以上」であるから、「○ちゃん」は、すべての条件にマッチする。従って、マッチング部40は、「A社」との類似度を「(1×0.5)+(1×1.0)+(1×0.5)=2.0」と計算する(図21(B)参照)。
同様に、「B社」の条件は「経験業種=コック」、「保有資格=栄養士免許」、「経験年数=5年以上」であるから、「○ちゃん」は、「保有資格」以外の条件にマッチする。従って、マッチング部40は、「B社」との類似度を「(1×0.5)+(0×1.0)+(1×0.5)=1.0」と計算する(図21(B)参照)。
従って、マッチング部40は、図21(C)のように、「A社」「B社」の順にしてマッチング結果を出力する。
また例えば、上記の「△くん」の例において、マッチング部40は、図19に示す多次元マッチングテーブルを受け取り、図22(A)の「C社」、「D社」の対象データとの類似度を計算する場合を説明する。
「C社」の条件は「経験業種=SE」、「保有資格=初級シスアド」、「経験年数=1年以上」であるから、「△くん」は、すべての条件にマッチする。従って、マッチング部40は、「A社」との類似度を「(1×0.5)+(1×0.1)+(1×0.8)=1.4」と計算する(図22(B)参照)。
同様に、「D社」の条件は「経験業種=コック」、「保有資格=上級シスアド」、「経験年数=5年以上」であるから、「△くん」は、「経験年数」以外の条件にマッチする。従って、マッチング部40は、「D社」との類似度を「(1×0.5)+(1×0.1)+(0×0.8)=0.6」と計算する(図22(B)参照)。
従って、マッチング部40は、図22(C)のように、「C社」「D社」の順にしてマッチング結果を出力する。
(A−3−5)多次元意図解析処理(ドメイン知識辞書の動的切替処理)
次に、多次元意図解析処理(ドメイン知識辞書の動的切替処理)について図面を参照しながら詳細に説明する。
図23は、多次元意図解析処理(ドメイン知識辞書の動的切替処理)に係る意図解析実行部21の処理を示すフローチャートである。また、図24は、多次元意図解析処理(ドメイン知識辞書の動的切替処理)に係るドメイン知識辞書マネージャ23の処理を示すフローチャートである。
まず、図23において、意図解析部20は、対話制御部11からユーザ発話文を受け取る(ステップS501)。
意図解析部20では、付属情報がある場合には、その付属情報をユーザデータとして拡張ユーザデータ53にセットする(ステップS502)。
またユーザ発話文が複数の文からなる場合、意図解析実行部21は、一文単位に区切り(ステップS503)、形態素解析部211がユーザ発話文に対して形態素解析を行い(ステップS504)、構文解析部212が構文解析を行う(ステップS505)。
さらに、意図解析実行部21は、意図解析用辞書22を参照して意図解析を行う。このとき、意図解析実行部21は、ユーザデータをドメイン知識辞書マネージャ23に与える(ステップS506)。
図24において、意図解析実行部21からユーザデータを受け取ると(ステップS601)、ユーザドメイン知識辞書マネージャ23は、特徴抽出部231が、ユーザデータと各次元の次元条件と照合し、次元条件に合う値を抽出する(ステップS602)。
条件並替部232は、特徴抽出部311が抽出した次元条件に対して、一定の基準に従って、次元別ドメイン知識辞書を優先順位に並べ替え(ステップS603)、辞書設定部233が、所定の優先順位で辞書引きされるように次元別ドメイン知識辞書を意図解析用辞書22にセットする(ステップS604)。
そして、図23のステップS507では、意図解析部20は、ドメイン知識辞書マネージャ23によりセッティングされた順序で次元別ドメイン知識辞書から辞書引きを行い、ユーザとの対話から得られた情報に応じた意図を生成する(ステップS507)。
例えば、図25〜図29を用いて、「○ちゃん」に対する、現住所に関する質問についてのユーザ発話文が「三田です」である場合の意図解析を例示して説明する。
まず、システム起動前に、「住所」クラスのクラス定義に従って、図28(A)〜図28(C)に示すような次元別ドメイン知識辞書を自動生成しておく。
例えば、図28(A)は、「/人間/パーソナリティ/勤め先住所=大阪」次元の「住所」クラスを定義した次元別ドメイン知識辞書であり、上位の階層を「住所」クラスとした場合、「住所」クラスの配下に「大阪」クラスがあり、「大阪」クラスの配下に「高槻市」クラス、「茨木市」クラス、…がある。また、「高槻市」クラス、「茨木市」クラス、…の異表記も併記したものである。
同様に、図28(B)は、「/人間/パーソナリティ/勤め先住所=関西」次元の「住所」クラスを定義したドメイン知識辞書であり、図28(C)は、「/人間/パーソナリティ/勤め先住所=東京」次元の「住所」クラスを定義したドメイン知識辞書である。
図26に示すユーザデータがドメイン知識辞書マネージャ23に与えられると、ドメイン知識辞書マネージャ32では、特徴抽出部231が、ユーザデータから特徴抽出を行い、プロパティ「勤め先場所」−クラス「大阪」を抽出する。
条件並替部232は、特徴抽出部231が抽出したプロパティ「勤め先場所」−クラス「大阪」を条件に合う次元別ドメイン知識辞書を選択し、所定の優先順位に従って次元別ドメイン知識辞書の並べ替えを行う。この次元別辞書の並べ替えにより、優先順位の高い次元別ドメイン知識辞書から辞書引きできるようにする。
このとき、条件並替部232は、特徴抽出部231がプロパティ「勤め先場所」−クラス「大阪」の条件に合う、図28(A)の次元別ドメイン知識辞書が一番高い優先順位とし、「大阪」クラスの上位階層のクラスである「関西」クラスのドメイン知識辞書を次に高い優先順位として並べ替える。
これにより、条件並替部232は、図27に示すように、特徴抽出部231の抽出条件から、図28(A)の「/人間/パーソナリティ/勤め先住所=大阪」次元のドメイン知識辞書、図28(B)の「/人間/パーソナリティ/勤め先住所=関西」次元のドメイン知識辞書の順に並べ替えを行う。このとき、図28(C)の「/人間/パーソナリティ/勤め先住所=関東」次元のドメイン知識辞書は、図26のユーザデータの条件に適合しないので使われない。
そして、例えばシステム発話文「おすまいはどちらですか?」に対するユーザ発話文「三田です」を意図解析部20が受け取る。
意図解析実行部21では、形態素解析部211がユーザ発話文「三田です」に対して形態素解析を行い、形態素解析結果「三田:名詞 だ:助動詞」を得て、構文解析部212が構文解析を行い、図25に示すような構文解析結果を得る。
そして、意図解析実行部21は、図27に示すように、図28(A)の「/人間/パーソナリティ/勤め先住所=大阪」次元のドメイン知識辞書を用いて解析し、次に優先順位の高い図28(B)の「/人間/パーソナリティ/勤め先住所=関西」次元のドメイン知識辞書を用いて解析する。
その結果、図28(B)の「/人間/パーソナリティ/勤め先住所=関西」次元のドメイン知識辞書を用いて、構文解析結果「住所−三田」に対応する「住所−三田市」を辞書引きして、当該ユーザの現住所が兵庫県の「三田市」であるとの意図解析結果を得て、これを出力する(図29参照)。このようにユーザから既に与えられている条件を利用することによって、三田という言葉における、兵庫県の三田市(さんだし)と東京の三田(みた)という曖昧性を解消することができる。
(A−3−6)多次元意図解析処理(解析対象文情報による動的切替処理)
次に、多次元意図解析処理(解析対象文情報による動的切替処理)について図面を参照しながら説明する。
解析対象文の動的切替処理とは、対象データから拡張対象データを構築する際の多次元意図解析処理である。
解析対象文の動的切替処理は、図23及び図24に示すフローチャートを用いてできるので、ここでは、図23及び図24を参照しながら説明する。なお、図23及び図24において、「ユーザデータ」と記載は「対象データ」となる。
図30(A)は、意図解析部20に与えられる対象データを示す。意図解析部20において、対象データには、「解析対象:対象データ」という付属情報が付される。従って、意図解析実行部21は、対象データに「解析対象:対象データ」が付与される(ステップS5001、S502)。
また、対象データは複数の文からなるので、意図解析実行部21は、対象データを1文単位に区切り(ステップS503)、対象データの各文に対して形態素解析を行い(ステップS504)、構文解析を行う(ステップS505)。
例えば、対象データの一部である「ネットワーク設計経験者優遇。」という文については、図30(B)に示すような構文解析結果を得る。つまり、「経験者待遇:名詞 設計:名詞 ネットワーク:名詞」という形態素解析結果から図30(B)のような構文解析結果となる。
意図解析実行部21は、当該ユーザデータをドメイン知識辞書マネージャ23に与える(ステップS506)。
意図解析実行部21からユーザデータを受け取ったドメイン知識辞書マネージャ23では、特徴抽出部231が、ユーザデータと、次元別のマッチングテーブルに登録されている全ての次元条件と照合し、各次元条件に合う次元条件を抽出する(ステップS601、S602)。
条件並替部232は、特徴抽出部231が抽出した次元条件に対して、一定の基準に従って、次元別ドメイン知識辞書を優先順位に並べ替え(ステップS603)、辞書設定部233が、所定の優先順位で辞書引きされるように次元別ドメイン知識辞書を意図解析用辞書22にセットする(ステップS604)。
例えば、ドメイン知識辞書マネージャ23のドメイン知識DBに、図32(A)及び図32(B)に示すような多次元構文辞書がある場合、ドメイン知識辞書マネージャ23は、特徴抽出部231の抽出条件から、一定の基準に従って、図32(A)の「/解析対象=対象データ」次元の構文辞書、図32(B)のベース次元の構文辞書の順に並べ替えを行う。
その結果、ドメイン知識辞書マネージャ23は、図31に示すように、図32(A)の「/解析対象=対象データ」次元の構文辞書を一番最初に辞書引きできるようにし、一番優先度が低い位置にベース次元の構文辞書を設定する。
そして、意図解析部20は、図32(A)の「/解析対象=対象データ」次元の構文辞書から辞書引きして、「経験職種=ネットワーク設計者」とする意図解析結果を出力する(図33参照)。
(A−3−7)マッチング結果と連動した対話制御処理
次に、マッチング結果と連動した対話制御処理について、図面を参照しながら詳細に説明する。
図34は、マッチング結果と連動した対話制御処理における対話制御部11における処理を示すフローチャートである。図35は、マッチング結果と連動した対話制御処理におけるマッチング処理を示すフローチャートである。
検索処理と連動した対話制御処理を行う前提として、ドメイン知識マネージャ31は、データ提供サーバ80から取得した対象データに対して、対象データの意図を解析し、拡張対象データ54に格納する。
図34において、対話制御部11は、意図解析部20から意図解析結果を受け取り(ステップS703)、ユーザデータとして拡張ユーザデータ53に格納し(ステップS702)、マッチング処理を起動する(ステップS703)。
例えば、ユーザ「○ちゃん」との対話によりユーザ発話文「Javaのプログラムを5年ほどやっています。」に対する意図解析結果が、「/人間/仕事の経験/内容=Java、/人間/仕事の経験/年数=5年」とする。
また、図36は、「○ちゃん」のユーザデータであるとし、対話制御部11は、図36に示すユーザデータを拡張ユーザデータ53に格納する。
マッチング部40は、拡張対象データ54に格納されるユーザデータに完全にマッチする全ての拡張対象データを取り出す(ステップS801)。
例えば、図37は、ユーザデータに完全にマッチする拡張対象データの例を示し、図37(A)は、「A社」の求人データ(対象データ)であり、プロパティ「社名」−クラス「A社」、プロパティ「使用言語」−クラス「Java」、プロパティ「経験年数」−クラス「3年以上」、…である。また、図37(B)は、「B社」の求人データ(対象データ)であり、プロパティ「社名」−クラス「B社」、プロパティ「使用言語」−クラス「Java」、…である。
マッチング部40がドメイン知識マネージャ31に対してマッチングテーブルの作成要求を行う(ステップS802)。
このとき、ドメイン知識マネージャ31は、(A−3−4)で説明した処理と同様に方法で、多次元マッチングテーブルを生成し、これをマッチング部40に与える。
ここで、図38は、マッチング部に与えられた多次元マッチングテーブルとする。
マッチング部40は、多次元マッチングテーブルに基づいて、全ての対象データに関して、ユーザデータとの類似度を計算し(ステップS803)、類似度の高いものから順に対象データを並び替える(ステップS804)。
このとき、マッチング部40は、最も高い類似度を持つ対象データに関して曖昧なマッチングがあるか否かを確認する(ステップS805)。
ここで、曖昧なマッチングとは、対象データには条件となる値が存在するが、ユーザデータには条件となる値が存在しない場合のマッチングをいう。
図39は、図38の多次元マッチンテーブルに基づいて、図36の「○ちゃん」のユーザデータと、図37(A)の「A社」の対象データとをマッチングした場合を説明する図である。
図39では、「A社」の対象データに条件する値として、「職種−プログラマ」、「使用言語−Java」、「経験年数−3年以上」がある。また、「○ちゃん」のユーザデータにも、上記の条件の値に対応する「プログラマ」、「Java」、「5年」が存在している。従って、「○ちゃん」のユーザデータには、曖昧なマッチングは存在しないと判断する。
なお、マッチング処理が終了すると、図34のステップS704に移行するが、次の質問文がセットされていないので、ステップS705〜S708の処理を行う。なお、ステップS705〜S708は、図12のステップS304〜S307に対応するので説明を省略する。
一方、ユーザ「△くん」の場合、ユーザ発話文「Java経験があります。」に対する意図解析結果が、「/人間/仕事の経験/内容=Java」であるとし、「△くん」のユーザデータは、図40に示すようものとする。
そして、図38の「/人間/現在の職種=プログラマ」次元のマッチンテーブルに基づいて、図40の「△くん」のユーザデータと、図37(A)の「A社」の対象データとをマッチングした場合を、図41に示す。
図41に示すように、上記同様、「A社」の対象データに条件する値として、「職種−プログラマ」、「使用言語−Java」、「経験年数−3年以上」がある。
しかし、「△くん」のユーザデータには、上記の条件の値に対応する「職種−プログラマ」、「使用言語−Java」は存在するが、「経験年数−3年以上」に相当する条件の値が存在しない。
そこで、マッチング部40は、プロパティ「経験年数」に関する深堀質問をセットし、これをドメイン知識マネージャ31に与える(ステップS806)。
そして、ドメイン知識マネージャ31は、プロパティ「経験年数」を次の質問文とするようにし、プロパティ「経験年数」の基本質問文「具体的な経験年数を教えて下さい。」を対話制御部11に与え、次の質問文が決定する。
この場合、ステップS704に移行し、対話制御部11には、次の質問文がセットされているので、プロパティ「経験年数」の基本質問文「具体的な経験年数を教えて下さい。」をユーザ側に出力する。
このようにすることで、「△くん」との対話処理で、「経験年数」を質問することができ、例えば「5年です。」という回答が得られた場合、「A社」の対象データとの類似度がより高くなり、「△くん」は、自分に合った会社を、より早く探すことができる。また、経験年数が「1年」であると回答を得た場合には、逆に自分が検討しても無駄な会社を、より早く候補外にすることができる。
また、もし、「A社」でなく、「B社」の場合には、経験年数を条件にしてないので、深堀質問はなされない。このように、検索結果となる対象データの状態に応じて、質問を自在に制御することができる。
(A−4)第1の実施形態の効果
以上、第1の実施形態によれば、多次元オントロジーを利用してマッチング処理を行うことにより、ユーザの意図や状況に応じて情報検索に係るマッチングの重要度を動的に変えることができるので、より的確なマッチングを行うことができる。
また、第1の実施形態によれば、意図解析を多次元化することにより、ユーザの意図や状況に応じて、適用する辞書を動的に切り替えることができるので、的確な情報検索の選択基準を選択させることができる。また、的確な選択基準を選択できるので、ユーザに対する質問やマッチングに係る検索対象も、ユーザの意図するものにすることができる。
さらに、第1の実施形態によれば、対象データに関する情報によって、適用する辞書を動的に切り替えることができるので、的確な情報検索の選択基準を選択させることができる。
また、第1の実施形態によれば、マッチング結果に連動させて対話制御を行うことで、対象データとのマッチングに必要な情報を次の質問文としてユーザに提示することができるので、より迅速かつ的確なマッチング処理を提供できる。
(B)他の実施形態
(B−1)意図解析の多次元化とは、ユーザから取得された値によって、解析エンジン(解析時に利用する辞書)を動的に使い分けることを意味する。解析エンジンを動的に使い分ける仕組みは、対話制御がドメイン知識マネージャを通じて、オントロジーを動的に使い分ける仕組みを応用することで実現可能である。
(B−2)意図解析を多次元化することにより、以下のようなことができる。
(1)関西を希望している人が、「三田がいい」と発言したら「三田市」と返すことができる。また、関東を希望している人は、「東京の三田」を返すことができる。
(2)口語で入力する人には、口語解析用エンジン、関西弁の人には、関西弁エンジンを使うことで、それぞれの解析精度が向上する。
(3)プロデューサを希望する人とプログラマを希望する人では、「プログラムを作る」の意味が違うことが理解できるようになる。
(4)正社員を希望する人は年収(又は月収)、パートの人は時給を給与のデフォルトにして解析することができる。
(5)求人データ、ユーザ発話文の解析時には、それぞれ別の解析エンジンを使うことで、解析精度が向上する
(6)求人データは、通常、情報がタグ付けされている。そのタグの値毎に、辞書を使い分けることにより、精度高く解析できる。例えば、求人職種タグの場合は、「職種」の入力を前提とした辞書で解析する。「先輩PR」タグの場合は、社員が述べるような内容の入力を前提とした辞書で解析する。
(B−3)検索の多次元化とは、ユーザから取得した値によって、検索の条件を動的に使い分けることを意味する。
例えば、意図解析がなくても(例えば、アンケートのようにユーザからの回答が決まっているため、意図解析する必要ながなくても)同様の処理は勿論可能である。
また、提示要求は、検索後であるとは限らず、いつでも検索しても良い。
さらに、第1の実施形態では、マッチング手法は、単純な例を示したが、マッチング手法は、種々の方法を広く適用することができる。例えば、完全マッチングであっても良いし、第1の実施形態のようにマッチングするものを順に並べるというものであっても良い。
また、マッチングテーブルをいくつも用意して、全てのマッチングテーブルに関して計算を予め行っておいて、ユーザが指定する条件の結果のみを表示するという応用も可能である。
(B−4)対話と検索の連動とは、「ユーザから取得された値によって検索し、その検索結果によって、さらに必要な情報をユーザに質問する」のように、検索結果によって、対話内容が動的に変化するような仕組みを意味する。
対話と検索の連動において、オントロジー、検索、意図解析の多次元化の仕組みを導入するようにしてもよい。