GENZITSU / UsefulMaterials

34 stars 0 forks source link

weekly useful materials -06/29- #58

Open GENZITSU opened 3 years ago

GENZITSU commented 3 years ago

GBDTのハイパーパラメータの意味を図で理解しつつチューニングを学ぶ

GBDTのパラメータを視覚的に理解する記事。 個人的に気になった箇所

num_leaves (max_leaves)

葉(ノード)の最大数。大きいほど複雑になるが過学習につながる。複雑さに直結するので最重要かもしれない 例えば、下図では葉が6つあるのでnum_leavesを5以下にすると木の形が変わる。

最大ノード数の7割にしたい場合max_leaves = int(0.7 * 2 ** max_depth)のように指定したりする

確かにダイナミックに形が変わる。

明示的にX割にしたい局面ってあるんだろうか...?(素人並感)

最重要なパラメータtop3

min_data_in_leaf num_leaves max_depth

計算速度を上げるには?

リソースを増やす

num_threadsで並列計算をするスレッド数を増やせる。

分割の負担を減らす

  • 使用するツリーノードの総数に応じて増加するのでツリーのノード数を少なくすると高速化する。具体的にはmax_depth、num_leavesを小さくする。ただし、学習が浅くなるので精度が落ちる可能性がある
  • ightGBM特有だが、データを読み込んだ際に各特徴量ごとに値のbinningが自動でされる。これはmax_binで binを最大でいくつ作るかを制御できるので値を小さくするほど作るbinの数が減って分割時の計算が簡単になる
    • max_binと似ているがbin内のデータ数の最小値min_data_in_binを大きくすることで結果的にmax_binを小さくするのと同じようなことが起きてbinの粒度を荒くできる
  • feature_fractionは分割の検討をする特徴量の割合を制御する。デフォルトでは1.0なので全特徴量を検討するが、例えば0.5のときはランダムで半分の特徴量しか分割の検討をしない。
  • 各木の作成時にデフォルトでは常に全データを使うが、bagging_fractionを用いることで使用するデータの割合(ランダムサンプリング)を制御することができる。

木の数を減らす

  • 作成する木の数(boosting round)を制御するnum_iterationsを小さくする。なお、その際は学習時間には関係ないが精度が落ちるのでlearning_rateを増やす必要がある。

精度を上げるには

  • max_binを上げるということは 、要は分割点を増やす=複雑な木にする、ということなのでその分精度が上がる
  • 小さいlearning_rateと大きなnum_iterationsを使う
  • 大きなnum_leavesを使う
  • GBDT(のMART)の正則化としてDrop Outの概念を入れて過学習を防ぐアルゴリズムらしい。

過学習を避ける

  • 小さなmax_binを使う
  • 小さなnum_leavesを使う
  • min_data_in_leafやmin_sum_hessian_in_leafを増やす
  • bagging_fractioとbagging_freqをつかってbaggingの調整をする
  • feature_fractionを使って特徴量のサンプリングを調整する
  • lambda_l1、lambda_l2、min_gain_to_splitで正則化の調整をする
  • max_depthを小さくする
  • extra_treesでExtremely Randomized Treesを作る
  • path_smoothを増やしスムージングの調整をする

感想

数%を求めた真面目なチューニングをしたことがあまりないが、網羅的にまとまっているのはとても助かる。
図があるので、狙っている効果かどうかの確認ができてとても良い。

出典

元記事

GENZITSU commented 3 years ago

トリビアからへぇを予測するAIを作り、自分の雑学を推論させた。Hee-AI(へぇあい)

具体的な取組よりも、特徴量抽出のところに心惹かれた

# from https://qiita.com/wataoka/items/164697e9b7c48e361bc5

# lambda
re_hira = re.compile(r'^[あ-ん]+$')
re_kata = re.compile(r'[\u30A1-\u30F4]+')
re_kanj = re.compile(r'^[\u4E00-\u9FD0]+$')
re_eigo = re.compile(r'^[a-zA-Z]+$')
is_hira = lambda word: not re_hira.fullmatch(word) is None
is_kata = lambda word: not re_kata.fullmatch(word) is None
is_eigo = lambda word: not re_eigo.fullmatch(word) is None
is_kanj = lambda word: not re_kanj.fullmatch(word) is None

def count_kata(sentence):
    cnt = 0; total=0
    for word in sentence.split(' '):
        if word == '': continue
        total += 1
        if is_kata(word): cnt += 1
    return cnt/total

def count_hira(sentence):
    cnt = 0; total=0
    for word in sentence.split(' '):
        if word == '': continue
        total += 1
        if is_hira(word): cnt += 1
    return cnt/total

def count_eigo(sentence):
    cnt = 0; total=0
    for word in sentence.split(' '):
        if word == '': continue
        total += 1
        if is_eigo(word): cnt += 1
    return cnt/total

