Open GENZITSU opened 3 years ago
具体的な取組よりも、特徴量抽出のところに心惹かれた
# 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
ひらがな/カタカナ/英語/漢字の文字数をカウントするのにこんな方法があったとは...
multi processにしても、プロセス間通信によって余計に生じるオーバーヘッドによって、逆に遅くなることがある。
(というかよくある)
マルチプロセスの並列化ではプロセス間でメモリのコピーが必要になります。
データのやり取りにかかるコストに着目していましたが、別で起動にかかるイニシャルコストもありますね。
経験則でいうとワーカーへの関数呼び出し回数が多いことが原因になっていることが多いですかねー。本質的にやっていることはメモリのコピーなんですが、そこに至るまでのお膳立てにかかるオーバーヘッドも大きくて、その部分にかかるコストはデータの大小に関わらず効いてきますので。
ワーカーとやり取りするデータを減らす 例) 引数にせずグローバル変数にする ※ ワーカー起動時の fork(2) しかコピーが生じない、CoW があればそれもない
ワーカーとやり取りする回数を減らす 例) 一行ずつの処理を複数行単位にする等
やりとりするデータを減らすは確かに大事かも。あんまりグローバル変数増やしたくないがしゃーなしか...?
本命は後者「やり取りする回数を減らす」か
1処理にかかる時間が数分とかでない限り、並列化しても恩恵少ない印象。
今のところ2つのデータセットが公開されており、いずれもライセンスはCC0。
三角問題・クリーク距離データセットとして公開されている。
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.
画像データのボリュームが意外とでかい。データセット名の通りダイソーの商品100修理についてのデータのようだ。
「UNION: An Unreferenced Metric for Evaluating Open-ended Story Generation」という論文。
referenceベースの評価手法では、正解が無限にあるこの手問題ではダメ。 反復/単語削除/文章順の置換/論理の逆転などを加えたNegative Samplesを自動生成してこの手の問題に対応した。
文章の順番変更は確かにいいかも。
まぁ単語順を考慮するモデルじゃないとダメだけど。
記事の通り。
# 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)
割と使用頻度高そう。
標準ライブラリのunicodedataを使うと簡単にかける。
# from https://zenn.dev/atu4403/articles/89c1380293cc6e22a19c
import unicodedata
s = "123①②③,㍻㍉㌦㎡㈱№,abcABC,Å🅱©,123abcABC,<>,アイウエオカキクケコ"
unicodedata.normalize("NFKC", s)
# '123123,平成ミリドルm2(株)No,abcABC,Å🅱©,123abcABC,<>,アイウエオカキクケコ'
具体的どのように変換されたかは、以下の表がわかりやすい。
変換方法は4種類あるようだ。
mojimojiのzen_to_hanとか使っていたのだが、こっちの方は①を1にしてくれたりするので有用そうに見える。
単にAIを導入するのではなく、オペレーションが自動的にデータを生み出すような整理にしないといけない。
カリム・ラカニたちが唱える「AIファクトリー」のエッセンスを改めてまとめると、下記のような形になる。
- 顧客にサービスを提供するのは従業員ではない。従業員がつくったAIが、顧客にサービスを提供する
- サービスを提供する際のオペレーションがデジタル化されることで、「データの蓄積→サービスの改善→ユーザーの拡大→データの蓄積」という好循環が発生する
- データの蓄積はサービスの改善にとどまらず、蓄積されたデータを活かした新たなサービス(=新たなAI)が次々とつくられていく
数週間前に取り上げたGAFAのMLアプリケーションデザインの話に通じるが、データが自動的/受動的にたまる用にデザインすることが重要っぽい。
まずはマージ済みの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"
そうかmaster
はmain
に変わっちまったんだな。。。
おかげでmasterが消えたぜ☆
西日本旅客鉄道株式会社の事例では、新幹線の走行音から異常を知らせるAIシステムを活用しています。このAIシステムでは、線路の近くに設置したマイクが新幹線の走行音を記録し、AIシステムへと送信しています。 そこで過去の正常な走行音を学習したAIによって判別が行われ、AIが異常を検知した場合は指令所へと通知が行われるという仕組みになっています。
安全管理業務にAIが活用されています。同社では近年経験の浅い製鉄所作業員が増加したことにより、以前よりも安全確保を優先する必要性が発生していました。 そのため、作業員が立ち入り禁止エリアに入った場合カメラが作業員を認識し、警告を発します。そして、自動的に製造ラインを停止するというAIを活用した安全管理システムを実用化しました。
プレス工場での自動車部品のひび割れ検査にAIを活用しています。これまでの同社のプレス工場では目視のチェックや画像ソフトを使った2段階の検査を行っていましたが、効率が良くありませんでした。 そのため、AIにサンプルとして大量のひび割れ画像を学習させ、ひび割れを自動検知できるシステムの開発を行い、数秒で検査が完了できるようになりました。
飲料品は季節や消費者動向などによって売れ行きが左右されるため、柔軟な生産計画を立てる必要があります。サントリーではこれまで経験のある社員が生産計画の立案や変更を行っていましたが、全体最適での生産計画の立案はできていませんでした。 そこで欠品、品薄、過剰などの在庫状況をAIが自動抽出し、タイムリーに生産計画を立案、変更するシステムを開発、導入しました。このシステムにより、サントリーでは生産計画の変更に掛かる時間を大幅に削減することに成功しました。
特になし。
● 学習時間や推論速度などの処理速度が業務上耐え得る速度ではなく、検証がやり直しになる ● 機械学習モデルの解釈性が低く、運用後のモニタリングやカスタマイズが難しい ● 既存システムとの連携を考慮せず、開発フェーズ のコストが想定よりかかる ● 適切な問題設定を行わないままPoCに進んでしまったため、PoC が終わらない ● 機械学習への期待値が高すぎる ● そもそも、ビジネス課題の解決手段として機械学習が適切でなかった
重要なのは「データ活用で解決可能な目標を設定する」ことです。 PoCで何を検証するのかを明確にする必要があり、加えてそれらは機械学習モデルの精度以外についてもあらかじめ検討項目として含んでいる方がよいでしょう。
● 機械学習モデルの性能がビジネスに使えるレベルまで達しておらず、次のステップになかなか進めない →性能が出ない理由にもよりますが、問題を設定し直す・データを集め直す・モデルはそのままで運用でカバーする、などで対応することが多いです。
● データ受領後に正解データにブレがありそのままのデータで分析を進めることが困難 →正解データにブレがあると、機械学習モデルは何を正として学習すればよいかわかりません。そういった場合、アノテーションの方法についても一緒に検討を進めさせていただきます。
適切な問題設定 / 目標設定 / 撤退シナリオを組んでおくのが良いのかなぁ。
撤退シナリオは考えるのは辛いものの、やるべき案件は無限にあるので、悲観せず気持ちを切り替えるべき。
アノテーションデータにブレがあることは本当にあるあるなので、アノテーション品質の管理はPoC時の最重要事項かもしれない。
ブレインパッドのテックブログでチ様々なチーム構成とそのメリデメについて語られていた。
まとめ
分析官一人で、分析 - 開発 - 運用を行う。 余程分析官が一人でない限り、基本的に避けた方が良い。 許容できるのは組織の立ち上がりフェーズくらいではななかろうか。
それぞれの専門家がいることで、システム化までがスムーズである反面、以下のデメリットがある。
知識共有の問題 専門外の分野について最低限の知識共有が必要になるため、プロジェクト初期の立ち上げ時期に少し時間がかかる
リソースの問題 チームに専門分野をもつメンバーを張り付けるため、ある程度の余剰人的リソースが必要
組織全体のスキル向上を考えるなら、これが最良の構成かもしれない。
専門性を持つチームメンバーと素早くコミュニケーションをとることでリカバリ等を素早くこなし、些事に気を取られることなく専門分野に集中することができる。 また、異なる専門性を持つメンバーとの知識交換により知識レベルが上がった点も大きかったと思います。
各々のフェーズを別企業 / 別部門 が取り仕切る形態。
規模の大きいプロジェクトはこうならざるを得ない。また以下のメリットがある。
必要なプロセスだけに予算をつけることができることによるコスト削減効果が大きいことだと思います。
ただし、デメリットもでかい。
責任範囲の問題 プロセス内で個別最適な結果しか得られず、全体最適な結果は得られない プロセスの境界やプロセスを横断した業務に関する責任範囲が不明瞭であることから派生する問題。
コミュニケーションの問題 別企業の担当者間でのコミュニケーションに非常に時間がかかるため、スケジュール遅延が多発する プロセスの境界にある業務に関する認識の齟齬による手戻りが発生する
機械学習系のプロジェクトでは数イテレーション回さないとダメなケースがあるので、認識齟齬蓄積していくと...
せめて、一つのチームとして活動するようにしたほうがいいかもしれない。
スキルレベルの高低はあるものの、全プロセスに知見があるメンバーで担当するパターン。 2番目のチーム構成の上位互換。以下のメリットがある。
リソースを余らせることがない 専門家を集めたチーム編成では、専門外分野に問題が発生した際にリソースの「空き」や「待ち」が発生するが、 この編成では問題に全員で取り組むことができるためリソースが余らない
- 素早いPoC-開発−運用プロセスのサイクル 各プロセスでの課題解決速度向上による高速化
とはいえ、この体制にも問題があって、
人員確保の問題 全てのプロセスに一定以上のレベルで通じたチームメンバーが必要だが、そういった人材は少ないため獲得が難しい
リソースの張り付き問題 全てのプロセスを少ない人員で全てのプロセスを回すことになるため、貴重な人材が特定のプロジェクトに張り付いてしまう。
持てる人材リソースにもよるが2か3の体制を撮るのが良いのかなぁ。
組織が成長の時は往々にして1になりがちなので、そこはどうにかせねば。。
短期的な生産性を少し下げてでも、できるだけ2に近づける努力が必要かも?
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の手法も比較
RANSAC至る所でつかっているが、USAC_MAGSACにしたほうがいいのかもしれない。 methodを32にするとよいっぽい?
//! 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++
};
デンソーによるトマト収穫ロボットの開発
大きく分けて二つの課題。
1つは、不定形な対象物を正確に認識すること。工業製品だと、対象物の形状はあらかじめ決まっていますし、認識を行う条件も揃っています。ところが農園の場合、対象のミニトマトはみんな形状が違いますし、光などの条件もバラバラです。
もう1つは、「果柄(かへい)」の検出です。果柄は太さが2、3ミリメートル程度しかないため、日光下では透けてしまって正しく検出できないという問題がありました。(ミニトマトの房は細い果柄で茎からぶら下がっており、ロボットはこの果柄を切ってミニトマトの房を収穫します。)
障害物検出、房の検出、熟度判別、果柄検出という機能ごとに、異なる多数のAIモデルを用いて画像認識を行っています
障害物と熟度の判別にはCNNベースの画像判別A 房と実の位置検出には物体検出 果柄検出はピクセル単位で正確な位置検出を行うためセマンティックセグメンテーション 特に、難易度の高い日光下の果柄検出は、デンソーの計測技術部と独自開発した補完アルゴリズムを組み合わせることで実現しています。
一人でモデルを開発するのは限界があるため、コンペ形式にしたとのこと。
ロボットのテストによるデータを蓄積し、それらデータのアノテーションを行いつつ、モデルを改良してロボットに搭載してまたテスト、というサイクルを回す。
特に、果柄の検出に用いたセマンティックセグメンテーションはピクセル単位で物体の検出を行えるのですが、正確な検出を行うためにはアノテーションもピクセル単位で行う必要がある。 作業が膨大だったので、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の知識も経験もなかった去年の新入社員の石川が、約半年で実現してくれました。
問題を的確に分割して個別にモデル開発するのは、いわゆる分割統治方なのかな笑
アノテーションのアウトソースってやはり難しいんだなぁ。
モチベを保つためにAIの性能向上をモニタリングするのは確かに良さそう。
ここらへんなんかノウハウあるんだろうか。
キャベツへの転用って実際何を転用したんだろう。パイプラインとかアノテーションノウハウかなぁ?
# 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とのこと。
opencvにこんな便利関数が入っていたとは。 精度高そう。
GPU: RTX A6000 CPU: Ryzen 3600
transformer系が速くて高精度っぽい。
今使おうとしているモデルがどんくらいの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に相性とかそういうのがあるんだろうか?
ある種参考としてみればいいのだろうけど、ベンチマークです!っていっちゃうといや俺の環境だともっと早いぜとか苦情来たりするからしないのかな笑
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つやることのことらしい。
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よりもよさげじゃない...?
各サンプルの性別を反転させたり、年齢の四捨五入、国籍のランダム変更などを行って実施する。
どのカラムに対してTTAを行うかは慎重に選ぶ必要がありそう。
性差があきらかにないとか、国籍差が明らかにない問題設定だったから聞いたのかな?
AI・データ分析プロジェクトのすべてという本をもとに作成されたチェックリストがすごい。
PJTを受注する前 / PJTの実行中 / PJTの終わり側 の3つのフェーズごとに必要なタスク/注意事項などが書かれている。
結構なボリュームになっているので、今いるフェーズごとに見落としがないかなどをチェックする使い方が良さそう。
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 時間です
クソ長いパッケージのインストールの後に、remind をつければ終わったのに気づかず無駄に待つことが減りそう。
画像を渡すと、それそれをポケモンの集合絵に変換してくれるAPIの開発記録。
Lambdaを使ったAPI化の方法として参考になる。
大まかな流れとして、Docker化して、Lambdaでfunctionにし、API Gatewayを用いてAPI化。
直近の業務で使いそう。
どうやらスパコンを用いてノイズ有りレンズマップとノイズ無しレンズマップを作成できるようだ。 それを用いてGANベースでデノイザーを作っているようだ。 シミュレーションでやってるのかな...?
スパコンすげぇ。擬似的な正解と誤答が作れると、こういうことができるんですね。
表題の通り、CVPR2021の単眼3D物体検出手法がまとめられている。 各論文のMotivation / Proposalが端的にまとめられているので、どんな課題をどんなアイデアで乗り越えようとしたかが見やすい。
ごつい提案手法が多いので、すぐに使えるとかはなさそうだけど、どっかで見返したい。
金融系 ML PJTを実施することで学んだAntipattersを紹介してくれている論文。
デプロイ後に、モデルをほったらかしにすることによる問題
コンセプトドリフトや出鱈目な予測、adversarialな攻撃などを検知できなくなる。
ハイパラチューニングは精度にクリティカルに効いてくるので、学習パイプラインに明示的に組み込む必要がある。
しかし、どのように探索したかを明らかにしておかないと、再現性がなくなる。。。
論文とかで報告された優位性は見かけだけかもしれないよ。ということ。
the reported empirical gains are actually just an occurrence of the Perceived Empirical SuperioriTy (PEST) antipattern.
実際レコメンデーション系のモデルでも枯れた技術で十分ですよ、的なのあったしね。
KISSに則って、できるだけシンプルなモデルから始めるのが良いとのこと。
提案された手法のgainがどこから来ているのかを見誤る問題。
モデルのアーキテクチャー由来のgainというよりも、問題設定やデータの前処理、ハイパラチューニング、優れた技術の組み合わせからもたらされることの方が多い。
ちゃんとしたvalidation dataを使わないことによる問題。
leakにも近いが、検証が不十分によることの誤り。
HARKing (Hypothesizing After Results are Known)もこれに近い。
データサイエンティストチームは、最新のGround Truthを常に取得できるようなシステムを設けておいた方が良いとのこと。
コンセプトドリフトに関連した問題が書かれてた。 ほぼ2と同じような...
不確実性を適切に表現できない問題。モデルがwell callibratedでないことによる問題。
モデルの説明のほかに、不確実性も十分な情報となるとのこと
検証時に実施したデータのフィルタリングを、プロダクションでは実施しないことによる問題。
何らかのサンプリング・フィルタリングをしていることを忘れていると....
チェックリスト的に使いたい。
# 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
ログファイルのパースとかするのに便利そう
GBDTのハイパーパラメータの意味を図で理解しつつチューニングを学ぶ
GBDTのパラメータを視覚的に理解する記事。 個人的に気になった箇所
num_leaves (max_leaves)
確かにダイナミックに形が変わる。
明示的にX割にしたい局面ってあるんだろうか...?(素人並感)
最重要なパラメータtop3
計算速度を上げるには?
リソースを増やす
分割の負担を減らす
木の数を減らす
精度を上げるには
過学習を避ける
感想
数%を求めた真面目なチューニングをしたことがあまりないが、網羅的にまとまっているのはとても助かる。
図があるので、狙っている効果かどうかの確認ができてとても良い。
出典
元記事