ツイートコンペの敗因をまとめました。 全部で38個あります。
ほとんど原因しか書いていませんが、対策がほぼ自明なので書く必要もないと思っています。
内容が被っている部分や矛盾している部分もありますが、微妙にニュアンスが違ったりするので、両方残しておきます。
- 締切前日までちゃんとしたルールを把握しておらず、ネガポジ判定みたいなデータだと勘違いしていた
- Notebookを2種類しか参考にしなかった
- スコアの高いやつを適当にCopyすればいいやといった雑さがあった
- 締切前日までちゃんとデータを見ずに突っ込んでしまった
- EDAをちゃんとやってなかったのでデータの傾向が分かっていなかった
- データが英語なのでそもそもデータの気持ちを理解できなかった（これはチームを組む以外に解決方法が無かった気がする）
- 学習データ/テストデータを根拠を持ってクリーンナップするべきだった
- Discussionをそもそも見ていなかった
- Notebookの計算資源が思ったより少なかった（言語処理＋PyTorchという組み合わせで、経験が足りず見積もりができなかった → 実践を積む）
- 30h/weekだと足りない → 根本的に長期的に戦う必要があった
- 必要に応じてTPUを使うこともアリだったかもしれない（長期戦になりそうなら、切り替えられるコードを作っておく）
- どのタイミングで30時間がリセットされるのか知らなかった → おそらく特定のタイミングではなく、その週で使った部分が記録され一週間後にリセットされる
- 他の計算資源も検討するべきだった（AWS, GCP, ほか）
- パラメータサーチやデバッグなどを高速な環境で試すべきだった（ハイパラサーチはそもそもしてないが）
- 本当に困っていたらColaboratoryなども使えるようにしておくべきだった（K80がもう一台あるだけでも心強いレベルの計算資源なので）
- 使ってない便利ツールが多い。今度からkaggle（PyPI）を使ってみる
- 知っている python モジュールが少ないので、自分のモノとして使えていない。ここぞというときに実装効率が落ちたり実装を諦めたりするので、普段から情報を集めておく必要がある
- 自然言語処理のセオリーを理解しないまま突っ込んでしまった
- 前処理を元Notebookに任せっぱなし
- 後処理も元Notebookに任せっぱなし
- PyTorchを書くのが初めてだったので、実装効率が落ちた
- デバッグしきれなかった
- 序盤はNotebookを写経するなど、迷走して時間を無駄にしていた
- PyTorchで実装方法がわからず諦めた部分がある
- 強引な実装が3-4箇所あり、どこかで意図していない動作をしている可能性がある
- Robertaが何なのかちゃんと調べずに突っ込んでしまった
- モデルがいまだに何をしているのか分かっていない
- 自分から論文を調べるという行為そのものをしていない
- アンサンブルの定石が分かっていない気がする（分かっていない部分が分かっていない）
- 適当に学習率を下げれば汎化性能が上がると勘違いしていた（PrivateScoreは下がり続けていた）
- 根拠なしに独自の理論を組めば性能が上がると勘違いし、時間を無駄にした（下がった）
- パラメータサーチさえしなかった（下がらないかもしれないが、探索している人に対して不利を取る）
- モデルの仕様が理解できなかったので実装を諦めた部分がある
- 絶対に勝てないと分かっていたのに朝まで続けてしまった（少し体調崩した）
- Shakeとかで雑にひっくり返ってワンチャン勝てると勘違いしていた
- Leaderboard上位者は必然的にSubmit数が多い。自分は1/10-1/20程度しか投げていない
- やりきるなら、最後はkaggleのGPUを並列で回せた。とりあえずやればいいやという怠惰な感情に気づかなかった
- ディープラーニングのことしか考えていなかった
負けるべくして負けたという感じ。
今まで支援していただいた方
並びは支援して頂いた順番です。
