相互検証はデータスヌーピングとどのように違いますか?


13

「統計学習入門」を終えました。クロス検証を使用して、さまざまな機械学習手法に最適なチューニングパラメーターを見つけることは、データスヌーピングと異なるのではないかと考えました。

チューニングパラメーターのどの値がテストセットで最良の予測結果をもたらすかを繰り返しチェックしています。到達したチューニングパラメーターが偶然この特定のテストセットに適合し、将来のテストセットでうまく機能しない場合はどうでしょうか。

機械学習の初心者の理解を許してください。私は教育を受けたいと思っています。

編集:「データスヌーピング」の定義に関する@AdamOの回答をご覧ください。私は質問でこの用語を非常に不正確に使用しました。


これを見つけてとてもうれしいです...明日何かを発表した研究者とTCを持ちます...残念ながら、この問題に苦しんでいます。いい質問です!
パールヴィルゼン

回答:


12

クロス検証を使用して、さまざまな機械学習手法に最適なチューニングパラメーターを見つけることは、データスヌーピングと異なるのではないかと考えました。

あなたの懸念はまさにその上にあり、このトピックに関する多くの文献があります。例えば

問題は、相互検証を使用したハイパーパラメーターチューニングがデータ駆動型の最適化プロセスであり、yorデータセットに過剰適合する傾向があることです(再置換エラーによるチューニングよりも少ないですが)。チューニングの相互検証結果を「独立した」パフォーマンス測定値として使用しようとすることは、パイを食べ(=チューニング)、維持する(=最終モデルのパフォーマンスを測定する)ような方法です。

これは、ハイパーパラメーターの調整に相互検証を使用すべきではないという意味ではありません。これは、1つの目的にのみ使用できることを意味します。検証目的でモデルのパフォーマンスを最適化または測定します。

解決策は、調整されたハイパーパラメーターで取得したモデルの品質を測定するために、独立した検証を行う必要があるということです。これは、ネスト検証または二重検証と呼ばれます。これらのトピックに関する多くの質問と回答がここにあります。

概念的には、トレーニングには、「通常の」モデルパラメーターだけでなく、ハイパーパラメーターを合わせる(自動調整する)ためのあらゆる種類の手の込んだ手順が含まれていると言いたいです。したがって、λのデータ駆動型最適化は明らかにモデルトレーニングの一部です。

経験則として、モデルトレーニングは、新しいケースの予測を生成できる、すぐに使用できる最終的なブラックボックス関数を使用する前に実行する必要があるすべてと言うこともできます。


PS:私の分野では「検証」とは、最終モデルが目的に合っていることを証明することを意味するため、テスト用語と検証用語は非常にわかりにくいと思います。私は、内側のテストセットを「チューニングテストセット」、外側の「最終検証テストセット」などを呼び出すことを好みます。


更新:

私のモデル(つまり、この場合の調整パラメーター)が外側の検証に失敗した場合、どうすればよいですか?

通常、これはただ起こることではありません。そのような失敗を引き起こす可能性のある典型的な状況があります。そして、私が知っているこのような状況はすべて、過剰な状況です。正則化はトレーニングケースの必要数を減らすのに役立ちますが、データ駆動型の最適化には大量のデータが必要であることを認識する必要があります。

私の推奨事項:

  • 通常、どのようなパフォーマンスを達成できるか、疑わしいほど見栄えが良いと思うパフォーマンスなど、大まかな期待は既にあるはずです。または、達成する必要があるパフォーマンスとベースラインパフォーマンスを指定します。それと、利用可能なトレーニングケースの数(決定した分割スキームの場合)から、内部(調整)テストの予想される不確実性を計算します。その不確実性が意味のある比較を取得できないことを示している場合は、データ駆動型の最適化を行わないでください。

  • 選択したλで得られた予測と、自動調整手順で見つかった最適なλの両方の安定性を確認する必要があります。λがデータのさまざまな分割に関して合理的に安定していない場合、最適化は機能しませんでした。

  • データ駆動型の最適化を行うことができないか、結局は機能しないことがわかった場合は、同様のデータの経験など、専門知識によってλを選択できます。または、最適化が失敗したことがわかった場合、より強力な正則化が必要になるという知識により、失敗につながる過適合は複雑すぎるモデルに対して機能します。


