Lucene および Solr での見つけやすさの最適化

読者の方々が私と同じであれば、子供の頃、ウェブ サイトまたはハードディスク内のテキストおよびデータの検索を向上させる仕事をするようになるなんて思いもしなかったでしょう。さらに言えば、大学に入って計算機工学を専攻しているときでも、そんなことは考えつきもしなかったでしょう。それなのに現実には、コンテンツを検索する必要があるプロジェクトに携わっており、その方法を模索してます。あるいは、既に検索できるようにはなっているものの、テストの結果やプログラミングで培った直感から、もっと優れた検索を実現できると感じてらっしゃるのかもしれません。ひどい場合には、上司、QA 部門、CEO、あるいは、お客様から、検索機能を改善するように求められている方もいらっしゃるでしょう。あれやこれやで、皆様は見つけやすさの問題を抱えていて、どうしたらよいのか分からない状態にあるということです。結局のところ、検索ライブラリーがうまく機能すればよいのですよね?

ルーシッド・イマジネーションの最近のお客様を例にとってみましょう。このお客様は誰でも知っている会社であり、Lucene を使用してオンライン・ストアを構築していました。このオンライン・ストアでは、1 日に何百万もの要求を処理しており、非常に高度な分析を使用して、購入につながった検索のコンバージョンを追跡していました。残念なことに、ベストセラー製品の 1 つ (ここでは、「ウィジェット X」と呼ぶことにします) に、見つけやすさの問題が生じていました。ユーザーが検索ボックスに「ウィジェット X」と入力すると、ウィジェット X に関係するあらゆる項目が表示されるのですが、ウィジェット X 自体が表示されるのは検索結果の 12 ページ目だったのです。言うまでもなく、ウィジェット X は他の流通経路でベストセラーであるため、これはかなりの利益を失っていることを意味しました。分析を行い、再現率の向上に関する私の記事のヒントをいくつか試した後に、ウィジェット X の検索対象の主フィールドの 1 つが空になっていることが分かりました。この問題をデータ入力システムまで追跡して修正を施し、次のサイト更新時にこの問題を解決しました。これで、ウィジェット X の問題は解決しました。

データベースなどのほとんどのツールは、非構造化コンテンツの検索に対応していることになっていますが、ほとんどのツールは問題に対して画一的な手法を使用するため、検索結果で問題が生じます。実際、Lucene のような検索ライブラリーはデフォルトのままでかなりの機能を実現しますが、検索機能をさらに向上させるために開発者および対象分野の専門家ができることもたくさんあります。

まず、既存のプロジェクトを修正するのではなく、新規プロジェクトを開始する場合には幸運です。優れた要件の収集、設計および仕様作成は、時代が変わっても大事なスッテプです。そのため、時間をかけてコンテンツ検索方法の計画を立てれば、確実に成功することができます。もちろん、一から開始しなくても、少し手間がかかるかもしれませんが、ここで説明するほとんどのテクニックはうまくいくでしょう。

よく見過ごされますが、「クリーンな」データの価値を過小評価しないでください。データベースおよび純粋なテキストを処理する際にも当てはまりますが、Microsoft Word や Adobe PDF などの一般的なオフィス文書を処理する際には特に当てはまります。例えば、ほとんどの科学論文の標準スタイルでは段組が使用されますが、抽出プログラムの多くは段組を適切に処理しないため、文が段組を超えてつながっているかのようになっているコンテンツを返します。他にも、形式が正しくないファイル、OCR で抽出されたスキャン・テキスト、言語混合テキスト、識別子の不足などの問題があります。これらの問題のほとんどは、プロセスのかなり初期段階で捕捉されますが、OCR データや言語混合テキストなどの一部の問題では、解決するために少し余分に時間が必要になるか、少なくとも回避策が必要になります。

幸運な場合は、不適切なデータのコストは、文書エラーという形で索引付け時に表れます (このエラーは適切に回復できます)。しかし、エラーにならずにプロセスが終了して、検索結果が不適切になったり、検索結果がなくなったりする場合もあります。このような場合には、ログを監視して、適合性テスト を忠実に実行し、正しくない文書を追跡および修正するしかありません。

