データ漏えいこんにちは
テストグループとトレーニンググループ間のデータ漏洩に関するいくつかの投稿を読みました。 漏れを避けるための一般的な提案：
1正規化、標準化、欠測値の代入の前に、トレーニングとテストセットでデータベースを分割します
2時系列の場合、ランダム分割を避けます。 タイムカットポイントを決定し、それを使用してトレーニングセットとテストセットを分離します。
コメント、提案、役立つ読み物はありますか？
フェリーチェ
分析Re：データ漏えい私の2セント：
時系列データがある場合、多くの補間を行わない限り、項目2がより大きな問題であると思う傾向があります。データ内のノイズの原因を検討します。これらのいずれかが複数の行で発生する場合、または行が前後の行に何らかの形でリンクされている場合（タンクが到達するまでに1行以上かかる場合、時間の経過とともにタンクレベルを監視します）たとえば、新しい定常状態）の場合、データを行ごとに分割して、検証セットまたはテストセットがトレーニングから独立していると期待することはできません。
代わりに、データをより大きなチャンクでテストと検証に分割することを検討できます。次に例を示します。
- プロセスが「重要な」変更を行う新しい期間を特定し、定常状態の実行期間を同じグループで維持する（より困難ですがより良い）、または
- 異なる実行条件を表すと確信できるほど長い期間を使用しますが、複数の実行条件で構成されないように十分に短い期間を使用し、その期間のすべての行を同じ検証グループに保持します（より簡単で、同じリスクにさらされる可能性があります） ）
- 上記で特定された期間を使用して、おそらく変数の平均または標準偏差、または他の機能データエクスプローラーを使用して、これらの各実行を1つの行に要約します。 （ベスト）
いずれの場合も、グループ間の移行期間を除外することを検討してください。
私の個人的な経験：これらの方法の少なくとも1つを使い始めて以来、検証とテストのグループ統計は、モデルの予測力に対するはるかに合理的な期待を表しています。
Re：データ漏えいこれが私の限られた経験です。
モデリングは非常に複雑です（正しいモデルの選択、データの準備、データの分割、メタデータの調整など）。
優れたロボストモデルは、分割、メタデータ、モデルタイプから独立しています...
トレーニングとテストセットの両方がプロセスを代表する必要がありますが、テストセットはそれほど包括的である必要はありません。 結果を判断するには、トレーニング/テストが必要です。 @ihすでに述べました。
分割の場合、stratifyオプションを使用して分割を制御できます。 しかし、モデリングと分割の両方について、プロセスがそれを最もよく行う方法を知っている必要があります。
複雑なモデルの場合、および結果が重要な場合は、さまざまなモデル、さまざまなメタデータ、およびさまざまな検証列をテストしようとしました。 大きな違いがなければ問題ありません。 そして、これはJMP（Pro）で非常に簡単に実行できます。
最後に、漏れがないかどうか、このテストだけが答えを与えます。 でも正直なところ、良いモデルが確実に手に入るときは、漏れは気になりません。
Re：データ漏えい漏れと過剰適合という2つのことを混同しているのではないかと思います。かなり違うと思います。過剰適合は常に予測モデリングの潜在的な問題であり、それを防ぐ通常の方法は検証を行うことです。十分なデータがある場合は、別のテストデータセットも使用します。私の経験から、他の多くの調整パラメーターもそれを防ぐのに役立つので、過剰適合はそうでない場合よりもJMPの問題ではありません。たとえば、決定木では、最小分割サイズを比較的高く設定すると、過剰適合を回避するのに役立ちます。それでも、モデルが新しいデータに対して現実的な予測を生成できるかどうかを評価するために、個別のテストデータを用意することをお勧めします。これは時系列データにとって特に重要だと思います。
私の見解では、漏れはまったく別の問題です。漏れは誤って指定されたモデルです。予測しようとしているものと同時にしかわからない要因を使用しています。たとえば、顧客維持を予測しようとしていて、その要因の1つが今年の購入である場合、保持されている顧客のデータしかなく、保持していない顧客のデータは失われます。その場合、今年の購入の要因は顧客維持を完全に予測しますが、それは有用なモデルではありません。それが漏れだと私は信じています。
トレーニング/検証/テストのデータセットを変えても、リークが防止または検出されるとは思いません。これらの3つのいずれかでリークを検出できます。トレーニングデータの完全なモデル（またはほぼそう）は、リークがある可能性があると疑うのに十分です。漏れを防ぐ最善の方法は、要因を慎重に検討し、それらをいつどのように測定するかを理解することだと思います。モデルが良すぎて真実ではないように見える場合は、リークが原因である可能性があります（または、非常に優れたモデルである可能性があります）。しかし、それは技術的な装置によって答えられる質問ではないと思います。
私は他の人がこれについて何を言わなければならないか聞いて興味があります。
Re：データ漏えい親愛な@dale_lehman 、はい、その通りです。全体的な目標について考えたように、少なくとも正式には、優れた堅牢なモデルを作成するために、それを混ぜ合わせました。 リークの回避は、テストセットのデータをまだ確認していないことを目的として定義されています。 私はここでいくつかの追加の説明を見つけました：
機械学習におけるデータ漏洩。 減少する問題を防ぐ方法…|デヴィン・ソニ:crown:|データサイエンスに向けて
しかし、通常、トレーニングセットとテストセットをランダムに分割する場合、これを意図的に行うにはどうすればよいでしょうか。 プロセスモデルのカテゴリでは、トレーニングとテストセットの両方が同じプロセスからのものだと思います。 予測を考えるとき、それは異なるかもしれません。
Re：データ漏えいあなたがリンクしている記事は、データ漏洩について非常に混乱しています。これは、トレーニングと検証/テストデータ（過剰適合）のパフォーマンスの違いという考えと、トレーニングデータとテストデータ（リークを考える1つの方法）の間に明確な境界がないことを混同しています。2つの概念は異なると私は信じています。モデルがテストデータではなくトレーニングデータに適合する場合、それは過剰適合の例です。漏れはそれを説明しません-実際、漏れがある場合、それはトレーニングデータにも表示されます。さらに、テストデータがランダムに選択された場合、トレーニングデータがテストデータにあるときはいつでも、トレーニングデータでリークが発生するはずです（またはその逆）。これは、応答を予測するために使用されているが、予測が行われているときに知ることができなかった有益な機能がデータに含まれていることに起因します。
テストデータはデータセット全体のランダムな選択ではないため、時系列データでは状況が少しわかりにくくなります（ランダムな時間である可能性があります）限目）。ほとんどの時系列モデルは、過去のデータを使用して将来を予測します。リークは、後のデータを使用して前のデータを予測した場合に発生します。過剰適合とは、期間を使用して、モデルの構築に使用される期間のサブセットを予測することです。つまり、期間を分離しないでください。時系列モデルで過剰適合と漏れが回避されたとしても、モデルの構築に使用された期間は、予測しようとしている期間と十分に類似していると想定されます。期間が類似していない場合（たとえば、力が変化してモデルが関連しなくなった場合）、モデルはあまり良くないと思いますが、その漏れとは呼ばず、おそらく過剰適合とも呼ばないでしょう。
Re：データ漏えいこんにちは@ FR60 、
あなたが提起する特定のポイントについての私の考え：
1.データを標準化および/または正規化する場合は、データセットを分割する前に行うのが最善だと思います。 欠測値の代入については、注意が必要です。 欠落しているデータが有益な場合とそうでない場合があります。 また、JMPが値を代入する方法は、特定のデータに適していない場合があります。 欠落しているデータを誤って代入し、モデルに誤って影響を与える人工的な動作をデータに導入する可能性があります。
2.時系列について、実際に時系列を使用して将来のイベントを時間内に予測および予測している場合、データセットを分割することはないと思います。少なくともJMPの時系列プラットフォームではそうではありません。 、これらのプラットフォームには検証列がありません。 ただし、さまざまな予測モデルを比較して、将来の未使用のデータに最適なモデルを確認するための独立したデータセットが必要な場合は、はい、ある時点でデータセットを分割し、それを使用して予測モデルを生成して保存します。これらの式をデータテーブルに追加して、未使用のデータをどれだけ適切に予測できるかを確認します。 単純なFitY byXを使用してR ^ 2値を調べ、どのモデルが結果を最もよく予測するかを確認したり、実際のデータとモデル化されたデータ間の残差を調べて、残差の合計が最小かどうかを確認したりできます。 。
ただし、一般的に、私が行うことは、データテーブル80/20をトレーニングデータセットとテストデータセットに分割することです。 次に、テストデータを完全に異なるデータテーブルに分離して、作成したモデルがテストデータを使用する機会がないようにします。 これは単にデータを「非表示」および「除外」するだけではなく、アルゴリズムが誤ってテストデータを使用する可能性を排除します。 次に、「トレーニング」セットデータテーブルを使用して、検証列を作成するか、プラットフォームの検証部分オプションを使用して、過剰適合を減らすために、80/20をトレーニング/検証に分割します。 異なるプラットフォームで複数の異なるモデルを生成した後、テストデータセットを使用して、未使用/見えないデータを最もよく予測するモデルを確認します。
お役に立てれば、
DS
Re：データ漏えいKaggleでのこのチュートリアルは非常に興味深いものでした。
トレーニングとテストセットでデータを分割する前に、欠測値の正規化と代入をデータに適用しないようにすることを再度強調します。
https://www.kaggle.com/alexisbcook/data-leakage
チャオフェリーチェ
