セキュリティで保護されたマルチテナント RAG 推論ソリューションの設計ガイド

取得拡張生成 (RAG) は、基本モデルを使用して、インターネット上で一般に公開されていない独自の情報やその他の情報を推論するアプリケーションを構築するためのパターンです。 一般に、クライアント アプリケーションは、ベクター データベースなどのデータ ストアから関連情報をフェッチするオーケストレーション レイヤーを呼び出します。 オーケストレーションレイヤーは、コンテキストの一部としてそのデータを基礎モデルにグラウンド データとして渡します。

マルチテナント ソリューションは、複数の顧客によって使用されます。各顧客 (テナント) は、同じ組織、会社、またはグループの複数のユーザーで構成されます。 マルチテナント シナリオでは、テナントまたはテナント内の個人が、確認する権限を持つグラウンド データのみを組み込むことができるようにする必要があります。

この記事では、ユーザーが表示する予定の情報にのみアクセスすることを保証する以外にも、マルチテナントの懸念事項がありますが、この記事ではマルチテナントのその側面に焦点を当てています。 この記事では、まず、シングル テナントの RAG アーキテクチャの概要、RAG を使用したマルチテナントに関する課題、および従う一般的なアプローチについて説明し、セキュリティで保護されたマルチテナントの考慮事項と推奨事項について説明します。

オーケストレーターを使用したシングル テナント RAG アーキテクチャ

図 1. シングルテナント RAG アーキテクチャ

ワークフロー

このシングル テナント RAG アーキテクチャでは、オーケストレーターは、関連する独自のテナント データをデータ ストアからフェッチし、基本モデルに対する基礎データとして提供する役割を担います。 大まかなワークフローを次に示します。

1. ユーザーがインテリジェント Web アプリケーションに要求を発行します。
2. ID プロバイダーがリクエスタを認証します。
3. インテリジェント アプリケーションは、ユーザー クエリとユーザーの承認トークンを使用してオーケストレーター API を呼び出します。
4. オーケストレーション ロジックは、要求からユーザーのクエリを抽出し、適切なデータ ストアを呼び出して、クエリの関連するグラウンド データをフェッチします。 次の手順では、基本モデル (Azure OpenAI で公開されているモデルなど) に送信されるプロンプトに、接地データが追加されます。
5. オーケストレーション ロジックは、基本モデルの推論 API に接続し、取得したグラウンド データを含むプロンプトを送信します。 結果はインテリジェント アプリケーションに返されます。

RAG の詳細については、「 RAG ソリューションの設計と開発」を参照してください。

直接データ アクセスを使用するシングル テナント RAG アーキテクチャ

シングル テナント RAG アーキテクチャのバリエーションでは、Azure Search などのデータ ストアと直接統合する Azure OpenAI サービスの機能を利用。 このアーキテクチャでは、独自のオーケストレーターがないか、オーケストレーターの責任が少なくなります。 Azure OpenAI API には、データ ストアを呼び出して接地データをフェッチし、そのデータを言語モデルに渡す必要があります。 次に、フェッチするグラウンド データとそのデータの関連性を制御することが少なくなります。

図 2. Azure OpenAI サービスからの直接データ アクセスを使用したシングルテナント RAG アーキテクチャ

ワークフロー

この RAG アーキテクチャでは、基本モデルを提供するサービスは、データ ストアから適切な独自のテナント データをフェッチし、そのデータを基本モデルへの基礎データとして使用する必要があります。 大まかなワークフローを次に示します (斜体化された手順は、オーケストレーター ワークフローを使用したシングル テナント RAG アーキテクチャと同じです)。

1. ユーザーがインテリジェント Web アプリケーションに要求を発行します。
2. ID プロバイダーがリクエスタを認証します。
3. その後、インテリジェント アプリケーションは、ユーザー クエリを使用して Azure OpenAI サービスを呼び出します。
4. Azure OpenAI サービスは、Azure AI Search や Azure Blob Storage などのサポートされているデータ ストアに接続して、グラウンド データをフェッチします。 グラウンド データは、Azure OpenAI サービスが OpenAI 言語モデルを呼び出すときに、コンテキストの一部として使用されます。 結果はインテリジェント アプリケーションに返されます。

