weekly useful materials -08/10-

[GENZITSU]

プログラミングをする上で大切なマインドセット

検討するべきこと

どういった力が必要か

• コーディングをしない際
  • 標準ライブラリをどれくらい知っているか、理解して使いこなせるか、また外部ライブラリを探す力というのも大切です。
• 既存コードを再利用する際
  • 何かを作るときは、なるべく汎用性の高いものを作る。
  • 何かを作るときは、わかりやすい場所に作る。共有する。管理する。
  • 以下のようなことを推測する力も役に立つ
    • このような関数はどこかに汎用化されているかもしれない
    • このような関数はこんな感じの名前で存在するかもしれない
    • このような関数はあの処理で使われているからそこにあるかもしれない
• 既存コードを抽象化・汎用化してから再利用する際
  • 他人が書いたものを読む力
  • 影響範囲を調べる力
  • 抽象化・汎用化できる力、およびそれをコーディングできる力
  • 品質を担保できる力
  • 業務ロジックの理解力

コメント

品質を高く保つためにも、この世界どんな実装があるかを把握しておくことが大事っぽい

出典

元記事

[GENZITSU]

Pythonで論文用のグラフ作った話

こんなこんな感じの綺麗なグラフを作れるスニペットの解説がなされている。

# from https://qiita.com/GoshBird/items/90ceaf29068d888aad64

from matplotlib import pyplot as plt
from matplotlib.ticker import ScalarFormatter
from pylab import *
import warnings

plt.rcParams["xtick.direction"] = "in"
plt.rcParams["ytick.direction"] = "in"

#graphs = [{"type":"yerror","x":[0,1,2],"y":[0,1,2],"xerr":[0.1,0.1,0.1],"yerr":[0.2,0.3,0.2],"marker":".","color":"tomato","label":"hoge","linestyle":"dashed"}]
#type -> "errory", "errorx", "errorxy", "plot", "scatter"
#range = {"xmax":10,"ymax":10, "xmin":0, "ymin":0}

def make_graph(graphs,xlabel,ylabel,range,fileName,legend=True,grid=True,show=False,capsize=3,xscale_log=False,yscale_log=False,dpi=300):
    fig,ax=plt.subplots(figsize=(7,4))

    for datas in graphs:
        if datas["type"] == "errory":
            ax.errorbar(datas["x"],datas["y"],yerr=datas["yerr"],marker=datas["marker"],color=datas["color"],label=datas["label"],capsize=capsize,linestyle=datas["linestyle"])
        elif datas["type"] == "errorx":
            ax.errorbar(datas["x"],datas["y"],xerr=datas["xerr"],marker=datas["marker"],color=datas["color"],label=datas["label"],capsize=capsize,linestyle=datas["linestyle"])
        elif datas["type"] == "errorxy":
            ax.errorbar(datas["x"],datas["y"],xerr=datas["xerr"],yerr=datas["yerr"],marker=datas["marker"],color=datas["color"],label=datas["label"],capsize=capsize,linestyle=datas["linestyle"])
        elif datas["type"] == "plot":
            ax.plot(datas["x"],datas["y"],marker=datas["marker"],color=datas["color"],label=datas["label"],linestyle=datas["linestyle"])
        elif datas["type"] == "scatter":
            ax.scatter(datas["x"],datas["y"],marker=datas["marker"],color=datas["color"],label=datas["label"])
        else:
            warnings.warn("wrong type")

    if xscale_log:
        ax.set_xscale("log")
    if yscale_log:
        ax.set_yscale("log")

    plt.xlabel(xlabel)
    plt.ylabel(ylabel)
    if legend:
        plt.legend()
    xmax, ymax, xmin, ymin = range["xmax"], range["ymax"], range["xmin"], range["ymin"]
    plt.xlim(xmin,xmax)
    plt.ylim(ymin,ymax)
    if grid:
        ax.grid(True)
        if not xscale_log:
            ax.xaxis.set_major_locator(MultipleLocator((xmax-xmin)/5))
            ax.xaxis.set_minor_locator(MultipleLocator((xmax-xmin)/25))
        if not yscale_log:
            ax.yaxis.set_major_locator(MultipleLocator((ymax-ymin)/5))
            ax.yaxis.set_minor_locator(MultipleLocator((ymax-ymin)/25))
            ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True))

    if show:
        plt.show()
    fileName += ".jpg"
    plt.savefig(fileName,format="jpg",dpi=dpi)
    print(f"saved as {fileName}")

コメント

PRJ共通のhelper,py的なものに置いておくと、便利そう

出典

元記事

[GENZITSU]

斧を砥ぐことの価値

ただただ至言である。

中長期の生産性は、今日の生産そのものより大事

そんなわけで生産性や能力に伸びしろがあり、中長期の成果を求められる場合、だいたいのケースでは「最初に斧を砥ぐ」ことが大きな力と意味を持ちます。 日々の仕事に追われてる…と感じるときは、いったん立ち止まって「斧を砥ぐ余地」がないかを考える。 たった1日手を止めて、マニュアルを作ったり、VBスクリプトを書いたり、チェックリストを作ったりするだけで、仕事の効率はビックリするほどあがる。

