JP5138046B2 - 検索システム、検索方法およびプログラム - Google Patents

Description

本発明は、検索結果のうち、どの文書が重複した内容で検索されたかを検知可能にした検索システム、その検索方法およびその方法を実現するためのコンピュータ可読なプログラムに関する。

インターネット等のネットワークに接続されたデータベースに格納されている文書を検索するためのシステムとして、検索エンジンがある。この検索エンジンには、複数の文書から特定の文字列を検索する全文検索機能を備えるものがある。

全文検索機能を備える全文検索エンジンは、複数の文書の内容を順次走査し、検索対象となる文字列を探索する逐次検索型と、検索対象となる文書数が膨大で、逐次検索では検索時間がかかることから、事前に、文字列、その文書の場所、更新日、出現頻度といったデータからなるテーブル構造のインデックスを作成しておき、検索時にはこのインデックスにアクセスすることで、高速に検索を可能にした索引型とがある。

索引型で使用されるインデックスには、様々な形式があり、一般的なものとしては、単語と、その単語を含む文書ファイルＩＤとで構成された可変長のレコードをもつ転置インデックスと呼ばれるものがある。

ここで、３つの文書と、それらに対する転置インデックスと、収集された文書を保管するデータ構造の例を、図１および２に示す。図１（ａ）〜（ｃ）に示す文書は、順に、文書ファイルＩＤが１〜３とされ、いずれも電子メールとされている。図２（ａ）に示す転置インデックスは、キーとなる単語と、その単語を含むＩＤとで構成され、この図２（ａ）では「ＰＨＰ」、「鈴木」、「コード」という単語を含む文書が対応付けられている。図２（ｂ）に示す収集された文書を保管するデータ構造のエントリ例では、キーとなる単語と、その単語に対応する文書の内容とが対応付けられ、この図２（ｂ）では、単語が左欄に配列され、選択された単語に対応する文書内容が右欄に表示されている。

全文検索エンジンでは、検索語と一致した単語が出現する文書群が検索結果として返される。このように文書全体の類似性を判定する技術として、例えば、特許文献１〜３に記載された技術がある。

これらの技術では、検索語と一致した単語が文書中のどのような文字列の中で出現したかは考慮されない。これでは、検索結果の中に文書が大量に存在する場合、その検索結果の中から真に必要となる文書を見つけ出すのは難しく、労力がかかる。例えば、検索語が文書のテンプレートに存在すると、そのテンプレートを使用している文書が全て返されてしまい、本来の目的となる検索語を本文中にもつ文書を検索結果から探し出す労力が必要となる。なお、テンプレートは、文書のヘッダやフッタ、Ｗｅｂサイトのメニュー、電子メールのシグニチャー等である。

電子メールでは、返信・転送する際、オリジナルのメールを末尾に追加することが多いが、その追加したメールに検索語が含まれていると、返信・転送するメールの本文中にその検索語が出現しなくても、検索結果として返される。このため、検索語を本文の話題としているメールを探したい場合にはノイズとなってしまう。

したがって、検索語が本文の同一の文字列中に出現する文書を１つのグループにまとめることができれば、評価すべき文書数が少なくなるので、真に必要となる文書を見つけやすくなる。

例えば、検索時に検索結果の文書それぞれについて、検索キーワードが含まれる文字列を作成し、比較することで、検索語の出現位置を考慮して、内容が重複する文書を検出する技術が提案されている（特許文献４参照）。

特許文献４に記載されている検索エンジンの構成を、図３に示す。この検索エンジン１０は、検索対象となる文書を保持するデータソース２０と接続され、また、ユーザが検索結果を得るために入力した問合せ（クエリ）を出力するクライアント装置３０と接続されている。

検索エンジン１０は、検索エンジン１０自身がもつデータベース１１に文書を登録し、インデックスを作成するためにデータソース２０上の文書を周期的に取得するクローラー１２を備える。このクローラー１２は、インデックス作成に用いられる文書のコピーを要求し、その文書中に含まれるリンクをたどり、別の文書を収集するという動作を繰り返す。また、クローラー１２は、新しい文書を見つけた場合は、データベース１１に登録し、文書が存在しないことを検出した場合は、データベース１１からその文書を削除する。

検索エンジン１０は、クローラー１２が取得し、データベース１１に登録された文書からテキストを抽出し、段落等のフォーマット情報を抽出するパーサー１３を備える。パーサー１３は、構文解析を行うもので、構文解析され抽出されたテキストやフォーマット情報を、ストア１４と呼ばれる収集された文書を保管するデータ構造へ入力する。

検索エンジン１０は、パーサー１３により抽出されたテキストやフォーマット情報からインデックスを作成するインデクサー１５を備える。インデクサー１５は、上述したように、キーとなる単語とその単語を含む文書のＩＤとを対応付けて索引１６に保管する。

検索エンジン１０は、さらに、クライアント装置３０から受信したクエリに応答して、クエリに含まれる検索語をキーとして、その検索語を含む文書を検索する検索サーバとしてのサーチ・ランタイム１７と、サーチ・ランタイム１７から検索結果を受け取り、その検索語を含む文書をストア１４から取得し、その検索語を含む文字列を生成するクエリ関連情報作成装置１８と、生成された文字列を検索結果の文書と比較するクエリ関連情報比較装置１９とを備える。

