SIGNATEコンペの振り返り

はじめに

SOTA Challenge[SIGNATE Cup　2024]に参加して銅メダルを「獲得していなかった為」、解法および自身の振り返りのために書きました。獲得した為と書き始めたかったのですが......。

獲得してませんでした...というのも、チャレンジ期間終了後のLBを見てギリギリだけど何とかメダルに手が届いたと胸を撫で下ろしていたのですが、１週間経ってもメダル付与されないんですよね。で問い合わせてみたら、「チャレンジ期間終了時点で最終評価が確定している投稿者数に対しての順位が上位10％内」なら（1000人なら100位内）メダル獲得ということだった、と。つまり「全投稿者数に対してなら銅メダル水準内」だけど、「最終評価が確定した投稿者数に対しては銅メダル水準に届かない」という事が判明しまして、意気揚々と書いていたのですが、途中で悲しい結果である事がわかった次第です。

すべり込みセーフだったけど運も実力！と自分を鼓舞してましたが、ギリギリ上位10%には入れないことも実力ということで、振り返りをしながら次に進もうという記事になります。

progateから始めて一年、コンペ参加歴は半年程ですが、独学(本や動画等）でChatGPTやGeminiに助けられたりハルシネーションに惑わされたりを繰り返しながらも構築していきましたので、稚拙な箇所が多々あるとは思いますがご容赦くださいませ。

経緯

実は、元コンペにもリアルタイムで参加しておりこの時のLBの結果は上位60%(上位をつけるだけでなんか良さげに見える）でした。参加自体が締め切り2週間位前だったこともあり、あまり試せずに終わってしまい消化不良だったため、改めてSOTA Challengeに参加して、色々試したいと取り組んでまいりました。元コンペ742位→122位(上位10%には入れませんでしたが）と躍進できたことは良かったです。

コンペの概要

（SIGNATE Cup 2024　タスク説明より）「旅行会社の保有する顧客データ（属性や志向、営業担当との接触履歴等）を元に、旅行パッケージの成約率を予測するモデルを構築していただきます」
ということで成約率の予測、評価方法はAUCでした。

前提

・実行環境はGoogle Colaboratory上で。
・とにかく色々試そうと思いEDAやモデルごとにファイルを分けて実施しました。

submitファイルの手順を保存する前にすぐに変更を加えており、環境管理が不十分だったこともあって完全に同じ結果が再現できませんでした。その為ソースコードの方はここで紹介しようとしたSubmitしたコードとは異なります(後半でその辺りのことも記載致しました）

1回目の参加時と2回目の参加時の違い

元コンペの上位入賞者の解法を参考にできたのは大きかったかな、と思います。不均衡データに対する各モデルのパラメータ設定は参考にさせて頂きました。また、1回目参加時にある程度の前処理は済んでいたのでそのまま運用できるところも多く、かなりの時短に繋げられました。これによりあれもこれも試せる！となるはずでしたが、終わった時の感想は時間が足りなかったであり、結局そういうのはキリがないなと感じた次第です。

データ概要

前処理

元配布データと基本的な前処理一覧

特徴量ヘッダ名称	説明	前処理の実施
id	営業リストの顧客ID	なし
Age	顧客の年齢	漢数字等削除・変換、数値に統一
TypeofContact	顧客への連絡方法	OrdinalEncoder、Nanに-1を割当て
CityTier	都市層(1>2>3)	一先ずそのまま
DurationOfPitch	営業担当者による顧客への売り込み時間	分単位に変換し数値で統一
Occupation	顧客のご職業	OrdinalEncoder
Gender	顧客の性別	文字表記を揃えてonehot encoding
NumberOfPersonVisiting	一緒に旅行を予定している人数の合計	そのまま
NumberOfFollowups	セールストーク後に営業担当者が行ったフォローアップの合計数	100以上は一先ずそのまま
ProductPitched	営業担当者による商品の売り込み	文字表記の統一後、各意味合いに沿ってrank化した数値へ
PreferredPropertyStar	顧客によるホテル施設の優先評価	そのまま
NumberOfTrips	顧客の年間旅行数	文字表記は削除変換等して年間の旅行回数に統一
Passport:	パスポートの所持	そのまま
PitchSatisfactionScore	売り込みの満足度スコア	そのまま
Designation	現在の組織における顧客の指定	文字表記の補正・統一
MonthlyIncome	顧客の月収	文字表記の削除と変更をし整数表記へ
customer_info	顧客の情報のメモ(婚姻状況や車の有無、旅行の子どもの同伴の有無について記載されている)	①子供の数、②車所持の有無、③既婚、離婚、独身と未婚に分けて、いずれもLabelEncoding
ProdTaken	目的変数	なし

欠損値処理について

下記のようなものを試して、複数の特徴量を作成しました。
・LightGBMで予測してその予測値で補完。(変数選択は、予測値補完をしたい特徴量以外は全て同じものとして、ハイパーパラメータも同じにして実行した）
・主に中央値で補完。
・欠損値であることを残すため-1として補完
・0として補完。

AgeやMonthyIncomeなどの連続値にはLightGBMで予測してその予測値で補完を採用していましたが、ソースコード含め、チャレンジ期間後半では中央値補完がメインです。そもそもLightGBMでの予測値による補完は、特徴量の数が増えるほどその予測値自体が変わる・変えられる可能性からあまり再現性がないよなあと思い至り最終的には不採用にしました。

モデル

・試したモデル:LightGBM,CatBoost,XGBoost,LDA,ロジスティック回帰、ニューラルネット
・一番良かった(最終的に採用した）モデル：LightGBM
・アンサンブル（スタッキング）：LightGBM、ニューラルネット

特徴量作成の一部(特徴量選択したものから抜粋）

特徴量作成及び前処理後の変更

特徴量ヘッダ名称	説明	内容・補足	理由や仮説
Age_Annual	年齢×世帯年収	年収に対する世帯収入という特徴量を作り掛け合わせ	年齢と世帯収入の関係性の強調
CityTier_reverse	都市層(1>2>3)	都市層(3>2>1)へ変換	都市層の規模を生かす為rank化
Occupation_rank	顧客のご職業:中小、会社員、大企業	職業の規模を生かす為rank化	lgbm以外でもint型として扱う為
NumberOfFollowups_max	セールストーク後に営業担当者が行ったフォローアップの合計数	100以上を元の最大値＋1	外れ値を新たな最大値として。Nanは0として扱う。
NumberOfTrips_year	顧客の年間旅行数	年間の旅行回数で統一しNanは０扱い。	旅行回数０もあり得るとした
Product_Score	売り込み商品のランク×売り込みの満足度	表記揺れ等を統一後に計算	商品ランクが良い程満足度も高く成約率も高いのでは
time_of_follow_new	営業担当者のフォローアップ回数×顧客への売込み時間	交互作用による営業力の算出	営業力が高い程成約率が上がるのでは
Designation_rank	現在の組織における顧客の指定	各意味合いに沿ってrank化した数値へ	可読性の向上、交互作用等に使う為
M_income_transformed	顧客の月収	Nanを予測値で変換したものをRANKGAUSS	右裾が長い為標準化措置。決定技系以外で使用予定だった
RankSatisfaction	売り込み満足度*顧客ランク	前処理したものを掛け合わせた	満足度と顧客ランクが高いほど成約率も高いのでは
travel_frequency	年齢に対する旅行頻度	年間旅行人数/年齢	年齢と旅行頻度の関係性の強調
material_count	婚姻状況	既婚、離婚、独身及び未婚に分けてLabelEncoding	成約可否には婚姻状況の関連性があるのでは
family	家族構成人数	結婚有無＋子供の数	家族構成人数が成約率と関連性があるのでは

特徴量選択

・基本は手動（主に各特徴量の相関を見ながら、さらに重要度を加味しながら行なった）

ハイパーパラメータ

入賞者の解法を参考にさせて頂きました。学習させない方向で何度も試しました。
"learning_rate": 1,
"num_leaves": 32,
'lambda_l1': 1,
'lambda_l2': 30,
"min_data_in_leaf": 20,
"max_depth": 1,
"n_estimators": 5000,
"feature_fraction": 0.9,
"bagging_fraction": 0.8,
"bagging_freq": 1,
"subsample_freq": 2,
"subsample": 0.7,
"random_state": 123,
"importance_type": "gain",
"early_stopping_rounds": 30,

他に試したこと(あまり上手くいかない、もしくは、わからないで不採用）

・アンダーサンプリング・オーバーサンプリング(スタッキング用としては採用）
・アンサンブル単純平均、加重平均
・Boruta:BalancedRandomForestClassifier

できなかったこと

・Optunaによるパラメータチューニング(時間が足りないというより待てない）
・グリッドサーチ等による特徴量選択（待ってられない、自分で選んでやる!となって不採用)
・スタッキング（結局時間が足りなくなって、最後の最後,やけくそでGeminiに手伝ってもらったけどよくわからないまま）
・キャリブレーション

感想

一番モヤモヤしてたのが、手元のtrとcvスコアとLBのスコアが中々nearにならないことでした。後半はAUCだけでなく、precition,recall,F1スコアも見てみましたが、指標がイマイチ曖昧な感じのまま進めていました（最終的には手元のSubmitで一番いいスコアが紛れていましたが）。random_seedを変えるだけでブレるとは入賞者の振り返りで耳にしていましたが、過学習を抑えるようパラメータ設定したものよりもやや過学習気味にした方がスコアが上がったりする、特に最初はCatBoost推しで、手元だと随分よく見せるので期待がどんどん高まる割にLBとの乖離の差が縮まらず最終的に不採用としました。結局、LightGBMに落ち着きました。スコア的には銅メダル水準のものは作れたかもしれないが、リーダーボードの結果からも暫定評価と最終評価のスコアの差があまりないモデルの方が上位に多く見られ汎用性があると言えるのかなと思いました。

反省点

色々試せた分、風呂敷を広げすぎて自分が追いつけていけなかったかもしれません、例えば以下のような事。

・特徴量作成の中でカテゴリ型用とint型用とで複数作った結果、混同して把握しづらくなった。
・特徴量選択を手動だけで決めた事。明確な取捨選択の判断ができておらず作るだけ作った感もありました。
・特徴量の意味や試したことをマメに記録しておかなかったせいで、一度不採用にしたものも時間が経つと忘れてもう一度実行してしまったりした。
・環境管理やログ保存。今回の経験から非常に勉強になりました。

他にも、スコアにこだわりすぎて本質を見失うような瞬間があることに気付けたことは大きかったです。初学者の域を出ない人間がガチャを回すが如く手動でハイパーパラメータ設定にのめり込んでしまい、時間をかなり浪費してしまいました。餅は餅屋でさっさとOptunaで良かったのではとも思いました。データに向き合うはずがスコアに固執していくのはある種当然なのだけども、何のために検証があるのかという事も改めて感じました。
気軽に相談したり聞いたりできる環境や参考にできる調べ方なんかももう少し改善しないとGeminiやChatGPTだけではどうにも遠回りな感じもしました。

元コード再現のためにやったこと

特徴量選択の違いであることまではわかっていたのですが、完全再現には至らず。元々投稿していたファイルの中に最終評価に対するスコアが良いものが紛れていたので、どうせならと思い、それをベースに何回か投稿し直していました（SOTAはチャレンジ終了後も投稿できるので良かったです)。
いつまでも探索するわけにもいかないので、切り上げましたが、結果的に最終評価スコアに関しては割と安定的に改善させることができました。暫定評価のスコアを超えることはできていないのですが、未知データに対してより安定した性能を発揮できるモデルが構築できたかなと思います。暫定スコア0.8314→0.8299、最終評価スコア0.8403→0.8434と改善。

まとめ

挙げればキリがないほど課題が浮き彫りになるなと改めて思いました。この辺りを生かしてまた次に進みます。作って失敗して、もう一度組み直して、壊して、組み直して、でも夢中になれる。勉強と改善をこれからも繰り返していくことになるなと思いました。メダルを最低一個獲るまでやめられません。　生成AIなどもそうですが、相変わらず実務と関係あればなあと感じます。あとNNはもっと使い倒したいです。