コメント

これの裏返しだけど、なんで今そんなに忙しいかっていうとそもそも斧が貧弱すぎるみたいな話もありそう

出典

元記事

[GENZITSU]

「仕事のコード」を残す際のチェックリスト

1. 構成管理

• そのコードの動作に必要なものについて、ひとつ残らず何処かに保管してありますか？

  • 必要なものは、コード自体だけではありません。設定項目、設定に使ったURL、発行したトークン、その他... 必要なものをピックアップして抜き出しましょう。

• そのコードは、Gitにより変更履歴が管理されていますか？

• 動作に必要なトークンなどは、専用のシークレットマネージャなどに別途保存されていますか？

  • トークンがコードの中に混ざっていませんか？
  • 混ざっている場合、最低でもダミーの表現にして、ドキュメントで「〜を置き換える」などのように書き残してください。

• ドキュメントも残していますか？

  • ドキュメントには、本チェックリストの次の項目以降で挙げるような内容を残しましょう。

2. デプロイメント

• そのコードをどこで動かしているか、書いていますか？

• そのコードを動かすようにするにはどうすればいいか、手順を必要な分だけ残らず残していますか？

  • コマンド一発でできなくても大丈夫です。ですが、必要に応じてちゃんと画面のキャプチャも含めたドキュメントを作りましょう。

• 動かすために必要な情報は揃って書かれていますか？

  • GASが紐づいているスプレッドシートのURLはどれですか？　また、必要な権限は誰に頼んだら得られますか？
  • 他のサービスを使っていたとして、デプロイしている先のサービスのアカウントはどうやったら作れますか？ 　 - APIトークンのようなものは必要ですか？　それはどこで保管していますか？　どうやって共有しますか？

3. 環境とテスト

• そのコードを試しに動かす方法は書かれていますか？

  • いわゆる本番環境に影響しない、自由にガチャガチャできるような環境は用意されていますか？　そこにアクセスする方法も、同じように残してください。 　- このコードは本番でしか動かない、試験時は空気を読んで設定を変えている、などの場合は... その設定の変え方も残してください。

• そのコードが、正しく動いていそうだ、と確認する方法は確立していますか？　そしてそれもドキュメントされていますか？

  • そもそもどういう風に動いていることを想定しているか、なるべく細かく残して置きましょう。 　- 上記のテスト環境で、こういう操作をしたら、こういう出力がされるはずです、という内容を押さえて残して置きます。

• そのコードを動かすための環境はどうやって作りますか？

  • 必要なソフトウェアをどうインストールするか、必要なアカウントをどうやって発行するか、その他必要な情報にどうたどり着くか、を一通りまとめておきます。

• 自動テストが添付されていれば、それを実行する方法も書いておきましょう。

4. その他

• コードを作った目的、背景もできるだけ書いておきましょう。

  • お仕事のシステムは誰かに引き継がれていきます。

• このコードが動かなくなるとどういう人たちに影響が出るか、わかる範囲で書かれていると助かります。

  • エンドユーザにまで影響が出るのか、30分の作業が1時間になるだけなのか、など。
  • 障害発生時に想定される影響範囲がわかると、変更を加える人がどれくらい慎重に行えばいいかの目安になります。

コメント

とてもためになるチェックリストだ...
そのコード群がなぜ存在するかは自明と言えば自明だけ、人と時が変わればそうでなくなるので残していかないと...

出典

元記事

[GENZITSU]

Obtaining Better Static Word Embeddings Using Contextual Embedding Models @ ACL2021

staticな単語ベクトルを学習する際に、通常は単語のベクトルと、周辺の単語ベクトルが似るように学習を行う。

通常の学習

SENT2VEcの場合

BERTを使うパターン 1

BERTを使うパターン 2

トレーニングの設定

結果

教師なし系データセットRG-65 以外では提案手法系が強い。
使用するBERTは何使ってもいい。

教師あり系データセット 流石にBERT系には負けるけど、static系には2~3%向上する。 ASEというのは Aggregated Static Embeddings の略で、異なるcontextに現れるwのpoolingをすることを言うらしい。

コメント

結構眉唾な論文だが、確かに静的なベクトルよりかは強いので、試す価値あるかもしれない。
もちろん、訓練時も推論時も計算資源が豊富な場合はこんなことやる必要ないけど、推論時の計算資源は押さえたい時に便利かも...?

出典

元論文

github

[GENZITSU]

Accumulated Local Effects（ALE）で機械学習モデルを解釈する

特徴量に相関がある場合に、Partial Dependence Plotがうまくいかない原因にふれ、そのような場合に使えるAccumulated Local Effectsについての解説がなされている。

以下のようにまとめられている

• PDは特徴量とモデルの予測値の関係を知ることができる有用な解釈手法だが、特徴量が強く相関する場合はあまりうまく機能しない。データには存在しない特徴量の組み合わせに対して無理やり予測した結果を利用することが原因（外挿問題）
• この問題を単純に回避しようとする手法にMarginal Plotがあるが、うまくいかない。Marginal Plotでは相関する特徴量の効果が混ざってしまう
• ALEは特徴量が強く相関する場合でも、（データが存在する範囲での）特徴量をとモデルの予測値の関係をうまく解釈することができる
• ALEはあくまで平均的な効果を解釈しており、インスタンスごとの解釈を行うことはできません。
  • インスタンスごとの解釈性が必要な場合はIndividual Conditional Expectation（ICE）を用いて解釈を行う必要があります。