この検索エンジン１０では、検索毎、検索結果毎に、クエリ関連情報作成装置１８により検索語を含む文字列を生成し、クエリ関連情報比較装置１９によりその文字列を比較することで、文章全体が一致したものや、サンプリングされた文書の数箇所が一致したものを、関連する文書として検出する。

米国特許第６２３０１５５号公報 米国特許第６６５８４２３号公報 米国特許第６９７８４１９号公報 米国特許第６６１５２０９号公報

従来の検索エンジンでは、同じ内容であるが、異なる文書として存在する場合、個々の検索結果として取り扱われるため、こういった同じ内容あるいは似通った内容の文書を前もって、文書収集時やインデックス作成時に除外することができる。しかしながら、従来の検索エンジンは、文章全体または文書の数箇所が同じ内容または似通った内容の文書を判断することができるだけで、部分的な同一性をもって同じ内容または似通った内容の文書とは判断することはできない。

また、従来の検索エンジンでは、Ｗｅｂサイトのメニューに検索語が出現する場合、そのメニューをもつページが全て返されるが、文書の特徴とならなさそうな単語や文字列を前もって指定することで、除外することができる。しかしながら、その指定をするためには、除外する単語や文字列を前もって知っていなければならない。

さらに、従来の検索エンジンでは、文書間の関連性が考慮されずに検索結果が返されるため、ユーザが、返された検索結果の文書全部につき、文書を１つずつ順に、真に必要な文書か否かを判断しなければならない。

本発明は、上記課題に鑑み、文書を構成するテキストを複数のブロックに分け、検索語が含まれるブロックに着目し、検索結果の文書のうち、そのブロックの内容が同じ文書同士をグループ化することで、部分的な同一性をもって同じ内容あるいは似通った内容の文書と判断することを可能にし、文書間の関連性を考慮した検索結果を返すことを可能にする。

具体的には、インデックス作成時に、検索対象となる文書中のテキストを複数のブロックに分割する。ブロックは、センテンス（文）、パラグラフ（段落）等とすることができる。このようにして得られたブロック毎にハッシュ値を計算する。ハッシュ値は、文字列に対応する数値である。このハッシュ値を、文書中のブロックの位置情報とともに、その文書に関連付けて保持する。

そして、検索実行時に、検索結果の各文書について、検索語が出現する位置情報を基に、対応するハッシュ値を取り出し、そのハッシュ値が一致する文書同士をグループ化して出力する。

これを実現するために、本発明では、検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割する分割部と、各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算する計算部と、得られたハッシュ値を文書におけるブロックの位置情報とともに記憶する記憶部と、検索語に基づき検索されて得られた各文書につき、検索語を含むブロックの位置情報を基に対応するハッシュ値を記憶部から取り出し、ハッシュ値が一致する文書をグループ化して、検索結果として出力する文書グループ化部とを備える、検索システムが提供される。

分割部は、分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する。付加情報としては、ＨＴＭＬ文書におけるＨＴＭＬタグを挙げることができる。分割部は、１つに限らず、複数の分割情報を使用して分割することができ、例えば、特定の検索語が使用された場合にはパラグラフ毎の分割情報を使用し、それ以外の検索語が使用された場合にはセンテンス毎の分割情報を使用することができる。また、このように複数の分割情報を使用できるようにすることで、ユーザやシステムがセンテンス毎の分割によるグループ化が適当でないと判断した場合、センテンス毎以外の、例えばパラグラフ毎の分割情報を使用してグループ化することが可能となる。

文書は、複数の単語（トークン）が順に配列するトークン列とされ、各ブロックに含まれる文字列は、少なくとも１つのトークンから構成される。このため、各ブロックの位置は、トークン数により表すことができ、その位置情報には、文書の先頭トークンから各ブロックの先頭トークンまでのトークンの順番を含むことができる。位置情報は、文書の先頭トークンから各ブロックの末尾トークンまでのトークンの順番を含むこともでき、それら２つのトークン数を、そのブロックを構成するトークン列の先頭から末尾までの範囲とすることができる。

また、各ブロックの位置は、文字数により表すこともでき、この場合、位置情報には、文書の先頭文字から各ブロックに含まれる文字列の先頭文字までの文字数が含まれる。位置情報は、文書の先頭文字から各ブロックの末尾文字までの文字数を含むこともでき、それら２つの文字数を、そのブロックを構成する文字列の先頭から末尾までの範囲とすることができる。

計算部は、ブロックに含まれる文字列において、指定された文字種を含む場合、その文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する。電子メールでは、受信内容を引用する場合に記号「>」が追加されるが、この記号「>」を除いた文字列からハッシュ値を計算することで、同じハッシュ値をもつ文書としてグループ化することが可能となる。

文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む。これにより、グループに含まれる複数の文書は、検索スコア順に並べられる。

本発明では、上記検索システムが行う検索方法を提供することもできる。この方法は、分割部、計算部、記憶部、文書グループ化部の各部が実行する処理ステップを含む。

この検索方法は、プログラムとして構成し、プログラムを実行させることにより実現することもできる。このプログラムは、記録媒体に格納して提供することができる。

