次の方法で共有

Azure 上の AI ワークロード

  • [アーティクル]

この記事では、AI ワークロードの設計に関するアーキテクチャの課題について説明します。 非決定的な機能、データとアプリケーションの設計、および操作に重点を置いています。 推奨事項は、Azure Well-Architected Framework の原則に基づいており、成功した Azure 実装からの分析情報が含まれています。

これらの記事は、ワークロード所有者アーキテクト、開発リーダー、IT リーダーなどの技術関係者を対象としています。 さまざまな役割とチーム間のコラボレーションが重要な側面であるため、データ サイエンティストなどの特殊な AI とデータ ロールも、このガイダンスに注意する必要があります。

Note

Azure には、ワークロードに統合したり、それを中心に構築したりできるさまざまな AI サービスが用意されています。 ビジネス ニーズに応じて、フル マネージドのサービスとしてのソフトウェア (SaaS) ソリューション、サービスとしてのプラットフォーム (PaaS) ソリューション、または独自の AI ソリューションの構築を選択できます。 ここでは、特定の Azure サービスとその機能については説明しません。 その情報については、それぞれの製品ドキュメントを参照することをお勧めします。

また、次のような特定の AI ワークロードはスコープ内にありません。

  • ローコードおよびノーコードのサービス (Copilot Studio など) によって実現されるワークロード。
  • ハイ パフォーマンス コンピューティングを必要とするワークロード。
  • 生成型または差別的な AI ユース ケースを実装していないワークロード。

AI ワークロードとは

Well-Architected Framework のコンテキストでは、AI ワークロードは予測タスク、判別タスク、または生成タスクのニーズを満たします。 倫理的な機能に焦点を当て、進化の速い AI テクノロジに適応し、関連性と説明性を維持します。 Well-Architected Framework の柱をすべての決定ポイントで 適用して、システムが信頼性、セキュリティ、効率性、コスト効率を確保できるようにします。

AI ワークロードは、ワークロードの一部の決定論的な機能を、固定された結果が実用的でない状況で解決する非決定的な動作に置き換えるため、従来のワークロードとは異なります。 代わりに、コードとデータをエンティティまたは モデルに結合して、従来のシステムでは提供できない独自のエクスペリエンスを実現します。

設計戦略を開始する前に、まずこれらの重要な点を考慮してください。

モデルの幅広いカテゴリについて理解する

  • 生成 AI: 機械学習を使用して、自律的に新しいコンテンツを作成します。 これには、ユーザー データを使用してカスタマイズしたり、Azure OpenAI Service などのサービスとして使用したりできる言語モデルが含まれています。 たとえば、言語モデルの一種である GPT は、人間の会話言語の模倣に特化しており、チャットや自然言語のエクスペリエンスに最適です。

    ユース ケース: 生成 AI は、記事、ストーリー、アートを生成できます。 また、合成データを生成してデータセットのバランスを取り、チャットボットをより人間的なものにすることもできます。

  • 判別 AI: 明示的なプログラミングを使用して、ルールとアルゴリズムに基づいて特定のタスクを実行します。 次の内容に分かれています。

    • モデルベースの: 予測システムは、予測を行うために以前の観察から実行されたトレーニングに基づいてパターンを見つけますが、新しいコンテンツを作成したり、独自に適応したりすることはできません。
    • モデルベース以外の: 自律エージェントは、事前に定義されたルールに従って、ビデオ ゲームのキャラクターなどのシステムと対話します。

    ユース ケース: 識別 AI は、予測分析、レコメンデーション システム、不正行為の検出に使用されます。

この一連の記事では、さまざまな AI ワークロードについて説明し、必要に応じて言語モデルなどの特定の種類に焦点を当てます。

重要

生成モデルと判別モデルのどちらかを選択する場合は、実行する必要があるタスクについて考えてください。 生成モデルでは、新しいデータが作成されます。 判別モデルは、特徴に基づいて既存のデータを分類します。 分類タスクまたは回帰タスクの場合は、ジョブに適合するモデルを選択します。 たとえば、分類できる言語モデルは、分類のみを行う言語モデルよりも汎用性が高い場合があります。

ビルドと購入のオプションを評価する

一般的な応答が許容される場合は、事前構築済みのモデルまたは不透明な処理を使用する AI サービス ベースのソリューションで、ワークロードに十分である必要があります。 ただし、ビジネスに固有のデータが必要な場合や、コンプライアンス要件がある場合は、カスタム モデルを作成します。

カスタム モデル、事前構築済みモデル、またはサービスのいずれかを選択する場合は、次の要因を考慮してください。

  • データ制御: カスタム モデルを使用すると、機密データをより詳細に制御できます。 事前構築済みモデルは、一般的なタスクに対して簡単です。
  • カスタマイズ: カスタム モデルは、固有のニーズに適しています。 事前構築済みモデルでは、柔軟性が欠ける可能性があります。
  • コストと維持: カスタム モデルには、継続的なメンテナンスとリソースが必要です。 事前構築済みモデルでは、通常、初期コストが低く、インフラストラクチャの負担が少なくなります。
  • パフォーマンス: 事前構築済みサービスは、最適化されたインフラストラクチャとスケーラビリティを提供します。 待ち時間の短いニーズやスケーラビリティの高いニーズに最適です。
  • 専門知識: カスタム モデルには熟練したチームが必要です。 事前構築済みモデルは、多くの場合、デプロイが迅速になり、専門知識が限られている場合は簡単に使用できます。

