ベースライン OpenAI エンドツーエンド チャット リファレンス アーキテクチャ

エンタープライズ チャット アプリケーションには、会話型インタラクションを通じて従業員に権限を与える機能があります。 これは、OpenAI の GPT モデルや Meta の LLaMA モデルなどの大規模言語モデルが継続的に進歩しているため、特に当てはまります。 これらのチャット アプリケーションを構成しているのは、チャット用のユーザー インターフェイス、データ リポジトリ (ユーザーのクエリに関連するドメイン固有の情報を含む)、ドメイン固有のデータについて推論して関連性の高い応答を生成する大規模言語モデル (LLM)、そしてこれらのコンポーネント間の相互作用を監視するオーケストレーターです。

この記事では、Azure OpenAI の大規模言語モデルを使用するエンタープライズ チャット アプリケーションの構築およびデプロイするためのベースライン アーキテクチャについて説明します。 このアーキテクチャでは、Azure Machine Learning (AML) プロンプトフローを使用して、受信プロンプトからデータストアへのワークフローを調整して、LLM の基本データと必要なその他の Python ロジックをフェッチする実行可能フローを作成します。 実行可能フローは、マネージド オンライン エンドポイントの背後にある Azure Machine Learning コンピューティング クラスターにデプロイされます。

カスタム チャット ユーザー インターフェイス (UI) のホスティングは、ゾーン冗長で高可用性のセキュアな Web アプリケーションを Azure APP Services でデプロイするためのベースライン アプリ サービス Web アプリケーションのガイダンスに従います。 そのアーキテクチャでは、App Service はプライベート エンドポイントを介した仮想ネットワーク統合を通じて Azure PaaS サービスと通信します。 同様に、チャット UI App Service はプライベート エンドポイント経由でフローのマネージド オンライン エンドポイントと通信するため、Azure Machine Learning ワークスペースへのパブリック アクセスは無効になります。

Machine Learning ワークスペースはマネージド仮想ネットワーク分離を用いて構成されており、送信接続はすべて承認を受ける必要があります。 この構成では、マネージド仮想ネットワークは、プライベート リソース (職場の Azure Storage、Azure Container Registry、Azure OpenAI など) への接続を可能にするマネージド プライベート エンドポイントと共に作成されます。 これらのプライベート接続は、フローの作成とテスト中に使用され、また Azure Machine Learning コンピューティングにデプロイされたフローによっても使用されます。

Architecture

図 1: OpenAI を使用したベースラインのエンド ツー エンドのチャット アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

コンポーネント

このアーキテクチャのコンポーネントの多くは、ベースライン アプリ サービス Web アプリケーションのリソースと同じです。このアーキテクチャのチャット UI ホスティングは、ベースライン App Service Web アプリケーションのアーキテクチャに従います。 このセクションで強調表示されているコンポーネントは、チャット フローの構築と調整に使用されるコンポーネント、およびデータ サービスと、LLM を公開するサービスに焦点を当てています。

• Azure Machine Learning は、機械学習モデルをトレーニング、デプロイ、および管理するために使用されるマネージド クラウド サービスです。 このアーキテクチャでは、大規模言語モデルを利用した AI アプリケーションの実行可能フローの開発とデプロイに使用される Azure Machine Learning の他の機能をいくつか使用します。
  • Azure Machine Learning プロンプト フローは開発ツールの 1 つで、ユーザー プロンプト、Python コードによるアクション、LLM への呼び出しをリンクするフローを構築、評価、デプロイできます。 このアーキテクチャーのプロンプト フローは、プロンプト、異なるデータ ストア、LLM との間でフローを調整する層として使用されます。
  • マネージド オンライン エンドポイントを使用すると、リアルタイ インターフェイスでフローをデプロイできます。 このアーキテクチャでは、マネージド オンライン エンドポイントは、Azure Machine Learning でホストされているプロンプト フローを呼び出すために、チャット UI の PaaS エンドポイントとして使用されます。
• Azure Storage は、プロンプト フロー開発のプロンプト フロー ソース ファイルを保持するために使用されます。
• Azure Container Registry を使用すると、あらゆる種類のコンテナー デプロイ用のプライベート レジストリにコンテナー イメージや成果物をビルド、保存、管理できます。 このアーキテクチャでは、フローはコンテナー イメージとしてパッケージ化され、Azure Container Registry に格納されます。
• Azure OpenAI は、GPT-4、GPT-3.5-Turbo、Embeddings のモデル セットなど、Azure OpenAI の大規模言語モデルへの REST API アクセスを提供するフル マネージド サービスです。 このアーキテクチャでは、モデル アクセスに加えて、仮想ネットワークとプライベート リンク、マネージド ID のサポート、コンテンツ フィルタリングなどの一般的なエンタープライズ機能を追加するために使用されます。
• Azure AI Search は、フルテキスト検索、セマンティック検索、ベクトル検索、ハイブリッド検索をサポートするクラウド検索サービスです。 Azure AI Search は、チャット アプリケーションの背後にあるフローで使用される一般的なサービスであるため、アーキテクチャに含まれています。 Azure AI Search を使用して、ユーザー クエリに関連するデータを取得してインデックスを作成することができます。 プロンプト フローは、RAG パターンである検索拡張生成を実装して、プロンプトから適切なクエリを抽出し、AI Search にクエリを実行し、その結果を Azure OpenAI モデルの基礎データとして使用します。

