weekly useful materials - 10/12 -

[GENZITSU]

pandas str.containsについて

引数によってnaの処理や大文字小文字の区別を制御できるようだ。

# from https://qiita.com/qiitaro_019475/items/1cc57625bbe63999c0b4

# na:False NaNがある行をFalseとして扱います
result = df1[df1['A'].str.contains('1',na = False)]

# case:False 大文字小文字を区別しない
result = df2[df2['A'].str.contains('a[1|0]',case = False)]

コメント

知らなかったことについてメモ

出典

元記事

[GENZITSU]

[Python] tenacity ライブラリを利用してリトライ処理を簡単に実装する

デコレーターでリトライ処理の実装を簡単に行えるようにするライブラリの紹介。

以下のようなことがデコレーターの引数ベースで実装できる

• リトライの上限設定
• リトライする上限時間の設定
• リトライ間隔の設定
  • 固定時間
  • 指数関数的に増加
• 特定のエラーのときだけリトライ
• 特定の返り値のときだけリトライ
• リトライ前後にログを仕込む
• リトライ制限に達した時だけ実行する関数を仕込む

コード例

# from https://qiita.com/engineer-taro/items/39cec5e6119c89c8bb32

from time import time
from tenacity import retry, wait_exponential

t = time()

@retry(wait=wait_exponential(multiplier=1, min=3, max=50))
def wait_exponential_sample():
    c = time()
    print(int(c-t))
    print('retry')
    raise Exception

# from https://qiita.com/engineer-taro/items/39cec5e6119c89c8bb32

from tenacity import retry, retry_if_exception_type

@retry(retry=retry_if_exception_type((TypeError, IndexError)))
def retry_if_exception_sample():
    print('retry')
    raise TypeError # 指定した例外なのでリトライする

retry_if_exception_sample()

コメント

めっちゃ便利そう。
ここら辺のリトライ処理は自分で描こうと思えば書けるがコードが汚くなりがちなので、 綺麗に整理できる方が大事な気がする。

出典

元記事

github

[GENZITSU]

PYTORCH PERFORMANCE TUNING GUIDE 2021

NVIDAからGTC2021で紹介されたトレーニング改善tipsのまとめ

新しく知ったやつだけメモ

Batchnorm前のCNNのBiasをオフにする

.zero_grad()を使わない

torch.jitを用いて複数演算をひとまとめにする

各種サイズを8の倍数にする

cudnn.benchmarkをTrueにする

指定デバイス上でtensorを生成する

cpu ⇄ gpuの転送を避ける

コメント

gradientの初期化の部分どんくらい変わるんだろうか？実験してみたい。

出典

元記事

torchのガイド

[GENZITSU]

2021 10-07 kdd2021読み会 uc phrase

教師なしでキーフレーズ抽出手法の紹介。
キーワードではなくキーフレーズなのがポイントっぽいが、文中に二回出てくるフレーズをシルバーラベルとするのが一番大事な気がする。

コメント

attention mapを画像として入力する愛では面白い。ただ、BERTでもそのまま行けそうな気がするんだけどなぁ。

出典

[元記事]()

[GENZITSU]

【NLP】医療系タスクに使える自然言語処理モデル一覧

haggingfaceで使用可能なモデルが紹介されている。

• BioELECTRA(2021):
• SapBERT(2021):
• Umls BERT (2021):
• RoBERTa-base-PM(2020)

今回のコンペでは事前学習手法の改良手法であるSapBERTをPubmedBERTに適用したものがダントツで高精度だったらしい

SapBERTはNAACL2021で発表された事前学習モデルの改善手法です。Umlsデータセットをもとに同音異義語や単語の表記ゆれなどを改善することにより精度改善につながったようです。今回のコンペではSapBERTを適用したPubmedBERTがCV、PublicLBともにダントツで優秀でした。（LBが微妙だったため提出できなかったのが悔やまれる）

コメント

メモ

出典

元記事

[GENZITSU]

This repository is in violation of YOLOv5 GPL 3.0 License #765