def count_kanj(sentence):
    cnt = 0; total=0
    for word in sentence.split(' '):
        if word == '': continue
        total += 1
        if is_kanj(word): cnt += 1
    return cnt/total

感想

ひらがな/カタカナ/英語/漢字の文字数をカウントするのにこんな方法があったとは...

出典

元記事

GENZITSU commented 3 years ago

multi processでの高速化テク

背景

multi processにしても、プロセス間通信によって余計に生じるオーバーヘッドによって、逆に遅くなることがある。
(というかよくある)

どう言った原理か

マルチプロセスの並列化ではプロセス間でメモリのコピーが必要になります。

データのやり取りにかかるコストに着目していましたが、別で起動にかかるイニシャルコストもありますね。

経験則でいうとワーカーへの関数呼び出し回数が多いことが原因になっていることが多いですかねー。本質的にやっていることはメモリのコピーなんですが、そこに至るまでのお膳立てにかかるオーバーヘッドも大きくて、その部分にかかるコストはデータの大小に関わらず効いてきますので。

ワークアランド(最近覚えた言葉^^)

  1. ワーカーとやり取りするデータを減らす 例) 引数にせずグローバル変数にする ※ ワーカー起動時の fork(2) しかコピーが生じない、CoW があればそれもない

  2. ワーカーとやり取りする回数を減らす 例) 一行ずつの処理を複数行単位にする等

感想

やりとりするデータを減らすは確かに大事かも。あんまりグローバル変数増やしたくないがしゃーなしか...?

本命は後者「やり取りする回数を減らす」か

1処理にかかる時間が数分とかでない限り、並列化しても恩恵少ない印象。

出典

元ツイート

GENZITSU commented 3 years ago

富士通研究所のDataset公開サイト

今のところ2つのデータセットが公開されており、いずれもライセンスはCC0。

グラフデータセット Bermuda Triangle

三角問題・クリーク距離データセットとして公開されている。

スクリーンショット 2021-05-15 22 13 24

画像データセットDAISO-100

100 class, 160,000枚の画像が含まれている。
それぞれのclassには明度の違い、カメラ画角、商品状況などの状況が異なるようだ。

Each image involves meta-data regarding the environment: illumination conditions, camera angle, and product conditions. Artificial domain shifts can be created using these meta-data.

スクリーンショット 2021-05-15 22 13 24

感想

画像データのボリュームが意外とでかい。データセット名の通りダイソーの商品100修理についてのデータのようだ。

出典

元サイト

GENZITSU commented 3 years ago

推薦理由の説明が可能なモデルがあるらしい

こんなグラフを出せるようです。

スクリーンショット 2021-05-15 22 13 24

感想

理論が長大すぎて、全然理解できなかったけど重要そうなので、頭の片隅にでも...

出典

元記事

GENZITSU commented 3 years ago

オープンドメインな物語を評価するためのモデル

「UNION: An Unreferenced Metric for Evaluating Open-ended Story Generation」という論文。

referenceベースの評価手法では、正解が無限にあるこの手問題ではダメ。 反復/単語削除/文章順の置換/論理の逆転などを加えたNegative Samplesを自動生成してこの手の問題に対応した。

スクリーンショット 2021-05-15 22 13 24 スクリーンショット 2021-05-15 22 13 24

感想

文章の順番変更は確かにいいかも。
まぁ単語順を考慮するモデルじゃないとダメだけど。

出典

元論文

GENZITSU commented 3 years ago

複数環境で同じscriptを実行させるときに便利な関数

記事の通り。

# from https://zenn.dev/sinchir0/scraps/47cd440abe0a68

import os
import sys

def classify_env(TRIAL_NAME: str, NOW: str):

    # Colab
    if 'COLAB_GPU' in set(os.environ.keys()):
        DATA_DIR = '/content/drive/MyDrive/Kaggle/Cassava/data'
        OUTPUT_DIR = f'/content/drive/MyDrive/Kaggle/Cassava/output/{NOW}-{TRIAL_NAME}'
        os.makedirs(OUTPUT_DIR, exist_ok=True)

        sys.path.append(f'{DATA_DIR}/pytorch-image-models-master')

        print('Use COLAB')

    # kaggle
    elif 'KAGGLE_URL_BASE' in set(os.environ.keys()):
        DATA_DIR = '../input/cassava-leaf-disease-classification/'
        OUTPUT_DIR = './'

        sys.path.append('../input/pytorch-image-models/pytorch-image-models-master')

        print('Use Kaglle')

DATA_DIR, OUTPUT_DIR = classify_env(TRIAL_NAME, NOW)

感想

割と使用頻度高そう。

出典

元記事

GENZITSU commented 3 years ago

pythonで全角を半角に変換する

標準ライブラリのunicodedataを使うと簡単にかける。

# from https://zenn.dev/atu4403/articles/89c1380293cc6e22a19c