Azure Machine Learning プロンプト フロー

エンタープライズ チャット アプリケーションのバックエンドは、通常、次のフローのようなパターンに従います。

• ユーザーがカスタム チャット ユーザー インターフェイス (UI) にプロンプトを入力する
• そのプロンプトがインターフェイス コードによってバックエンドに送信されます
• ユーザーの意図 (質問または指示) がバックエンドによってプロンプトから抽出される
• (省略可能) バックエンドによって、ユーザー プロンプトに関連するデータを保持するデータ ストアが決まる
• バックエンドは関連するデータストア (複数可) にクエリを実行します
• バックエンドで、意図、関連する基礎データ、およびプロンプトで提供された履歴が LLM に送信されます。
• バックエンドは結果をユーザー インターフェイスに表示できるように返します

バックエンドは、任意の数の言語で実装でき、さまざまな Azure サービスにデプロイできます。 このアーキテクチャでは、Azure Machine Learning プロンプト フローが選択されました。プロンプト、バック エンド データ ストア、LLM の間で調整されるフローをより効率的に構築、テスト、デプロイできるためです。

ネットワーク

ネットワーク セキュリティは ID ベースのアクセスと共に、OpenAI を使用したベースラインのエンド ツー エンドのチャット アーキテクチャの中核です。 ネットワーク アーキテクチャでは、大まかに次のことが実現されます。

• チャット UI トラフィックのセキュアな単一エントリ ポイント
• ネットワーク トラフィックがフィルター処理される
• 転送中のデータは TLS を使用してエンドツーエンドで暗号化される
• Private Link を使用して Azure にトラフィックを保持することで、データ流出は最小限に抑えられます
• ネットワーク リソースは論理的にグループ化され、ネットワークのセグメント化によって相互に分離される

ネットワーク フロー

図 2: OpenAI を使用したベースラインのエンド ツー エンドのチャット アーキテクチャに関するネットワーク フロー

この図の 2 つのフローは、ベースラインのアプリ サービス Web アプリケーションで説明されています。1. エンド ユーザーからチャット UI への受信フローおよび 2. App Service から Azure PaaS サービスへのフロー。 これらのフローの詳細については、その記事を参照してください。 このセクションでは、Azure Machine Learning オンライン エンドポイント フローに焦点を当てます。 以下は、ベースライン App Service Web アプリケーションで実行されているチャット UI から Azure Machine Learning コンピューティングにデプロイされるまでのフローの詳細です。

1. App Service でホストされているチャット UI からの呼び出しは、プライベート エンドポイントを経由して Azure Machine Learning オンライン エンドポイントにルーティングされます。
2. オンライン エンドポイントは、デプロイされたフローを実行しているサーバーに呼び出しをルーティングします。 オンライン エンドポイントは、ロード バランサーとルーターの両方として機能します。
3. デプロイされたフローで必要な Azure PaaS サービスへの呼び出しは、マネージド プライベート エンドポイント経由でルーティングされます。

Azure Machine Learning へのイングレス

このアーキテクチャでは、Azure Machine Learning ワークスペースへのパブリック アクセスは無効になります。アクセスは、Azure Machine Learning ワークスペース構成のプライベート エンドポイントに従っているため、プライベート アクセスを介して可能です。 実際、ID ベース セキュリティを補完するために、このアーキテクチャ全体でプライベート エンドポイントが使用されています。 たとえば、App Service でホストされているチャット UI が、Azure Machine Learning エンドポイントなど、パブリック インターネットに公開されていない PaaS サービスに接続できるようにします。

プライベート エンドポイント アクセスは、フロー作成のために Azure Machine Learning ワークスペースに接続するためにも必要です。

図 3: Azure Machine Learning プロンプト フロー作成者のネットワーク フロー

この図は、プロンプト フロー作成者が Azure Bastion 経由で仮想マシン ジャンプ ボックスに接続していることを示しています。 そのジャンプ ボックスから、作成者はジャンプ ボックスと同じネットワーク内のプライベート エンドポイント経由で Machine Learning ワークスペースに接続できます。 仮想ネットワークへの接続は、ExpressRoute または VPN ゲートウェイと仮想ネットワーク ピアリング経由で実現することもできます。

Azure Machine Learning マネージド仮想ネットワークから Azure PaaS サービスへのフロー

Azure Machine Learning ワークスペースは、すべての送信接続の承認が必要な構成を用いて、マネージド仮想ネットワーク分離用に構成することをお勧めします。 このアーキテクチャは、その推奨事項に従います。 承認済みのアウトバウンド規則は 2 種類あります。 必要なアウトバウンド規則は、ソリューションが機能するために必要なリソース (Azure Container Registry や Azure Storage など) が対象になります。 ユーザー定義のアウトバウンド規則は、ワークフローで使用するカスタム リソース (Azure OpenAI や Azure AI Search など) が対象です。 ユーザー定義の送信ルールを構成するのはユーザーの責任ですが、必要な送信ルールはマネージド仮想ネットワークの作成時に構成されます。

