はじめに
社内システムは複数サブシステムに分かれており、各々のシステムが検索エンジンを持っている
例えばShare pointやServiceNowやBoxやCYDASにはそれ自身に検索エンジンとインデックス化済のデータがある(APIの提供もある)
これらのデータに対し、改めてデータを一箇所に集約しインデックス処理を行うより、
サブシステムの検索エンジンをAPIで呼び出しをバックエンドで行い、フロントのユーザーインタフェースをChatUIに統一する方が開発効率もユーザー体験も良いでしょう。
本記事では、複数のサブシステムをまたぐ社内情報検索のためRAG構成を検討します。
メタ検索エンジン
メタ検索エンジンは、ユーザーの検索クエリを複数の検索エンジンに送信し、それらの結果を集約して一つの結果ページに表示するシステムです。メタ検索エンジン自体はウェブページをクロールせず、他の検索エンジンの結果を利用しています。
メタ検索エンジンの考え方
- 方法: 複数の検索エンジンの結果を集約して、一つのインターフェースで表示
- 特徴: 複数のデータソースから情報を取得し、幅広い視点からの検索結果を提供
- 制限: 単一の検索エンジンの詳細な分析能力には劣ることがある
このアプローチにより、ユーザーは一度の検索で複数のデータベースを横断的に検索でき、より幅広い情報を得られる可能性があります。
メリット例
-
SharepointとService Nowに社内情報が泣き別れている状態でも、ユーザーは意識せずに検索できる。文書にたどり着ける
- サービス提供者側は統合し文書整理方針ややインデックス化などが不要。事務工数を抑え、各サブシステム単独で検索性能を上げていけば良い
-
部門の部員数の集計や、部署情報のリストを、(公開文書の変更をまたず)リアルタイムで正確にかつ自然言語で問い合わせが可能になる
- CYDASAPIで取得可能な要素
- これらの情報を文書からNLPで取得する方策(=文書のベクトル化)は非常に非効率的。TBL形式で取得すべき
参考資料
処理フローイメージ
この図は、クエリ理解システムがどのように機能して、複数の検索バックエンドへルーティングを行うかを示しています。
- Query Engine:ユーザーの質問(=クエリ)を受け取り、解釈するコンポーネントです。これにより、クエリは複数の検索リクエストに変換されます
- MultipleSearchRequests: クエリエンジンによって生成された複数の検索リクエストが、異なる検索バックエンドへ送信されます
- SearchRequest 1, 2, 3: 個別の検索リクエスト。それぞれが異なるバックエンドシステムに送られる
- Backend 1, 2, 3: 検索リクエストを処理する異なる検索システム。各システムは独自のデータやアルゴリズムを使用して検索結果を生成します
- UI, Summary: 検索バックエンドからの出力。ユーザーインターフェイス（UI）や要約など、ユーザーが利用する形式で提供されます
このシステムは、検索結果を最適化し、ユーザーの意図に最も適した結果を提供するために、クエリをより正確に解釈し、適切なバックエンドにルーティングします。
シーケンス図
複数のサブシステムをまたぐ社内情報検索を含むLLM RAGアプリを処理を例示します。
- ユーザーがクエリをRAGフロントエンドに送信し、RAGバックエンドに転送
- バックエンドでクエリの正規化と基本的なNLP処理が行う
- Azure OpenAIを用いてクエリの意図を識別し、結果をバックエンドに返す
- バックエンドが情報源を決定しクエリをサブクエリに分割。SharePointなどの複数のサービスに送信
- 各サービスからの応答結果を集め、AzureOpenAIに統合を依頼し、応答をバックエンドに返す
- バックエンドが最終クエリを生成し、Azure OpenAIに回答の合成を依頼し、受け取った回答を事後処理する
- 改善された回答はフロントエンドを通じてユーザーに転送・表示される