yoloxにyolov5のライセンス継承違反があったとのこと。 yolov5はGPL3.0で公開されているが、yolov5と同じ関数がyoloxにあるにもかかわらず、apach 2.0で公開されているとのこと。

コメント

今後の修正対応に期待。

出典

元記事

[GENZITSU]

HTTP cats

httpのレスポンスコードとそれに対応する猫画像がまとめられている。

コメント

可愛い

出典

元記事

[GENZITSU]

過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】

1. 目的と手段がごっちゃになってない？

要件定義は「顧客が現在抱えている問題（要件の背景）」と「本来あるべき理想の姿（業務要件）」を明確にするフェーズです。

2.業務フローは明確になってる？

業務フローを作る上で、注意すべき・よく指摘されたポイントは以下になります。 　・各業務フローの開始条件・終了条件が明確になっているか。 　・アクター間でやりとりが発生する場合の連絡手段・連携手段が明確になっているか。 　・機能化する部分と運用（手作業）で対応する部分が明確になっているか。 　・業務フローの粒度は適切か。

3.リリース後の運用のことも検討してある？

業務フローで明確にした「運用で対応する作業」についての設計（手順書・チェックシートの作成等）をする必要があります。

4.制約条件と前提条件の区別できてる？

制約条件：変更できない条件のことです。 前提条件：プロジェクトを進めていくにあたって仮決めした条件のことです。

前提条件は自分たちで仮決めした条件なので、顧客と必ず合意を取る必要があります。

また制約条件と前提条件を明確にしておくことが後々、プロジェクトが遅延した際などに役に立ちます。 制約条件はマストなので必ず達成しないといけませんが、前提条件は仮決めした条件なので交渉次第で何とかできる可能性があるためです。

5.プロジェクトが成功するかは要件定義にかかってる。

プロジェクトの失敗原因の約7割は、要件定義が不十分なことだと言われています。

コメント

制約条件と前提条件を区別することは確かに大事そう。
制約だとおもってめちゃくちゃ頑張っても、実は交渉次第でなんとかできるところかもしれないし。
運用フローをしっかり意識しないと結局使えないものになるのはそれはそうだろうなぁ。

出典

元記事

[GENZITSU]

sklearn.model_selection.TimeSeriesSplit

時系列用のCV foldを作ってくれるsklearnの関数

# from https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html#sklearn-model-selection-timeseriessplit

TimeSeriesSplit(gap=0, max_train_size=None, n_splits=5, test_size=None)
>>> for train_index, test_index in tscv.split(X):
...     print("TRAIN:", train_index, "TEST:", test_index)
...     X_train, X_test = X[train_index], X[test_index]
...     y_train, y_test = y[train_index], y[test_index]
TRAIN: [0] TEST: [1]
TRAIN: [0 1] TEST: [2]
TRAIN: [0 1 2] TEST: [3]
TRAIN: [0 1 2 3] TEST: [4]
TRAIN: [0 1 2 3 4] TEST: [5]

# from https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html#sklearn-model-selection-timeseriessplit

>>> # Add in a 2 period gap
>>> tscv = TimeSeriesSplit(n_splits=3, test_size=2, gap=2)
>>> for train_index, test_index in tscv.split(X):
...    print("TRAIN:", train_index, "TEST:", test_index)
...    X_train, X_test = X[train_index], X[test_index]
...    y_train, y_test = y[train_index], y[test_index]
TRAIN: [0 1 2 3] TEST: [6 7]
TRAIN: [0 1 2 3 4 5] TEST: [8 9]
TRAIN: [0 1 2 3 4 5 6 7] TEST: [10 11]

コメント

めっちゃ便利そう。

出典

元記事

[GENZITSU]

文字単位BERTかサブワードBERTか問題

発端となった論文: How Good is Your Tokenizer? On the Monolingual Performance of Multilingual Language Models

単言語BERTは多言語BERTよりも性能が高い傾向にあるが、それを学習させたtokenizerのせいであるとした論文。 多言語BERTのtokenizerを単言語用のものに取り替え，embeddingのみ再学習するだけで性能が上がることを確認したとのこと

