arutema47's blog

書いたり書かなかったり。

学習が何で律速してるか、把握してますか?

(最新SSD IOはPCIe x4でした。ご指摘ありがとうございます。)

はじめに

Kaggle Advent Calendar 2022 8日目です。

突然ですが、あなたはDNN学習時にどの処理で学習速度が律速しているか把握してますか?

DNN学習には図に示すように大きく3つの要素があります:

  • (SSDからの)データ読み込み
  • (CPUによる)データ前処理
  • (GPUによる)DNN計算

学習時のデータの流れとしては

  1. SSDからデータが読み込まれ、CPUに送られる(SATA or PCIe)
  2. CPUにてaugmentationや正規化などの前処理が行われ、GPUにデータが送られる(PCIe x16)
  3. GPUにてDNNの計算・学習・パラメータ更新が行われる (GDDR)

というのが一般的かと思います。

ここで各データ通信に使われるインターフェース(IO)に注目してみましょう。

まずGPUとGPUメモリ(GPU内DRAM)間通信はGDDRというメモリIOが使われ、その速度は非常に早いです(A6000なら600GB/s)。 またCPU-DRAM間もDDR4といったメモリIOで数10GB/s出ており、CPU-GPU間の通信はPCIeが16束になったPCIe x16というIOでこれも高速です。 対してSSD-CPU間は普通のPCならSATA、最新PCならばPCIe x4で接続されるのが一般的です。

特にSATAは他のDDR系に対して最悪2桁ほど通信が遅く、注意しないとデータ読み込みで容易に速度が律速してしまうのがわかるかと思います。 またHDDを使っているとSSDより読み出し速度は1/3程度になってしまうので使うのは問題外です・・

GPU処理に関する高速化などの記事は大量にある反面、データ読み込みやデータ前処理の高速化の速度律速についてはあまり語られていない気がします。

この記事を読むことで

  • 自分の学習が何で律速しているか把握できるように
  • データ読み込みや前処理の高速化
  • 学習高速化してより早く多く実験を回す

ようになるきっかけとなれば良いと思います。

どの処理で律速しているか調べる

僕は学習を回したら

  • 1) GPU使用率を調べる
  • 2) CPU使用率を調べる

の2つを見ます。

まずステップ1といてnvidia-smiを叩いてみましょう。

このGPU使用率が具体的に何を指しているかは今回省きますが、 ここでGPU使用率が100%になっていればGPU律速になっており、データ読み込みやデータ前処理に問題はありません。

ただこの使用率が20~60%と低い値になっている場合、GPUは半分以上の時間データを待っているだけであり、データ読み込みかデータ前処理に処理が律速されていると考えられます。

次にステップ2として、htopなど叩いてみてCPU使用率を見てみましょう(windowsならタスクマネージャーで見れます)

CPU利用率が高い場合(全コア使用されている)、データ前処理で処理が律速されています(CPU律速)。 kaggle notebookはCPUが貧弱(2コアしかない)ため、頻繁にCPU律速が起きてしまいます。 ただpytorch dataloaderでnumber_of_workerを設定していない場合は全コアを使用してくれません。自分のコア数程度にworker数を設定して前処理速度を高めましょう。

一方でGPU律速でもCPU律速でもない場合、データ読み込みが全体を律速している可能性があります。 上記でも書いた通りSSD⇨CPUのIOは貧弱であり、あまり多くのデータが送れません。 そのためCPUやGPUが十分に早いとCPU/GPUのデータ待ちといった状況が発生します(SSD律速)。

各律速の改善方法については次章に書きます。

各処理の速度改善方法

データ読み込み速度の改善

データ読み込みは他IOに比べ数桁遅いため、ボトルネックになりやすいです。

これを改善するためには

  1. 読み込むデータのサイズを予め小さくしておく
  2. データを圧縮しておく
  3. DRAMに予めデータを展開してDRAMからデータを読む
  4. 早いSSDに買い替える

の4通りが考えられます。まず1つ目ですが、例えばKaggleから配布された画像サイズが1024x1024であった場合でも学習に用いるサイズは512x512と低解像度である場合がほとんどです。 その場合、予め画像データを512x512等縮小したものを保存しておき学習時にはそちらを読み込むことで、この例ではデータの読み込みスループットは4倍向上します。

また画像であれば可逆圧縮であるpngに対し、非可逆圧縮であるjpgに保存フォーマットを変えることで大きくファイルサイズを削減することができます。 生データであれば(CPU負担は増えますが)npzといった圧縮形式で保存しておくことでデータ読み出しのスループットは向上できます。