本発明の検索システム、検索方法、プログラムおよび記録媒体を提供することにより、検索結果の中から真に必要な文書が見つけやすくなり、その必要文書を探索する労力を軽減し、探索時間を短縮することが可能となる。

検索対象となる３つの文書を例示した図。 図１に示す文書に対する転置インデックスと、収集された文書を保管するデータ構造の例を示した図。 従来の検索エンジンの構成例を示した図。 検索対象となる文書を保持するデータソースと、検索要求を行うクライアント装置と、検索要求を受けて検索処理を行う検索エンジンを備えるサーバ装置とから構成されるネットワーク・システムを例示した図。 サーバ装置のハードウェア構成の一例を示した図。 サーバ装置を検索システムとして構成した場合の機能ブロック図。 検索対象となる３つの文書を例示した図。 分割された各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算したところを示した図。 グループ化された文書を検索結果として表示した図。 電子メールの４つの例、それらをブロックに分けたところ、ハッシュ値と位置情報とを対応付けて表したところを示した図。 グループ化した検索結果の一例を示した図。

以下、本発明を図面に示した具体的な実施の形態に沿って説明するが、本発明は、後述する実施の形態に限定されるものではない。

図４は、検索対象となる文書を保持するデータソースと、検索要求を行うクライアント装置と、検索要求を受けて検索処理を行う検索エンジンを備えるサーバ装置とから構成されるネットワーク・システムを例示した図である。ここでは、データソース１００、クライアント装置２００、サーバ装置３００がそれぞれ１つずつしか示されていないが、２つ以上がネットワーク４００に接続されていてもよい。また、データソース１００とサーバ装置３００は、直接接続されていてもよい。

データソース１００は、文書を保持する装置であればいかなる装置であってもよく、項目毎にデータを集めて管理するデータベースや他のサーバ装置とすることができる。データソース１００は、文書を保持する、他のユーザが使用するＰＣ等であってもよい。

データソース１００がデータベースである場合、そのデータベースとしては、複数の関係（リレーション）を基本的なデータ型とし、格納されたデータを取得するための問合せが、等号や不等号等の関係演算子や、論理積や論理和や否定等の論理演算子を用いて行われるリレーショナル・データベースを用いることができる。なお、データベースは、オペレーティング・システム（OS）が提供するファイル・システム上に直接構築されたものでも、データベース管理システム（DBMS）を用いて構築されたものであってもよい。

クライアント装置２００は、検索要求を出力することができるものであればいかなる装置であってもよく、ユーザが入力した検索語について検索要求を生成し、ネットワークを介した問合せを可能にするアプリケーションを備えるＰＣとすることができる。このＰＣは、ユーザが検索語を入力するためのキーボード、入力位置を指定し、検索開始の指示を与えるマウス、入力画面や検索結果を表示する表示装置、ネットワークに接続するためのネットワークＩ／Ｆ、アプリケーションを記憶するＨＤＤ、それらが実行のために読み出されるＲＡＭ、それらを実行するＣＰＵ等を備える。また、アプリケーションのほか、ネットワークを介した通信を可能にするために、Ｗｅｂブラウザを用いることができる。

サーバ装置３００も、クライアント装置２００と同様のハードウェア構成とすることができるが、Ｗｅｂブラウザと通信を行うためにＷｅｂサーバと、クライアント装置２００から受信した検索要求を処理するための検索エンジンとを備える。

サーバ装置３００は、上述したクライアント装置２００と同様のハードウェア構成とすることができるが、図５を参照して、サーバ装置３００のハードウェア構成の一例について簡単に説明する。図５に示すハードウェア構成では、メモリ３１０と、少なくとも１つのプロセッサ３２０と、メモリ制御部３３０と、チャネル・サブシステム３４０と、少なくとも１つの制御装置３５０と、少なくとも１つの入出力デバイス３６０とを備えている。

メモリ３１０は、入出力デバイス３６０から入力されたデータやプログラムを格納し、プロセッサ３２０およびチャネル・サブシステム３４０からのアドレス指定に応答して、そのアドレスに格納しているデータ等をプロセッサ３２０およびチャネル・サブシステム３４０へ送る。

プロセッサ３２０は、装置全体を制御し、少なくとも１つのOSを実行する。OSは、装置におけるプログラムの実行や入出力処理を制御する。メモリ制御部３３０は、バスを経由してメモリ３１０、プロセッサ３２０、チャネル・サブシステム３４０のそれぞれに接続される。このメモリ制御部３３０は、プロセッサ３２０やチャネル・サブシステム３４０が出したリクエストを一時的にキューに格納し、所定のタイミングでメモリ３１０へ送る。

チャネル・サブシステム３４０は、各制御装置３５０へ接続され、プロセッサ３２０の処理負荷を軽減するために、入出力デバイス３６０とメモリ３１０との間のデータ転送を制御する。これにより、プロセッサ３２０による演算処理と、入出力デバイス３６０による入出力処理とを並列に実行させることができ、処理効率を向上させることができる。

