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