送信ルールには、プライベート エンドポイント、サービス タグ、または外部パブリック エンドポイントの FQDN を使用できます。 このアーキテクチャでは、Azure Container Registry、Azure Storage、Azure Key Vault、Azure OpenAI サービス、Azure AI Search などの Azure サービスへの接続は、プライベート リンク経由で接続されます。 このアーキテクチャではありませんが、FQDN アウトバウンド規則を構成する必要がある一般的な操作の中には、pip パッケージのダウンロード、GitHub リポジトリの複製、外部リポジトリからのベース コンテナー イメージのダウンロードがあります。

仮想ネットワークのセグメント化とセキュリティ

このアーキテクチャのネットワークには、次に対する別個のサブネットがあります。

• Application Gateway
• App Service 統合コンポーネント
• プライベート エンドポイント
• Azure Bastion
• ジャンプ ボックス仮想マシン
• トレーニング - このアーキテクチャのモデル トレーニングでは使用されません
• ポイントの計算

各サブネットにはネットワーク セキュリティ グループがあり、これらのサブネットの受信と送信の両方のトラフィックを必要なトラフィックのみに制限します。 次の表には、ベースラインによって各サブネットに追加される NSG 規則を簡単に示しています。 表では、規則名と機能を示しています。

その他のトラフィックはすべて明示的に拒否されます。

仮想ネットワークのセグメント化とセキュリティを実装する場合は、次の点を考慮してください。

• パブリック IP を持つアプリケーション ゲートウェイに属するサブネットがあるすべての仮想ネットワークで、DDoS 保護を有効にします。
• 可能であれば、すべてのサブネットに NSG を追加します。 ソリューションの全機能を有効にする最も厳密な規則を使用する必要があります。
• アプリケーション セキュリティ グループを使用します。 アプリケーション セキュリティ グループを使用すると、NSG をグループ化し、複雑な環境でルールを簡単に作成できます。

コンテンツのフィルタリングと不正使用の監視

Azure OpenAI サービスには、分類モデルのアンサンブルを使用して、入力プロンプトと出力完了の両方において特定のカテゴリの潜在的に有害なコンテンツを検出して防止する、コンテンツ フィルタリング システムが含まれています。 この有害な可能性のあるコンテンツのカテゴリには、ヘイト、性的、自傷行為、暴力、冒涜、および脱獄 (LLM の制約を回避するように設計されたコンテンツ) が含まれます。 カテゴリごとにコンテンツをフィルタリングする厳密さを、低、中、または高のオプションで構成できます。 このリファレンス アーキテクチャは厳格なアプローチを採用しています。 要件に応じて設定を調整する必要があります。

Azure OpenAI サービスでは、コンテンツ フィルタリングに加えて、不正使用の監視機能が実装されています。 不正使用の監視は、Azure OpenAI の行動規範に違反する可能性のある方法でサービスを使用することを示唆する、繰り返し表示されるコンテンツや繰り返し行われる動作のインスタンスを検出して軽減できるように設計された非同期操作です。 たとえば、機密性の高いデータの場合や、不正使用の検出のためにデータの処理を防止する内部ポリシーまたは適用される法律や規制がある場合は、不正使用の監視と人間によるレビューの除外を要求できます。

信頼性

ベースラインの App Service Web アプリケーション アーキテクチャでは、主要なリージョン サービスのゾーン冗長に重点を置いています。 可用性ゾーンは、リージョン内の物理的に分離された場所です。 2 つ以上のインスタンスがリージョン全体にデプロイされている場合、リージョン内にサポート サービスに対する冗長が提供されます。 1 つのゾーンでダウンタイムが発生しても、リージョン内の他のゾーンは影響を受けない場合があります。 このアーキテクチャを使用すると、Azure サービスの十分なインスタンスとそれらのサービスの構成が可用性ゾーンに確実に分散されるようになります。 ベースラインを参照して、そのガイダンスを確認してください。

このセクションでは、Azure Machine Learning、Azure OpenAI、Azure AI Search など、App Service ベースラインで扱われていないこのアーキテクチャのコンポーネントの観点から信頼性について説明します。

フロー デプロイのゾーン冗長

通常、エンタープライズ デプロイには、少なくともゾーン冗長が必要です。 Azure でこれを実現するには、リソースが可用性ゾーンをサポートしている必要があり、少なくともリソースのインスタンスをデプロイするか、インスタンス制御が利用できない場合にはプラットフォーム サポートを有効にする必要があります。 現在、Azure Machine Learning コンピューティングは、可用性ゾーンのサポートを提供していません。 データセンター レベルの大災害による AML コンポーネントへの潜在的な影響を軽減するには、さまざまなリージョンにクラスターを確立すると共に、ロード バランサーをデプロイしてこれらのクラスター間で呼び出しを分散する必要があります。 ヘルス チェックを使用すると、呼び出しが適切に機能しているクラスターにのみルーティングされるようになります。

プロンプト フローのデプロイは、Azure Machine Learning コンピューティング クラスターに限定されません。 実行可能フローはコンテナー化されたアプリケーションであるため、コンテナーと互換性のある任意の Azure サービスにデプロイできます。 これらのオプションには、Azure Kubernetes Service (AKS)、Azure Functions、Azure Container Apps (ACA)、Azure App Service などのサービスが含まれます。 これらの各サービスは、可用性ゾーンをサポートします。 マルチリージョン デプロイをさらに複雑化させることなく、プロンプト フロー実行のゾーン冗長を実現するには、これらのサービスのいずれかにフローをデプロイする必要があります。