マルチテナント ソリューションでこのアーキテクチャを検討するには、グラウンド データに直接アクセスする Azure OpenAI などのサービスで、ソリューションに必要なマルチテナント ロジックをサポートする必要があります。

RAG アーキテクチャのマルチテナント

マルチテナント ソリューションでは、テナント データがテナント固有のストアに存在するか、マルチテナント ストア内の他のテナントと共存している可能性があります。 テナント間で共有されるデータがストア内にある場合もあります。 ユーザーが表示する権限を持つデータのみを、グラウンド データとして使用する必要があります。 ユーザーには、フィルタールールが適用されたテナントの共通 (すべてのテナント) データのみが表示され、表示が許可されているデータのみが表示されるようにする必要があります。

図 3: RAG アーキテクチャ - 複数のデータ ストア テナントを使用する

ワークフロー

このワークフローは、 オーケストレーターを使用したSingle テナント RAG アーキテクチャと同じです 手順 4 を除きます。

1. ユーザーがインテリジェント Web アプリケーションに要求を発行します。
2. ID プロバイダーがリクエスタを認証します。
3. インテリジェント アプリケーションは、ユーザー クエリとユーザーの承認トークンを使用してオーケストレーター API を呼び出します。
4. オーケストレーション ロジックは、要求からユーザーのクエリを抽出し、適切なデータ ストアを呼び出して、クエリのテナント承認された関連するグラウンド データをフェッチします。 グラウンディング データは、次の手順で Azure OpenAI に送信されるプロンプトに追加されます。 次の手順の一部またはすべてが関係します。
   1. オーケストレーション ロジックは、適切なテナント固有のデータ ストア インスタンスからグラウンド データをフェッチし、セキュリティ フィルター規則を適用して、ユーザーがアクセスを許可されているデータのみを返す可能性があります。
   2. オーケストレーション ロジックは、マルチテナント データ ストアから適切なテナントのグラウンド データをフェッチし、ユーザーがアクセスを許可されているデータのみを返すセキュリティ フィルター規則を適用する可能性があります。
   3. オーケストレーション ロジックは、テナント間で共有されているデータ ストアからデータをフェッチします。
5. オーケストレーション ロジックは、基本モデルの推論 API に接続し、取得したグラウンド データを含むプロンプトを送信します。 結果はインテリジェント アプリケーションに返されます。

RAG でのマルチテナント データの設計に関する考慮事項

ストア分離モデルの選択

マルチテナント シナリオでのストレージとデータには、 主に 2 つのアプローチがありますテナントごとのストアとマルチテナント ストアです。 これらのアプローチは、テナント間で共有されるデータを含むストアに加えて行われます。 このセクションでは、各アプローチについて説明します。 マルチテナント ソリューションでは、これらのアプローチを組み合わせて使用できることに注意してください。

テナントごとのストア

テナントごとのストアでは、名前が示すように、各テナントには独自のストアがあります。 このアプローチの利点には、データとパフォーマンスの分離の両方が含まれます。 各テナントのデータは、独自のストアにカプセル化されます。 ほとんどのデータ サービスでは、分離されたストアは、他のテナントのノイズの多い近隣の問題の影響を受けにくいです。 この方法では、ストア展開のコスト全体を 1 つのテナントに起因できるため、コストの割り当ても簡略化されます。

このアプローチの課題には、管理と運用のオーバーヘッドが増え、コストが高くなる可能性があります。 このアプローチは、企業間のシナリオなど、多数の小規模なテナントがある場合には考慮しないでください。 この方法は、 サービスの制限に対しても発生する可能性があります。

この AI シナリオのコンテキストでは、テナントごとのストアは、コンテキストに関連性を持ち込むのに必要な接地データが、テナントの接地データのみを含む既存または新規のデータ ストアから取得されることを意味します。 このトポロジでは、データベース インスタンスはテナントごとに使用される識別子です。

マルチテナント ストア

マルチテナント ストアでは、複数のテナント データが同じストアに共存します。 このアプローチの利点には、コストの最適化の可能性、テナントごとのストア モデルよりも多くのテナントを処理する機能、ストア インスタンスの数が少ないための管理オーバーヘッドの削減などがあります。