重要

独自のモデルを作成して維持するには、多くのリソース、時間、専門知識が必要です。 決める前に十分に研究することが重要です。 通常、事前構築済みのモデルまたはマネージド サービスを選択することをお勧めします。

一般的な課題とは

  • コンピューティング コスト: コンピューティングのニーズが高いため、AI 関数のコストが高くなる可能性があり、コンピューティングのニーズはワークロードの設計によって異なる場合があります。 要件を理解し、コストを管理するための適切なサービスを選択します。
  • セキュリティとコンプライアンスの要件: 既製のソリューションは、セキュリティとコンプライアンスのニーズを満たしていない可能性があります。 不要な負担を回避するための研究オプション。
  • データ量: 大量のデータをさまざまな形式で処理する場合、機密情報の保護と効率的な処理の課題が伴います。 ストレージ、処理、転送コストの最適化は、継続的なアクティビティである必要があります。
  • モデルの減衰: モデルは時間の経過と同時に低下する可能性があり、結果が不正確になります。 AI システムのテストは、そのランダム性のために困難です。
  • スキルの課題: 新しい AI ワークロードには、広範なトレーニングを必要とする特殊なロールと新しい運用プロセスが必要になる場合があります。
  • AI イノベーションのペース: 最新のテクノロジを採用することは、最先端に留まりたくなる可能性があります。 新しいテクノロジを慎重に評価して、ユーザー エクスペリエンスを向上させ、最新の状態を保つためだけに複雑さを追加しないようにします。
  • 倫理的要件: ユース ケースが AI の倫理的なターゲットであるかどうかを明確に判断します。 責任あるシステムを構築するためには、計画と実装のフェーズ全体を通じて倫理基準を維持する必要があります。

このガイダンスの使用方法

✔ 設計手法から始めます。この手法では、技術的および運用領域全体の論理的根拠と繰り返しのテーマが概説されています。 この体系的なアプローチは、要件と設計戦略を定義するのに役立ちます。 ワークロードの全体的な目標に合わせて調整する不確実な選択に直面した場合は、この手法を見直します。 また、技術的な決定を正当化し、継続的な改善のために顧客のフィードバックを組み込むために、利害関係者と共同作業するためのフレームワークも提供します。

✔ 設計の原則に進み、設計手法が主要な Well-Architected Framework の柱にどのように適合しているかを確認します。 成長の進化を検討してください。 すべての柱の基礎となる原則を、トレードオフも含めて総合的に評価します。

✔ ソリューションに最も大きな影響を与える 設計領域 に焦点を当てます。 各領域には、設計の意思決定を導くための考慮事項と推奨事項が含まれています。

✔ Assessment Review Tool を使用して、運用環境での最適化された AI ワークロードの準備状況を評価します。

一般的なアーキテクチャ パターンと設計領域

次の図は、最初の収集から最終的なユーザー操作まで、システムを介してデータがどのように流れるかを示しています。

AI ワークロードの一般的なアーキテクチャ パターンを示す図。

このアーキテクチャでは、さまざまなコンポーネントの統合が強調され、AI 駆動型ソリューションでの効率的なデータ処理、モデルの最適化、リアルタイムアプリケーションのデプロイが可能になります。 これには、データ ソース、データ処理、モデル トレーニング、モデルデプロイ、ユーザー インターフェイスなどのモジュールが含まれます。

次の表では、そのパターンに関連するいくつかの主要な設計領域について説明します。

設計領域
アプリケーション設計: 既存のアプリケーション設計標準に大きな影響を与える可能性がある AI ワークロード固有の考慮事項について説明します。
アプリケーション プラットフォーム: モデルのホスティング、モデル トレーニング、推論など、AI ワークロード機能をサポートするために使用する最適なプラットフォームを決定します。
トレーニング データ設計: モデル トレーニング データを処理するためのデータ インジェスト、前処理、保持、ガバナンスに関するトピックの設計戦略。
接地データ設計: 検索可能性と取得を最適化し、接地データのセキュリティとコンプライアンスの要件を満たす設計戦略。
データ プラットフォームの: ワークロードで使用される大量のデータおよび多くの形式を効果的に処理できる最適なホスティング プラットフォームを決定します。
機械学習操作とジェネレーティブ AI 運用: 機械学習または生成型 AI の機能とシステムをサポートする最新の DevOps プラクティスを確立します。
ワークロード運用: 新しいアプローチで運用プラクティスを最新化し、特殊なロールとトレーニングを追加します。
テストと評価の: AI ワークロードを対象とするメトリックを使用して、精度、精度、感度、特定性などの特性を測定するためのテストおよび評価戦略を開発します。
ワークロード ペルソナ: AI ワークロードのライフサイクル全体にペルソナがどのように関与しているかを理解し、チームが完全に構築およびサポートできるようにします。
責任ある AI: AI ソリューションを一般に公開するユーザー エクスペリエンスと倫理的な影響に特別な注意を払います。 AI は、新しい製品やサービスに素晴らしい機会をもたらしますが、かなりのリスクも伴います。

ヒント

すべてのアーキテクチャ上の決定には、さまざまな考慮事項と、フレームワークのさまざまな側面のバランスを取る一連の認識された妥協点が伴います。 これらのトレードオフは、このアイコン によって示されます。

次のステップ

設計手法