import unicodedata

s = "123①②③,㍻㍉㌦㎡㈱№,abcABC,Å🅱©,123abcABC,<>,アイウエオカキクケコ"
unicodedata.normalize("NFKC", s)

# '123123,平成ミリドルm2(株)No,abcABC,Å🅱©,123abcABC,<>,アイウエオカキクケコ'

具体的どのように変換されたかは、以下の表がわかりやすい。

スクリーンショット 2021-05-15 22 13 24

変換方法は4種類あるようだ。

スクリーンショット 2021-05-15 22 13 24

感想

mojimojiのzen_to_hanとか使っていたのだが、こっちの方は①を1にしてくれたりするので有用そうに見える。

出典

元記事

GENZITSU commented 3 years ago

ハーバードが350社の事例から導いた“DXの答え”、「AIファクトリー」とは

単にAIを導入するのではなく、オペレーションが自動的にデータを生み出すような整理にしないといけない。

カリム・ラカニたちが唱える「AIファクトリー」のエッセンスを改めてまとめると、下記のような形になる。

  1. 顧客にサービスを提供するのは従業員ではない。従業員がつくったAIが、顧客にサービスを提供する
  2. サービスを提供する際のオペレーションがデジタル化されることで、「データの蓄積→サービスの改善→ユーザーの拡大→データの蓄積」という好循環が発生する
  3. データの蓄積はサービスの改善にとどまらず、蓄積されたデータを活かした新たなサービス(=新たなAI)が次々とつくられていく
スクリーンショット 2021-05-15 22 13 24

感想

数週間前に取り上げたGAFAのMLアプリケーションデザインの話に通じるが、データが自動的/受動的にたまる用にデザインすることが重要っぽい。

出典

元記事

GENZITSU commented 3 years ago

写真上のレゴを認識して、何が作れるかをsuggestするアプリがすごい。

とりあえずツイートの動画を見てみてほしい。

動画の最後にチラッと出てるが、どこに該当のレゴがあるかも表示している。
適当にサジェストしても成立しそうだが、まさかここまでとは...。

スクリーンショット 2021-05-15 22 13 24

感想

冷蔵庫の写真から何が作れるかをサジェストするアプリの登場はそう遠くない未来なのかもしれない。

出典

元ツイート

アプリ

GENZITSU commented 3 years ago

gitでマージ済みのブランチを削除する方法

まずはマージ済みのbranchを確認する

git branch --merged

ここから、消したくないbranchを除いてgit branch -dすれば良い。
下の例では、developとmainを除いて削除するようにしている。

git branch --merged|egrep -v '\*|develop|main'|xargs git branch -d

ただ、毎回これを書くと辛いので、aliasを貼っておくのが良い。

[alias]
       delete-merged-branch = "!f () {git branch --merged|egrep -v '\\*|develop|main'|xargs git branch -d; };f"

感想

そうかmastermainに変わっちまったんだな。。。 おかげでmasterが消えたぜ☆

出典

元記事

GENZITSU commented 3 years ago

AIによる品質管理事例4選

1:西日本旅客鉄道株式会社

西日本旅客鉄道株式会社の事例では、新幹線の走行音から異常を知らせるAIシステムを活用しています。このAIシステムでは、線路の近くに設置したマイクが新幹線の走行音を記録し、AIシステムへと送信しています。 そこで過去の正常な走行音を学習したAIによって判別が行われ、AIが異常を検知した場合は指令所へと通知が行われるという仕組みになっています。

2:JFEスチール株式会社

安全管理業務にAIが活用されています。同社では近年経験の浅い製鉄所作業員が増加したことにより、以前よりも安全確保を優先する必要性が発生していました。 そのため、作業員が立ち入り禁止エリアに入った場合カメラが作業員を認識し、警告を発します。そして、自動的に製造ラインを停止するというAIを活用した安全管理システムを実用化しました。

3:Audi

プレス工場での自動車部品のひび割れ検査にAIを活用しています。これまでの同社のプレス工場では目視のチェックや画像ソフトを使った2段階の検査を行っていましたが、効率が良くありませんでした。 そのため、AIにサンプルとして大量のひび割れ画像を学習させ、ひび割れを自動検知できるシステムの開発を行い、数秒で検査が完了できるようになりました。

4:サントリーホールディングス株式会社

飲料品は季節や消費者動向などによって売れ行きが左右されるため、柔軟な生産計画を立てる必要があります。サントリーではこれまで経験のある社員が生産計画の立案や変更を行っていましたが、全体最適での生産計画の立案はできていませんでした。 そこで欠品、品薄、過剰などの在庫状況をAIが自動抽出し、タイムリーに生産計画を立案、変更するシステムを開発、導入しました。このシステムにより、サントリーでは生産計画の変更に掛かる時間を大幅に削減することに成功しました。

感想

特になし。

出典

元記事

GENZITSU commented 3 years ago

