翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
分割とデータ漏洩
データ漏洩は、モデルが本番環境にあり、予測リクエストを受信している推論中にモデルがデータを取得したときに発生します。たとえば、トレーニングに使用されたデータサンプルや、モデルが本番環境にデプロイされたときに使用できない情報など、アクセスすべきではないデータ漏洩が発生します。
モデルが誤ってトレーニングデータでテストされた場合、データ漏洩によってオーバーフィットが発生する可能性があります。オーバーフィットは、モデルが見えないデータに対してうまく一般化されないことを意味します。このセクションでは、データ漏洩やオーバーフィットを回避するためのベストプラクティスについて説明します。
データを少なくとも 3 つのセットに分割する
データ漏洩の一般的な原因の 1 つは、トレーニング中にデータを不適切に分割 (分割) することです。たとえば、データサイエンティストは、テストに使用されたデータについてモデルを意図的または無意識にトレーニングした可能性があります。このような状況では、オーバーフィットによって引き起こされる非常に高い成功メトリクスが見られることがあります。この問題を解決するには、データを training、、 validationの 3 つ以上のセットに分割する必要がありますtesting。
この方法でデータを分割することで、 validationセットを使用して、学習プロセス (ハイパーパラメータ) を制御するために使用されるパラメータを選択および調整できます。望ましい結果に達した場合、または改善の頂点に達した場合は、testingセットに対して評価を実行します。testing セットのパフォーマンスメトリクスは、他のセットのメトリクスと似ている必要があります。これは、セット間で分散の不一致がなく、モデルが本番環境でうまく一般化することが予想されることを示します。
層別化分割アルゴリズムを使用する
小さなデータセットtestingのデータを training、validation、 に分割する場合、または高度に不均衡なデータを使用する場合は、必ず階層化された分割アルゴリズムを使用してください。層別化は、各分割に、各分割のクラスのほぼ同じ数または分布が含まれることを保証します。scikit-learn ML ライブラリ
サンプルサイズについては、統計的に有意な結論に達することができるように、検証セットとテストセットに評価に十分なデータがあることを確認してください。たとえば、比較的小さなデータセット (100 万個未満のサンプル) の一般的な分割サイズは、、、および で 70%training、15%validation、15% ですtesting。非常に大規模なデータセット (100 万個を超えるサンプル) では、90%、5%、5% を使用して利用可能なトレーニングデータを最大化できます。
ユースケースによっては、本番データが収集期間中に急激で急激な分散の変化を経験していた可能性があるため、データを追加のセットに分割すると便利です。例えば、食料品店商品の需要予測モデルを構築するためのデータ収集プロセスを考えてみましょう。データサイエンスチームが 2019 年にtrainingデータを収集し、2020 年 1 月から 2020 年 3 月までtestingのデータを収集した場合、モデルはおそらくtestingセットに対して適切にスコア付けされます。ただし、モデルを本番環境にデプロイすると、特定のアイテムのコンシューマーパターンは、 COVID-19 の世界的猶予により既に大幅に変化し、モデルの結果は低下します。このシナリオでは、モデル承認のための追加の保護として、別のセット ( などrecent_testing) を追加するのが理にかなっています。この追加により、ディストリビューションの不一致が原因ですぐにパフォーマンスが低下するモデルを本番環境で承認できなくなる可能性があります。
場合によっては、少数集団に関連するデータなど、特定のタイプのサンプルを含む追加の validationまたは testingセットを作成する場合があります。これらのデータサンプルは正しくするために重要ですが、データセット全体では適切に表現されていない可能性があります。これらのデータサブセットはスライスと呼ばれます。
国全体のデータでトレーニングされ、ターゲット変数のドメイン全体を均等に考慮するようにバランスが取れたクレジット分析用の ML モデルの場合を考えてみましょう。さらに、このモデルにCity機能がある可能性があることも考慮してください。このモデルを使用する銀行がビジネスを特定の都市に拡大する場合、そのリージョンでのモデルのパフォーマンスに関心がある可能性があります。したがって、承認パイプラインは、国全体のテストデータに基づいてモデルの品質を評価するだけでなく、特定の都市スライスのテストデータも評価する必要があります。
データサイエンティストが新しいモデルに取り組むとき、モデルの検証段階で少数派のスライスを統合することで、モデルの機能を簡単に評価し、エッジケースを考慮できます。
ランダム分割を実行するときは、重複したサンプルを検討してください。
もう 1 つの、あまり一般的ではない漏洩の原因は、重複するサンプルが多すぎる可能性のあるデータセットにあります。この場合、データをサブセットに分割しても、異なるサブセットに共通のサンプルがある可能性があります。重複の数によっては、オーバーフィットが一般化と間違える場合があります。
本番環境で推論を受信するときに使用できない可能性のある機能を検討する
データ漏洩は、推論が呼び出された時点で、実稼働環境で利用できない機能を使用してモデルがトレーニングされた場合にも発生します。モデルは履歴データに基づいて構築されることが多いため、このデータは、ある時点で存在しなかった追加の列や値で強化される可能性があります。過去 6 か月間に顧客が銀行に対して行ったローンの数を追跡する機能を持つクレジット承認モデルの場合を考えてみましょう。このモデルがデプロイされ、銀行に 6 か月の履歴がない新規顧客のクレジット承認に使用されると、データ漏洩のリスクがあります。
Amazon SageMaker AI Feature Store