またDRAMに自信ニキの場合、予めメインメモリ上に全てのデータを展開しておく力技も考えられます。 そうすればDDRでデータ読み込みを行えるため、ボトルネックは解消できます。(書くの大変ですが)

Dataloader resets dataset state - #6 by bfeeny - PyTorch Forums

それでも解消しない場合はPCIe対応のSSDを買いましょう! 現在は第四世代PCIeのSSDも売っており、10倍ほど早くなります。マザボが対応しているかはご確認ください。

価格.com - インターフェイス:PCI-Express Gen4のSSD 比較 2022年人気売れ筋ランキング

データ前処理速度の改善

  1. worker数を最大化する
  2. 画像を縮小する
  3. CPUを買い替える

のが考えられるアプローチです。

まずデータ前処理が律速している場合、まずはdataloaderのworker数を最大化しましょう。 こちらの記事のdataloder編が詳しいです。

qiita.com

また画像の前処理(というか画像処理一般)は画素数をNとした場合O(N2)と書けるため、予め画素数を縮小しておくおくことで前処理速度も大きく向上します。 予めresizeした画像を使うのはもちろん、例えばresizeを最初にしてから他前処理をすることでも処理速度の向上が期待できます。

最後にはCPUをコア数多いものに買い替えましょう(8コアあれば大抵十分な気もしますが・・)

GPU処理速度の改善

書いてる人多いので簡単に。

  1. AMPなどFP16・TF32を用いて計算する
  2. pytorch2.0のcompileを使う
  3. batch数を増やす
  4. GPUを買い替える

aru47.hatenablog.com

AMP(mixed precison)で学習するとFP32に比べメモリ転送量が半分になる他、TensorCoreを使うことで計算速度が大幅に向上します。 まず最初に試しましょう。

またpytorch2.0(現在はnightly build)のcompileを行い計算グラフを最適化することで精度劣化なく"ただで”1.5~2倍の高速化が可能とのことです。 是非試してみましょう(試したらなんか書きます)

またbatch数が極端に少ないとGPU速度が遅い場合もあります。WIP。

コンピューティングについての他記事

GPUってそもそもなんや?

aru47.hatenablog.com

律速律速ってそもそもなんや?

aru47.hatenablog.com

Pytorch学習スケジューラはtimmのCosineLRSchedulerがいいぞ

kaggle的備忘録

Pytorchモデル学習では学習率スケジューラ(LR scheduler)が必須。

特に論文ではCosineLRスケジューラがよく使われる。

こんなん

事前学習モデルでは最初に低いLRでwarmupを数epochした後に最高LRに設定後cosine上にLRが低下していくスケジューリングが経験上良い精度を達成できる。

これがpytorchデフォルトにあれば良いのだが、用意されていない。

一方でtimmに用意されているのは意外と?知られていない。

timm.fast.ai

from timm.scheduler import CosineLRScheduler
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)
scheduler = CosineLRScheduler(optimizer, t_initial=100, lr_min=1e-6, 
                                  warmup_t=3, warmup_lr_init=1e-6, warmup_prefix=True)

そして学習ループ内で

for epoch in range(100):
   scheduler.step(epoch)
   train()
   eval()

のように回せば良い。

研究室立ち上げ時に参考にしたこと【WIP】

研究室運営の初動は共同研究者にも恵まれたのもあり、安定しつつありますが企業→大学講師パスだったので着任時に科研費もさきがけの存在すらしらなかったので情報収集に苦労しました。

誰かの役に立てるよう、備忘録的に参考になったサイトや情報をまとめます。

研究室運営

着任~3年目まで何をしたか具体的に書かれている貴重なサイト。 着任時にはかなり読み込み、1年目は出せるグラントには全部出しました。

30pi.blogspot.com

明大中村先生の貴重な研究室運営のノウハウ

nkmr-lab.org

学生指導

(TBD)

グラントライティング

グラントライティングは独特な作法・ノウハウがあると感じました。(電気・CS分野だと科研費本はそこまで頼りになりません) Twitter・人脈を総動員して先輩研究者の申請書を見せてもらうのが一番勉強になると思います。

https://pbg.cs.illinois.edu/misc/SecuringGrants.pdf

特にこのページを大事にしてます

pages.cs.wisc.edu