機械学習プロジェクトを推進するにあたって大切なこと ~DX推進時の「企画・PoC 」フェーズの落とし穴にはまらないために~

企画フェーズの落とし穴

● 学習時間や推論速度などの処理速度が業務上耐え得る速度ではなく、検証がやり直しになる ● 機械学習モデルの解釈性が低く、運用後のモニタリングやカスタマイズが難しい ● 既存システムとの連携を考慮せず、開発フェーズ のコストが想定よりかかる ● 適切な問題設定を行わないままPoCに進んでしまったため、PoC が終わらない ● 機械学習への期待値が高すぎる ● そもそも、ビジネス課題の解決手段として機械学習が適切でなかった

重要なのは「データ活用で解決可能な目標を設定する」ことです。 PoCで何を検証するのかを明確にする必要があり、加えてそれらは機械学習モデルの精度以外についてもあらかじめ検討項目として含んでいる方がよいでしょう。

PoCフェーズの落とし穴

● 機械学習モデルの性能がビジネスに使えるレベルまで達しておらず、次のステップになかなか進めない →性能が出ない理由にもよりますが、問題を設定し直す・データを集め直す・モデルはそのままで運用でカバーする、などで対応することが多いです。

● データ受領後に正解データにブレがありそのままのデータで分析を進めることが困難 →正解データにブレがあると、機械学習モデルは何を正として学習すればよいかわかりません。そういった場合、アノテーションの方法についても一緒に検討を進めさせていただきます。

感想

適切な問題設定 / 目標設定 / 撤退シナリオを組んでおくのが良いのかなぁ。
撤退シナリオは考えるのは辛いものの、やるべき案件は無限にあるので、悲観せず気持ちを切り替えるべき。

アノテーションデータにブレがあることは本当にあるあるなので、アノテーション品質の管理はPoC時の最重要事項かもしれない。

出典

元記事

GENZITSU commented 3 years ago

機械学習プロセスを成功させるためのチーム編成とは

ブレインパッドのテックブログでチ様々なチーム構成とそのメリデメについて語られていた。

まとめ

スクリーンショット 2021-05-15 22 13 24

PoC担当者のみでプロジェクトを担当するチーム

分析官一人で、分析 - 開発 - 運用を行う。 余程分析官が一人でない限り、基本的に避けた方が良い。 許容できるのは組織の立ち上がりフェーズくらいではななかろうか。

スクリーンショット 2021-05-15 22 13 24

「PoC担当者-開発者-運用者混成」でプロジェクトを担当するチーム

それぞれの専門家がいることで、システム化までがスムーズである反面、以下のデメリットがある。

  • 知識共有の問題 専門外の分野について最低限の知識共有が必要になるため、プロジェクト初期の立ち上げ時期に少し時間がかかる

  • リソースの問題 チームに専門分野をもつメンバーを張り付けるため、ある程度の余剰人的リソースが必要

組織全体のスキル向上を考えるなら、これが最良の構成かもしれない。

専門性を持つチームメンバーと素早くコミュニケーションをとることでリカバリ等を素早くこなし、些事に気を取られることなく専門分野に集中することができる。 また、異なる専門性を持つメンバーとの知識交換により知識レベルが上がった点も大きかったと思います。

スクリーンショット 2021-05-15 22 13 24

3.「プロジェクトの単一プロセスのみ」を担当するチーム

各々のフェーズを別企業 / 別部門 が取り仕切る形態。

規模の大きいプロジェクトはこうならざるを得ない。また以下のメリットがある。

必要なプロセスだけに予算をつけることができることによるコスト削減効果が大きいことだと思います。

ただし、デメリットもでかい。

  • 責任範囲の問題 プロセス内で個別最適な結果しか得られず、全体最適な結果は得られない プロセスの境界やプロセスを横断した業務に関する責任範囲が不明瞭であることから派生する問題。

  • コミュニケーションの問題 別企業の担当者間でのコミュニケーションに非常に時間がかかるため、スケジュール遅延が多発する プロセスの境界にある業務に関する認識の齟齬による手戻りが発生する

機械学習系のプロジェクトでは数イテレーション回さないとダメなケースがあるので、認識齟齬蓄積していくと...

せめて、一つのチームとして活動するようにしたほうがいいかもしれない。

スクリーンショット 2021-05-15 22 13 24

「全プロセスを俯瞰できるメンバー」でプロジェクトを担当するチーム

スキルレベルの高低はあるものの、全プロセスに知見があるメンバーで担当するパターン。 2番目のチーム構成の上位互換。以下のメリットがある。

リソースを余らせることがない 専門家を集めたチーム編成では、専門外分野に問題が発生した際にリソースの「空き」や「待ち」が発生するが、 この編成では問題に全員で取り組むことができるためリソースが余らない

  • 素早いPoC-開発−運用プロセスのサイクル 各プロセスでの課題解決速度向上による高速化

