統合検索

フェデレーション検索は、 1 つ以上の検索エンジン上に構築された検索アプリケーションを介して、さまざまなソースから情報を取得します。^[1]ユーザーは単一のクエリ要求を作成し、それがフェデレーションに参加している検索エンジン、データベース、またはその他のクエリ エンジンに配信されます。フェデレーション検索は、検索エンジンから受信した結果を集約してユーザーに提示します。フェデレーション検索は、単一の大規模組織 (「エンタープライズ」) 内または Web 全体のさまざまな情報リソースを統合するために使用できます。

フェデレーション検索は、分散検索とは異なり、検索可能なリソースの集中的な調整を必要とします。これには、個々の検索エンジンに送信されるクエリの調整と、各検索エンジンから返される検索結果の融合の両方が含まれます。

フェデレーション検索は、1 つのクエリで複数の異なるコンテンツ ソースを検索するというニーズを満たすために生まれました。これにより、ユーザーは複数のデータベースをリアルタイムで同時に検索し、さまざまなデータベースからの結果を使いやすい形式に整理して、ユーザーに結果を提示することができます。

したがって、これは情報の集約または統合アプローチであり、多くの情報リソースへの単一ポイント アクセスを提供し、通常は標準形式または部分的に均質化された形式でデータを返します。その他のアプローチには、エンタープライズ データ ウェアハウス、データ レイク、またはデータ ハブの構築が含まれます。フェデレーション検索では、さまざまな方法で何度もクエリを実行します (各ソースは個別にクエリされます)。一方、他のアプローチでは、通常は夜間のバッチ プロセスで、何度もデータをインポートして変換します。フェデレーション検索では、すべてのソース (すべてがオンラインで使用可能である場合) のリアルタイム ビューが提供されます。

LinkedInなどの産業用検索エンジンでは、あいまいなクエリの垂直的な優先順位をパーソナライズするためにフェデレーション検索が使用されています。^[2]たとえば、ユーザーがLinkedInで「機械学習」などのクエリを発行する場合、機械学習のスキルを持つ人、機械学習のスキルを必要とする仕事、またはそのトピックに関するコンテンツを検索しようとしている可能性があります。このような場合、フェデレーション検索はユーザーの意図（雇用、求職、コンテンツの消費など）を利用して、各ユーザーの垂直的な順序をパーソナライズできます。

Peter Jacso (2004 ^[3] ) が説明しているように、統合検索は、(1)クエリを変換し、適切な構文を使用して、異なるデータベースまたはその他の Web リソースのグループにブロードキャストし、(2) データベースから収集された結果をマージし、(3) 重複を最小限に抑えて簡潔で統一された形式で結果を提示し、(4) 自動的にまたはポータルユーザーによって実行される、マージされた結果セットを並べ替える手段を提供することから構成されます。

統合検索ポータルは、商用またはオープン アクセスを問わず、一般に、パブリック アクセスの書誌データベース、パブリック アクセスの Web ベース図書館カタログ ( OPAC )、 Googleなどの Web ベース検索エンジン、および/またはオープン アクセスの政府運営または企業のデータ コレクションを検索します。これらの個々の情報ソースは、検索クエリの結果のリストをポータルのインターフェイスに送り返します。ユーザーはこのヒット リストを確認できます。一部のポータルは、実際のデータベース結果をスクリーン スクレイピングするだけで、ユーザーが情報ソースのアプリケーションに直接入力することはできません。より高度なポータルでは、重複を結合および削除して結果リストの重複を排除します。多くのポータルで使用できる追加機能がありますが、基本的な考え方は同じです。つまり、個々の検索の精度と関連性を向上させ、リソースの検索に必要な時間を短縮することです。

このプロセスにより、既存のクローラーベースの検索エンジンと比較して、統合検索にはいくつかの重要な利点があります。統合検索では、トラフィックの増加を処理すること以外に、個々の情報ソースの所有者に要件や負担を課す必要はありません。統合検索は、個々の情報ソースがリアルタイムで検索されるため、本質的に個々の情報ソースと同じくらい最新の状態です。

