JP5038939B2 - 情報検索システム、方法及びプログラム - Google Patents

情報検索システム、方法及びプログラム Download PDF

Info

Publication number
JP5038939B2
JP5038939B2 JP2008051871A JP2008051871A JP5038939B2 JP 5038939 B2 JP5038939 B2 JP 5038939B2 JP 2008051871 A JP2008051871 A JP 2008051871A JP 2008051871 A JP2008051871 A JP 2008051871A JP 5038939 B2 JP5038939 B2 JP 5038939B2
Authority
JP
Japan
Prior art keywords
order
information
word
document
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008051871A
Other languages
English (en)
Other versions
JP2009211263A (ja
Inventor
大介 宅間
祐太 坪井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to JP2008051871A priority Critical patent/JP5038939B2/ja
Priority to US12/396,876 priority patent/US8171052B2/en
Publication of JP2009211263A publication Critical patent/JP2009211263A/ja
Application granted granted Critical
Publication of JP5038939B2 publication Critical patent/JP5038939B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/3331—Query processing
    • G06F16/334—Query execution
    • G06F16/3344—Query execution using natural language analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/316—Indexing structures
    • G06F16/322—Trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Artificial Intelligence (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Machine Translation (AREA)
  • Document Processing Apparatus (AREA)

Description

この発明は、テキストデータから、所定のパターンにマッチするテキストを検索するためのシステム、方法及びプログラムに関するものである。
例えば、コールセンターでのやりとりのテキストデータに対して、所定のパターンにマッチするテキストを検索する技術の要望がある。すなわち、マッチするパターンを検索して、問題解析を行う。その他、メールデータに対しても、コンプライアンス違反分析などのために、同様の要望がある。
コールセンターでのやりとりを例にとると、「注文と違う製品が届いた」という内容について、検索パターンを作成し、対策を取った前後の検索該当文書数をトラッキングするような業務が考えられる。このような用途の業務には、高い精度が要求され、やりとりのテキストに関する言語処理の構文解析結果に対するパターンマッチングを行うことが望まれる。
この場合、例えば、
・「違う」が「製品」に係る
・「製品」が「届く」に係る
というパターンにマッチする文書を取得することが考慮される。
構文解析結果は、文毎に、単語間の依存構造を表現した依存構造木と呼ばれるツリー構造である。そうして、依存構造木にマッチさせるパターンも、ツリー構造で表現し、すると、マッチングは、依存構造木が、パターンを親子ノード間のギャップを許す部分構造として含むかどうかを判定する問題となる。
インターナショナル・ビジネス・マシーンズ・コンーポレーションから提供されている、Omnifind Analytics Editionでは、パターンを予め記述し、バッチ処理において、全ての文書に対して、パターン・マッチングを行っている。
しかし、この際のパターンの記述には、次のような問題点がある。
１．パターン作成は試行錯誤を伴い、しかも、パターン編集から結果閲覧まで逐次処理を要し、効率が悪い。特に、データサイズが大きい場合、編集結果の確認のために、一日以上待つことがある。
２．テキストデータの全体を見渡さないと、どのようなパターンが存在するか分からない。
３．業務に有用なパターンを探す際に、未知のパターンを見つける手掛かりがない。
ツリー構造の検索では、XPathに対する検索技術として、"A Fast Index for Semistructured Data", Brian F. Cooper, Neal Sample, Michael J. Franklin, Gisli R. Hjaltason, Moshoe Shasmon, The VLDB Conference 2001 に、各ノードのpreorder, postorderをもつテーブルに、各ノードを１レコードとして、ＲＤＢ上で扱うことが、記述されている。この技術を構文解析結果に適用すれば、上記１．を改善することができるが、それでも、１００ＭＢのデータにおける２単語からなる単純な係り受けの検索に数秒かかり、数ＧＢ〜数１０ＧＢのデータでは、ユーザがストレスを感じるレベルの時間がかかる。また、上記２．や３．については、問題に対する解決策を提供できない。
発見的にパターンを列挙することは、ツリーマイニングに関する、"Efficiently Mining Frequent Trees in a Forest", Mohammed J. Zaki, Proceedings of the eighth ACM SIGKDD international conference on Knowledge discovery and data mining, July 23-26, 2002という文献に記述されている技術が知られている。この技術によれば、バッチ処理によって頻出する部分ツリー(embedded sub-tree：親子のノードがもとのツリー上で直接親子関係でないものも含む部分ツリー)を抽出しておくことが可能である。しかし、構文解析結果にこれを適用した場合、「お願い」→「致す」、「電話」→「を」→「切る」等、ユーザーにとって自明なパターンが大量に抽出されてしまい、上記３．に対する解決策にならない。
金山博、鳥澤健太郎、光石豊、辻井潤一「３つ以上の候補から係り先を選択する係り受け解析モデル」自然言語処理 vol. 7, no. 5, pp. 71-91, 2000 は、係り元の文節と係り先の文節の候補となる全ての文節に関する情報を確率の条件部として、ある文節が係り先として選択される確率を求めるようにした、３つ組／４つ組モデルを提案する。
特開２００７−３１７１３９は、係り受け関係同士の関係に着目して、文書データ解析を支援することを開示する。係り受け関係検索条件入力部は、取り出したい係り受け関係を指定するものである。通常の検索では、キーワードおよびその検索位置（係り部か受け部か、またはその双方）を指定する。係り受け関係検索部は係り受け関係集合記憶部の基礎意味チャンク集合記憶部を参照して該当する係り受け関係を抽出する。係り受け関係検索部は係り受け関係集合記憶部のメタ意味チャンク記憶部を参照して係り元または係り先の係り受け関係を抽出し、表示部は検索結果の係り受け関係集合を表示する。
特開２００７−３１７１３９ "A Fast Index for Semistructured Data", Brian F. Cooper, Neal Sample, Michael J. Franklin, Gisli R. Hjaltason, Moshoe Shasmon, The VLDB Conference 2001 "Efficiently Mining Frequent Trees in a Forest", Mohammed J. Zaki, Proceedings of the eighth ACM SIGKDD international conference on Knowledge discovery and data mining, July 23-26, 2002 金山博、鳥澤健太郎、光石豊、辻井潤一「３つ以上の候補から係り先を選択する係り受け解析モデル」自然言語処理 vol. 7, no. 5, pp. 71-91, 2000
この発明の目的は、大量のテキスト文書を含む文書データから、係り受けパターンにマッチする文書を高速に検索するための技法を提供することにある。
本発明は、上記目的を解決するために、動的に与えられた検索パターンに対して、それにノードを１つ追加した拡張検索パターンでテキストデータ中に頻出するものを、頻度順にＮ個高速に取得する仕組みを提供する。これにより、対話的な検索パターンの編集、有用な検索パターンへの誘導を可能にし、以って上述した問題を解決する。
本発明に従うシステムは、インデックス作成部、クエリ入力部、インデックス読取部を構成要素とし、各単語について、構文解析結果上の位置情報のリストを、好適には、文書頻度でソートしてもつ。
インデックス作成部は、構文解析結果のツリーのノードとして出現した各単語からもノードの出現情報（文書ＩＤ、ツリー上位置）の配列をシーケンシャルアクセスで取得できるインデックスを作成する。このインデックスにおいて、各ノードは、該当文書ＩＤ数（重複は数えない）の降順にソートしておく。
クエリ入力部は、ユーザまたは外部アプリケーションからクエリを受理する。クエリは、検索パターン（単語をノードラベルにもつツリーで、ブランチに最大depth（深さ）差情報をもつ）、ピボット（検索パターン拡張の基点、または基準とするノード）、正整数d（ピボットから拡張ノードを探す際の最大depth差、ギャップ）、正整数N（頻度順に提示する拡張ノードの最大数）、及びフラグ（上位ノードを探すかどうかを指定するフラグ）から構成される。
インデックス読取部は、先ず、検索パターンにマッチする箇所のピボットの出現情報配列を取得する。次に、検索パターンのリーフノードと、その親の単語について、テキストデータ中の出現情報で、最大depth差以内の上位下位関係にあるペアを取得し、親ノードに対する出現配列情報を、ペアに含まれるもののみで（メモリ上で）上書きし、リーフノードを検索パターンから削除する。
上記の検索を、ルートとピボットを結ぶいずれかのノードに辿り着くまで行う。
次に、検索パターンのルートとその子ノードについて、テキストデータ中の出現情報で、最大depth以内の上位下位関係にあるペアを取得し、子ノードの出現情報配列を、ペアに含まれるもののみで更新し、ルートを削除する。
上記の処理を、ピボットに達するまで行い、最終的に、ピボットの出現情報配列をアウトプットする。
拡張ノード計算では、ピボットのd階層以内の上位ノード（フラグ＝偽の場合、下位ノード）をカウントする。
そうして、インデックスのソート順に、各単語の出現情報配列を取得し、ピボットの出現情報配列と、上位下位条件、depth差条件を満たす出現情報を算出し、そこで出現した文書ＩＤを、単語頻度とする。
頻度順上位Ｎ個の単語を保持したまま上記を行い、第Ｎ位の頻度がインデックス上の次の未読ラベルの文書ＩＤ数以上となったら処理を止め、上位Ｎの単語と頻度をアウトプットする。
この発明によれば、動的に与えられた検索パターンに対して、それにノードを１つ追加した拡張検索パターンでテキストデータ中に頻出するものを、頻度順にＮ個高速に取得する仕組みを提供することによって、大量のテキスト文書から、係り受けパターンにマッチする文書を高速に検索するための技法が実現される。
以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。
図１を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・パス１０２には、ＣＰＵ１０４と、主記憶（ＲＡＭ）１０６と、ハードディスク・ドライブ（ＨＤＤ）１０８と、キーボード１１０と、マウス１１２と、ディスプレイ１１４が接続されている。ＣＰＵ１０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標） ４、Ｃｏｒｅ（商標） ２ ＤＵＯ、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１０６は、好適には、２ＧＢ以上の容量をもつものである。ハードディスク・ドライブ１０８は、コールセンターなどから入手したテキスト・ファイルと、その構文解析結果に対するインデックス・ファイルを格納するために、２００ＧＢ以上の容量をもつものであることが望ましい。
ハードディスク・ドライブ１０８には、個々に図示しないが、オペレーティング・システム、コールセンターなどから入手したテキスト・ファイル、構文解析用プログラム、本発明に係る処理用プログラムが、予め格納されている。ハードディスク・ドライブ１０８には更に、好適には、本発明に係る処理の結果生成されたインデックス・ファイルも格納される。
オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ（商標） Ｖｉｓｔａ、Ｗｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃ ＯＳ（商標）などの、ＣＰＵ１０４に適合する任意のものでよい。
ハードディスク・ドライブ１０８にはまた、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）などの任意のプログラム言語処理系を格納してもよい。このプログラム言語処理系は、本発明に係る処理プログラムを作成し、維持するために使用される。
ハードディスク・ドライブ１０８にはさらに、プログラム言語処理系でコンパイルするためのソースコードを書くためのテキスト・エディタ、及び、Ｅｃｌｉｐｓｅ（商標）などの開発環境を含んでいてもよい。
キーボード１１０及びマウス１１２は、オペレーティング・システムまたは、ハードディスク・ドライブ１０８から主記憶１０６にロードされ、ディスプレイ１１４に表示されたプログラム（図示しない）を起動したり、文字を打ち込んだりするために使用される。
ディスプレイ１１４は、好適には、液晶ディスプレイであり、例えば、ＸＧＡ（１０２４×７６８の解像度）、またはＵＸＧＡ（１６００×１２００の解像度）などの任意の解像度のものを使用することができる。ディスプレイ１１４は、図示しないが、本発明に係るインデックス作成ツール、及び検索ツールなどのの操作画面を表示するために使用される。すなわち、この画面に、キーボード１１０で所定のパラメータやファイル名を入力し、表示されている所定のボタンをマウス１１２でクリックすることにより、キーワード作成処理が開始される。
次に、図２は、本発明の処理に係る機能ブロック図である。図２に示すように、本発明の処理のためには先ず、コールセンターなどから入手したテキスト・ファイルに対して構文解析を行うことによって、構文解析済みテキスト・データ２０２が用意される。テキスト・ファイルを構造解析することによって、ツリー構造を生成する技法は、本出願に係る特開２００１−１３４５７５、特開２００２−３１８７９８などに記述されて公知であり、本発明の処理の要部ではないので、ここでは詳述しない。
テキスト・データの構文解析においては、複数の文書であるテキスト・データを入力とし、それらの文書の構文解析結果としての、係り元の単語を子ノードとかる単語のツリー構造を生成する。図３は、そのような構文解析結果のツリーの例であって、「ＯＳを導入してからＣＤ−ＲＯＭを認識しない。」という文書のツリー３０２と、「解決法を教えて欲しい。」文書のツリー３０４を、ルートノード３０６の下に追加した構造を示す。このようなデータ構造は、Ｃ、Ｃ＋＋などの構造体とポインタの組み合わせ、またはディスクに永続化されたＪａｖａのクラスなどの、適当なデータ構造によって実現することができることを、この分野の当業者なら理解するであろう。
＜インデックス作成部＞
インデックス作成部２０４は、上記構文解析済みテキスト・データを読み込み、図４に示すインデックス・ファイルを作成する。これは、図２では、インデックス２０６と、総称的に示されている。インデックス・ファイルは、ランク・ファイル４０２と、ノード・アレイ・ファイル４０４とからなり、ハードディスク・ドライブ１０８上に書かれる。
ランク・ファイル４０２は、テキストデータに出現した各単語について、ノードとしての出現回数の累積、１回以上ノードとして出現した文書数、及び単語ＩＤ、の３つの組を、文書数の降順でソートして、ハードディスク・ドライブ１０８上に保存したものである。
出現回数の累積の情報は、図１３などに関連して後述する検索部１ １３０２と、検索部２ １３０４によって使用される。また、文書数、及び単語ＩＤの情報は、やはり図１３などに関連して後述する、トップＮ算出部１３０８によって使用される。出現回数の累積の情報は、ノード・アレイ・ファイル４０４における、その行までのinfo（図４に関連して後述する）のブロックの数の累積になるので、事実上、ポインタの役割を果たす。
ノード・アレイ・ファイル４０４は、各単語のテキスト・データ上での出現位置を、文書ＩＤ、preorder、postorder、depth（ツリー上の深さ）の４つの組（図４では、infoとして図示されている）として、ハードディスク・ドライブ１０８上に記録している。preorderとは、ルート・ノードから各ノードを数えた順方向の番号である。postorderとは、１つの末端ノードからルート・ノードに向かって数えた逆方向の番号である。尚、テキスト・データ上のツリーには、ノードのオーダーはもともと与えられていないが、そのオーダーは、単語のオフセット順などの適当な方法で、一意に決めておくものとする。このオーダーとしては単語の文書数の降順、文書ＩＤの昇順、depthの昇順、preorderの昇順の順に行う。
preorderは各文の中でユニークなので、このオーダーで、出現情報のソートは、一意に決まる。ランク・ファイル４０２上の各単語ＩＤのランクは、図４の矢印４００で示すように、別途、マップ型のインデックスで保持しておく。
尚、preorder、postorder、depthについて、図７を参照して、説明を補足する。図７は、ノードＡ〜Ｊをもつ例を示す。この例(a)で、ノードＡを起点とすると、preorderは、ＡＢＣＤＥＦＧＨＩＪである。これらは順に、1,2,..と順番を付けられ、例えば、preorder=3はＣであり、preorder=5はＥである。このpreorder番号付けアルゴリズムは、図８を参照して、後で説明する。
一方、postorderは、ノードＤを起点とすると、ＤＣＥＢＨＩＧＪＦＡである。これらは順に、1,2,..と順番を付けられ、例えば、postorder=4はＢであり、postorder=6はＩである。このposteorder番号付けアルゴリズムは、図９を参照して、後で説明する。
これらのpreorder、postorderで以って、別の観点でノードＡ〜Ｊを図式化すると、図７(b)のようになる。ノードを矩形で表示し、その左側に書かれているのがpreorderで、右側に書かれているのがpostorderである。これによると、ノードxがノードyの上位にあることの必要十分条件は、
xのpreorder > yのpreorder且つ、yのpostorder < xのpostorderである。
例えば、図７のノードＦをノードxということにすると、ノードyがノードxの下位ノードであるかどうかは、図７(b)で、ノードyの箱の左端・右端が、点線の範囲内にあるかどうかで判断できる。
また、深さについては、depth(Ａ) = 1
depth(Ｂ) = depth(Ｆ) = 2
depth(Ｃ) = depth(Ｅ) = depth(Ｇ) = depth(Ｊ) = 3
depth(Ｄ) = depth(Ｈ) = depth(Ｉ) = 4
次に、図５のフローチャートを参照して、インデックス作成部２０４のインデックス作成処理を、より具体的に説明する。図５において、ステップ５０２では、ノードラベル（単語）をキー、値を出現頻度配列とするマップＭが初期化される。
なお、図５の処理は、主記憶の制限から、入力テキスト・データのファイルを適当な文書ＩＤ毎に分割し、サイズをあるレベル（例えば、５００ＭＢ）以下に抑え、その分割された文書群に対して、中間的なランク・ファイルと、ノード・アレイ・ファイルを出力するものである。
ステップ５０４では、テキスト・ファイルに未読文書が存在するかどうかが判断される。そして、もしまだ、テキスト・ファイルに未読文書が存在するなら、ステップ５０６では、未読文書が１つ読み込まれる。ここでいう文書すなわちテキスト文とは、図３に示す、ツリー構造の文書３０２や、文書３０４のような単位である。
ステップ５０８では、読み込んだ文書の各ノードに、preorder、postorder順の整数値と、depthを振る。ここの詳しい処理は、図８、図９及び図１０のフローチャートに関連して、後で説明する。
ステップ５１０では、文書に未読ノードxが存在するかどうかが、判断される。未読ノードxが存在するなら、未読ノードxを読み込み、ステップ５１４では、Ｍのキーに、xのラベルが存在するかどうかが判断される。
もしステップ５１４の判断が肯定的なら、ステップ５１６で、Ｍのキーxのマップ先の出現情報配列に、xの出現情報（文書ＩＤ、preorder、postorder、depth）が追加されて、ステップ５１０に戻る。
もしステップ５１４の判断が否定的なら、ステップ５１８で、Ｍのキーがxのラベル、値が長さ0の出現情報配列のエントリーを追加する。それから、ステップ５１６を経て、ステップ５１０に戻る。
ステップ５１０に戻って、文書に未読ノードxが最早存在しないと判断されたなら、処理はステップ５０４に戻り、そこで、テキスト・ファイルに最早未読文書が存在しないと判断されると、ステップ５２０で、累積出現数aを0に初期化した後、ステップ５２２に行って、Ｍが空かどうかが、判断される。
そして、もし空でなければ、ステップ５２４で、Ｍの中で出現情報配列の文書数（重複は、カウントしない）が最大のエントリーwと、出現情報配列info[]を取得し、そのエントリが、Ｍから削除される。
次に、ステップ５２６では、aにinfo[]の配列長が加算されて、ランク・ファイルに出力される。続いて、文書数、wの単語ＩＤも、ランク・ファイルに出力される。
次に、ステップ５２８では、info[]を、文書ＩＤ昇順、depth昇順、preorder昇順でソートし、ノード・アレイ・ファイル４０４に、文書ＩＤ、preorder、postorder、depthの４つの組が、ソート順に出力される。
こうして、Ｍのすべてのエントリについて、ステップ５２４、５２６、５２８が完了すると、ステップ５２２の判断が肯定的になって、処理が完了する。
この処理の結果、入力テキスト・データのファイルを適当な文書ＩＤ毎に分割された文書群に対して、それぞれ、中間的なランク・ファイルと、中間的なノード・アレイ・ファイルが出力される。
図６は、このような中間的なランク・ファイルと、中間的なノード・アレイ・ファイルをマージして、単一のランク・ファイル４０２と、ノード・アレイ・ファイル４０４を生成するための処理のフローチャートである。
図６のステップ６０２では、中間的なランク・ファイルがすべて、メモリに読み込まれる。ステップ６０４では、各単語ＩＤについて、全ての中間的なランク・ファイルでの文書数の和、出現頻度の和が計算される。
ステップ６０６では、文書数の和の降順に、単語ＩＤ、文書数の和、出現頻度の和が、結果のランク・ファイル４０２に出力される。
ステップ６０８では、文書数の和の順に、各単語について、文書ＩＤの小さい順に、中間ノード・アレイ・ファイルに検索をかけて、出現情報配列を取得し、それらを足したものを、結果のノード・アレイ・ファイル４０４に出力する。
次に、図８のフローチャートを参照して、ノードにpreorderを付与する処理を説明する。ステップ８０２では、p = 1, n = ルートノードと初期化される。
ステップ８０４では、ノードnにpreorderが未付与かどうかが判断される。もしそうなら、ステップ８０６で、ノードnにpreorder pが付与される。
ステップ８０４での判断が否定的なら、ステップ８０８で、nにpreorder未付与の子ノードが存在するかどうかが判断される。もしそうであれば、ステップ８１０で、nに、preorder未付与のnの子ノードのうちの最初のノードが代入される。そうして、処理は、ステップ８０４に戻る。
ステップ８０８での判断が否定的なら、ステップ８１２で、nにpreorder未付与の兄弟ノードが存在するかどうかが判断される。もしそうであれば、ステップ８１４で、nに、preorder未付与のnの兄弟ノードのうちの最初のノードが代入される。そうして、処理は、ステップ８０４に戻る。
ステップ８１２での判断が否定的なら、ステップ８１６で、nがルートノードかどうかが判断される。もしそうなら、処理は完了である。そうでなければ、ステップ８１８で、nにnの親ノードが代入されて、処理は、ステップ８０４に戻る。
次に、図９のフローチャートを参照して、ノードにpostorderを付与する処理を説明する。ステップ９０２では、p = 1, n = ルートノードと初期化される。
ステップ９０４では、ノードnにpostorderが未付与の子ノードmが存在するかどうかが判断される。もしそうなら、ステップ９０６で、ノードnにpreorder未付与のnの子ノードのうち最初のノードが付与される。そうして、処理は、ステップ９０４に戻る。
ステップ９０４での判断が否定的なら、ステップ９０８で、nにpostorder pを付与し、pが1増分される。
ステップ９１０では、ノードnにpostorderが未付与の兄弟ノードmが存在するかどうかが判断される。もしそうなら、ノードnにpreorder未付与のnの兄弟ノードのうち最初のノードが付与される。そうして、処理は、ステップ９０４に戻る。
ステップ９１０での判断が否定的なら、ステップ９１４で、nがルートノードかどうかが判断される。もしそうなら、処理は完了である。そうでなければ、ステップ９１６で、nにnの親ノードが代入されて、処理は、ステップ９０４に戻る。
次に、図１０のフローチャートを参照して、ノードにdepthを付与する処理を説明する。ステップ１００２では、depth値 d = 1, n = ルートノードと初期化される。ステップ１００４では、ノードnにdepthが未付与の子ノードmが存在するかどうかが判断される。もしそうなら、ステップ１００６で、dが１増分されて、nにmが代入される。そうして、処理は、ステップ１００４に戻る。
ステップ１００４での判断が否定的なら、ステップ１００８で、ノードnにdepth dを付与する。次に、ステップ１０１０では、ノードnにdepthが未付与の兄弟ノードmが存在するかどうかが判断される。もしそうなら、ステップ１０１２で、nにmが代入されて、処理は、ステップ１００４に戻る。
ステップ１０１０での判断が否定的なら、ステップ１０１４で、nがルートノードかどうかが判断される。もしそうなら、処理は完了である。そうでなければ、ステップ９１６で、nにnの親ノードが代入されて、dが１減らされ、処理は、ステップ１００４に戻る。
＜クエリ入力部＞
クエリ入力部２１０（図２）は、ユーザまたは外部アプリケーション・プログラムから、以下をパラメータにもつクエリを受理する。
・検索パターン：単語をノードラベルとするツリーで、各ブランチに、ノード最大depth差を意味する正整数属性をもつ。
・検索パターン上のノード・ピボット：検索パターン拡張の基準とする。
・ピボットとの最大depth差を指定する正整数d
・正整数N：取得する拡張ノードラベル候補の最大数。
・フラグ：これがtrueの場合、ピボットの頻出上位ノードを探す。falseの場合、ピボットの頻出下位ノードを探す。一般的に、trueの場合、ピボットは、検索パターンのルートノードになる。
ノードに対してラベルを対応させる関数をL、検索パターンをP={Np,Bp,D}であらわす。
ここで、Npはノードの集合、Bpはブランチ（親ノード,子ノード)の集合、Dはブランチに対して最大depth差を返す関数である。すると、検索パターンPは、以下を満たすとき、
文書T={NT,BT}とマッチする。
Figure 0005038939
これは、親子ノードのギャップを許す形で、検索パターンを含む文書を検索することを意味する。頻度順トップN単語の計算では、上記のm1, m2, ..., mkのうち、ピボットと同じ単語のものを、m*として、フラグ=trueの場合、各単語について、単語をラベルとするm∈NTで、m>>m* (M), M<=dとなるものを含む文書数を頻度とする。
フラグ=falseの場合、上記の条件は、m<<m* (M), M<=dとなる。
図１１には、入力テキスト・データの構文木に対する、検索パターンのパターン・マッチを示す図である。この図の示す例では、「ＳＰ２」というラベルをもつノードを跨いで、パターンがマッチしている。
図１２は、検索パターンにおけるピボットの例を示す図である。図１２では、「たら」というラベルをもつノードがピボットと指定され、結果として、このクエリにマッチする文書が検索されるが、その際、ピボットの子ノードに入る単語と、その該当文書数が、例えば、吹き出し１２０２に示すように、求められる。
＜インデックス読取部＞
インデックス読取部２０８は、図１３に示すように、検索部１ １３０２、検索部２ １３０４、出現情報読取部１３０６、トップＮ計算部１３０８、及び上位下位判定部１３１０からなる。
インデックス読取部２０８の動作の概要は、図１４のフローチャートに示すように、ステップ１４０２で検索部１を呼び出し、ステップ１４０４で検索部２を呼び出し、ステップ１４０６でトップＮ計算部１３０８を呼び出すことにより行われる。このとき、出現情報読取部１３０６と、上位下位判定部１３１０は、補助的に呼び出される。
次に、インデックス読取部２０８の各機能ブロックの機能を、詳細に説明する。
先ず、出現情報読取部１３０６は、図４に示すインデックスを行単位で読み込み、出現情報配列を作成する。出現情報読取部１３０６は、検索部１ １３０２、検索部２ １３０４から呼び出され、指定された単語の出現情報配列を作成する際は、ランク・ファイル４０２の該当する単語ＩＤの出願頻度の累積を読み、その情報をオフセットとして用いて、ノード・アレイ・ファイル４０４の該当行のトップにランダムアクセスし、その後、シーケンシャルアクセスで出現情報配列を読み込む。各単語ＩＤのランク・ファイル４０２上の位置は，別途保持しているマップ型インデックスで調べる。
インデックス読取部２０８が、検索部１ １３０２、検索部２ １３０４から呼び出される場合の処理を、図１５のフローチャートを参照して説明する。図１５において、ステップ１５０２で、ランク・ファイル４０２上の指定された単語ＩＤであるwの箇所にアクセスし、その単語の出現回数の累積であるp(w)及び、その１つ前の出現回数の累積であるq(w)を読み取る。なお、クエリ入力部２１０から入力されるのは、単語ＩＤではなく、単語なので、単語から、対応する単語ＩＤを突き止める必要がある。
このため、図示しないが、ハッシュによって、(1) 単語から単語ＩＤの対応、(2) 単語ＩＤから、ランク・ファイル４０２上の単語のランク、及び(3) 単語ＩＤから単語への対応、のマップを作成しておく。
そうして、検索の単語文字列wが与えられたら、上記(1)のハッシュで、先ず単語ＩＤを取得する。それから、上記(2)のハッシュで、ランクrを取得する。すると、ランク・ファイル４０２上での単語wの位置は、
(r - 1) × { ([出現回数の累積]のバイト数) + ([文書数]のバイト数) + ([単語ID]のバイト数) }
で、アクセスできるので、n2 = wの[出現回数の累積]、n1 = wの1つ上位のランクの[出現回数の累積] を読む。
但し、w が最上位のランクの場合 n1=0 とする。
ノード・アレイ・ファイル４０４の n1 × ([info]ブロックバイト数) から n2 × ([info]ブロックバイト数)をシーケンシャルアクセスで読み、出現情報配列を返す。上記のことは、以下のステップでも、繰り返して説明する。ここで示す[info]は、図４に示されているようなものである。
ステップ１５０４では、ノード・アレイ・ファイル４０４のq(w)×infoブロックのバイト数から、p(q)×infoブロックのバイト数を読み取る。ステップ１５０６では、そうして取得した出現情報を、呼び出した検索部１／検索部２に返す。
出現情報読取部１３０６は、トップＮ計算部１３０８から呼び出され、文書数順に単語の出現情報配列を読み込む際には、全てシーケンシャルアクセスで読み、逐次、出現情報配列を出力する。
インデックス読取部２０８が、トップＮ計算部１３０８から呼び出される場合の処理を、図１６のフローチャートを参照して説明する。図１６において、ステップ１６０２で、終了ポインタpが0にセットされ、ランクrが0で初期化される。
ステップ１６０４では、トップＮ計算部１３０８から読み取り要求があったかどうかが判断される。もし、最早読み取り要求がなければ、処理は終了する。
ステップ１６０４で、トップＮ計算部１３０８から読み取り要求があったと判断されると、ステップ１６０６で、rに1が足される。ステップ１６０８では、ランク・ファイル４０２のr行目が読み取られる。
ステップ１６１０では、トップＮ計算部１３０８のステップ７（後述する）の処理に、文書数が返される。
ステップ１６１２では、開始ポインタqにpが代入され、pに読み取った出現回数の累積が代入される。
ステップ１６１４では、ノード・アレイ・ファイル４０４のq×infoブロックのバイト数から、p×infoブロックのバイト数を読み取る。
ステップ１６１６では、トップＮ計算部１３０８のステップ２（後述する）に、出現情報配列が返される。
次に、上位下位判定部１３１０について説明する。上位下位判定部１３１０は、２つの出現情報配列、upper_candidatesとlower_candidatesと最大depth差dを入力とし、それらを、上位下位条件、及び、depth差条件を満たすペアに属すもののみにフィルターしたfiltered_upper_candidatesとfiltered_lower_candidatesを出力とする。その計算ステップは、下記のとおりである。
1.upper_candidates、lower_candidatesのポインタを0にセットする。
2.upper_candidates、lower_candidatesの現在のポインタの文書ＩＤが等しくなるまで、文書ＩＤが小さい方のポインタを進める。途中で配列の末尾に達したら終了する。
3.文書ＩＤが等しい範囲で、lower_candidatesのdepthがupper_candidatesのdepthより大きくなるまで、lower_candidatesのポインタを進める。途中で文書ＩＤが等しい範囲を超えたらステップ２に戻る。
4.lower_candidatesのdepthが(upper_candidatesのdepth + d)以上の範囲で、lower_candidatesのポインタを進め、upper_candidatesの現在のpreorder／postorderよりもlower_candidatesの現在のpreorder／postorderがそれぞれ大きく／小さくなった箇所で、upper_candidatesとlower_candidatesの出現情報をそれぞれfiltered_upper_candidates、filtered_lower_candidatesに追加する。
5.lower_candidatesのポインタを、ステップ３の時点の位置に戻す。
6.upper_candidatesのポインタを1進め、ステップ２に戻る。
上位下位判定部１３１０については、単語Ａと単語Ｂの出現情報（文書ＩＤ, preorder, postorder, depth)の配列が１つずつあるとき、Ａの出現位置がＢの出現位置の上位になっていて、且つdepth差が入力パラメータd以内の出現情報のペアをすべて見つけるものである、ということもできる。
言い換えると、Ａ.文書ＩＤ = Ｂ.文書ＩＤで、
Ａ.preorder < Ｂ.preorder且つ、Ｂ.postorder < Ａ.postorderを満たすペアを全て見つける、ということである。すると、上記のステップ２は、配列は文書ＩＤでソートされているので、Ａ.文書ＩＤ = Ｂ.文書ＩＤになるまで配列のポインタを進めることである。
上記のステップ３は、文書ＩＤが等しい範囲では、配列はdepth昇順でソートされているので、Ｂの配列ポインタのみ、Ｂ.depth >= Ａ.depthとなるところまで進めることである。
上記のステップ４は、上記のポインタ位置から、Ｂ.depth <= Ａ.depth + dの範囲でＢの配列ポインタを進め、その範囲で、Ａ.preorder < Ｂ.preorder且つ、Ｂ.postorder < Ａ.postorderを満たすペアを抽出する。
１つの出現情報に対して、１つしか下位ノードとなる出現情報を出力しない場合は、ステップ４で、１ペアfiltered_upper_candidates、filtered_lower_candidatesに追加した時点でステップ５に進む。この場合、検索漏れが出る可能性があるが、大幅に処理を単純化できる。
次に、検索部１の処理について、図１７のフローチャートを参照して説明する。検索部１では、検索パターンのルートからピボットまでのパスπ以外のノードについて、検索を行う。検索部１の終了段階で、検索パターンからπ以外のノードは削除され、図１７において、ステップ１７０２では、ピボット以外のリーフノードＡが存在するかどうかが判断される。もし存在しないなら、処理は終了する。
ステップ１７０２で、ピボット以外のリーフノードＡが存在すると判断されると、ステップ１７０４で、インデックス読取部２０８が、リーフノードＡの出現情報配列を読み込み、ノード属性に追加する。
ステップ１７０６では、リーフノードＡの親ノードＢの出現情報配列が読み込み済かどうかが、判断される。もしそうでなければ、ステップ１７０８で、インデックス読取部２０８が、親ノードＢの出現情報配列を読み込み、ノード属性に追加して、ステップ１７１０に至る。もし、リーフノードＡの親ノードＢの出現情報配列が読み込み済であれば、直ちにステップ１７１０に行く。
ステップ１７１０では、上位下位判定部１３１０で、リーフノードＡと、その親ノードＢの出現情報配列をフィルターし、filtered_upper_candidatesで、親ノードＢの出現情報配列を更新する。
ステップ１７１２では、リーフノードＡを削除して、ステップ１７０２の判断に戻る。
次に、検索部２の処理について、図１８のフローチャートを参照して説明する。検索部２では、ステップ１８０２で、ルートがピボットかどうかが判断される。ルートがピボットでないなら、処理は終わる。ルートがピボットであるなら、処理は、ステップ１８０４に進む。
ステップ１８０４では、ルートの出現情報配列が読み込み済かどうかが、判断される。もしそうでなければ、ステップ１８０６で、インデックス読取部２０８が、ルートの出現情報配列を読み込み、ノード属性に追加して、ステップ１８０８に至る。もし、ルートの出現情報配列が読み込み済であれば、直ちにステップ１８０８に行く。
ステップ１８０８では、子ノードＡの出現情報配列が読み込み済かどうかが、判断される。もしそうでなければ、ステップ１８１０で、インデックス読取部２０８が、ルートの出現情報配列を読み込み、ノード属性に追加して、ステップ１８１２に至る。もし、ルートの出現情報配列が読み込み済であれば、直ちにステップ１８１２に行く。
ステップ１８１２では、上位下位判定部１３１０で、ルートと、その子ノードＡの出現情報配列をフィルターし、filtered_lower_candidatesで、子ノードＡの出現情報配列を更新する。
ステップ１８１４では、ルートを削除して、ステップ１８０２の判断に戻る。
次に、トップＮ算出部では、ピボットの出現情報配列、正整数Ｎ、最大depth差d、flagを入力とし、ピボットからd以内の深さにある単語の頻度トップＮ個とその頻度を出力する。flag=trueの場合の処理を以下に示す。
1.暫定トップＮ集合を空集合で初期化する。
2.インデックス読込部から、未読の単語のうち、インデックスでのソート順でトップの単語Ａの出現情報配列を取得する。
3.上位下位判定部で、upper_candidates=Aの出現情報配列、lower_candidates=ピボットの出現情報配列、最大depth差dで、フィルタリングを行い、filtered_upper_candidatesの文書ＩＤを(重複を除いて)カウントする。
4.暫定トップＮ集合に(A、ステップ3で算出した頻度)のペアを追加する。
5.暫定トップＮ集合の要素数がＮより大きい場合、最も頻度の小さいペアを削除する。
6.インデックスに未読の単語が残っていなければ終了する。
7.インデックスのソート順でトップの未読の単語の頻度が、暫定トップＮ集合の最も頻度の小さいペアの頻度以下の場合終了する。このときの終了判定に、ランク・ファイル４０２の文書数が使用される。すなわち、好適には、ランク・ファイル４０２が、文書数でソートされているため、ファイルを途中までしか読んでいない段階でも、暫定Ｎ位のキーワードの文書数が、未読キーワードの文書数以上であれば、検索条件を見るまでもなく以下のキーワードは、ランクに入らないことになる。
8.ステップ２に戻る。
最終的な出力は、終了時点での暫定トップＮとなる。flag=falseの場合は、ステップ3においてupper_candidatesとlower_candidatesが入れ替わり、filtered_upper_candidatesがfiltered_lower_candidatesになる。
＜追加機能＞
上記に提示した検索パターンは、検索ヒット対象を限定していく目的のみで作成されていたが、実用的には、表現の言い換えにより検索ヒット対象を拡げるためのOR条件が必要なケースもある。例として、「Windows のインストールに失敗する」ケースを検索する条件として、
(Windows → インストール → できる → ない)
OR (Windows → インストール → 失敗する)
という条件が考えられる。しかし、ここで更に「Windows」にも言い換え表現を指定する場合を考えると、下記のように検索パターン数が組み合わせ爆発を起こし、列挙された検索パターン全てを処理するのでは効率が悪い。
(Windows → インストール → できる → ない)
OR (Windows → インストール →失敗する)
OR (WIN → インストール → できる → ない)
OR (WIN → インストール →失敗する)
OR (ウィンドウズ→ インストール → できる → ない)
OR (ウィンドウズ→ インストール →失敗する)
よって、上記のような複雑なOR条件の検索処理においても、処理が冗長にならない仕組みが必要になる。
上記の課題を解決するため、言い換え表現を含む箇所を複合ノードという特殊なノードで置き換えることを考える(図１９参照)。複合ノードの実体は、複数の複合ノード検索パターン(図１９右側の「できる→ない」、「失敗する」のツリーに相当)へのポインタとする。出現情報読取部に複合ノードが渡された場合、複合ノード検索パターンのいずれかにマッチする出現情報(処理は後述)を、parent_candidatesとchild_candidatesの2つの配列として返す。複合ノードの出現情報配列は、上位下位判定部に渡す際には、上位ノードとの判定ではparent_candidatesを用い、下位ノードとの判定ではchild_candidatesを用いる。出現情報読取部が返す通常の単語ラベルのノードの出現情報配列をcandidatesとする時、そのノードのparent_candidates、child_candidatesを
parent_candidates=child_candidates=candidates
と定義することで、単語ノードと複合ノードの処理は出現情報読取部の外では、区別せずに扱うことができる。
複合ノード検索パターンのオブジェクト構造は、検索パターンと同じタイプのオブジェクトにchild-connecting_nodeというノードへのポインタを新たに持たせたものとする。ルートノードを「P」、child-connecting_nodeを「C」と記して、図２０にその例を示す。ルートノード「P」は複合ノードの親ノードと接続するノードを意味し、child-connecting_node「C」は複合ノードの子ノードと接続するノードを指す。また、最大depth差は、複合ノードをノードとして含む検索パターン(図２０の一番左のツリー)上で定義されているので、各複合ノード検索パターンのルートとその上位ノードとの最大depth差、child-connecting_nodeとその下位ノードとの最大depth差は、全ての複合ノード検索パターンで共通になる。
複合ノード検索パターンに対し、parent_candidatesとchild_candidatesを計算する仕組みを以下に示す。まず、検索部1のロジックでpivotをルートノードとして、ルートノードの出現情報配列を取得し、これをparent_candidatesとする。その後、ルートノードからchild-connecting_nodeへのパスからなるツリーについて、ルートノードの出現情報配列を上記のparent_candidatesにセットした状態で、検索部2のロジックを、pivot=child-connecting_nodeで適用し、child-connecting_nodeの出現情報配列を計算する。そこで計算された出現情報配列をchild_candidatesとして出力する。各々の複合ノード検索パターンのparent_candidatesとchild_candidatesが計算されたら、それらを配列としてアペンドする。parent_candidatesとchild_candidatesはそれぞれの第n要素(n=0, 1, …)同士がペアになっているが、アペンドする際に、ペアとして完全に重複するものは、重複除去を行い、1つに纏める。以上により、複合ノードを含む検索パターンをパラメタとした、パターン検索、トップＮ計算が可能になる。
＜従来技法に対する、本発明の技法の具体的な効果の説明＞
従来技法では、パターン作成は試行錯誤を伴い、また、パターン編集から結果閲覧までに逐次処理を経由するので、きわめて効率が悪い。
一方、本発明の技法は、検索部２までの結果を用いてパターン検索機として使用することができる。すなわち、インデックスを使っての検索で、パターン作成後から検索結果を得るまでは、１．４ＧＨｚのクロックレートのインテル Ｃｏｒｅ（商標）２ ＤＵＯのパーソナル・コンピュータで、３．６ＧＢ、１０万件のデータで、平均１秒以内、検索候補の係り元、係り先のトップＮの計算も数秒〜数十秒程度である。図２１に、編集サイクルの違いを示す。
従来技法では、テキストデータ全体を見渡さないと、どのようなパターンが存在するか分からない。
一方、本発明の技法では、トップＮ機能により、高頻度のパターンを優先的に見つけることができる。
従来技法では、業務に有用なパターンを探す際、未知のパターンを見つける手がかりが無い。
一方、本発明の技法では、トップN機能で、興味のある単語の周辺から発見的にトピックを見つけ出せる。以下に例を挙げる。パターンを拡張する際に人間の手を介在できるため、自明なパターンかどうかの判断を行いながらのパターン作成が可能である。
また、本発明の技法では、製品名、サービス名、部品名等の係り先のトップＮを調べることで、「壊れる」、「つまらない」、「分からない(分かる+ない)」、「動かない(うごく+ない)」等、興味のある対象について頻繁に言及されている表現を高い精度(共起ではなく、係り受けを調べるという意味で)で見つけることができる。
また、「ＣＤ−ＲＯＭを認識しない(ＣＤ−ＲＯＭ+認識する+ない)」のような、現象を表すフレーズに対し、用言「認識する」の係り元を調べ、「たら」、「から」、「後」等を解して係っている語を調べることで、「Windows95を導入した」、「FORMATをした」、「HDDを増設した」といった現象の原因を見つけることができる。
＜具体的な検索例＞
次に、図２２以下を参照して、具体的な検索処理の実例を説明する。
図２２においては、例えば、下記の６個の文章、すなわちテキスト文をもつものとする。なお、実際はこれよりもはるかに多数の文書を扱うが、説明の便宜上、少ない文書数で説明する。
文書１：店でＰＣを買った。
文書２：今日電池を買った。
文書３：今日ＰＣを買いたい。
文書４：ＰＣをお店で買ったか、ＰＣを通販で買ったか忘れた。
文書５：昨日、渋谷の店でＰＣを買った。
文書６：ＰＣはその店で買った。
図２２に、それぞれの文書の構造木をあらわす。なお、図２２では、便宜上、句読点とルートは省略している。
図２３は、図２２に示した文書から、ノード・アレイ・ファイル４０４のインデックスを作成することを示す。ここでは、特に、「買う」と、「を」と、「ＰＣ」に着目し、図中ではそれらのノードはそれぞれ、強調表示されている。もちろん、その他の単語についても、ノード・アレイ・ファイル４０４のエントリは作成されるのだけれども、便宜上、説明を省略する。
すなわち、「買う」の出現情報 (文書ＩＤ, preorder, postorder, depth) = (1,2,5,2) (2,2,4,2) (3,2,4,2) (4,5,5,5) (4,12,12,5) (5,2,8,2) (6,2,6,2)
「を」の出現情報： (1,3,2,3), (2,4,3,3) (3,4,3,3) (4,6,2,6) (4,13,9,6) (5,8,6,4)
「ＰＣ」の出現情報： (1,4,1,4) (3,5,2,4) (4,7,1,7) (4,14,8,7) (5,9,6,4) (6,4,1,4)
この処理は、図２のインデックス作成部２０４によって、図５、図６のフローチャートを用いて、実行される。
次に、図２４を参照して、実際の検索の処理について説明する。図２４では、「ＰＣ買った」という検索パターンで、検索するものとする。この検索パターンの入力であるが、１つの方法は、「ＰＣ」、「買う」、「た」と、個別入力することである。それに応じてシステムは、これらを順次つなぐ構造木を生成する。
別の方法は、「ＰＣ買った」と、一文を入力して、コンピュータ・システム側の構文解析により、検索用の構造木を生成することである。これらの場合、生成した構造木のノードをクリックすることにより、ピボットを指定する。
あるいは、「昨日、＿＿というＰＣを買った。」のような文章からクエリを生成し、「＿＿」の部分のトップＮを、コーパス上の頻度を用いて計算する自動応答システム等のインターフェースも考えられる。
検索部１、検索部２の目的は、上記検索パターンにマッチする箇所として、以下に示すような強調表示ノードを求め、その箇所におけるピボットの「買う」のノードの出現情報を取得することである。
図２４に戻って、検索によりヒットした、「ＰＣ」、「買う」、「た」に対応する文書中のノードを、検索パターン例と同様に強調表示した。このとき、文書２も、文書３も、「買う」ノードを含むが、「ＰＣ」も「た」も含まないため、文書２及び文書３では、どのノードも強調表示されていないことに留意されたい。
図２５を参照すると、検索部１では、π以外のノードの検索を行う。検索部１の処理が完了した時点で、π以外の出現情報は破棄したいため、π以外のノードである「ＰＣ」ノードだけでなく、その親ノードの「買う」も検索し、「買う」ノードが「ＰＣ」ノードの上位であるような出現箇所における「買う」ノードの出現情報のみを記憶しておく。
図２６は、検索部１の処理の終了時を示す。検索部１から呼び出された際、インデックス読取部２０８は、「買う」の出現情報：(1,2,5,2) (2,2,4,2) (3,2,4,2) (4,5,5,5) (4,12,12,5) (5,2,8,2) (6,2,6,2)と、「ＰＣ」の出現情報：(1,4,1,4) (3,5,2,4) (4,7,1,7) (4,14,8,7) (5,9,6,4) (6,4,1,4)を、メモリ１０６に読み込む。
上位下位判定部１３１０は、「買う」の出現情報と、「ＰＣ」の出現情報の間で、ペアをみつける。この結果、「買う」の(1,2,5,2)と「ＰＣ」の(1,4,1,4)、「買う」(3,2,4,2)のと「ＰＣ」の(3,5,2,4)、「買う」の(4,5,5,5)と「ＰＣ」の(4,7,1,7)、「買う」の(4,12,12,5)と「ＰＣ」の(4,14,8,7)、「買う」の(5,2,8,2)と「ＰＣ」の(5,9,6,4)、「買う」の(6,2,6,2)と「ＰＣ」の(6,4,1,4)が、それぞれマッチするが、「買う」の(2,2,4,2)は、マッチする相手が見つからず、捨てられる。これは、文書２の「買う」に対応している。
検索部２では、検索パターンの全ノードの出現情報を上から順に検索し、検索パターンにマッチするパターンに限った「買う」ノードの出現情報を計算する。検索部１の段階では、文書３も「ＰＣ」と「買う」にマッチしていたが、図２７に示すように、検索部２の段階では、「た」ノードを、「買う」ノードの上位にもたないため、文書３での出現情報は、破棄される。
図２８には、トップＮ計算部１３０８の処理を示す図である。ノード・アレイ・ファイル４０４の出現情報を、出現文書数の多い単語の順で読み込む。この場合、出現文書数の多い単語の順とは、下記のとおりである。
「買う」６件
「を」、「ＰＣ」、「た」 ５件
「で」、「店」 ４件
「今日」 ２件
「電池」、「通販」、「か」、「の」、「昨日」、「渋谷」、「その」、「は」、「その」 １件
ここでは、図示されているように、「買う」というノードがハイライトされており、よって、「買う」というノードの下位のノードで、depth差がd以内のノードが、上位下位判定部１３１０で調べられる。ここでは、図示されているように、d=3とする。すると、図２８の囲みで示されているように、「買う」０件、「を」３件、「ＰＣ」４件、「た」０件、「で」４件、「店」４件、と計算される。
この時点で、暫定トップＮが「ＰＣ」４件、「で」４件、「店」４件、「を」３件だが、未読の最多ワード「今日」が２件で、暫定最下位の「を」よりも出現文書数が少ないため、ここで終了となる。
上記実施例は、日本語の例で説明したが、英語その他の印欧語、韓国語、中国語、トルコ語、アラビア語等でも、適当な構文解析システムにより、構造木に振り分けることができるので、本発明は、日本語以外の任意の言語で記述された文書の検索に適用可能であることを、この分野の当業者なら、理解するであろう。
本発明を実施するためのハードウェアの概要ブロック図である。 本発明を実施するための論理構成の概要ブロック図である。 文書の構造木を示す図である。 ランク・ファイルと、ノード・アレイ・ファイルを示す図である。 ランク・ファイルと、ノード・アレイ・ファイルを作成するための処理を示すフローチャートである。 ランク・ファイルと、ノード・アレイ・ファイルを作成するための処理を示すフローチャートである。 構造木と、preorder及びpostorderの関係を示す図である。 構造木のノードに、preorderを付与する処理を示すフローチャートである。 構造木のノードに、postorderを付与する処理を示すフローチャートである。 構造木のノードに、depthを付与する処理を示すフローチャートである。 構造木と検索パターンの関係を示す図である。 検索結果におけるピボットに関連するキーワードを示す図である。 検索処理のための論理構成の概要ブロック図である。 検索処理の概要フローチャートを示す図である。 インデックス読取部が、検索部１／検索部２から呼び出される処理を示すフローチャートである。 インデックス読取部が、トップＮ計算部から呼び出される場合の処理を示すフローチャートである。 検索部１の処理を示すフローチャートである。 検索部２の処理を示すフローチャートである。 言い換え表現を含む箇所を複合ノードで置き換えることを説明する図である。 複合ノード検索パターンのオブジェクト構造を示す図である。 従来技術と、本発明の、パターン作成と検索処理に関する処理の比較を示す図である。 テキストデータの構造木の例を示す図である。 テキストデータの構造木の、インデックスにおける内部状態を説明するための図である。 テキストデータの構造木に対する、クエリと検索部の概要を説明するための図である。 テキストデータの構造木に対する、検索部１の処理を説明するための図である。 テキストデータの構造木に対する、検索部１の処理終了時の内部状態を説明するための図である。 テキストデータの構造木に対する、検索部２の内部状態を示す図である。 テキストデータの構造木に対する、トップＮ計算部の処理を示す図である。