この論文では日本語用に文字単位tokenizerを使っていたことが物議を醸した。

一連のツイートでは

、やはり文字単位よりもサブワード単位の方がよさそう。論文には「NERで予備実験をしたところ文字単位の方がよかった」と書かれているが、これは使われたデータが文字単位でラベルがついているからで、そのままサブワードを適用すると約2ポイント精度が下がる。

論文の他のタスク(以下)だと、文または単語単位でラベルがついていて、それだと予想通り、サブワード単位の方が文字単位よりも一貫して、少しいい〜それなりにいい、という結果になった。

• Sentiment Analysis (文単位)
• Dependency Parsing (単語単位)
• POS Tagging (単語単位)

単語分割のように文字単位のモデルを使わざるを得ないタスクを除いては、サブワード単位のモデルを使えばいいはず。 タスクによっては文字とサブワード単位の精度がほぼ同じであることはあるが、サブワード単位の方がトークン数が減って学習・推論時間が短くなるのでよい。

コメント

とりあえずサブワードを使っておいた方がよいっぽい。

出典

元記事

[GENZITSU]

ガートナーのテクノロジーハイプサイクル 2021が公開された。

1. 責任あるAI

AI技術の信頼や透明性、公平性、可監査性の向上が、幅広いステークホルダーにとってますます重要になっている。データにバイアスがかかっていたとしても公平性を実現し、透明性や説明可能性を実現する方法が進化していったとしても信頼を獲得し、AIの確率的な性質に対処しながら規制順守を確保するために責任あるAIが役立つ

Gartnerは2023年までに、AIの開発やトレーニングのために採用される人員は全て、責任あるAIに関する専門知識と経験を要求されるようになると予想

スモールデータとワイドデータのアプローチ

スモールデータとワイドデータのアプローチは、より強力な分析とAIを実現し、組織のビッグデータへの依存を低減し、より適切で包括的な状況認識を可能にする。

AIプラットフォームの運用化

『AIオーケストレーションと自動化プラットフォーム』（AIOAPs）や、『モデルの運用化』（ModelOps）のようなイノベーションは、AIの再利用性やスケーラビリティ、ガバナンスを実現し、AIの導入と発展を加速させる」

データ、モデル、コンピュートリソースの効率利用

AIの展開に関わるデータやモデル、コンピュートリソースの複雑さと規模の大きさを考えると、AIイノベーションでは、こうしたリソースを最大限効率的に利用する必要がある。

コメント

synthetic dataも結構トレンドになりつつあるな。 cvが幻滅期に入ったのは本当なんだろうか...?

出典

日本語記事

元記事

[GENZITSU]

Approximate Vector Search at Scale, With Application to Image Search - SciPY JP 2020

画像のindexingには画像を特徴量化してfaissを用いている。

既存のindexingサービスは異なる更新周期のサービスが乱立していたが、メンテが大変なので1時間更新の統一的なindexingサービスに代替することにした。

そのためには、アップデートの時間を1時間以内に収めるという課題と、重複画像を削除するという課題があった。

更新時間を収めるためには、faiassのmerge_from()を使うことで短縮化ができた。

重複画像の削除に関しては、従来はvectorから類似indexを探す方法をとっていたが、非効率的なので、indexから重複を検索できるfaiassのfind_duplicates()を使用することで、高速化を実現した。

コメント

faiassには便利な関数が揃っているんだなぁ。

出典

元記事

[GENZITSU]

実在しない顔の画像3000点を無償配布、AI学習用データセットに　法人向け・商用利用可

エイアイ・フィールドが自社の技術で自動生成した、実在しない10代～90代の男女の画像を提供。APTOが作成した年齢・性別などのアノテーションも付属する。申し込みは専用サイトで受け付ける。

　もともとはエイアイ・フィールドが自社サービスで活用するために作成した画像だったが、6月に用途を研究目的に限った上で1000点を無料配布したところ、利用者からの反響があったことから、データを2000点追加し、商用利用を認めた上で再配布することを決めたという。