制御装置３５０は、入出力デバイス３６０のデータ転送のタイミング等を制御する。入出力デバイス３６０は、制御装置３５０、チャネル・サブシステム３４０、メモリ制御部３３０を経由し、メモリ３１０との間でデータ転送を行う。入出力デバイス３６０としては、HDD、ディスプレイ、キーボード、プリンタ、通信デバイス、他の記憶装置を挙げることができ、入出力デバイス３６０の１つには、データソース１００が直接に、またはネットワーク４００を介して接続される。

サーバ装置３００による検索処理を実現するために、プログラムが記録された記録媒体が提供され、その記録媒体が入出力デバイス３６０の１つに接続され、そのプログラムが、制御装置３５０、チャネル・サブシステム３４０、メモリ制御部３３０を経由して、メモリ３１０へ送られ、メモリ３１０に格納される。格納されたプログラムは、再度それらを経由して入出力デバイス３６０に接続されたHDDへインストールされ、適宜プロセッサ３２０により読み出され、実行される。

プログラムが格納される記録媒体としては、フレキシブル・ディスク、CD-ROM、DVD、SDカード、フラッシュメモリ等を挙げることができる。このプログラムは、検索処理を実行し、検索結果を出力する処理を実現するプログラムを含む。このプログラムは、同じHDDにインストールされ、適宜プロセッサ３２０が読み出し、実行することにより検索エンジンとして機能する。

図６は、サーバ装置３００を検索システムとして構成した場合の機能ブロック図である。この検索システムは、図３に示した従来の検索エンジンと同様、文書を周期的に取得する取得部としてのクローラー５００、取得した文書を格納する格納部としてのデータベース５０５、文書からテキストを抽出し、段落等のフォーマット情報を抽出する抽出部としてのパーサー５１０、抽出したテキストおよびフォーマット情報を蓄積する蓄積部としてのストア５１５、テキストやフォーマット情報からインデックスを作成する作成部としてのインデクサー５２０、作成したインデックスを保管する保管部としての索引５２５、クライアント装置２００から受信した検索要求に応答して、その検索要求に含まれる検索語をキーとして、その検索語を含む文書を検索する検索部としてのサーチ・ランタイム５３０を含む。

図３に示した従来の検索エンジンでは、クエリ関連情報作成装置１８、クエリ関連情報比較装置１９を含んでいたが、図６に示す検索システムでは、分割部５３５、計算部５４０、記憶部５４５、文書グループ化部５５０を含む。

クローラー５００、データベース５０５、パーサー５１０、ストア５１５、インデクサー５２０、索引５２５、サーチ・ランタイム５３０の各機能については、既に述べたので、ここでは、分割部５３５、計算部５４０、記憶部５４５、文書グループ化部５５０について詳述する。

分割部５３５は、パーサー５１０により抽出されたテキストやフォーマット情報を受け取り、ユーザにより指定された分割情報に基づき、テキストを複数のブロックに分割する。分割情報は、テキストをどのように分割するかを示す情報で、センテンス毎、パラグラフ毎、空行、文書に付加された付加情報の少なくとも１つを選択することができる。センテンス毎を選択した場合は、テキストは、センテンス毎に分割される。複数の分割情報を選択して使用することもでき、例えば、特定の検索語が使用された場合は、パラグラフ毎の分割情報を使用し、その特定の検索語以外が使用された場合は、センテンス毎の分割情報を使用することができる。また、複数の分割情報を設定しておき、それらを使用して分割することができるようにすることで、ユーザやシステムがセンテンス毎の分割によるグループ化が適当ではないと判断した場合、パラグラフ毎の分割情報を使用してグループ化することできる。このように、複数の基準で分割できるようにすることで、検索時にグループ化の粒度を調整することができ、有用である。ここで、付加情報としては、ＨＴＭＬ文書におけるＨＴＭＬタグを挙げることができる。なお、この分割は、インデックス作成時に行われる。

計算部５４０は、各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算する。ハッシュ関数は、データからある一定範囲の数値を生成する関数で、ハッシュ関数を適用して得られるハッシュ値は、それぞれの文字列に対応する数値である。ハッシュ値は、Ｊａｖａ（登録商標）言語の標準的なメソッド、例えばhashCode()等を使用して算出することができる。なお、hashCode()は、ハッシュ値を返すメソッドである。

ハッシュ関数の１つの例としては、文字列の１文字毎に割り当てられた文字コード、例えば数値を加算して求める関数を挙げることができる。この場合の文字コードとしては、ＡＳＣＩＩ文字コードを挙げることができる。上記例は一例であるので、ハッシュ値を求めるために、これまでに知られたいかなる計算式やアルゴリズムでも用いることができる。

記憶部５４５は、計算部５４０が計算して得たハッシュ値を、文書におけるブロックの位置情報とともに記憶する。ブロックの位置情報については下記に詳述する。

文書グループ化部５５０は、検索語に基づき検索されて得られた各文書につき、検索語を含むブロックの位置情報を基に、対応するハッシュ値を記憶部５４５から取り出す。そして、文書グループ化部５５０は、ハッシュ値が一致する文書をグループ化して、検索結果として出力する。出力された検索結果は、サーチ・ランタイム５３０へ送られ、サーチ・ランタイム５３０がクライアント装置２００へ返す。クライアント装置２００では、Ｗｅｂブラウザが検索結果を受信すると、表示装置へその検索結果を表示させる。

これらの詳細な処理を、図７〜図１１を参照して説明する。図７（ａ）〜（ｃ）は、文書例として、３つの電子メールが示されている。これらの電子メールはいずれも、本文と署名等からなるシグニチャーとから構成され、本文とシグニチャーとの間には空行がある。ここでは、分割情報として「空行」が指定されており、分割部５３５は、インデックス作成時に、この指定された「空行」という分割情報に基づき、電子メールを、空行で、本文とシグニチャーとの２つに分割する。具体的には、分割部５３５は、クローラー５００が周期的に文書を取得し、パーサー５１０が構文解析した後、構文解析された文書を、複数のブロックに分割する。

図８は、分割された各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算したところを示した図である。ブロックに含まれる文字列は、パーサー５１０によりトークン（分かち書きされた単語）列とされている。ここで、分かち書きとは、日本語の文章において語の区切りに空白を挟んで記述することをいう。図８（ａ）では、本文の「ＰＨＰのソースコードを添付します。よろしくお願いします。」と、シグニチャーの「------ 鈴木 Example Corp Japan XXX@example.co.jp」との間に空行があり、この空行によって２つのトークン列に分割されている。

計算部５４０は、各トークン列にハッシュ関数を適用し、対応する数値であるハッシュ値を計算する。上記の例でいうと、「ＰＨＰのソースコードを添付します。よろしくお願いします。」から計算により「1234567890」を、「------ 鈴木 Example Corp Japan XXX@example.co.jp」から計算により「0987654321」を算出する。ここでは、１０桁の数値としてハッシュ値を算出しているが、１０桁に限られるものではなく、いかなる桁の数値であってもよい。

文書中の文字は、行方向に、左から右へと配列し、その行が終了すると、その下の行に、左から右へと配列している。このことから、文書中のトークンは、左上隅にあるトークンを先頭に、右下隅にあるトークンまで順に並んでいる。位置情報としては、文書中の先頭トークンから各ブロックに含まれる文字列の先頭トークンまでのトークンの順番を含むことができる。ブロックの位置は、例えば、この順番と、文書中の先頭トークンから各ブロックに含まれる文字列の末尾トークンまでのトークンの順番とを用いて範囲で表すことができ、位置情報としては、その範囲を採用することもできる。

上記の例の「ＰＨＰのソースコードを添付します。よろしくお願いします。」では、「ＰＨＰ」、「の」、「ソースコード」、「を」、「添付」、「し」、「ます」、「。」、「よろしく」、「お願い」、「し」、「ます」、「。」という１３のトークンから構成され、「ＰＨＰ」は最初のトークンであるから０トークンであり、最後の「。」は１３トークン目であるから、その位置情報は「０トークン〜１２トークン」とすることができる。図８（ａ）では、これらを「＠」という記号を使用して結合し、「1234567890＠０トークン〜１２トークン」、「0987654321＠１３トークン〜２４トークン」で表されている。これらの情報は、記憶部５４５に記憶される。

上記例では、位置情報に、文書中の先頭トークンから各ブロックの先頭トークンまでのトークン数を、各ブロックの先頭トークンまでのトークンの順番として用いた。ところが、実際にパーサー５１０では、同じ単語から複数のトークンが生成される場合がある。例えば、活用形でも検索を行うことができるように、５つの単語しかないのに、６つのトークンが生成されることがある。その一方、検索システムは、何番目のトークンでヒットしたという情報を返すので、上記のようにトークン数から計算した位置情報では、取り出すブロックがずれてしまうことがある。

この場合について「ＰＨＰのソースコードを添付します。よろしくお願いします。」という文を、センテンス毎にブロックに分け、その位置情報を計算する場合について説明する。パーサー５１０では、先頭から順に、「ＰＨＰ」、「の」、「ソースコード」、「を」、「添付」、「し」、「ます」、「ました」、「。」、「よろしく」、「お願い」、「し」、「ます」、「ました」、「。」という１５のトークンを生成したとする。ここで、２つの「ました」は、活用形として生成されたものであり、実際の文には含まれないものである。分割部５３５は、この文をセンテンス毎に分ける場合、「ＰＨＰのソースコードを添付します。」と「よろしくお願いします。」という２つのブロックに分ける。

計算部５４０は、ハッシュ値を計算するとともに位置情報を計算すると、パーサー５１０から得られた先頭トークンからのトークン数として「ます」を７番目、１３番目、「ました」を８番目、１４番目と計算するのではなく、実際に文に含まれない「ました」についてはその直前にある「ます」とトークンが重複する形で配列に並び、「ます」と「ました」の両方を７番目、１２番目のトークンとして計算する。

そして、計算部５４０は、「ＰＨＰのソースコードを添付します。」というブロックに対しては、そのブロックの先頭トークンまでの順番と末尾トークンまでの順番とを使用して「ハッシュ値＠０−７」、「よろしくお願いします。」というブロックに対しても、同様の順番を使用して「ハッシュ値＠８−１２」を求め、それらを記憶部５４５に記憶する。

