ユーザーとアイテムのマッチ度を算出するモデルを利用していますが、ユーザー側の特徴量として商品の提案日というものを使っています。これは、例えば夏に商品を提案する際にコートを提案するのはあまり意味が無いという事から、ファッションにおける推薦には季節性を考慮する必要があるという所をモチベーションとしています。この記事では日付を特徴量として使った際に線形モデルで季節を予測してアプリケーションで使う際の注意点について解説します。配送日は日付なので、循環するものであると言えます。12月31日と1月1日はとなり合わせの日付なので特徴としては非常に近いはずです。ところが日付をそのまま入力とすると、機械学習のモデルは12月31日と1月1日の間に数字的な繋がりを見出す事が出来ません。そこでモデルが日付を循環したものとして捉えられるように三角関数を使って日付を変換します。エンコードされた日付を使えば数字的な繫がりを加味した入力と出来そうですが、実はこのデータを線形モデルの入力としてそのまま使うと思わぬ落とし穴にハマる可能性があるので解説します。作られたデータを使って以下のようなコードで季節を推定してみます。target_seasons))まずは季節が春である事を判断出来るかどうかを試してみます。エンコードされた日付データから、上手く春を推定できている事がわかります。ある事を判断できるかを試してみます。'FALL']このように、全く判断出来ていない事がわかります。いった隣り合った季節の推定は問題なく出来ます。'WINTER']これは直感的には以下のように考える事ができると思います。本引けば分離可能なので線形モデルで判断が可能です。本引く必要があり、線形モデルでは判断が不可能であると考えられます。本の線が必要このようにエンコードされた日付を入力として使った場合に、線形モデルを使ってしまうと上手く特徴が使えない事があり得るという事がわかります。非線形モデルでの挙動それでは非線形なモデルではどのような挙動になるかを試してみます。"FALL"])このように、隣り合ってない季節でも正確に予測する事が出来ます。非線形モデルによる挙動の違いについて解説しました。データを上手く作っても、モデルの特性によっては望んだ性能が得られないといったケースがあり得てしまう事を検証しました。アプリケーションやデータによって、どういったモデルを使うのか、また選択したモデルでデータを上手く扱う事が出来るのか、といった事を考慮に入れながら開発をしていくのが大事だと考えいます。書いているのでぜひとも参照してください!自分もやったことは記事内の2ヶ月〜最終日以外はほぼ同じです。時系列のコンペでは、特徴量として各訓練例が取得された時間や日付を組み込むことがあります。