コメント

GANか何かを使って生成した画像データを配布している？
これを学習データにつかって何か悪影響はないものだろうか？

出典

元記事

[GENZITSU]

Fake It Till You Make It: Face analysis in the wild using synthetic data alone (ICCV 2021)

CGで作成した顔画像だけでモデルを学習させることで、リアルデータに肉薄する精度を達成したとのこと。 いままでCGとリアルデータの間のドメインギャップをつなぐためにさまざまなテクが提案されていたが、単純にCG技術を向上させることで、ギャップを減らした模様。

Researchers have tried to bridge this gap with data mixing, domain adaptation, and domain-adversarial training, but we show that it is possible to synthesize data with minimal domain gap, so that models trained on synthetic data generalize to real in-the-wild datasets.

データセットには100,000件の画像が含まれており、非商用限定だけど公開予定。

CGベースなので、ピクセルレベルの詳細なアノテーションをすることが可能。

このCGの作り方は以下

• templateの顔を用意
• identityをランダムに付与
• 表情をランダムに付与
• ランダムなテクスチャーを付与
• ランダムな髪を付与
• ランダムな服を付与
• ランダムな環境をCyclesを用いてレンダリングする

Starting with our template face, we randomize the identity, choose a random expression, apply a random texture, and attach random hair and clothing. We finally render the face in a random environment using Cycles: a physically-based path tracing renderer

CGデータを用いているのでデータのバイアスをなくすことができ、多様性(人種 / 年齢 / 性別)に配慮したモデルを作成することができる。

一応リアルデータとの比較

コメント

CGデータのモデリングをコードベースで実行できるようになると、無限にデータを作り出せるようになるからすごい。
単純なモデリング技術の向上でドメインギャップの提言ができるというのも面白い。 (広い意味でいうルールベースに該当するのかもしれない。)

出典

元記事

元論文

[GENZITSU]

How to Analyze 100-Dimensional Data with UMAP in Breathtakingly Beautiful Ways

UMAPの使い方やパラメータチューニングの方法が詳しく書かれている。

大事なパラメータは以下の4つ

• n_components
• n_neighbors
• min_dist
• metric

またumapはメモリ消費量がかなり大きいので、low_memoryというパラメータをTrueにするのと、numpy配列はできるだけ省メモリな型にするべきと書かれている。

The documentation suggests setting low_memory to True as a possible fix. Additionally, I recommend reducing the memory usage of the dataset by casting each column to the smallest subtype possible using NumPy.

コメント

メモリ消費量でかいのしらなかった。次からはちゃんと型をdown castしておきたい。

出典

[元記事]()

[GENZITSU]

scikit-learn 1.0 リリース！更新内容を一部紹介します。

sklearnが1.0になったということで、大きい更新内容が紹介されている。

1. 1. キーワード引数の強制

sklearnは位置引数が多用されていたが、キーワード引数をつかないといけなくなる。 これはコードが見やすくなるのでとても良さそう。

# from https://scikit-learn.org/stable/auto_examples/release_highlights/plot_release_highlights_1_0_0.html

HistGradientBoostingRegressor(
    loss="squared_error",
    learning_rate=0.1,
    max_iter=100,
    max_leaf_nodes=31,
    max_depth=None,
    min_samples_leaf=20,
    l2_regularization=0.0,
    max_bins=255,
    categorical_features=None,
    monotonic_cst=None,
    warm_start=False,
    early_stopping="auto",
    scoring="loss",
    validation_fraction=0.1,
    n_iter_no_change=10,
    tol=1e-7,
    verbose=0,
    random_state=None,
)

2. pandasのデータフレームからの特徴量名のサポート

特徴量エンジニアリングや前処理を行う関数に対して、.get_feature_names_out()というメソッドが新たに追加。 これにより、特徴量名を手動で書かずに済むようになる。

# from https://scikit-learn.org/stable/auto_examples/release_highlights/plot_release_highlights_1_0_0.html

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import OneHotEncoder
import pandas as pd