共有ストアを使用する場合の課題には、データの分離、データ管理、不要な近隣のアンチパターンの可能性、テナントへのコストの割り当ての困難が含まれます。 この方法では、データの分離を確保することが最も重要な懸念事項です。 テナントがデータにのみアクセスできるようにセキュリティ アプローチを実装する責任があります。 テナントが異なるデータ ライフサイクルを持ち、異なるスケジュールでインデックスを作成するなどの操作を必要とする場合も、データ管理が困難になる可能性があります。

一部のプラットフォームには、共有ストアでテナント データ分離を実装するときに利用できる機能があります。 たとえば、Azure Cosmos DB ではパーティション分割とシャーディングがネイティブにサポートされており、テナント識別子をパーティション キーとして使用して、テナント間で何らかのレベルの分離を提供するのが一般的です。 Azure SQL と Postgres Flex では行レベルのセキュリティがサポートされていますが、マルチテナント ストアで使用する予定の場合は、これらの機能を中心にソリューションを設計する必要があるため、この機能はマルチテナント ソリューションでは一般的には使用されません。

この AI シナリオのコンテキストでは、すべてのテナントの基礎データが同じデータ ストアに格納されることを意味します。そのため、そのデータ ストアに対するクエリには、テナントのコンテキスト内の関連データのみを返すように応答が制限されるようにテナント判別機能を含める必要があります。

共有ストア

マルチテナント ソリューションには、多くの場合、テナント間で共有されるデータがあります。 医療ドメインのマルチテナント ソリューションの例では、一般的な医療情報やテナント固有ではない情報を格納するデータベースが存在する可能性があります。

この AI シナリオのコンテキストでは、これは、データがシステム内のすべてのテナントに関連して承認されているため、テナントに基づくフィルター処理を特に必要としない、一般的にアクセス可能なグラウンド データ ストアになります。

ID

ID は、セキュリティで保護されたマルチテナント RAG を含む マルチテナント ソリューションの重要な側面です。 インテリジェント アプリケーションは、ID プロバイダー (IdP) と統合して、ユーザーの ID を認証する必要があります。 マルチテナント RAG ソリューションには、権限のある ID または ID への参照が格納される id ディレクトリが必要です。 この ID は要求チェーンを通過する必要があり、オーケストレーターやデータ ストア自体などのダウンストリーム サービスがユーザーを識別できるようにする必要があります。

また、ユーザーをテナントに マッピングする手段も必要です そのテナント データへのアクセス権を付与できます。

テナントと承認の要件を定義する

マルチテナント RAG ソリューションを構築するときは、ソリューションのテナント 定義する必要があります。 選択する 2 つの一般的なモデルは、企業間 (B2B) と企業間 (B2C) です。 この決定は、ソリューションを設計するときに考慮する必要がある領域を通知するのに役立ちます。 テナントの数を理解することは、データ ストア モデルを決定するうえで重要です。 テナントの数が多いと、ストアごとに複数のテナントを持つモデルが必要になる場合があります。一方、テナント ごとのストア モデルでは、少ない数を使用できる場合があります。 テナントごとのデータの量も重要です。 テナントに大量のデータがあり、データ ストアのサイズ制限によりマルチテナント ストアを使用できなくなる可能性がある場合。

この AI シナリオをサポートするように拡張されている既存のワークロードでは、既にこの選択を行っている可能性があります。 一般に、そのデータ ストアが十分な関連性を提供し、その他の機能以外の要件を満たすことができる場合は、グラウンド データに既存のデータ ストレージ トポロジを使用できます。 ただし、専用ベクター検索ストアなどの新しいコンポーネントを専用のグラウンド ストアとして導入する場合は、現在のデプロイ スタンプ戦略、アプリケーションコントロール プレーンへの影響、テナントごとのデータ ライフサイクルの違い (パフォーマンスの支払い状況など) などの要因を考慮して、この決定を行う必要があります。