Claims (21)

  1. コンピュータにより、各々に固有の文書ＩＤが付与された複数の文書データからなるデータベースを検索するシステムであって、
    前記複数の文書データが格納される記憶装置と、
    前記複数の個々の文書データを、ルート・ノードから始まる構文解析により構造木の形式であらわした場合に、該文書データに含まれる単語毎に、該単語が含まれる文書データの文書ＩＤと、該ルート・ノードから順方向に辿った順番である第１の順番と、該構造木の末端ノードから前記ルート・ノードへ逆方向に辿った順番である第２の順番を含む出現情報を前記記憶装置に格納したインデックス格納手段と、
    少なくとも２つの検索すべき単語の情報を受領する受領手段と、
    前記受領した単語毎の前記出現情報を、前記インデックス格納手段から読み取る読取手段と、
    前記受領した単語のうちの第１の単語の出現情報と、前記受領した単語のうちの第２の単語の出現情報を比較して、それらの間で、文書ＩＤが一致し、且つ前記第１の順番が他方より小さく、且つ前記第２の順番が他方より大きい、一方の出現情報の文書ＩＤを検索する検索手段とを有する、
    情報検索システム。
  2. 前記出現情報は、各単語ＩＤ毎に、出現頻度の降順でソートされて、その順でリストされている、請求項１の情報検索システム。
  3. 前記出現情報が、前記ルート・ノードからの深さの情報をさらに含み、前記検索手段は、前記比較した出現情報の深さの差が所定値以下であるときのみ、前記出現情報の文書ＩＤを返す、請求項１の情報検索システム。
  4. 少なくとも１つの基点のノードの単語を指定する指定手段と、
    該基点のノードの単語の前記出現情報を、前記インデックス格納手段から読み取り、該基点の単語の前記出現情報に関して、文書ＩＤが同一で、且つ前記第１の順番がより大きく、且つ前記第２の順番がより小さく、深さの差が所定値以下である出現情報をもつ単語をリストする手段をさらに有する、請求項３の情報検索システム。
  5. 前記単語のリストは、該単語の、該当する出現情報の頻度順にリストされる、請求項４の情報検索システム。
  6. 記憶装置をもつコンピュータにより、各々に固有の文書ＩＤが付与された複数の文書データからなるデータベースを検索する方法であって、
    前記個々の複数の文書データを、構文解析により、ルート・ノードから始まる構造木の形式で、前記記憶装置に格納するステップと、
    前記個々の複数の文書データを、ルート・ノードから始まる構文解析により構造木の形式であらわした場合に、該文書データに含まれる単語毎に、該単語が含まれる文書データの文書ＩＤと、該ルート・ノードから順方向に辿った順番である第１の順番と、該構造木の末端ノードから前記ルート・ノードへ逆方向に辿った順番である第２の順番を含む出現情報を前記記憶装置に格納するステップと、
    少なくとも２つの検索すべき単語の情報を受領するステップと、
    前記受領した単語毎の前記出現情報を、前記記憶装置から読み取るステップと、
    前記受領した単語のうちの第１の単語の出現情報と、前記受領した単語のうちの第２の単語の出現情報を比較して、それらの間で、文書ＩＤが一致し、且つ前記第１の順番が他方より小さく、且つ前記第２の順番が他方より大きい、一方の出現情報の文書ＩＤを検索するステップとを有する、
    情報検索方法。
  7. 前記出現情報は、各単語ＩＤ毎に、出現頻度の降順でソートされて、その順でリストされている、請求項６の情報検索方法。
  8. 前記出現情報が、前記ルート・ノードからの深さの情報をさらに含み、前記検索手段は、前記比較した出現情報の深さの差が所定値以下であるときのみ、前記出現情報の文書ＩＤを返す、請求項６の情報検索方法。
  9. 少なくとも１つの基点のノードの単語を指定する指定手段と、
    該基点の単語の前記出現情報を、前記記憶装置から読み取り、該基点のノードの単語の前記出現情報に関して、文書ＩＤが同一で、且つ前記第１の順番がより大きく、且つ前記第２の順番がより小さく、深さの差が所定値以下である出現情報をもつ単語をリストするステップをさらに有する、請求項８の情報検索方法。
  10. 前記単語のリストは、該単語の、該当する出現情報の頻度順にリストされる、請求項９の情報検索方法。
  11. 記憶装置をもつコンピュータにより、各々に固有の文書ＩＤが付与された複数の文書データからなるデータベースを検索するプログラムであって、
    前記コンピュータをして、
    前記個々の複数の文書データを、構文解析により、ルート・ノードから始まる構造木の形式で、前記記憶装置に格納するステップと、
    前記個々の複数の文書データを、ルート・ノードから始まる構文解析により構造木の形式であらわした場合に、該文書データに含まれる単語毎に、該単語が含まれる文書データの文書ＩＤと、該ルート・ノードから順方向に辿った順番である第１の順番と、該構造木の末端ノードから前記ルート・ノードへ逆方向に辿った順番である第２の順番を含む出現情報を前記記憶装置に格納するステップと、
    少なくとも２つの検索すべき単語の情報を受理するステップと、
    前記受領した単語毎の前記出現情報を、前記記憶装置から読み取るステップと、
    前記受領した単語のうちの第１の単語の出現情報と、前記受領した単語のうちの第２の単語の出現情報を比較して、それらの間で、文書ＩＤが一致し、且つ前記第１の順番が他方より小さく、且つ前記第２の順番が他方より大きい、一方の出現情報の文書ＩＤを検索するステップを実行させる、
    情報検索プログラム。
  12. 前記出現情報は、各単語ＩＤ毎に、出現頻度の降順でソートされて、その順でリストされている、請求項１１の情報検索プログラム。
  13. 前記出現情報が、前記ルート・ノードからの深さの情報をさらに含み、前記検索手段は、前記比較した出現情報の深さの差が所定値以下であるときのみ、前記出現情報の文書ＩＤを返す、請求項１１の情報検索プログラム。
  14. 少なくとも１つの基点のノードの単語を指定する指定手段と、
    該基点の単語の前記出現情報を、前記インデックス格納手段から読み取り、該基点の単語の前記出現情報に関して、文書ＩＤが同一で、且つ前記第１の順番がより大きく、且つ前記第２の順番がより小さく、深さの差が所定値以下である出現情報をもつ単語をリストするステップをさらに有する、請求項１３の情報検索プログラム。
  15. 前記単語のリストは、該単語の、該当する出現情報の頻度順にリストされる、請求項１４の情報検索プログラム。
  16. 記憶装置をもつコンピュータにより、各々に固有の文書ＩＤが付与された複数の文書データからなるデータベースを検索するための、インデックス作成方法であって、
    前記個々の複数の文書データを、構文解析により、ルート・ノードから始まる構造木の形式で、前記記憶装置に格納するステップと、
    前記個々の複数の文書データを、ルート・ノードから始まる構文解析により構造木の形式であらわした場合に、該文書データに含まれる単語毎に、該単語が含まれる文書データの文書ＩＤと、該ルート・ノードから順方向に辿った順番である第１の順番と、該構造木の末端ノードから前記ルート・ノードへ逆方向に辿った順番である第２の順番を含む出現情報を前記記憶装置に格納するステップとを有する、
    データベースのインデックス作成方法。
  17. 前記出現情報は、各単語ＩＤ毎に、出現頻度の降順でソートされて、その順でリストされている、請求項１６のインデックス作成方法。
  18. 前記出現情報が、前記ルート・ノードからの深さの情報をさらに含む、請求項１６のインデックス作成方法。。
  19. 記憶装置をもつコンピュータにより、各々に固有の文書ＩＤが付与された複数の文書データからなるデータベースを検索するための、インデックス作成用プログラムであって、
    前記個々の複数の文書データを、構文解析により、ルート・ノードから始まる構造木の形式で、前記記憶装置に格納するステップと、
    前記個々の複数の文書データを、ルート・ノードから始まる構文解析により構造木の形式であらわした場合に、該文書データに含まれる単語毎に、該単語が含まれる文書データの文書ＩＤと、該ルート・ノードから順方向に辿った順番である第１の順番と、該構造木の末端ノードから前記ルート・ノードへ逆方向に辿った順番である第２の順番を含む出現情報を前記記憶装置に格納するステップとを有する、
    データベースのインデックス作成用プログラム。
  20. 前記出現情報は、各単語ＩＤ毎に、出現頻度の降順でソートされて、その順でリストされている、請求項１９のプログラム。
  21. 前記出現情報が、前記ルート・ノードからの深さの情報をさらに含む、請求項１９のプログラム。
