サブシステムをまたぐ社内情報検索のためRAG構成


## はじめに

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

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

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

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

# メタ検索エンジン

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

## **メタ検索エンジンの考え方**

- 方法: 複数の検索エンジンの結果を集約して、一つのインターフェースで表示
- 特徴: 複数のデータソースから情報を取得し、幅広い視点からの検索結果を提供
- 制限: 単一の検索エンジンの詳細な分析能力には劣ることがある


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



## メリット例

1. SharepointとService Nowに社内情報が泣き別れている状態でも、ユーザーは意識せずに検索できる。文書にたどり着ける
    - サービス提供者側は統合し文書整理方針ややインデックス化などが不要。事務工数を抑え、各サブシステム単独で検索性能を上げていけば良い

2. 部門の部員数の集計や、部署情報のリストを、(公開文書の変更をまたず)リアルタイムで正確にかつ自然言語で問い合わせが可能になる
    - [CYDASAPIで取得可能な要素](https://developer.cydas.com/#tag/部署情報)
    - これらの情報を文書からNLPで取得する方策(=文書のベクトル化)は非常に非効率的。TBL形式で取得すべき


### 参考資料
- [SharePoint REST サービスの概要](https://learn.microsoft.com/ja-jp/sharepoint/dev/sp-add-ins/get-to-know-the-sharepoint-rest-service?tabs=csom)
- [製品ドキュメント | ServiceNow](https://docs.servicenow.com/ja-JP/bundle/tokyo-application-development/page/build/applications/concept/api-rest.html)
- [APIリファレンス - Box Developerドキュメント](https://ja.developer.box.com/reference/)
- [PEOPLE API](https://developer.cydas.com/)

# 処理フローイメージ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/348593/5a8e59eb-e600-83fe-8e12-fb00b328f42f.png)

この図は、クエリ理解システムがどのように機能して、複数の検索バックエンドへルーティングを行うかを示しています。
- **Query Engine**:ユーザーの質問(=クエリ)を受け取り、解釈するコンポーネントです。これにより、クエリは複数の検索リクエストに変換されます
- **MultipleSearchRequests**: クエリエンジンによって生成された複数の検索リクエストが、異なる検索バックエンドへ送信されます
- **SearchRequest 1, 2, 3**: 個別の検索リクエスト。それぞれが異なるバックエンドシステムに送られる
- **Backend 1, 2, 3**: 検索リクエストを処理する異なる検索システム。各システムは独自のデータやアルゴリズムを使用して検索結果を生成します
- **UI, Summary**: 検索バックエンドからの出力。ユーザーインターフェイス（UI）や要約など、ユーザーが利用する形式で提供されます

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

## シーケンス図

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

1. ユーザーがクエリをRAGフロントエンドに送信し、RAGバックエンドに転送
2. バックエンドでクエリの正規化と基本的なNLP処理が行う
3. Azure OpenAIを用いてクエリの意図を識別し、結果をバックエンドに返す
4. **バックエンドが情報源を決定しクエリをサブクエリに分割。SharePointなどの複数のサービスに送信**
5. **各サービスからの応答結果を集め、AzureOpenAIに統合を依頼し、応答をバックエンドに返す**
6. **バックエンドが最終クエリを生成し、Azure OpenAIに回答の合成を依頼し、受け取った回答を事後処理する**
7. 改善された回答はフロントエンドを通じてユーザーに転送・表示される

``` mermaid 

sequenceDiagram
    participant ユーザー
    participant FE as フロントエンド
    participant BE as バックエンド
    participant Azure as Azure OpenAI
    participant SharePoint
    participant BO as Box
    participant ServiceNow
    participant AzureSearch as AzureAIsearch
    participant CYDAS as CYDAS


    note over FE: 1.ユーザークエリの受信
    ユーザー->>FE: クエリを送信
    FE->>BE: クエリを転送

    note over BE: 2.事前処理
    BE->>BE: 事前処理を実行（正規化、スペルミス修正）

    note over BE: 3.意図識別
    BE->>Azure: 意図識別のためのクエリを送信
    Azure-->>BE: 意図分析結果を返送

    note over BE: 4.ルーティングとクエリの処理
    BE->>BE: ルーティングのための情報源を決定
    BE->>BE: クエリの書き換え
    BE->>BE: サブクエリの生成

    par AzureAIsearchにサブクエリ送信
        BE->>AzureSearch: サブクエリを送信
        AzureSearch-->>BE: 検索結果を返送
    and Boxにサブクエリ送信
        BE->>BO: APIを送信
        BO-->>BE: 検索結果を返送
    and ServiceNowにサブクエリ送信
        BE->>ServiceNow: APIを送信
        ServiceNow-->>BE: 検索結果を返送
    and SharePointにAPI送信
        BE->>SharePoint: APIを送信
        SharePoint-->>BE: 検索結果を返送
    and CYDASにAPI送信
        BE->>CYDAS: APIを送信
        CYDAS-->>BE: 検索結果を返送
    end

    note over BE: 5.結果の統合
    BE->>BE: 中間結果の収集（非同期の結果待ち）
    BE->>Azure: 結果の統合とポストプロセスのための要求
    Azure-->>BE: 統合された応答を返送
    BE->>BE: 応答品質改善のためのフィルタリングや並べ替えなど

    note over BE: 6.回答の合成と事後処理
    BE->>BE: クエリの生成
    BE->>Azure: 回答の合成のための要求
    Azure-->>BE: 応答を返送
    BE->>BE: 事後処理を実行（引用元リンクの追加,問い合わせ先の追加）

    BE-->>FE: 回答を転送
    FE-->>ユーザー: 回答を表示
    
```