Open GENZITSU opened 3 years ago
Simple Copy-Paste Data Augmentationの再現実験を通じて、物体検出の精度向上をもたらすtipsを発見。
We conducted a series of ablation experiments to understand which hyperparameter changes drove these improvements. To see whether we can drive accuracy even higher, we also tried deeper models with larger images. Our experiments demonstrated that:
長い時間をかけてトレーニングを実施し、image sizeを大きくすることでBox AP, MaskAPは向上するが、scale jitterは大きくしすぎてもだめ。
- A longer training schedule, larger input image size, and a larger scale jitter range have positive effects on AP. Box AP and Mask AP continued to scale with increases in training schedule (as shown in the chart above). Box AP and Mask AP plateaued for scale jitter at 0.5–1.6 when trained with 144 epoch schedule (as shown in the chart below).
Sync Batch Norm, weight Decay, DeepなBox headは共に精度向上に寄与する
- Sync Batch Norm, Weight Decay, and deeper Region Proposal Network (RPN) and Region of Interest (ROI) heads also have a positive impact on Box AP and Mask AP, as shown in the table below.
AMPは学習速度を30%高速化させるが、degradeは限定的
- Enabling PyTorch’s automatic mixed precision (AMP) and FP16 improved training speed by 30 percent and does not degrade Box AP and Mask AP. These performance gains were on an eight-node cluster, where each node had eight Nvidia V100 32GB GPUs.
ちょろっと書かれ血えるが、ImageNet Initializationよりもrandom Initializationの方が精度が高いのが驚き。 Copy-Pasteで生成されるクリーンなラベルの影響だろうか...?
諸々のテクは機会があれば使いたい。
%load_ext google.colab.data_table
をつけることで、interactiveにDataFrameの表示が可能になる。
紹介動画 https://twitter.com/i/status/1190585213837021186
簡単に要約すると
- ランキングの分野では、最適化したいメトリックにノイズを加えて滑らかにすることで、学習の目的関数として使う手法がある
- ランキングメトリックにはモデルスコアがタイになる場合の扱いに関する曖昧さがあるが、既存手法はそれに無頓着であったことを指摘
- タイの扱いに対して consistent な smoothing を提案。既存手法より良いことを実験で確認
StochasticRank を使えば好きなランキングメトリックをグローバルに最適化でき、とても強力なように思われる。
ちなみに、ロスをsmoothにするというのは以下のようなイメージ。
普通はあるアイテムペア同士のロスは階段上になっているが、これを平坦にする。
LambdaMartでも十分と言えば十分。
[元論文](StochasticRank: Global Optimization of Scale-Free Discrete Functions)
これまで列車の混雑状況は、車両の重さや駅ホームでの人による目視で把握するケースが一般的だった。だが「車両の重さを用いた手法では、相互に乗り入れをしている他社の列車の混雑状況までを把握することは難しかった」(吉野秀行運転部輸送課主任)という
開発したシステムはデプスカメラをホーム端に設置し、駅を出発する列車内を撮影する。撮影した映像からエッジサーバーで混雑情報をテキストデータ化し、クラウドサーバーへ送信する。クラウド上では機械学習をしたAIによって分析、解析させることにより、駅を出発してから十数秒で列車の混雑状況を号車ごとに算出する。
「新たに開発したシステムでは、相互乗り入れする他社の列車であってもリアルタイムに計測することが可能」
ホームから列車を撮影して混雑状況を把握するのが意外だった。 確かに各列車に置くよりかは効率的なのかな? (列車(車両)の数と駅の数どっちが多いのだろうか、流石に車両だと思うが...)
オクルージョン問題はカメラの角度でなんとかできるのかなぁ?
パスワードの解析は意外と普通のパソコンでも実施可能
1秒間に50億回のパスワードが、普通のデスクトップパソコンでも実は解析できます。文字数が増えてくると、どんどん時間がかかります。7文字になると1分ぐらいでできたのもあれば、複雑な記号が入っていれば20分ぐらいかかるのもあります。理論的に1秒間に200億回で計算すると、54分ぐらいかかるのが最大だと考えられます。
パスワード付きzipが弱いのは96bitしかないから
zipのパスワードが弱いと言われる所以が、96bitしかないので、パスワードの文字に記号などいろいろと入れて94文字、95文字あると考えると、15文字のパスワードで同じものが出てきている。そのため、14文字以降は総当たりをしちゃえばいい。
9文字になると理論値は1年近くになって、これはちょっとパスワードを複雑なものでやりましたが、断念しました。1週間も回していないのでわかりませんが、もう面倒くさいので、ここは理論値で見るしかない。10文字、11文字、12文字になっていくと、どんどん倍々どころかすごく桁が上がってきます。
使用する文字の種類も大事
では種類はどうなのか。例えば英語の小文字だけを使うと26種類しかありません。これだと、例えば11文字のパスワードでも2日ぐらいで解けます。文字の種類もやはり重要です。どの文字を使われているかわからなければ、たぶん簡単な方法で攻撃すると思うので、記号などが入っていないパスワードだと、実はわりと早く破られる。
オフィスのパスワードはかなり頑丈
パスワードの解析にかかる金額感
パスワードは最低9文字, 文字種はアルファベット以外も使うようにします。
GPT-3と同等の精度かつApache-2.0で商用利用可能なGPTが登場したので日本語で試してみた記事
https://github.com/kingoflolz/mesh-transformer-jax EleutherAIというオープンソースでGPT-NeoやGPT-NeoX,大規模言語コーパスPileの作成を手がける研究プロジェクトが作成
デモ用のノートブックを利用して日本語で試していた。
大まかな推論時間
そもそもの学習データは日本語ではないものの、日本語の出力も一応可能。
ただし、成功確率は5%程度のようだ。
今回は日本語にフォーカスしましたが、英語だと日本語よりもZero-Shotで解けるタスクが多かったです。GPT-J-6Bの事前学習で使われているPileデータセットは日本語メインではないにもかかわらず、ここまで出力できるのは驚き。 とはいえ、出力結果は安定しないのでタスクに応じたドメインテキストで再度、事前学習する必要しないと現実課題では利用は難しいと思います。例えば要約タスクは20回ほど実行して成功例に出力を得ることができました。
gpt3まぁまぁ値段かかるので、opensource化ありがたい。
日本語データでのfinetuiningどうすればいいんだろう。
googleが2019~2020年にタイで実施した眼底検査AIの導入事例からの教訓。
タイでは看護師が患者の眼底画像を撮影し、10週間ほどかかって検査する
In the system Thailand had been using, nurses take photos of patients’ eyes during check-ups and send them off to be looked at by a specialist elsewhere—a process that can take up to 10 weeks.
精度90%で10分で検査可能
The AI developed by Google Health can identify signs of diabetic retinopathy from an eye scan with more than 90% accuracy—which the team calls “human specialist level”—and, in principle, give a result in less than 10 minutes.
看護師が学習データと同等のクオリティで検査画像を撮影するとは限らない。
it was designed to reject images that fell below a certain threshold of quality. With nurses scanning dozens of patients an hour and often taking the photos in poor lighting conditions, more than a fifth of the images were rejected.
画像をアップロードする必要があるので、回線が弱い地域だと、アップロードにめちゃくちゃ時間がかかって診察が回せない。
Because the system had to upload images to the cloud for processing, poor internet connections in several clinics also caused delays. “Patients like the instant results, but the internet is slow and patients then complain,” said one nurse. “They’ve been waiting here since 6 a.m., and for the first two hours we could only screen 10 patients.”
ラボ環境で高精度を出すことは初めの一歩に過ぎない。
He sees the Google study as a timely reminder that establishing accuracy in a lab is just the first step.
AIの精度自体が問題になるというよりかは、現場のプロセスに適合していることが大事。
例えば、「シンプルに推論ができない」ではなく「なんでできないか」を提示することが大事そう(?)
Abramoff also questions the usefulness of comparing AI tools with human specialists when it comes to accuracy. Human doctors disagree all the time, he says—and that’s fine. An AI system needs to fit into a process where sources of uncertainty are discussed rather than simply rejected.
とはいえ、成せれば実りは大きい。一人の看護師が1,000人の患者を裁くことも可能
Get it right and the benefits could be huge. When it worked well, Beede and her colleagues saw how the AI made people who were good at their jobs even better.
人々は、AIによる診断か人間による診断かはあまり関係なくて、UXの方が重要。
“There was one nurse that screened 1,000 patients on her own, and with this tool she’s unstoppable,” she says. “The patients didn’t really care that it was an AI rather than a human reading their images. They cared more about what their experience was going to be.”
ラボ環境で不用意に問題を簡易化することの危険性を感じた。
想定しているワークフローで発生しうる事象を考慮した上でモデルを作成する必要があるのだろうか...?
あえて、無視してとりあえず全体のシステムを作ってみるのも手といえば手?
ライヤーポイントのデフォルトシンボルです。空の文字列('')はフライヤーを隠します。Noneの場合、フライヤーのデフォルトは'b+'となります。より詳細な制御は flierprops パラメータで行います。
引数にsym=""を設定すると外れ値を表現しないらしい
sns.boxplot(df["sim_free_flg"], df["price"], sym="")
すげー
wantedly輪読会からまるまる引用
データセット作成、問題設定、データ分析、評価の各フェイズで発生しうるバイアスをまとめている.
- データセット作成に関連するバイアス
- Sampling Bias (白人がやけに多いとか)
- Measurement Bias (Capture Bias, Device Bias)
- Label Bias (アノテーション, 確証バイアス, ピークエンド効果)
- Negative Set Bias (代表的なクラス以外を少数のクラスもしくはサンプルで表すことで生じる偏り)
- 問題設定に関連するバイアス
- Framing Effect Bias (問題設計によっては得られる結果が異なり偏ったものになる)
- データ分析やアルゴリズムに関連するバイアス
- Sample Selection Bias (無作為ではなく何らかの条件付けで抽出することで発生する偏り)
- Confounding Bias (交絡)
- Design-related Bias (アルゴリズムやUI起因)
- 評価に関連するバイアス
- Human Evaluation Bias (定性評価とか)
- Sample Treatment Bias (評価できるデータと評価できないデータでは偏りがあるかもね)
- Validation and Test Dataset Bias (データセット作成段階のバイアスが影響)
あのCANINEが柴犬になって登場!!
こんな感じで使う
from shiba import Shiba, CodepointTokenizer, get_pretrained_state_dict
shiba_model = Shiba()
shiba_model.load_state_dict(get_pretrained_state_dict())
shiba_model.eval() # disable dropout
tokenizer = CodepointTokenizer()
inputs = tokenizer.encode_batch(['自然言語処理', '柴ドリル'])
outputs = shiba_model(**inputs)
各種評価指標
元のCANINEとは以下の点で若干異なるとのことこと
- SHIBA uses windowed local attention, not the blockwise local attention used by CANINE.
- SHIBA does not have token type embeddings.
- There are very minor differences in how the downsampling of charater embeddings is done. The most important is that SHIBA will not truncate the last character of max-length sequences like CANINE will.
事実上の未知後が存在しないCANINEはseequence taggingとかNERとかで有利そう。
というかBERT系のNERが大変すぎるだけとも言うが...
元のCANINEとの相違点は実はよく意味がわかっていない
2021-03-24以降 v0.1.0がリリースされたことにより、LinuxかMacならば、単にpip installするだけでインストールできるようになりました。
pip install pyopenjtalk
使用方法
text = "こんにちは" phones = pyopenjtalk.g2p(text, kana=False) print(phones)``` ```k o N n i ch i w a```
ハイパーパラメータが高次元で計算量がかかる問題については得意。
ただし、探索空間が動的に変化したり、非同期処理系は不得手。
kurobakoというベンチマークをgithub actionsで自動的に走らせることでディグレをチェックする。
ただし、毎度0からベンチマークを走らせると時間がかかるので、サロゲートモデル(真の評価関数ではない代理の関数)を用いて探索を効率化させる。
入力値固有のバグが結構たくさんあるが、テストケースでカバーすることは不可能なので、自動でインプットを作成してバグが発生するケースを洗い出す手法をとっている。
機械学習系のAPIチェックをするのに、Fuzzingという手法は使えるかもしれない。
ハングリールートがほかのオンライン食品配達サービス会社と異なるのは、機械学習と予測モデリングを用いて、それぞれのニーズと目的に応じて顧客のカートに商品を入れる点だ。
同サービスにログインした顧客は、食習慣、食べものの好み、家族の人数などに関する調査を受ける。そうしたニーズに最も合うように、スマートアルゴリズムが毎週、カートいっぱいの新鮮な食品と簡単なレシピを提案する
推薦された72%の商品が実際に購入されている。
ほとんどの顧客は、食品を自分にかわって毎週選んでくれる同社をおおむね信頼しており、購入された全食品のうち、同社のアルゴリズムが選んだものは72%にのぼる。
お客様からは、ハングリールートを利用するだけで、週に平均22ドルを節約できるとの声が寄せられています。 献立作成、栄養サポート、自宅配送を完備した、顧客第一のパーソナライズされた食品ショッピング体験に対してお金を出しているのです。当社はそうした仕事を代行することで、お客様の手間を省き、時間とお金を節約し、頭痛の種を取り除けるようにしている
ハングリールートのような企業は、エンドツーエンドの食品購入体験を全面的につくり変え、消費者の買い物平均所要時間を、「週2~3時間」からわずか「2~3分」に短縮している。
半年ほど1人暮らしをしてみて、確かに買い物がだるく感じてきたのでありがたいっちゃありがたいのかもしれない。
cold start問題どんな風に対処してるのだろうか。
京都工芸繊維大学と高知工科大学は、機能的磁気共鳴画像法(fMRI)を利用した脳活動計測実験と参加者同士が対面して会話を行う行動実験により、初対面の男女が会話した際の相性を、事前に取得した脳機能データの類似度を用いた人工知能(AI)アルゴリズムによって一部予測可能であることを明らかにした
自己申告データでの相性マッチングには限界があることがわかっている。
利用者が自己報告した心理特性や嗜好などの情報に基づいた相性予測システムとするものを提供しているサービスもある。しかし、それらの大多数のシステムについて、先行研究では、100以上の自己報告データを用いても、異性間の相性を予測することはできないことが示されていることもあり、科学的な妥当性はないという。
そのほかの研究からも、自己報告による相手の好みと実際に選択した相手は必ずしも一貫しないことや、自己報告データの類似度と実際に会話した際に知覚した類似度は一致しないことなど、自己報告データを用いた相性予測の限界が示されていた。
実際に実験に参加したのは、20歳代の大学生43名(男性22名、女性21名)。参加者は、fMRIの計測装置中でスクリーンに提示される十字マークを見るよう指示され、その間の脳活動が10分間にわたって計測された。
会話課題では、目の前の異性の参加者と3分間の会話を行ったあとに次の席へ移動し、また目の前の参加者と3分間の会話を行うということを異性全員と話し終えるまで繰り返され、参加者はすべての会話終了後に、また話したいと思った異性を半数以上選ぶよう求められた。
実験終了後のアンケート結果から、お互いにまた話したいと思ったペアを相性のよいペア、それ以外を相性がよいとはいえないペアとラベリング。
Elastic-net正則化ロジスティック回帰によって、異性間ペアの類似度から相性のよし悪しを学習・予測し、統計的有意性について「パーミュテーション検定」によって検定が行われた。その結果、相対的に速い周波数帯の類似度を用いることで、異性間の相性を有意に予測できることが示されたとした。
今回の研究は、心理尺度などの自己報告データでは予測できなかった異性間の相性を、安静時機能的結合プロファイルの類似性から一部予測できることが初めて示された形だ。
研究チームでは、今回の研究における相性の予測精度や相性の定義は限定的とするが、将来的には他者との関係構築をサポートする手法として、今回の提案手法が活用される可能性があるとしている。
夢が広がる。がしかし、この脳活動計測機器が手軽に使える感じにならないとなぁ。
国交省が出していた京都東⼭地区の事例。
ナンバープレート解析以外にも以下の二つのトピックがあったが、今回はナンバープレート解析のみについて紹介。
その他解析事例
課題が3点ほど
ピントブレや白飛び、視界不良、オクルージョンなどで精度がブレる → 対応策、歩行者検知は一旦切ってズームする。
必要な機能ごとに、カメラのチューニングをするのは大事なんだなぁ。
照明問題は正直どうしようもない気がするが...
辞書型のobjectをd.key1.key2のように扱うためのライブラリ。
typeという関数を使っても似たようなことはできるがdict in dictに対応できないとのこと。
pip install attrdict
# from https://ohke.hateblo.jp/entry/2020/01/25/230000
from attrdict import AttrDict
d = {"key1": "value1", "key2": {"key21": 1, "key22": None}}
o = AttrDict(d)
print(o, type(o))
# AttrDict({'key1': 'value1', 'key2': {'key21': 1, 'key22': None}}) <class 'attrdict.dictionary.AttrDict'>
print(o.key1, type(o.key1))
# value1 <class 'str'>
普通にd["key1"]["key2"]と書いたり、d.get("key1").get("key2")と書くのだと煩雑な時に使うのだろうか?
この方法だと、複数の類似度から最も良いものを選ぶのが困難
# from https://qiita.com/thmd9726/items/5b096a32183247c6e35e
import nltk
nltk.download('wordnet')
from nltk.corpus import wordnet
def wordnet_sim_word(word):
synonyms = []
antonyms = []
for syn in wordnet.synsets(word):
for l in syn.lemmas():
if "_" not in l.name() and "-" not in l.name():
synonyms.append(l.name())
return list(set(synonyms))
word = 'have'
synonym = wordnet_sim_word(word)
print(synonym)
# 出力結果
# ['let', 'birth', 'possess', 'stimulate', 'have', 'ingest', ...
Lexical Simplification with Pretrained Encoders (2020)という論文に準拠したやり方。
面白い点は、単に[MASK]のある1文を入力するのではなく、答えのある1文と[MASK]のある1文をセットで入力していることです。こうすることで、予測される中で最も確率の高い単語がもとの単語と一致するようになります。
# from https://qiita.com/thmd9726/items/5b096a32183247c6e35e
def get_synonym_with_bert(text, masked_idx):
text_length = len(text.split())
masked_idx = masked_idx + text_length + 2
segments_ids = [0] * (text_length + 2) + [1] * (text_length + 1)
text = " ".join(["[CLS]", text, "[SEP]", text, "[SEP]"])
# Tokenize a text
# tokenized_text = tokenizer.tokenize(text)
tokenized_text = text.split()
# Mask a complex token which should be substituted
complex_word = tokenized_text[masked_idx]
tokenized_text[masked_idx] = '[MASK]'
# Convert inputs to PyTorch tensors
tokens_ids = tokenizer.convert_tokens_to_ids(tokenized_text)
tokens_tensor = torch.tensor([tokens_ids])
segments_tensors = torch.tensor([segments_ids])
# Predict a masked token
model.eval()
if torch.cuda.is_available():
tokens_tensor = tokens_tensor.to('cuda')
segments_tensors = segments_tensors.to('cuda')
model.to('cuda')
with torch.no_grad():
outputs = model(tokens_tensor, token_type_ids=segments_tensors)
predictions = outputs[0]
# Output top 10 of candidates
topk_score, topk_index = torch.topk(predictions[0, masked_idx], 10)
topk_tokens = tokenizer.convert_ids_to_tokens(topk_index.tolist())
# Visualize output probabilities
plt.bar(topk_tokens, torch.softmax(topk_score, 0).tolist())
plt.xticks(rotation=70)
plt.ylabel('Probability')
plt.show()
return topk_tokens
text = "the cat perched on the mat"
for i in range(6):
get_synonym_with_bert(text=text , masked_idx = i)
元の単語の確率が高くなっており、2番目以降から類義語を選択します。いい感じの類義語が取れていることがわかります。
類似度を求めされるのに、単純な[MASK]ではなく、元の文+[MASK]付き文を渡すやり方があったとは...
記事の通りだが、
# from https://qiita.com/Eliza_wb/items/6ac73679b6d2a2316a2b
RUN apt-get update && apt-get install -y \
uvccapture \
guvcview \
cheese
# from https://qiita.com/Eliza_wb/items/6ac73679b6d2a2316a2b
function launch_docker() {
local image_tag=$1
# GUI不要の場合、--deviceのみでOK
# GUI用にすべてのX接続を受け入れる
xhost +
docker run --privileged -it \
-e DISPLAY=$DISPLAY \ # Xの宛先をホストと同一に
-v /tmp/.X11-unix:/tmp/.X11-unix:rw \ # Xソケットを共有
--device /dev/video0:/dev/video0:mwr \ # カメラデバイスを共有
--device /dev/video1:/dev/video1:mwr \ # 複数指定も可能
${image_tag} /bin/bash
}
launch_docker image_tag
dockerで環境構築したものの、カメラデバイスを認識させられないという事象がよくあるため、助かる。
ただDocker for Macでは使えないという噂が...
重要なポイントは
- 機械学習によるビジネス成果(ここでは利益向上)は、この ai を通じてしか影響しえない
- aiは別に機械学習で決めなくてもよく、人間が赤ペンをなめて適当に決めても良い
ビジネスモデル(利益形式)の商売をしている場合、 家賃保証をする・しない2値分類問題の予測確率のしきい値は、この利益が最大になるようなしきい値を使ってやればよいということになる。 すなわち、ここではPrecision(とTP+FP)という評価指標が機械学習とビジネスを橋渡ししており、家賃保証する・しないを決める予測確率の閾値を制御することで条件付期待値の最大化問題を解き、利益を最大化することができるのだ!
この利益計算こそがビジネスの根幹であり、ある程度の分類はできるだろうが、それは会社ごとに異なるので一般論を打ち立て得ない
今自分が取り組んでいることが、ビジネスモデル上のどのアクセルに関わっているのかを意識するのが大事。
こと機械学習に関していえば、機械学習によって代替した意思決定が、最終的に売り上げにどう寄与するかの定式化を試みるのが大事。
表題の通り個人開発をする際の費用に何が必要になり、どう抑えられるかが書いてある。
個人的に気になったのは以下
必要な契約
- サーバー
- ドメイン取得
- メール送信サービス
- 決済サービス
Sendgrid 無料プラン 通数上限12,000通/月 Railsのメール機能を使ってもいいが無料枠が大きいので
Stripe 簡単なAPIで実装が簡単 クレジットなどの情報を持たなくて良いので安心 決済成立ごとに3.6%なのでランニングコストはゼロ
PRTIMESの無料枠 法人であれば24ヶ月もの間累計10件の記事が無料! (本来1記事3万円) このためだけに法人化していいかも
PR-FREE 個人でも何度でも無料でプレスリリースし放題!
PRTIMESって意外と安いですね。(効果があるかは別として)
dockerを介すとアプリのパーフォマンスが下がる事例の紹介
感想
機械学習エンジニア的に気になるのはファイルの読み書きのところ。 ファイルの読み書き性能が低いとあるが、これはホスト側のファイルを読み取るときに遅いんだろうか?
(バインドマウントとボリュームマウントでも違いが出そう :thinking: )
あんまり遅いと学習のボトルネックになりそうなので、素インスタンス上で環境構築したほうがいいのかなぁ?
出典
元ツイート
検証記事