Azure で AI ワークロードのトレーニング データを設計する
アプリケーションで AI 機能のデータを設計する場合は、運用性、コスト、セキュリティなどの機能以外の要件と、データ インジェスト、準備、検証に関連する機能要件の両方を考慮してください。
データ設計とアプリケーション設計を切り離すことはできません。 アプリケーションの設計では、ユース ケース、クエリ パターン、鮮度の要件を理解する必要があります。 AI を使用する必要性を促進するビジネス要件に対処するために、アプリケーションでは、判別モデル、生成モデル、またはモデルの種類の組み合わせからの出力が必要になる場合があります。
意味のある結果を得るには、AI モデルをトレーニングする必要があります。 モデル トレーニングでは、新しい状況や見えない状況を分類または予測するようにモデルに教える必要があります。 トレーニング データは、特定の問題とワークロードコンテキストに合わせて調整する必要があります。
教師ありトレーニングでは、ラベル付きのサンプルをモデルに提供します。 この種類のトレーニングは、目的の結果が明確な場合に役立ちます。 これに対し、教師なし学習では、モデルは、予想される出力に関するガイダンスなしで、データ内のパターンとリレーションシップを識別できます。 トレーニング中に、モデルの学習方法を制御するために、アルゴリズムの種類とそのパラメーターが調整されます。 このアプローチは、ニューラル ネットワーク、デシジョン ツリーなど、モデルの種類によって異なります。
たとえば、画像検出モデルは、通常、物体検出、顔認識、シーン理解などのタスクでトレーニングされます。 注釈付き画像から学習し、特定のオブジェクトまたは特徴を識別します。 その他の一般的な例としては、不正検出アルゴリズムや価格ポイント予測モデルなどがあります。 これらのモデルは、過去の財務データから学習し、情報に基づいた意思決定を行います。
この記事では、主に前述のユース ケースに焦点を当てています。モデルは 前にトレーニングされており アプリケーションに意味のある入力を提供できます。 この記事には、データの収集、処理、格納、テスト、およびメンテナンスに関するガイダンスが含まれています。 探索的データ サイエンスまたは AI を介したビジネス インテリジェンスのデータ設計については説明しません。 目標は、AI ワークロードのトレーニング データ パイプラインに関する推奨事項を提供することで、ワークロードの要件に合わせた戦略を通じてトレーニング ニーズをサポートすることです。
コンテキストの 保証 推論を必要とする AI モデルのデータ設計については、「 データ設計を参照してください。
重要
データ設計は、統計的実験に基づく反復的なプロセスであることを期待します。 許容できる品質レベルに到達するには、トレーニング データ、その処理、モデル特徴開発、モデルハイパーパラメーター (可能な場合) を調整します。 この実験ループは、通常、最初のモデル トレーニング中と、ワークロード内の機能の有効期間にわたるデータとモデルの誤差に対処するための継続的な絞り込み作業の間に発生します。
推奨事項
この記事で提供される推奨事項の概要を次に示します。
| 推奨 | 説明 |
|---|---|
| ワークロードの要件に基づいてデータ ソースを選択します。 | 使用可能なリソースと、データ ソースがモデル トレーニングで許容できるデータ品質に到達するのに役立つかどうかを考慮します。 正と負の両方の例について説明します。 多様なデータ型を組み合わせて、分析とモデリングに十分な完全性を実現します。 データの不足や不均衡に対する合成少数派オーバーサンプリング手法 (SMOTE) などの手法を検討してください。 ▪ Data インジェストと分析 |
| 収集したデータに関するデータ分析を早期に実施。 | Exploratory Data Analysis (EDA) などの分析プロセスをオフラインで実行します。 コストとセキュリティへの影響を考慮してください。 リソース制約のない小規模なデータセットの場合は、ソースで分析を実行することを検討できます。 ▪ Data コレクション ストア |
| ビジネス要件と技術要件で必要な場合は、データのセグメント化を維持。 | 個別のセキュリティ要件を持つデータ ソースを使用する場合は、モデルごとに個別のパイプラインを作成します。 特定のデータ サブセットとの対話を制限するアクセス制御を確立します。 ▪ Data のセグメント化 |
| データを前処理して、トレーニング目標に対して意味のあるものにします。 | ノイズをフィルター処理し、データのスコープを変更し、重複に対処し、多様な形式を標準化することで、取り込まれたデータの品質を調整します。 ▪ Data の前処理 |
| 古いデータに対するトレーニングは避けてください。 | 内部および外側の運用ループの一部としてデータドリフトと概念ドリフトを監視し、モデルの精度と信頼性を経時的に維持します。 新しい観測値を使用してトレーニング データを定期的に更新します。 モデルの再トレーニングをトリガーする条件を定義し、更新頻度を決定します。 ▪ Data メンテナンス |
データの型
モデルで予測力を構築するには、データを収集して処理し、モデルにフィードする必要があります。 通常、このプロセスは、ステージに分割されたパイプラインとして概念化されます。 パイプラインの各ステージは同じデータ セットを処理する場合がありますが、異なる目的に対応する場合があります。 通常、次の型のデータを処理します。
ソース データ はポイントインタイム観測データです。 また、データ パイプラインへの潜在的な入力として機能するようにラベル付けできるデータを指定することもできます。
通常、このデータは運用環境または外部ソースから取得されます。 これらのデータ ソースは、ストレージ アカウント、データベース、API、またはその他のソースに含めることができます。 データは、OLTP データベース、非構造化ドキュメント、ログ ファイルなど、さまざまなデータ形式にすることができます。 このデータは、データ パイプラインへの潜在的な入力として機能します。
トレーニング データ は、モデルにサンプルを提供するために使用されるソース データのサブセットです。 サンプルは、モデルがパターンとリレーションシップを学習するのに役立つ説明的な事前計算済みデータです。 このデータがないと、モデルは関連する出力を生成できません。
評価データ は、トレーニング中に機械学習モデルのパフォーマンスを監視および検証するために使用されるソース データのサブセットです。 トレーニング データとテスト データとは異なり、トレーニング フェーズ中にモデルのパフォーマンスを定期的に評価し、ハイパーパラメーターのチューニングをガイドするために使用されます。 詳細については、「 Model の評価」を参照してください。
テスト データ は、トレーニング済みモデルの予測力を検証するために使用されます。 このデータは、トレーニングに使用されなかったソース データからサンプリングされます。 テスト プロセスが決定的になるように、運用環境からの観察が含まれています。 データ設計の観点から、このデータを格納する必要があります。 モデルのテストについては、「 Testing デザイン領域」を参照してください。
場合によっては、アプリケーションとの対話中にユーザーによって提供される情報が、最終的にソース データになる可能性があります。 一般に、この方法を使用したユーザー入力は高品質であることをお勧めします。 そうしないと、品質の問題をダウンストリームで継続的に処理する必要が問題になる可能性があります。 ユーザー データの処理に関するガイダンスについては、この記事では説明しません。
データインジェストと分析
トレーニング データは、選択したモデルの種類をトレーニングするための十分な表現を持つ、事前に定義されたウィンドウ内に収集されます。 たとえば、二項分類モデルをトレーニングする場合、トレーニング データには、ケース (肯定的な例) とそうでないもの (否定的な例) の表現が含まれている必要があります。 トレーニング データを意味のあるものにするには、機能設計の早い段階で EDA を実施します。
EDA は、ソース データを分析して、特性、リレーションシップ、パターン、品質の問題を特定するのに役立ちます。 ソース データ ストアで EDA を直接実行したり、データ レイクやデータ ウェアハウスなどの一元的なストアにデータをレプリケートしたりできます。 このプロセスの結果は、効果的なモデル トレーニングのためにデータの収集と処理を通知することです。
Note
EDA は実稼働前プロセスですが、運用環境から取得されたデータを使用します。 運用環境の場合と同じレベルの制御をこのプロセスに適用します。
モデル トレーニングの準備としてデータを収集する際の考慮事項を次に示します。
データ ソース
データは、次のソースから収集できます。
独自のデータ は、組織によって作成または所有されます。 これは、パブリック消費を目的としたものではありません。 内部的な目的を果たします。
パブリック ソース はだれでもアクセスできます。 これらのソースには、Web サイト、研究論文、パブリック共有データベースが含まれます。 ニッチな領域に固有の場合があります。 たとえば、Wikipedia と PubMed のコンテンツは、パブリックにアクセス可能と見なされます。
データ ソースの選択は、ワークロードの要件、使用可能なリソース、モデルのトレーニングに許容されるデータの品質によって異なります。 不均衡なデータセットは、偏ったモデルにつながる可能性があるため、代表的なデータの十分なサンプルを取得するためにデータ収集を設計する必要があります。 マイノリティ データまたはアンダーサンプル マジョリティ データのオーバーサンプリングが必要になる場合があります。 データが不足しているか不均衡な場合は、 SMOTE や 合成データ生成などの手法を検討。
データ 収集ストア
ソース データを収集するには、主に次の 2 つのオプションがあります。
- データ ソースでのデータのクエリ
- ローカライズされたデータ ストアにデータをコピーし、そのストアに対してクエリを実行する
選択は、ワークロードの要件とデータの量によって異なります。 データ量が比較的少ない場合は、ソース システムが直接生クエリを処理する可能性があります。 ただし、一般的な方法は、ローカライズされたストアからクエリを実行して分析することです。
Tradeoff. ローカライズされたデータ ストアは分析とトレーニング プロセスを容易にする場合がありますが、コスト、セキュリティ、モデルの要件のバランスを取る必要もあります。
データを複製すると、ストレージとコンピューティングのコストが発生します。 別のコピーを維持する場合は、追加のリソースが必要です。 ローカル コピーには機密情報が含まれている場合があります。 その場合は、通常のセキュリティ対策を使用してデータを保護する必要があります。
トレーニング データに運用データを使用する場合は、そのデータのすべての元のデータ分類の制約に従う必要があります。
データはトレーニング プロセス (プッシュ モード) に提供することも、プロセス自体がデータ ソース (プル モード) に対してクエリを実行することもできます。 選択は、所有権、効率性、およびリソースの制約によって異なります。
データがワークロードにプッシュされると、データ ソース所有者は新しいデータを提供する必要があります。 ワークロード所有者は、ローカライズされたデータ ストアにデータを格納するための適切な場所を提供します。 この方法は、パブリック ソースではなく、組織が所有する独自のデータに適用されます。
データのプルに使用できる方法は 2 つあります。 1 つのアプローチでは、ワークロードはデータ ストアに対してクエリを実行し、必要なデータを取得し、ローカライズされたストアに配置します。 もう 1 つの方法は、メモリ内でリアルタイム クエリを実行することです。 決定は、データ ボリュームと使用可能なコンピューティング リソースによって異なります。 データセットが小さい場合は、メモリ内の取得でモデルのトレーニングに十分な場合があります。
プッシュ モードとプル モードのどちらを使用するかに関係なく、古いデータに対するモデルのトレーニングは避けてください。 データ更新の頻度は、ワークロードの要件に合わせる必要があります。
データのセグメント化
ワークロード固有の要件では、データのセグメント化が必要になる場合があります。 考えられるユース ケースを次に示します。
多くの場合 セキュリティ要件によってセグメント化の決定が促進されます。 たとえば、規制上の制約により、地政学的リージョン間でのデータのエクスポートが妨げられます。 アプリケーション設計で個別のモデルを使用できる場合、データ設計にはモデルごとに個別のデータ パイプラインが組み込まれます。
ただし、1 つのモデルを使用する場合は、セグメント化されたデータ ソースがそのモデルにフィードされます。 両方の地域のデータに対してモデルをトレーニングする必要があり、複雑さが増す可能性があります。
アプリケーションが 1 つのモデルを使用しているか、複数のモデルを使用しているかに関係なく、各データ セグメントのセキュリティ対策を保持して、配信元のデータと同じレベルの厳しさで保護されるようにします。
データの鮮度率 は、データを分離するための要因となる場合があります。 異なるソースからのデータは、さまざまな時間間隔で更新される場合があります。 データが変更されると、再トレーニングが必要になります。 セグメント化により、データ ライフサイクルをきめ細かく制御できます。 異なるデータ セグメントに個別のテーブルまたはパイプラインを使用することを検討してください。
ユース ケースに関係なく、データをセグメント化する場合は、アクセス制御がキーになります。 データ エンジニアやデータ サイエンティストなどのデータプロフェッショナルは、使用可能なソース データを調べて、パターンと関係を理解します。 その分析情報は、結果を予測するトレーニング モデルに貢献します。 承認されたユーザーのみが特定のデータ サブセットと対話できるように、アクセス制御を確立します。 関連性があると見なされるデータに対して最小限の特権を適用します。 データ所有者と共同作業して、適切なアクセス許可を設定します。
データの前処理
実際のシナリオでは、ソース データは単に AI シナリオ用に格納されるわけではありません。 トレーニング用にデータを準備する中間プロセスがあります。 この段階では、データがノイズを除去され、消費に役立ちます。 ソース データを扱うとき、データ サイエンティストは探索、実験、意思決定のプロセスに取り組みます。 主な目標は、予測力を保持するソース データの一部を特定して抽出することです。
前処理ロジックは、問題、データ型、および必要な結果によって異なります。 前処理の一般的な手法を次に示します。 このリストは、包括的ではありません。 ワークロードの実際の条件は、ビジネス要件に基づきます。
品質。 前処理は、トレーニング データがノイズを除去するのに役立ちます。 目標は、トレーニング データ内のすべての行が、ユース ケースに関連する明確な観察または良い例を表し、品質や予測能力を欠く観察を排除することです。 たとえば、製品レビューを照合する場合は、短すぎるデータを排除することを選択できます。 意味のある予測結果を生み出すデータ品質を見つける必要があります。
スコープ。 特定しすぎるソース データ フィールドでは、予測能力が制限される可能性があります。 たとえば、アドレス フィールドを考えてみます。 完全な住所 (自宅番号と番地) から、市区町村、都道府県、国/地域などの上位レベルに範囲を広げると、より関連性が高くなる可能性があります。
重複除去。 冗長性を排除することで、トレーニング データを正確かつ代表的な状態に保つことができます。 場合によっては、観測の頻度は関係ありません。 たとえば、ログをスキャンするときに、ログ エントリが 1,000 回表示された場合、その頻度を示します。 必ずしも、1 回だけ発生したログよりも重大なエラーであるとは限りません。 この種類の冗長性により、ノイズが発生する可能性があります。
機密データの処理。 匿名化では実現できない方法でモデルの予測能力に絶対に不可欠でない限り、個人データを排除します。 トレーニング データは、プライバシーを損なうことなく効果的である必要があります。 データが価値を提供する場合は、機密データの処理に関する倫理的な考慮事項に注意する必要があります。 詳細については、「責任ある AI」を参照してください。
標準化された変換。 ドメインの専門家は、前述の手法を特徴エンジニアリングの中核となる部分と考えている。 広範な範囲と多様なソース データは、最終的には、モデルをトレーニングする明示的な目的のために、特徴が整理されている機能ストア (たとえば、特徴テーブル) にマージする必要があります。 トレーニング用の予測データを選択した後、データを標準化された形式に変換します。 標準化により、トレーニング モデルとの互換性も確保されます。
画像をテキスト表現に変換することは、変換の一種です。 たとえば、スキャンしたドキュメントや画像を機械で読み取り可能なテキストに変換できます。
モデルとの互換性を確保するために、モデルの期待に合わせて画像の向きまたは縦横比を調整することが必要になる場合があります。
Note
大量の構造化データと非構造化データを混在させると、処理時間が長くなる可能性があります。 ワークロード チームは、多様な形式の処理の影響を測定する必要があります。 再トレーニングの間の期間が短くなるにつれて、前処理に費やされる時間がより重要になります。
データの保持
モデルをトレーニングした後、トレーニングに使用するデータを削除するかどうかを評価し、次のトレーニング ウィンドウでモデルを再構築します。
データが比較的変更されていない場合は、モデルの誤差が発生しない限り、再トレーニングは必要ない可能性があります。 予測の精度が低下した場合は、モデルを再トレーニングする必要があります。 データの再取り込み、前処理、モデルの構築を選択できます。 最後のトレーニング期間以降にデータに有意な差分がある場合は、この一方のアクションが最適です。 大量のデータがあり、あまり変更されていない場合は、モデルを前処理して再構築する必要がない可能性があります。 その場合は、データを保持し、インプレース更新を行い、モデルを再トレーニングします。 トレーニング データを保持する期間を決定します。
一般に、パフォーマンスが低く、現在または将来のモデルに関連しなくなった機能の低優先コストとストレージ コストを削減するために、機能ストアからデータを削除します。 データを保持する場合は、コストを管理し、データの重複の一般的な懸念事項であるセキュリティの問題に対処する必要があります。
系列の追跡
データ系列 は、ソースからモデル トレーニングでの使用までのデータのパスを追跡することを指します。 説明容易性のためには、データ系列を追跡することが不可欠です。 ユーザーはデータの起源に関する詳細情報を必要としないことがありますが、その情報は内部データ ガバナンス チームにとって非常に重要です。 系列メタデータは、モデルによって直接使用されていない場合でも、透明性と説明責任を保証します。 これはデバッグに便利です。 また、データの前処理中にバイアスが導入されるかどうかを判断するのにも役立ちます。
可能な場合は、系列追跡にプラットフォーム機能を使用します。 たとえば、Azure Machine Learning は Microsoft Purview に統合されています。 この統合により、MLOps ライフサイクルの一部として、データ検出、系列追跡、ガバナンスの機能にアクセスできます。
データのメンテナンス
すべてのモデルが時間の経過と同時に古くなる可能性があるため、モデルの予測能力や関連性が低下します。 いくつかの外部変更によって、ユーザーの行動の変化、市場のダイナミクス、その他の要因など、減衰が発生する可能性があります。 状況が変化するため、しばらく前にトレーニングされたモデルの関連性が低い場合があります。 より忠実度の高い予測を行うには、最新のデータが必要です。
新しいモデルの採用。 関連性を確保するには、モデルのパフォーマンスを継続的に評価し、新しいモデルを考慮する運用ループが必要です。これにより、データ パイプラインの中断を最小限に抑えることができます。 または、データのライフサイクルとパイプラインの再設計を伴うより大きな変更に備えることができます。
新しいモデルを選択する場合、必ずしも新しいデータ セットから始める必要はありません。 トレーニングに使用される既存の観測値は、モデル切り替え中でも価値が残る可能性があります。 新しいモデルではシナリオが狭くなる可能性がありますが、基本的なプロセスは変わりません。 特徴ストアやデータ メッシュなどのデータ管理アプローチにより、新しい機械学習モデルの導入を効率化できます。
トリガー ベースの操作とルーチン操作。 モデルの再トレーニングを特定のイベントまたは条件によってトリガーするかどうかを検討します。 たとえば、新しい、より関連性の高いデータが利用可能になったり、確立されたベースラインより低い関連性が低下したりすると、再トレーニングがトリガーされる可能性があります。 このアプローチの利点は、応答性とタイムリーな更新です。
メンテナンスは、毎日や毎週のように、定期的に一定の間隔でスケジュールすることもできます。 フェール Proof 操作の場合は、両方の方法を検討してください。
データの削除。 リソースの使用を最適化し、モデルトレーニングに古いデータや無関係なデータを使用するリスクを最小限に抑えるために、トレーニングに使用されなくなったデータを削除します。
忘れられる権利は オンライン プラットフォームまたはデータベースから個人データを削除する個人の権利を指します。 トレーニングに使用される個人データを削除するためのポリシーを設定してください。
データ保有。 状況によっては、既存のモデルを再構築する必要があります。 たとえば、ディザスター リカバリーの場合は、致命的なイベントの前とまったく同じようにモデルを再生成する必要があります。 モデルの減衰への対処、トリガー ベースまたはルーチン操作による定期的な更新、その他のメンテナンス タスクなど、プライマリ パイプラインのワークロード要件に従うセカンダリ データ パイプラインを用意することをお勧めします。
データのメンテナンスがモデル操作の一部として行われることを確認します。 可能な限り自動化によって変更を処理し、適切なツール セットを使用するプロセスを確立する必要があります。 詳細については、Azure での AI ワークロード MLOps と GenAIOpsに関するページを参照してください。