検索拡張生成 (RAG) パターンに含まれる LLM と Azure OpenAI のサンプル参照アーキテクチャ (プレビュー)

  • [アーティクル]

重要

これはプレビュー機能です。 この情報は、リリース前に大幅に変更される可能性のあるプレリリース機能に関するものです。 マイクロソフトは、ここで提供される情報に関して、明示または黙示を問わず、いかなる保証も行いません。

この記事では、検索拡張生成 (RAG) パターンのコンテキスト内で大規模言語モデル (LLM) と Azure OpenAI を使用する例を示します。 具体的には、重要なガードレールを考慮しながら、これらの技術をソブリン ランディング ゾーン内でどのように適用できるかを検討します。

シナリオ

一般的なシナリオは、LLM を使用して、 検索拡張生成 (RAG) パターン を通じて独自のデータを使用して会話を行うことです。 このパターンにより、LLM の推論機能を活用し、モデルを微調整することなく、特定のデータに基づいて応答を生成できます。 これにより、LLM を既存のビジネス プロセスまたはソリューションにシームレスに統合できるようになります。

Cloud for Sovereignty - AI と LLM の参照アーキテクチャ

Microsoft Cloud for Sovereignty は、Sovereign Landing Zone (SLZ) 内の一般的な Retrieval Augmented Generation (RAG) アーキテクチャを示す参照アーキテクチャを提供します。 一般的な推奨実装テクノロジの選択肢、用語、テクノロジの原則、一般的な構成環境、および適用可能なサービスの構成の概要を示します。

Sovereign AI および LLM 構成を参照してください。

このリファレンス アーキテクチャ図の 印刷用 PDF をダウンロードします。

主要な段階/データフローは次のとおりです。

アプリケーション ランディング ゾーン

管理グループ階層では、これらのサービスは非機密管理グループ内のサブスクリプションに配置されます。

データソースと変換パイプライン

多くの場合、データ ソースと変換パイプラインは、基幹業務の組織内に存在します。 RAG 実装などの LLM アプリケーションを既存のデータと統合すると、新しいワークロードになります。

データフロー制御を確実にするために、参照アーキテクチャでは、データ ソースに対して データ ドメイン が調整された データ ランディング ゾーン を推奨し、それらのソースの近くにデータ変換パイプラインを配置して、LLM アプリケーションで使用される データ製品 を作成します。 このアプローチにより、個別にホストされる LLM ベースのソリューションにプロビジョニングされたデータの正確な管理が保証されます。

データ変換コンポーネント は、さまざまなテクノロジとサービスを活用して、グラウンディングの目的でセマンティック検索またはベクトル検索を通じて LLM ベースのアプリケーションで検索および使用できる形式にデータを変換します。 これらのパイプラインは単独で動作することも、Azure AI サービスや OpenAI などの AI サービスを使用して、データを変換し、ベクター検索またはセマンティック検索データベースに格納することもできます。

AI サービスを使用する場合、ネットワーク ピアリングにより、常にプライベート エンドポイントを通じて (ハブ経由または直接) AI サービスが利用できるようになります。 ガバナンス、セキュリティ、コンプライアンス上の理由から、データ変換コンポーネントには、LLM ワークロードの検索データベースに提供されるデータとその形式を決定する権限があります。

データ変換コンポーネントは、さまざまな種類の データソース LLM ワークロードが依存する検索データベースに最適な結果のデータを提供します。 これらのデータ ソースは、顧客の環境に応じて、SQL データベース、データ レイク、またはカスタム データ ソリューションをホストする仮想マシンになる場合があります。

データ ソースは Orchestrator アプリから直接アクセスできないようにする必要がありますが、代わりにこれらのリソースは仮想ネットワークのプライベート境界内からのみ利用できる必要があります。 これは、Microsoft Azure 仮想ネットワーク (たとえば VM の場合と同様)、プライベート リンク サービス、または仮想ネットワーク サービス エンドポイント (プライベート リンクまたは仮想ネットワークの直接統合が利用できない場合のみ) の直接統合を意味します。

AI および LLM 関連のコンポーネントは、Corp または オンライン 管理グループ (パブリック アクセスが必要かどうかによって異なります) 下の独自のサブスクリプションでワークロードとしてホストされる必要があります。 これらのコンポーネントには、以下のものが含まれます:

Azure OpenAI サービス は、GPT や Ada などテキスト埋め込みのような LLM の操作をカプセル化し、OpenAI Orchestrator アプリによって提供される標準 API を通じてアクセスできるようにします。

