エンタープライズ チャット アプリケーションは、会話による対話を通じて従業員を支援することができます。 これは、OpenAI の GPT モデルや Meta の LLaMA モデルなどの言語モデルが継続的に進歩しているため、特に当てはまります。 これらのチャット アプリケーションを構成しているのは、チャット ユーザー インターフェイス、ユーザーのクエリに関連するドメイン固有の情報を含むデータ リポジトリ、ドメイン固有のデータについて推論して関連性の高い応答を生成する言語モデル、そしてこれらのコンポーネント間の相互作用を監視するオーケストレーターです。
この記事では、Azure OpenAI Service の言語モデルを使用するエンタープライズ チャット アプリケーションを構築およびデプロイするためのベースライン アーキテクチャについて説明します。 このアーキテクチャでは、プロンプト フローを使用して実行可能フローを作成します。 これらの実行可能フローは、受信プロンプトからデータ ストアへのワークフローを調整して、言語モデル用にグラウンディングするデータを他の必要な Python ロジックと共にフェッチします。 実行可能フローは、マネージド コンピューティングを使用してマネージド オンライン エンドポイントにデプロイされます。
カスタム チャット ユーザー インターフェイス (UI) のホスティングは、セキュリティで保護されたゾーン冗長で高可用性の Web アプリケーションを Azure アプリ Service にデプロイするためのベースライン アプリ サービス Web アプリケーションのガイダンスに従います。 そのアーキテクチャでは、App Service は、プライベート エンドポイントを介した仮想ネットワーク統合を通じて Azure PaaS (サービスとしてのプラットフォーム) ソリューションと通信を行います。 チャット UI App Service は、プライベート エンドポイント経由でフローのマネージド オンライン エンドポイントと通信を行います。 Azure AI Studio へのパブリック アクセスは無効になっています。
重要
この記事では、ベースライン App Service Web アプリケーションのコンポーネントやアーキテクチャの決定については説明しません。 チャット UI をホストする方法に関するアーキテクチャ ガイダンスについては、その記事をお読みください。
Azure AI Studio ハブは、 管理された仮想ネットワーク分離を使用して構成されます すべての送信接続を承認する必要があります。 この構成では、マネージド仮想ネットワークが、プライベート リソース (職場の Azure Storage、Azure Container Registry、Azure OpenAI など) への接続を可能にするマネージド プライベート エンドポイントと共に作成されます。 これらのプライベート接続は、フローの作成とテスト中に使用され、また Machine Learning コンピューティングにデプロイされたフローによっても使用されます。
ハブは、セキュリティ、接続性、およびその他の懸念事項を複数のプロジェクトにわたって管理するための中心的な方法を提供する最上位の Azure AI Studio リソースです。 このアーキテクチャでは、ワークロードに必要なプロジェクトは 1 つだけです。 異なるロジックで異なるプロンプト フローを必要とする追加のエクスペリエンスがあり、データ ストアなどの異なるバックエンド リソースを使用する可能性がある場合は、それらを別のプロジェクトに実装することを検討してください。
ヒント
この記事は、Azure でのベースラインのエンド ツー エンドのチャット実装を紹介する参照実装によって裏付けられます。 この実装は、実稼働に向けた最初のステップとして、カスタム ソリューション開発の基盤として使用できます。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
コンポーネント
このアーキテクチャの多くのコンポーネントは、基本的な Azure OpenAI エンドツーエンド チャット アーキテクチャと同じです。 次のリストでは、基本的なアーキテクチャに対する変更のみを強調しています。
- Azure OpenAI は、このベースライン アーキテクチャと基本アーキテクチャの両方で使用されます。 Azure OpenAI は、GPT-4、GPT-3.5-Turbo、埋め込みのモデル セットなど、Azure OpenAI の言語モデルへの REST API アクセスを提供するフル マネージド サービスです。 ベースライン アーキテクチャでは、基本的なアーキテクチャが実装していない 仮想ネットワークやプライベート リンク などのエンタープライズ機能を利用します。
- Azure AI Studio は、AI ソリューションの構築、テスト、デプロイに使用できるプラットフォームです。 このアーキテクチャでは、AI Studio を使用して、チャット アプリケーションのプロンプト フロー オーケストレーション ロジックを構築、テスト、デプロイします。 このアーキテクチャでは、Azure AI Studio は、ネットワーク セキュリティのために 管理された仮想ネットワーク を提供します。 詳細については、「 networking」セクション を参照してください。
- Application Gateway は、レイヤー 7 (HTTP/S) のロード バランサーおよび Web トラフィック ルーターです。 URL パスベースのルーティングを使用して、受信トラフィックを可用性ゾーン間で分散し、暗号化をオフロードしてアプリケーションのパフォーマンスを向上させます。
- Web Application Firewall (WAF) は、SQL インジェクションやクロスサイト スクリプティングなどの一般的な悪用から Web アプリを保護するクラウドネイティブ サービスです。 Web Application Firewall を使用すると、Web アプリケーションとの間のトラフィックを可視化できるため、アプリケーションを監視してセキュリティで保護できます。
- Azure Key Vault は、シークレット、暗号化キー、証明書を安全に格納および管理するサービスです。 機密情報の管理を一元化します。
- Azure 仮想ネットワークは、Azure で分離された安全なプライベート仮想ネットワークを作成できるサービスです。 App Service 上の Web アプリケーションの場合は、リソース間のネットワーク セキュア通信にプライベート エンドポイントを使用するための仮想ネットワーク サブネットが必要です。
- Private Link を使用すると、クライアントはパブリック IP アドレス指定を使用せずに、プライベート仮想ネットワークから直接 Azure サービスとしてのプラットフォーム (PaaS) サービスにアクセスできます。
- Azure DNS は、DNS ドメインのホスティング サービスであり、Microsoft Azure インフラストラクチャを使用した名前解決を提供します。 プライベート DNS ゾーンは、サービスの完全修飾ドメイン名 (FQDN) をプライベート エンドポイントの IP アドレスにマップする方法を提供します。
代替
このアーキテクチャには、ワークロードの機能要件と非機能要件に適した他の Azure サービスによって提供される可能性のある複数のコンポーネントがあります。 注意すべきそのような代替手段をいくつか次に示します。
Azure Machine Learning ワークスペース (およびポータル エクスペリエンス)
このアーキテクチャでは、 Azure AI Studio を使用して、プロンプト フローを構築、テスト、デプロイします。 また、 Azure Machine Learning ワークスペースを使用することもできます。両方のサービスに重複する機能があります。 プロンプト フロー ソリューションを設計する場合は AI Studio が適していますが、Azure Machine Learning で現在サポートが強化されている機能がいくつかあります。 詳細については、 機能の比較を参照してください。 Azure AI Studio と Azure Machine Learning を組み合わせないようにすることをお勧めします。 AI Studio で作業を完全に行うことができる場合は、AI Studio を使用します。 Azure Machine Learning スタジオの機能が引き続き必要な場合は、Azure Machine Learning スタジオを引き続き使用してください。
アプリケーション層コンポーネント
Azure には、チャット UI フロントエンドのアプリケーション層として機能するマネージド アプリケーション サービスオファリングがいくつか用意されています。 コンテナー ソリューションについては、「 Azure コンピューティング サービスの と Azure コンテナー サービスの の選択 」を参照してください。 たとえば、チャット UI API とプロンプト フロー ホストの両方に対して Azure Web Apps と Web App for Containers をそれぞれ選択した場合、Azure Kubernetes Service (AKS) または Azure Container Apps でも同様の結果が得られます。 ワークロードの特定の機能要件と非機能要件に基づいて、ワークロードのアプリケーション プラットフォームを選択します。
プロンプト フローのホスティング
プロンプト フローのデプロイは Machine Learning コンピューティング クラスターに限定されるものではなく、このアーキテクチャは、Azure アプリ Service の代替手段を使用してこれを示しています。 フローは最終的にコンテナー化されたアプリケーションであり、コンテナーと互換性のある任意の Azure サービスにデプロイできます。 これらのオプションには、Azure Kubernetes Service (AKS)、Azure Container Apps、Azure アプリ Service などのサービスが含まれます。 オーケストレーション レイヤーの要件に基づいて Azure コンテナー サービスを選択します。
代替コンピューティングでのプロンプト フロー ホスティングをホストする理由の例については、この記事の後半で説明します。
データ ストアの接地
このアーキテクチャは Azure AI Search を利用しますが、グラウンド データ用のデータ ストアの選択は、ワークロードに固有のアーキテクチャ上の決定です。 多くのワークロードは実際にはポリグロットであり、データを接地するためのさまざまなソースとテクノロジを持っています。 これらのデータ プラットフォームは、既存の OLTP データ ストア、Azure Cosmos DB などのクラウド ネイティブ データベースから、Azure AI Search などの特殊なソリューションまで多岐に分けられます。 このようなデータ ストアの一般的な特性は、必須ではありませんが、ベクター検索です。 この領域のオプションについては、「 ベクター検索用の Azure サービスを選択する 」を参照してください。
考慮事項と推奨事項
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
ベースラインの App Service Web アプリケーション アーキテクチャでは、主要なリージョン サービスのゾーン冗長に重点を置いています。 可用性ゾーンは、リージョン内の物理的に分離された場所です。 2 つ以上のインスタンスがリージョン全体にデプロイされている場合、リージョン内にサポート サービスに対する冗長が提供されます。 1 つのゾーンでダウンタイムが発生しても、リージョン内の他のゾーンは影響を受けない場合もあります。 このアーキテクチャを使用すると、Azure サービスの十分なインスタンスとそれらのサービスの構成が可用性ゾーンに確実に分散されるようになります。 詳細については、ベースラインを参照して、ガイダンスを確認してください。
このセクションでは、Machine Learning、Azure OpenAI、AI Search など、App Service ベースラインで扱われていないこのアーキテクチャのコンポーネントの観点から信頼性について説明します。
フロー デプロイのゾーン冗長
通常、エンタープライズ デプロイには、ゾーン冗長が必要です。 Azure でゾーン冗長を実現するには、リソースが可用性ゾーンをサポートしている必要があり、リソースのインスタンスを少なくとも 3 つデプロイするか、インスタンス制御が利用できない場合にはプラットフォーム サポートを有効にする必要があります。 現在、Machine Learning コンピューティングは、可用性ゾーンのサポートを提供していません。 データセンター レベルの大災害による Machine Learning コンポーネントへの潜在的な影響を軽減するには、さまざまなリージョンにクラスターを確立すると共に、Load Balancer をデプロイしてこれらのクラスター間で呼び出しを分散する必要があります。 ヘルス チェックを使用すると、呼び出しが適切に機能しているクラスターにのみルーティングされるのを確実にすることができます。
Azure Kubernetes Service (AKS)、Azure Functions、Azure Container Apps、Azure アプリ Service などの Machine Learning コンピューティング クラスターには、いくつかの代替手段があります。 これらの各サービスでは、可用性ゾーンがサポートされています。 マルチリージョン デプロイをさらに複雑化させることなく、プロンプト フロー実行のゾーン冗長を実現するには、これらのサービスのいずれかにフローをデプロイする必要があります。
次の図では、プロンプト フローが Azure App Service にデプロイされる代替アーキテクチャを示しています。 このアーキテクチャで App Service が使用されるのは、ワークロードがすでにチャット UI に App Service を使用しており、ワークロードに新しいテクノロジを導入してもメリットが得られないためです。 AKS の使用経験があるワークロードチームは、特に AKS がワークロード内の他のコンポーネントに使用されている場合は、その環境へのデプロイを検討する必要があります。
この図では、このアーキテクチャで注目すべき領域に番号が付けられています。
フローはプロンプト フローで作成され、ネットワーク アーキテクチャは変更されません。 フロー作成者は引き続きプライベート エンドポイントを介して AI Studio プロジェクトのオーサリング エクスペリエンスに接続し、マネージド プライベート エンドポイントはフローのテスト時に Azure サービスへの接続に使用されます。
この点線は、コンテナー化された実行可能フローが Container Registry にプッシュされることを示しています。 この図には、フローをコンテナ化して Container Registry にプッシュするパイプラインは示されていません。 これらのパイプラインが実行されるコンピューティングは、Azure コンテナー レジストリや AI Studio プロジェクトなどのリソースに対するネットワークの見通し線を持っている必要があります。
チャット UI を既にホストしている同じ App Service プランにデプロイされた別の Web アプリがあります。 新しい Web アプリは、コンテナー化されたプロンプト フローをホストします。これは、可用性ゾーン全体に分散された、少なくとも 3 つのインスタンスで既に実行されているのと同じ App Service プランに併置されています。 これらの App Service インスタンスは、プロンプトフロー コンテナー イメージを読み込むときに、プライベート エンドポイント経由で Container Registry に接続します。
プロンプトフロー コンテナーは、フローを実行するためにすべての依存サービスに接続する必要があります。 このアーキテクチャでは、プロンプト フロー コンテナーは AI Search と Azure OpenAI に接続します。 Machine Learning マネージド プライベート エンドポイント サブネットにのみ公開されていた PaaS サービスも、App Service から通信経路を確立できるようにするために、現在では仮想ネットワークで公開することが必要となっています。
Azure OpenAI - 信頼性
Azure OpenAI では現在、可用性ゾーンはサポートされていません。 データセンター レベルの大災害による Azure OpenAI のモデルのデプロイへの潜在的な影響を軽減するには、ロードバランサーをデプロイしてリージョン間で呼び出しを分散すると共に、Azure OpenAI をさまざまなリージョンにデプロイする必要があります。 ヘルス チェックを使用すると、呼び出しが適切に機能しているクラスターにのみルーティングされるのを確実にすることができます。
複数のインスタンスを効果的にサポートするには、チューニング ファイルを geo 冗長ストレージ アカウントなどに外部化することをお勧めします。 この方法では、リージョンごとに Azure OpenAI に格納されている状態が最小限に抑えられます。 モデル デプロイをホストするには、各インスタンスのファイルを引き続き微調整する必要があります。
1 分あたりのトークン数 (TPM) と 1 分あたりの要求数 (RPM) の観点から、必要なスループットを監視することが重要です。 デプロイの需要を満たすのに十分な TPM がクォータから割り当てられていることを確認し、デプロイされたモデルの呼び出しがスロットリングされないようにしてください。 Azure API Management などのゲートウェイは、Azure OpenAI サービスまたはサービスの前にデプロイでき、一時的なエラーや調整がある場合は再試行するように構成できます。 API Management は、サービスが呼び出しで一杯になり、クォータを超過するのを防止するためのブレーカー (遮断機) としても使用できます。 信頼性の問題に関するゲートウェイの追加の詳細については、「 ゲートウェイ経由で Azure OpenAI やその他の言語モデルにアクセスするを参照してください。
AI Search - 信頼性
可用性ゾーンをサポートするリージョンに Standard 価格レベル以上の AI Search をデプロイし、3 つ以上のレプリカをデプロイします。 レプリカは、可用性ゾーン全体に自動的に均等に分散されます。
レプリカとパーティションの適切な数を決定するために、次のガイダンスを考慮してください。
クエリベースのスロットリングやパーティションを回避し、インデックスベースのスロットリングを回避するために、監視メトリックやログおよびパフォーマンス分析を使って適切なレプリカ数を決定します。
Azure AI Studio - 信頼性
Machine Learning マネージド オンライン エンドポイントの背後にあるコンピューティング クラスターにデプロイする場合は、スケーリングに関する次のガイダンスを検討してください。
オンライン エンドポイントを自動的にスケールして、需要を満たすのに十分な容量を確保します。 バーストの使用が原因で使用シグナルの適時性が十分とは言えない場合は、オーバープロビジョニングを検討して、使用できるインスタンスが少なすぎることによる信頼性への影響を防ぐようにしてください。
CPU 負荷などのデプロイ メトリックと、要求の待機時間などのエンドポイント メトリックに基づいたスケーリング規則の作成を検討してください。
アクティブな運用デプロイには、3 つ以上のインスタンスをデプロイする必要があります。
使用中のインスタンスに対するデプロイは避けてください。 代わりに、新しいデプロイにデプロイし、デプロイでトラフィックの受信準備ができたら、トラフィックをシフトします。
マネージド オンライン エンドポイントは、その背後で実行されているマネージド コンピューティングのロード バランサーおよびルーターとして機能します。 各デプロイにルーティングするトラフィックの割合は、パーセンテージが最大 100% に加算される限り構成できます。 また、0% のトラフィックが任意のデプロイにルーティングされるマネージド オンライン エンドポイントをデプロイすることもできます。 提供されている参照実装と同様に、コードとしてのインフラストラクチャ (IaC) を使用して、マネージド オンライン エンドポイントを含むリソースをデプロイする場合は、信頼性の問題があります。 デプロイ (CLI または Azure AI Studio を使用して作成) にルーティングするようにトラフィックが構成されていて、マネージド オンライン エンドポイントを含む後続の IaC デプロイを実行する場合、マネージド オンライン エンドポイントが更新されない場合でも、エンドポイント トラフィックは 0% のトラフィックのルーティングに戻ります。 実際には、これは、トラフィックを目的の場所に調整するまで、デプロイされたプロンプト フローに到達できなくなることを意味します。
Note
フローを APP Service にデプロイする場合は、ベースライン アーキテクチャから同じ App Service スケーラビリティに関するガイダンスが適用されます。
複数リージョンの設計
このアーキテクチャは、マルチリージョン アーキテクチャのリージョン スタンプとして構築されていません。 可用性ゾーンが完全に使用されているため、1 つのリージョン内で高可用性が提供されますが、マルチリージョン ソリューションに対してこれを本当に準備するための重要なコンポーネントがいくつかあります。 このアーキテクチャに含まれていないいくつかのコンポーネントまたは考慮事項を次に示します。
- グローバルイングレスとルーティング
- DNS 管理戦略
- データ レプリケーション (または分離) 戦略
- アクティブ/アクティブ/パッシブ/アクティブ/コールドの指定
- ワークロードの RTO と RPO を実現するためのフェールオーバーとフェールバックの戦略
- Azure Studio Hub リソースでの開発者エクスペリエンスのリージョンの可用性に関する決定
ワークロードの要件に複数リージョンの戦略が必要な場合は、このアーキテクチャに記載されている内容に加えて、コンポーネントと運用プロセスに関する追加の設計作業に投資する必要があります。 負荷分散またはフェールオーバーは、次のレイヤーでサポートするように設計します。
- グラウンディング データ
- モデルのホスティング
- オーケストレーション レイヤー (このアーキテクチャでのプロンプト フロー)
- クライアント側 UI
さらに、監視、ポータル エクスペリエンス、コンテンツの安全性などの責任ある AI の問題でビジネス継続性を維持する必要があります。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
このアーキテクチャでは、Azure OpenAI アーキテクチャを使用した基本的なエンドツーエンド チャットで実装されているセキュリティ フットプリントを拡張しています。 基本アーキテクチャでは、システム割り当てマネージド ID とシステム割り当てロールの割り当てが使用されますが、このアーキテクチャでは、手動で作成されたロールの割り当てとユーザー割り当て ID が使用されます。
このアーキテクチャでは、基本アーキテクチャで実装されている ID 境界と共に、ネットワーク セキュリティ境界が実装されています。 ネットワークの観点から見ると、インターネットからアクセスできる必要があるのは、Application Gateway を介したチャット UI のみです。 ID の観点から見ると、チャット UI は要求を認証し、承認する必要があります。 可能な場合は、マネージド ID を使用して、アプリケーションを Azure サービスに対して認証します。
このセクションでは、ネットワークに関する考慮事項と共に、キーローテーションと Azure OpenAI モデルの微調整に関するセキュリティに関する考慮事項について説明します。
ID 管理とアクセス管理
ユーザー割り当てマネージド ID を使用する場合は、次のガイダンスを検討してください。
- 必要に応じて、次の Azure AI Studio と Machine Learning リソース用に個別のマネージド ID を作成します。
- AI Studio ハブ
- フローの作成と管理のための AI Studio プロジェクト
- フローがマネージド オンライン エンドポイントにデプロイされている場合の、デプロイされたフローのオンライン エンドポイント
- Microsoft Entra ID を使用することで、チャット UI の ID アクセス制御を実装します。
アクセス許可の観点から他のユーザーから分離するさまざまなプロンプト フローに対して、個別のプロジェクトとオンライン エンドポイントを作成します。 プロジェクトとマネージド オンライン エンドポイントごとに個別のマネージド ID を作成します。 プロンプト フロー作成者に、必要なプロジェクトにのみアクセスできるようにします。
作成フローなどの機能を実行するためにユーザーを Azure AI Studio プロジェクトにオンボードする場合は、必要なリソースに最小限の特権ロールの割り当てを行う必要があります。
Machine Learning のロールベースのアクセス ロール
基本アーキテクチャと同様に、システムはシステム割り当てマネージド ID のロールの割り当てを自動的に作成します。 使用できるハブとプロジェクトの機能がシステムで認識されないため、すべての潜在的な機能をサポートするロールの割り当てが作成されます。 自動的に作成されたロールの割り当ては、ユース ケースに基づいてプロビジョニング特権を超える可能性があります。 たとえば、コンテナー レジストリのハブに割り当てられた "共同作成者" ロールでは、コントロール プレーンへの "閲覧者" アクセスのみが必要になる可能性があります。 最小限の特権目標のためにアクセス許可をさらに制限する必要がある場合は、ユーザー割り当て ID を使用する必要があります。 これらのロールの割り当てを自分で作成して維持します。
必要なすべての割り当てを管理するメンテナンスの負担のため、このアーキテクチャは、絶対最小特権ロールの割り当てよりもオペレーショナル エクセレンスを優先します。 テーブルに一覧表示されているすべての割り当てを行う必要があることに注意してください。
| マネージド ID | 範囲 | ロールの割り当て |
|---|---|---|
| ハブマネージド ID | Contributor | リソース グループ |
| ハブマネージド ID | ハブ | Azure AI 管理者 |
| ハブマネージド ID | Container Registry | Contributor |
| ハブマネージド ID | Key Vault | Contributor |
| ハブマネージド ID | Key Vault | 管理者 |
| ハブマネージド ID | ストレージ アカウント | Reader |
| ハブマネージド ID | ストレージ アカウント | Storage Account Contributor |
| ハブマネージド ID | ストレージ アカウント | ストレージ Blob データ共同作成者 |
| ハブマネージド ID | ストレージ アカウント | ストレージ ファイル データ権限付き共同作成者 |
| ハブマネージド ID | ストレージ アカウント | ストレージ テーブル データ共同作成者 |
| プロジェクトのマネージド ID | Project | Azure AI 管理者 |
| プロジェクトのマネージド ID | Container Registry | Contributor |
| プロジェクトのマネージド ID | Key Vault | Contributor |
| プロジェクトのマネージド ID | Key Vault | 管理者 |
| プロジェクトのマネージド ID | ストレージ アカウント | Reader |
| プロジェクトのマネージド ID | ストレージ アカウント | Storage Account Contributor |
| プロジェクトのマネージド ID | ストレージ アカウント | ストレージ Blob データ共同作成者 |
| プロジェクトのマネージド ID | ストレージ アカウント | ストレージ ファイル データ権限付き共同作成者 |
| プロジェクトのマネージド ID | ストレージ アカウント | ストレージ テーブル データ共同作成者 |
| オンライン エンドポイントのマネージド ID | Project | Azure Machine Learning ワークスペースの接続シークレット |
| オンライン エンドポイントのマネージド ID | Project | AzureML メトリック ライター |
| オンライン エンドポイントのマネージド ID | Container Registry | ACRPull |
| オンライン エンドポイントのマネージド ID | Azure OpenAI | Cognitive Services OpenAI ユーザー |
| オンライン エンドポイントのマネージド ID | ストレージ アカウント | ストレージ Blob データ共同作成者 |
| オンライン エンドポイントのマネージド ID | ストレージ アカウント | ストレージ BLOB データ閲覧者 |
| App Service (プロンプト フローが App Service にデプロイされている場合) | Azure OpenAI | Cognitive Services OpenAI ユーザー |
| ポータル ユーザー (プロンプト フロー開発) | Azure OpenAI | Cognitive Services OpenAI ユーザー |
| ポータル ユーザー (プロンプト フロー開発) | ストレージ アカウント | ストレージ BLOB データ共同作成者 (条件付きアクセスを使用) |
| ポータル ユーザー (プロンプト フロー開発) | ストレージ アカウント | ストレージ ファイル データ権限付き共同作成者 |
AI Studio ハブには、ストレージ アカウントやコンテナー レジストリなどのプロジェクト間で共有される Azure リソースがあることを理解しておくことが重要です。 プロジェクトのサブセットにのみアクセスする必要があるユーザーがいる場合は、 ロール割り当て条件をサポートする Azure サービスに対して、リソースへの最小限の特権アクセスを提供することを検討してください。 たとえば、Azure Storage の BLOB はロールの割り当て条件をサポートします。 プロジェクトのサブセットへのアクセスを必要とするユーザーの場合、コンテナーごとにアクセス許可を割り当てる代わりに、ロール アクセス条件を使用して、それらのプロジェクトで使用される BLOB コンテナーへのアクセス許可を制限します。 各プロジェクトには、そのプロジェクトで使用される BLOB コンテナーの名前のプレフィックスとして機能する一意の GUID があります。 その GUID は、ロールの割り当て条件の一部として使用できます。
ハブには、ハブリソースとプロジェクト リソースの作成と管理を許可するために、ハブ リソース グループへの Contributor アクセス権が必要です。 ハブがリソース グループ内の任意のリソースに対するコントロール プレーン アクセス権を持つという副作用。 ハブとそのプロジェクトに直接関連しない Azure リソースは、別のリソース グループに作成する必要があります。 セルフマネージド Azure AI Studio Hub を使用して、ワークロード チーム用に少なくとも 2 つのリソース グループを作成することをお勧めします。 ハブ、そのプロジェクト、および Azure コンテナー レジストリ、Key Vault などの直接の依存関係をすべて含む 1 つのリソース グループ。 ワークロード内の他のすべてを含む 1 つのリソース グループ。
ワークロード内の他のコンポーネントによるハブの操作 (Container Registry、ストレージ アカウント、Key Vault、Application Insights) に必要な Azure リソースの使用を最小限に抑えるようにすることをお勧めします。 たとえば、ワークロードの一部としてシークレットを格納する必要がある場合は、ハブに関連付けられているキー コンテナーとは別に、別の Key Vault を作成する必要があります。 ハブ Key Vault は、ハブとプロジェクトのシークレットを格納するためにのみハブで使用する必要があります。
個別のプロジェクトごとに、依存関係に対するロールの割り当てによって、ポータル ユーザーとマネージド オンライン エンドポイントのマネージド ID に必要のないリソースへのアクセスが提供されないようにします。 たとえば、Azure OpenAI への Cognitive Services OpenAI User ロールの割り当てにより、そのリソースのすべてのデプロイへのアクセスが許可されます。 そのロール割り当てアクセス権を持つフロー作成者またはマネージド オンライン エンドポイントマネージド ID を、Azure OpenAI の特定のモデル デプロイに制限する方法はありません。 このようなシナリオでは、Azure OpenAI や Azure AI Search などのサービスをプロジェクトごとにデプロイし、作成者やマネージド オンライン エンドポイントのマネージド ID がアクセスできないサービスにリソースをデプロイしないようにします。 たとえば、プロジェクトがアクセスする必要があるプロジェクトの Azure OpenAI インスタンスにのみモデルをデプロイします。 プロジェクトがアクセスできるプロジェクトの Azure AI Search インスタンスにのみインデックスをデプロイします。
ネットワーク
ネットワーク セキュリティは ID ベースのアクセスと共に、OpenAI を使用するベースラインのエンド ツー エンドのチャット アーキテクチャの中核となっています。 ネットワーク アーキテクチャでは、大まかに次のことが保証されます。
- チャット UI トラフィックのための単一の安全なエントリーポイントに限定します。
- ネットワーク トラフィックがフィルター処理されます。
- データは、トランスポート層セキュリティ (TLS) を使用してエンドツーエンドで暗号化されます。
- プライベート リンクによってデータ流出を最小限に抑え、Azure でのトラフィックを維持します。
- ネットワーク リソースは論理的にグループ化され、ネットワークのセグメント化によって互いに分離されます。
ネットワーク フロー
この図の 2 つのフローは、ベースライン App Service Web アプリケーション アーキテクチャで説明されている、エンド ユーザーからチャット UI への受信フロー (1) と、App Service から Azure PaaS サービスへのフロー (2) です。 このセクションでは、Machine Learning オンライン エンドポイント フローに焦点を当てます。 以下のフローでは、ベースライン App Service Web アプリケーションで実行されるチャット UI から Machine Learning コンピューティングにデプロイされたフローへ流れていきます。
- App Service でホストされているチャット UI からの呼び出しは、プライベート エンドポイントを経由して Machine Learning オンライン エンドポイントにルーティングされます。
- オンライン エンドポイントは、デプロイされたフローを実行しているサーバーに呼び出しをルーティングします。 オンライン エンドポイントは、Load Balancer とルーターの両方として機能します。
- デプロイされたフローで必要な Azure PaaS サービスへの呼び出しは、マネージド プライベート エンドポイント経由でルーティングされます。
Machine Learning へのイングレス
このアーキテクチャでは、Machine Learning ワークスペースへのパブリック アクセスが無効になっています。 このアーキテクチャは Machine Learning ワークスペースの構成のプライベート エンドポイントに従うため、ユーザーはプライベート アクセスを介してワークスペースにアクセスすることができます。 実際、ID ベース セキュリティを補完するために、このアーキテクチャ全体でプライベート エンドポイントが使用されています。 たとえば、App Service でホストされているチャット UI は、Machine Learning エンドポイントなど、パブリック インターネットに公開されていない PaaS サービスに接続することができます。
プライベート エンドポイント アクセスは、フロー作成のために Machine Learning ワークスペースに接続するためにも必要です。
この図は、プロンプト フロー作成者が Azure Bastion 経由で仮想マシン ジャンプ ボックスに接続していることを示しています。 そのジャンプ ボックスから、作成者はジャンプ ボックスと同じネットワーク内のプライベート エンドポイント経由で Machine Learning ワークスペースに接続できます。 仮想ネットワークへの接続は、ExpressRoute または VPN ゲートウェイと仮想ネットワーク ピアリング経由で実現することもできます。
Azure AI Studio マネージド仮想ネットワークから Azure PaaS サービスへのフロー
すべての送信接続を承認する必要がある、 管理された仮想ネットワークの分離 用に Azure AI Studio ハブを構成することをお勧めします。 このアーキテクチャは、その推奨事項に従います。 承認済みのアウトバウンド規則は 2 種類あります。 必要なアウトバウンド規則は、ソリューションが機能するために必要なリソース (Container Registry や Storage など) が対象になります。 ユーザー定義のアウトバウンド規則は、ワークフローで使用されるカスタム リソース (Azure OpenAI や AI Search など) が対象です。 ユーザー定義のアウトバウンド規則を構成する必要があります。 必須のアウトバウンド規則は、マネージド仮想ネットワークの作成時に構成されます。 マネージド仮想ネットワークは、最初に使用するときにオンデマンドでデプロイされ、それ以降は永続化されます。
アウトバウンド規則には、プライベート エンドポイント、サービス タグ、または外部パブリック エンドポイントの完全修飾ドメイン名 (FQDN) を使用できます。 このアーキテクチャでは、Container Registry、Storage、Azure Key Vault、Azure OpenAI、AI Search などの Azure サービスへの接続は、プライベート リンク経由で接続されます。 このアーキテクチャにはありませんが、FQDN アウトバウンド規則の構成が必要な場合がある一般的な操作の中には、pip パッケージのダウンロード、GitHub リポジトリの複製、外部リポジトリからのベース コンテナー イメージのダウンロードがあります。
仮想ネットワークのセグメント化とセキュリティ
このアーキテクチャのネットワークには、次の目的に対応する別個のサブネットがあります。
Application Gateway
App Service 統合コンポーネント
プライベート エンドポイント
Azure Bastion
ジャンプ ボックス仮想マシン
トレーニングサブネットとスコアリングサブネット - これらはどちらも、トレーニングと推論に関連する独自のコンピューティングを持ち込むためです。 このアーキテクチャでは、トレーニングは行いません。また、マネージド コンピューティングを使用しています。
ポイントの計算
各サブネットにはネットワーク セキュリティ グループ (NSG) があり、これらのサブネットの受信と送信の両方のトラフィックを必要なトラフィックのみに制限します。 次の表では、ベースラインによって各サブネットに追加される NSG 規則を簡単に示しています。 表では、規則名と機能を示しています。
| Subnet | 受信 | 送信 |
|---|---|---|
| snet-appGateway | チャット UI ユーザーのソース IP (パブリック インターネットなど) に対する許容値と、サービスに必要な項目。 | App Service のプライベート エンドポイントへのアクセスと、サービスに必要な項目。 |
| snet-PrivateEndpoints | 仮想ネットワークからのトラフィックのみが許可されます。 | 仮想ネットワークへのトラフィックのみが許可されます。 |
| snet-AppService | 仮想ネットワークからのトラフィックのみが許可されます。 | プライベート エンドポイントと Azure Monitor へのアクセスが許可されます。 |
| AzureBastionSubnet | NSG アクセスと Azure Bastion の使用 のガイダンスを参照してください。 | NSG アクセスと Azure Bastion の使用 のガイダンスを参照してください。 |
| snet-jumpbox | Azure Bastion ホスト サブネットからの受信リモート デスクトップ プロトコル (RDP) と SSH を許可します。 | プライベート エンドポイントへのアクセスを許可する |
| snet-agents | 仮想ネットワークからのトラフィックのみが許可されます。 | 仮想ネットワークへのトラフィックのみが許可されます。 |
| snet-training | 仮想ネットワークからのトラフィックのみが許可されます。 | 仮想ネットワークへのトラフィックのみが許可されます。 |
| snet-scoring | 仮想ネットワークからのトラフィックのみが許可されます。 | 仮想ネットワークへのトラフィックのみが許可されます。 |
その他のトラフィックはすべて明示的に拒否されます。
仮想ネットワークのセグメント化とセキュリティを実装する場合は、次の点を考慮してください。
パブリック IP アドレスを持つアプリケーション ゲートウェイの一部であるサブネットを持つ仮想ネットワークに対して DDoS Protection を有効にします。
可能であれば、すべてのサブネットに NSG を追加します。 ソリューションの全機能を有効にする最も厳密な規則を使用します。
アプリケーション セキュリティ グループを使用して NSG をグループ化します。 NSG をグループ化すると、複雑な環境向けのルールを簡単に作成できるようになります。
キーの交換
このアーキテクチャには、キーベースの認証 (Machine Learning マネージド オンライン エンドポイント) を使用するサービスが 1 つあります。 このサービスにはキーベースの認証を使用するため、次の点が重要です。
プロンプト フロー コンテナーをホストする Azure Web アプリなど、許可されているクライアントからのオンデマンド アクセス用に、Key Vault などの安全な保管場所にキーを格納します。
キー ローテーション戦略を実装します。 キーを手動でローテーション 場合キーの有効期限ポリシーを作成し、Azure Policy を使用してキーがローテーションされたかどうかを監視します。
OpenAI モデルのチューニング
実装時に OpenAI モデルのチューニングを行う場合は、次のガイダンスを考慮してください。
チューニング用にトレーニング データをアップロードする場合は、カスタマー マネージド キーを使用してそのデータを暗号化することを検討してください。
Azure Blob Storage などのストアにトレーニング データを格納する場合は、データ暗号化のためのカスタマー マネージド キー、データへのアクセスを制御するためのマネージド ID、およびデータに接続するためのプライベート エンドポイントの使用を検討してください。
ポリシーによるガバナンス
セキュリティとの整合性を確保するために、デプロイがワークロードの要件に沿うよう、Azure Policy とネットワーク ポリシーの使用を検討します。 ポリシーを使用したプラットフォームの自動化は、手動の検証手順による負担を軽減し、パイプラインがバイパスされた場合でもガバナンスが確保されます。 次のセキュリティ ポリシーを検討してください。
- Azure AI サービスや Key Vault などのサービスで、キーまたはその他のローカル認証アクセスを無効にする。
- ネットワーク アクセス規則または NSG の特定の構成を要求する。
- カスタマー マネージド キーの使用など、暗号化を要求する。
Azure Key Vault の Azure AI Studio ロールの割り当て
Azure AI Studio マネージド ID には、コントロール プレーン (共同作成者) ロールとデータ プレーン (Key Vault 管理者) ロールの割り当ての両方が必要です。 つまり、この ID には、Azure Key Vault に格納されているすべてのシークレット、キー、証明書に対する読み取りと書き込みアクセス権が付与されるということです。 ワークロードに、Key Vault 内のシークレット、キー、または証明書へのアクセスを必要とする Azure AI Studio 以外のサービスがある場合、ワークロードまたはセキュリティ チームは、それらの成果物にアクセスできる Azure AI Studio ハブのマネージド ID に慣れるのに不慣れた場合があります。 この場合は、Azure AI Studio ハブ専用の Key Vault インスタンスと、ワークロードの他の部分に適した他の Azure Key Vault インスタンスをデプロイすることを検討してください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
このシナリオの価格例を確認するには、Azure 料金計算ツールを使用します。 この例ではアーキテクチャに含まれるコンポーネントが含まれているだけなので、使用率に合わせて例をカスタマイズする必要があります。 このシナリオで最もコストの高いコンポーネントは、DDoS Protection と、マネージド オンライン エンドポイントの一部としてデプロイされるファイアウォールです。 その他の注目すべきコストは、チャット UI とプロンプト フロー コンピューティングと AI 検索です。 最大限コストを削減するには、これらのリソースの最適化を行います。
Compute
プロンプト フローでは、実行可能フローをホストするための複数のオプションがサポートされています。 オプションには、Machine Learning、AKS、App Services、Azure Kubernetes Service の管理されたオンライン エンドポイントが含まれます。 これらのオプションにはそれぞれ独自の課金モデルがあります。 コンピューティングの選択は、ソリューションの全体的なコストに影響を及ぼします。
Azure OpenAI
Azure OpenAI は従量課金ベースのサービスであり、あらゆる消費ベースのサービスと同様に、供給に対して需要を制御することが一番のコスト管理になります。 これを特に Azure OpenAI で行うには、以下に挙げるアプローチを組み合わせて使用する必要があります。
クライアントを制御する。 クライアント要求は従量課金モデルの主なコスト源になるため、クライアントの動作を制御することは極めて重要です。 すべてのクライアントは次のことを行う必要があります。
承認を受けます。 制限のないアクセスをサポートするような方法でサービスを公開することを避けます。 ネットワーク制御と、キーやロールベースのアクセス制御 (RBAC) などの ID 制御の、両方を使用してアクセスを制限します。
自己管理する。 max_tokens や max_completions などの API 呼び出しによって提供されるトークン制限制約を使用するようクライアントに要求します。
実用的であればバッチ処理を使用します。 クライアントを確認して、プロンプトが適切にバッチ処理されるようにします。
プロンプトの入力と応答の長さを最適化します。 プロンプトが長いほど消費されるトークンが増えるため、コストは上がりますが、十分なコンテキストが不足しているプロンプトでは、モデルで良い結果を引き出すことはできません。 モデルが有用な応答を生成できるようにするのに十分なコンテキストを提供する簡潔なプロンプトを作成します。 同様に、確実に応答の長さの制限を最適化するようにします。
Azure OpenAI プレイグラウンドの使用は、これらのアクティビティで運用コストが発生しないように、必要に応じて、運用前環境のインスタンスで行う必要があります。
適切な AI モデルを選択します。 モデルの選択も、Azure OpenAI の全体的なコストで大きな役割を果たします。 すべてのモデルには長所と短所があり、個別に価格が設定されています。 ユースケースに適したモデルを使用して、より安価なモデルで許容できる結果が得られた場合に、より高価なモデルに対する過剰な支出を確実に抑えるようにします。 このチャット リファレンス実装では GPT-4 よりも GPT 3.5-turbo を選択したことで、十分な結果を得ながらも、モデル デプロイのコストを 1 桁ほど削減しました。
課金ブレークポイントを理解します。 チューニングは 1 時間単位で課金されます。 最も効率的にするには、次の請求期間に入ってしまうことを避けながら、1 時間あたりに使用可能な時間をできるだけ多く利用して、微調整の結果を改善する必要があります。 同様に、イメージ生成による 100 個のイメージにかかるコストは、1 個のイメージにかかるコストと同じです。 プラスの効果が得られるように価格のブレークポイントを最大限に活用します。
課金モデルを理解します。 Azure OpenAI は、プロビジョニングされたスループット オファリングを通じて、コミットメントベースの課金モデルでも利用できます。 予測可能な使用パターンが用意できたら、現在の使用量でコスト効率が改善される場合は、この事前購入課金モデルへの切り替えを検討します。
プロビジョニングの制限を設定します。 すべてのプロビジョニング クォータが、モデルごとに、ワークロードの一部となることが予想されるモデルにのみ割り当てられるようにします。 動的クォータが有効になっている間、すでにデプロイされたモデルのスループットは、このプロビジョニングされたクォータに制限されません。 クォータはコストに直接マップされないため、コストは異なる場合があります。
CPU 使用率による従量課金制を監視します。 従量課金制の価格を使用する場合は、TPM と RPM の使用状況を監視します。 その情報を使用して、どのモデルを使用するかなどのアーキテクチャの設計上の決定に関する情報を提供したり、プロンプト サイズを最適化したりします。
プロビジョニングされたスループットの使用状況を監視します。 プロビジョニング済みスループットを使用する場合は、プロビジョニング マネージド使用率を監視して、購入したプロビジョニング済みスループットが十分に活用されていない状況が生じないことを確認します。
コスト管理。 OpenAI でコスト管理機能を使用してコストの監視、コストを管理するための予算の設定、リスクや異常を利害関係者に通知するアラートの作成について、ガイダンスに従います。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
組み込みのプロンプト フロー ランタイム
基本アーキテクチャと同様、このアーキテクチャでも自動ランタイムを使用して運用上の負担を最小限に抑えています。 自動ランタイムは、Machine Learning 内のサーバーレス コンピューティング オプションで、これによってコンピューティング管理が簡素化され、プロンプト フロー構成の大部分が、実行中のアプリケーションの requirements.txt ファイルと flow.dag.yaml 構成に委任されます。 メンテナンスに手がかからず、一時的に使用でき、アプリケーション駆動型のオプションとなっています。 コンピューティング インスタンス ランタイムまたはこのアーキテクチャなどの外部化されたコンピューティングを使用するには、より多くをワークロード チームが管理するコンピューティングのライフサイクルが必要です。これは、ワークロード要件が自動ランタイム オプションの構成機能を超える場合に選択する必要があります。
監視
基本アーキテクチャと同様、すべてのサービスに対して診断が構成されています。 App Service 以外のすべてのサービスは、ログをすべてキャプチャするように構成されています。 App Service は、AppServiceHTTPLogs、AppServiceConsoleLogs、AppServiceAppLogs、AppServicePlatformLogs をキャプチャするように構成されています。 運用環境では、すべてのログが過剰である可能性があります。 運用上のニーズに合わせてログ ストリームを調整します。 このアーキテクチャの場合、Azure AI Studio プロジェクトで使用される Azure Machine Learning ログには、AmlComputeClusterEvent、AmlDataSetEvent、AmlEnvironmentEvent、および AmlModelsEvent が含まれます。
Azure Monitor ベースライン アラートに含まれるものなど、このアーキテクチャ内のリソースのカスタム アラートの構築を評価します。 次に例を示します。
Azure OpenAI モデルのデプロイに対するトークンの使用状況を必ず追跡してください。 このアーキテクチャでは、プロンプト フローは、Azure アプリlication Insights との統合によってトークンの使用状況を追跡します。
言語モデルの操作
このアーキテクチャのような Azure OpenAI ベースのチャット ソリューションのデプロイは、Azure DevOps を使用したプロンプト フローによる GenAIOps と GitHub を使用したプロンプト フローによる GenAIOps のガイダンスに従う必要があります。 また、継続的インテグレーションと継続的デリバリー (CI/CD)、およびネットワークで保護されたアーキテクチャのベスト プラクティスを考慮する必要があります。 次のガイダンスでは、GenAIOps のレコメンデーションに基づいたフローとそれに関連するインフラストラクチャの実装について説明します。 このデプロイに関するガイダンスには、ベースラインの高可用性ゾーン冗長 Web アプリケーション アーキテクチャと同じフロントエンド アプリケーション要素は含まれていません。
開発
プロンプト フローには、Azure AI Studio でのブラウザー ベースの作成エクスペリエンスと、 Visual Studio Code 拡張機能の両方が用意されています。 どちらのオプションも、フロー コードをファイルとして保存します。 Azure AI Studio を使用すると、ファイルはストレージ アカウントに格納されます。 Microsoft Visual Studio Code で作業する場合、ファイルはローカル ファイル システムに保存されます。
コラボレーション開発のベスト プラクティスに従うには、ソース ファイルを GitHub などのオンライン ソース コード リポジトリに保持する必要があります。 このアプローチにより、すべてのコード変更の追跡、フロー作成者間のコラボレーション、すべてのコード変更をテストおよび検証するデプロイ フローとの統合が促進されます。
エンタープライズ開発の場合、開発には Microsoft Visual Studio Code 拡張機能 と プロンプトフロー SDK/CLI を使用します。 プロンプト フローの作成者は、Microsoft Visual Studio Code からフローを構築およびテストし、ローカルに保存されたファイルをオンライン ソース管理システムおよびパイプラインと統合できます。 ブラウザーベースのエクスペリエンスは探索的な開発に適していますが、何らかの作業を行うことで、ソース管理システムと統合できます。 フロー フォルダーは、Filesパネルのフロー ページからダウンロードして解凍し、ソース管理システムにプッシュできます。
評価
他のソフトウェア成果物をテストする場合と同様に、チャット アプリケーションで使用されるフローをテストします。 言語モデルの出力に対する唯一の「正しい」答えを指定して断言することは困難ですが、言語モデル自体を使用することで応答を評価することができます。 言語モデル フローの次の自動評価を実装することを検討してください。
分類の精度: 言語モデルが「正しい」スコアを与えているか「正しくない」スコアを与えるいるかを評価し、結果を集計して精度グレードを生成します。
コヒーレンス: モデルで予測した回答の文章がどのように書かれているか、および文章が一貫性をもってどのように相互につながっているかを評価します。
流暢性: モデルで予測した回答を、文法と言語の精度の点で評価します。
コンテキストに対する根拠: モデルで予測した回答が、事前構成されたコンテキストにどれだけ適切に基づいているかを評価します。 言語モデルの応答が正しい場合でも、指定されたコンテキストに対して検証できない場合、その応答は根拠のないものになります。
関連性: モデルで予測した回答がどれだけ質問と一致しているかを評価します。
自動評価を実装する場合は、次のガイダンスを考慮してください。
評価からスコアを生成し、事前定義された成功しきい値と比較してスコアを測定します。 これらのスコアを使用して、パイプラインでのテストの合格/不合格を報告します。
これらのテストの一部では、質問、コンテキスト、およびグラウンド トゥルースの事前構成されたデータ入力が必要です。
テスト結果の信頼性を確保するために、十分な数の質問と回答のペア、少なくとも 100 ~ 150 のペアを含めることをお勧めします。 これらの質問と回答のペアは、"ゴールデン データセット" と呼ばれます。データセットのサイズとドメインによっては、より大きな母集団が必要になる場合があります。
ゴールデン データセットのデータの生成に言語モデルを使用することは避けます。
デプロイ フロー
プロンプト エンジニア/データ科学者は、特定のタスクまたは機能に取り組む機能ブランチを開きます。 プロンプト エンジニア/データ サイエンティストは、Microsoft Visual Studio Code のプロンプト フローを使用してフローを反復し、定期的に変更をコミットして、その変更を機能ブランチにプッシュします。
ローカルでの開発と実験が完了すると、プロンプト エンジニア/データ科学者は機能ブランチからメイン ブランチへのプル要求を開きます。 プル要求 (PR) は PR パイプラインをトリガーします。 このパイプラインでは、次の内容を含む高速の品質チェックが実行されます。
- 実験フローの実行
- 構成された単体テストの実行
- コードベースのコンパイル
- スタティック コード分析
パイプラインには、マージする前に少なくとも 1 人のチーム メンバーが PR を手動で承認する必要があるステップを含めることができます。 承認者はコミッターにはなれず、プロンプト フローの専門知識があり、プロジェクト要件に精通している必要があります。 PR が承認されない場合、マージはブロックされます。 PR が承認されている場合、または承認手順がない場合、機能ブランチはメイン ブランチにマージされます。
メインへのマージによって、開発環境のビルドとリリースのプロセスがトリガーされます。 具体的には、次のように使用します。
- CI パイプラインは、マージからメインにトリガーされます。 CI パイプラインでは、PR パイプラインで実行されるすべての手順と、次の手順が実行されます。
- 実験フロー
- 評価フロー
- 変更が検出されると、Machine Learning Registry にフローを登録します
- CD パイプラインは、CI パイプラインの完了後にトリガーされます。 このフローでは次の手順が実行されます。
- Machine Learning レジストリから Machine Learning オンライン エンドポイントにフローをデプロイする
- オンライン エンドポイントを対象とする統合テストを実行する
- オンライン エンドポイントを対象とするスモーク テストを実行する
承認プロセスは、リリース プロモーション プロセスに組み込まれています。承認後、手順 4.a & 4.b.で説明されている CI & CD プロセスが、テスト環境を対象に繰り返されます。 手順 a. と b. は同じですが、テスト環境のスモーク テストの後にユーザー受け入れテストが実行される点が異なります。
手順 4.a & 4.b で説明されている CI & CD プロセスは、テスト環境が検証および承認された後に、リリースを運用環境にレベル上げするために実行されます。
ライブ環境へのリリース後、パフォーマンス メトリックを監視し、デプロイされた言語モデルを評価する運用タスクが実行されます。 たとえば、次のようなものが挙げられます。
- データドリフトの検出
- インフラストラクチャの観察
- コストの管理
- モデルのパフォーマンスに関する利害関係者への伝達
展開ガイダンス
Machine Learning エンドポイントを使用すると、運用環境へのリリース時に柔軟な方法でモデルをデプロイできます。 最高のモデルのパフォーマンスと品質を確保するには、次の戦略を検討してください。
ブルーグリーン デプロイ: この戦略では、すべてのトラフィックを新しいデプロイに転送する前に、Web サービスの新しいバージョンを一部のユーザーまたは要求のグループに安全にデプロイできます。
A/B テスト: ブルーグリーン デプロイは、変更を安全にロールアウトするのに効果的なだけでなく、一部のユーザーが変更の影響を評価できるようにする新しい動作をデプロイするためにも使用できます。
パイプラインのプロンプト フローの一部である Python ファイルのリンティングを含めます。 リンティングは、スタイル標準への準拠、エラー、コードの複雑さ、未使用のインポート、変数の名前付けをチェックします。
ネットワーク分離された Machine Learning ワークスペースにフローをデプロイする場合は、セルフホステッド エージェントを使用してアーティファクトを Azure リソースにデプロイします。
Machine Learning モデル レジストリは、モデルに変更があった場合にのみ更新する必要があります。
言語モデル、フロー、クライアント UI は疎結合である必要があります。 フローとクライアント UI の更新は、モデルに影響を与えることなく行うことができ、また、その逆も同様です。
複数のフローを開発してデプロイする場合、各フローには独自のライフサイクルを設定する必要があります。これを行うことで、実験から運用環境にフローのフェーズを移行するときに、疎結合エクスペリエンスを実現できます。
インフラストラクチャ
ベースラインの Azure OpenAI エンド ツー エンド チャット コンポーネントをデプロイすると、プロビジョニングされたサービスの一部はアーキテクチャ内で基本的かつ永続的なものになりますが、一部のコンポーネントは本質的に一時的なものであり、その存在はデプロイに結び付いています。 また、マネージド仮想ネットワークは基本ですが、コンピューティング インスタンスを作成すると自動的にプロビジョニングされるため、いくつかの考慮事項が発生します。
基礎コンポーネント
このアーキテクチャの一部のコンポーネントは、個々のプロンプト フローやモデル デプロイの枠を超えたライフサイクルを持って存在します。 通常、これらのリソースはワークロード チームによる基本的なデプロイの一部として一度デプロイされ、プロンプト フローまたはモデル デプロイの新規、削除、更新とは別に保持されます。
- Machine Learning ワークスペース
- Machine Learning ワークスペース用の Storage アカウント
- Container Registry
- AI Search
- Azure OpenAI
- Azure Application Insights
- Azure Bastion
- ジャンプ ボックス用の Azure 仮想マシン
エフェメラル コンポーネント
一部の Azure リソースは、特定のプロンプト フローの設計に、より緊密に結合されています。 このアプローチにより、これらのリソースをコンポーネントのライフサイクルにバインドし、このアーキテクチャで一時的なものにすることができます。 Azure リソースは、フローの追加や削除、新しいモデルの導入など、ワークロードが進化するときに影響を受けます。 これらのリソースは再作成され、以前のインスタンスは削除されます。 これらのリソースの一部は直接 Azure リソースであり、一部は、そのリソースが含まれるサービス内のデータプレーン マニフェストです。
Machine Learning モデル レジストリのモデルは、変更された場合、CD パイプラインの一部として更新する必要があります。
コンテナー イメージは、CD パイプラインの一部としてコンテナー レジストリで更新する必要があります。
Machine Learning エンドポイントは、存在しないエンドポイントをデプロイが参照している場合にプロンプト フローがデプロイされると作成されます。 パブリック アクセスを無効にするには、そのエンドポイントを更新する必要があります。
Machine Learning エンドポイントのデプロイは、フローがデプロイまたは削除されると更新されます。
新しいエンドポイントが作成されるとき、クライアント UI のキー コンテナーはエンドポイントへのキーで更新される必要があります。
オンデマンドマネージド仮想ネットワーク
マネージド仮想ネットワークは、コンピューティング インスタンスを初めて作成するときに自動的にプロビジョニングされます。 インフラストラクチャをコードとして使用してハブをデプロイしていて、Bicep に AI Studio コンピューティング リソースがない場合、マネージド仮想ネットワークはデプロイされず、Azure AI Studio に接続するときにエラーが表示されます。 IaC のデプロイ後にマネージド仮想ネットワークを手動でプロビジョニングするには、1 回限りのアクションを実行する必要があります。
リソースの編成
ワークロード チーム以外のチームがハブを一元的に所有しているシナリオがある場合は、プロジェクトを個別のリソース グループにデプロイすることを選択できます。 インフラストラクチャをコードとして使用している場合は、Bicep で別のリソース グループを設定することでこれを実現できます。 ポータルを使用している場合は、workspaceHubConfigのdefaultWorkspaceResourceGroup プロパティを、プロジェクトを作成するリソース グループに設定できます。
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
このセクションでは、Azure Search、Azure OpenAI、Machine Learning の観点からパフォーマンス効率について説明します。
Azure Search - パフォーマンス効率
AI Search のパフォーマンスを分析するための、ガイダンスに従ってください。
Azure OpenAI - パフォーマンス効率
アプリケーションで、プロビジョニングされたスループット、または共有ホスティング、または従量課金モデルのどれを要求するかを決定します。 プロビジョニングされたスループットは、OpenAI モデル デプロイの予約済み処理機能を保証し、モデルに予測可能なパフォーマンスとスループットを提供します。 この課金モデルは、共有ホスティングや従量課金モデルとは異なります。 従量課金モデルはベストエフォート型であり、プラットフォーム上の近隣ノイズやその他のストレス要因の影響を受ける可能性があります。
プロビジョニングされたスループットの場合は、プロビジョニング マネージド使用率を監視します。
Machine Learning - パフォーマンス効率
Machine Learning オンライン エンドポイントにデプロイする場合:
オンライン エンドポイントをオートスケールする方法に関するガイダンスに従ってください。 これは、特に使用率が低い期間に過剰なオーバープロビジョニングを行わずに、需要に的確に沿うようにするためです。
パフォーマンスの目標を達成するために、オンライン エンドポイントに適切な仮想マシン SKU を選択してください。 最適な構成を見つけるには、少ないインスタンス数と大きな SKU の組み合わせ、および多くのインスタンス数と小さな SKU の組み合わせの両方のパフォーマンスをテストします。
このシナリオのデプロイ
参照実装をデプロイして実行するには、OpenAI のエンド ツー エンドのベースライン参照実装の手順に沿って対応してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- Rob Bagby | パターン & プラクティス - Microsoft
- Freddy Ayala | クラウド ソリューション アーキテクト - Microsoft
- Prabal Deb | シニア ソフトウェア エンジニア - Microsoft
- Raouf Aliouat | ソフトウェア エンジニア II - マイクロソフト
- Ritesh Modi | プリンシパル ソフトウェア エンジニア - Microsoft
- Ryan Pfalz | シニア ソリューション アーキテクト - Microsoft
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。