最後に、コンピューター・フォレンジックなどの一部のフィールドでは、データの処理は元々困難です。このような状況では、できることを最大限実行して、寄せ集めのデータから価値を引き出せればと、代替アプローチを辛抱強く試行します。どのような場合でも、状況を改善できる分析およびクエリーのテクニックが存在します。次に続く3つの節では、見つけやすさを向上させる多くの一般的な IR テクニックの概要を説明します。

長年にわたって、検索プロセスで Lucene が「解析」(analysis)と呼んでいるものの役割に関する多くの研究がなされてきました。学術機関では、基本的出力、大/小文字の区別、句および固有表現などの抽出の使用、N グラム、その他の多くのテクニックに関して研究を行ってきました。これらのテクニックについては簡潔に説明します。これらのテクニックの中には、検索を大幅に改善するものもあれば、ほとんどのユーザーが気づくことのない非常に小さな改善をひねり出すものもあります。本当に役立つものに焦点を合わせたいと思いますが、状況によって異なることも理解しています。すべてのテクニックがすべての状況で役立つわけではありません。実際、悪影響を及ぼす場合もあります。

要約すると、Lucene では解析は、入力文字列をトークンに変換するプロセスです。トークンはその後索引付けされて検索可能な状態にされます。例えば、解析は以下の文の変換を行います。

この文を以下のトークンに分割します。

Lucene (なお、Solr も Lucene の解析プロセスを共有します) での解析の選択は、システムが返す検索結果の精度に非常に大きな影響を与えます。また、他の画一的なシステムとは異なり、Lucene では必要に応じてプロセスを直接制御できます。

以下に示す表で、長年の研究によって、全体的に検索を改善することが示されている、多くの一般的なテクニックについて詳しく説明します。

これらのテクニックのいくつかを単一および複数のフィールドで使用するのが、一般的です。例えば、あるフィールドを小文字にして基本形出力し、別のフィールドは小文字に変換するだけで、さらに別のフィールドはトークン分割するだけといったようになります。

より良いクエリーを構築する方法の説明に進む前に、基本形出力はもう少し説明する必要のある重要な解析テクニックであるため、基本形出力について少々詳しく説明します。

ここまで、コンテンツ面に焦点を合わせてきましたが、見つけやすさについて考える際には、クエリーの作成方法について検討することも同じくらい重要です。クエリーの面では、少なくとも 2 つのタイプのクエリーについて説明する必要があります。ユーザーが入力するクエリーとシステムに実行依頼される実際のクエリーです。それというのも、ほとんどのシステムでは通常、システムのデフォルト、ユーザーが選択したオプション、および元のクエリーの構文解析結果に基づいて、ユーザーのクエリーを変更するからです。ユーザー・レベルで検索結果を向上させるには、教育と誘導が重要です。単純な例および価値の高い資料を用意することで、サポートされる構文についてユーザーを教育してください。サジェスチョンなどのツールや入力を処理する方法から推測を行うオプションを用意することで、より良いクエリーを実行依頼するように促してください。

残念なことに、ユーザーの教育と誘導ではこの程度までしかできません。関連性を向上させるには、以下の推奨事項の 1 つ以上を採用することを検討してください。

もちろん、ここまでで説明した解析テクニックの多くは、コンテンツのみに固有のものではありません。一般的に、解析プロセスは、索引付けと検索で同じものである必要があるため、アプリケーションの作成時にはそのことを念頭に置いてください。次に、表示とナビゲーションに関する考え方について簡単に説明してから、結論と関連資料を示して記事を締めくくります。

ここまで、解析からクエリーの構築に至るまで、たくさんのことを説明しました。見つけやすさという難しいジグソーパズルの最後の大きなピースは、ナビゲーションです。ナビゲーションを強化する方法はたくさんありますが、ここでは Solr および Lucene を使用してできることに焦点を絞ります。