統合検索の 1 つのアプリケーションは、メタ検索エンジンです。ただし、メタ検索アプローチでは、不完全なインデックスなど、コンポーネント検索エンジンの欠点は克服されません。検索エンジンによってインデックス付けされていないドキュメントは、ディープ Webまたはインビジブル Web と呼ばれるものを作成します。Google Scholar は、検索エンジンが無視する電子ドキュメントをインデックス付けすることで、この問題に対処しようとしている多くのプロジェクトの一例です。また、メタ検索アプローチは、基礎となる検索エンジン技術と同様に、電子形式で保存されている情報ソースでのみ機能します。

メタ検索の主な課題の 1 つは、検索クエリが、統合および結合されているコンポーネント検索エンジンと互換性があることを保証することです。検索システムの検索語彙またはデータ モデルが、 1 つ以上の外部ターゲット システムのデータ モデルと異なる場合、クエリを各外部ターゲット システムに変換する必要があります。これは、単純なデータ要素変換を使用して実行できますが、セマンティック変換が必要になる場合もあります。たとえば、ある検索エンジンでは正確な文字列または n-gram の引用が許可されているのに、別の検索エンジンでは許可されていない場合、クエリは各検索エンジンと互換性があるように変換する必要があります。引用された正確な文字列クエリを変換するには、各検索エンジンで目的の検索結果が得られる可能性が最も高い、重複するn-gramのセットに分割できます。

統合検索エンジンの実装で直面するもう 1 つの課題は、スケーラビリティです。統合検索エンジンは、ますます多くの情報ソースを組み合わせるため、パフォーマンス、応答速度を維持することが困難になります。この問題に対処し始めた統合検索の実装の 1 つが、米国エネルギー省の科学技術情報局がホストするWorldWideScienceです。WorldWideScience ^{[4] は}40 を超える情報ソースで構成されており、そのうちのいくつかは統合検索ポータルです。そのようなポータルの 1 つが Science.gov ^[5]で、それ自体が米国連邦政府の R&D 成果のほとんどを代表する 30 を超える情報ソースを統合しています。Science.gov は最もランクの高い結果を WorldWideScience に返し、WorldWideScience はこれらの結果を WorldWideScience を構成する他の情報ソースから返された検索とマージしてランク付けします。^[5]このカスケード統合検索のアプローチにより、1 つのクエリで多数の情報ソースを検索できます。

ノルウェーとスウェーデンで稼働している別のアプリケーションであるSesamは、フェデレーテッド検索ソリューションに特化したオープンソースプラットフォーム上に構築されています。Sesat ^[6]は、 Sesam Search Application Toolkitの略で、並列検索とパイプライン検索の処理に必要なフレームワークと機能の多くを提供し、ユーザーインターフェイスでそれらをエレガントに表示するためのプラットフォームであり、エンジニアがインデックス/データベース構成の調整に集中できるようにします。

^{LinkedInの検索エンジン[2]}は、フェデレーテッド検索における垂直順序をパーソナライズするために、検索者のプロフィールと最近の活動を利用して、採用、求職、コンテンツの消費などの意図を推測し、その意図と他の多くのシグナルを使用して、個々の検索者に個人的に関連のある垂直順序をランク付けします。

SWIRL Search ^[7]は、Apache 2.0ライセンスの下でリリースされたオープンソースの連合検索エンジンです。人気のオープンソース検索エンジンへのコネクタがあらかじめ組み込まれており、コサインベクトル類似度を使用して結果を再ランク付けします。

従来の単一ソース検索と比較して、フェデレーション検索にはいくつかの重要な課題があります。

1. 資格証明書の交付

安全なデータソースに対してフェデレーション検索を実行する場合、適切なセキュリティが維持されるように、ユーザーの資格情報を各基盤検索エンジンに渡す必要があります。ユーザーがシステムごとに異なるログイン資格情報を持っている場合は、ログインIDを各検索エンジンのセキュリティドメインにマッピングする手段が必要です。^[8]