Orchestrator アプリ は、API または UX ベースのインターフェースを備えたフロントエンドとして機能し、RAG ベースのエクスペリエンスを構築するために必要なさまざまなステップを調整します。 多くの場合、それは Web アプリケーションまたは Web API です。 これらの手順には通常次のものが含まれます:

  • セマンティック検索エンジンからデータを取得して即座に根拠を示す
  • 迅速なグラウンディングのためにデータソースからデータを取得する
  • 異なるリクエストを LLM に正しくチェーンする

Orchestrator アプリは、Azure が送信した要求と受信した応答の履歴を保持し、OpenAI サービスは以前のやり取りに基づいて確立されます。 たとえば、ChatGPT やBing Chat などのチャットに似たエクスペリエンスでは、Orchestrator アプリは会話セッションの履歴を維持またはキャッシュし、LLM サービス バックエンドによって会話フローで考慮されるようにします。

オンライン 環境では、Orchestrator アプリ エンドポイントが、Web アプリケーション ファイアウォールと DDoS 保護サービスによって保護されたパブリック エンドポイント を通じて提供される唯一のアプリである必要があります。 パブリック エンドポイントのない Corp 環境では、Orchestrator は、仮想マシンや VM スケール セットなどの Virtual Network に直接統合されたサービスでホストされるか、Azure App Services の場合のようにプライベート リンクまたは Virtual Network サービス エンドポイントをサポートするサービスを使用します。

検索サービス は、LLM サービスの迅速な基盤構築のために、さまざまなデータ ソースからのデータを効率的に使用できるように最適化された形式で提供します。 Microsoft は、Azure AI Search でサポートされている検索サービスに基づいて、プロンプト グラウンディングで最良の結果を達成するために、ベクトル化とセマンティック検索の組み合わせを提案しています。 セマンティック ランキング を使用すると、言語理解を使用して検索結果をランク付けすることで、検索の関連性が大幅に向上します。 これにより、LLM にリクエストを送信する前に検索サービスからの検索結果が改善され、プロンプトのグラウンディングがより正確になるため、RAG アプリケーションのユーザー エクスペリエンスが向上します。

AI サービスの組み合わせ を使用すると、Orchestrator を通じてエンドユーザー向けにカスタマイズされたエクスペリエンスを作成したり、データ取り込みプロセスを最適化したりできます。 Azure AI Document Intelligence などのフォーム認識サービスを使用して、フォームから構造化された情報を抽出し、ユーザー入力を効率的に処理して要約することを想像してみてください。 このサービスは、LLM と連携して、認識されたフォーム入力からの主要な調査結果を要約できます。 もうひとつのシナリオでは、ドキュメント認識サービスを使用して、PDF や Word ドキュメントなどのさまざまな形式のドキュメントをテキストに変換します。 その後、LLM テキスト埋め込みサービスによって、認識されたテキストがベクトル化され、さらに分析されます。

プライベート リンク サービス はすべてのコンポーネントに展開され、すべてのサービスがプライベート環境内でのみアクセス可能になります。 唯一の例外は Orchestrator アプリです。このアプリが オンライン ランディング ゾーンでホストされている場合、Web アプリケーション ファイアウォールまたは同等のサービスの背後でパブリックに提供される可能性があります。

インフラストラクチャ コンポーネント

インフラストラクチャ コンポーネントは、ワークロードの一部としてホストすることも、ハブまたは ID サブスクリプションで集中的にホストすることもできます。

Sovereign Landing Zone 実装の中心的なインフラストラクチャ コンポーネントは、プラットフォーム接続ハブです。これは、すべての Sovereign Landing Zone 展開によって提供される 仮想ネットワーク です。 これは、プラットフォーム管理グループ内の接続サブスクリプションに配置されます。

共有ネットワーク コンポーネントは、ハブ仮想ネットワークに配置されます。 これらのコンポーネントには、一般的に以下のものが含まれます:

  • 企業、機関、または組織の企業ネットワークへの接続用の ExpressRoute 回線 または VPN ゲートウェイ。

  • ファイアウォール は、アプライアンスまたは Web アプリケーション ファイアウォールを含む Azure Firewall サービスの組み合わせを使用して実装できます。 これらのソリューションにより、トラフィックの検査、フィルタリング、ルーティングが可能になります。

  • 分散型サービス拒否攻撃からワークロードを保護する DDoS 保護 コンポーネント。

  • ランディング ゾーンを使用して実装された仮想データ センター ランドスケープ全体で使用されるすべてのタイプのサービス用のプライベート DNS ゾーン。

  • ハブ ネットワークを介してデータ ソース、変換、LLM コンポーネントなどのさまざまなワークロードの仮想ネットワークを接続する Virtual Network ピアリング。

  • ポリシー は、必要に応じてハブのファイアウォールを通過するトラフィック フローを制御します。

