どうもこんにちは。
今日は私がわからなくて色々調べまわった、交差検証の目的についてまとめていきます。
交差検証（クロスバリデーション）は”検証”をする工程
交差検証とはモデルを作る工程ではありません。
交差検証で作成されたモデル・予測結果は使ってはいけません。
交差検証で一番精度が良かったモデル（n分割目のモデル）だけ取り出すなんて言語道断ですよ
では交差検証は何をするのでしょうか。
それでは、交差検証の目的を確認していきましょう。
注意：
交差検証の文脈で出てくる”モデル”とは、分割数分できる学習機のことではありません。
ここでいうモデルとは「とある設定をされたとあるモデル」が近い意味になります。
例えば同じLightGBMを用いていても、深さが4で作成されたものと深さが5で作成されたものはそれぞれ違うモデルと捉えます。
さらに、扱う説明変数が異なっていたりしてもそれらはまた違うモデルと捉えます。
つまり、「交差検証をする」とは「とある設定をされたとあるモデル」の性能を「交差検証を用いて検証すること」になります。
目的1. 作成したモデルの汎化性能を正しく評価する
モデルを作るたびにスコアがばらつく。そんなことありませんか？
モデルを作るときにはランダムスタートといってパラメタの学習開始の初期値がランダムに決められるため、結果がばらついてしまいます。
そんな一時的な評価を避けるために交差検証を行います。
交差検証のスコアを平均することでバラツキを抑えた評価をしたいということです。
そして、その平均スコアを控えておき、別の種類のモデルなどと交差検証の平均スコアを比較してどちらのモデルが優れているのかを評価することができます。
まさに“検証”です。
目的2. どの分割でも有効である説明変数を発見する
交差検証で複数の分割パターンで検証することによりどのように分割しても同等の結果がでる説明変数を見つけることができます。つまり、たまたまデータが偏った分割をされてたまたまとある説明変数が有効であったと判定されてしまうことを防ぐことができます。
そういったたまたまの分割で相関があると出てしまった説明変数を含んでしまうと未知のデータに対して偏った予測をしてしまうかも知れません。
そのために分割を施し（=交差）、評価を平均して観察する必要があります。
目的3. 交差検証でどの分割でも有効であるパラメタ/モデルを発見する
先ほどの説明変数を選定するプロセスと同様ですが、同じようにどのように分割しても近しいスコアが出るパラメタ/モデル（分類だとAUCやLoglossを比較）を見つけること、つまり過学習を避けたパラメタ/モデルの発見ができます。
例えば決定木の深さを6にして、ホールドアウトでは正解率9割だったけど交差検証では平均正解率7割しか出なかったと言う場合、それはすなわちたまたまの分割に過学習しただけの信頼できないスコアだったと言うことになります。
このように偶発的なスコアを見てもこのモデルがどれくらいのスコアなのかわかりませんので、交差検証の過程でどの分割でもスコアが近しくなるように木の深さを調整してスコアを確認する必要があります。
このように交差検証のプロセスでどの分割でも近しいスコアが出るパラメタ/モデルを見つけることによりたまたまの分割に特化してしまう設定を除外することができます。
逆に言えば交差検証のスコアが安定しないと言うのは何か過学習や未学習、特徴量が不足している等が起こっている可能性があるということです。
そう言った場合には、例えば正則化をしたりパラメタチューニングをして精度のばらつきができるだけ押されられるように調整しましょう。
また、当然ながら有効な特徴量がデータ中に存在せず十分なスコアが出せない案件もありえます。
交差検証の後はどうしたらいいの？
交差検証を通して比較した設定/モデルの中で良いものを選択したら、その設定で全データを使用してモデルを作成します。
それが最終モデルになります。
このモデルの評価はどうするのかというと、それは交差検証で得られた評価が得られるはずだということです。
（ここまで私達は何を行なっていたのか思い出しましょう。私達はこのモデルの未知のデータへの当てはまり具合を交差検証を用いて測定したのでした。）
ただし、先ほど言及したランダムリスタートやデータが極端に少ないなどで交差検証の評価が極端にばらついてしまう場合はこの最終モデルがどれくらいの評価を得られるか”不安”である場合があります。
その場合には複数個のモデルを作りそれらの予測値の平均を用いて安定させる必要あるでしょう。（例えばRandom Seed AverageやBaggingといったアンサンブル）
Random Seed Averageの場合は評価はできませんがやはり交差検証で得られた評価と同等の評価が得られると判断できます。
Baggingですと一部のデータが必然と余るため、それらをテストデータとして用いることができます。（=Out of Bagging: 詳しくは末尾の資料に任せます。）
しかし、実際はモデルがそのまま使われている…
ここまでモデルは使ってはいけないと書いてきましたが、実際のところKaggleなどでも交差検証で作成したモデルを全て使っているシーンがあります。
それはなぜかというと、モデルを作り直すコスト（時間など）が割に合わないといった理由です。
仮に5分割KFoldを行った場合、１つのモデルには20%のデータが含まれない訳ですが、他のモデルは含んでいるためあまり劣化はしない算段ということです。
ただし、データが少なく分割することで偏ってしまうというような場合にはやはり全てのデータを学習させたモデルをアンサンブル（Random Seed Average）するかバギングなどをあらためて行う方が良いでしょう。
有名なKagglerの方でも、「シンプルな方が良い」という理由で場合によってはモデルは1つ（全て学習させる）で取り組んでいる方もいらっしゃるようです。
まとめ
このように、交差検証はモデルを作成するプロセスではなく評価やチューニングを目的としたプロセスであると理解できたでしょうか。
しかし、データが多く学習に時間がかかって仕方がないような場合や、交差検証のための検証データを学習に使用せずとも潤沢にデータがある場合は交差検証のモデルをそのまますべてアンサンブルすることが多いようです。（結果的にRandomSeedAverageに近いアプローチになる。）
こちらでは比較的簡単に精度向上が見込めるアンサンブル、Baggingについて解説しています。
ご参考ください。
それでは！
コメント