以下は、プロンプト フローが Azure App Service にデプロイされる代替アーキテクチャです。 このアーキテクチャで App Service が使用されるのは、ワークロードがすでにチャット UI に App Service を使用しており、ワークロードに新しいテクノロジを導入してもメリットが得られないためです。 AKS の使用経験があるワークロードチームは、特に AKS がワークロード内の他のコンポーネントに使用されている場合は、その環境へのデプロイを検討する必要があります。

図 4: OpenAI を使用してプロンプト フローを Azure App Services にデプロイする、代替のエンド ツー エンドのチャット アーキテクチャ

この図には、このアーキテクチャで注目すべき領域に番号が付けられています。

1. フローは引き続き Azure Machine Learning プロンプト フローで作成され、Azure Machine Learning ネットワーク アーキテクチャは変更されません。 フロー作成者は引き続きプライベート エンドポイント経由でワークスペース作成エクスペリエンスに接続し、フローのテスト時に Azure サービスに接続するためにマネージド プライベート エンドポイントが使用されます。
2. この点線は、コンテナー化された実行可能フローが Azure Container Registry (ACR) にプッシュされることを示しています。 この図には、フローをコンテナ化して ACR にプッシュするパイプラインは示されていません。
3. 同じ App Service プランにデプロイされた別の Web アプリがあり、すでにチャット UI をホストしています。 新しい Web アプリは、コンテナー化されたプロンプト フローをホストし、可用性ゾーン全体に分散された少なくとも 3 つのインスタンスで、すでに実行されている同じ App Service プランに併置されます。 これらの App Service インスタンスは、プロンプトフロー コンテナー イメージを読み込むときに、プライベート エンドポイント経由で ACR に接続します。
4. プロンプトフロー コンテナーは、フローを実行するためにすべての依存サービスに接続する必要があります。 このアーキテクチャでは、Azure AI Search と Azure OpenAI サービスがこれに該当します。 AML マネージド プライベート エンドポイント サブネットにのみ公開されていた PaaS サービスも、仮想ネットワークで公開する必要が出てきたため、App Service から通信経路を確立できます。

Azure OpenAI - 信頼性

Azure OpenAI では現在、可用性ゾーンはサポートされていません。 データセンター レベルの大災害による Azure OpenAI のモデルのデプロイへの潜在的な影響を軽減するには、ロードバランサーをデプロイしてリージョン間で呼び出しを分散すると共に、Azure OpenAI をさまざまなリージョンにデプロイする必要があります。 ヘルス チェックを使用すると、呼び出しが適切に機能しているクラスターにのみルーティングされるようになります。

複数のインスタンスを効果的にサポートするには、微調整ファイルを地理冗長 Azure Storage アカウントなどに外部化することをお勧めします。 これにより、リージョンごとに Azure OpenAI サービスに保存される状態が最小限に抑えられます。 モデル デプロイをホストするには、インスタンスごとに微調整を行う必要もあります。

1 分あたりのトークン数 (TPM) と 1 分あたりの要求数 (RPM) の観点から必要なスループットを監視し、デプロイの需要を満たすのに十分な TPM をクォータから割り当てるようにして、デプロイされたモデルへの呼び出しが抑えられないようにすることが重要です。 Azure API Management (APIM) などのゲートウェイは、OpenAI サービスの前にデプロイでき、一時的なエラーやスロットルが発生した場合に再試行するように構成できます。 APIM は、サービスが呼び出しで一杯になり、クォータを超過するのを防止するためのブレーカー (遮断機) としても使用できます。

Azure AI Search - 信頼性

可用性ゾーンをサポートするリージョンに Standard 価格レベル以上の Azure AI Search をデプロイし、3 つ以上のレプリカをデプロイします。 レプリカは、可用性ゾーン全体に自動的に均等に分散されます。

レプリカとパーティションの適切な数を決定するために、次のガイダンスを考慮してください。

• ガイダンスに従って Azure AI Search を監視します。
• メトリックとログの監視とパフォーマンス分析を使用して、クエリベースの調整を回避するためのレプリカとインデックスベースの調整を回避するためのパーティションについて適切な数を決定します。

Azure Machine Learning - 信頼性

Azure Machine Learning マネージド オンライン エンドポイントの背後にあるコンピューティング クラスターにデプロイする場合は、スケーリングに関する次のガイダンスを考慮してください。

• ガイダンスに従ってオンライン エンドポイントを自動スケールし、需要を満たすのに十分な容量を確保します。 バーストの使用が原因で使用シグナルの適時性が十分とは言えない場合は、オーバープロビジョニングを検討して、使用できるインスタンスが少なすぎることによる信頼性への影響を防ぐようにしてください。
• CPU 負荷などのデプロイ メトリックと、要求の待機時間などのエンドポイント メトリックに基づいたスケーリング規則の作成を検討してください。
• アクティブな運用デプロイには、3 つ以上のインスタンスをデプロイする必要があります。
• 使用中のインスタンスに対するデプロイは避けてください。 代わりに、新しいデプロイにデプロイし、デプロイでトラフィックの受信準備ができたら、トラフィックをシフトします。

セキュリティ