ソリューションのテナントを定義したら、データの承認要件を定義する必要があります。 テナントはテナントからのデータにのみアクセスしますが、承認要件がより細かい場合があります。 たとえば、医療ソリューションでは、次のようなルールが含まれる場合があります。

• 患者は自分の患者データにのみアクセスできます
• 医療専門家が患者のデータにアクセスできる
• 財務ユーザーは、財務関連のデータにのみアクセスできます
• 臨床監査人はすべての患者のデータを見ることができる
• すべてのユーザーが共有データ ストアの基本医療知識にアクセスできます

ドキュメント ベースの RAG アプリケーションでは、ドキュメントに設定されたタグ付けスキームまたは秘密度レベルに基づいて、ドキュメントへのユーザー アクセスを制限できます。

テナントの定義を作成し、承認規則を明確に理解したら、その情報をデータ ストア ソリューションの要件として使用します。

フィルター処理

フィルター処理 (セキュリティ トリミングとも呼ばれます) は、表示が許可されているユーザーにのみデータを公開することを指します。 マルチテナント RAG シナリオでは、ユーザーをテナント固有のストアにマップできます。 これは、ユーザーがそのストア内のすべてのデータにアクセスできることを意味するわけではありません。 テナントと承認の要件を定義するでは、データの承認要件を定義することの重要性について説明しました。 これらの承認規則は、フィルター処理の基礎として使用する必要があります。

フィルター処理は、行レベルのセキュリティなどのデータ プラットフォーム機能を使用して実現できます。または、カスタム ロジック、データ、またはメタデータが必要になる場合があります。 ここでも、これらのプラットフォーム機能は、これらの機能を中心にシステムを設計する必要があるため、マルチテナント ソリューションでは一般的には使用されません。

マルチテナント データ ロジックのカプセル化

使用しているストレージ メカニズムの前に API を用意することをお勧めします。 API はゲートキーパーとして機能し、ユーザーがアクセスする必要がある情報にのみアクセスできるようにします。

図 4 マルチテナント テナント データ アクセス ロジックをカプセル化する API を使用したマルチテナント RAG アーキテクチャ

この記事で前述したように、データへのユーザー アクセスは次の方法で制限できます。

• ユーザーのテナント
• プラットフォーム機能
• カスタム セキュリティ フィルター/トリミング規則。

このレイヤーには、次の役割が必要です。

• テナントごとのストア モデルでテナント固有のストアにクエリをルーティングする
• マルチテナント ストア内のユーザーのテナントからデータのみを選択する
• プラットフォーム対応の承認ロジックをサポートするためにユーザーに適切な ID を使用する
• カスタム セキュリティ トリミング ロジックを適用する
• 監査目的で接地情報のアクセス ログを保存する

テナント データにアクセスする必要があるコードでは、バックエンド ストアに直接クエリを実行することはできません。 データに対するすべての要求は、この API レイヤーを通過する必要があります。 この API レイヤーは、テナント データの上に単一のガバナンス層またはセキュリティ 層を提供します。 この方法では、テナントとユーザーのデータ アクセス承認ロジックがアプリケーションのさまざまな領域にブリードされないようにします。 このロジックは API レイヤーにカプセル化されます。 このカプセル化により、ソリューションの検証とテストが容易になります。

まとめ

マルチテナント RAG 推論ソリューションを設計する場合は、テナントのグラウンド データ ソリューションを設計する方法を考慮する必要があります。 テナントの数と、格納するテナントごとのデータの量について理解を深めます。 この情報は、データ テナント ソリューションの設計に役立ちます。 マルチテナント ロジックとフィルター 処理ロジックの両方を含む、データ アクセス ロジックをカプセル化する API レイヤーを実装することをお勧めします。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

• John Downs | プリンシパル ソフトウェア エンジニア
• Daniel Scott-Raynsford | シニア パートナー ソリューション アーキテクト、データおよび AI

次のステップ

関連リソース

• SaaS およびマルチテナント ソリューション アーキテクチャ
• 基本 OpenAI エンドツーエンド チャット リファレンス アーキテクチャ
• ベースライン OpenAI エンドツーエンド チャット リファレンス アーキテクチャ
• ゲートウェイ経由で Azure OpenAI などの言語モデルにアクセスする