考慮事項

参照アーキテクチャ図は、Sovereign Landing Zone のコンテキストにおける LLM RAG ベースのワークロードの一般的なコンポーネントを含む代表的なサンプル アーキテクチャを示しています。 前のセクションでは説明しなかった、留意すべき考慮事項がいくつかあります。

Well-Architected フレームワークとクラウド導入フレームワークの原則との整合

前のセクションでは、Well-Architected フレームワーク (WAF) とクラウド導入フレームワーク (CAF) に関連するいくつかの調整の側面について簡単に説明しました。 すべてのアーキテクチャ上の決定は、CAF と Azure Landing Zones、 CAF クラウド スケール分析、 WAF ( Azure における WAF の分析観点 OpenAIを含む) の基本原則と完全に一致している必要があることに注意することが重要です。

ガードレールの取り扱いはランディング ゾーン環境では標準的な手順ですが、LLM および AI ワークロードについてはいくつかの領域で他の考慮事項を行う必要があります。 ワークロード サブスクリプションのインフラストラクチャを設計および定義する際には、Azure セキュリティ基準のコンプライアンス と Sovereignty Baseline Policy イニシアチブの標準 に従うことが最適です。

これらの標準から LLM RAG ベースのアプリケーションに関して強調すべき主な考慮事項は次のとおりです:

データ所在地とリージョンの選択

Sovereignty により、データ所在地に厳格な要件が課せられるため、SLZ 内の特定の Azure リージョンへの展開が制限される可能性があります。 LLM ワークロードのリージョンの選択は、必要なサービスの可用性によって制限されます。

  • データ所在地や近接性の理由から、データとワークロードをホストするターゲット リージョンで Azure OpenAI と Azure AI Search の両方が使用可能であることを確認します。 さらに、これらのサービスは、パフォーマンスの観点から、エンドユーザーのアプリケーション エクスペリエンスにとって重要です。

  • 2 番目に、Azure OpenAI を見ると、すべてのモデルがすべての地域で同じように利用できるわけではないため それぞれの LLM モデルの可用性 が重要となります

  • 指定したターゲット リージョンでデータ ソースやその他のコグニティブ サービスが利用できない場合は、データ所在地要件に合わせて別のリージョンでそれらを見つけて操作できる可能性があります。 しかし、パフォーマンス上の理由から、Azure OpenAI サービスと Azure AI Search は Orchestrator アプリと同じリージョンに存在する必要があります。

ネットワーク

パブリックエンドポイントは Corp 環境で許可されていません。 したがって、すべてのサービスを Virtual Network にカプセル化する必要があります。 サービスによっては、VM または AKS クラスター、プライベート リンク、Virtual Network サービス エンドポイントなどの直接カプセル化機能が提供される場合があります。 Virtual Network サービス エンドポイントは、可能な限り Private Link に置き換える必要があります。

カプセル化に加えて、すべてのサービスに対してパブリック アクセスを無効にする必要があります。 最後に、対応する拒否ポリシーを構築できないサービスに対してパブリック アクセスが誤って有効にならないように、Azure Policy を使用したポリシー適用を有効にする必要があります。 多層防御戦略では、すべてのサービスに対して対応する監査機能を有効にします。

保管中および転送中のデータの暗号化

Azure のほとんどのサービスは、転送中の暗号化と保存時の暗号化の両方の機能をサポートしています。 利用可能な場合は、すべてのサービスで保存時および転送時の暗号化を有効にします。 転送暗号化には、最新の TLS バージョン (現在は TLS 1.2) を有効にします。

マネージド ID

資格情報のシークレットを管理する必要がないように、すべてのサービスとサービス間通信にマネージド ID を使用します。

Key Vault でのキー ローテーション

証明書などのセキュリティ資産が必要な場合は、コンプライアンスを維持するために、Key Vault 内のそれらのシークレットのキーローテーションを有効にします。

ネットワークおよびアプリケーション セキュリティ グループ