• ALEはあくまでもある区間に含まれるインスタンスに対して特徴量が与える影響を累積であることにも注意が必要です。区間が離れていくごとにインスタンスの属性も異なっていくと考えられるので、ALEの解釈はあまり離れた部分に対して行うのではなく、できるだけ近い範囲で行うことが無難です

ALEのアイデア

• ALEは、Marginal Plotと同じく、特徴量Xjの値の範囲をいくつかのブロックに分割して、そこに含まれるインスタンスのみを対象にする手法 Marginal Plotはその区間での「平均的な予測値」に注目していましたが、ALEではその区間の両端での「予測値の差分」に注目します。

コメント

ALEというものを初めて知った。 各インスタンスに対する予測みたいなのはできないので、そこは紹介されているICEというものを使わないとダメっぽい。

出典

元記事

検証に用いられたコード

[GENZITSU]

量子計算による顔認証が大きく向上、マスク着用でも可能に—中国

本源量子チームが独自に研究開発した量子機械学習フレームワーク「VQNet」に基づき設計した量子敵対的生成ネットワーク（QGAN）は、人の顔の修復などの画像処理に用いることができる。

研究開発者はQGANを使い、画像修復面の応用例を実現した。量子コンピュータの敵対的生成ネットワークが人の顔修復分野で従来のコンピュータより速度と空間における優位性を示し、超伝導量子ビット技術に基づく量子機械学習の学習の実現可能性を証明

分かりやすく言えば、マスク着用時に顔認証が必要な保安検査を通過する場合、量子計算に基づくこのアルゴリズムがビッグデータ解析と画像修復を総合すれば、マスクに隠された顔の部分も認識できる

コメント

ぼちぼち量子機械学習とかいうのも勉強しないといけないのかもしれない。

出典

元記事

[GENZITSU]

Kaggle「CommonLit Readability Prize」コンペ25位の振り返りと上位解法まとめ

コンペの概要

英語の文章の「読みやすさ」の値を-3から3程度の範囲（大きいほど読みやすい）で予測する問題でした。 正解の値は、2つの文章の比較結果を利用する「Bradley–Terry model」で付けられていたそうです 値を予測する回帰問題で、評価指標はRMSEでした。

全体共通の傾向

• roberta-largeなどの言語モデルを複数利用しアンサンブル
• dropoutを除外することで性能が向上したという報告が目立った
• 直近で日本では「回帰問題でニューラルネットワークを使う場合にdropoutは避けるべき」という記事が話題になっていた
• hidden_dropout_probなども含めて消していた事例も

その他目についたもの

1位解法

• 外部データを利用
  • sentence bertを用いて、学習用データセットの各サンプルについて、最も類似している外部データ5件を追加データとして利用。roberta-baseとroberta-largeのアンサンブルで擬似ラベルを付与

加えて、外部データに対した擬似ラベルデータの学習の後に、オリジナルのデータでの学習もしていた模様

この解放には元ネタがある模様で、 ①少量のデータ+外部データ(似ている文章を引っ張ってきて、擬似ラベルを付与する)を用いたBertの学習手法の提案Augmented SBERT: Data Augmentation Method for Improving Bi-Encoders for Pairwise Sentence Scoring Tasks@NAACL 2021 ②こちらも大規模外部データに擬似ラベルを付与してモデルを学習させる手法Self-training Improves Pre-training for Natural Language Understanding

ちなみに[multipel noisy student](Self-training with Noisy Student improves ImageNet classification)は試してみたもののうまくいかなかったらしい。
また、文章間の類似度を特徴量とした回帰も効果があったとのこと。

3位解法

foldを切りながら、外部データに擬似ラベルを付与

その他の技

what worked:

• 3 group decaying lr for encoder
• simple attention head
• separate lr for head
• multi-sample dropout
• weighted average of hidden layers
• early stop
• fold specific pseudo-label
• Deberta-large

5位解法

学習用データセットは文章のテーマに沿って並んでいたので、シャッフルしないKFoldを意図的に使って、ジャンルの異なる記事への汎用性を確認

加えて、dropoutを用いるとtrain()とeval()でのパフォーマンスが変わることを知り、train()を用いた推論を行ったとのこと。

その他の技

Other hyper-parameters that worked for me

• Adamw 5 epochs
• cosine learning rate scheduler
• change learning rate exponentially across layers
• re-initialize some layers
• gradient accumulation for larger batch size
• linear head followed by mean pooling on last hidden state

6位解法

9個のモデルと、第2段階のガウス過程回帰

擬似ラベルによる学習もしていたが、OOF embeddingをconcatしたベクトルで行ったガウス過程回帰が特徴的だった

9位解法