このアーキテクチャは、ネットワークと ID セキュリティ境界の両方を実装します。 ネットワークの観点から見ると、インターネットからアクセスできる必要があるのは、App Gateway を介したチャット UI のみです。 ID の観点から見ると、チャット UI は要求を認証し、承認する必要があります。 可能な場合は、マネージド ID を使用して、アプリケーションを Azure サービスに対して認証します。

ネットワークセキュリティについては、ネットワークのセクションで説明しました。 このセクションでは、ID およびアクセス管理、ならびにキーのローテーションと Azure OpenAI モデルの微調整に関するセキュリティ上の考慮事項について説明します。

ID 管理とアクセス管理

次のガイダンスは、App Service ベースラインの ID およびアクセス管理に関するガイダンスを拡張するものです。

• 必要に応じて、次の AML リソースに対して個別のマネージド ID を作成します。
  • ワークスペース - フロー作成と管理中に使用されます
  • コンピューティング インスタンス - フローのテスト時に使用されます
  • オンライン エンドポイント - マネージド オンライン エンドポイントにデプロイされている場合は、デプロイされたフローによって使用されます
• Microsoft Entra ID を使用してチャット UI の ID アクセス制御を実装する

Azure Machine Learning の RBAC ロール

Azure Machine Learning ワークスペースへのアクセスを管理するために使用できる既定のロールは、AzureML データ科学者、AzureML コンピューティング オペレーター、閲覧者、共同作成者、所有者の 5 つです。 これらの既定のロールに加えて、ワークスペース シークレットやレジストリなどのワークスペース リソースへのアクセスを許可する AzureML ワークスペース接続のシークレット閲覧者と AzureML レジストリ ユーザーがあります。

このアーキテクチャは、必要な場合に上記の ID にのみロールを割り当てることで、最小限の特権の原則に従います。 ロールの割り当てを次に示します。

キーの交換

このアーキテクチャには、キーベースの認証を使用する 2 つのサービスがあります。それは、Azure OpenAI と Azure Machine Learning マネージド オンライン エンドポイントです。 これらのサービスにはキーベースの認証を使用しているため、次のことが重要です。

• 許可されているクライアント (プロンプト フロー コンテナーをホストする Azure Web アプリなど) からのオンデマンド アクセス用に、Azure Key Vault などのセキュア ストアにキーを格納します。
• キー ローテーション戦略を実装します。 キーを手動でローテーションする場合は、キーの有効期限ポリシーを作成し、Azure ポリシーを使用してキーがローテーションされたかどうかを監視する必要があります。

OpenAI モデルの微調整

実装時に OpenAI モデルを微調整する場合は、次のガイダンスを考慮してください。

• 微調整用にトレーニング データをアップロードする場合は、カスタマー マネージド キーを使用してそのデータを暗号化することを検討します。
• Azure Blob Storage などのストアにトレーニング データを格納する場合は、カスタマー マネージド キーを使用してデータ暗号化を行うことを検討し、そのデータへのアクセスを制御する場合はマネージド ID を、そしてそのデータへ接続する場合はプライベート エンドポイントを使用します。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

このセクションでは、Azure Search、Azure OpenAI、Azure Machine Learning の観点からパフォーマンス効率について説明します。

Azure Search - パフォーマンス効率

ガイダンスに従って、Azure AI Search のパフォーマンスを分析します。

Azure OpenAI - パフォーマンス効率

• アプリケーションで、プロビジョニングされたスループットを要求するか、共有ホスティング (従量課金) モデルを使用するかを決定します。 プロビジョニングされたスループットは、OpenAI モデル デプロイの予約済み処理機能を提供し、モデルに予測可能なパフォーマンスとスループットを提供します。 この課金モデルは、プラットフォーム上で近隣ノイズなどのストレス要因を受ける可能性のあるベストエフォート型の共有ホスティング (従量課金) モデルとは異なります。
• プロビジョニングされたスループットの場合は、プロビジョニングマネージド使用率を監視する必要があります

Azure Machine Learning - パフォーマンス効率

Azure Machine Learning オンライン エンドポイントにデプロイする場合:

• オンライン エンドポイントを自動スケールする方法に関するガイダンスに従い、特に使用量が少ない時期に過剰なオーバープロビジョニングを行わずに、需要にきっちりと合わせて調整します
• パフォーマンスの目標を達成するために、オンライン エンドポイントに適切な仮想マシン SKU を選択してください。 最適な構成を見つけるには、少なめのインスタンス数と大きな SKU の組み合わせ、および多めのインスタンス数と小さな SKU の組み合わせの両方のパフォーマンスをテストする必要があります。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

このシナリオの価格例を確認するには、Azure 料金計算ツールを使用します。 この例にはアーキテクチャに含まれるコンポーネントが含まれているだけなので、使用率に合わせて例をカスタマイズする必要があります。 このシナリオで最も高価なコンポーネントは、チャット UI & プロンプト フロー コンピューティングおよび Azure AI Search であるため、コストを最大限削減するには、これらのリソースの最適化に目を向けてみましょう。

Compute

Azure Machine Learning プロンプト フローは、実行可能フローをホストする複数のオプションをサポートしています。 オプションには、Azure Machine Learning、Azure Kubernetes Service、Azure App Service、Azure Container Service のマネージド オンライン エンドポイントが含まれます。 これらのオプションにはそれぞれ独自の課金モデルがあります。 コンピューティングの選択は、ソリューションの全体的なコストに影響します。

Azure OpenAI