JP2008051871A 2008-03-03 2008-03-03 情報検索システム、方法及びプログラム Expired - Fee Related JP5038939B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008051871A JP5038939B2 (ja) 2008-03-03 2008-03-03 情報検索システム、方法及びプログラム
US12/396,876 US8171052B2 (en) 2008-03-03 2009-03-03 Information search system, method and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008051871A JP5038939B2 (ja) 2008-03-03 2008-03-03 情報検索システム、方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2009211263A JP2009211263A (ja) 2009-09-17
JP5038939B2 true JP5038939B2 (ja) 2012-10-03

Family

ID=41013927

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008051871A Expired - Fee Related JP5038939B2 (ja) 2008-03-03 2008-03-03 情報検索システム、方法及びプログラム

Country Status (2)

Country Link
US (1) US8171052B2 (ja)
JP (1) JP5038939B2 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8375061B2 (en) * 2010-06-08 2013-02-12 International Business Machines Corporation Graphical models for representing text documents for computer analysis
JP2012212422A (ja) * 2011-03-24 2012-11-01 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
US8990175B2 (en) 2012-02-07 2015-03-24 Dassault Systemes Americas Corp. Related data dependencies
JP5921379B2 (ja) * 2012-08-10 2016-05-24 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ テキスト処理方法、システム及びコンピュータ・プログラム。
DE102013003055A1 (de) * 2013-02-18 2014-08-21 Nadine Sina Kurz Verfahren und Vorrichtung zum Durchführen von Suchen in natürlicher Sprache
CN103530067B (zh) * 2013-10-09 2017-06-09 华为技术有限公司 一种数据操作的方法和设备
CN104679778B (zh) * 2013-11-29 2019-03-26 腾讯科技（深圳）有限公司 一种搜索结果的生成方法及装置
US9836529B2 (en) * 2014-09-22 2017-12-05 Oracle International Corporation Semantic text search
CN104484481B (zh) * 2014-12-26 2018-01-02 上海携程商务有限公司 票务订单的数据匹配方法、装置及系统
CN105991671A (zh) * 2015-01-28 2016-10-05 中兴通讯股份有限公司 一种存储文件的方法和服务器
US10423623B2 (en) * 2015-02-05 2019-09-24 Sap Se Hierarchy modeling and query
SG10201503755QA (en) * 2015-05-13 2016-12-29 Dataesp Private Ltd Searching large data space for statistically significant patterns
CN106940675B (zh) * 2016-01-05 2020-05-19 佛山市顺德区顺达电脑厂有限公司 系统日志查询方法
US10528661B2 (en) * 2016-02-11 2020-01-07 International Business Machines Corporation Evaluating parse trees in linguistic analysis
CN111666753B (zh) * 2020-05-11 2023-04-18 清华大学深圳国际研究生院 基于全局和局部匹配的短文本匹配方法及系统
CN114491164B (zh) * 2022-01-17 2022-12-09 广州市玄武无线科技股份有限公司 一种树形数据处理方法及系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2768921B2 (ja) * 1994-09-13 1998-06-25 株式会社東芝 データ検索装置、データ処理装置、データ検索方法及びデータ処理方法
JP3353829B2 (ja) * 1999-08-26 2002-12-03 インターナショナル・ビジネス・マシーンズ・コーポレーション 膨大な文書データからの知識抽出方法、その装置及び媒体
JP2001134575A (ja) 1999-10-29 2001-05-18 Internatl Business Mach Corp <Ibm> 頻出パターン検出方法およびシステム
US7114123B2 (en) 2001-02-14 2006-09-26 International Business Machines Corporation User controllable data grouping in structural document translation
JP4332356B2 (ja) * 2003-01-22 2009-09-16 キヤノン株式会社 情報検索装置及び方法並びに制御プログラム
JP2005284723A (ja) * 2004-03-30 2005-10-13 Fuji Xerox Co Ltd 自然言語処理システム及び自然言語処理方法、並びにコンピュータ・プログラム
JP2005352817A (ja) * 2004-06-11 2005-12-22 Fuji Xerox Co Ltd 情報処理システム及び情報処理方法、並びにコンピュータ・プログラム
US7533088B2 (en) * 2005-05-04 2009-05-12 Microsoft Corporation Database reverse query matching
JP4489029B2 (ja) * 2006-02-01 2010-06-23 株式会社東芝 構造化文書検索システムおよび構造化文書検索方法
JP2007317139A (ja) 2006-05-29 2007-12-06 Fuji Xerox Co Ltd 文書データ解析装置および方法