算出されるハッシュ値は、同じトークンの並びであれば必ず同じものになり、１つのトークンでも異なると、異なったハッシュ値になる。図８（ａ）、（ｂ）を参照してみると、本文は、一部のトークンが異なっているため、ハッシュ値が「1234567890」と「2345678901」のように異なった値となっており、その一方で、シグニチャーは、いずれのトークンも同じであるため、「0987654321」で同じハッシュ値となっている。図８（ｃ）は、図８（ａ）、（ｂ）の本文、シグニチャーのいずれも、少なくとも一部のトークンが異なっているため、ハッシュ値が異なった値となっている。

特定の文字種である記号からなるトークンについては、ハッシュ値の計算を行わないようにすることができる。このようにすることで、「こんにちは」という文字列と「>こんにちは」という文字列は、記号「>」の部分が異なるのみで、文字列「こんにちは」の部分が同じであるため、同じハッシュ値を算出することができる。この記号「>」は、電子メールの内容が引用された場合に追加されるものである。したがって、受信した電子メールの内容が引用されて記号「>」が追加されていたとしても、その他のトークンの並びが同じであれば、同じハッシュ値となる。これは、電子メールを検索する場合に有用である。これまでの処理は、インデックス作成時に行われる。なお、ハッシュ値の計算時に除かれる文字種としては、電子メールにおいて内容が引用された場合に追加される「>」や「>>」に限られるものではなく、ユーザが予め指定しておくことにより、その文字種を除いて計算することができる。

クライアント装置２００が検索要求を出力すると、サーチ・ランタイム５３０は、検索要求に含まれる検索語を基に、インデクサー５２０が作成したインデックスを索引５２５の中から検索し、検索して得られた文書のテキストやフォーマット情報をストア５１５から取得する。サーチ・ランタイム５３０は、これらの情報を文書グループ化部５５０へ渡す。

文書グループ化部５５０は、検索結果の文書毎にヒットしたトークンが含まれていたブロックのハッシュ値を、検索語を含むブロックの位置情報を基に記憶部５４５から取り出し、同一のハッシュ値をもつ文書を１つのグループとしてグループ化する。

サーチ・ランタイム５３０は、入力された検索語に基づき検索を実行した場合、何番目のトークンでヒットしたという結果を返すが、計算部５４０がトークン列のトークンの順番を位置情報として計算し、記憶部５４５に記憶しているので、文書グループ化部５５０は、サーチ・ランタイム５３０から返されたトークンの順番に基づきハッシュ値を取り出すことで、適切なハッシュ値を取り出すことができる。

複数のトークン列を含む文書は、分割部５３５により、複数のブロックに分割され、計算部５４０により、各ブロックに含まれるトークン列から各ハッシュ値が計算され、各々が記憶部５４５に記憶されるが、２以上のブロックに検索語が含まれる場合、それら２以上のブロックに含まれるトークン列から計算されたハッシュ値を合計したものを、その文書のハッシュ値として計算し、記憶することができる。

ユーザがクライアント装置２００において「鈴木」という検索語を入力し、検索要求を出力した場合、サーチ・ランタイム５３０は、索引５２５を検索し、図８（ａ）〜（ｃ）に示す３つの文書を検索結果として得る。図８（ａ）〜（ｃ）に示す文書を順に、文書１〜３として参照すると、文書１では、検索語「鈴木」が１５トークン目にあり、そのトークンを含むブロックのハッシュ値は、「0987654321」である。文書２では、検索語「鈴木」が１７トークン目にあり、そのトークンを含むブロックのハッシュ値は、「0987654321」で、上記文書１と同じである。このため、文書１と文書２は、同じグループとしてグループ化される。

文書３では、検索語「鈴木」が１トークン目にあり、そのトークンを含むブロックのハッシュ値は、「3456789012」で、文書１および文書２とは異なる。このため、文書３は、文書１や文書２とは別のグループとしてグループ化される。

グループ化された文書を検索結果として表示する場合、その文書があるグループに含まれていることが判断できればいかなる表示であってもよく、例えば、図９（ｂ）に示すような表示とすることができる。この図９（ｂ）に示す検索結果は、同じグループにグループ化された文書は、１番目の文書は、通常通り表示されるが、２番目以降は、右にインデントされ、その先頭に縦棒が表示されている。このようにすることで、ユーザは、検索結果の文書間の関連性を一見して判断することができる。なお、グループ化された文書の表示は、上記の縦棒およびインデントに限られるものではなく、字体を変える、識別記号を付する等により識別することができる。

グループ化された文書の配列は、検索スコアを基に行うことができる。検索スコアは、検索語が出現する文書数と全文書数とから、全文書中のどの程度の文書に検索語が出現するかを表す値を求め、その値と検索語の出現回数とを乗じて得られる値とすることができる。このため、出現回数が多い文書ほど高スコアとなり、出現回数が少ない文書ほど低スコアとなる。

図９（ａ）には、図９（ｂ）との比較のために、グループ化をしない従来の単に検索語「鈴木」に基づいてサーチ・ランタイム５３０により検索を行った結果を表示している。図９（ａ）に示す検索結果では、ユーザは、それぞれの検索結果を評価する必要があるが、図９（ｂ）に示す検索結果では、ユーザは、どの結果が重複しているかを一見して判断することができるので、そのうちの１つを評価すればよく、必要な文書を容易に探し出すことが可能となる。

