ネストされたクロス検証に関する次の投稿を読んでいますが、ネストされたクロス検証を使用したモデル選択で何をすべきかはまだ100％わかりません。

• モデル選択のためのネストされたクロス検証
• モデルの選択と相互検証：正しい方法

混乱を説明するために、ネストされた相互検証方法を使用して、モデルの選択をステップごとに見てみましょう。

1. K-Foldを使用して外側のCVループを作成します。これは、各内部CVループを「獲得」したハイパーパラメーターのパフォーマンスを推定するために使用されます。
2. GridSearchCVを使用して、内部CVループを作成します。各内部ループでは、GSCVがパラメータースペースのすべての可能な組み合わせを調べて、最適なパラメーターセットを見つけます。
3. GSCVは、内側のループで最適なパラメーターを見つけた後、外側のループでテストセットを使用してテストし、パフォーマンスを推定します。
4. 次に、外側のループがテストセットとして次のフォールドに更新され、残りがトレーニングセットとして更新され、1〜3回繰り返されます。可能な「勝ち」パラメータの合計は、外側のループで指定されたフォールドの数です。外側のループは5倍であれば、あなたはとアルゴリズムの性能予測しています5つの異なるセットハイパーパラメータの、NOTハイパーパラメータの一つの特定のセットのパフォーマンスを。

このアプローチは、SKLearnのサンプルページに示されています：http ://scikit-learn.org/stable/auto_examples/model_selection/plot_nested_cross_validation_iris.html

質問：4.の 後、どのハイパーパラメーターが最適に機能したかをどのように判断しますか？最後にCOMPLETEデータセットを使用してアルゴリズム（ロジスティック回帰、ランダムフォレストなど）をトレーニングする必要があることを理解しています。しかし、ネストされたクロス検証でどのハイパーパラメーターが最適に機能したかをどのように判断しますか？私の理解では、各内部ループに対して、異なるハイパーパラメーターのセットが勝つということです。また、外側のループについては、GridSearchCVのパフォーマンスの推定値を取得していますが、ハイパーパラメーターの特定のセットは取得していません。それでは、最終的なモデル作成で、どのハイパーパラメーターを使用するかをどのように知るのでしょうか？それは、他のトレッドから理解するのに苦労している欠落しているロジックです。

特に@Dikran Marsupialと@cbeleitesが鳴り響く場合は、ヒントを事前にありがとうございます！

編集：可能であれば、答えには「アルゴリズム」や「ハイパーパラメーター」などの用語を使用してください。私にとって混乱の原因の1つは、人々が「モデル」または「モデル選択」という用語を使用していることだと思います。使用するアルゴリズムの選択について、または使用するハイパーパラメーターの選択について話しているのかどうか、私は混乱します。

編集2：ネストされた相互検証を行う2つの方法を示すノートブックを作成しました。最初の方法はSKLearnの例で示したもので、もう1つの方法は私が書いたものです。SKLearnに示されている方法は、「勝つ」ハイパーパラメーターを公開していませんが、私の長い方法は公開しています。しかし、問題は同じままです。ハイパーパラメーターが公開されている場合でも、ネストされたクロス検証を完了した後、どうすればよいですか？ノートブックの最後にあるハイパーパラメーターからわかるように、それらはかなり異なります。

（この答えのほとんどはすでにいくつかの答えで書いていると思いますが、今は見つけられません。誰かがその答えに出くわした場合は、リンクしてください）。ここでは、2つの異なるアプローチがありますが、どちらも賢明だと思います。

しかし、最初のいくつかの用語：

• 適用されたフィールドから来て、私にとって（適合/訓練された）モデルはすぐに使用できます。つまり、モデルには、新しいデータの予測を生成するために必要なすべての情報が含まれています。したがって、モデルにはhyperparametersも含まれます。ご覧のとおり、この観点は、以下のアプローチ2と密接に関連しています。
• OTOH、私の経験でのトレーニングアルゴリズムは次の意味で十分に定義されていません。ただし、ハイパーパラメーターも修正する必要があります。私のアプリケーションの観点からは、パラメーターとハイパーパラメーターの間に実際には大きな違いはありません。どちらもモデルの一部であり、トレーニング中に推定/決定する必要があります。
  これらの違いは、通常、トレーニングアルゴリズムのクラスをステアリングパラメーター（ハイパーパラメーター）アプリケーション/ドメインの知識がなくても、修正するのが難しい/不可能（または、少なくともそれらの決定/推定方法を修正するのが難しい）。

アプローチ1：安定した最適化結果が必要