とはいえ、この体制にも問題があって、

  • 人員確保の問題 全てのプロセスに一定以上のレベルで通じたチームメンバーが必要だが、そういった人材は少ないため獲得が難しい

  • リソースの張り付き問題 全てのプロセスを少ない人員で全てのプロセスを回すことになるため、貴重な人材が特定のプロジェクトに張り付いてしまう。

スクリーンショット 2021-05-15 22 13 24

感想

持てる人材リソースにもよるが2か3の体制を撮るのが良いのかなぁ。 組織が成長の時は往々にして1になりがちなので、そこはどうにかせねば。。
短期的な生産性を少し下げてでも、できるだけ2に近づける努力が必要かも?

出典

元記事

GENZITSU commented 3 years ago

OpenCV RANSAC の時代が終わった....!?

opencv のデフォルトransacは精度が悪い上にとても遅いことが確認されている。

“Image Matching across Wide Baselines: From Paper to Practice“, which, among other messages, has shown that OpenCV RANSAC for fundamental matrix estimation is terrible: it was super inaccurate and slow.

今回比較したメソッド

非opencvの手法も比較

比較結果

スクリーンショット 2021-07-04 10 44 08 スクリーンショット 2021-07-04 10 44 32

感想

RANSAC至る所でつかっているが、USAC_MAGSACにしたほうがいいのかもしれない。 methodを32にするとよいっぽい?

スクリーンショット 2021-07-04 10 56 32

methodのリスト

//! type of the robust estimation algorithm
enum { LMEDS  = 4,  //!< least-median of squares algorithm
       RANSAC = 8,  //!< RANSAC algorithm
       RHO    = 16, //!< RHO algorithm
       USAC_DEFAULT  = 32, //!< USAC algorithm, default settings
       USAC_PARALLEL = 33, //!< USAC, parallel version
       USAC_FM_8PTS = 34,  //!< USAC, fundamental matrix 8 points
       USAC_FAST = 35,     //!< USAC, fast settings
       USAC_ACCURATE = 36, //!< USAC, accurate settings
       USAC_PROSAC = 37,   //!< USAC, sorted points, runs PROSAC
       USAC_MAGSAC = 38    //!< USAC, runs MAGSAC++
     };

出典

元記事

GENZITSU commented 3 years ago

トマト収穫ロボットの開発日記

デンソーによるトマト収穫ロボットの開発

ロボットの開発において、特に苦労した点

大きく分けて二つの課題。

1つは、不定形な対象物を正確に認識すること。工業製品だと、対象物の形状はあらかじめ決まっていますし、認識を行う条件も揃っています。ところが農園の場合、対象のミニトマトはみんな形状が違いますし、光などの条件もバラバラです。

もう1つは、「果柄(かへい)」の検出です。果柄は太さが2、3ミリメートル程度しかないため、日光下では透けてしまって正しく検出できないという問題がありました。(ミニトマトの房は細い果柄で茎からぶら下がっており、ロボットはこの果柄を切ってミニトマトの房を収穫します。)

どう解決したか?

障害物検出、房の検出、熟度判別、果柄検出という機能ごとに、異なる多数のAIモデルを用いて画像認識を行っています

障害物と熟度の判別にはCNNベースの画像判別A 房と実の位置検出には物体検出 果柄検出はピクセル単位で正確な位置検出を行うためセマンティックセグメンテーション 特に、難易度の高い日光下の果柄検出は、デンソーの計測技術部と独自開発した補完アルゴリズムを組み合わせることで実現しています。

一人でモデルを開発するのは限界があるため、コンペ形式にしたとのこと。

認識フロー

スクリーンショット 2021-07-03 22 23 28

スクリーンショット 2021-07-03 22 35 49スクリーンショット 2021-07-03 22 42 24

スクリーンショット 2021-07-03 22 42 34スクリーンショット 2021-07-03 22 42 45

アノテーションに関する工夫

ロボットのテストによるデータを蓄積し、それらデータのアノテーションを行いつつ、モデルを改良してロボットに搭載してまたテスト、というサイクルを回す。

特に、果柄の検出に用いたセマンティックセグメンテーションはピクセル単位で物体の検出を行えるのですが、正確な検出を行うためにはアノテーションもピクセル単位で行う必要がある。 作業が膨大だったので、20名ほどのプロジェクトメンバー全員に毎日1人100枚のノルマを約一ヶ月お願いしました。

アウトソースは意外に難しい。どの部分をどこまで塗りつぶすのか人によって違っては困るので、明確な判断基準を決めないといけません。ある程度ルールを決めて作業を進めていても、途中で例外が出てきたりする。あまり大きくルールを変えると、後から全部やり直しになってしまいますから、この塩梅をどうするかは悩みました。 それでも、精度向上のためにアノテーションをやり直さなければならないことが2回ほどありました。