Azure OpenAI は従量課金ベースのサービスであり、あらゆる消費ベースのサービスと同様に、供給に対して需要を制御することが一番のコスト管理になります。 これを特に Azure OpenAI サービスで行うには、次のようなアプローチを組み合わせて使用する必要があります。

• クライアントを制御する。 クライアントの動作を制御することは極めて重要であるため、クライアント要求は従量課金モデルの主なコスト源になります。 すべてのクライアントは次を実行する必要があります。
  • 承認を受けます。 制限のないアクセスをサポートするような方法でサービスを公開することを避けます。 ネットワークと ID の両方の制御 (キーまたは RBAC) を介してアクセスを制限します。
  • 自己管理する。 max_tokens や max_completions などの API 呼び出しによって提供されるトークン制限制約を使用するようクライアントに要求します。
  • 実用的であればバッチ処理を使用します。 クライアントを確認して、プロンプトが適切にバッチ処理されるようにします。
  • プロンプトの入力と応答の長さを最適化します。 プロンプトが長いほど消費されるトークンが増えるため、コストは上がりますが、十分なコンテキストが不足しているプロンプトでは、モデルで良い結果を引き出すことはできません。 モデルが有用な応答を生成できるようにするのに十分なコンテキストを提供する簡潔なプロンプトを作成します。 同様に、応答の長さの制限を最適化するようにします。
• Azure OpenAI プレイグラウンドの使用は、必要に応じて、運用前環境インスタンスで行う必要があるため、これらのアクティビティでは運用コストは発生しません。
• 適切な AI モデルを選択する。 モデルの選択も、Azure OpenAI の全体的なコストで大きな役割を果たします。 すべてのモデルには長所と短所があり、個別に価格が設定されています。 ユースケースに適したモデルを使用すると、より安価なモデルで許容できる結果が得られた場合に、より高価なモデルに過剰な支出をすることがなくなります。 このチャット リファレンス実装では GPT-4 よりも GPT 3.5-turbo を選択したことで、十分な結果を得ながらも、モデル デプロイのコストを 1 桁ほど削減しました。
• 課金ブレークポイントを理解する - 微調整は 1 時間ごとに課金されます。 最も効率的にするには、次の請求期間に入ってしまうことを避けながら、1 時間あたりに利用できる時間をできるだけ多く利用して、微調整の結果を改善する必要があります。 同様に、イメージ生成による 100 個のイメージにかかるコストは、1 つのイメージにかかるコストと同じです。 プラスの効果が得られるように価格のブレークポイントを最大限に活用します。
• 課金モデルを理解する - Azure OpenAI は、プロビジョニングされたスループット オファリングを通じてコミットメント ベースの課金モデルでも利用できます。 予測可能な使用パターンが用意できたら、この事前購入課金モデルへの切り替えを評価します (現在の使用量でコスト効率が上がると計算された場合)。
• プロビジョニングの制限を設定する - すべてのプロビジョニング クォータが、ワークロードに含まれることが予測されるモデルのみに、モデルごとに割り当てられていることを確認します。 動的クォータが有効になっている間、すでにデプロイされたモデルのスループットは、このプロビジョニングされたクォータに制限されません。 クォータはコストに直接マップされないため、コストが異なる場合があることに注意してください。
• 従量課金制の使用状況を監視する - 従量課金制を使用している場合は、1 分あたりのトークン数 (TPM) と 1 分あたりの要求数 (RPM) の使用状況を監視します。 どのモデルを使用するかなどのアーキテクチャの設計上の決定事項を通知したり、プロンプト サイズを最適化したりするには、その情報を使用します。
• プロビジョニングされたスループットの使用状況を監視する - プロビジョニングされたスループットを使用している場合は、プロビジョニングマネージド使用率を監視し、購入してプロビジョニングされたスループットが十分に活用されていないことを確認します。
• コスト管理 - OpenAI でコスト管理機能を使用してコストの監視、コストを管理するための予算の設定、リスクや異常を利害関係者に通知するアラートの作成についてガイダンスに従います。

大規模言語モデル運用 (LLMOps)

このアーキテクチャのような Azure OpenAI ベースのチャット ソリューションのデプロイは、Azure DevOps と GitHub を使用したプロンプト フローによる LLMOps のガイダンスに従う必要があります。 さらに、CI/CD およびネットワークで保護されたアーキテクチャのベストプラクティスを考慮する必要があります。 次のガイダンスでは、LLMOps の推奨事項に基づいて、フローとその関連インフラストラクチャの実装について説明します。 このデプロイに関するガイダンスには、ベースラインの高可用性ゾーン冗長 Web アプリケーション アーキテクチャと同じフロントエンド アプリケーション要素は含まれていません。

開発

Azure Machine Learning プロンプト フローでは、Azure Machine Learning スタジオで、および VS Code 拡張機能経由の両方で、ブラウザーベースの作成エクスペリエンスが提供されます。 どちらのオプションも、フロー コードをファイルとして保存します。 Azure Machine Learning スタジオを使用する場合、ファイルは Azure Strage アカウントに格納されます。 VS Code で作業する場合、ファイルはローカル ファイルシステムに格納されます。

コラボレーション開発のベスト プラクティスに従うには、ソース ファイルを GitHub などのオンライン ソース コード リポジトリに保持する必要があります。 このアプローチにより、すべてのコード変更の追跡、フロー作成者間のコラボレーション、すべてのコード変更をテストおよび検証するデプロイ フローとの統合が促進されます。

