はじめに

社内システムは複数サブシステムに分かれており、各々のシステムが検索エンジンを持っている

例えばShare pointやServiceNowやBoxやCYDASにはそれ自身に検索エンジンとインデックス化済のデータがある(APIの提供もある)

これらのデータに対し、改めてデータを一箇所に集約しインデックス処理を行うより、
サブシステムの検索エンジンをAPIで呼び出しをバックエンドで行い、フロントのユーザーインタフェースをChatUIに統一する方が開発効率もユーザー体験も良いでしょう。

本記事では、複数のサブシステムをまたぐ社内情報検索のためRAG構成を検討します。

メタ検索エンジン

メタ検索エンジンは、ユーザーの検索クエリを複数の検索エンジンに送信し、それらの結果を集約して一つの結果ページに表示するシステムです。メタ検索エンジン自体はウェブページをクロールせず、他の検索エンジンの結果を利用しています。

このアプローチにより、ユーザーは一度の検索で複数のデータベースを横断的に検索でき、より幅広い情報を得られる可能性があります。

SharepointとService Nowに社内情報が泣き別れている状態でも、ユーザーは意識せずに検索できる。文書にたどり着ける
- サービス提供者側は統合し文書整理方針ややインデックス化などが不要。事務工数を抑え、各サブシステム単独で検索性能を上げていけば良い
部門の部員数の集計や、部署情報のリストを、(公開文書の変更をまたず)リアルタイムで正確にかつ自然言語で問い合わせが可能になる
- CYDASAPIで取得可能な要素
- これらの情報を文書からNLPで取得する方策(=文書のベクトル化)は非常に非効率的。TBL形式で取得すべき

この図は、クエリ理解システムがどのように機能して、複数の検索バックエンドへルーティングを行うかを示しています。

このシステムは、検索結果を最適化し、ユーザーの意図に最も適した結果を提供するために、クエリをより正確に解釈し、適切なバックエンドにルーティングします。

複数のサブシステムをまたぐ社内情報検索を含むLLM RAGアプリを処理を例示します。