Writing grant proposals is hard. They are harder than papers because they are part fiction. Fiction tends to come unnaturally to scientists and engineers who may be more comfortable dealing with known facts. Ph.D. students encounter a similar challenge when proposing their Ph.D. work. Below I present:

  • CARE: Are you tackling an important problem? If you can make progress on it, will anyone care?
  • NOW: Why now? If this problem is so important, why has it not been addressed before?
  • IDEAS: Do you have concrete ideas for starting an attack on the problem and a vision for proceeding further? Is initial progress likely and subsequent progress possible?
  • RESULTS: Do you have some preliminary results? Do you demonstrate a good understanding of the problem and the methods needed attack it further?
  • PLAN: Do you have sensible plans and methods (e.g., concrete steps and ways of decoupling risks)?
  • CAN-DO: Why you? Why are your qualifications and infrastructure appropriate?
  • LEGAL: Have you followed the rules of the solicitation (e.g., compelling broader impacts for NSF)?

代表で出したグラント

  • 民間財団はテーマが最低限マッチするものを>10は出しました。

  • 科研費: 研究スタートアップ、基盤B

  • JST: さきがけ

OpenAIのWhisperを使って動画字幕を自動生成

目的

OpenAIが公開した文字起こしAIのWhisperを使って動画に字幕を自動生成します。

パーフェクトではないですが、十分実用的な日本語字幕が生成できます。

用意

github.com Python3.7+とpytorch1.0+環境が必要。ローカルがなくてもcolabで十分動くと思います。

pip install git+https://github.com/openai/whisper.git # whisperインストール
sudo apt install ffmpeg # ffmpegインストール

Whisper 実行

動画test.mp4の字幕生成するとします。

# ffmpegを使い動画から音声データ抽出
ffmpeg -i test.mp4 -acodec libmp3lame -ab 256k audio.mp3

# Whisper実行
whisper audio.mp3
# Whisper実行(モデル精度変更)
whisper audio.mp3 --model medium

# 字幕動画生成
ffmpeg -i test.mp4 -vf subtitles=audio.mp3.srt test_subtitle.mp4

モデル性能は以上のようにまとまってます。 試した感じmedium辺りがミスが少ない精度です(英語であればbase程度でも性能高いです)

物体検出ライブラリの紹介と所感

記事について

f:id:aru47:20220101123652p:plain

画像はDetectron2より

物体検出をほとんど使っていない方を対象として、2021年末の物体検出ライブラリを俯瞰することが本記事の目的。

ある程度物体検出の経験ある方は学ぶことは少ないと思う。またあくまで書いてあるのは筆者の感想であるので人によっては全く違う意見になることもあるかと。また本記事ではモデルの技術的な説明はありません。それらについて理解を深める際は参考ページや元論文を当ってみると良いかと思います。

また大変遅くなりましたが、本記事はKaggleアドベントカレンダー(裏)の24日目でもあります(年明けちゃってすみません)。

qiita.com

紹介するライブラリ一覧

Library mAP range Architecture Instance segmentation License Repo Stars
yolov5 37-50 Single-stage GPL-3.0 Here 20.4k
YOLOX 40-51 Single-stage Apache-2.0 Here 5.4k
efficientdet 33-53 Single-stage Apache-2.0 Here 1.3k
Detectron2 35-48 FRCNN Apache-2.0 Here 19.4k
mmdetection 35-50 Single, FRCNN Apache-2.0 Here 17.8k

FRCNNって何?って方は以下記事もどうぞ。

qiita.com

所感

  • yolov5がstar一番多い

  • yolov5以外はオープン(Apache-2.0)ライセンス。GPL-3.0は仕事で使うには注意が必要。

  • どのライブラリも達成可能な精度レンジは似ている。

  • yolov5,YOLOX,efficientdet, Detectron2はあるアーキテクチャに特化したライブラリに対し、 mmdetectionは様々な物体検出モデルの再現用ライブラリとなっている。

  • Instance segmentationにはMask-RCNNアーキテクチャが必要。サポートしているのはDetectron2とmmdetection。

アンサンブルについて

  • 実際にkaggle等で使う時はyolo+effdetなどをアンサンブルすることが多い。カツオコンペやvinbigなど複数ライブラリのアンサンブルでスコアが一気に伸びる例が多かった

  • Signateカツオコンペ yu4uさんカツオコンペ解法

  • Kaggle Vinbig 1st place solution f:id:aru47:20220101200405p:plain

Yolov5+effdetのアンサンブル

VinBigData Chest X-ray Abnormalities Detection | Kaggle

  • Kaggle Satorius 2nd place solution f:id:aru47:20220101200301p:plain

Cellの物体認識はyolov5+effdet+MaskRCNNのアンサンブルで実施している。