エンタープライズ開発の場合は、VS Code 拡張機能とプロンプト フロー SDK/CLI を使用して開発する必要があります。 プロンプト フローの作成者は、VS Code からフローを構築してテストし、ローカルに保存されたファイルをオンラインソース管理システムおよびパイプラインと統合できます。 ブラウザーベースのエクスペリエンスは探索的な開発に適していますが、何らかの作業を行うことで、ソース管理システムと統合できます。 フロー フォルダーは、Filesパネルのフロー ページからダウンロードして解凍し、ソース管理システムにプッシュできます。

評価

他のソフトウェア成果物をテストする場合と同様に、チャット アプリケーションで使用されるフローをテストする必要があります。 LLM 出力に対する唯一の「正しい」答えを指定して断言することは困難ですが、LLM 自体を使用して応答を評価できます。 LLM フローの次の自動評価を実装することを検討してください。

• 分類の精度: LLM が "正しい" スコアを与えているか "正しくない" スコアを与えるいるかを評価し、結果を集計して精度グレードを生成します。
• コヒーレンス: モデルで予測した回答の文章がどのように書かれているか、および文章が一貫性をもってどのように相互につながっているかを評価します。
• 流暢性: モデルで予測した回答を、文法と言語の精度の点で評価します。
• コンテキストに対する根拠: モデルで予測した回答が、事前構成されたコンテキストにどれだけ適切に基づいているかを評価します。 LLM の応答が正しい場合でも、指定されたコンテキストに対して検証できない場合、その応答は根拠のないものになります。
• 関連性: モデルで予測した回答がどれだけ質問と一致しているかを評価します。

自動評価を実装する場合は、次のガイダンスを考慮してください。

• 評価からスコアを生成し、事前定義された成功しきい値と比較してスコアを測定します。 これらのスコアを使用して、パイプラインでのテストの合格/不合格を報告します。
• これらのテストの一部では、質問、コンテキスト、およびグラウンド トゥルースの事前構成されたデータ入力が必要です。
• テスト結果の信頼性を確保するために、十分な数の質問と回答のペア、少なくとも 100 ~ 150 のペアを含めることをお勧めします。 これらの質問と回答のペアは、"ゴールデン データセット" と呼ばれます。データセットのサイズとドメインによっては、より大きな母集団が必要になる場合があります。
• LLM を使用してゴールデン データセット内のデータを生成しないようにします。

デプロイ フロー

図 5: プロンプト フローのデプロイ

1. プロンプト エンジニア/データ科学者は、特定のタスクまたは機能に取り組む機能ブランチを開きます。 プロンプトエンジニア/データ サイエンティストは、VS Code のプロンプト フローを使用してフローを反復し、定期的に変更をコミットし、それらの変更を機能ブランチにプッシュします。

2. ローカルでの開発と実験が完了すると、プロンプト エンジニア/データ科学者は機能ブランチからメイン ブランチへのプル要求を開きます。 プル要求 (PR) は PR パイプラインをトリガーします。 このパイプラインでは、次の内容を含む高速の品質チェックが実行されます。

   • 実験フローの実行
   • 構成された単体テストの実行
   • コードベースのコンパイル
   • スタティック コード分析

3. パイプラインには、マージする前に少なくとも 1 人のチーム メンバーが PR を手動で承認する必要があるステップを含めることができます。 承認者はコミッターにはなれず、プロンプト フローの専門知識があり、プロジェクト要件に精通している必要があります。 PR が承認されない場合、マージはブロックされます。 PR が承認されている場合、または承認手順がない場合、機能ブランチはメイン ブランチにマージされます。

4. メインへのマージによって、開発環境のビルドとリリースのプロセスがトリガーされます。 具体的には、次のように使用します。

   a. CI パイプラインは、マージからメインにトリガーされます。 CI パイプラインでは、PR パイプラインで実行されるすべての手順と、次の手順が実行されます。

   • 実験フロー
   • 評価フロー
   • 変更が検出されると、Azure Machine Learning Registry にフローを登録します

   b. CD パイプラインは、CI パイプラインの完了後にトリガーされます。 このフローでは次の手順が実行されます。

   • Azure Machine Learning Registry から Azure Machine Learning オンライン エンドポイントにフローをデプロイする
   • オンライン エンドポイントを対象とする統合テストを実行する
   • オンライン エンドポイントを対象とするスモーク テストを実行する

5. 承認プロセスは、リリース プロモーション プロセスに組み込まれています。承認後、手順 4.a & 4.b.で説明されている CI & CD プロセスが、テスト環境を対象に繰り返されます。 手順 a. と b. は同じですが、テスト環境のスモーク テストの後にユーザー受け入れテストが実行される点が異なります。

6. 手順 4.a & 4.b で説明されている CI & CD プロセスは、テスト環境が検証および承認された後に、リリースを運用環境にレベル上げするために実行されます。

7. ライブ環境へのリリース後、パフォーマンス メトリックを監視し、デプロイされた LLM を評価する運用タスクが実行されます。 たとえば、次のようなものが挙げられます。

   • データドリフトの検出
   • インフラストラクチャの観察
   • コストの管理
   • モデルのパフォーマンスに関する利害関係者への伝達