X = pd.DataFrame({"pet": ["dog", "cat", "fish"], "age": [3, 7, 1]})
preprocessor = ColumnTransformer(
    [
        ("numerical", StandardScaler(), ["age"]),
        ("categorical", OneHotEncoder(), ["pet"]),
    ],
    verbose_feature_names_out=False,
).fit(X)

preprocessor.get_feature_names_out()

>> array(['age', 'pet_cat', 'pet_dog', 'pet_fish'], dtype=object)

3. 新しいplot用のクラス追加

rocカーブや混同行列を書くメソッドが変わり、ConfusionMatrixDisplay、PrecisionRecallDisplayなどのクラスに変更される。

sklearn.metricsモジュールのplot_confusion_matrixやplot_roccurveが使えましたが、scikit-lean 1.0からは非推奨になり、1.2では削除の予定とのことです。代わりにConfusionMatrixDisplay、PrecisionRecallDisplayといったクラスが追加されました。元のplot*関数はestimatorが引数に必要だったのですが、from_predictionsメソッドを使うことにより、ラベルと予測した値を渡せば描画ができるようになりました。

使い方としてはこう

# from https://scikit-learn.org/stable/auto_examples/release_highlights/plot_release_highlights_1_0_0.html

clf = SVC(random_state=0)
clf.fit(X_train, y_train)
SVC(random_state=0)
y_pred = clf.predict(X_test)
ConfusionMatrixDisplay.from_predictions(y_test, y_pred)

4. StratifiedGroupKFoldの追加

StratifiedKflodとGroupKFoldを同時に実施できるクラスが実装された。

コメント

キーワード引数が強制されるのはとても良い。.get_feature_namesも嬉しい。

出典

元記事

sklearnのリリースノート

[GENZITSU]

augmentationは終盤かけない方がいいらしい

出典に挙げた二つの論文ではaugmentationを途中で解除した方が良いことが述べられている。

参考ツイート①

Data AugmentationやL2正則化は、途中で解除したら学習が高速化される上に精度が上がる（少なくとも下がらない）のは、この論文でも言ってたなぁ。個人的には、解除する適切なタイミングは終盤だけじゃなくて、割と序盤に解除したほうが効果的な場合もあるのが面白かった。

参考ツイート②

ちなみにこの論文はもっと面白い事を言っていて、最初はdata augmentationを使って学習するが、後半になったら元データセットだけで学習する方が精度が良くなると言う。

コメント

論文リンク用にメモ

出典

参考論文①

[参考論文②](Data Augmentation Revisited: Rethinking the Distribution Gap between Clean and Augmented Data)

[GENZITSU]

なぜリベラルの声は中間層に届かないのか？

1億2千万件を超える安倍元首相に関するツイート（「安倍」または「アベ」が含まれるツイート）を解析し，保守派のツイートの方がリベラル派のツイートよりも穏健な中間層によく届いていることを明らかにしました．

保守派のツイートは23.23%が中間層によって拡散されているのに対し，リベラル派のツイートは6.46%が中間層によって拡散されていることが分かり，保守派のツイートを中間層が拡散する割合はリベラル派のそれと比較して約3.6倍多いことがわかりました．

保守派の方がリベラル派よりも中間層からのフォローを返報しやすく，保守派が中間層をフォローした場合の方がリベラル派よりも中間層からフォローの返報を受けやすいことが明らかになりました．

社会ネットワーク的に言えば，保守派の方がリベラル派よりも中間層と相互に接続されメッセージが届きやすくなっていることを意味します．

保守派，リベラル派，中間層で比較すると口語的な形容詞の使用が最も類似しているのは保守派とリベラル派だが，保守派の方が中間層と似ていることがわかりました．

コメント

こういう切り口の分析面白いな。
保守派とリベラル派で中間層に対するフォロバ率が違うのも、派閥による特性違いが見れて面白い。

出典

元記事

[GENZITSU]

Operationalizing machine learning in processes

McKinseyから出ている、MLを運用に入れるためのプロセスの提案。

Step 1. Create economies of scale and skill