このアプローチでは、「モデルトレーニング」は「通常の」モデルパラメーターの適合であり、ハイパーパラメーターが与えられます。内部のクロス検証などがハイパーパラメーターの最適化を処理します。

ハイパーパラメーターセットを選択する必要があるジレンマを解決するための重要なステップ/仮定は、最適化が安定していることを要求することです。検証目的の相互検証では、すべての代理モデルが最終モデル（データセット全体に適用された同じトレーニングアルゴリズムによって得られた）に十分に類似していることを前提として、それら自体を（最終モデルと同様に）同等に処理できるようにします。この仮定が崩れ、

1. サロゲートモデルは依然として最終モデルと同等（または同等）ですが、最終的なモデルとは異なります。クロス検証の悲観的なバイアスについてはよく知られています。

2. また、サロゲートモデルが互いに等しくない/等しい場合、不安定性に問題があります。

内側のループの最適化の結果では、最適化が安定していれば、ハイパーパラメーターの選択に競合はありません。また、内部クロス検証の結果でかなりの変動が見られる場合、最適化は安定していません。不安定なトレーニング状況には、どのハイパーパラメーターセットを選択するかを決定することよりもはるかに悪い問題があります。

ただし、ここには例外があります。最適化には、実際の目的で同等のパフォーマンスをもたらすいくつかの極小値がある場合があります。また、安定性を確保するための選択を必要とすることは、不必要な強力な要件かもしれませんが、このジレンマから抜け出す方法はわかりません。

すべてのモデルが同じ勝利パラメーターセットを生成しない場合は、ここで一般化エラーとして外部ループ推定を使用しないでください。

• $p$
  
• しかし、すべてのスプリットが同じパラメーターを生成したため、決定が含まれていない限り、これは外側のループの独立性を破ります：各スプリットのテストデータは、他のすべてのスプリットのトレーニングデータであるため、どのパラメーターセットが勝つかの決定をすでに入力しているため、使用されますパラメータを最適化します。

アプローチ2：ハイパーパラメーターチューニングをモデルトレーニングの一部として扱う

このアプローチは、「トレーニングアルゴリズム開発者」とトレーニングアルゴリズムの応用ユーザーの視点を橋渡しします。

トレーニングアルゴリズム開発者は、「裸の」トレーニングアルゴリズムを提供しますmodel = train_naked (trainingdata, hyperparameters)。適用されるユーザーのニーズに応じ tunedmodel = train_tuned (trainingdata)て、ハイパーパラメーターの修正も行います。

train_tunedたとえば、クロス検証ベースのオプティマイザーをネイキッドトレーニングアルゴリズムにラップすることで実装できますtrain_naked。

train_tunedその後、ハイパーパラメータ入力を必要としない他のトレーニングアルゴリズムと同様に使用できます。たとえば、その出力tunedmodelを相互検証することができます。これで、クロス検証の評価の一部として「通常の」パラメーターの安定性をチェックする必要があるのと同様に、ハイパーパラメーターの安定性がチェックされます。

これは、実際には、個々のパラメーターセットに関係なく、すべての受賞モデルのパフォーマンスを平均化する場合に、ネストされたクロス検証で実行および評価することです。

違いは何ですか？

最終的に、これらの2つのアプローチをとるさまざまな最終モデルになります。

• アプローチ1の最終モデルは train_naked (all data, hyperparameters from optimization)
• 一方、アプローチ2は次を使用しますtrain_tuned (all data)。-より大きなデータセットでハイパーパラメーターの最適化を再度実行するため、ハイパーパラメーターの別のセットで終わる可能性があります。

ただし、ここでも同じロジックが適用されます。最終モデルのパラメーターが相互検証サロゲートモデルとは大幅に異なることがわかった場合、それは仮定1に違反しているという症状です。私見では、ここでも競合はありませんが、（暗黙の）仮定が正当化されるかどうかのチェックがあります。そうでない場合は、とにかくその最終モデルのパフォーマンスを適切に推定することにあまり賭けるべきではありません。

多くの人がアプローチ1を行うネストされたクロス検証について考える印象もあります（CVで同様の質問/混乱の数を見てください）。しかし、一般化エラーは通常アプローチ2に従って推定されるので、最終モデルも同様です。

アイリスの例

要約：最適化は基本的に無意味です。使用可能なサンプルサイズでは、ここでのパラメーターセットのパフォーマンスを区別できません。

しかし、アプリケーションの観点から見ると、4つのパラメーターセットのどれを選択するかは問題ではありません。これはそれほど悪いニュースではありません。比較的安定したパラメーターのプラトーが見つかりました。チューニングされたモデルの適切なネストされた検証の利点があります。それが最適なモデルであると主張することはできませんが、アプローチ2を使用してデータ全体に基づいて構築されたモデルは約97％の精度（150のテストケースのうち145の正解に対する95％の信頼区間：92-99％）