• データ数が少ないので、交差検証の分割数を増やすと良いという仮説を立て、実験結果もその通りだった
  • (K=5,10,15,25) を試し、最終的には25を利用

12位解法

外部データを使ってpretrainし、コンペデータでfinetuning pretrainではMLMに加えて擬似ラベルを用いた事前学習を行なっていた

その他のテクとして注目すべきなのが、

• re-initialization top N layers of pre-trained model. N=5
  • worked a lot
  • https://arxiv.org/abs/2006.05987

コメント

コンペの解法読みはとても勉強になる。
外部データを使った擬似ラベルを用いた事例としてかなり参考になるコンペだと思われる。

出典

元記事

[GENZITSU]

Pythonで学ぶ音声合成 (Text-to-speech with Python)の付属ライブラリ

ttslearnという音声合成用ライブラリが公開された。

このライブラリにはWavenetやTacotoronなどの学習済みモデルが入っており、簡単に試すことができる。

Tacotoron 2のモデルはかなり精度が高いので、そのまま流用しても違和感ないかもしれない。

コメント

音声合成全くやってことないので、環境構築とかめんどくさそうと思っていたが、めちゃくちゃ簡単なライブラリが登場していた。

出典

元記事

github

デモページ

[GENZITSU]

医療検索における婉曲表現変換

専門用語を知らないユーザーが記述する症状を正確な病名に紐づけるため データ構築方法が提案されている。

クエリ→ラベル(病名)ではなく、ラベル(病名) + 動画 → クエリをクラウドソーシングすることでデータを構築する。

コメント

データセットの構築方法が面白かった。

出典

元記事

元論文(SIGIR 14)

[GENZITSU]

Kaggleで学んだBERTをfine-tuningする際のTips①〜学習効率化編〜

BERTの学習を効率化させるためのテクとその効果などがまとめられている。

混合精度(Mixed Precision)の利用

百度とNVIDIAが発表したMixed Precision Trainingという論文で、いくつか工夫を加えることで、半分の 16 ビットの半精度浮動小数点数 (FP16) でも、モデルの正確度をほぼ落とすことなく、トレーニングを高速化できることが示されました

FP16 で学習することができれば、必要なメモリは半分になるため、大きなバッチサイズを使うことができます

加えて最新のGPUにはTensorコアというものが導入されており、単純な演算速度の向上も見込める

pytorchはversion 1.6からデフォルトで混合精度の学習をサポートしています

文章の切り詰め方

How to Fine-Tune BERT for Text Classification? という論文には、重要な情報は文章の最初と最後に現れることが多いので、文章を切り詰める際に先頭と末尾を利用することを提案しており、実際の文書分類のタスクで単純に先頭や末尾のみを切り取った場合とくらべて良い精度が出せていることを示しています

うまく文章を切り詰めれば、タスクにもよると思いますが、トークン数を制限してメモリを削減しつつ精度を担保することが期待できます

# from https://www.ai-shift.co.jp/techblog/2138

MAX_LEN　# トークンの最大数(デフォルト512)
TOKENIZER # モデルに合わせたTokenizer

def cut_head_and_tail(text):
    # まずは限界を設定せずにトークナイズする
    input_ids = TOKENIZER.encode(text)
    n_token = len(input_ids)

    # トークン数が最大数と同じ場合
    if n_token == MAX_LEN:
        input_ids = input_ids
        attention_mask = [1 for _ in range(MAX_LEN)]
        token_type_ids = [1 for _ in range(MAX_LEN)]
    # トークン数が最大数より少ない場合
    elif n_token < MAX_LEN:
        pad = [1 for _ in range(config.MAX_LEN-n_token)]
        input_ids = input_ids + pad
        attention_mask = [1 if n_token > i else 0 for i in range(MAX_LEN)]
        token_type_ids = [1 if n_token > i else 0 for i in range(MAX_LEN)]
    # トークン数が最大数より多い場合
    else:
        harf_len = (MAX_LEN-2)//2
        _input_ids = input_ids[1:-1]
        input_ids = [0]+ _input_ids[:harf_len] + _input_ids[-harf_len:] + [2]
        attention_mask = [1 for _ in range(MAX_LEN)]
        token_type_ids = [1 for _ in range(MAX_LEN)]

    d = {
        "input_ids": torch.tensor(input_ids, dtype=torch.long),
        "attention_mask": torch.tensor(attention_mask, dtype=torch.long),
        "token_type_ids": torch.tensor(token_type_ids, dtype=torch.long),
    }

    return d

Uniform Length Batching

データセット全体で長さを合わせてpaddingをするのではなく、バッチごとに動的にpaddingを行うことで、メモリの節約をするテク

この手法の懸念点として、バッチごとのバリエーションが少なくなってしまうので、学習が不安定になってしまうことがあるので注意してください

勾配累積(Gradient Accumulation)

小さいバッチで計算した重みを保存しておき、複数回分ためてから平均を取り、それを用いてモデルのパラメータを更新する

# from https://www.ai-shift.co.jp/techblog/2138

ITERS_TO_ACCUMULATE # 累積数

