セキュリティで保護されたマルチテナント RAG 推論ソリューションを設計する
Retrieval-Augmented 生成 (RAG) は、基本モデルを使用して、インターネットで一般に公開されていない独自の情報やその他のデータを推論するアプリケーションを構築するためのパターンです。 一般に、クライアント アプリケーションは、ベクター データベースなどのデータ ストアから関連情報をフェッチするオーケストレーション レイヤーを呼び出します。 オーケストレーションレイヤーは、コンテキストの一部としてそのデータを基礎モデルにグラウンド データとして渡します。
マルチテナント ソリューションは、複数の顧客によって使用されます。 各顧客 (テナント) は、同じ組織、会社、またはグループの複数のユーザーで構成されます。 マルチテナント シナリオでは、テナントまたはテナント内の個人が、アクセスを許可されているグラウンド データのみを組み込むことができるようにする必要があります。
ユーザーがアクセスを許可されている情報にのみアクセスすることを保証する以外にも、マルチテナントの懸念があります。 ただし、この記事では、マルチテナントのその側面に焦点を当てています。 この記事では、まずシングルテナント RAG アーキテクチャの概要について説明します。 ここでは、RAG を使用したマルチテナントで発生する可能性がある課題と、いくつかの一般的なアプローチについて説明します。 また、セキュリティを強化するためのマルチテナントの考慮事項と推奨事項についても説明します。
手記
この記事では、Azure OpenAI On Your Data 機能など、Azure OpenAI サービスに固有のいくつかの機能について説明します。 ただし、この記事で説明されている原則のほとんどは、任意のプラットフォーム上の基本的な AI モデルに適用できます。
オーケストレーターを使用したシングルテナント RAG アーキテクチャ
ワークフロー
このシングルテナント RAG アーキテクチャでは、オーケストレーターは、関連する独自のテナント データをデータ ストアからフェッチし、基本モデルに対するグラウンド データとして提供します。 次の手順では、ワークフローの概要について説明します。
- ユーザーがインテリジェント Web アプリケーションに要求を発行します。
- ID プロバイダーがリクエスタを認証します。
- インテリジェント アプリケーションは、ユーザーのクエリとユーザーの承認トークンを使用してオーケストレーター API を呼び出します。
- オーケストレーション ロジックは、要求からユーザーのクエリを抽出し、適切なデータ ストアを呼び出して、クエリの関連するグラウンド データをフェッチします。 次の手順では、基本モデル (Azure OpenAI で公開されているモデルなど) に送信されるプロンプトに、接地データが追加されます。
- オーケストレーション ロジックは、基本モデルの推論 API に接続し、取得したグラウンド データを含むプロンプトを送信します。 結果はインテリジェント アプリケーションに返されます。
詳細については、「RAG ソリューションの設計と開発」を参照してください。
直接データ アクセスを使用するシングルテナント RAG アーキテクチャ
シングルテナント RAG アーキテクチャのこのバリアントでは、Azure OpenAI の On Your Data 機能 を使用して、Azure AI Search などのデータ ストアと直接統合します。 このアーキテクチャでは、独自のオーケストレーターがないか、オーケストレーターの責任が少なくなります。 Azure OpenAI API は、データ ストアを呼び出してグラウンド データをフェッチし、そのデータを言語モデルに渡します。 この方法を使用すると、フェッチするグラウンディング データやそのデータの関連性を制御する自由度が低下します。
手記
Azure OpenAI は Microsoft によって管理されます。 データ ストアと統合されますが、モデル自体はデータ ストアと統合されません。 モデルは、オーケストレーターがデータを取得するのと同じ方法で、基礎データを受け取ります。
ワークフロー
この RAG アーキテクチャでは、基本モデルを提供するサービスは、データ ストアから適切な独自のテナント データをフェッチし、そのデータを基本モデルへの接地データとして使用します。 次の手順では、ワークフローの概要について説明します。 斜体化された手順は、オーケストレーター ワークフローを持つ上記のシングルテナント RAG アーキテクチャと同じです。
- ユーザーがインテリジェント Web アプリケーションに要求を発行します。
- ID プロバイダーがリクエスタを認証します。
- インテリジェント アプリケーションは、ユーザーのクエリを使用して Azure OpenAI を呼び出します。
- Azure OpenAI は、AI Search や Azure Blob Storage などのサポートされているデータ ストアに接続して、グラウンド データをフェッチします。 グラウンド データは、Azure OpenAI が OpenAI 言語モデルを呼び出すときにコンテキストの一部として使用されます。 結果はインテリジェント アプリケーションに返されます。
マルチテナント ソリューションでこのアーキテクチャを使用する場合は、Azure OpenAI などのグラウンド データに直接アクセスするサービスで、ソリューションに必要なマルチテナント ロジックをサポートする必要があります。
RAG アーキテクチャのマルチテナント
マルチテナント ソリューションでは、テナント データがテナント固有のストアに存在するか、マルチテナント ストア内の他のテナントと共存している可能性があります。 データは、テナント間で共有されるストア内にある場合もあります。 ユーザーがアクセスを許可されているデータのみを、グラウンド データとして使用する必要があります。 ユーザーには、アクセスが許可されているデータのみを確実に表示できるようにフィルター処理されたテナントの共通データまたはテナント全体のデータのみが表示されます。
ワークフロー
次の手順では、ワークフローの概要について説明します。 斜体化された手順は、オーケストレーター ワークフローを使用した シングルテナント RAG アーキテクチャと同じです。
- ユーザーがインテリジェント Web アプリケーションに要求を発行します。
- ID プロバイダーがリクエスタを認証します。
- インテリジェント アプリケーションは、ユーザーのクエリとユーザーの承認トークンを使用してオーケストレーター API を呼び出します。
- オーケストレーション ロジックは、要求からユーザーのクエリを抽出し、適切なデータ ストアにアクセスして、クエリに関連するテナント承認済みの基盤データを取得します。 次のステップで Azure OpenAI に送信されるプロンプトに、基礎データが追加されます。 次の手順の一部またはすべてが含まれています。
- オーケストレーション ロジックは、適切なテナント固有のデータ ストア インスタンスからグラウンド データをフェッチし、セキュリティ フィルター規則を適用して、ユーザーがアクセスを許可されているデータのみを返す可能性があります。
- オーケストレーション ロジックは、マルチテナント データ ストアから適切なテナントのグラウンド データをフェッチし、ユーザーがアクセスを許可されているデータのみを返すセキュリティ フィルター規則を適用する可能性があります。
- オーケストレーション ロジックは、テナント間で共有されているデータ ストアからデータをフェッチします。
- オーケストレーション ロジックは、基本モデルの推論 API に接続し、取得したグラウンド データを含むプロンプトを送信します。 結果はインテリジェント アプリケーションに返されます。
RAG でのマルチテナント データの設計に関する考慮事項
マルチテナント RAG 推論ソリューションを設計するときは、次のオプションを検討してください。
ストア分離モデルを選択する
マルチテナント シナリオでのストレージとデータに対する 2 つの主な アーキテクチャ アプローチ、テナントごとのストアとマルチテナント ストアです。 これらのアプローチは、テナント間で共有されるデータを含むストアに加えて行われます。 マルチテナント ソリューションでは、これらのアプローチを組み合わせて使用できます。
各テナント専用のストア
テナントごとのストアでは、各テナントに独自のストアがあります。 このアプローチの利点には、データとパフォーマンスの分離の両方が含まれます。 各テナントのデータは、独自のストアにカプセル化されます。 ほとんどのデータ サービスでは、分離されたストアは、他のテナントのノイズの多い近隣の問題の影響を受けにくいです。 この方法では、ストア展開のコスト全体が 1 つのテナントに起因する可能性があるため、コストの割り当ても簡略化されます。
このアプローチでは、管理と運用のオーバーヘッドの増加やコストの増加などの課題が生じている可能性があります。 企業間のシナリオのように、多数の小規模なテナントがある場合は、このアプローチを使用しないでください。 この方法は、サービスの制限に達したり超えたりする可能性もあります。
この AI シナリオのコンテキストでは、テナントごとのストアは、コンテキストに関連性を持ち込むのに必要な接地データが、テナントのグラウンド データのみを含む既存または新規のデータ ストアから取得されることを意味します。 このトポロジでは、データベース インスタンスはテナントごとに使用される識別子です。
マルチテナント ストア
マルチテナント ストアでは、複数のテナントのデータが同じストアに共存します。 このアプローチの利点には、コストの最適化の可能性、テナントごとのストア モデルよりも多くのテナントを処理する機能、ストア インスタンスの数が少ないための管理オーバーヘッドの削減などがあります。
共有ストアを使用する場合の課題には、データの分離と管理の必要性、ノイズの多い近隣のアンチパターンの可能性、テナントへのより複雑なコスト割り当てが含まれます。 この方法を使用する場合、データの分離が最も重要な懸念事項です。 テナントがデータにのみアクセスできるように、セキュリティで保護されたアプローチを実装する必要があります。 また、テナントのデータ ライフサイクルが異なり、異なるスケジュールでインデックスを作成するなどの操作が必要な場合、データ管理が困難になる場合もあります。
一部のプラットフォームには、共有ストアでテナント データ分離を実装するときに使用できる機能があります。 たとえば、Azure Cosmos DB では、データのパーティション分割とシャーディングがネイティブにサポートされています。 テナント間でいくつかの分離を提供するために、テナント識別子をパーティション キーとして使用するのが一般的です。 Azure SQL と Azure Database for PostgreSQL - フレキシブル サーバーでは、行レベルのセキュリティがサポートされます。 ただし、マルチテナント ストアで使用する予定の場合は、これらの機能を中心にソリューションを設計する必要があるため、通常、これらの機能はマルチテナント ソリューションでは使用されません。
この AI シナリオのコンテキストでは、すべてのテナントのグラウンド データが同じデータ ストア内で通信されます。 そのため、そのデータ ストアに対するクエリには、テナントのコンテキスト内で関連するデータのみを返すよう応答が制限されるように、テナント判別機能を含める必要があります。
共有ストア
マルチテナント ソリューションは、多くの場合、テナント間でデータを共有します。 医療ドメインのマルチテナント ソリューションの例では、データベースには、一般的な医療情報やテナントに固有ではない情報が格納される場合があります。
この AI シナリオのコンテキストでは、データはシステム内のすべてのテナントに対して関連性があり、承認されているため、一般に、グラウンド データ ストアにはアクセス可能であり、特定のテナントに基づくフィルター処理は必要ありません。
同一性
ID は、マルチテナント RAG ソリューションを含むマルチテナント ソリューションの重要な側面です。 インテリジェント アプリケーションは、ユーザーの ID を認証するために ID プロバイダーと統合する必要があります。 マルチテナント RAG ソリューションには、権限のある ID または ID への参照を格納する ID ディレクトリ が必要です。 この ID は、要求チェーンを通過し、オーケストレーターやデータ ストア自体などのダウンストリーム サービスがユーザーを識別できるようにする必要があります。
また、そのテナント データへのアクセスを許可できるように、ユーザーをテナント に マップする方法も必要です。
テナントと承認の要件を定義する
マルチテナント RAG ソリューションを構築するときは、ソリューション のテナント定義する必要があります。 選択する 2 つの一般的なモデルは、企業間モデルと企業間モデルです。 選択したモデルは、ソリューションをビルドするときに考慮する必要があるその他の要因を決定するのに役立ちます。 テナントの数を理解することは、データ ストア モデルを選択するうえで重要です。 多数のテナントでは、ストアごとに複数のテナントを持つモデルが必要になる場合があります。 テナントの数が少ない場合、テナントごとのストア モデルが可能になる場合があります。 各テナントのデータ量も重要です。 大量のデータを持つテナントでは、データ ストアのサイズに制限があるため、マルチテナント ストアを使用できないことがあります。
この AI シナリオをサポートするために既存のワークロードを拡張する場合は、既にこの決定を行っている可能性があります。 一般に、そのデータ ストアが十分な関連性を提供し、その他の機能以外の要件を満たすことができる場合は、グラウンド データに既存のデータ ストレージ トポロジを使用できます。 ただし、専用ベクター検索ストアなどの新しいコンポーネントを専用のグラウンド ストアとして導入する場合は、この決定を行う必要があります。 現在のデプロイ スタンプ戦略、アプリケーション コントロール プレーンへの影響、テナントごとのデータ ライフサイクルの違い (パフォーマンスの支払い状況など) などの要因を考慮してください。
ソリューションのテナントを定義したら、データの承認要件を定義する必要があります。 テナントはテナントからのデータにのみアクセスしますが、承認要件がより細かい場合があります。 たとえば、医療ソリューションでは、次のようなルールがある場合があります。
- 患者は自分の患者データにのみアクセスできます。
- 医療専門家は、患者のデータにアクセスできます。
- 財務ユーザーは、財務関連のデータにのみアクセスできます。
- 臨床監査人は、すべての患者のデータを見ることができます。
- すべてのユーザーは、共有データ ストアの基本的な医療知識にアクセスできます。
ドキュメント ベースの RAG アプリケーションでは、ドキュメントに割り当てられたタグ付けスキームまたは秘密度レベルに基づいて、ドキュメントへのユーザーのアクセスを制限できます。
テナントの定義を作成し、承認規則を明確に理解したら、その情報をデータ ストア ソリューションの要件として使用します。
データのフィルター処理
ユーザーがアクセスを許可されているデータのみにアクセスを制限することは、フィルタリング またはセキュリティトリミング と呼ばれます。 マルチテナント RAG シナリオでは、ユーザーがテナント固有のストアにマップされる可能性があります。 これは、ユーザーがそのストア内のすべてのデータにアクセスできることを意味するわけではありません。 テナントと承認の要件を定義、データの承認要件を定義することの重要性について説明します。 これらの承認規則は、フィルター処理の基礎として使用する必要があります。
行レベルのセキュリティなどのデータ プラットフォーム機能を使用して、フィルター処理を実装できます。 または、カスタム ロジック、データ、またはメタデータが必要な場合があります。 これらのプラットフォーム機能は、通常、マルチテナント ソリューションでは使用されません。これらの機能を中心にシステムを設計する必要があるためです。
マルチテナント データ ロジックをカプセル化する
使用するストレージ メカニズムの前に API を用意することをお勧めします。 この API はゲートキーパーのように機能し、ユーザーがアクセスを許可されている情報にのみアクセスできるようにします。
ユーザーのデータへのアクセスは、次の方法で制限できます。
- ユーザーのテナント。
- プラットフォーム機能。
- カスタム セキュリティ フィルターまたはトリミング規則。
API レイヤーは次の必要があります。
- テナントごとのストア モデルのテナント固有のストアにクエリをルーティングします。
- マルチテナント ストア内のユーザーのテナントのデータのみを選択します。
- プラットフォーム対応の承認ロジックをサポートするには、ユーザーに適した ID を使用します。
- カスタム セキュリティ トリミング ロジックを適用します。
- 監査目的で、グラウンド情報のアクセス ログを保存します。
テナント データにアクセスする必要があるコードでは、バックエンド ストアに直接クエリを実行することはできません。 データに対するすべての要求は、API レイヤーを通過する必要があります。 この API レイヤーは、テナント データの上に単一のガバナンスポイントまたはセキュリティを提供します。 この方法により、テナントとユーザーのデータ アクセス承認ロジックがアプリケーションの他の領域に到達できなくなります。 このロジックは API レイヤーにカプセル化されます。 このカプセル化により、ソリューションの検証とテストが容易になります。
概要
マルチテナント RAG 推論ソリューションを設計する場合は、テナントの基礎データ ソリューションを設計する方法を検討する必要があります。 テナントの数と、格納するテナントごとのデータの量について理解します。 この情報は、データ テナント ソリューションの設計に役立ちます。 マルチテナント ロジックやフィルター 処理ロジックなど、データ アクセス ロジックをカプセル化する API レイヤーを実装することをお勧めします。
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主な作成者:
- ジョン ダウンズ |プリンシパル ソフトウェア エンジニア
- ダニエル・スコット=レインズフォード |シニア パートナー ソリューション アーキテクト、データ & AI
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
関連リソース
- SaaS とマルチテナントソリューションのアーキテクチャ
- 基本的な OpenAI のエンド ツー エンド チャット参照アーキテクチャ
- ベースライン OpenAI エンドツーエンド チャット リファレンス アーキテクチャ
- ゲートウェイ を介して Azure OpenAI やその他の言語モデルにアクセスする