展開の手引き

Azure Machine Learning エンドポイントを使用すると、運用環境へのリリース時に柔軟な方法でモデルをデプロイできます。 最高のモデルのパフォーマンスと品質を確保するには、次の戦略を検討してください。

• ブルーグリーン デプロイ: この戦略では、すべてのトラフィックを新しいデプロイに転送する前に、Web サービスの新しいバージョンを一部のユーザーまたは要求のグループに安全にデプロイできます。
• A/B テスト: ブルーグリーン デプロイは、変更を安全にロールアウトするのに効果的なだけでなく、一部のユーザーが変更の影響を評価できるようにする新しい動作をデプロイするためにも使用できます。
• パイプラインのプロンプト フローの一部である Python ファイルのリンティングを含めます。 リンティングは、スタイル標準への準拠、エラー、コードの複雑さ、未使用のインポート、変数の名前付けをチェックします。
• ネットワーク分離された Azure Machine Learning ワークスペースにフローをデプロイする場合は、セルフホステッド エージェントを使用してアーティファクトを Azure リソースにデプロイします。
• Azure Machine Learning モデル レジストリは、モデルに変更があった場合にのみ更新する必要があります。
• LLM、フロー、クライアント UI は疎結合である必要があります。 フローとクライアント UI の更新は、モデルに影響を与えることなく行うことができ、また、その逆も同様です。
• 複数のフローを開発してデプロイする場合、各フローには独自のライフサイクルを設定する必要があります。そうすることで、実験から運用環境にフローをレベル上げする際に、疎結合エクスペリエンスを実現できます。

インフラストラクチャ

ベースラインの Azure OpenAI エンド ツー エンド チャット コンポーネントをデプロイすると、プロビジョニングされたサービスの一部はアーキテクチャ内で基本的かつ永続的なものになりますが、一部のコンポーネントは本質的に一時的なものであり、その存在はデプロイに関係しています。

基礎コンポーネント

このアーキテクチャの一部のコンポーネントは、個々のプロンプト フローやモデル デプロイの枠を超えたライフサイクルを持って存在します。 通常、これらのリソースはワークロード チームによる基本的なデプロイの一部として一度デプロイされ、プロンプト フローまたはモデル デプロイの新規、削除、更新とは別に保持されます。

• Azure Machine Learning ワークスペース
• Azure Machine Learning ワークスペース用の Azure Storage アカウント
• Azure Container Registry
• Azure AI Search
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• ジャンプ ボックス用の Azure 仮想マシン

エフェメラル コンポーネント

一部の Azure リソースは、特定のプロンプト フローの設計とより緊密に結合されているため、これらのリソースをコンポーネントのライフサイクルにバインドして、このアーキテクチャのエフェメラル コンポーネントにすることができます。 これらは、フローの追加や削除、新しいモデルの導入など、ワークロードが進化するときに影響を受けます。 これらのリソースは再作成され、以前のインスタンスは削除されます。 これらのリソースの一部は直接 Azure リソースであり、一部は、そのリソースが含まれるサービス内のデータプレーン マニフェストです。

• Azure Machine Learning モデル レジストリのモデルが変更された場合は、CD パイプラインの一部として更新する必要があります。
• コンテナー イメージは、CD パイプラインの一部としてコンテナー レジストリで更新する必要があります。
• Azure Machine Learning エンドポイントは、存在しないエンドポイントをデプロイが参照している場合にプロンプト フローがデプロイされると作成されます。 パブリック アクセスを無効にするには、そのエンドポイントを更新する必要があります。
• Azure Machine Learning エンドポイントのデプロイは、フローがデプロイまたは削除されるときに更新されます。
• 新しいエンドポイントの作成時に、クライアント UI の Key Vault をエンドポイントのキーで更新する必要があります。

監視

すべてのサービスに対して診断が構成されます。 Azure Machine Learning と Azure App Service 以外のすべてのサービスは、ログをすべてキャプチャするように構成されています。 Azure Machine Learning 診断は、顧客とデータのやり取りやサービスの設定を記録するすべてのリソース ログである監査ログをキャプチャするように構成されています。 Azure App Service は、AppServiceHTTPLogs、AppServiceConsoleLogs、AppServiceAppLogs、AppServicePlatformLogs をキャプチャするように構成されています。

このシナリオのデプロイ

参照実装をデプロイして実行するには、OpenAI のエンド ツー エンドのベースライン参照実装の手順に沿って対応してください。

共同作成者

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

• Rob Bagby | パターン & プラクティス - Microsoft
• Freddy Ayala | クラウド ソリューション アーキテクト - Microsoft
• Prabal Deb | シニア ソフトウェア エンジニア - Microsoft
• Raouf Aliouat | ソフトウェア エンジニア II - マイクロソフト
• Ritesh Modi | プリンシパル ソフトウェア エンジニア - Microsoft
• Ryan Pfalz | シニア ソリューション アーキテクト - Microsoft

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

Azure OpenAI の詳細を確認してください

関連リソース

• Azure OpenAI
• Azure OpenAI 大規模言語モデル
• Azure Machine Learningプロンプト フロー
• ワークスペースのマネージド仮想ネットワーク分離
• Azure Machine Learning ワークスペース用にプライベート エンドポイントを構成する
• コンテンツのフィルター処理