インスタンスセグメンテーションをせずに、認識したBoxから更にU-netでセマンティックセグメンテーションを実施している。

精度vs速度トレードオフ

f:id:aru47:20211230204414p:plain

ブログ執筆にあたりA6000 GPUを使い学習済みモデルの推論速度を計測してみた。

グラフにまとめたのが上図。

所感:

  • 思ったよりもyolov5の性能が良い

  • YOLOXページ上ではV100でベンチマークしており、YOLOXの方が早いという結果。これはGPUによって前後しそう

  • YOLOX, yolov5はTensorRTに対応しており、適応すれば推論は数倍早くなると思われる。

  • YOLO系がefficientdet系より大幅に早いという事はどのGPUでも成り立つ。

  • Detectron2, mmdetectionの速度は未測定。学習時の感覚では大体efficientdetくらいの速度ー精度トレードオフ。

ライブラリ紹介

yolov5

f:id:aru47:20211231202104p:plain

ライセンス以外文句なしのライブラリ。

とにかく学習と推論が早いので実験しやすく、精度も高い。またs,m,l,xと4サイズ揃っており精度と速度トレードオフを作りやすい。

ドキュメントも豊富でissue検索すると大体のやりたいことはカバーできるかと思われる。Issueを立てても開発者の返事も早くバグfix速度が凄い。

欠点はライセンスがGPLである点とモデル、データ周りの改造が難しい点でしょうか。

Wandb連携しておりログも自動化してくれてるのが地味にありがたい。

f:id:aru47:20211231202026p:plain

学習について

学習時にはデータを独自フォーマットに変換する必要あり。COCO形式からの変換についてはkaggle notebookをみるのが良いと思う。

公式より:

github.com

小麦コンペのNotebookより:

www.kaggle.com

Vinbigコンペより:

www.kaggle.com

推論について

公式ページにあるtorchhubのモデル推論がお手頃(以下抜粋)。 Kaggle環境ではこのコードではエラー出るため、detect.pyを使うことが多い。 Kaggle環境でも問題なく回ります。

import torch

# Model
model = torch.hub.load('ultralytics/yolov5', 'yolov5s')  # or yolov5m, yolov5l, yolov5x, custom

# Images
img = 'https://ultralytics.com/images/zidane.jpg'  # or file, Path, PIL, OpenCV, numpy, list

# Inference
results = model(img)

# Results
results.print()  # or .show(), .save(), .crop(), .pandas(), etc.

www.kaggle.com

Yolox

f:id:aru47:20211231233155p:plain

出た当初は学習コードが分かりづらかったがかなり整備されてきた。

ライセンスがオープンなyolov5と言えるかも。仕事で手軽な物体検出を使うとしたら自分もコレを使う気がする。

中国のトラッキングライブラリなどでyoloxが使われることが多く、採用は増えている。

学習について

公式readmeより:

github.com

サンゴコンペよりnotebook:

www.kaggle.com

Efficientdet

Yoloxが来る前はライセンスフリーで最高精度が出るライブラリだった。ただ学習速度は4〜8倍ほど遅い。あとd7といった巨大モデルではよく学習が落ちるのに苦労した。

精度、速度共にyolo系に劣るがyolo系とは抽出する特徴が違うのか、アンサンブルに加えると精度向上に寄与するため様々なコンペで使われている。

学習コード

小麦コンペのnotebookがわかりやすい。ただこれは最新repoには対応していない方式である点に注意。 使う場合はdatasetにあるeffdetのバージョンを使おう。

www.kaggle.com

torchvision

なんだかんだ言って使いやすいライブラリ。精度はそこそこだがPytorchに付属しているのでインストール不要なのがありがたい。

pytorch.org

Detectron2

MaskRCNNの公開レポだったものが包括的な物体検出ライブラリに進化した。

昔は物体検出ライブラリ自体が使いやすいものがなかったが、最近はyolov5を始めとして高精度・使いやすいものが出てきており役割が変わろうとしている気も。開発は止まり気味で最新モデルのインプリは少ない。

一方で今でもインスタンスセグメンテーションを扱えるのは強み。

ちなみにDetectron2の解説についてはHiroto Hondaさんの一連の記事がとても詳しいです。

medium.com

学習コード

このcolabがデータセット準備から学習までカバーしている。癖が強いのでなれるまでは苦労するかも

colab.research.google.com

mmdetection

f:id:aru47:20220101121824p:plain

学会で発表された物体検出技術をかなり広範囲に渡り実装、モデル公開しているライブラリ。model zooを見て通り対応モデル数が凄まじい。

