【Kaggle挑戦記】Spaceship Titanic 攻略 #10：統計的補正の罠。AIの「楽観」を抑えた結果、見えてきたもの

1. 独自の仮説：分布不変の原則

LightGBMで 0.796 まで到達した今、次なる一手として「学習データとテストデータの分布は同じはずだ」という統計的な仮説を立てました。 AIが一律「0.5」という閾値で判断するなら、その結果としての True（転送された）の割合は、学習データの事実（50.36%）に一致すべき。もしズレているなら、閾値を動かして矯正すべきではないか、と考えたのです。

2. 実装と、Macのターミナルが示した驚愕の数字

AIに「確率」を出させ、上位50.36%だけを True と判定するように閾値を調整したところ、コンソールには衝撃的なログが流れました。

 学習データの True 割合 (目標): 0.5036
...
[LightGBM] [Info] [binary:BoostFromScore]: pavg=0.503624 -> initscore=0.014495
⚙️ 算出された最適な閾値: 0.5950
   (デフォルトの 0.5 から +0.0950 調整されました)
------------------------------
 調整後の予測 True 割合: 0.5036 (目標との差: 0.0000)

なんと、AI（LightGBM）をそのまま信じると、True の割合が統計的予測を大きく上回ってしまっていたのです。私は判定ラインを約10%引き上げ、0.5950 という厳しい基準で「選別」を行いました。

3. リーダーボードの結果：無情な 0.79003

結果は、自己ベスト更新ならず。

 Current Best (LightGBM) : 0.79611
 Ratio Adjusted Result    : 0.79003 (▼ 0.00608)

あえて統計に寄せた判断が、スコアを落とす結果となりました。

4. 考察：なぜ「正論」が通じなかったのか？

エンジニアとして、この結果から2つの教訓を得ました。

テストデータの分布差： 「学習用」と「テスト用」のデータ分布は、必ずしも完全一致するとは限らない。今回の事故では、テストデータ側の転送率は 50.36% より高かった可能性があります。
確率は「相対的」なもの： AIが出す確率は「確信度」であって、絶対的な数値ではない。AIが 0.6 と言っても、それは「0.5の人よりは可能性が高い」という順位付けには有効ですが、その数値そのものを統計に当てはめるのは時期尚早だったのかもしれません。

5. それでも、方向性は間違っていない

「0.5」というデフォルト設定を疑い、マクロな視点で補正を試みたことは、今後の複雑なコンペティションにおいて必ず活きる経験です。 AIに盲従せず、エンジニアとしての仮説をぶつけ、その反応をデータで確認する。この試行錯誤こそが、0.8 への唯一の道。次はいよいよ、物理情報である「Cabin（客室）」のパースに挑みます。

データは正直だ。そして、だからこそ面白い。