ビジネスオペレーションは多様なセクターをまたぐことが普通だが、MLの自動化をの1プロセスにしか適用されないことが多い。
しかしこれは間違いで、本来はビジネスプロセス全体をより自動化できるようにデザインすべき。

Because processes often span multiple business units, individual teams often focus on using ML to automate only steps they control. That, we find, is usually a mistake.

Rather than seeking to apply ML to individual steps in a process, companies can design processes that are more automated end to end.

Step 2. Assess capability needs and development methods

企業がMLを導入する際には3つの方法がある。
自作する、platformerのツールを使って作成する、適所的なソリューションを取り入れる。

それぞれpros/consがあるが

Step 3. Give models ‘on the job’ training

MLの開発ファーズは通常3つに分かれる。

• 変更が容易にできる開発環境
• テスト環境
• 商用環境

Typically, deployments span three distinct, and sequential, environments: the developer environment, where systems are built and can be easily modified; a test environment (also known as user-acceptance testing, or UAT), where users can test system functionalities but the system can’t be modified; and, finally, the production environment, where the system is live and available at scale to end users.

どの環境のデータでも学習は可能だが最も好ましいのはプロダクション環境。
このプロダクション環境のデータを使って学習することを job trainingと評している。
これを実現するためには、初期にhuman in the loopのアプローチを取ることが良いと例示されている。 実際にとある企業ではこのアプローチをとることで、3ヶ月足らずで自動化率40%→80%まで向上したとのこと。

To deal with this challenge, some leading organizations design the process in a way that allows a human review of ML model outputs The model-development team sets a threshold of certainty for each decision and enables the machine to handle the process with full autonomy in any situation that exceeds that threshold. This human-in-the-loop approach gradually enabled a healthcare company to raise the accuracy of its model so that within three months, the proportion of cases resolved via straight-through processing rose from less than 40 percent to more than 80 percent.

ちなみに業界によってはプロダクション環境からデータを外に出すことすら難しく、学習フェーズに十分なデータを集められないこともあるのでこのアプローチがよいのだとか。

Step 4. Standardize ML projects for deployment and scalability

MLOpsなどの機械学習モデルを安定的にデプロイするための標準化が必要と述べられていた。

モデルデプロイの標準化に加えて、MLパイプラインの影響を受けるメンバーの配慮が必要になる。
彼らの日々のオペレショーンにMLが組み込まれるのを許容できるようなコミュニケーションやスキル開発が必要になってくる。

正しいマインドセット

データは多ければ多いほど良い

• The more data, the better. Unlike rule-based automation, which is highly centered around processes, ML is data-centric.

実行する前にどのようにスケールさせていくかの戦略を練る

Plan before doing. Because the ML journey contains so many challenges, it is essential to break it down into manageable steps. Think about archetypical use cases, development methods, and understand which capabilities are needed and how to scale them.

個別最適ではなく、全体最適を目指す。

Think end to end. It’s important to reimagine entire processes from beginning to end, redesigning the process in a way that’s more conducive to how machines and people work together.

コメント

end2endを想定したソリューションを考えるのが大事というのはわかるが、それができる立場は限られるような気がする。
とはいえ個別最適すぎるソリューションを作ることに終始していないかは常に意識しておいた方がよいかも。

それと最初の段階はhuman in the loopを前提にMLモデルをデプロイするon the job trainingというアプローチはABEJAも謳っていたような気がする。(参考)
こちらの発表資料では、精度が出ない状態でも限定的にでも効果出るフローを確立することで、PoC期間を伸ばしながら、AIの精度向上に不可欠なデータを貯めることができるのでおすすめとされていた。
on th job trainingというアプローチがいいのはわかるけど、費用対効果とか関係者調整が死ぬほど大変そう。
そこまでして効果が出なかった時がやばいので、効果が出そうなビジョンが描けるような領域じゃないと厳しいだろうなぁ。

出典

元記事

[GENZITSU]

ResNet strikes back: An improved training procedure in timm

