相互検証は検証セットの適切な代替物ですか？

テキスト分類では、約800サンプルのトレーニングセットと約150サンプルのテストセットがあります。テストセットは使用されたことがなく、最後まで使用されるのを待っています。

私は800のサンプルトレーニングセット全体を使用し、分類器と機能を調整および微調整しながら10倍の相互検証を行います。つまり、個別の検証セットはありませんが、10倍に達するたびに検証セットが自動的に選択されます。

すべてに満足し、評価の最終段階に入りたいと思ったら、800サンプル全体で分類器をトレーニングします。150サンプルのテストセットでテストします。

テキスト分類でのクロス検証のそのような使用法を理解していますか？このプラクティスは有効ですか？

クロス検証に関するもう1つの質問は次のとおりです。

10倍ではなく、パフォーマンスの一般的な指標として1つを省いてみました。除外する場合、f1 / precision / recallに関する情報を取得することはできないため、leave-one-outの精度と10倍のメトリクスの関係はどうなっているのでしょうか？

どんな洞察も大歓迎です。

編集：

これは、相互検証の非常に良い紹介です。また、他の研究論文も参照しています。

あなたは確かに、相互検証を扱う方法を正しく説明しました。実際、モデルを最適化するためにクロス検証が使用されることが多いため、最後に妥当な検証を設定することは「幸運」ですが、「実際の」検証は行われません。

@Simon Stellingがコメントで述べたように、クロスバリデーションは推定エラーの低減につながります（常にデータを再利用しているので理にかなっています）が、幸いなことにこれはすべてのモデルに当てはまります。 「悪い」モデルの場合はわずかに、「良い」モデルの場合はより多く）、交差検証された基準で最高のパフォーマンスを発揮するモデルを選択することも、通常、「実際の」最高のモデルになります。

特に準モデルを探している場合は、低い誤差をいくらか修正するために時々使用される方法は、交差検証誤差が（交差検証）最適値から1 SD以内にある最小のモデル/最も簡単な方法を選択することです。クロスバリデーション自体として、これはヒューリスティックであるため、注意して使用する必要があります（これがオプションの場合：チューニングパラメーターに対してエラーのプロットを作成します。これにより、許容できる結果があるかどうかがわかります）。

エラーの下方バイアスを考えると、クロスバリデーションからのエラーやその他のパフォーマンス測定値を公開しないことが重要です。これらはクロスバリデーションによるものであることに言及せずに（ただし、真実は言われています：性能指標は---そう言及クロスバリデーションは、実際にあなたの結果の価値を作るのいずれかの元のデータセットのパフォーマンスをチェックするから入手したより）。検証セットがあるため、これは問題になりません。

最後の警告：モデルのフィッティングにより近い競合他社が発生する場合は、後で検証セットでパフォーマンスを確認することをお勧めしますが、最終的なモデル選択はそれに基づいて行わないでください：良心ですが、検証セットを見る前に「最終」モデルが選択されている必要があります。

2番目の質問について：コメントで必要なすべての答えをサイモンが与えたと思いますが、全体像を説明するために、バイアスと分散のトレードオフが重要です。平均して、正しい結果（偏りのない状態）に達することがわかっている場合、通常、価格は個々の計算のそれぞれがそれからかなり離れている可能性があります（高分散）。昔は、公平性はnecとultraでしたが、現在では、（小さな）バイアスを受け入れている場合があります（したがって、計算の平均が正しい結果になることすらわかりません）分散が低くなります。10倍の交差検証でバランスが許容できることが経験により示されています。あなたにとって、バイアスはモデルの最適化の問題にすぎません。検証セットで後で（不偏に）基準を推定できるためです。そのため、相互検証を使用しない理由はほとんどありません。