メンバーのモチベーションを上げるため、アノテーションの進捗状況と認識精度の情報を共有するようにした。 AIが賢くなっていく様子を可視化することで、AIを育成している気分になれるよう工夫した。

AIがちゃんと育っていることに対して、感謝する気持ちを込めて1枚ずつアノテーションをするため、我々はこの作業を 感謝のアノテーション と呼んでいます。

現在の精度

障害物検出の精度が65%→98%へ、房の検出速度が3秒→1秒へ、熟度判別の誤差が2クラス→1クラスへ、果柄検出精度が50%→92%

80メートルでの収穫成功率は90%を超える、ただ、畑の管理が想定外の場合には60%程度に下がってしまうときもある 理想的な条件であれば 収穫速度は1房20秒くらいで収穫可能

ミニトマト以外の農作物

中玉トマトに関しては、現在のAIモデルでもうまく認識できています。 大きなトマトでは実を1つずつ採ることになるため、画像認識以外にもより高度なロボット制御を行わなければならず難易度は上がる キャベツの画像認識に関しては、ミニトマトで使っているAIモデルを、今まで培ったノウハウを使って学習し直すことで、短期間で高い性能を実現することができました。これは、AIの知識も経験もなかった去年の新入社員の石川が、約半年で実現してくれました。

スクリーンショット 2021-07-03 23 47 33

感想

問題を的確に分割して個別にモデル開発するのは、いわゆる分割統治方なのかな笑

アノテーションのアウトソースってやはり難しいんだなぁ。
モチベを保つためにAIの性能向上をモニタリングするのは確かに良さそう。
ここらへんなんかノウハウあるんだろうか。

キャベツへの転用って実際何を転用したんだろう。パイプラインとかアノテーションノウハウかなぁ?

出典

元記事

GENZITSU commented 3 years ago

opencvで1次元バーコードを認識する

使い方

# from https://opencv.org/recognizing-one-dimensional-barcode-using-opencv/

import cv2

bardet = cv2.barcode_BarcodeDetector()
img = cv2.imread("your file path")
ok, decoded_info, decoded_type, corners = bardet.detectAndDecode(img)

性能評価

BarcodeTestDatasetを用いて評価。小さくて歪んでいるバーコードがたくさん入っている。 精度が96%とかなり高い。

20msとあるが、c++を使用。ZxingらはJavaとのこと。

スクリーンショット 2021-07-04 11 23 09スクリーンショット 2021-07-04 11 23 16

処理パイプライン

  1. グレースケール化
  2. Scharr演算子でx,y方向の勾配を求める
  3. gradient coherenceによって候補パッチを求める
  4. erosionでノイズ除去
  5. バーコード領域の抽出
  6. 超解像
  7. 2値化(大津の2値化でうまくいかなかったら、ZXing’s Hybrid-binarizationを使う。)
  8. 最後にdecodeする

スクリーンショット 2021-07-04 11 37 08スクリーンショット 2021-07-04 11 37 15

スクリーンショット 2021-07-04 11 40 54 スクリーンショット 2021-07-04 11 40 59

感想

opencvにこんな便利関数が入っていたとは。 精度高そう。

出典

元記事

GENZITSU commented 3 years ago

さまざまな画像認識モデルのspeed benchmark

実験環境

GPU: RTX A6000 CPU: Ryzen 3600

結果抜粋

transformer系が速くて高精度っぽい。

スクリーンショット 2021-07-04 11 58 49 スクリーンショット 2021-07-04 12 00 13

感想

今使おうとしているモデルがどんくらいのspeedが出るかをざっくり見積もるのに良さそう。

ただ、真の意味でのbench markingは困難らしい。
Ross Wightman曰く、float16やAMPを使った場合の比較や、inputのshape、pytorchバージョンごとの違いなどを考慮して比較をする必要があるらしい。

Then try that in pure float16 and compare with AMP, and then try the conv nets w/ NHWC layout and w/o, run across a few PyTorch versions, incl NGC, and look at the variations across all of that and then realize even with the exact same hardware, it's not so simple to compare :)

アーキテクチャとpytorch versionに相性とかそういうのがあるんだろうか?
ある種参考としてみればいいのだろうけど、ベンチマークです!っていっちゃうといや俺の環境だともっと早いぜとか苦情来たりするからしないのかな笑

出典

github

Rossさんの元ツイ①

GENZITSU commented 3 years ago

segmenation特化のお助けライブラリ pytorch toolbelt

TTA、タイリングなどの関数が揃っているのが印象的。

# from https://github.com/BloodAxe/pytorch-toolbelt

from pytorch_toolbelt.inference import tta

model = UNet()

# Truly functional TTA for image classification using horizontal flips:
logits = tta.fliplr_image2label(model, input)

# Truly functional TTA for image segmentation using D4 augmentation:
logits = tta.d4_image2mask(model, input)