ResNet50の学習方法を工夫することで、imagenetでの精度を75%→80%まで引き上げたという報告。

一番の注目点としては、一つの画像に複数のクラスが入っていることを考慮し、損失関数をcross entropyからBinary Cross Entropyを用いたところだろうか。

Noticeably, we depart from the usual cross-entropy loss. Instead, our training solves a multi-classification problem when using Mixup and CutMix: we minimize the binary cross entropy for each concept selected by these augmentations, assuming that all the mixed concepts are present in the synthetized image.

使用されたテクニックは以下の表にまとめられている。

以下、知らなかったテクニックだけまとめていく

LAMB

optimizerの一種らしく、こちらの記事が詳しかった

曰く、

大規模なミニバッチの場合、同じ時間をかけても、ミニバッチサイズが小さいときよりもtotalのepoch数が少なくなります。それを補うために単純に学習率を大きくすると、今度は高すぎる学習率で訓練が安定しづらいという問題が発生します。

そこで、学習率に“trust ratio”と呼ばれる、勾配に応じた係数をかける手法がLARS（Layerwise Adaptive Rate Scaling）です。

また、LAMB（Layer-wise Adaptive Moments optimizer for Batch training）は、LARSに各ウェイトパラメータの1epochごとの変化の速度も考慮した最適化手法となります。

LAMBを使うことで、通常81時間かかるBERTの学習を、76分と、100倍程度高速化できます。

元論文はLarge Batch Optimization for Deep Learning: Training BERT in 76 minutes @ICLR2020

計算式は以下のようになる。 見ればわかるがLARSがmomentum SGDの派生系で、LAMBがADAMの派生系。

repeated aug

元論文はMultiGrain: a unified image embedding for classes and instancesで、以下のような記載がある。

In RA we form an image batch B by sampling d|B|/me different images from the dataset, and transform them up to m times by a set of data augmentations to fill the batch. Thus, the instance level ground-truth yij = +1 iff images i and j are two augmented versions of the same training image. The key difference with the standard sampling scheme in SGD is that samples are not independent, as augmented versions of the same image are highly correlated. While this strategy reduces the performance if the batch size is small, for larger batch sizes RA outperforms the standard i.i.d. scheme – while using the same batch size and learning rate for both schemes. This is different from the observation of [19], who also consider repeated samples in a batch, but simultaneously increase the size of the latter.

すなわち、ミニバッチ (Batchsize N)を構成する際に、N/m個のみの画像をサンプリングし、それらの画像に対してm回augmentationをかけてバッチを埋めるという手法。
この手法はバッチサイズが大きい時やデータセットが巨大な時に有効なスキームのようで、対象のデータセットがaugmentationに対して常に不変の出力を出すことを強制しやすいのだとか。

コメント

LAMBもRepeated augmentaionもデータセット/バッチサイズが大きい時用の手法のようなので、縁遠いテクニックかもしれない。
しかし、LARSもLAMBもなぜ勾配を計算する際に、x(t)が出てくるのだろうか...

出典

元記事

[GENZITSU]

Pillow(PIL)で生成するgifの画質を上げる

pillowでgif画像を作るときに画質劣化が起きる時は、画像をあらかじめ.quantize()しておくのが良いとのこと。

# from https://qiita.com/Mechanetai/items/4ec988a463fe649a52f9

from PIL import Image

im1 = Image.open("gohan1.jpg").quantize()
im2 = Image.open("gohan2.jpg").quantize()
im3 = Image.open("gohan3.jpg").quantize()
images = [im1, im2, im3]
images[0].save('test2.gif', save_all=True,
               append_images=images[1:], optimize=False, duration=800, loop=0)

.quantize()にはオプションが3種あるようなので、gifにする前にどれが良いかを可視化しておくのが良さそう。

• メジアンカット(option=0)
• maximum coverage
• fast octree

コメント

自分でgif化した時に、画質劣化がかなり目についていたのでこれは助かる。
事前に減色しておくことで、画質劣化を低減することができるとは。

出典

元記事

[GENZITSU]