github.com

  • サポートも手厚く、issue上げるとすぐに返事をもらえるのがありがたい

  • またフレームワークも独自形式のため最初は苦労するかもしれないが、モデル定義もデータセット形式も慣れると使いやすく改造もしやすい。

  • Kaggleのようにひたすら性能を出したいというよりかは研究で様々な手法を検証したい、新たにbqckboneやheadを置き換えたい時に便利だと思う。

  • YOLO系と抽出する特徴が違うためかアンサンブルに加えると精度向上に寄与するため、様々なコンペで使われている

学習コード

github.com

Sartorius: MMDetection [Train] | Kaggle

ゼロから実装する物体検出モデル

こんな記事書いておいてなんだけど、物体検出ライブラリを使っているだけでは物体検出について理解を深めることはできない。

自分でネットワークを実装しないと応用性のある知識や技術は身につかないと思う。

また既存物体検出ライブラリは改造が難しく、仕事や特定コンペの飛び道具として使う時に対応が難しくイチからネットワークを書けると対応の幅が広がる。

SSD

物体検出モデルの基本のsingle-stage-detector。まずはこのモデルから実装することで物体検出モデルに対する理解を深められると思う。

例えばamdegrootのssd repoは非常に読みやすい実装である。

github.com

発展Pytorchに詳しい解説があるため、よみながらイチから実装すると良い。

CenterNet

個人的には物体検出モデルをとことんシンプルにした革命的な実装。

誤解を恐れずに言うとu-netで物体検出しているため、ネットワークが非常にシンプルになる。自分でイチからモデルを書くのも簡単(精度出すのは色々作ろこみが必要だが)で応用も効きやすいと思う。

github.com

github.com

小麦コンペの筆者の実装

www.kaggle.com

公式実装はわかりづらいため、上のような実装が良い参考になると思う。

コンペ使用例

例えばPKUコンペではCenterNetのheadを拡張し、画像から3D位置を認識するネットワークがベースラインとなった。

www.kaggle.com

またNFLコンペでは上位者の解放でヘルメット位置と角度を検出するネットワークにCenterNetが使われた。

www.kaggle.com

2021年面白かった本

実は三体とメダリストを布教する記事なんですが、オマケで今年面白かった技術書もまとめました。

技術書(順不同)

ディープラーニング学習する機械

ディープラーニングの歴史は耳タコだが、過去のAIブームからずっとニューラルネットを牽引している当事者が記述した貴重な本。

Brag-LuCunのあだ名通り随所に入る自慢話や悪口が軽快で面白いw

量子コンピュータの進歩と展望

量子コンピュータの基礎、応用、そしてこれからについてコンピュータ・サイエンス目線でスタンフォード大教授がまとめた本。

アメリカの本流としての量子コンピュータ研究がどのように向かっているかわかってとても良かった。

また一章に書いてある半導体発展の歴史も非常に面白い(ミーティングでよく言っていた)

研究者の仕事術

PIとしての時間管理術、プロジェクト管理術を書いた貴重な一枚。色々なビジネス書のエッセンスを凝縮しPI向けに書き直してくれているのが良い。

研究者に限らずエンジニアやフリーランスで一旗あげようとしている方ならば参考になることが多いと思う。

  • 狭い世界でまずは世界一になれ

  • クオリティの高い成果の20%があなたの評価の80%を決める20/80の法則

など金言が多い。

科研費獲得の方法とコツ

科研費って何?からPI始めた自分にとって本書は大助かり。

RISC-V原典

RISC-Vの概要、利点から命令セットまで短くまとまっている。今更授業用に読んだけど面白かった。

ちなみに英語版は無料で読める。

Pythonではじめる数理最適化

数理最適化とはなんぞやから実務的データへの最適化の適応をいくつかのケース(クラス分けから割引クーポンの配分等)に分けて紹介しており実践的な一冊だった。

数式も多すぎず初学者向けなので、引き出しを増やしたい人に取っ掛かりとして読む一冊として良いと思う。

Reinforcement Learning 2nd edition

http://www.incompleteideas.net/book/RLbook2020.pdf

無料で内容が公開されており、強化学習の初歩から理論をわかりやすく記述している。

来年ゼロから作るDeepLearning④強化学習編が発売され似た範囲をカバーしてるのでそちらを読んでもよいかも。

小説

三体

三体

三体

Amazon

久しぶりに時間を忘れて読んだ小説。オバマ大統領がファンであることを公言したことで話題になった中国発のSF小説。

翻訳者もSFの重鎮で非常にスムーズに訳されておりとても読みやすい。