タイリング

# # from https://github.com/BloodAxe/pytorch-toolbelt

import numpy as np
from torch.utils.data import DataLoader
import cv2

from pytorch_toolbelt.inference.tiles import ImageSlicer, CudaTileMerger
from pytorch_toolbelt.utils.torch_utils import tensor_from_rgb_image, to_numpy

image = cv2.imread('really_huge_image.jpg')
model = get_model(...)

# Cut large image into overlapping tiles
tiler = ImageSlicer(image.shape, tile_size=(512, 512), tile_step=(256, 256))

# HCW -> CHW. Optionally, do normalization here
tiles = [tensor_from_rgb_image(tile) for tile in tiler.split(image)]

# Allocate a CUDA buffer for holding entire mask
merger = CudaTileMerger(tiler.target_shape, 1, tiler.weight)

# Run predictions for tiles and accumulate them
for tiles_batch, coords_batch in DataLoader(list(zip(tiles, tiler.crops)), batch_size=8, pin_memory=True):
    tiles_batch = tiles_batch.float().cuda()
    pred_batch = model(tiles_batch)

    merger.integrate_batch(pred_batch, coords_batch)

# Normalize accumulated mask and convert back to numpy
merged_mask = np.moveaxis(to_numpy(merger.merge()), 0, -1).astype(np.uint8)
merged_mask = tiler.crop_to_orignal_size(merged_mask)

感想

segmentation用のttaってやっぱ回転くらいしかないんだなぁ。
d4 augというのは90度回転を4つやることのことらしい。

出典

github

GENZITSU commented 3 years ago

TTA用ライブラリ ttach

segmentationやclassification, keypoint detectionなどのTTAを行うことが可能

segmentationの例

# from https://github.com/qubvel/ttach

import ttach as tta

tta_model = tta.SegmentationTTAWrapper(model, tta.aliases.d4_transform(), merge_mode='mean')

回転以外もできる。拡大縮小

# from https://github.com/qubvel/ttach

import ttach as tta

 defined 2 * 2 * 3 * 3 = 36 augmentations !
transforms = tta.Compose(
    [
        tta.HorizontalFlip(),
        tta.Rotate90(angles=[0, 180]),
        tta.Scale(scales=[1, 2, 4]),
        tta.Multiply(factors=[0.9, 1, 1.1]),        
    ]
)

tta_model = tta.SegmentationTTAWrapper(model, transforms)

mergeの仕方もたくさん揃ってる。

- mean
- gmean (geometric mean)
- sum
- max
- min
- tsharpen (temperature sharpen with t=0.5)

感想

なんかtool-beltよりもよさげじゃない...?

出典

元記事

GENZITSU commented 3 years ago

テーブルデータに対するTTA

各サンプルの性別を反転させたり、年齢の四捨五入、国籍のランダム変更などを行って実施する。

スクリーンショット 2021-07-04 17 58 31 スクリーンショット 2021-07-04 17 58 39

感想

どのカラムに対してTTAを行うかは慎重に選ぶ必要がありそう。
性差があきらかにないとか、国籍差が明らかにない問題設定だったから聞いたのかな?

出典

元論文

GENZITSU commented 3 years ago

データPJTに関するフェーズごとチェックリスト

AI・データ分析プロジェクトのすべてという本をもとに作成されたチェックリストがすごい。

ダウンロードリンク

PJTを受注する前 / PJTの実行中 / PJTの終わり側 の3つのフェーズごとに必要なタスク/注意事項などが書かれている。

感想

結構なボリュームになっているので、今いるフェーズごとに見落としがないかなどをチェックする使い方が良さそう。

出典

元記事

元の本

GENZITSU commented 3 years ago

コマンドが終わった時に通知を行う。

AppleScriptを使って通知を行う。

~/.bashrcに以下を記述する。

# from https://qiita.com/TsukasaGR/items/4d6f1e4a4ab998e09966