東大、様々な体形や姿勢に対応するバーチャル試着を開発　深層学習用いて

東京大学は8日、深層学習の技術を用いて、様々な体形や姿勢に応じたオンライン試着ができる手法を開発したと発表した。

今回の研究は、東京大学大学院情報理工学系研究科の五十嵐健夫研究室が実施。深層学習に必要な訓練データを大量に自動取得するために、姿勢や体形を自動制御できるロボットマネキンも同時に開発した。

利用者が計測用の衣服を着て深度センサ付きカメラの前に立つと、商品の衣服を着た画像がリアルタイムで高品質に生成される。

コメント

ロボットマネキンでデータを作成するという、もはやCGを通り越したアプローチが面白いw
深度センサー付きカメラの前に立たないといけないので、ecサイトとかでの使用はちょと難しいかもしれない。

出典

元記事

[GENZITSU]

【製造DX】なぜAIは“再現不可能”を攻略できたのか

少子高齢化によるオペレータの現象やそもそもの制御の難しさから化学プラントをAIによって制御するというPRJが、NTTコミニュケーションズと横河ソリューションサービスの二社協業という形で2017年から始まった。

NTTコムの伊藤さんは言う。 というのもAIやシステムの開発を担当する企業が、導入先の業務に対して高い専門性を発揮するのは難しかったり、ビジネス的な信用の欠如からデータのやり取りも難しいからだ。

AIを現場に導入してもらうには、「BtoBtoX」の座組みは不可欠です。 化学プラントといっても、石油やゴムなどさまざまで、そのすべてにおいてNTT Comが専門性を持つのは難しい。 高い専門性を持つミドルB、その顧客である事業会社Xの協力がなければ、AIの導き出した結果が妥当かどうかも判断できません。 AIに不可欠なプラントの運転データは、私どもがいきなり現場に出かけていって預けていただけるようなものではありません。 これまでNTTグループと接点のなかった化学メーカーから貴重なデータを提供いただけたり、我々のAIを実際にプラント操業の現場で使ってみてくださったりするのは、YJPと化学メーカーの関係あってこそです。

当初は蒸留塔の反応をシミュレータ上で再現するデジタルツインのアプローチをとって、プラント制御を行うアプローチをとっていたが、反応塔という別のパイプラインだと全く使えなかったという。

蒸留塔で起こる化学反応は割とシンプルで規則性を見出しやすかった。ところが反応塔の内部の化学反応は、想像以上に複雑だったんです。

そこで、両者は模倣学習によりオペレータの操作をAIが模倣できるようなアプローチをとることにした。 この開発に関しては、現場のオペレータのノウハウがふんだんに盛り込まれていたようだ。

伊藤　たとえばオペレーターの方々が、どんなポイントをどのタイミングで見ているか、ですね。実際に操作をせずに済む場合もあるので、ここはデータだけでは見えてきません。 たびたび現場にお邪魔してヒアリングさせてもらい、その結果を持ち帰ってはAIに組み込むことを繰り返しました。

コメント

BtoBtoXという座組みの組み方は面白い。 部署間同士の小さい案件だと、導入部門が十分専門性をもっていたり信頼関係があるからよいので、仲介を取り持つBはおそらく入らないかもしれないが、案件がデカくなればなるほど、専門的な業界知識を持つ仲介業者の存在が必要になるかもしれない。

出典

元記事

[GENZITSU]

How to Train Large Deep Learning Models as a Startup

startup企業いかにして、巨大な音声認識AIを作ったかという記事。

イテレーション高速化に寄与したこと

• より多くのGPUを用いる
• GPU間のコミュニケーションコストを下げる
  • Horovod is a great library that helps you get a lot more efficiency as you add more GPUs to your training clusters.
• Train with lower precision

モデルの学習を低コストに実施するためには

• Buy your own hardware
• Dedicated cloud servers
• これは自前でカスタマイズ可能なクラウドサーバーのことのようだ

コメント

本格的なモデル開発をすることになったらクラウドでの学習は逆にコスパが悪くなることを肝に銘じておきたい。

出典

元記事