翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 分割とデータ漏洩
データ漏洩は、モデルが本番環境にあり、予測リクエストを受信している推論中にモデルがデータを取得したときに発生します。たとえば、トレーニングに使用されたデータサンプルや、モデルが本番環境にデプロイされたときに使用できない情報など、アクセスすべきではないデータ漏洩が発生します。
モデルが誤ってトレーニングデータでテストされた場合、データ漏洩によってオーバーフィットが発生する可能性があります。オーバーフィットは、モデルが見えないデータに対してうまく一般化されないことを意味します。このセクションでは、データ漏洩やオーバーフィットを回避するためのベストプラクティスについて説明します。
## データを少なくとも 3 つのセットに分割する
データ漏洩の一般的な原因の 1 つは、トレーニング中にデータを不適切に分割 (分割) することです。たとえば、データサイエンティストは、テストに使用されたデータについてモデルを意図的または無意識にトレーニングした可能性があります。このような状況では、オーバーフィットによって引き起こされる非常に高い成功メトリクスが見られることがあります。この問題を解決するには、データを `training`、、 `validation`の 3 つ以上のセットに分割する必要があります`testing`。
この方法でデータを分割することで、 `validation`セットを使用して、学習プロセス (*ハイパーパラメータ*) を制御するために使用されるパラメータを選択および調整できます。望ましい結果に達した場合、または改善の頂点に達した場合は、`testing`セットに対して評価を実行します。`testing` セットのパフォーマンスメトリクスは、他のセットのメトリクスと似ている必要があります。これは、セット間でディストリビューションの不一致がなく、モデルが本番環境でうまく一般化されることが予想されることを示します。
## 層別化分割アルゴリズムを使用する
小さなデータセット`testing`でデータを `training`、`validation`、 に分割する場合、または非常に不均衡なデータを使用する場合は、必ず階層分割アルゴリズムを使用してください。層別化は、各分割に、各分割のクラスのほぼ同じ数または分布が含まれることを保証します。[scikit-learn ML ライブラリ](https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.train_test_split.html)はすでに階層化を実装しており、[Apache Spark ](https://spark.apache.org/docs/latest/api/python/reference/pyspark.sql/api/pyspark.sql.DataFrame.sampleBy.html)も実装しています。
サンプルサイズについては、統計的に有意な結論に達することができるように、検証セットとテストセットに評価に十分なデータがあることを確認してください。たとえば、比較的小さなデータセット (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](https://aws.amazon.com/sagemaker/feature-store/) は、この問題を解決するのに役立ちます。タイムトラベルクエリを使用してモデルをより正確にテストできます。タイムトラベルクエリを使用すると、特定の時点でデータを表示できます。