機械学習プロジェクトにおける特徴エンジニアリングの 5 つのベスト プラクティス

私たちは長年にわたり、機械学習プロジェクトで何が機能し、何が機能しないかを特定するために、さまざまな手法とアプローチを採用してきました。以下の 5 つの手順をまとめましたので、ご参考になれば幸いです。

[[398566]]

シンプルな機能を生成する

モデリング プロセスを初めて開始するときは、できるだけ多くの単純な機能を生成するようにし、コーディングに時間がかからない機能を生成するようにします。たとえば、Word2vec モデルをトレーニングする代わりに、最小限のコードで何千もの特徴を生成する単純な bag-of-words モデルを最初に実装できます。 1 つ以上の特徴の組み合わせが予測に役立つかどうかを事前に明確に知る方法がないため、最初から特徴として測定できるものはすべて使用する必要があります。

ID は機能としても使用できます (必要な場合)

一意の ID はモデルの一般化にあまり貢献しない可能性があるため、機能セットの一部として ID を追加するのは愚かなように思えるかもしれません。ただし、ID を含めると、実践者は一般的なケースでは 1 つの動作を持ち、他のケースでは異なる動作を持つモデルを作成できます。

たとえば、ある場所を説明するいくつかの特徴に基づいて、その場所についての予測を行いたいとします。機能セットの一部として場所の ID を含めることで、一般的な場所のトレーニング例をさらに追加し、他の特定の場所で異なる動作をするようにモデルをトレーニングできるようになります。

カーディナリティを減らす（可能な場合）

一般的な経験則として、多くの異なる一意の値（たとえば 12 個以上）を持つカテゴリ機能がある場合は、その機能に基づいてモデルを異なる動作にしたい場合にのみ、その機能を使用する必要があります。たとえば、米国には 50 の州があるため、モデルの予想される動作をカリフォルニア州では 1 つの方法、フロリダ州では別の方法にしたい場合は、「州」という特徴を使用することを検討します。

一方、「状態」機能に応じて異なる動作をするモデルが必要ない場合は、「状態」機能のカーディナリティを減らす方がよいでしょう。

数え上げ問題に注意する

場合によっては、Bag of Words (BoW) の場合のように、ドキュメントの長さが時間の経過とともに増加または減少しない場合、合計は時間の経過とともにほぼ同じ範囲に留まります。

問題を引き起こしている可能性のあるインスタンスを数えます。 たとえば、あるシナリオでは、ユーザーがサービスに加入してから行った通話の数をカウントする機能があります。 サブスクリプション サービスを提供している会社が長い間存在している場合、純粋な統計では、その会社が多数の電話をかけていることがわかります。

データが増えるにつれて、現在は頻度が低い値も将来的には頻繁に出現するようになる可能性があります。したがって、このような問題に対処するための時間枠を増やす必要がある。

特徴選択を実行する

絶対に必要な場合にのみ機能選択を実行する理由はいくつかあります。

モデルは解釈可能でなければならないので、最も重要な特徴だけを残すのが最善である。

厳しいハードウェア要件がある

大規模な実験を実行したり、本番環境向けにスキーマを再構築したりする時間があまりない

複数のモデルトレーニング間で分布の変化が予想される