クロス検証を使用して、さまざまな機械学習手法に最適なチューニングパラメーターを見つけることは、データスヌーピングと異なるのではないかと考えました。
あなたの懸念はまさにその上にあり、このトピックに関する多くの文献があります。例えば
問題は、相互検証を使用したハイパーパラメーターチューニングがデータ駆動型の最適化プロセスであり、yorデータセットに過剰適合する傾向があることです(再置換エラーによるチューニングよりも少ないですが)。チューニングの相互検証結果を「独立した」パフォーマンス測定値として使用しようとすることは、パイを食べ(=チューニング)、維持する(=最終モデルのパフォーマンスを測定する)ような方法です。
これは、ハイパーパラメーターの調整に相互検証を使用すべきではないという意味ではありません。これは、1つの目的にのみ使用できることを意味します。検証目的でモデルのパフォーマンスを最適化または測定します。
解決策は、調整されたハイパーパラメーターで取得したモデルの品質を測定するために、独立した検証を行う必要があるということです。これは、ネスト検証または二重検証と呼ばれます。これらのトピックに関する多くの質問と回答がここにあります。
概念的には、トレーニングには、「通常の」モデルパラメーターだけでなく、ハイパーパラメーターを合わせる(自動調整する)ためのあらゆる種類の手の込んだ手順が含まれていると言いたいです。したがって、λのデータ駆動型最適化は明らかにモデルトレーニングの一部です。
経験則として、モデルトレーニングは、新しいケースの予測を生成できる、すぐに使用できる最終的なブラックボックス関数を使用する前に実行する必要があるすべてと言うこともできます。
PS:私の分野では「検証」とは、最終モデルが目的に合っていることを証明することを意味するため、テスト用語と検証用語は非常にわかりにくいと思います。私は、内側のテストセットを「チューニングテストセット」、外側の「最終検証テストセット」などを呼び出すことを好みます。
更新:
私のモデル(つまり、この場合の調整パラメーター)が外側の検証に失敗した場合、どうすればよいですか?
通常、これはただ起こることではありません。そのような失敗を引き起こす可能性のある典型的な状況があります。そして、私が知っているこのような状況はすべて、過剰な状況です。正則化はトレーニングケースの必要数を減らすのに役立ちますが、データ駆動型の最適化には大量のデータが必要であることを認識する必要があります。
私の推奨事項:
通常、どのようなパフォーマンスを達成できるか、疑わしいほど見栄えが良いと思うパフォーマンスなど、大まかな期待は既にあるはずです。または、達成する必要があるパフォーマンスとベースラインパフォーマンスを指定します。それと、利用可能なトレーニングケースの数(決定した分割スキームの場合)から、内部(調整)テストの予想される不確実性を計算します。その不確実性が意味のある比較を取得できないことを示している場合は、データ駆動型の最適化を行わないでください。
選択したλで得られた予測と、自動調整手順で見つかった最適なλの両方の安定性を確認する必要があります。λがデータのさまざまな分割に関して合理的に安定していない場合、最適化は機能しませんでした。
データ駆動型の最適化を行うことができないか、結局は機能しないことがわかった場合は、同様のデータの経験など、専門知識によってλを選択できます。または、最適化が失敗したことがわかった場合、より強力な正則化が必要になるという知識により、失敗につながる過適合は複雑すぎるモデルに対して機能します。