Azure での AI ワークロードのアプリケーション設計
AI 関数を持つアプリケーションを作成する場合は、多くの選択肢を考慮する必要があります。 ユース ケースが従来の機械学習、生成、決定論的、または AI の種類の組み合わせのいずれであるかなど、独自の機能要件と非機能要件は、設計に関する高レベルの決定を絞り込むのに役立ちます。 これらの選択は、高レベルの設計領域から下位レベルの設計領域に移行する際に考慮します。
「作業の開始」 記事で説明したように、独自のモデルを構築するか、事前構築済みのモデルを使用するかは、最初に行う重要な決定事項の 1 つです。 事前構築済みモデルを使用する場合は、次の点を考慮してください。
カタログ ソース。 Hugging Face Model Hub、TensorFlow Hub、Azure AI Foundry ポータル モデル カタログなどのリポジトリを調べて、事前トレーニング済みのモデルを見つけます。 これらのプラットフォームは、さまざまなタスクのモデルの広範なカタログを提供します。
ライセンス。 特にアプリケーションを配布したり、他のサービスと統合したりする場合は、モデルのライセンス条項がセキュリティ、コンプライアンス、アプリケーションの目標に合っていることを確認します。
主要なコンポーネント。 モデルのアーキテクチャ、トレーニング データ、パフォーマンス、ライセンスを調べて、タスクまたはドメインに合わせて微調整されているかどうかを判断します。
ホスティング プラットフォームの選択に関するガイダンスについては、「モデルのホスティングと推論プラットフォームのに関する考慮事項」を参照してください。
この記事では、テクノロジとアプローチに関する決定を行うときに考慮すべき一般的な設計領域と要因について説明します。
推奨事項
次の表は、この記事で提供される推奨事項をまとめたものです。
| 推奨 | 説明 |
|---|---|
| 既製のソリューションに優先順位を付ける。 | 実用的な場合は常に、サービスとしてのプラットフォーム (PaaS) ソリューションを使用してワークロード機能を処理します。 可能な場合は、事前構築済みおよび事前トレーニング済みのモデルを使用して、ワークロードチームと運用チームの運用と開発の負担を最小限に抑えます。 |
| クライアントから離れた抽象関数と機能。 | レート制限やフェールオーバー操作などの横断的な問題を処理するようにバックエンド サービスを設計することで、クライアントをできるだけ薄く保ちます。 |
| データ ストアへのアクセスをブロックします。 | AI システム内のコードは、データ ストアに直接アクセスしないでください。 API レイヤーを介してすべてのデータ要求をルーティングします。 API は、必要なタスク専用に構築する必要があります。 |
| モデルを分離する。 | データ ストアと同様に、API レイヤーを使用して、モデルへの要求のゲートウェイとして機能します。 Azure OpenAI Service や Azure Machine Learning などの一部の PaaS ソリューションでは、この目的に SDK が使用されます。 プロンプト フローなどの多くのツールには、API をサービスに伝達するためのネイティブ サポートが含まれています。 |
| コンポーネントを個別に展開できるように設計。 | AI モデル、データ パイプライン、フロントエンド コンポーネント、データの前処理、特徴抽出、推論などのマイクロサービスは、ワークロードの柔軟性、スケーラビリティ、および操作性を最適化するために、個別にデプロイできる必要があります。 |
コンポーネントをコンテナー化する
独立してデプロイ可能なコンポーネントが完全に自己完結型であることを確認し、デプロイを合理化するには、設計戦略の一部としてコンテナー化を検討してください。 次のコンポーネントをコンテナー化する必要があります。
マイクロサービス. データ処理、モデル推論、ユーザー認証など、アプリケーションの特定の機能を処理する個々のマイクロサービスをコンテナー化する必要があります。 このアプローチにより、独立したデプロイとスケーリングが可能になり、より効率的な更新とメンテナンスが容易になります。
AI モデル。 AI モデルをコンテナー化して、すべての依存関係、ライブラリ、および構成がバンドルされていることを確認します。 この方法では、モデル環境をホスト システムから分離して、バージョンの競合を防ぎ、異なるデプロイ環境間で一貫した動作を確保します。
データ処理パイプライン。 データクリーニング、変換、特徴抽出など、モデル推論の前または後に行うデータ処理タスクは、コンテナー化する必要があります。 このアプローチにより、再現性が向上し、依存関係の管理が簡略化されます。
インフラストラクチャ サービス。 データベースやキャッシュ レイヤーなどのインフラストラクチャサポートを提供するサービスは、コンテナー化のメリットも得られます。 これらのサービスをコンテナー化すると、バージョンの整合性を維持し、これらのコンポーネントのスケーリングと管理が容易になります。
AI コンポーネントを他のワークロード コンポーネントと併置する
AI コンポーネントを他のワークロード コンポーネントと併置する理由はいくつかありますが、それに関連するトレードオフがあります。 コンポーネントの併置は、次の理由で選択できます。
待機時間感度。 低待機時間が重要な場合は、API ホスティングなどの他のサービスと AI コンポーネントを併置します。 たとえば、ユーザー エクスペリエンスを向上させるためにリアルタイム推論が必要な場合、API の近くに AI モデルを配置すると、結果の取得にかかる時間を最小限に抑えることができます。
データの近接性。 AI モデルが検索インデックスなどの特定のデータセットに頻繁にアクセスする必要がある場合、これらのコンポーネントを併置すると、パフォーマンスが向上し、データ転送のオーバーヘッドが軽減され、処理と推論が高速化されます。
リソース使用率。 CPU やメモリなど、特定のコンポーネントに補完的なリソースニーズがある場合は、それらを併置することでリソース使用量を最適化できます。 たとえば、大量の計算を必要とするモデルでは、同時に需要が低いサービスとリソースを共有できます。
トレードオフ。 コンポーネントを併置するかどうかを決定する際に考慮すべきトレードオフがあります。 コンポーネントを個別にデプロイまたはスケーリングする機能が失われる可能性があります。 また、インシデントの爆発半径を増やすことで、誤動作のリスクを高めることもできます。
生成 AI ソリューションでのオーケストレーターの使用を評価する
オーケストレーターは、複雑なワークロードでは管理が困難な AI ソリューションのさまざまなコンポーネント間の通信を調整することで、ワークフローを管理します。 ワークロードに次のいずれかの特性がある場合は、オーケストレーターを設計に組み込することをお勧めします。
複雑なワークフロー ワークフローには、前処理、モデル チェーン、後処理など、複数の手順が含まれます。
条件付きロジック 。 結果をさまざまなモデルにルーティングするなどの決定は、モデルの出力に基づいて動的に行う必要があります。
スケーリングとリソース管理の。 需要に基づくモデル スケーリングを使用して、大量のアプリケーションのリソース割り当てを管理する必要があります。
状態管理。 ユーザー操作の状態とメモリを管理する必要があります。
データ取得。 インデックスから拡張データを取得できる必要があります。
複数のモデルを使用する場合の考慮事項
ワークロードで複数のモデルを使用する場合は、オーケストレーターが不可欠です。 オーケストレーターは、ユース ケースに基づいてデータと要求を適切なモデルにルーティングします。 モデル間のデータ フローを計画し、あるモデルからの出力が別のモデルの入力として機能することを確認します。 計画には、データ変換またはエンリッチメント プロセスが含まれる場合があります。
オーケストレーションとエージェント
生成 AI ワークロードの場合は、オーケストレーションに拡張性を追加するために、エージェントベースのアプローチ ( agentic とも呼ばれる) を設計に取ることを検討してください。 エージェントは、コンテキストにバインドされた機能を提供します。 マイクロサービスと多くの特性を共有し、オーケストレーターと組み合わせてタスクを実行します。 オーケストレーターは、エージェントのプールにタスクをアドバタイズすることも、エージェントがオーケストレーターに機能を登録することもできます。 どちらの方法でも、オーケストレーターは、エージェント間でクエリを分割してルーティングする方法を動的に決定できます。
エージェントアプローチは、エクスペリエンスに接続できる複数の進化する機能を備えた共通の UI サーフェスを使用して、時間の経過と同時にフローにスキルと接地データを追加する場合に最適です。
エージェントが多い複雑なワークロードの場合、オーケストレーターを使用してタスクを分割して割り当てるのではなく、エージェントが動的に共同作業できるようにする方が効率的です。
オーケストレーターとエージェントの間の通信は、トピック キュー パターンに従う必要があります。このパターンでは、エージェントはトピックのサブスクライバーであり、オーケストレーターはキューを介してタスクを送信します。
エージェントアプローチの使用は、 choreography パターンではなくオーケストレーション パターンに最適です。
詳細については、「オーケストレーション プラットフォームの Considerationsを参照してください。
API ゲートウェイの使用を評価する
Azure API Management などの API ゲートウェイ API から関数を抽象化し、要求元のサービスと API の間の依存関係を分離します。 API ゲートウェイは、AI ワークロードに次の利点を提供します。
複数のマイクロサービス。 ゲートウェイは、レート制限や認証などの一貫性のあるポリシーを適用する必要がある場合に、複数の AI モデル エンドポイントを管理するのに役立ちます。
トラフィック管理。 ゲートウェイは、要求の管理、応答のキャッシュ、負荷の分散によって、トラフィックの多いアプリを効率的に管理するのに役立ちます。
セキュリティ。 ゲートウェイは、ゲートウェイの背後にある API に対して一元的なアクセス制御、ログ記録、脅威保護を提供します。
AI アプリケーションの設計パターンを使用する
AI アプリケーションの業界では、いくつかの一般的な設計パターンが確立されています。 これらを使用して、設計と実装を簡略化できます。 これらの設計パターンは次のとおりです。
モデル アンサンブリング。 この設計パターンでは、複数のモデルからの予測を組み合わせて、個々のモデルの弱点を軽減することで精度と堅牢性を向上させます。
マイクロサービスのアーキテクチャ。 コンポーネントを個別にデプロイ可能なサービスに分離することで、スケーラビリティと保守容易性が向上します。 これにより、チームはアプリケーションのさまざまな部分で同時に作業できます。
イベント駆動型アーキテクチャ。 イベントを使用してアクションをトリガーすると、分離されたコンポーネントとリアルタイム処理を使用して、変化するデータに対するシステムの応答性と適応性を高めます。
RAG パターンとチャンク戦略
Retrieval-Augmented 生成 (RAG) パターンは、生成モデルと取得システムを組み合わせたものです。これにより、モデルは外部ナレッジ ソースにアクセスしてコンテキストと精度を向上できます。 このパターンの詳細なガイダンスについては、設計と RAG ソリューション 一連の記事を参照してください。 2 つの RAG アプローチがあります。
Just-In-Time。 この方法では、要求時に関連情報を動的に取得して、最新のデータが常に使用されるようにします。 リアルタイム コンテキストを必要とするシナリオでは有益ですが、待機時間が発生する可能性があります。
事前計算 (キャッシュ)。 この方法では、取得結果をキャッシュして、事前に計算されたデータを提供することで応答時間を短縮します。 これは、一貫性のあるデータを格納できる需要の高いシナリオに適しています。 データに最新の情報が反映されていない可能性があり、関連性の問題につながる可能性があります。
RAG パターンを使用する場合、ワークロードのパフォーマンス効率を最適化するには、明確に定義されたチャンク戦略が不可欠です。 設計で提供されている ガイダンス から始めて、RAG ソリューション シリーズを開発します。 考慮すべきその他の推奨事項を次に示します。
データ型、クエリの複雑さ、およびユーザー要件に基づいてチャンク サイズを調整する動的チャンク戦略を実装します。 これにより、取得効率とコンテキストの保持が強化されます。
フィードバック ループを組み込んで、パフォーマンス データに基づいてチャンク戦略を調整します。
グラウンド ソースにリンクするメタデータと一意の識別子を維持することで、チャンクのデータ系列を保持します。 明確な系列ドキュメントは、ユーザーがデータの原点、変換、および出力にどのように貢献するかを確実に理解するのに役立ちます。
デザイン パターンを使用する場合
ユース ケースが説明されている条件を満たす場合は、次の設計パターンを使用することを検討してください。
複雑なワークフロー. 複雑なワークフローや複数の AI モデル間の相互作用がある場合、RAG やマイクロサービスなどのパターンは、複雑さを管理し、コンポーネント間の明確な通信を確保するのに役立ちます。
スケーラビリティ要件。 アプリケーションの需要が変動する場合、マイクロサービスのようなパターンを使用すると、個々のコンポーネントを個別にスケーリングして、システム全体のパフォーマンスに影響を与えることなく、さまざまな負荷に対応できます。
データ ドリブン アプリケーション。 アプリケーションで広範なデータ処理が必要な場合、イベント ドリブン アーキテクチャを使用すると、リアルタイムの応答性と効率的なデータ処理を実現できます。
Note
通常、小規模なアプリケーションや POC は、これらの設計パターンの利点を得られません。 これらのアプリケーションは、わかりやすくするために設計する必要があります。 同様に、リソース (予算、時間、人員) の制約がある場合は、後でリファクタリングできる単純な設計を使用する方が、複雑な設計パターンを採用するよりも優れたアプローチです。
適切なフレームワークとライブラリを選択する
フレームワークとライブラリの選択は、アプリケーション設計と密接に関連しています。 パフォーマンス、スケーラビリティ、保守容易性に影響します。 ただし、設計要件によってフレームワークの選択が制限される場合があります。 たとえば、セマンティック カーネル SDK を使用すると、多くの場合、各エージェントまたは関数が独自のサービス内にカプセル化されるマイクロサービス ベースの設計が推奨されます。 フレームワークとライブラリを選択するときは、次の要因を考慮してください。
アプリケーションの要件。 リアルタイム処理やバッチ処理などのアプリケーションの要件によって、フレームワークの選択が制限される場合があります。 たとえば、アプリケーションで低待機時間が必要な場合は、非同期機能を備えるフレームワークを使用することが必要になる場合があります。
統合にはが必要です。 設計では、他のシステムやサービスとの特定の統合が必要になる場合があります。 フレームワークが必要なプロトコルまたはデータ形式をサポートしていない場合は、設計を再検討するか、別のフレームワークを選択する必要があります。
チームの専門知識。 開発チームのスキル セットでは、フレームワークの選択を制限できます。 あまり使い慣れていないフレームワークに依存する設計では、開発時間と複雑さが増す可能性があるため、より使い慣れたツールを使用できます。
ID、承認、アクセスの戦略を設計する
一般に、ID、承認、アクセスは、通常アプリケーションを設計する場合と同じ方法でアプローチする必要があります。 これらの領域を可能な限り管理するには、Microsoft Entra ID などの ID プロバイダーを使用する必要があります。 ただし、多くの AI アプリケーションには、特別な考慮事項が必要な固有の課題があります。 新しい開発なしでシステムを通じてアクセス制御リスト (ACL) を保持することは困難な場合や不可能な場合もあります。
セキュリティ トリミング メタデータをドキュメントやチャンクに追加する方法については、セキュアなマルチテナント RAG 推論ソリューション設計ガイド を参照してください。 このトリミングは、セキュリティ グループまたは同様の組織構造に基づいて行うことができます。
機能しない要件を検討する
ワークロードには、AI テクノロジに固有の要因が原因で課題となる非機能要件が存在する場合があります。 一般的な非機能的要件とその課題を次に示します。
モデル推論およびタイムアウトのレイテンシ 多くの場合、AI アプリケーションでは、リアルタイムまたはほぼリアルタイムの応答が必要です。 待ち時間を短くするための設計は非常に重要です。 これには、モデル アーキテクチャ、データ処理パイプライン、ハードウェア リソースの最適化が含まれます。 タイムアウトを回避し、タイムリーな応答を提供するには、キャッシュ戦略の実装と効率的なモデル読み込みの確保も不可欠です。
トークンまたは要求スループットの制限。 多くの AI サービスでは、特にクラウドベースのモデルでは、トークンの数または要求のスループットに制限が課されます。 これらの制限を設計するには、入力サイズを慎重に管理し、必要に応じて要求をバッチ処理し、ユーザーの期待を管理し、サービスの中断を防ぐためにレート制限またはキュー メカニズムを実装する可能性があります。
コストとチャージバックのシナリオ。 コストの透明性を確保するための設計には、チャージバック モデルを容易にする使用状況の追跡とレポート機能の実装が含まれます。 これらの機能により、組織は部門間でコストを正確に割り当てることができます。 チャージバック管理は、通常、Azure API Managementなどの API ゲートウェイによって処理されます。