アプローチ1も見た目ほど遠くないことに注意してください-以下を参照してください：結びつきのために最適化が比較的明確な「勝者」を誤って見逃しました（これは実際にサンプルサイズの問題の別の非常に明白な症状です）。

ここでは、C = 1が適切な選択であることを「見る」ほどSVMに深くは入っていませんが、より制限的な線形カーネルを使用します。また、最適化を行ったように、すべてのパラメーターセットが実質的に同等のパフォーマンスにつながることを認識していても、勝者のパラメーターセットを選択しても問題はありません。

ただし、将来的には、経験から期待できるパフォーマンスの大まかな推測値が得られるかどうか、おおよそどのモデルが良い選択になるかを検討してください。次に、そのモデルを（手動で固定されたハイパーパラメーターを使用して）構築し、そのパフォーマンスの信頼区間を計算します。これを使用して、最適化を試みることが賢明かどうかを判断します。（私は主に、10個の独立したケースを取得するのが簡単ではないデータで作業している-あなたが大きな独立したサンプルサイズのフィールドにいる場合、物事ははるかに良く見えると付け加えるかもしれません）

ロングバージョン：

例については、irisデータセットでの結果。iris150のケースがあり、2 x 2パラメーターのグリッド（2カーネル、ペナルティーの2桁）を持つSVM Cが考慮されます。

内側のループには、129（2x）と132（6x）のケースが分割されています。「最良の」パラメータセットは、C = 1の場合、線形カーネルとrbfカーネルの間で未決定です。ただし、内部テストの精度はすべて（常に失われるC = 10を含む）、観測精度94〜98.5％以内です。分割の1つにある最大の違いは、C = 1対10のrbfの3対8エラーです。

これが重要な違いになる方法はありません。CVの個々のケースの予測を抽出する方法はわかりませんが、3つのエラーが共有され、C = 10モデルでさらに5つのエラーが発生したと仮定しても：

> table (rbf1, rbf10)
         rbf10
rbf1      correct wrong
  correct     124     5
  wrong         0     3

> mcnemar.exact(rbf1, rbf10)

    Exact McNemar test (with central confidence intervals)

data:  rbf1 and rbf10
b = 5, c = 0, p-value = 0.0625
alternative hypothesis: true odds ratio is not equal to 1

2 x 2グリッドには6つのペアワイズ比較があるため、複数の比較についても修正する必要があることに注意してください。

アプローチ1

rbfが線形カーネルで「勝った」4つの外部分割のうち3つでは、実際には同じ推定精度がありました（タイの場合、minは最初の適切なインデックスを返します）。

グリッドをparams = {'kernel':['linear', 'rbf'],'C':[1,10]} yieldに変更 する

({'kernel': 'linear', 'C': 1}, 0.95238095238095233, 0.97674418604651159)
({'kernel': 'rbf', 'C': 1}, 0.95238095238095233, 0.98449612403100772)
({'kernel': 'linear', 'C': 1}, 1.0, 0.97727272727272729)
({'kernel': 'linear', 'C': 1}, 0.94444444444444442, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 0.94444444444444442, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 1.0, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 1.0, 0.96212121212121215)

アプローチ2：

これclfが最終モデルです。でrandom_state = 2、C = 1のrbfが勝ちます：

In [310]: clf.grid_scores_
[...snip warning...]
Out[310]: 
[mean: 0.97333, std: 0.00897, params: {'kernel': 'linear', 'C': 1},
 mean: 0.98000, std: 0.02773, params: {'kernel': 'rbf', 'C': 1},
 mean: 0.96000, std: 0.03202, params: {'kernel': 'linear', 'C': 10},
 mean: 0.95333, std: 0.01791, params: {'kernel': 'rbf', 'C': 10}]

（5回に1回、6回に1回linear、rbfwith C = 1がランク1に結び付けられます）

上記の質問と回答を2回以上読みました（3回前の1回目）。私は興味があり、データの相互検証を行うための絶対的に適切な方法を見つけたいです。たくさんの考えと読書の後、私は穴を見つけたようで、ここに私の修正があります：

混乱を説明するために、ネストされた相互検証方法を使用して、モデルの選択をステップごとに見てみましょう。