for epoch in epochs:
    for i, (input, target) in enumerate(data):

        output = model(input)
        loss = loss_fn(output, target)
        loss = loss / iters_to_accumulate
        loss.backward()

        if (i + 1) % ITERS_TO_ACCUMULATE == 0:
            optimizer.step()
            optimizer.zero_grad()

コメント

文章の切り詰め方のテクニックは知らなかった。
gradient accumulationの実装も知らなかったけど、意外と単純で驚いた。

出典

元記事

[GENZITSU]

Handling Temporal Query for Health Search with ja-timex

最近公開されたja-timexをelasticsearchを用いた時間情報を考慮した検索

コメント

時間情報を構造化して取り込むこむことが可能なja-timexかなり便利そうだ

出典

元記事

[GENZITSU]

フェンシング剣の軌跡、AIと4Kカメラで捕まえた　“ライトセーバー”みたいな可視化技術、約5年間の開発秘話

東京五輪のフェンシング競技で採用された同技術では、マーカーを使わない手法でほぼリアルタイムでの可視化に成功している。

実現のカギは、24台の4KカメラとAIのディープラーニング（深層学習）を使った、画像解析技術

2選手の両サイドに12台ずつカメラを配置し、死角が生まれないよう上下のアングルから動画を撮影。1フレームごとに切り出した画像から、AIが剣先の位置を特定し、その動きをトラッキング。リアルタイムでARと合成し、可視化しているという。

マーカーを剣先につける場合は2014年でもトラッキング可能だったが、マーカーレスは困難だった

14年のエキシビションマッチで、招致映像と同様の取り組みを観客に披露したが、当時は剣先にマーカーを装着して可視化を実現した。

OpenCVを使った検出には限界があったとのこと

可視化するには、まず剣先を捕捉しなければならない。そこで花井さんは画像解析に着目。画像の明るさの情報を使い、剣先を検出するという原始的な画像解析のアルゴリズムを試したが「使い物にならなかった」という。 17年頃に花井さんの周囲で深層学習がプチブームに。既に、オープンソースの画像処理ライブラリ「OpenCV」などを使い「できることは全てやっていた」と花井さん。

深層学習アプローチによりマーカー無しの剣のトラッキングが可能になった、

深層学習という新たなアプローチを採用した花井さん。剣先の検出という点では一歩前進したが、当時の手法では軌跡の合成に必要な精度が出なかった。 　そこで、翌18年には使用する物体認識のアルゴリズムを変更。トラッキングするエリアも中央部分に限定したところ、単純な動きのみではあるが、ようやくマーカーレスとリアルタイムの可視化に成功した。

剣先は細かいので、解像度を落とした検出はできないので、剣全体→剣先の2段階検出を行っている。

フェンシングの剣は細く、よく曲がるため、通常の物体よりも検出が難しい。競技特性を踏まえて“フェンシング仕様”にカスタマイズし、2段階構成で剣先を検出する仕組みにシフトした。 具体的には4K画像から剣全体を切り出した上で、剣先を検出することで4Kの解像度を失うことなく、リアルタイムで正確に、剣の動きをトラッキングできるという。 当初は剣先のみを検出する手法だったが「リサイズした小さい画像から一発で剣先のみを見つけるのは難しい」と花井さん。4K画像をリアルタイムで分析するには時間がかかるため、解像度を下げなければならないという、ハードウェア側の技術的な制約も、検出方法を変更した一因だ

ある程度実現可能性が見えたところで、大々的にデータを拡充して学習。その際にはCGのデータも使った。

フェンシング協会の全面協力の下、12人の選手の動きを複数の照明条件で撮影した20万枚以上の静止画からなるデータセットを新たに作成。あらゆる条件を想定した100万枚以上のCGのデータセットも作成し、AIに学習させた結果、実戦で使えるような水準でのマーカーレスでの検出方法を確立した。

現在の技術だと照明環境などはかなりシビアに調整しているようだ

花井さんはシステムの導入には「カメラの設置場所や照明など会場の条件がシビア」と話す。カメラのシャッタースピードを限界まで下げて撮影しており、照明が少しでも暗くなると解析対象の画像も暗くなることから、24台のカメラも正確な場所に配置しなければならない。このため、会場責任者や主催者との綿密な事前調整が必須だ。

コメント

フェンシングの剣を高速に検出するのは意外と難しそう。
フェンシングの剣は曲がったりするので、剣全体をbboxで囲もうとするとかなり広がってしまう気がする。
そうなると検査機の誤検出の可能性も増えるので、工夫がいろいろ必要そうだ。

出典

元記事

[GENZITSU]

AIやデータサイエンスへの投資効果をどのように考えるべきか？

ROIを計算するのが難しい理由

1. データ収集・統合・整形のコストが不確実 データの保管・メンテナンスの状況は各社で全く違います。顧客や業務に関するデータを細部まで収集し、活用しやすいように整理できている企業も多くありますが、ITの多くを外注しており自社にノウハウが少なく、自社でどんなデータの保管の仕方をしているかを把握しきれていない企業もあります。 データの保管状態とプロジェクトの目的によって、データに関するコストを見積もるのがかなり難しい