近年、多くのオンライン・ストアでファセット処理が注目を集めています。ファセット処理は、結果セット・データから求めた制限された選択肢セットをユーザーに用意するというテクニックです。ユーザーは、この選択肢セットからクエリーを絞り込むことができます。ここで重要なことは、すべての選択肢で有効な検索結果が得られるということです。ファセット処理された表示では多くの場合、各ファセット内の文書数も示されます。例えば、CNet Shopper (Solr ベース) のサイトでは、ファセット処理を広く使用しています。一例として、ファセット処理の例を参照してください。当然、固有表現や句などの解析時に抽出した有益な情報はすべて、優れたファセットに結びつきます。現在、Solr でのファセット処理はデフォルトのままでも使用できますが、Lucene でカスタマイズすることもできます。ファセット処理の詳細については、Yonik Seeley の記事を参照してください。

図 1. ファセット処理の例

CNet Shopper (http://shopper.cnet.com) では、この例のように、検索結果でファセット処理を広く使用しています。

ファセット処理に加えて、数は大分減りますが、他の集約テクニックもよく使用されます。文書と検索結果のクラスタリングはともに適切な状況では役立ちます。たくさんの関連文書を単一のクラスターにまとめて、代表的な結果を選択できます。Solr では、Carrot2 クラスタリング・プロジェクト (検索結果ベース) のサポートを追加する準備段階の (つまり、コミットされていない) 作業が進行しています。また、Apache Mahout で、多くのクラスタリング・アルゴリズムを利用できます。詳細については、SOLR-769 を参照してください。

その他の有益なナビゲーション・テクニックには、「More Like This」(類似検索)、代替ソート・オプション、フィルタリング・オプション、「もしかして」(サジェスチョン) 機能などがあります。「More Like This」では、ユーザーは一致性の高い文書を選択して、その文書に類似した文書を求めることができます。「もしかして」(サジェスチョン) 機能では、コレクション内で頻度がより高い用語のスペリングのサジェスチョンを提供することで、多くの場合、ユーザーはより良い検索結果を得ることができます。ソートについては、新しい文書順に表示したい場合もあれば、まだ表示していない文書を先に表示したい場合もあるでしょう。同様に、ユーザーがフィルタリング情報 (日付、価格範囲、作者など) を指定することで前もって結果セットを制限できれば、返す結果セットの数を減らすことができるため、閲覧しやすくなります。最後に、ハイライト機能を使用することで、少なくとも、文書内のクエリーに関連した部分にユーザーの目を直接引き付けることができます。

もっと深いレベル、つまり専門家レベルについてはここまであまり触れてきませんでしたが、Lucene の Similarity クラスをカスタム設定でオーバーライドすることもできます。特に、Lucene で全体として検索結果で短い文書または長い文書が優先される傾向が見られた場合に、長さの正規化係数を変更できます。さらに、独自のスコアリング機能を備えた自作の Query クラスを実装することもできます。実際、Lucene のクエリー・クラスの多くはユーザーが作成したものです。コントリビュートすることもぜひ考えてください。自作のクラスを作成する場合には、Lucene のソースを確認して、進め方の例を調べてください。また、適切なメーリング・リストでどんどん質問してください。

最後に、検索ではほとんどのものがそうですが、見つけやすさも、一度完成させれば放置してよいものではありません。検索アプリケーションの定期的なチェックをスケジュールに入れて、期待どおりのパフォーマンスを発揮しているかを確認することをお勧めします。多くの場合、新しい文書が追加されて索引が増大するにつれて、検索結果に影響するコレクション統計が変化して、以前とは異なる結果が生成されるようになるため、アプリケーションをチューニングする必要が生じることがあります。

この記事では、Lucene と Solr を使用してコンテンツの見つけやすさを強化する方法に関する多くのトピックについて触れました。コンテンツ、ユーザー、および解析プロセスをより深く把握するための方法についても述べました。さらに、より良いクエリーを作成するためのヒントおよびテクニックについても触れました。この記事が、まずは検索可能性を高める方法を深く考えて、それから Lucene と Solr でその方法を活用する方法を考えることで、より優れた検索システムの作成方法について理解する一助となれば幸いです。最後に、この記事の末尾に記載したアドレスに、アプリケーションの関連性を向上させた方法についてのコメントを気兼ねなくお送りください。

以下の資料により、見つけやすさおよび Lucene と Solr を活用してアプリケーションを向上させる方法の詳細を学習できます。

日本語訳著作権 © 2010 Basis Technology Corp. 原文著作権 © 2010 Lucid Imagination. All Right Reserved.