第3部まであり、1部も面白いのですが2部から加速度的に面白くなってくる。ここまで面白い本には中々出会えそうにもないのが残念。

No Rules

Netflixの社風について書いた本。

かなりぶっ飛んでおり真似できる気はしないが、何故この会社が急成長を遂げられたか垣間見れて面白い。

漫画

メダリスト

f:id:aru47:20211229203555p:plain

今年イチの漫画。

1巻はKindle版無料なのでまずは読んでみよう。

主人公いのりの成長は激アツですね。。個人的には3月のライオン以来の衝撃で5巻が楽しみ。

ラーメン再遊記

f:id:aru47:20211229203657p:plain

【画像】ラーメンハゲ、ガキから正式にラーメンハゲ呼ばわりされる : チャーシュー速報

ラーメン発見伝を読んでいれば楽しめる、ネットで有名なラーメンハゲが主人公となったスピンオフ。

枯れたおっさんが放浪しているだけなんだけどなぜだかやたらと面白い。

クソコンペオブザイヤー2021

よくぞこの記事に来てくれた。
褒美としてクソコンペに参加する権利をやろう

f:id:aru47:20211212193533p:plain

本記事について

クソコンペオブザイヤー2021(KCY2021)へようこそ!

どうも、クソコンペ愛好家のarutema47です。

本記事はKaggleアドベントカレンダー(裏)の12日目の記事となります。

よくKaggleが(仕事の)役に立たないと言われる要因として

  • データセットがキレイすぎて非現実的
  • 実際に仕事ではそのようなキレイなデータセットは手に入らない
  • 評価指標の設計こそデータサイエンティストの仕事として重要

という意見があり、ある程度的を得ていると思います。

一方でKaggleや他コンペサイトも常時キレイなデータセットかつ考え抜いた評価指標を提供しているわけではありません。評価指標のバグは日常茶飯事ですし、データのアノテーションバグなどもよくあります。ただこれらのバグに対しても指摘をすればすぐに対応してくれ、コンペに大きな支障があることは少ないです。

しかし明らかに狂ったデータセットやタスク設計のまま、最後までコンペが走ってしまうことが年に何度かあり、そのようなコンペはクソコンペの名を(主にTwitterで)冠します。これらのコンペにコミットしてしまうと中々辛いものがあるのですが、(良コンペからは決して学べない)反面教師として学べる事項が多いと思っています。

そのため本記事はクソコンペから反面教師として学びを得ることを主たる目的とし、特定ホストを中傷する意図はありません(炎上気味なタイトル付けといてなんですが)。またクソコンペの判断基準は著者独自のものです。もし他に取り上げたいコンペがありましたら、是非別記事を書いてみてください!

そして月刊Kaggleは役に立たないといった意見で"タスク設計やデータがキレイすぎる"と聞いた時はこのようなクソコンペも過去にったことをそっと思い出してください:angelface:

クソコンペを考える

KCY2021のノミネート前に著者が考えるクソコンペの要因を挙げます。端的にクソコンペとなりえる要因(以後クソ要因と略)は大きく4つほどあると思っており、それぞれブレークダウンしてみます。

クソ要因

  • A データセットの品質が低く、コンペに重大な支障がある
  • B タスク設計が悪い(今の技術では解くのが困難、評価指標が良くない)
  • C 致命的なリークがある
  • Dタスク設計に面白みがない(参加者目線ですが)

Aはまさに一番学びのあるクソ要因であり、本記事でも積極的に取り上げたいと思います。データセットの品質というと例えばラベルエラーがまず挙がります。後述するようにラベリングエラーが大きすぎるとモデル精度を正常に測ることができなくなってしまい、コンペが成り立ちません。

Bはタスク設計が難しすぎる・現在の技術では解くのが困難なため結果運ゲーとなってしまうコンペを指します。例えば6ヶ月後の株式を予測するコンペなどはタスク設計が難しすぎ、運ゲーとなってしまい参加者としてあまり面白みはありません(e.g. Jane Street Market PredictionTwo Sigma: Using News to Predict Stock Movements)。一方で同じ金融タスクでも短期間のボラリティ予測とタスク設計を工夫したOptiver Realized Volatility Prediction色々ありましたが最終的には比較的良コンペだったのではないかと思っています(Time-series APIを使用しなかったためリークはありましたが。。)。

Cは学習データと同様のデータが評価データに混入してしまう"リーク(Leakage)"と呼ばれる現象です。これが起きてしまうとモデル自体よりもLeakageを如何に活用するかを焦点として参加者がスコアを伸ばしてしまうのでコンペとしての面白みやホストの目的も形骸化してしまいます。

