データ漏洩こんにちは
テスト グループとトレーニング グループ間のデータ漏洩に関する投稿をいくつか読みました。 漏れを避けるための一般的な提案:
1 正規化、標準化、欠損値の代入の前に、トレーニング セットとテスト セットでデータベースを分割します。
2 時系列の場合は、ランダムな分割を避けます。 タイムカットポイントを決定し、それを使用してトレーニングセットとテストセットを分離します。
コメント、提案、有益な読み物はありますか?
フェリーチェ
データのブレンディングとクリーンアップRe: データ漏洩こんにちは@FR60 、
残念ながら、JMP がすべてのプラットフォームまたはすべての状況でそれを行うかどうかは確認できません。
JMP のいくつかのモデリング プラットフォームでは、推定レポートを取得すると、多くの場合、スケーリングされた推定用のレポートが存在することは知っています。 これは、Fit Y by X プラットフォームでも確認できます。 ここで、直線、多項式、またはその他の関数をデータに当てはめると、JMP は当てはめ関数を中心とした式を返します。 したがって、近似が y=a*x+b*x^2 +c の場合、JMP が返す関数は実際には y=a*(x-x0)+b*(x-x1)^2+c になります。ここで、x0 x1 は定数です。 明示的にそうしないように指示しない限り、これが行われます。
データをセンタリングした場合、センタリングしない場合よりも a、b、c の推定値がより正確になるため、JMP がこのようにしていると理解しています。 JMP がすべてのプラットフォームでこれを行うとしても驚かないでしょうが、私にはわかりません。 DOE の生成時にすべてのデータがエンコードされるため、実際の値を入力した場合でも、プログラムのバックエンドでは、DOE の低、中、高の設定に -1、0、1 などのエンコードされた値が使用されます。 。 実際には、入力する可能性のある実際の数値は使用されません。
この件について完全な確認を得るには、JMP スタッフに直接手紙を書くか、あなたの分野をサポートするシステム エンジニアに相談します。 これがプラットフォームに依存するものなのか、それとも JMP を使用して全体的に行われるのかを知ることは良いことです。
ありがとう！、
DS
Re: データ漏洩こんにちはディードリッヒ
コメントありがとうございます。
トレーニング テストの漏洩について、いくつかのブログで報告されている提案は、データの前処理を行う前にデータを分割するというものです。 たとえば、すべての予測子を 0 と 1 の間で正規化したい場合は、データを分割する前にトレーニング データのみを使用して最小/最大を計算し、それらの値を使用して検証データとテスト データも正規化する必要があります。 Z 標準化や欠損値の代入など、他の同様のタイプのデータ管理についても同じです。 もちろん、相互検証を使用する場合は、上記で報告したのと同じ方法論に従って、より複雑な計算を実装する必要があります。
それでは、質問に移ります。 メールには次のように書きました。
」分割後にデータを標準化/正規化することが重要である理由がわかりました。それは理にかなっています。 私の理解では、JMP は通常、計算中にバックグラウンドでこれを実行し、レポート作成時に再スケールするだけであると理解しています。 」
これは、JMP アルゴリズムによって内部的に回避されるため、JMP を使用するとトレーニング テストのリークについて心配する必要がないことを意味します。
もしそうなら、これは私にとって素晴らしいことです。
確認していただけますか？
ありがとうフェリーチェ
Re: データ漏洩こんにちは@FR60 、
これに関して、どこで混乱が生じたのかがわかります。 Kaggle の記事を参照したときと同様に、あなたが言及している分割とリークには 2 種類あります。 @dale_lehmanこれについてもコメントしました。
1 つの分割は、モデルのトレーニングに使用されるデータに、結果でのみ知られるデータが含まれていないことを確認することです。 それがKaggleの言うところの「ターゲット漏洩」だろう。 もう 1 つは「トレーニングとテストの汚染」です。テスト データがトレーニング セットや検証セットに混入しないようにする必要があります。 2 番目のものは、私がより言及していたものです。通常、私のデータセットには、予測子変数の後に既知の列が含まれていないため、「ターゲットの漏れ」を心配することは一般的ではありませんが、「トレーニングテスト」は汚染」です。
JMP の場合、データ分割を行方向の分割 == "トレーニングテストの汚染" と列方向の分割 == "ターゲット リーク" として考えると簡単かもしれません。 データ構造に応じて、一方のみを実行することも、両方を実行することもできます。
分割後にデータを標準化/正規化することが重要である理由がわかりました。それは理にかなっています。 私の理解では、JMP は通常、計算中にこれをバックグラウンドで実行し、レポートを作成するときにそれを再スケールするだけです。
元の投稿に戻ると、データをどのように分割する必要があるか、そしてデータがどのように構造化されているか、つまり時間的に垂直に構造化されているか、水平的に構造化されているかによって異なると思います。 これにより、時間データを行方向または列方向のどちらで分割するかが決まる場合があります。 ただし、時系列をいつ切り取るかを決定する際にも、同様のロジックを適用します。 結果の結果が予測変数としてモデルに入力される可能性がある時点がある場合は、その前にカットする必要があります。 「列車試験の汚染」問題について、これを適切な方法で行う方法がわかりません。 予測や時系列分析を実行しようとしている場合、JMP は実際にそのためのすべてのデータを使用して非常にうまく機能します。 過去の時間データに基づいて将来を予測する期間を決定でき、出力には信頼区間などが含まれます。
良い議論を!、
DS
Re: データ漏洩データ前処理中のデータ漏洩に関する別の投稿。
https://machinelearningmastery.com/data-preparation-without-data-leakage/
Re: データ漏洩Kaggle のこのチュートリアルは非常に興味深いと思いました。
ここでも、データをトレーニング セットとテスト セットに分割する前に、欠損値の正規化や代入をデータに適用することを避けることが強調されています。
https://www.kaggle.com/alexisbcook/data-leakage
チャオフェリーチェ
Re: データ漏洩こんにちは@FR60 、
あなたが指摘した具体的な点についての私の考えは次のとおりです。
1. データを標準化または正規化する場合は、データセットを分割する前に行うのが最善だと思います。 欠損値の代入については注意が必要です。 欠損データが有益な場合もあれば、そうでない場合もあります。 また、JMP が値を代入する方法は、特定のデータには適切ではない可能性があります。 欠損データが誤って代入され、モデルに誤った影響を与える人為的な動作がデータに導入される可能性があります。
2. 時系列については、将来の出来事を時間内に予測し予測するために時系列を実際に使用している場合、データセットを分割することはないと思います。少なくとも JMP の時系列プラットフォームでは分割しないと思います。 、これらのプラットフォームには検証列がありません。 ただし、異なる予測モデルを比較して、将来の未使用データに最も適合するものを確認するための独立したデータ セットが必要な場合は、はい、ある時点でデータ セットを分割し、それを使用して予測モデルを生成し、保存します。これらの数式をデータ テーブルに追加し、未使用のデータがどの程度正確に予測されるかを確認します。 おそらく、単純な Y by X のフィットを使用して R^2 値を調べて、どのモデルが結果を最もよく予測するかを確認したり、実際のデータとモデル化されたデータの間の残差を調べて、どちらの残差の合計が最小であるかを確認したりすることもできます。 。
ただし、一般に、私が行うのは、データ テーブル 80/20 をトレーニング データ セットとテスト データ セットに分割することです。 次に、テスト データをまったく別のデータ テーブルに分離して、構築するモデルがテスト データを使用する機会をなくします。 これは単にデータを「非表示」にして「除外」するだけではなく、アルゴリズムがテスト データを誤って使用する可能性を排除します。 「トレーニング」セットのデータテーブルを使用して、検証列を作成するか、プラットフォームの検証部分オプションを使用して、過学習を減らすために再びトレーニング/検証に 80/20 に分割します。 さまざまなプラットフォームで複数の異なるモデルを生成した後、テスト データ セットを使用して、どのモデルが未使用/未表示のデータを最もよく予測するかを確認します。
お役に立てれば、
DS
Re: データ漏洩リンク先の記事は、データ漏洩に関して非常に混乱しています。これは、トレーニング データと検証/テスト データのパフォーマンスの差 (過学習) と、トレーニング データとテスト データの間の明確な境界の欠如 (漏れの考え方の 1 つ) を混同しています。この 2 つの概念は異なるものであると私は考えています。モデルがテスト データではなくトレーニング データに適合する場合、それは過剰適合の一例です。漏洩はこれを考慮しません。実際、漏洩があれば、それはトレーニング データにも現れます。さらに、テスト データがランダムに選択された場合、トレーニング データがテスト データ内に存在する場合は常に、トレーニング データ内で漏れが発生するはずです (逆も同様です)。これは、応答を予測するために使用されているデータ内に有益な特徴が含まれていることから生じますが、予測が行われているときにはそれを知ることができませんでした。
時系列データの場合は、テスト データがデータ セット全体からランダムに選択されたものではないため、状況が少し明確になりません (ランダムな時間である可能性があります)。期間）。ほとんどの時系列モデルは、将来を予測するために過去のデータを使用します。以前のデータを予測するために後のデータを使用すると、漏れが発生します。オーバーフィッティングでは、モデルの構築に使用された期間のサブセットを予測するために期間を使用します。つまり、期間を分離しておきません。時系列モデルで過剰適合と漏れが回避されたとしても、モデルの構築に使用された期間が予測しようとしている期間と十分に類似しているという前提があります。期間が類似していない場合 (たとえば、力が変化してモデルが適切でなくなった場合)、モデルはあまり良くないと言えますが、それを漏れとは呼びませんし、おそらく過学習とも呼びません。
Re: データ漏洩親愛なる@dale_lehmanはい、その通りです。優れた堅牢なモデルを作成するという全体的な目標について考えたので、少なくとも形式的には混合しました。 漏洩を避けることは目的として定義されており、テスト セット内のデータをすでに確認していることではありません。 ここで追加の説明を見つけました。
機械学習におけるデータ漏洩。 影響を減らす問題を防ぐ方法… |デビン・ソーニ著：クラウン： |データサイエンスに向けて
しかし、通常、トレーニング セットとテスト セットをランダムに分割する場合、これを意図的に行うにはどうすればよいでしょうか? 私は、プロセス モデル カテゴリでは、トレーニングとテスト セットの両方が同じプロセスに由来すると考えています。 予想を考えると違うかもしれません。
Re: データ漏洩リークとオーバーフィッティングという 2 つのことを混同しているのではないかと思います。かなり違うと思います。予測モデリングではオーバーフィッティングは常に潜在的な問題であり、これを防ぐ通常の方法は検証を行い、十分なデータがある場合は別のテスト データ セットも用意することです。私の経験から言えば、JMP を使用した場合は、他の多くの調整パラメータも過学習の防止に役立つため、過学習はそうでない場合に比べて問題になりません。たとえば、デシジョン ツリーの場合、比較的大きな最小分割サイズを設定すると、過剰適合を回避できます。それでも、モデルが新しいデータに対して現実的な予測を生成できるかどうかを評価するために、別のテスト データを用意することをお勧めします。これは時系列データでは特に重要だと思います。
私の考えでは、漏洩は全く別の問題です。漏れは仕様ミスです。予測しようとしているものと同時にしか分からない要素を使用しています。たとえば、顧客維持率を予測しようとしていて、要因の 1 つが今年の購入である場合、維持された顧客のデータのみが存在し、維持されなかった顧客のデータは欠落します。その場合、今年の購入要因によって顧客維持率が完全に予測されますが、これは有用なモデルではありません。それが漏洩であると私は信じています。
異なるトレーニング/検証/テストデータセットを使用することで漏洩が防止または検出されるとは思いません。これら 3 つのいずれかで漏洩を検出できる可能性があります。トレーニング データに完全なモデル (またはそれに近いモデル) があれば、漏洩の可能性を疑うのに十分です。漏れを防ぐ最善の方法は、要因を注意深く検討し、いつどのように測定されるかを理解することだと思います。モデルが真実であるとは思えないほど優れているように見える場合は、漏れが原因である可能性があります (または、モデルが非常に優れているだけである可能性があります)。しかし、それはいかなる技術的な手段によっても答えられる質問ではないと思います。
これについて他の人が何と言っているかを聞くことに興味があります。
Re: データ漏洩これが私の限られた経験です。
モデリングは非常に複雑です (適切なモデルの選択、データの準備、データの分割、メタデータの調整など)。
優れたロボットモデルは、分割、メタデータ、モデルタイプなどから独立しています。
トレーニング セットとテスト セットは両方ともプロセスを代表するものである必要がありますが、テスト セットはそれほど包括的である必要はありません。 結果を判断するにはトレーニング/テストが必要です。 @ihすでに述べた。
分割の場合、階層化オプションを使用して分割を制御できます。 ただし、モデリングと分割の両方について、最適な方法を知っているプロセスが必要です。
複雑なモデルの場合、結果が重要な場合は、さまざまなモデル、さまざまなメタデータ、さまざまな検証列をテストしようとしました。 大きな差異がない場合は問題ありません。 これは JMP (Pro) で非常に簡単に実行できます。
最終的にはこのテストだけで漏れがないかどうかがわかります。 しかし正直に言うと、確実に良いモデルを入手できるのであれば、漏れは気にしません。
Re: データ漏洩私の2セント:
時系列データがある場合、多くの内挿を行っていない限り、項目 2 がより大きな問題であると考える傾向があります。データ内のノイズの発生源が複数の行にわたって発生する場合、または行が前後の行に何らかの形でリンクされている場合 (タンクのレベルを長期間監視する場合、タンクがレベルに達するまでに 1 行以上かかる場合) を考慮してください。新しい定常状態など) の場合、データを行ごとに分割し、検証セットやテスト セットがトレーニングから独立していることを期待することはできません。
代わりに、データをより大きなチャンクでのテストと検証に分割することを検討することもできます。次に例を示します。
- プロセスが何らかの「重大な」変化を起こす新しい期間を特定し、定常状態の実行期間を同じグループ内に維持します (より困難ですがより良い)、または
- 期間は、異なる実行条件を表していると確信できる程度に長く使用しますが、複数の実行条件で構成されない程度に短くし、その期間内のすべての行を同じ検証グループに保持します (より簡単で、潜在的に同じリスクにさらされる可能性があります)。 )
- 上記で特定した期間を使用して、変数の平均や標準偏差、または他の関数データ エクスプローラーを使用して、これらの実行のそれぞれを 1 つの行に要約します。 （最高）
いずれの場合も、グループ間の移行期間を除外することを検討してください。
私の個人的な経験: これらの方法の少なくとも 1 つを使用し始めて以来、検証とテストのグループ統計は、モデルの予測能力に対するはるかに合理的な期待を表すようになりました。