1. K-Foldを使用して外側のCVループを作成します。これは、各内部CVループを「獲得」したハイパーパラメーターのパフォーマンスを推定するために使用されます。
2. GridSearchCVを使用して、内部CVループを作成します。各内部ループでは、GSCVがパラメータースペースのすべての可能な組み合わせを通過し、最適なパラメーターセットを見つけます。（注：ここでは、内側のループのデータ=外側のループのトレーニングデータを想定しています。あなたは尋ねることができます：なぜ？回答：https : //stackoverflow.com/questions/42228735/scikit-learn-gridsearchcv-with-multiple-repetitions/ 42230764＃42230764 Vivek Kumarのステップ4）で回答セクションを読んでください
3. GSCVは、内側のループで「最良のパラメーター」を見つけた後（内側の勝者と呼びます）、外側のループのテストセットでテストして、パフォーマンスの推定値を取得します（outer_fold_score1と呼びます）。
4. 次に、外側のループがテストセットとして次のフォールドに更新され、残りがトレーニングセットとして更新され（外側のループの「内側の勝者」を評価するため）、「内側の勝者」が新しいテストセット（outer_fold_score2）で再度テストされます。その後、ループが完了するまで、外側のループが次のフォールドに更新されます。各フォールド（outer_fold_score 1,2 ..）のスコアは平均で、外側のループ（outer_score）の「内側の勝者」のスコアを取得します
5. その後、外側のループはテストセットとして次のフォールドに更新され、残りはトレーニングセットとして（次の「内側の勝者」を見つけるために）、1〜4回繰り返されます（1を繰り返すとき、新しいK-折りますが、毎回同じ外側Kfoldを使用します。1〜4サイクルのそれぞれで、outer_scoreを持つ「最適なパラメーター」（または「内部勝者」）を取得します。勝者

推論：

• 基本的に、あなたの質問は、外側のループに多くの「勝つパラメーター」があることに関するものです。問題は、「外側の勝者」を評価して見つけるために外側のループを完了しなかったことです。4番目のステップでは、外側のループの1倍の「内側の勝者」のみを評価しますが、「ループ」しませんでした。したがって、これを4番目のステップで置き換える必要があります。外側のループで評価ステップを「ループ」し、外側のスコアを取得します（平均化により）
• 5番目のステップは外側のループで「ループ」ジョブを実行しましたが、それは別の「内側の勝者」を構築するためだけのものです。この「内側の勝者」の「評価」を外側のループでループしませんでした

ネストされた交差検証を使用してアルゴリズムのハイパーパラメーターを選択することはありません。この方法は、モデル構築手順の一般化誤差を推定するために使用されます。モデル構築手順により、私はあなたがフィールドで使用する最終モデルに到達するために適用したすべてのステップを意図しています。
モデル構築手順は、データに適用する前処理、使用する機能、使用するハイパーパラメーターを決定するために適用したルールで構成できます。これは、特定のデータセット入力として受け取りする一種の「メタアルゴリズム」と考えてください。$D$ 前処理変換、機能、最後にハイパーパラメーター値のセット。

$X , y$
$x$$X$$y$

$X', y'$$X, y$

使用する機能を選択するためのすべてのデータ。したがって、ステップ2で相互検証を行った場合でも、機能は、相互検証の実行ごとにテストフォールドに存在するいくつかの情報を既に見て覚えています。結果は、テストエラーの過度に楽観的な推定になり、これは機能選択バイアスと呼ばれます。見積もりでこれを考慮するには、ステップ2の相互検証ループ内に機能選択ステップを配置する必要があり
ます。ループ内の特徴選択ステップを使用した相互検証で見つかった最良のエラーは、一般化エラーの公正な推定ですか？
理論的には答えはまだありません、問題は、自由に特定のデータセットの相互検証エラーを最小化するためにハイパーパラメーターが選択されているため、特定の意味で、ハイパーパラメーターを過剰適合のリスクでデータに適合させていることです。モデル選択バイアスと呼ばれます。しかし、これは実際には懸念事項ですか？特定のアプリケーションに依存します。データセットが小さく、調整するハイパーパラメーターの数が比較的多い場合、トレーニングのオーバーフィットとしてより深刻になる可能性があります。汎化エラーを推定するときにこれを考慮するには、説明したようにネストされた相互検証を適用します。これにより、汎化エラーの正しい推定が得られます。
最後に、最後の質問に答えるために、ネストされた相互検証を使用して「モデル構築手順」一般化エラーを公正に推定した後、単に手順（ステップ1 + 2）をデータセット全体に適用して、固定セットのモデルを取得します機能の設定とハイパーパラメータ値を設定しますが、このモデルが表示されないデータに与えると予想されるエラーは、ネストされた相互検証の推定値であることに注意してください。