Also Published As

Publication number Publication date
US8171052B2 (en) 2012-05-01
JP2009211263A (ja) 2009-09-17
US20090222407A1 (en) 2009-09-03

Similar Documents

Publication Publication Date Title
JP5038939B2 (ja) 情報検索システム、方法及びプログラム
JP5376163B2 (ja) 文書管理・検索システムおよび文書の管理・検索方法
US7516125B2 (en) Processor for fast contextual searching
US7809551B2 (en) Concept matching system
US9519706B2 (en) Multiple rule development support for text analytics
US8135717B2 (en) Processor for fast contextual matching
US8781817B2 (en) Phrase based document clustering with automatic phrase extraction
EP0378848A2 (en) Method for use of morphological information to cross reference keywords used for information retrieval
JPH11120203A (ja) データベースを合併する方法およびデータベースからドキュメントを検索する装置
US7024405B2 (en) Method and apparatus for improved internet searching
JPH0844771A (ja) 情報検索装置
US7949656B2 (en) Information augmentation method
JP2005242416A (ja) 自然言語文の検索方法および検索装置
US10572592B2 (en) Method, device, and computer program for providing a definition or a translation of a word belonging to a sentence as a function of neighbouring words and of databases
JP4378106B2 (ja) 文書検索装置、文書検索方法及びプログラム
KR100659370B1 (ko) 시소러스 매칭에 의한 문서 ｄｂ 형성 방법 및 정보검색방법
JP2007133682A (ja) 全文検索システム、及び、その全文検索方法
Dhanapal An intelligent information retrieval agent
JP2000003366A (ja) 文書登録方法と文書検索方法及びその実施装置並びにその処理プログラムを記録した媒体
JPH08190571A (ja) 文書検索方法
JPH0612451A (ja) 例文検索システム
Wouda Similarity between Index Expressions
JPH03229367A (ja) テキストベース検索方式
JP2006163723A (ja) ドキュメント検索方法
JP2006018584A (ja) 構造化文書管理システム、値索引生成方法及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101027

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120531

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120612

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120706

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150713

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees