次の方法で共有


AI の管理 – AI を管理するプロセス

この記事では、AI ワークロードを管理するための組織のプロセスについて説明します。 開発から、デプロイ、操作に至るまで AI ワークロードを管理するための推奨事項が提供されます。 効果的な AI 管理には、開発からデプロイ、継続的な操作に至るまでの構造化されたアプローチが必要です。 データ ドリフトやモデル ドリフトなどの問題を防止し、AI が長期にわたって正確で信頼性の高い状態を維持するために、企業は、標準化されたプラクティスと定期的な監視を必要としています。

AI 導入プロセスを示す図: AI 戦略、AI 計画、AI-Ready、AI のガバナンス、AI の管理、セキュリティで保護された AI。

AI 操作を管理する

AI 操作を管理することで、AI ライフサイクル全体の可視性と一貫性が確保されます。 MLOps のような操作フレームワークの採用、サンドボックス環境の作成、CI/CD パイプラインの確立により、開発、テスト、デプロイを監視することができます。

  • AI 操作のフレームワークを採用します。 従来の機械学習ワークフロー用の MLOps (機械学習の運用) フレームワークと、生成 AI ワークロード用の GenAIOps を実装します。 これらの操作フレームワークは、AI 開発のエンド ツー エンド サイクルを編成します。 各フレームワークは、ワークロード チームのアプローチとツールに影響します。 詳細については、MLOps とGenAIOps を参照してください。

  • AI 開発ツールを標準化します。 開発チーム間で一貫性を保つため、SDK と API の使用を定義して標準化します。 AI ワークロード用の Azure SDK などのツールは、AI モデルのスケーリングとアプリケーションへの統合に最適化されたライブラリと API を提供します。 生成 AI の場合は、セマンティック カーネル、LangChain、プロンプト フローなどの AI プラットフォームとオーケストレーターを標準化します。

  • AI 実験にはサンドボックス環境を使用します。 AI モデルの実験にはサンドボックス環境を使用します。 開発、テスト、および運用環境間で一貫性を保つ必要があります。 そのため、AI 開発ライフサイクルにおいて、サンドボックス環境は、開発、テスト、運用環境とは区別する必要があります。 開発環境、テスト環境、運用環境の間でデプロイやガバナンス モデルを変更すると、破壊的変更が非表示になったり、導入されたりする可能性があります。

  • デプロイのための継続的統合と継続的デリバリーのパイプラインを確立します。 データ パイプラインで、リンティングや静的分析などのコード品質チェックがカバーされていることを確認します。 データ パイプラインには、単体テストや統合テスト、実験や評価のフローも含める必要があります。 最後に、手動による承認に従って、リリースをテスト環境や運用環境に昇格させるといった、運用環境のデプロイ手順を組み込みます。 1 つのコンポーネントの更新が他のコンポーネントに影響しないように、モデル、プロンプト フロー、クライアント ユーザー インターフェイスの分離を維持します。 各フローには、独立した昇格のための独自のライフサイクルが必要です。

AI のデプロイを管理する

AI デプロイ管理では、AI リソースをデプロイできるユーザーと、これらのエンドポイントを管理するユーザーを定義します。 AI センター オブ エクセレンスが主導する構造化されたアプローチは、企業がワークロード チームと中央チームのどちらがリソースを管理すべきかを決定し、開発速度とガバナンス要件のバランスを取るのに役立ちます。 AI CoE は、最適なアプローチを決定する取り組みを主導します。

  • AI リソースのワークロード チーム管理により、より迅速な開発を実現します。 ワークロード チームが AI リソースを管理する場合、ガバナンス ポリシーの範囲内で AI リソースをデプロイおよび管理する自律性があります。 Azure Policy を使用して、すべてのワークロード環境に一貫したガバナンスを適用します。 ワークロード チームが従うべき AI ポリシーを作成し、伝達することで、ガバナンスのギャップに対処します。 たとえば、コンテンツ フィルター設定を適用し、許可されていないモデルの使用を防止する生成 AI ポリシーを作成します。 これらのポリシーをワークロード チームに明確に周知し、定期的に監査します。

    AI ワークロードのワークロード チーム管理を示す図。図 1. AI リソースのワークロード チーム管理。

  • AI リソースの共有管理を使用して、AI ガバナンスを強化します。 共有 AI 管理アプローチでは、中央チームがすべての AI ワークロードの AI リソースを管理します。 このチームは、コア AI リソースをデプロイし、すべてのワークロード チームが使用するセキュリティとガバナンスを構成します。 1 つのチームでワークロード全体の AI デプロイとガバナンスを制御する場合は、このアプローチを使用します。

    AI ワークロードの共有管理を示す図。図 2. AI リソースの中央 AI チーム管理。

AI エンドポイント共有を管理する