2. どのくらい効果が表出するか見積もることが難しい ROIを計算するにあたり問題になるのが、KPIをどの程度改善させられるかが、やってみないとわからない

3. メンテナンスコストもわからない 一旦、予測モデルやダッシュボードを作ったとしても、その後はメンテナンスをし続けなくてはなりません。特に予測モデルは定期的に更新していくことが多い

このようにやってみないとわからないことが多いので、簡単かつ小さく始められるところからやるのが定石なのだが、どこかで大規模な投資を行い競争優位性や顧客への新たな価値提供へ舵を切らないといけなくなる。 その時の投資への正当性については以下の論点がある。

AIやデータサイエンスへの投資をどのように正当性を示したら良いか？

投資の正当性を考えるためには、AIやデータサイエンスをどのように自社の競争力へ結びつけていくかというビジョンが重要になってきます。そのビジョンとは新しい提供価値や新しいビジネスモデル、さらに新しい組織のあり方といった将来のありたき姿です。

1. 誰にどのような価値を届けるのか？ 顧客への価値には以下の3タイプがある
   1. コストバリュー: 無料または超低価格といった価格面での価値
   2. エクスペリエンスバリュー: カスタマイズや自動化による体験価値
   3. プラットフォームバリュー: コミュニティ化やエコシステム化といったネットワークされることによる「場」の価値

2.価値を実現するために必要なデータは何か？ そのまま。

3.誰がデータを活用するのか？ 描いたビジョンを実現するにあたり、ごく一部の人材がデータを活用すれば良いのか、全社員がデータを活用する必要があるのかによって、組織のあり方や、教育の方法が変わります。

長期的なビジョンの流れの中に、個別PJTがある

上記のような視点で、中長期のビジョンを描き、その上で、一番簡単に手を付けられるプロジェクトから始めていきます。つまり、各個別のプロジェクトは、長期ビジョンを実現するためのステップである

コメント

個別PJTのROI計算はある程度できそうだけど、会社の長期的なROIの計算(投資判断におけるROI)を描くのはわからないことも多いので難しそう。
誰にどのような価値をみたいなところを突き詰めていくと自ずと見えていくものなんだろうか？

出典

元記事

[GENZITSU]

JTubeSpeech: Corpus of Japanese speech collected from YouTube

This repository provides 1) a list of YouTube videos with Japanese subtitles (JTubeSpeech) 2) scripts for making new lists of new languages 3) tiny lists for other languages.

データの形式はCSV形式でyoutubeのリンクが納められている。

ちなみに日本語は10,000時間分の動画があるとのこと

コメント

自分でyoutubeのリンクを集めることもできそうだけど、10,000時間分ともなるとさすがに時間がかかるのありがたい。 動画カテゴリの分布が少し気になる。

出典

元記事

[GENZITSU]

大規模なユーザーとアイテムに対して逐次学習アルゴリズムを利用

アイテム/ユーザー数が多く、かつ新アイテムが多いとのことで、逐次的に行列分解を行っている。

数千万のユーザー、アイテムを扱いつつ、さらにユーザー、アイテムを頻繁に追加したいのですが、この手法では追加の度にすべてを学習し直す必要があります。そこで逐次学習アルゴリズムを利用します

しかし、この方法は元論文との問題設定の違いからうまくいかなかったとのこと、
そこで、いくつかの工夫を行ったとのこと。

原因は恐らく、問題設定の違いにあります。元の論文では多数のユーザーかつ少数のアイテムを対象としていますが、今回は多数のアイテムに対応するため、いくつか変更を行いました。

ただしナイーブにやると、大半のペアを興味ありと予測してしまう問題が

一方で、未評価の組み合わせでは大部分を「興味あり」と予測していました。つまり、単純にすべてを「興味あり」と学習してしまっていました。学習が適切であれば未評価の大部分を「興味なし」と予測するはずなので、これでは問題がありました。

これに対応するためにネガティブサンプリングを加えたとのこと。
ただし、高速化のために、本当にネガティブかどうかは判定しなかった模様。

プラスアルファとしてチャンク(つまり日)を跨いだ学習行うことで、ユーザー/アイテムペアのカバー率を上げたとのこと。
ここではチャンクの重み付けサンプリングで表現している。

実行環境は以下

CPU、16コアぐらいで、メモリが100GBちょっとのサーバーで動かしています。

コメント

やってること自体はネガティブサンプリング付きの行列分解だが、ユーザーとアイテム数が膨大故の苦労がありそうだ。

出典

元記事

[GENZITSU]

テスラの「完全自動運転をAIチームディレクターが解説」を翻訳とともに解説

テスラのカメラオンリー自動運転とその学習エコシステムについての紹介 (CVPR2021の基調講演の翻訳)

アメリカでは現在、主にテスラの従業員で構成される2000人のベータテスターにより、FSD Betaと呼ばれる、完全自動運転により近い運転支援システムのテストが行われている

カメラオンリーという選択肢

Google系列のWaymoや、最近自動運転Lv 3を達成したホンダ・レジェンドなど、他メーカーの多くがLiDARを採用