function remind() { # 関数名は好きにいじってください
  description="通知です" # デフォルトの文字は好きにいじってください
  if [ $# != 0 ]; then
    description=$1
  fi
  command /usr/bin/osascript -e "display notification \"$description\" with title \"Remind🔥\"" # タイトルも好きにいじってください
}

動作確認

sleep 10; remind 時間です
スクリーンショット 2021-07-05 9 24 08

感想

クソ長いパッケージのインストールの後に、remind をつければ終わったのに気づかず無駄に待つことが減りそう。

出典

元記事

GENZITSU commented 3 years ago

AWS Lambdaを使った画像変換API

画像を渡すと、それそれをポケモンの集合絵に変換してくれるAPIの開発記録。

スクリーンショット 2021-07-05 9 24 08

Lambdaを使ったAPI化の方法として参考になる。

大まかな流れとして、Docker化して、Lambdaでfunctionにし、API Gatewayを用いてAPI化。

感想

直近の業務で使いそう。

出典

元記事

GENZITSU commented 3 years ago

PythonでのShapefile(.shp)操作まとめ

Shapefileにまつわる操作が圧倒的なボリュームでまとめられている。

スクリーンショット 2021-07-05 15 38 35 スクリーンショット 2021-07-05 15 38 48 スクリーンショット 2021-07-05 15 39 00

感想

今後お世話になることになりそう。

出典

元記事

GENZITSU commented 3 years ago

国立天文台、AIを用いてダークマターの地図からノイズを取り除く手法を開発

どうやらスパコンを用いてノイズ有りレンズマップとノイズ無しレンズマップを作成できるようだ。 それを用いてGANベースでデノイザーを作っているようだ。 シミュレーションでやってるのかな...?

スクリーンショット 2021-07-05 20 26 57

感想

スパコンすげぇ。擬似的な正解と誤答が作れると、こういうことができるんですね。

出典

元記事

GENZITSU commented 3 years ago

DeNA, MoT合同AI勉強会発表資料 / Monocular 3D Object Detection @ CVPR2021

表題の通り、CVPR2021の単眼3D物体検出手法がまとめられている。 各論文のMotivation / Proposalが端的にまとめられているので、どんな課題をどんなアイデアで乗り越えようとしたかが見やすい。

感想

ごつい提案手法が多いので、すぐに使えるとかはなさそうだけど、どっかで見返したい。

出典

元slide

GENZITSU commented 3 years ago

Using AntiPatterns to avoid MLOps Mistakes

金融系 ML PJTを実施することで学んだAntipattersを紹介してくれている論文。

スクリーンショット 2021-07-05 9 24 08

1. Data Leakage AntiPattern

  1. Peek-a-Boo AntiPattern. データが生成されるタイムラグの考慮し忘れから発生するleak
  2. Temporal Leakage AntiPattern データ生成の時系列性を無視してデータを分割することによるleak
  3. Oversampling Leakage AntiPattern over samplingをデータ分割前に実施することによるleak
  4. Metrics-from-Beyond AntiPattern. testデータも使って前処理/後処理のパラメータを決めることによるleak

2. ‘Act Now, Reflect Never’ AntiPattern

デプロイ後に、モデルをほったらかしにすることによる問題
コンセプトドリフトや出鱈目な予測、adversarialな攻撃などを検知できなくなる。

3. Tuning-under-the-Carpet AntiPattern

ハイパラチューニングは精度にクリティカルに効いてくるので、学習パイプラインに明示的に組み込む必要がある。
しかし、どのように探索したかを明らかにしておかないと、再現性がなくなる。。。

4. ‘PEST’ AntiPattern

論文とかで報告された優位性は見かけだけかもしれないよ。ということ。

the reported empirical gains are actually just an occurrence of the Perceived Empirical SuperioriTy (PEST) antipattern.

実際レコメンデーション系のモデルでも枯れた技術で十分ですよ、的なのあったしね。

KISSに則って、できるだけシンプルなモデルから始めるのが良いとのこと。

5. Bad Credit Assignment AntiPattern

提案された手法のgainがどこから来ているのかを見誤る問題。

モデルのアーキテクチャー由来のgainというよりも、問題設定やデータの前処理、ハイパラチューニング、優れた技術の組み合わせからもたらされることの方が多い。

6. Grade-your-own-Exam AntiPattern

ちゃんとしたvalidation dataを使わないことによる問題。
leakにも近いが、検証が不十分によることの誤り。

HARKing (Hypothesizing After Results are Known)もこれに近い。

データサイエンティストチームは、最新のGround Truthを常に取得できるようなシステムを設けておいた方が良いとのこと。

7. Set & Forget AntiPattern

コンセプトドリフトに関連した問題が書かれてた。 ほぼ2と同じような...

8. ‘Communicate with Ambivalence’ AntiPattern

不確実性を適切に表現できない問題。モデルがwell callibratedでないことによる問題。

モデルの説明のほかに、不確実性も十分な情報となるとのこと

9. ‘Data Crisis as a Service’ AntiPattern

検証時に実施したデータのフィルタリングを、プロダクションでは実施しないことによる問題。

何らかのサンプリング・フィルタリングをしていることを忘れていると....

感想

チェックリスト的に使いたい。

出典

元論文

GENZITSU commented 3 years ago

pythonで特定の文字列に挟まれた部分を取得する方法

# from https://qiita.com/empelt/items/97dd2a78e530ec41c8f8

# group(0)  挟む文字列自身を含む
str1 = re.search(r'AB(.+)FG',origin_str).group(0)
# group(1)  挟む文字列自身を含まない
str2 = re.search(r'AB(.+)FG',origin_str).group(1)

print(str1)
>>> ABCDEFG

print(str2)
>>> CDE

感想

ログファイルのパースとかするのに便利そう

出典

元論文