ワークロード間で AI エンドポイントを共有することで管理を効率化できますが、ガバナンスとモデルの要件を慎重に考慮する必要があります。 企業は、ニーズが一貫した単一のワークロード内でのみエンドポイントを共有すべきです。異なるニーズ間でエンドポイントを共有すると、ガバナンスが複雑になり、コストが増加する可能性があります。

  • ガバナンスとモデルのニーズが異なる場合は、AI エンドポイントを共有しないようにします。 入力と出力のガバナンスなど、さまざまなコンテンツ フィルター設定を必要とするワークロードでは、エンドポイントを共有しないでください。 また、別の AI モデルがワークロード要件を満たす、よりコスト効率の高い方法を提供する場合は、単一の AI エンドポイントを共有しないでください。

  • 1 つのワークロード内でのみ AI エンドポイントを共有します。 AI エンドポイントの共有は、ワークロード チームが同じワークロードの一部として複数のアプリケーションを持っている場合に最適です。 AI エンドポイント共有は、管理オーバーヘッドを最小限に抑え、デプロイを簡素化します。 これらのアプリケーションは、同じガバナンス ニーズと AI モデル ニーズを共有する必要があります。 エンドポイントを共有すると、レート制限とクォータ制限に達する可能性があります。 ほとんどの Azure サービスには、サブスクリプションごとの制限があります。 サブスクリプション内では、各リージョンにクォータ制限があります。

AI モデルを管理する

AI モデル管理には、ガバナンス構造の設定、継続的な監視、長期にわたってパフォーマンスを維持するための再トレーニングが含まれます。 このプロセスは、企業がモデルを倫理基準と整合させ、モデルのパフォーマンスを追跡し、AI システムの効果とビジネス目標との整合性が維持されていることを確認するのに役立ちます。

  • AI 監視のためのガバナンス構造を確立します。 AI センター オブ エクセレンス (AI CoE) を作成するか、AI リードを任命します。 責任ある AI 標準への準拠を確保する必要があります。 これらのレポートに基づいてシステムを調整する必要があるかどうかを判断すべきです。 責任ある AI ダッシュボードを使用して、モデルの出力に関するレポートを生成します。

  • AI の測定ベースラインを定義します。 AI モデルがビジネス目標および倫理基準と一致していることを確認するために測定ベースラインを確立します。 公平性、透明性、正確性など、責任ある AI 原則に関連する KPI を使用します。 これらの KPI を AI ワークロードにマップします。 たとえば、顧客サービス チャットボットでは、さまざまな人口統計グループ間でモデルのパフォーマンスを評価して公平性を測定します。 これらの測定値を取得するには、責任ある AI ダッシュボードで使用されるツールから始めます。

  • 継続的な監視を実施します。 AI ワークロードは、データの進化、モデルの更新、ユーザー行動の変化などにより、時間の経過とともに変化する可能性があります。 AI モデルAI リソースAI データを監視して、これらのワークロードが KPI と一致していることを確認します。 定義された責任ある AI の原則と評価基準に照らして AI システムを評価するための監査を実施します。

  • パフォーマンスの問題の根本原因を特定します。 パフォーマンスや精度の低下が検出された場合、AI をモニタリングすることで問題の原因を特定します。 問題を特定し、是正措置をより迅速に実施するために、対話の各段階を確実に可視化します。 たとえば、カスタマー サービス チャットボットが不正確な応答を生成する場合、モニタリングすることによって、そのエラーがプロンプトの作成に含まれているのか、それともモデルの文脈理解にあるのかを判断することができます。 Azure Monitor や Application Insights などの組み込みツールを使用して、パフォーマンスのボトルネックや異常を事前に特定します。

  • モデルの提供終了を追跡します。 ベンダー サポートの終了に伴うパフォーマンスの問題を防ぐために、事前トレーニング済みモデルの提供終了を追跡します。 たとえば、生成 AI モデルが非推奨になる可能性があるため、機能を維持するには更新する必要があります。 Studio には、すべてのデプロイのモデル提供終了日が表示されます。

  • 必要に応じて AI モデルを再トレーニングします。 データの変化によるモデルの経年劣化を考慮します。 モデルのパフォーマンスまたはビジネス ニーズに基づいて定期的な再トレーニングをスケジュールし、AI システムの関連性を維持します。 再トレーニングにはコストがかかるため、初期トレーニングのコストを評価し、そのコストを使用して AI モデルを再トレーニングする頻度を評価します。 モデルのバージョン管理を維持し、パフォーマンスの低いバージョンのロールバック メカニズムを確保します。

  • モデルの昇格プロセスを確立します。 品質ゲートを使用し、パフォーマンス基準に基づいて、トレーニング済み、微調整済み、再トレーニング済みのモデルをより高い環境に昇格させます。 パフォーマンス基準は、各アプリケーションに固有です。

