エンタープライズ チャット アプリケーションは、会話による対話を通じて従業員を支援することができます。 これは、OpenAI の GPT モデルや Meta の LLaMA モデルなどの言語モデルが継続的に進歩しているため、特に当てはまります。 これらのチャット アプリケーションを構成しているのは、チャット ユーザー インターフェイス、ユーザーのクエリに関連するドメイン固有の情報を含むデータ リポジトリ、ドメイン固有のデータについて推論して関連性の高い応答を生成する言語モデル、そしてこれらのコンポーネント間の相互作用を監視するオーケストレーターです。
この記事では、Azure OpenAI Service の言語モデルを使用するエンタープライズ チャット アプリケーションを構築およびデプロイするためのベースライン アーキテクチャについて説明します。 このアーキテクチャでは、Azure Machine Learning プロンプト フローを使用して実行可能なフローを作成します。 これらの実行可能フローは、受信プロンプトからデータ ストアへのワークフローを調整して、言語モデル用にグラウンディングするデータを他の必要な Python ロジックと共にフェッチします。 実行可能フローは、マネージド オンライン エンドポイントの背後にある Machine Learning コンピューティング クラスターにデプロイされます。
カスタム チャット ユーザー インターフェイス (UI) のホスティングは、ゾーン冗長で高可用性のセキュアな Web アプリケーションを Azure APP Services でデプロイするためのベースライン アプリ サービス Web アプリケーションのガイダンスに従います。 そのアーキテクチャでは、App Service は、プライベート エンドポイントを介した仮想ネットワーク統合を通じて Azure PaaS (サービスとしてのプラットフォーム) ソリューションと通信を行います。 チャット UI App Service は、プライベート エンドポイント経由でフローのマネージド オンライン エンドポイントと通信を行います。 Machine Learning ワークスペースへのパブリック アクセスは無効になっています。
重要
この記事では、ベースライン App Service Web アプリケーションのコンポーネントやアーキテクチャの決定については説明しません。 チャット UI をホストする方法に関するアーキテクチャ ガイダンスについては、その記事をお読みください。
Machine Learning ワークスペースはマネージド仮想ネットワーク分離を用いて構成されており、送信接続はすべて承認を受ける必要があります。 この構成では、マネージド仮想ネットワークが、プライベート リソース (職場の Azure Storage、Azure Container Registry、Azure OpenAI など) への接続を可能にするマネージド プライベート エンドポイントと共に作成されます。 これらのプライベート接続は、フローの作成とテスト中に使用され、また Machine Learning コンピューティングにデプロイされたフローによっても使用されます。
ヒント
この記事は、Azure でのベースラインのエンド ツー エンドのチャット実装を紹介する参照実装によって裏付けられます。 この実装は、実稼働に向けた最初のステップとして、カスタム ソリューション開発の基盤として使用できます。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
コンポーネント
このアーキテクチャのコンポーネントの多くは、ベースライン App Service Web アプリケーション アーキテクチャのリソースと同じです。これは、チャット UI をホストするために使用されるメソッドが、両方のアーキテクチャで同じであるためです。 このセクションで強調表示されているコンポーネントは、チャット フローの構築と調整に使用されるコンポーネント、データ サービス、および言語モデルを公開するサービスに焦点を当てています。
Machine Learning は、機械学習モデルのトレーニング、デプロイ、管理に使用できるマネージド クラウド サービスです。 このアーキテクチャでは、言語モデルを利用した AI アプリケーションの実行可能フローの開発とデプロイに使用される Machine Learning の他の機能をいくつか使用します。
Machine Learning プロンプト フローは開発ツールの 1 つで、これを使用することで、ユーザー プロンプト、Python コードによるアクション、言語学習モデルへの呼び出しをリンクするフローを構築、評価、デプロイすることができます。 このアーキテクチャーのプロンプト フローは、プロンプト、異なるデータ ストア、言語モデルとの間でフローを調整する層として使用されます。
マネージド オンライン エンドポイントを使用すると、リアルタイム推論用のフローをデプロイできます。 このアーキテクチャでは、マネージド オンライン エンドポイントは、Machine Learning でホストされているプロンプト フローを呼び出すために、チャット UI の PaaS エンドポイントとして使用されます。
Storage は、プロンプト フロー開発のプロンプト フロー ソース ファイルを保持するために使用されます。
Container Registry を使用すると、あらゆる種類のコンテナー デプロイ用のプライベート レジストリにコンテナー イメージや成果物をビルド、格納、管理できるようになります。 このアーキテクチャでは、フローはコンテナー イメージとしてパッケージ化され、Container Registry に格納されます。
Azure OpenAI は、GPT-4、GPT-3.5-Turbo、埋め込みのモデル セットなど、Azure OpenAI の言語モデルへの REST API アクセスを提供するフル マネージド サービスです。 このアーキテクチャでは、モデル アクセスに加えて、仮想ネットワークとプライベート リンク、マネージド ID のサポート、コンテンツ フィルタリングなどの一般的なエンタープライズ機能を追加するために使用されます。
Azure AI Search は、フルテキスト検索、セマンティック検索、ベクトル検索、ハイブリッド検索をサポートするクラウド検索サービスです。 AI Search は、チャット アプリケーションの背後にあるフローで使用される一般的なサービスであるため、アーキテクチャに含まれています。 AI Search を使用すると、ユーザー クエリに関連するデータを取得してインデックスを作成することができます。 プロンプト フローは、RAG (検索拡張生成) パターンを実装して、プロンプトから適切なクエリを抽出し、AI Search にクエリを実行して、その結果を Azure OpenAI モデルのグランディング データとして使用します。
Machine Learning プロンプト フロー
エンタープライズ チャット アプリケーションのバックエンドは、通常、次のフローのようなパターンに従います。
- ユーザーがカスタム チャット ユーザー インターフェイス (UI) にプロンプトを入力します。
- そのプロンプトがインターフェイス コードによってバックエンドに送信されます。
- ユーザーの意図である質問か指示のいずれかが、バックエンドによってプロンプトから抽出されます。
- 必要に応じて、バックエンドが、ユーザー プロンプトに関連するデータを保持するデータ ストアを決定します。
- バックエンドは関連するデータストアにクエリを実行します。
- 意図、関連する基礎データ、およびプロンプトで提供された履歴が、バックエンドによって言語モデルに送信されます。
- バックエンドは、UI に表示できるように結果を返します。
バックエンドは、任意の数の言語で実装でき、さまざまな Azure サービスにデプロイできます。 このアーキテクチャでは、Machine Learning プロンプト フローが使用されています。これは、このプロンプト フローを使用することで、プロンプト、バック エンド データ ストア、言語モデルの間で調整されるフローをより効率的に構築、テスト、デプロイできるためです。
プロンプト フローのランタイム
Machine Learning では、2 種類のプロンプト フロー ランタイムを直接ホストすることができます。
自動ランタイム: コンピューティングのライフサイクルとパフォーマンス特性を管理し、環境のフロー駆動型カスタマイズを可能にするサーバーレス コンピューティング オプション。
コンピューティング インスタンス ランタイム: ワークロード チームがパフォーマンス特性を選択する必要がある常時稼働コンピューティング オプション。 このランタイムは、より多くのカスタマイズと環境のコントロールを提供します。
プロンプト フローは、ホスト コンテナー ホスト プラットフォームで上 Machine Learning コンピューティングの外部でホストすることもできます。 このアーキテクチャでは、App Service を使用して外部ホスティングを実証しています。
ネットワーク
ネットワーク セキュリティは 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 ゲートウェイと仮想ネットワーク ピアリング経由で実現することもできます。
Machine Learning マネージド仮想ネットワークから Azure PaaS サービスへのフロー
Machine Learning ワークスペースは、すべての送信接続が承認を受ける必要があるマネージド仮想ネットワーク分離に対応するように構成することをお勧めします。 このアーキテクチャは、その推奨事項に従います。 承認済みのアウトバウンド規則は 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 をグループ化すると、複雑な環境向けのルールを簡単に作成できるようになります。
コンテンツのフィルタリングと不正使用の監視
Azure OpenAI には、分類モデルのアンサンブルを使用して、入力プロンプトと出力完了の両方において特定のカテゴリの潜在的に有害なコンテンツを検出して防止する、コンテンツ フィルタリング システムが含まれています。 この有害な可能性のあるコンテンツのカテゴリには、ヘイト、性的、自傷行為、暴力、冒涜、および脱獄 (言語モデルの制約を回避するように設計されたコンテンツ) が含まれます。 カテゴリごとにコンテンツをフィルタリングする厳密さを、低、中、または高のオプションで構成できます。 このリファレンス アーキテクチャは厳格なアプローチを採用しています。 要件に応じて設定を調整します。
Azure OpenAI では、コンテンツ フィルタリングに加えて、不正使用の監視機能が実装されています。 不正使用の監視は、Azure OpenAI の行動規範に違反する可能性のある方法でサービスを使用することを示唆する、繰り返し表示されるコンテンツや繰り返し行われる動作のインスタンスを検出して軽減できるように設計された非同期操作です。 機密性の高いデータの場合や、不正使用の検出のためにデータの処理を防止する内部ポリシーまたは適用される法律や規制がある場合は、不正使用の監視と人間によるレビューの除外を要求することができます。
信頼性
ベースラインの App Service Web アプリケーション アーキテクチャでは、主要なリージョン サービスのゾーン冗長に重点を置いています。 可用性ゾーンは、リージョン内の物理的に分離された場所です。 2 つ以上のインスタンスがリージョン全体にデプロイされている場合、リージョン内にサポート サービスに対する冗長が提供されます。 1 つのゾーンでダウンタイムが発生しても、リージョン内の他のゾーンは影響を受けない場合もあります。 このアーキテクチャを使用すると、Azure サービスの十分なインスタンスとそれらのサービスの構成が可用性ゾーンに確実に分散されるようになります。 詳細については、ベースラインを参照して、ガイダンスを確認してください。
このセクションでは、Machine Learning、Azure OpenAI、AI Search など、App Service ベースラインで扱われていないこのアーキテクチャのコンポーネントの観点から信頼性について説明します。
フロー デプロイのゾーン冗長
通常、エンタープライズ デプロイには、ゾーン冗長が必要です。 Azure でゾーン冗長を実現するには、リソースが可用性ゾーンをサポートしている必要があり、リソースのインスタンスを少なくとも 3 つデプロイするか、インスタンス制御が利用できない場合にはプラットフォーム サポートを有効にする必要があります。 現在、Machine Learning コンピューティングは、可用性ゾーンのサポートを提供していません。 データセンター レベルの大災害による Machine Learning コンポーネントへの潜在的な影響を軽減するには、さまざまなリージョンにクラスターを確立すると共に、Load Balancer をデプロイしてこれらのクラスター間で呼び出しを分散する必要があります。 ヘルス チェックを使用すると、呼び出しが適切に機能しているクラスターにのみルーティングされるのを確実にすることができます。
プロンプト フローのデプロイは、Machine Learning コンピューティング クラスターに限定されません。 実行可能フローはコンテナ化されたアプリケーションであるため、コンテナーと互換性のある任意の Azure サービスにデプロイできます。 これらのオプションには、Azure Kubernetes Service (AKS)、Azure Functions、Azure Container Apps、App Service などのサービスが含まれます。 これらの各サービスでは、可用性ゾーンがサポートされています。 マルチリージョン デプロイをさらに複雑化させることなく、プロンプト フロー実行のゾーン冗長を実現するには、これらのサービスのいずれかにフローをデプロイする必要があります。
次の図では、プロンプト フローが Azure App Service にデプロイされる代替アーキテクチャを示しています。 このアーキテクチャで App Service が使用されるのは、ワークロードがすでにチャット UI に App Service を使用しており、ワークロードに新しいテクノロジを導入してもメリットが得られないためです。 AKS の使用経験があるワークロードチームは、特に AKS がワークロード内の他のコンポーネントに使用されている場合は、その環境へのデプロイを検討する必要があります。
この図では、このアーキテクチャで注目すべき領域に番号が付けられています。
フローは引き続き Machine Learning プロンプト フローで作成され、Machine Learning ネットワーク アーキテクチャは変更されません。 フロー作成者は引き続きプライベート エンドポイント経由でワークスペース作成エクスペリエンスに接続し、フローのテスト時に Azure サービスに接続するためにマネージド プライベート エンドポイントが使用されます。
この点線は、コンテナー化された実行可能フローが Container Registry にプッシュされることを示しています。 この図には、フローをコンテナ化して Container Registry にプッシュするパイプラインは示されていません。
同じ App Service プランにデプロイされ、すでにチャット UI をホストしている別の 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 などのゲートウェイは、1 つ以上の OpenAI サービスの前にデプロイでき、一時的なエラーや制限が発生した場合に再試行するように構成できます。 API Management は、サービスが呼び出しで一杯になり、クォータを超過するのを防止するためのブレーカー (遮断機) としても使用できます。
AI Search - 信頼性
可用性ゾーンをサポートするリージョンに Standard 価格レベル以上の AI Search をデプロイし、3 つ以上のレプリカをデプロイします。 レプリカは、可用性ゾーン全体に自動的に均等に分散されます。
レプリカとパーティションの適切な数を決定するために、次のガイダンスを考慮してください。
クエリベースのスロットリングやパーティションを回避し、インデックスベースのスロットリングを回避するために、監視メトリックやログおよびパフォーマンス分析を使って適切なレプリカ数を決定します。
Machine Learning - 信頼性
Machine Learning マネージド オンライン エンドポイントの背後にあるコンピューティング クラスターにデプロイする場合は、スケーリングに関する次のガイダンスを考慮してください。
オンライン エンドポイントを自動的にスケールして、需要を満たすのに十分な容量を確保します。 バーストの使用が原因で使用シグナルの適時性が十分とは言えない場合は、オーバープロビジョニングを検討して、使用できるインスタンスが少なすぎることによる信頼性への影響を防ぐようにしてください。
CPU 負荷などのデプロイ メトリックと、要求の待機時間などのエンドポイント メトリックに基づいたスケーリング規則の作成を検討してください。
アクティブな運用デプロイには、3 つ以上のインスタンスをデプロイする必要があります。
使用中のインスタンスに対するデプロイは避けてください。 代わりに、新しいデプロイにデプロイし、デプロイでトラフィックの受信準備ができたら、トラフィックをシフトします。
Note
フローを APP Service にデプロイする場合は、ベースライン アーキテクチャから同じ App Service スケーラビリティに関するガイダンスが適用されます。
セキュリティ
このアーキテクチャは、ネットワークと ID セキュリティ境界の両方を実装します。 ネットワークの観点から見ると、インターネットからアクセスできる必要があるのは、Application Gateway を介したチャット UI のみです。 ID の観点から見ると、チャット UI は要求を認証し、承認する必要があります。 可能な場合は、マネージド ID を使用して、アプリケーションを Azure サービスに対して認証します。
このセクションでは、ID およびアクセス管理、ならびにキーのローテーションと Azure OpenAI モデルのチューニングに関するセキュリティ上の考慮事項について説明します。
ID 管理とアクセス管理
次のガイダンスは、App Service ベースラインの ID およびアクセス管理に関するガイダンスを拡張するものです。
- 必要に応じて、次の Machine Learning リソースに対して個別のマネージド ID を作成します。
- フローの作成と管理のためのワークスペース
- フローをテストするためのコンピューティング インスタンス
- フローがマネージド オンライン エンドポイントにデプロイされている場合の、デプロイされたフローのオンライン エンドポイント
- Microsoft Entra ID を使用することで、チャット UI の ID アクセス制御を実装します。
Machine Learning のロールベースのアクセス ロール
Machine Learning ワークスペースへのアクセスを管理するために使用できる既定のロールは、AzureML データ科学者、AzureML コンピューティング オペレーター、閲覧者、共同作成者、所有者の 5 つです。 これらの既定のロールに加えて、ワークスペース シークレットやレジストリなどのワークスペース リソースへのアクセスを許可することができる、AzureML Learning ワークスペース接続のシークレット閲覧者と AzureML レジストリ ユーザーがあります。
このアーキテクチャは、必要な場合に前述の ID にのみロールを割り当てることで、最小限の特権の原則に従います。 次のロールの割り当てを検討してください。
| マネージド ID | 範囲 | ロールの割り当て |
|---|---|---|
| ワークスペースのマネージド ID | リソース グループ | Contributor |
| ワークスペースのマネージド ID | ワークスペース ストレージ アカウント | ストレージ BLOB データ共同作成者 |
| ワークスペースのマネージド ID | ワークスペース ストレージ アカウント | ストレージ ファイル データ権限付き共同作成者 |
| ワークスペースのマネージド ID | ワークスペース Key Vault | Key Vault Administrator |
| ワークスペースのマネージド ID | ワークスペース コンテナー レジストリ | AcrPush |
| オンライン エンドポイントのマネージド ID | ワークスペース コンテナー レジストリ | AcrPull |
| オンライン エンドポイントのマネージド ID | ワークスペース ストレージ アカウント | ストレージ BLOB データ閲覧者 |
| オンライン エンドポイントのマネージド ID | Machine Learning ワークスペース | AzureML ワークスペース接続シークレット閲覧者 |
| コンピューティング インスタンスのマネージド ID | ワークスペース コンテナー レジストリ | AcrPull |
| コンピューティング インスタンスのマネージド ID | ワークスペース ストレージ アカウント | ストレージ BLOB データ閲覧者 |
キーの交換
このアーキテクチャには、キーベースの認証を使用する 2 つのサービス、Azure OpenAI と Machine Learning マネージド オンライン エンドポイントがあります。 これらのサービスではキーベースの認証を使用するため、次のことが重要です。
プロンプト フロー コンテナーをホストする Azure Web アプリなど、許可されているクライアントからのオンデマンド アクセス用に、Key Vault などの安全な保管場所にキーを格納します。
キー ローテーション戦略を実装します。 キーを手動でローテーションする場合は、キーの有効期限ポリシーを作成し、Azure Policy を使用してキーがローテーションされたかどうかを監視します。
OpenAI モデルのチューニング
実装時に OpenAI モデルのチューニングを行う場合は、次のガイダンスを考慮してください。
チューニング用にトレーニング データをアップロードする場合は、カスタマー マネージド キーを使用してそのデータを暗号化することを検討してください。
Azure Blob Storage などのストアにトレーニング データを格納する場合は、データ暗号化のためのカスタマー マネージド キー、データへのアクセスを制御するためのマネージド ID、およびデータに接続するためのプライベート エンドポイントの使用を検討してください。
ポリシーによるガバナンス
セキュリティとの整合性を確保するために、デプロイがワークロードの要件に沿うよう、Azure Policy とネットワーク ポリシーの使用を検討します。 ポリシーを使用したプラットフォームの自動化は、手動の検証手順による負担を軽減し、パイプラインがバイパスされた場合でもガバナンスが確保されます。 次のセキュリティ ポリシーを検討してください。
- Azure AI サービスや Key Vault などのサービスで、キーまたはその他のローカル認証アクセスを無効にする。
- ネットワーク アクセス規則または NSG の特定の構成を要求する。
- カスタマー マネージド キーの使用など、暗号化を要求する。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
このシナリオの価格例を確認するには、Azure 料金計算ツールを使用します。 この例ではアーキテクチャに含まれるコンポーネントが含まれているだけなので、使用率に合わせて例をカスタマイズする必要があります。 このシナリオで最もコストの高いコンポーネントは、チャット UI、プロンプト フロー コンピューティング、および AI Search です。 最大限コストを削減するには、これらのリソースの最適化を行います。
Compute
Machine Learning プロンプト フローは、実行可能フローをホストする複数のオプションをサポートしています。 オプションには、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 - 組み込みのプロンプト フロー ランタイム
自動ランタイムは、運用上の負担を最小限に抑えるための、Machine Learning 内のサーバーレス コンピューティング オプションで、これにより、コンピューティング管理が簡素化され、プロンプト フロー構成の大部分が実行中のアプリケーションの requirements.txt ファイルと flow.dag.yaml 構成に委任されます。 メンテナンスに手がかからず、一時的に使用でき、アプリケーション駆動型のオプションとなっています。 コンピューティング インスタンス ランタイムまたはこのアーキテクチャなどの外部化されたコンピューティングを使用するには、より多くをワークロード チームが管理するコンピューティングのライフサイクルが必要です。これは、ワークロード要件が自動ランタイム オプションの構成機能を超える場合に選択する必要があります。
監視
すべてのサービスに対して診断が構成されます。 Machine Learning と App Service 以外のすべてのサービスは、ログをすべてキャプチャするように構成されています。 Machine Learning 診断は、顧客とデータのやり取りやサービスの設定を記録するすべてのリソース ログである監査ログをキャプチャするように構成されています。 App Service は、AppServiceHTTPLogs、AppServiceConsoleLogs、AppServiceAppLogs、AppServicePlatformLogs をキャプチャするように構成されています。
Azure Monitor ベースライン アラートに含まれるものなど、このアーキテクチャ内のリソースのカスタム アラートの構築を評価します。 次に例を示します。
言語モデルの操作
このアーキテクチャのような Azure OpenAI ベースのチャット ソリューションのデプロイは、Azure DevOps を使用したプロンプト フローによる GenAIOps と GitHub を使用したプロンプト フローによる GenAIOps のガイダンスに従う必要があります。 また、継続的インテグレーションと継続的デリバリー (CI/CD)、およびネットワークで保護されたアーキテクチャのベスト プラクティスを考慮する必要があります。 次のガイダンスでは、GenAIOps のレコメンデーションに基づいたフローとそれに関連するインフラストラクチャの実装について説明します。 このデプロイに関するガイダンスには、ベースラインの高可用性ゾーン冗長 Web アプリケーション アーキテクチャと同じフロントエンド アプリケーション要素は含まれていません。
開発
Machine Learning プロンプト フローでは、Machine Learning スタジオで、および Visual Studio Code 拡張機能経由の両方で、ブラウザーベースの作成エクスペリエンスが提供されます。 どちらのオプションも、フロー コードをファイルとして保存します。 Machine Learning スタジオを使用する場合、ファイルは Strage アカウントに格納されます。 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 のキー コンテナーはエンドポイントへのキーで更新される必要があります。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによる需要を満たすために効率的にスケーリングするワークロードの能力です。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
このセクションでは、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 にサインインします。