これまで説明してきた実施形態では、ブロックの位置情報をトークンの順番により表してきた。しかしながら、位置情報は、トークンの順番で表すものに限らず、配列する文字の順番によって表すこともできる。図１０（ａ）〜（ｄ）は、電子メールの４つの例、それらをブロックに分けたところ、ハッシュ値と位置情報とを対応付けて表したところを示した図である。

図１０に示す実施形態も、分割部５３５により、空行で、各ブロックに分割されている。図１０（ａ）および（ｂ）に示す文書１および文書２では、本文とシグニチャーの２つに、図１０（ｃ）および（ｄ）に示す文書３および文書４では、引用された文章およびシグニチャーに記号「>」や「>>」が追加され、複数の本文とシグニチャーの４および６つに分割されている。

計算部５４０は、各ブロックに含まれる文字列からハッシュ値を計算し、文書の先頭文字からその文字列の先頭文字までの文字数と、文書の先頭文字からその文字列の末尾文字までの文字数とを使用して表される範囲を位置情報として用い、その位置情報とハッシュ値と対応付けて記憶部５４５に記憶する。図１０（ａ）に示す文書でいえば、本文の「db2jcc.jarを明日、チェックインします。」と、シグニチャーの「---- 田中」とに分割され、本文に対し「11111111」が算出され、シグニチャーに対し「22222222」が算出されている。この本文は、それ以前に文字が存在しないため、１文字目から開始し、文字数が２４文字であることから、位置情報は「１〜２４」とされ、シグニチャーが２５文字目から開始し、文字数が６文字であることから、位置情報は「２５〜３０」とされている。

クライアント装置２００からの検索要求を受けて、サーチ・ランタイム５３０が索引５２５の中から文書を検索する。ここでは、検索語として「db2jcc.jar」が入力されている。サーチ・ランタイム５３０は、この「db2jcc.jar」を含む文書を検索し、検索結果を文書グループ化部５５０へ渡す。文書グループ化部５５０は、その「db2jcc.jar」を含むブロックのハッシュ値が同じ文書を１つのグループにグループ化する。この実施形態では、文書１、３、４が同じ「11111111」というハッシュ値をもつため、文書グループ化部５５０は、これらを同じグループにグループ化する。文書２については、「db2jcc.jar」を含むブロックのハッシュ値が「33333333」と異なるため、文書グループ化部５５０は、異なるグループにグループ化する。

文書グループ化部５５０は、グループ化した検索結果をサーチ・ランタイム５３０へ返し、サーチ・ランタイム５３０がクライアント装置２００へその検索結果を送信する。このときのグループ化した検索結果の一例を、図１１（ａ）、（ｂ）に例示する。検索結果は、一見して分かるように、同じグループに属する文書の２番目以降がインデントされている。図１１では、文書１、３、４が、同じグループとされ、文書２が別のグループとされている。

本発明では、検索対象となる文書を、複数のブロックに分割し、各ブロックに含まれる文字列からハッシュ値を計算し、計算したハッシュ値にそのブロックの位置情報を対応付けて記憶している。このため、ハッシュ値と位置情報を記憶する分だけ、メモリ使用量が増加する。メモリ使用量の大幅な増加は、プロセッサの処理速度の大幅な低下を招いてしまう。

そこで、どの程度メモリ使用量が増加するかについて検討した。格納される文書（電子メール）の数が１１８３０、センテンス数が５１２１２７のメール・コーパスをデータソースとして使用した。文書の分割は、センテンス毎で行い、ハッシュ値は、８バイトの長さ、位置情報は、文書の先頭トークンからセンテンスの先頭トークンまでの順番を表すトークン番号と、文書の先頭トークンからセンテンスの末尾トークンまでの順番を表すトークン番号とした。

この条件の下、インデックスを格納するために使用されるメモリ使用量は、従来のインデックスを格納するのみで、ハッシュ値を記憶しない場合には、９３９９５００８バイトとなり、本発明のインデックスに加えてハッシュ値も記憶する場合には、９８８２００９６バイトとなった。これは、１センテンス当たり、９．４２バイトの増加で、メモリ使用量は、約５％増加しただけであった。このことから、メモリ使用量が大幅に増加することはなく、プロセッサの処理速度に影響はないものと考えられる。

検索対象となる文書は、テキストが抽出できる文書であればいかなる文書であってもよく、テキストファイル、オフィス文書、電子メール等を挙げることができる。なお、データ・フォーマットが異なる文書でも、抽出されたテキストと分割情報が同一であれば、関連する文書であるか否かを検出することができる。このため、ブロックの分割は、同じ区切り方でなければならない。区切り方が異なれば、関連する文書の判断が変わるからである。

検索システムが文書毎に持つべき情報としては、上記の文書を構成するトークン列、どのように分割するかを示す分割情報のほか、文書の識別情報（例えば、文書番号）、ハッシュ値に含める文字情報等を挙げることができる。トークン列および文書の識別情報は、パーサー５１０から受け取るが、分割情報は分割部５３５が、ハッシュ値に含める文字情報は計算部５４０がそれぞれ保持する。

また、インデックス作成時に記憶し、検索時に使用する情報としては、ハッシュ値、ブロックの位置情報のほか、文書の識別情報を挙げることができる。これらは、記憶部５４５に記憶され、検索時に、文書グループ化部５５０により読み出される。