今年の4月27日以降に製造されたアメリカ向けのモデル3およびYはレーダーすら搭載されておらず、先述のFSD Betaもたとえレーダー搭載車であってもレーダーを利用していません。 理由としては、レーダーなど他のセンサー類はカメラと比べて情報量が少なすぎること、そしてカメラだけだとセンサーフュージョンをしなくてよいためコンピューターの処理能力を全て画像処理に回せることを挙げています。

学習エコシステム

学習させたモデルを全世界で走っている車でバックグラウンドで推論させ、人間の操作との解離をデータとして収集している。

テスラには世界中でオートパイロット機能を備えた車が100万台以上走行しており、合計で約80億km分のオートパイロット走行のデータにアクセスできるため、生データの量には困っていません。

Waymoの自動運転走行データは2009年から累計で2000万kmしかありません。その多くをエンジニアに給料を払って運転させて収集させている一方で、テスラは400倍のデータをオーナーから無料で収集できている

こううして得たデータをユーザーの車に配信し、自動運転には関与させずに裏で実行し）、ドライバーとコンピューターで判断が異なった場合は、そのデータを吸い上げて改善に役立てるというループを繰り返します。

これによって完成したデータセットは、AIにとって判断が難しいシナリオが100万通り、距離や速度が正確にラベリングされたオブジェクトが60億個、データ量にして1.5ペタバイト（1500テラバイト）にのぼります。

カメラオンリーの成果

1, 急ブレーキをかける車への対応
カメラを用いることで、減速が自然になる

走車が急減速すると、オレンジ線がガクガクしていることが分かります。これは減速が急すぎて前走車があたかもレーダーから消え、また現れて、を繰り返しているように車には見えるため、自車の減速が不十分になります。一方で青い線は途切れることなく前走車との距離や速度、加速度を捉え続けているため、安定して減速することができます。

2. ファントムブレーキ
   カメラでは障害物の誤検知が少ない

   ファントムブレーキとはオートパイロットで走行中に、例えば高速道路で橋をくぐる際に車が障害物だと認識して一瞬急ブレーキを踏む現象

ファントムブレーキは、レーダーとカメラの両方を使っていることに起因します。 レーダーは縦方向の分解能力があまりないため、高架道路をくぐる手前で陸橋が頭上にあるのか、衝突コースにあるのか判断しづらいのです。そこにカメラがデタラメな距離情報を瞬間的に吐き出すと、コンピューターはレーダーとカメラの間違った情報を結びつけて、前方に何かあると勘違いします。

テスラビジョンではカメラの測距精度が高く、高架道路に衝突しないことも画像から明白なため、ファントムブレーキは発生しません。下図のグラフは先ほどと同じ色分けですが、青い線はグラフに急激な変化がなく、オレンジ線は幻影（ファントム）を誤認識していることが分かります。

3. 本当の障害物への対応
   カメラだと障害物の認識が遅れないので、減速がスムーズ。

   レーダーとは常に些細なことでも「前方に障害物が！」と警告を出してきます。そのため、自動運転コンピューターはカメラ信号の中に、本当にそれに対応する障害物がないかを探し続けます。この時、カメラが前方のトラックを認識するのに時間がかかると、下図のグラフのように、オレンジ線の山の立ち上がりが遅れます（＝ブレーキが遅れます）。 テスラビジョンでは180m手前から徐々に減速を開始し、145m手前ではっきりとトラックを認識して一貫したブレーキングを行います。

コメント

学習エコシステムが完成されているのがすごい。
バッググラウンドでの推論と人間の操作を見比べるアプローチはかなり筋が良さそう。

出典

元記事

元動画

[GENZITSU]

Hundreds of AI tools have been built to catch covid. None of them helped.

たくさんのcovid-19用AIツールが開発されたが、役に立つものは一つもなかったどころか有害なものもあった。

In the end, many hundreds of predictive tools were developed. None of them made a real difference, and some were potentially harmful.

Wynants is lead author of one of them, a review in the British Medical Journal 232 algorithms for diagnosing patients or predicting how sick those with the disease might get. They found that none of them were fit for clinical use.

Derek Driggs, a machine-learning researcher at the University of Cambridge, and his colleagues, They looked at 415 published tools and, like Wynants and her colleagues, concluded that none were fit for clinical use.

What went wrong

ひところで言えばデータの品質が悪いことに尽きるが、これはコロナ禍の緊急対応が故でもある。

the poor quality of the data that researchers used to develop their tools. Many tools were built using mislabeled data or data from unknown sources.

データセットが乱立している事による、重複が思わぬリーケージを生んでいるケースも報告されている

Frankenstein data sets, which are spliced together from multiple sources and can contain duplicates.

子供の症例がないことから、子供はconvidではないと学習するケースも

Many unwittingly used a data set that contained chest scans of children who did not have covid as their examples of what non-covid cases looked like. But as a result, the AIs learned to identify kids, not covid.

病院側が埋め込んだフォントを鍵に判断していたケースも

In yet other cases, some AIs were found to be picking up on the text font that certain hospitals used to label the scans.

レントゲンを撮った医師のバイアスが載ることも

any medical scans were labeled according to whether the radiologists who created them said they showed covid.