2. 結果リストナビゲーターを共通フォームにマッピングする

3 つの不動産サイトを検索すると、各サイトにはハイパーリンクされた都市名のリストがあり、クリックすると各都市の一致のみが表示されます。理想的には、これらのファセットを 1 つのセットにまとめますが、これには追加の技術的課題があります。^[9] ユーザーが統合された結果をページングできるようにするには、システムは「次のページ」リンクも理解する必要があります。

共通フォームへのマッピングに関するこの課題の一部は、連合リソースがRDFを介してリンクされたオープンデータをサポートしていれば解決できます。そのテクノロジーを使用して、結果を共通フォームにマッピングするためのオントロジー (ルール) を追加できます。

3. 結果の並べ替えと採点

各 Web リソースには、関連性スコアという独自の概念があり、並べ替えられた結果の順序がサポートされている場合があります。関連性は検索の「フェデレート」間で大きく異なるため、最も関連性の高い結果を表示するために結果をインターリーブする方法を知ることは困難または不可能です。

4. 堅牢なクエリ

フェデレーション検索は、すべてのフェデレーションに共通する最小限のクエリ機能セットに制限される可能性があります。たとえば、Google が否定や引用符付きのフレーズをサポートしているのに、science.gov がサポートしていない場合、フェデレーション検索で否定や引用符付きのフレーズをサポートすることは不可能になります。

5. 可用性とタイムアウト

フェデレート (フェデレーション ソース) の数が増えると、1 つ以上のフェデレートが低速またはオフラインになる可能性が高くなります。フェデレーション検索では、フェデレートをオフラインと見なすか、応答が遅いまで待機するかを決定する必要があります。応答時間は、最も遅いフェデレートによって決まります。

6. 企業内での開発とテスト（パブリックインターネット上ではなく）

開発グループは通常、通常の作業を行うため、実際の運用システムにアクセスすることはなく、集中的な負荷テストを行う必要もありません。また、一部のリソースはセキュリティ保護されており、プライバシーとセキュリティ上の懸念から、開発中に勝手にクエリしたり公開したりすべきではありません。したがって、開発、テスト、パフォーマンス テストの環境には、安全でセキュリティ保護されたテストを可能にするために、多くのサブシステムのインストールと構成が含まれている必要があります。

7. HA/DR（高可用性そして災害復旧）

フェデレーション システム全体を HA/DR にするには、すべてのサブシステムを HA/DR にする必要があります。

同様に、フェデレーション システムのパフォーマンス モデリングと容量計画には、すべてのフェデレーションのモデリング、計画、場合によっては拡張が必要になります。

上記のすべての理由から、企業内では、データ ハブまたはデータ レイク、あるいはハイブリッド アプローチが望ましい場合があります。データ ハブとデータ レイクは開発とアクセスを簡素化しますが、データが使用可能になるまでに多少のタイム ラグが発生する可能性があります (特別な同期ロジックがない場合)。Web では、フェデレーションがより一般的です。

• 検索アグリゲータ
• Z39.50

• フェデレーテッド検索 101。Linoski、Alexis、Walczyk、Tine、Library Journal、2008 年夏季 Net Connect、Vol. 133。このコンテンツはここに移動されましたが、記事全体を取得するには、ローカル ライブラリを介したリモート アクセス アカウントが必要になります。
• Cox, Christopher N. Federated Search: オンライン ライブラリ サービスの解決策か後退か。ニューヨーク州ビンガムトン: Haworth Information Press、2007 年。目次
• フェデレーテッド検索入門。Lederman, S.、AltSearchEngines、2009 年 1 月。この資料は、 Wayback Machineの商用検索エンジン会社のブログに2019-11-14 アーカイブされて再投稿されています。
• Si, Luo; Shokouhi, Milad (2011). 「Federated Search」。情報検索の基礎と動向。5 : 1–102. doi : 10.1561/1500000010. S2CID  33433994。