Open GENZITSU opened 3 years ago
classification: timm detection: yolox, yet-another-efficientdet, adelaidet segmentation: semantic-segmentation.pytorch (tracking: fairmot, nofair) self-supervision: vissl metric learning: insightface, pytorch-metric-learning
知らないライブラリが結構ある。。
中身を見ていくと、yoloxはV100で100FPS近く出るっぽい。 そしてinsightfaceは顔検出から特徴抽出までできるっぽい
TabNetのわかりやすい説明スライド。 使う分にはpytorch_tabnetというものを使うのが簡単とのこと。 ただし、学習時間自体は勾配ブースティング系のほうが早い。
以下ピックアップ
わかりやすくて助かる。
Hydra + MLflowに加えて、Optunaを使ってハイパラ探索を行う方法の紹介。
Hydraを用いることで、ハイパラのファイル管理 + コマンドラインからの変更行うことができる。
コマンドライン変更に加えて、グリッドサーチも可能
グリッドサーチを行った際の評価の保存にはmlflowを用いる
さらに、ハイパラサーチを効率的に行うためにはoptuna用のプラグインを入れることができる。
hydraのoptuna用extension知らなかった。
定期的にtwitterのアカウント名を変更するgithub actionsの作成および、marketplaceでの効果までの手順が書かれている。
まずgithub actionsの作り方には3種類ある
この記事ではdockerfileベースの手法を用いており、書き方としてはAWS ECSで書くとき見たく、Dockerfile内で最後に起動させたいスクリプトを呼び出す形にしておけば良い。
起動に際して必要な環境変数たちはactionを管理するaction.ymlのinputsに入れておけば良い。
さらにはcronを仕込むことができ、定期実行させることもできる
cronまで使えるの知らなかった。完全無料でちょっとしたレンタルサーバー的なことができるようになるな笑。
ちなみにgithub 無料ユーザーでも500MB, 2000分までは無料みたい
ランダムシードがモデルの性能に与える影響がしらべらており、10**4オーダのシードで実験することでシードによって性能が上下することが確かめられている。
いわくシードによる差は確かにあり、明らかに最終的な到達性能が変わる
What is the distribution of scores with respect to the choice of seed? The distribution of accuracy when varying seeds is relatively pointy, which means that results are fairly concentrated around the mean. Once the model converged, this distribution is relatively stable which means that some seed are intrinsically better than others.
さらに2%程度ずれることもありこれは研究界隈で非常に大きな数値 Are there black swans, i.e., seeds that produce radically different results? Yes. On a scanning of 104seeds, we obtained a difference between the maximum and minimum accuracy close to 2% which is above the threshold commonly used by the computer vision community of what is considered significant.
データセットが大きくなると影響は小さくなるものの、それでも0.5%でかい。 Does pretraining on larger datasets mitigate variability induced by the choice of seed? It certainly reduces the variations due to using different seeds, but it does not mitigate it. On Imagenet, we found a difference between the maximum and the minimum accuracy of around 0.5%, which is commonly accepted as significant by the community for this dataset
やはり...
実務的には複数シードで結果を見る必要が出てくるのが辛いところかな...?
kaggle的にはseed averagingが肯定される結果になるんだろうか
鍵となるのがtqdmのpositionのところで、ここで表示する位置を制御することで、以下のような出力を得ている。
# from https://qiita.com/nkato_/items/9e2c75013d44050851ed
from time import sleep
import random
from tqdm import tqdm
from multiprocessing import Pool, freeze_support, RLock
L = 8
def long_time_process(p):
info = f'#{p:>2} ' # 進捗バーの左側に表示される文字列
for _ in tqdm(range(20), desc=info, position=p+1):
sleep(random.random())
return p * 2
if __name__ == '__main__':
freeze_support() # Windows のみ必要
with Pool(L,
# Windows のみ必要
initializer=tqdm.set_lock, initargs=(RLock(),)) as p:
result = p.map(long_time_process, range(L))
print("\n" * L) # tqdm終了後のカーソル位置を最下部に持ってくる
print(result)
知らんかった。
表題の通り。
収集したデータは以下。全てのパターンを網羅することはできないので、一部人工的に作成を行っている。
最終的に34パターンの抵抗について1400枚程度の画像を収集することが出来ましたが、それでも予測対象の抵抗は全部で1100パターンもあり、到底足りていないです。
データ水増しとして、収集できなかったカラーパターンを作成するために、別の抵抗から色だけ抽出して塗り絵的に貼り付けるということをしました。
使用したモデルはmobilenetv3-largeだが行くつか変更点も存在する。
torchvisionパッケージにあるMobileNetV3-largeバックボーンのFPNありFasterRCNNをそのままクラスラベル数を1100にして学習したわけでわなく、いくつか変更を加えています。
- fasterrcnnでは全ての全てのスケールのoutputに対して、同じサイズのアンカーボックスを割り当てていたが、スケールに応じて割り当てるアンカーボックスのサイズを変更
- 元々91個のclass logitを出力していた全結合層の出力は33個にした。最初の2つの出力がbackgroundかforegroundかを出力、次の10個の出力が1本目の色のlogit、次の10個の出力が2本目の色のlogit、最後の11個の出力が3本目の色のlogitに対応
- 元々のモデルではクラスごとに別々のbox regressionが割り当てられていたが、修正後は1つのbox regressionのみを使用
モデルはdynamic quantizationを行い軽量化を実施、torch scriptへの変換もおこなられており、相応に早くなっている。
簡単ですね。モデルの量子化によって元々79MBあったモデルのサイズを38MBまで減らすことが出来ました。
結果としては手元で集められなかった色については検出あ難しかった。
画像データを収集出来ず人工的な色の切り貼りによってごまかしたパターンの抵抗についての予測精度は正直期待していたレベルとは程遠く、正しい抵抗値が予測リストの中にさえ含まれていないということも結構あります。
色の順番さえ正しく検出できれば、抵抗値は100%正解できそうだけど、うまくいかなかったのだろうか。 ただしこれ上下反転した時ってどうなるんだろう、
frugally-deepとはC++でdeepなモデルを扱えるようにするライブラリで以下の特徴を持つ (一部のみ抜粋)
- モダンでピュアな C++ で書かれた小さなヘッダーのみのライブラリ
- TensorFlow の(小さな)サブセット、つまり予測をサポートするために必要な操作を再実装している
- TensorFlow をリンクするよりもはるかに小さいバイナリサイズ
- 32ビットの実行ファイルにコンパイルしても動作
- システムの中で最も強力な GPU を完全に無視し、予測ごとに1つのCPUコアしか使わない ;-)
二個目の記事ではMNISTがCPU推論で200FPSだそうだ。 C++やはり早い...
文法誤り修正用のデータは収集が難しいので人工的に作る方法が模索されている。
ラベルなしデータすべてが正しい文として考えて、その文に対して人工的に誤りを付与する方法です。 たとえばI am a student.といった文がラベルなしデータにあったとして、ランダムに文中の文字や単語に置換や挿入、削除の操作を行いI have a sudent.のような誤り文を作成します。 この例のように、この誤り文の作成方法では誤り文としても現実に存在しないものが生まれることが多いのですが、それでも、この擬似的な学習データを用いることで文法誤り訂正の精度が改善することが報告されています。
本物のデータの入出力をひっくり返して、訂正文を入力、誤り文を出力とした誤り生成モデルを学習し、そのモデルを用いてラベルなしデータの各文から対応する誤り文を作成する方法も存在します。 こちらの論文によると前述の人工的な誤り付与よりは、この誤り生成モデルを用いて作成した擬似的な学習データの方が文法誤り訂正の精度を向上させるとのことです。
まずはBreak it Fix itの方法を取る。この手法は教師なしで文修正用のデータの生成をおこなうもので以下の3コンポーネントに分かれる
手順は以下
ラベルなしデータから、人工誤りを利用しrw擬似学習データを作成し、それを用いてFixerを学習。同時に、Criticを用いてラベルなしデータの各文が文法的に正しいかを判別
誤りと判定されたものについてはFixerを用いて訂正を行い、その訂正文がCriticによって正しいと判断された場合、学習ペアとして登録してBreakerを学習
次はこの逆を行い、正しいと判定されたものをBreakerで誤り文にし、その誤り文がCriticによって誤っていると判断された場合、学習ペアとして登録してFixerを学習
後はこの無限ループ
この一連処理にはCriticの働きがとても重要なので、LM Criticでは個々に工夫を入えた
具体的にはGPT2を利用し、言語モデルのスコアを元に、入力された文の正誤を判定しました。 。
ある入力文に対して文字単位や単語単位の人工的なノイズを付与し、入力文についていくつかのバリエーション文を作成しました。 その後、入力文とそのバリエーション文すべてに対してGPT2を用いて文の確率を算出し、入力文の確率がもっとも高い場合は入力文が正しく、そうでない場合、入力文は誤っていると判定します。 この方法を用いた場合、正しい文の推定、誤り文の推定のどちらの場合でも閾値を用いた判定よりも高い精度を達成しました。
一番単純な方法は、入力された文に対してGPT2を用いてその文の確率を算出し、その確率が定めた閾値を超えた場合は正しい文、下回った場合は誤った文とすることです。 しかしながら、これは著者たちの事前実験ではうまくいかなかったとのことです。
ラベルなしデータに必要なテキスト量が気になるところ。 この手法自体はラベル有りとの併用ができるから嬉しい。
同じチームで様々な振り返り手法とそれを行った結果がまとめられている。
その他方法だけ載っているものも多数あった。
振り返り手法っていろいろあるんだなぁ。
上期が終わったところで、ちょっとやってみたいところ。特にtimeline
チーム間でことなるリージョンを使用していたことで、大陸間通信のか金額が莫大になってしまったようだ。
課金の表面的な事象はGCSの大陸間通信です。
今回、2人でLandmarkを取り組んでおり、TPUを中心に実施していました。 相方のGCPのインスタンスがヨーロッパ、私が格納していたデータのGCSのリージョンが北米にあったことにより、大陸間通信が膨大となり、課金されてしまったということです。 逆に言えば、チーム組む皆さんはきちんと認識を取りましょう。AWSのS3でも似たような課金体系だったはずです。
なぜリージョンが異なってしまったかというと以下
私のGCSがUSだったのは安いからです。また、チームメンバーがヨーロッパなのは、TRCのTPU無料枠を用いていたのですが、その無料枠は(その人が)使えるリージョンがヨーロッパに固定されていたためです。
リージョン間通信... 気をつけないと...
[元記事]()
マルチモーダルなデータセットは量と質のトレードオフの問題が従来からあった。
自動収集したデータは量が確保できるが質が低くなる。
一方で質を担保しようとすると量が確保できなくなり、英語以外のデータセットの構築が難しくなる。
そこでgoogleはwikipediaを利用して新たなマルチモーダルデータセットを作成した
データセットの内容は以下
データセットの質を上げるためには以下のことを行なっている
- text-based filtering to ensure caption availability, length and quality (e.g., by removing generic default filler text);
- image-based filtering to ensure each image is a certain size with permissible licensing;
- image-and-text-entity–based filtering to ensure suitability for research (e.g., excluding those classified as hate speech).
- We further randomly sampled image-caption sets for evaluation by human editors, who overwhelmingly agreed that 98% of the samples had good image-caption alignment.
論文の内容はこう
ラベルではなく様々なセマンティックな情報が書かれているので扱いが難しそうだ。
kaggleのコンペの取り組みは要注意かも。
巷のツイートでCPUで50FPSが出るという動画を拝見した。
もう少し見てみると、どうも横転した車も取れる精度らしい (参考)
そしてこのYOLOX、あのphalanxさんもよくつかっているライブラリらしい。(参考)
ということでYOLOXをすこし調べてみた。
まずはスピードと性能のトレードオフから
現在PwCでSOTAを総なめしているYOLORとは主戦場が違うように見える。とにかく鬼のように早いのに高性能。
こいつは一体なんなのか。
論文のタイトルは「YOLOX: Exceeding YOLO Series in 2021」ということで、YOLO系を超えたモデルということみたい。
モデルの構造は下記で、anchor freeとdecoupled headが大きな特徴のようだ。
decoupled headはclassificationとregressiionの矛盾に対応するためのもの
the conflict between classification and regression tasks is a well-known problem
この矛盾はRevisiting the Sibling Head in Object Detector @ CVPR2020という論文で詳しく詳説されている。
たしかにanchorがある構造にはデメリットが多い
First, to achieve optimal detection performance, one needs to conduct clustering analysis to determine a set of optimal anchors before training. Those clustered anchors are domain-specific and less generalized. Second, anchor mechanism increases the complexity of detection heads, as well as the number of predictions for each image. On some edge AI systems, moving such large amount of predictions between devices (e.g., from NPU to CPU) may become a potential bottleneck in terms of the overall latency.
またMosaicとMixupという強いaugmentaionを採用することで、もはやimagenet pretrainが必要なかったとも書かれている。
After using strong data augmentation, we found ImageNet pre-training is no more beneficial, we thus train all the following models from scratch.
他にもいろいろ工夫をしているがその分解表がこれ。精度上はstrong augmentationとmulti positive, SimOTAのゲインが大きいが、anchor freeは推論速度の向上に一役買っている。
このSimOTAというのはOTA: Optimal Transport Assignment for Object Detection @CVPR2021という論文で提案されたOTAという手法の簡略版。学習時間の短縮に一役買っているらしい。
難しくてよくわからないが、どうも物体のanchorを自動で正しく設定するための手法のよう。
multi positiveというのは、anchorを惜しいところまで予測できているものを救済することで学習を高速化させるための手法で不均衡是正の効果があるとのこと。
optimizing those high quality predictions may also bring beneficial gradients, which may alleviates the extreme imbalance of positive/negative sampling during training. We simply assigns the center 3×3 area as positives, also named “center sampling”
strong augmentationとmulti positiveというのは自前のモデルを作るときにも適用できる気がする。 こういう地道な積み重ねでとんでも精度なのに高速なモデルが生まれる技術の進歩に驚愕する。。。
MLP編に続く、CNN編。
結論から先に書くと、pytorchに比べて2枚程度高速に学習が回せるようになる。(32s → 13s)
CNNの定義自体は何の変哲もないが、btachnormの実装だけ一癖ある。
以下のように、batchnormは学習中は一つ前のbatchから引き継いだ統計量をもとに移動平均が計算される一方で、
推論時は学習データの統計量を使う必要がある。
# from https://zenn.dev/jellied_unagi/articles/70dbb7ce206c13
# x_in: 入力バッチ
# mean: 前バッチから引き継いでいる移動平均
# var: 前バッチから引き継いでいる移動分散
batch_mean = x_in.mean(0)
batch_var = x_in.var(0)
if is_training:
# 移動平均・分散の更新。momentum=慣性パラメタによって前バッチから引き継いでいる統計量の影響を残す
mean = momentum * mean + (1 - momentum) * batch_mean
var = momentum * var + (1 - momentum) * batch_var
else:
# 推論時は学習データの移動平均・分散を用いる
batch_mean = mean
batch_var = var
# 正規化。ゼロ除算を防ぐためにepsilonで下駄をはかせる
x_in_normed = (x_in - batch_mean) / jnp.sqrt(batch_var + epsilon)
# スケール・バイアスの適用
x_out = x_in_normed * scale + bias
これにより、以前のbatchの統計量の引継ぎ周りをマニュアルで書く必要がでてくる
# from https://zenn.dev/jellied_unagi/articles/70dbb7ce206c13
@partial(jax.jit, static_argnums=(4,))
def step(x, y, state, batch_stats, is_training=True):
def loss_fn(params, batch_stats):
y_pred, mutated_vars = state.apply_fn({"params": params, "batch_stats": batch_stats}, x, is_training, mutable=["batch_stats"])
new_batch_stats = mutated_vars["batch_stats"]
loss = optax.softmax_cross_entropy(logits=y_pred, labels=y).mean()
return loss, (y_pred, new_batch_stats)
y = jnp.eye(10)[y]
if is_training:
grad_fn = jax.value_and_grad(loss_fn, has_aux=True)
(loss, (y_pred, new_batch_stats)), grads = grad_fn(state.params, batch_stats)
state = state.apply_gradients(grads=grads)
else:
loss, (y_pred, new_batch_stats) = loss_fn(state.params, batch_stats)
return loss, y_pred, state, new_batch_stats
だいぶ早くなるな...。
jaxくるか...?
MoTがサービス提供しているドラレコからの地図情報更新サービスでAWS Batchがどのように活用されているかの紹介。
分散機械学習が必要になる理由はシンプル。高速な試行錯誤のため。
AWS Batchの概要
MoTで行われた工夫
Docker イメージのビルドに1時間もかかっているのは一体なぜ...?
あり得るのだろうか...
実行時間の短縮系
GPUがいらない処理をCPUに任せる策は失敗したとのこと
勉強になるなぁ。 MLエンジニアとしてはAWS Batchがあることを見越した実装を常日頃から考えておくのが重要かもしれない。
PASS: An ImageNet replacement for self-supervised pretraining without humans
プライバシーやライセンスの問題をクリーンにしてSSL回のImageNetになることを目指したデータセット。
全部で140万枚の画像があり、それら全てにライセンスが付与されているのが印象的。
Imagentと比べて以下のような特徴がある
こんな感じの画像が入っているらしい
さらにgithubではpassでSSLした重みも公開されている
人間やImagenet pretrainのモデルと遜色ない性能が出せるらしい
また以下の表をみると、人間が写っている画像がpretrainになくてもよいが、データの件数は大事っぽいことがわかる
コメント
はっきりとCCBYというライセンスで巨大データセットが公開されるのは嬉しい。
ファインチューニングする分にはimagenetと遜色ないのであれば多くの企業がこちらにのりかえるのでは...??
出典
元記事
元論文
データセットプレビュー
github