このようなバイアスがあるにもかかわらず、提供されているAIツールに対してはバイアスが載っているかどうかを確認する術がないことが問題

several published models from researchers tied to this company, all of them with a high risk of bias. “We don’t actually know what the company implemented,” she says.

How to fix it

1. 実務家との協業が必要

   The simplest move would be for AI teams to collaborate more with clinicians

2. 成果を急ぐより手堅い改善を

   most researchers rushed to develop their own models, rather than working together or improving existing ones. The result was that the collective effort of researchers around the world produced hundreds of mediocre tools, The models are so similar—they almost all use the same techniques with minor tweaks, the same inputs—and they all make the same mistakes

3. データの統一化

   Getting hold of data would also be easier if formats were standardized the World Health Organization is considering an emergency data-sharing contract that would kick in during international health crises. It would let researchers move data across borders more easily,

コメント

セクシーな問題を解く前にアンセクシーな問題に手をつけなければ、全く同じ問題を繰り返すだけになるという最後の言葉が重い。
自分が用いているデータにどのような問題がありそうかを常に意識することが大事。

出典

元記事

[GENZITSU]

「長さの近いデータを同じbatchに入れる」の性能劣化と速度

Uniform Length Batching と呼ばれるテクニックを実際に試していた記事があった。
jigsawコンペのデータにて検証を行い以下のような結果を得ている。

評価指標はAUC

ちなみにこのデータの文字数の分布はこんな感じで、かなりばらつきがある模様
https://www.kaggle.com/kabure/simple-eda-hard-views-w-easy-code

ちなみに推論の時も文章長でソートすることで早くできる。

推論時にもデータのソートを実施したところ、推論時間が58min -> 25min に短縮されました。

コメント

文章長のバラツキに対しての速度向上ゲインがどのようなものかはわからないが、メリットの方がかなり大きそうな手法に見える。
なんなら前半epochはuniform length batchingして後半ランダムだったり、uniformとランダムを数epochずつ入れ替えるとかの手法もありそう。

出典

元記事

[GENZITSU]

Deep One-Class Classificationに基づく外れ値検知を実装した（PyTorch）

Deep SVDDをPyOD形式に実装した記事。 記事中にはDeepSVDDの論文や解説スライドの記事も纏まっている。

大まかな動かし方は以下

# from https://tam5917.hatenablog.com/entry/2021/08/16/200142

    # train one_class_svm detector
    clf_name = 'DeepSVDD'
    clf = DeepSVDD(hidden_neurons=[256, 128], output_dim=64, batch_size=256)
    clf.fit(X_train)

    # get the prediction labels and outlier scores of the training data
    y_train_pred = clf.labels_  # binary labels (0: inliers, 1: outliers)
    y_train_scores = clf.decision_scores_  # raw outlier scores

    # get the prediction on the test data
    y_test_pred = clf.predict(X_test)  # outlier labels (0 or 1)
    y_test_scores = clf.decision_function(X_test)  # outlier scores

    # evaluate and print the results
    print("\nOn Training Data:")
    evaluate_print(clf_name, y_train, y_train_scores)
    print("\nOn Test Data:")
    evaluate_print(clf_name, y_test, y_test_scores)

コメント

PyODに沿った形式で実装しておくと、取り回しが楽になって良さげ。

出典

元記事

[GENZITSU]

「顧客の声を聞かない」とはどういうことか

特に重要なスライドを抜粋

コメント

金言しかない。 全部で10Pしかないので、元スライドを読みましょう。

出典

元記事

[GENZITSU]

コアラから犬、熊まで——。動物にも応用される「顔認証技術」

1: 機械学習がコアラを救う

コアラが道路を横断する行動習性の理解を深め、横断の予測を行う オーストラリアのグリフィス大学では、コアラの外見と動きから個体識別する顔認証技術を開発

道路を横断するコアラをカメラが捉えると、その画像が同大学のサーバーに転送され、コンピューターと機械学習システムがコアラの個体を識別します。この方法により、どのコアラが動物用に設けられた地下道や橋を渡るかを観測する

2: 犬の識別というより監視社会の拡大？

中国の都市部では、ペットの糞を道路にそのまま残した場合、飼い主に罰金が科されるそう。そんな公共衛生の取り締まりに利用されているのが、犬の顔認証技術です。

犬の鼻にあるシワは「鼻紋」と呼ばれ、犬によりその形や長さが異なるため、人間の指紋と同じように個体識別に使うことができます。 中国のスタートアップが、異なるアングルから撮影した犬の鼻の画像をもとに、AIが個体識別する技術を開発。これまでに登録されている鼻紋を95％の高い精度で識別する

3: ディープラーニングで熊を識別

カナダのビクトリア大学は熊専用の顔認証技術「BearID」を開発。 熊の画像数千枚を使って深層学習を行うことで、84％の精度でクマの個体識別ができるようになった 熊は、成長したり季節が変わったりすると顔が変化しますが、この顔認証技術はそんな変化にも対応できるように進化していく計画

コメント

いろんな動物用の個体識別AIが出てきていて面白かった。
データセットの作成方法が肝になるような気もする。

出典

[元記事]()