1
私は専門用語電車/テスト/検証は非常に直感的ではありません、同意する
M.バーク

3

k

λλ

「データスヌーピング」または、私がそれを呼ぶことができるように、「探索的データ分析」は、事前に指定された質問に対処しません。可能性があり、もっともらしい結果をいくつか列挙し、それらを個別に評価します。探索的分析はいくつでも実行でき、通常、複数のテストについて心配する必要はありません。相互検証を使用して各探索的分析を個別に評価できますが、複数の探索的分析がある場合、本質的に複数のテストを考慮しません。この設定の仮説は、「前立腺がんに関連する要因はどれですか」という非常に広範囲かつ広範囲に及ぶ可能性があります。(コーヒーの飲酒、精管切除の使用法などがコホートで測定されたもの)。重要な結果は「仮説生成」とみなされており、確証的な証拠はありません。

k


λλ

1
@Anh:クロス検証によるλの調整自体は悪くありません。しかし、そうすると、λの調整のためにそのクロス検証を「使い果たし」、λの調整プロセスを含むモデリングから独立した別の検証が必要になります。この外部検証を行わないのは悪いことです。その特定のλが「再び」機能しない場合(たとえば、データの別の分割で)、最適化は機能しませんでした。そのような状況では、通常、外側の検証結果と、チューニング中に観測される「最高の」パフォーマンスとの間に大きな違いがあります。
cbeleitesはモニカをサポートします14

@cbeleitesでは、モデル(この場合はチューニングパラメーター)が外部検証に失敗した場合、どうすればよいですか?本質的には外側の検証がチューニングテストセットに変わるため、別のチューニングパラメーターを見つけることはできません。じゃあ何をすればいいの?
ハイゼンベルク14

λ

λk倍検証を選択された特徴の数を評価します(特徴の数がから20に変化する場合、特異性の証拠は低くなります)トレーニングモデルの3つの機能)。実際の調整パラメーターは、尤度と同様に、非常にデータ固有の意味を持ちます。私はそれを決して報告しませんが、それを変えることの結果として結果の感度に焦点を合わせます。
AdamO 14

1

実際、CV中に、検証セットでテストセットとは異なる最適なパラメーターを見つけようとします。データ全体を3つのセット(トレーニングセット、検証セット、テストセット)に分割します。適切に相互検証を行うと、最後までテストの終わりを見ることはないので、スヌーピングはまったくありません。テストセットで相互検証を行うことは、重大な(まだ頻繁な)方法論的エラーです。


検証セットとテストセットが異なる場合、それは私にとって理にかなっています。しかし、私が読んだ本(Hastie et al。も同様)では、彼らは、ホールドアウトテストの使用は費用がかかる(トレーニングに大量のデータを使用していない)と主張しているため、k倍交差検証を推奨しています。別のテストセットがあるとは思わない。
ハイゼンベルク14

1
@Anh:両方の分割は、1つの小さなデータセットのみを確保する代わりに、リサンプリング(例:相互検証の繰り返し)によって実行できます。
cbeleitesはモニカをサポートします14

@Anh:k分割交差検証では、元のトレーニングセットのk倍を小さなトレーニングセットと検証セットに分割します。元のテストセットは関与せず、最後にのみ使用されます。
ジェロックス14

0

たとえば、「なげなわの例」の「統計学習の概要」の225ページを見ると、ネストされた交差検証が実際に行われていることがわかります。モデル選択がで行われ、IE cv.glmnettrainによって分割されセット、cv.glmnet列車の試験のペアにパッケージ。モデル検証は検証( " test")セットで実行されるため、独立した検証です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.