この[外部クロス検証]出力からモデルを選択するにはどうすればよいですか？
簡単な答え：そうではありません。
モデルの適合手順の一部として内部交差検証を扱います。つまり、ハイパーパラメーターのフィッティングを含むフィッティング（これは、内部クロス検証が非表示になる場所です）は、他のモデル推定ルーチンとまったく同じです。
外側のクロス検証では、このモデルフィッティングアプローチのパフォーマンスを推定します。そのためには、通常の仮定を使用します
- 外側のサロゲートモデルが構築されたことにより、「本物」のモデルと同等であり 、すべてのデータを持ちます。k
model.fitting.procedure
- または、ケース1.で故障した場合（リサンプリング検証の悲観的バイアス）、少なくとも外部代理モデルは互いに同等です。
これにより、テスト結果をプール（平均）できます。また、それらは基本的に同じであると想定しているため、それらの中から選択する必要がないことも意味します。この2番目の弱い仮定の内訳は、モデルの不安定性です。k
サロゲートモデルのうち、一見最適なものを選択しないでください。これは通常、テストの不確実性を「収穫」するだけで、楽観的なバイアスにつながります。k
モデルの選択にネストされたCVを使用するにはどうすればよいですか？
内側の CVは選択を行います。
各モデルはデータセットのさまざまな部分でトレーニングおよびテストされているため、これらのK個の勝利モデルから最良のモデルを選択することは公平な比較ではないように思えます。
サロゲートモデルの1つを選択するのは得策ではないという点で、あなたは正しいです。しかし、あなたはその理由について間違っています。本当の理由：上記を参照してください。これらが同じデータでトレーニングおよびテストされていないという事実は、ここでは「痛い」ことはありません。k
- 同じテストデータを持たない：後でテスト結果が見たことのないデータに一般化すると主張したいので、これは違いを生むことができません。
- 同じトレーニングデータがない：
- モデルが安定していても、違いはありません。ここで安定しているとは、いくつかのケースを他のケースに置き換えてトレーニングデータが「乱れ」ている場合、モデルが（ほとんど）変化しないことを意味します。
- モデルが安定していない場合、3つの考慮事項が重要です。
- 反復/反復 倍交差検証を使用することにより、実際にこれが当てはまるかどうか、またどの程度であるかを実際に測定できます。これにより、わずかに異なるトレーニングデータに基づいて構築された異なるモデルによって予測された同じケースのクロス検証結果を比較できます。k
- モデルが安定していない場合、倍交差検証のテスト結果で観測される分散が増加します。合計で有限数のケースのみがテストされるという事実による分散があるだけでなく、追加の分散があります。モデルの不安定性（予測能力の分散）のため。k
- 不安定性が実際の問題である場合、「実際の」モデルのパフォーマンスを適切に推定することはできません。
最後の質問にお答えします。
外側のKフォールドから取得したスコアを使用して、どのような種類の分析/チェックを実行できますか？
- 予測の安定性をチェックします（反復/反復交差検証を使用）
最適化されたハイパーパラメーターの安定性/変動を確認してください。
1つには、乱雑に分散するハイパーパラメーターが、内部最適化が機能しなかったことを示している可能性があります。別のこととして、これにより、将来同様の状況でコストのかかる最適化ステップなしでハイパーパラメーターを決定できる場合があります。コストがかかるので、計算リソースについては言及しませんが、この「コスト」情報は「通常の」モデルパラメーターを推定するために使用するほうがよいという事実を指します。
選択したモデルの内側と外側の推定値の違いを確認してください。大きな差がある場合（内部が非常に楽観的である場合）、過剰適合のために内部の最適化がうまく機能しなかったというリスクがあります。
@ user99889の質問を更新：外側のCVが不安定になった場合はどうすればよいですか？
まず、外側のCVループで、モデルがその点で安定した予測を生成しないことを検出することは、予測誤差がアプリケーションにとって高すぎることを検出することと実際には異なりません。これは、モデルの検証（または検証）の結果の1つであり、私たちが持っているモデルがその目的に適合していないことを意味しています。
@davipsに答えるコメントで、私は内部 CVの不安定性に取り組むことを考えていました-つまり、モデル最適化プロセスの一部として。
しかし、あなたは確かに正しいです。外側のCVの結果に基づいてモデルを変更する場合、変更されたモデルの独立したテストの別のラウンドが必要です。
ただし、外部CVの不安定性は、最適化が適切に設定されなかったことの兆候でもあります。したがって、外部CVの不安定性を見つけることは、内部CVが必要な方法で不安定性にペナルティを与えなかったことを意味します-これが私の主要なポイントですそのような状況での批判。言い換えれば、最適化によりモデルが過度にオーバーフィットすることを許可/導くのはなぜですか？
しかし、1つのクセは私見であることここにありて後に「最終」モデルのさらなる変化言い訳正確な状況を慎重に考慮し、我々は過剰適合を検出しなかったとして、モデルへの提案された変更を（少数のDF /より制限または凝集）になります。オーバーフィッティングの少ない方向（または、少なくともオーバーフィッティングの傾向が少ないハイパーパラメーター）であること。独立したテストのポイントは、過剰適合を検出することです-不足適合は、トレーニングプロセスで既に使用されたデータによって検出できます。
たとえば、PLSモデルの潜在変数の数をさらに減らすことについて話をしている場合（提案された変更がSVMではなくPLSなどのまったく異なるタイプのモデルである場合、すべてのベットはオフになります） ）、とにかくモデリングの中間段階にいることを知っていれば、それについてさらにリラックスできます-結局、最適化されたモデルがまだ不安定であれば、さらに多くのケースが必要であることは疑いありません。また、多くの状況では、パフォーマンスのさまざまな側面を適切にテストするために設計された研究を最終的に実行する必要があります（たとえば、将来取得したデータの一般化）。それでも、完全なモデリングプロセスを報告する必要があり、これらの最新の変更の影響を慎重に議論する必要があると主張します。
また、すでに利用可能な結果から、パフォーマンスのアウトオブバッグアナログCV推定を含む集計が可能になります。これは、ここで良性と考えたい他のタイプのモデルの「後処理」です。繰り返しになりますが、集計が個々の予測よりも有利でないことを確認するために、最初から調査を設計した方が良いでしょう（これは、個々のモデルが安定していると言う別の方法です）。
更新（2019）：これらの状況について考えれば考えるほど、「ネストなしのクロスネスト検証」のアプローチを好むようになります。