これまで、本発明の検索システムおよびその検索システムにより実行される検索方法を、図面を参照して詳細に説明してきたが、本発明は上記実施の形態に限定されるものではなく、他の実施形態や、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。本発明は、コンピュータ読み取り可能なプログラムとして構成し、コンピュータにそのプログラムを実行させることにより、検索システムとして実現することができ、そのプログラムは、記録媒体に格納して提供することができる。

１０…検索エンジン、１１…データベース、１２…クローラー、１３…パーサー、１４…ストア、１５…インデクサー、１６…索引、１７…サーチ・ランタイム、１８…クエリ関連情報作成装置、１９…クエリ関連情報比較装置、２０…データソース、３０…クライアント装置、１００…データソース、２００…クライアント装置、３００…サーバ装置、３１０…メモリ、３２０…プロセッサ、３３０…メモリ制御部、３４０…チャネル・サブシステム、３５０…制御装置、３６０…入出力デバイス、４００…ネットワーク、５００…クローラー、５０５…データベース、５１０…パーサー、５１５…ストア、５２０…インデクサー、５２５…索引、５３０…サーチ・ランタイム、５３５…分割部、５４０…計算部、５４５…記憶部、５５０…文書グループ化部

Claims (20)

1. 入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムであって、
   検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割する分割部と、
   各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部と、
   得られた前記ハッシュ値を前記文書におけるブロックの位置情報とともに記憶する記憶部と、
   前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力する文書グループ化部とを備える、検索システム。
2. 前記分割部は、前記分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する、請求項１に記載の検索システム。
3. 前記文書は、複数の単語（トークン）が順に配列するトークン列とされ、前記各ブロックの位置情報は、前記文書の先頭トークンから前記各ブロックの先頭トークンまでのトークンの順番を含む、請求項１に記載の検索システム。
4. 前記各ブロックの位置情報は、前記文書の先頭文字から前記各ブロックの先頭文字までの文字数を含む、請求項１に記載の検索システム。
5. 前記計算部は、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する、請求項１に記載の検索システム。
6. 前記文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む、請求項１に記載の検索システム。
7. 入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムにより実行される検索方法であって、
   検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割するステップと、
   各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算するステップと、
   得られた前記ハッシュ値を前記文書におけるブロックの位置情報とともに記憶部に記憶するステップと、
   前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力するステップとを含む、検索方法。
8. 前記分割するステップと前記計算するステップと前記記憶するステップは、前記検索システムが検索時に使用するインデックスの作成時に実行され、前記出力するステップは、前記検索時に実行される、請求項７に記載の検索方法。
9. 前記分割するステップでは、前記分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する、請求項７に記載の検索方法。
10. 前記文書は、複数の単語（トークン）が順に配列するトークン列とされ、前記各ブロックの位置情報は、前記文書の先頭トークンから前記各ブロックの先頭トークンまでのトークンの順番を含む、請求項７に記載の検索方法。
11. 前記各ブロックの位置情報は、前記文書の先頭文字から前記各ブロックの先頭文字までの文字数を含む、請求項７に記載の検索方法。
12. 前記計算するステップでは、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する、請求項７に記載の検索方法。
13. 前記出力するステップは、グループに含まれる複数の文書を、検索スコアに基づきソートするステップを含む、請求項７に記載の検索方法。
14. 入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムにより実行される検索方法を実行するためのコンピュータにより読み取り可能なプログラムであって、
    検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割するステップと、
    各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算するステップと、
    得られた前記ハッシュ値を前記文書におけるブロックの位置情報とともに記憶部に記憶するステップと、
    前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力するステップとを実行させる、プログラム。
15. 前記分割するステップと前記計算するステップと前記記憶するステップを、前記検索システムが検索時に使用するインデックスの作成時に実行させ、前記出力するステップを、前記検索時に実行させる、請求項１４に記載のプログラム。
16. 前記分割するステップでは、前記分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する、請求項１４に記載のプログラム。
17. 前記計算するステップでは、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する、請求項１４に記載のプログラム。
18. 前記出力するステップは、グループに含まれる複数の文書を、検索スコアに基づきソートするステップを含む、請求項１４に記載のプログラム。
19. 入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムであって、
    検索対象となる文書を、指定された分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つに基づき複数のブロックに分割する分割部と、
    各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部と、
    得られた前記ハッシュ値を、複数の単語（トークン）が順に配列するトークン列とされる前記文書の先頭トークンから前記各ブロックの先頭トークンまでのトークンの順番を含むブロックの位置情報とともに記憶する記憶部と、
    前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力する文書グループ化部とを備え、
    前記計算部は、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算し、
    前記文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む、検索システム。
20. 入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムであって、
    検索対象となる文書を、指定された分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つに基づき複数のブロックに分割する分割部と、
    各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部と、
    得られた前記ハッシュ値を、前記文書の先頭文字から前記各ブロックの先頭文字までの文字数を含むブロックの位置情報とともに記憶する記憶部と、
    前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力する文書グループ化部とを備え、
    前記計算部は、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算し、
    前記文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む、検索システム。

Images