Dはあまり賞金ありコンペでは見られませんが、タスクがシンプルすぎる(出来ることがない)ためあまり学びのないコンペになりがちです。例えばよくplaygroundで設定されているflower classificationなどは特段やることがなく、アンサンブルゲー+運ゲーになってしまいがちです。

どうしたらクソ要因を減らせるのか?

それでは逆に良コンペの例を見てみましょう。

例えばatmacupでは運営が複数ベースラインを用意しある程度自らデータ解析を行いタスク難易度解析やスコア予測を行っていることが伺えます。

そのためこの段階で1)タスクに無理がないか?2)(すぐに見つかる)リークはないか?3)データ品質は適切か?といったパイプクリーニングを行うことができます。

このようにコンペを開く前にDSとデータ取得サイドで連携し、ある程度のベースラインを作ることでクソ要因の多くを取り除けるのではないかと思います。(言うは易し^^)

Shakeが大きいコンペがクソコンペか?

クソ要因Bの場合等、クソコンペでは大きいShakeが起きることがあります。一方でShakeが起きたからクソコンペ、という論調もたまにDiscussionでみますがケースによると思います。自分はShake要因が予想できたかどうか、というのが大きいと思います。例えば

  • 1 PublicとPrivate分布の違いが予め示唆されている、またはそれを解くのがコンペ目的の場合。(例:BengaliPANDAコンペ)
  • 2 そもそもPublicデータが少なく、trust CVが推奨される場合(例:OSICなど医療コンペに多い)

といった場合は大きなshakeが予想され、それへの対応も分析者の力量のうちとなります。

一方でタスク設計の不味さによってShakeが起きるとクソコンペ認定されるケースが多いのかと思ってます(例:Malwareタピオカコンペ)。

クソコンペを避けるには

クソコンペは傍から見ている分には面白いですが、真面目に参加すると痛い目に会います。そのため自分でクソコンペを察し回避することも重要となります。これらは経験などによって培われますが、どうしても初心者だが良コンペを掴みたい場合は

  • 1 Bestfitting特徴量
  • 2 金圏GM比率

などを見ると良いです。1についてですが、強い人はデータを見る嗅覚が発達しているのでヤバそうなコンペにはあまり参加しません。そのためKaggleRanking上位のBestfitting,Diter,Psi,Guanshuoが参加しているかをみてみると良いと思います。

2についてですが、強い方が参加しているのにも関わらずLBの金圏にほとんどGMがいないコンペはShakeが起きる可能性が大きいです。こちらはクソコンペとは限りませんが、耐shake体制を取りCVの切り方を注意深く見直す事が推奨されます。

KCY2021 グランプリ候補

ようやく本題のクソコンペオブザイヤーのグランプリ候補について述べます。

また繰り返しとなりますが、本記事ではクソコンペから教訓を得るのが目的であり順位付けなどはしません。そのため挙げるコンペの順番は順不同です。

Kaggle Cassava Leaf Disease Classification(タピオカコンペ)

f:id:aru47:20211212193736p:plain

www.kaggle.com

  • arutema参加: あり

アフリカの主要な農作物であるタピオカの病気を低画質スマホカメラ映像から判別可能なAIシステムを作るー社会的インパクトの極めて高いコンペ開催に参加者は盛り上がり、結果として3900チーム以上を集めた。タスクも単純で事前コンペも開催しているから品質も大丈夫なハズ、そう信じて多くのKagglerがGPUに火を付けた。

しかし何をやってもスコアが上がらない。そして音信のないホスト。混迷と迷走の3ヶ月の後に参加者に待っていたのは盛大なshakeであった。

f:id:aru47:20211212194756p:plain

クソ要因

データセットの品質(特にラベリング品質)がtrain/testともに低いのが厳しいコンペでした。

ベースラインモデルの混乱行列を見てみると

f:id:aru47:20211212195421p:plain

とclass:0(Cassava Bacterial Blight)とclass:4(健康)のクラスが異様に精度が低いのがわかります。

f:id:aru47:20211212195546p:plain

特にclass0と4は取り違えやすく、目で見てもほぼ健康にしか見えない画像が病気としてラベルされておりラベリング品質が低くかったです。 Trainがノイジーなのはともかく、Testのラベルもノイジーで低品質だと正常にモデル評価することは難しく、"俺は何をやらされているんだ?"感が強かったです。 (PublicとPrivateは相関していたことからPrivateラベル品質も同様に低かったかと思います)