AI コストを管理する

AI コストを管理するには、コンピューティング、ストレージ、トークン処理など、リソースに関連する費用を明確に理解する必要があります。 予期せぬ出費を避け、リソース効率を最適化するために、コスト管理のベスト プラクティスを導入し、使用量を監視し、自動アラートを設定する必要があります。

  • 各サービスのコスト管理のベスト プラクティスに従います。 各 Azure サービスには、コストを最大限最適化するための特定の機能とベスト プラクティスがあります。 Azure AI FoundryAzure OpenAI Service、および Azure Machine Learningの のコストの計画と管理に関する次のガイダンスについて理解します。

  • 課金効率を監視して最大化します。 コスト ブレークポイントを理解して、不要な料金を回避します。 たとえば、画像生成のための定額しきい値をフル活用したり、1 時間ごとに微調整したりすることができます。 1 分あたりのトークン数 (TPM) や 1 分あたりの要求数 (RPM) など、使用パターンを追跡し、それに応じてモデルとアーキテクチャを調整します。 一貫した使用パターンには、コミットメントベースの課金モデルを検討してください。

  • 自動コスト アラートを設定します。 予算アラートを使用して予期せぬ請求が通知されるようにし、AI 経費を制御および予測する予算戦略を確立します。

Azure OpenAI を使用した生成 AI アプリケーションについては、次のコスト最適化の推奨事項を参照してください。

AI データを管理する

効果的な AI データ管理では、AI ライフサイクル全体を通じてデータの正確性、整合性、機密度を維持することに重点を置いています。 高品質のデータセットをキュレーションし、データ パイプラインをセキュリティで保護することで、データの信頼性を維持し、変化する規制要件に準拠することができます。

  • データの正確性を維持し、ゴールデン データセットをキュレーションします。 両方の AI タイプにわたって、定期的なテストと検証に使用される権威ある一連のデータを開発します。 このデータセットを継続的にキュレーションして、最新の正確な情報が確実に反映されるようにします。

  • データ パイプラインの整合性を確保します。 カスタム データ パイプラインを開発して維持し、データ コレクションから前処理とストレージまでのデータ整合性を確保します。 どちらのタイプの AI アプリケーションにおいてもパフォーマンスと信頼性を維持するには、パイプラインの各ステップをセキュリティで保護する必要があります。

  • データの機密度の変更を管理します。 データの機密度の分類は、時間の経過とともに変化する可能性があることを理解してください。 ビジネスや規制の変更が原因で、機密性の低いデータを機密性の高いものとして再分類したくなる場合があります。 ダウンストリーム システムの機密データを削除または置き換えるプロセスを開発します。 Microsoft Defender for CloudMicrosoft Purview は、機密データのラベル付けと管理に役立ちます。 このプロセスは、AI のインジェストの前に、適切なデータ カタログから始まります。 変更が発生した場合は、その機密データを使用するすべてのモデルまたはシステムを特定します。 可能であれば、再分類された機密データを除外したデータセットで AI モデルを再トレーニングします。

AI のビジネス継続性を管理する

AI のビジネス継続性とディザスター リカバリーには、複数リージョンのデプロイを作成し、復旧計画を定期的にテストする必要があります。 これらの戦略は、中断時にも AI システムの稼働を維持し、長時間の停止やデータ損失のリスクを最小限に抑えるのに役立ちます。

  • AI には複数リージョン デプロイを使用します。 生成型と非生成型両方の AI システムの高可用性と回復性を確保するために、複数リージョン デプロイを実装します。 これらの戦略により、ダウンタイムを最小限に抑え、地域的な停止やインフラストラクチャの障害時にも、重要な AI アプリケーションを確実に稼働させることができます。 停止中に再トレーニングを行う必要がないように、トレーニング済みおよび微調整されたモデルに必要な冗長性を実装してください。

  • ディザスター リカバリー計画を定期的にテストして検証します。 ディザスター リカバリー計画の定期的なテストを実行して、生成型および非生成型の AI システムを効果的に復元できることを確認します。 データ復元プロセスのテストと検証手順を含め、復旧後にすべての AI コンポーネントが正常に機能していることを確認します。 定期的に検証することで、実際のインシデントに備え、復旧中の障害のリスクを最小限に抑えることができます。

  • AI システムの変更を管理および追跡します。 モデル、データ、構成に対するすべての変更が、Git などのバージョン管理システムで管理されていることを確認します。 これを行うことは、変更を追跡し、復旧中に以前のバージョンを復元できるようにするために重要です。 生成 AI および非生成 AI については、計画外の変更をすばやく特定して元に戻すことができるように、モデルとシステムの変更の自動監査を実施する必要があります。

次のステップ