独立した安全な環境では、ネットワーク セキュリティ グループ (NSG) とアプリケーション セキュリティ グループ (ASG) の使用が強制されます。 セキュリティ グループが欠落していると、準拠していない展開が発生します。 通常の SSL ポートは HTTPS に基づいているため、LLM/RAG ワークロードが依存するほとんどのサービスに役立ちます。 ソースから検索データベースおよびベクター データベースへのデータ取り込みには、特定のポートが必要です。 パブリック IP は Corp ランディング ゾーンで許可されていません。 すべてのサービスは仮想ネットワーク内でのみアクセス可能である必要があるため、PaaS サービスにはプライベート リンクまたは仮想ネットワークのサービス エンドポイントを使用する必要があります。

さらなるセキュリティと主権のガードレール

前のセクションで説明したインフラストラクチャとアプリケーションの設計に関する最も重要かつ明白なガードレールは、Sovereign または Azure Landing Zone の外部でも再利用できます。 その他のグローバル ポリシーは、Log Analytics ワークスペースやエンタープライズ規模のランディング ゾーン内の Microsoft Sentinel 展開など、集中管理されるリソースに関連付けられています。 インフラストラクチャとアプリケーションの設計プロセスでは、これらの集中管理対象リソースを考慮することが重要です。 これを怠ると、展開後に追加の労力と時間が発生する可能性があります。 幸いなことに、Azure のポリシー コンプライアンス機能では、デプロイ後に非準拠のリソースを識別できます。 さらに、Sovereign Landing Zone と Azure Landing Zone はどちらも、多数のリソースに対して DeployIfNotExists ポリシーを提供するため、プロセスがさらに簡素化されます。

こういったガードレールの例は次のとおりです。

  • 一元管理された Log Analytics ワークスペースへのログインのアクティブ化。

  • Azure Security Center または Microsoft Defender for Cloud との統合。

  • Microsoft Sentinel などのセキュリティ情報およびイベント管理 (SIEM) スイートとの統合。

  • 集中管理されたファイアウォール、Web アプリケーション ファイアウォール、または DDoS Protection との統合。

これらは、最初の展開後に要件として特定できるガードレールのほんの一部です。 テスト ランディング ゾーンで展開をテストし、それらのガードレールの実現をインフラストラクチャとアプリケーション コードベースに反復的に統合することをお勧めします。 それが完全に不可能な場合は、これらのガードレールの多くは、DeployIfNotExists ポリシーを使用して、展開後に対処できます。

次のようなシナリオを展開する

Sovereign Landing Zones 内で、Retrieval Augmented Generation (RAG) パターン に基づく Large Language Models (LLM) と Azure OpenAI を活用するには、まず Sovereign Landing Zone (SLZ) を展開して構成し、Sovereignty Baseline ポリシー イニシアチブを適用する必要があります。 SLZ とそのすべての機能の詳細な概要については、GitHub の ソブリン ランディング ゾーン ドキュメントを参照してください。

SLZ は、ポリシーとポリシー セット、セキュリティの適用、ワークロードとアプリケーションを展開するための一貫したベースライン インフラストラクチャを通じてガードレールを提供する環境を提供します。 SLZ は、Azure Landing Zones をベースに、主権要件に特化したガードレールとセキュリティ制御で拡張したものです。

Microsoft Cloud for Sovereignty は、コンプライアンス目標の達成を支援すると同時に、顧客の Time-to-Value を加速するために、一貫した展開と反復可能な方法で運用できる、すぐに使えるワークロードのテンプレートを搭載しています。 ワークロード テンプレートは、ソブリン ベースライン ポリシーの取り組み、ソブリン ポリシー ポートフォリオのクラウド、Azure ランディング ゾーンの既定ポリシー に準拠しています。

情報アシスタント アクセラレータ

情報アシスタントはソリューション アクセラレータであり、組織が独自のカスタム生成 AI 機能を構築して、Azure OpenAI の機能を組織のユーザーとそのプライベート ドメイン データに拡張するための出発点となります。 これは Cloud for Sovereignty 内に展開でき、この記事で提供されている参照アーキテクチャとガイダンスに準拠しています。 アクセラレータは、内部ワークロード用には Corp ランディング ゾーン内に、パブリック アクセス用には オンライン ランディング ゾーンへの展開をセキュリティで保護するガイダンスに厳密に従うことをお勧めします。

アクセラレータは、顧客とパートナーに無料で提供されるコード、説明書、教育リソースの組み合わせであり、価値実現までの時間を短縮するのに役立ちます。

Information Assistant アクセラレータの展開と構成方法の詳細については、GitHub の 情報アシスタント 説明書を参照してください。 このアクセラレータで実現できる可能性のある使用事例については、情報アシスタントのビデオ を参照してください。