教訓:ラベリング仕様について固めずにデータだけ取ってしまうと低品質なデータセットが出来上がってしまう。病気と健康を分ける定量的なクライテリアを用意し、ラベリング仕様として反映するべきだった。

Leak疑惑

www.kaggle.com

一位はPublic/Privateの完全優勝を達成しています。1位と2位参加者が精度向上のキーとして挙げていたのはTensorFlowHubにホストが上げていたCropNetというモデルであり、これをアンサンブルに加えることでスコアが大幅上昇したそうです。ノイジーなデータでこのようにモデル一つが効くことは怪しく、ホストはtestデータで学習したモデルをHubにアップロードしていたのでは?という疑惑が残りました。

RSNA-MICCAI Brain Tumor Radiogenomic Classification

f:id:aru47:20211212193827p:plain

www.kaggle.com

  • arutema参加:エアプ

RSNAコンペにクソコンペなしーそう言われるほどRSNA主催コンペは定評があり、今回もGunaxioとBestfittingが名勝負を繰り広げてくれると誰もが期待した。

しかし蓋を開けてみると早々にProbingによるLB崩壊、盛り上がらないディスカッションと暗雲が漂う。

俺達のRSNAならきっとどうにかしてくれる。。という願いも届かずPrivateは散々なshakeだった。

f:id:aru47:20211212200625p:plain

クソ要因

中の人変わった?という声も聞かれるくらい過去のRSNAとは打って変わった運ゲーのクソコンペであった。Discussionを見るとランダムで推論した方がEfficientNetより性能が出た*1CV,LB,PB全てが乖離していたと言う声があり、機械学習で解けるタスクだったかという根底が怪しく、ホストのベースライン作成が疎かだった可能性がある。1位のチーム名が"I hate this competition"だったことから闇の深さが伺える(なお順位確定後にI love this competitionに変わった)。

画像データを使ったレモンの外観分類(レモンコンペ)

f:id:aru47:20211212193915p:plain

signate.jp

我ら日本国が誇るコンペサイトSignateから通称レモンコンペが堂々のエントリーを果たした。

ルールにあるアンサンブル禁止令に若干の不安と炎上を挟みつつもレモンの品質等級検知という社会実装であり注目度も高く、賞品のレモン10kg欲しさに大勢の参加者が集まった。

しかし初日から評価指標がQuadratic WeightedKappaにも関わらず0.99を叩き出すぶっ壊れ具合と運営の明後日に向いた回答でTwitterは大荒れ。一夜にして時のコンペになった。

クソ要因

QWKで0.99..を出すのはいくら問題が簡単でも難しく、リークが原因だった。

リーク内容

配布されたデータは同一レモンを異なる角度で撮影したものが使い回されており、更に同じレモンがtrainとtestに跨って使用されており過度に精度が出る要因となった。また配布データ名も乱数化されておらず日時データのままだったため、ファイル名を降順に並べることでtestにおけるレモンのラベルをtrainデータから容易に類推することができた。(更に撮影時間でラベル情報を区切っていたため、レモンを見ずにファイル名から完璧にラベルを推定できることが参加者から報告された)

一方でこのようなリークは失敗事例であると同時にビジネス界では共有されない貴重なノウハウであると思います。ここまで詳しく書いているのもホストを叩く意味ではなく、事例から学ぶためです。

一度でもスタッフ側でベースラインを作っていたら予防できた事態なのではないか、と傍から見ていて思いました。また農作物といったデータは集めるのが大変なので少数データ収集→データ分析上問題ないかDSサイドでベースラインを作りリーク、タスク難易度確認→本格的にデータ収集といくつかのフェーズに分け収集側とDS側でコミュニケーションを取りつつプロジェクトを進めないと後々大変な事態になるな、とも感じました。

trainデータをtestに含めては行けないという原理原則、そしてデータセットの作成には気をつけないと大変なことになる等様々な酸っぱい教訓をレモンコンペは俺達に教えてくれました。

その後

結局trainデータはそのままに、testデータはリークをなくしたものを再収集しそちらで評価するという手はずになった。運営の対応は(初動はアレにせよ)誠実で他2つと比べ参加者とのコミュニケーションは取れていました。しかし等級分類よりもtrainに存在するリークを如何にして無くすかというのが高得点を取る主眼となってしまい、参加者が本質のタスクに集中できなかったため(また開催前に初歩的なリークを見破れなかった残念さもあり)KCYに入れました。

(追記:アップデートされたTestデータの色味が大幅に違ったようです。こちらのブログに詳しくまとまっております。)