特徴量選択に用いるデータとタイミングについて

Question

質問

研究で集めた教師付きデータに対して機械学習を適用する予定の者です。
Pythonのライブラリ(SFS)を使って、特徴量選択をしたいと考えています。

全データのうち80%をトレーニングデータ、20パーセントをテストデータとして用いるとします。
80%のトレーニングデータでクロスバリデーションをしてから、テストデータでの精度を
確認しようと思っています。特徴量の選択をしたい場合、

Q1.特徴量選択に使用するデータはどこまでなのか？
もしくは特徴量選択用に新たにデータの分割が必要なのか？

Q2.特徴量選択をするタイミングはいつなのか？(クロスバリデーションの前？中？)

について教えていただきたいです。

Answer 1

こちらの記載がわかりやすいように思います。
変数選択・特徴量選択のときに注意すること

• 特徴量選択の元データは、実際使うデータであっても、新たにデータ分割したものであっても、オーバーフィッティングのリスクは存在する。
• 大切なのは、目的変数の情報を特徴量選択に入れないこと。

ただし、これは、オーバーフィッティングに着目した考え方の原理ですので、「目的変数の情報を特徴量選択に入れること」を否定するものではありません。オーバーフィッティングのリスクを考慮して、汎化性能を見てマズそうなら別の手法に変えましょう、くらいなニュアンスと思います。実際、サンプルコードとしては、目的変数の情報を特徴量選択に入れる方法の1種であるEmedded Methodとして、決定木による重要度を使っている例が多いようです。

また、特徴量選択の際に、どこまでのデータを利用するのかは、様々な流儀があるようです。必ずしもout-of-Foldで検証するべきとは限らず、実際の学習と同じテストデータをそのまま使うことが多いです。サンプルコードも単純にx-train, y-trainそのまま使っている例が多いです。この理由としては、特徴量選択という行為は、本質的にはモデルを単純化して、バリアンスを減らす方向に働くため、オーバーフィッティングのリスクは他の最適化より少ないからである、と考えます。なお、書籍「Kaggleで勝つデータ分析の技術」では「理想的にはout-of-Foldで検証することが望ましい」と記載されており、逆に言えば、多くの場合はそうしていない、ということを表現しています。

一方、ハイパーパラメータチューニングの際は、行為そのものがバリアンスを増やすリスクがあります。よって、kfoldといった手法で、out-of-Foldで検証すべきでしょう。サンプルコードでもそうなっている例が多いようです。

特徴量生成〜選択〜ハイパーパラメータ最適化の一連の流れについては、「特徴量生成、特徴量選択、ハイパーパラメータのチューニングを自動化するライブラリを使ってみた」も参考になります。

Comments

[CoffeeLover]

回答ありがとうございます。
教えていただいた記事を読みました。
オーバーフィッティングのリスクはいつでも存在し、
目的変数の情報を特徴量選択で使用すると、さらにそのリスクが高まるのですね

「SFSなどの目的変数の情報を使用する特徴量選択も手段の一つではあるが、目的変数を使用しない特徴量選択の方法を考える方が良い。」
と解釈したのですが、間違いはないでしょうか？

[toast-uz]

だいたいそういう認識ですが、「目的変数の情報を使用する特徴量選択」を否定するものではなく、オーバーフィッティングのリスクを考慮して、汎化性能を見てマズそうなら別の手法に変えましょう、くらいなニュアンスと思います。（同一のテストデータで汎化性能高める方に選択しすぎても、オーバーフィッティングのリスクあり）

考え方の原理として、ご紹介した記述は有用だと思いました。

[CoffeeLover]

ありがとうございます。理解が深まります。

最後にもう一つお聞きしたいのですが、
もし「目的変数の情報を使用する特徴量選択」を行う場合は、
学習データをさらに分割して、学習データの一部を特徴量選択用に使い、残りをクロスバリデーションに使うという認識で合っていますか？
特徴量選択用に学習データ全てを使用して、クロスバリデーションでも学習データ全てを使うということはしないですよね？

[toast-uz]

「特徴量選択用に学習データ全てを使用して、クロスバリデーションでも学習データ全てを使う」の方が多いようです。エビデンスや理由含めて回答を追記してみました。確認ください。

[CoffeeLover]

そうなのですね。詳細に回答していただき本当にありがとうございました。
教えていただいた書籍や記事を参考に研究を進めていきたいと思います。