Open GENZITSU opened 1 year ago
広告効果予測に際して、テキスト、画像にくわえて、広告音声も特徴量に加えられないかを検討した記事。
広告が配信されている Twitter や LINE などの各媒体毎に設定されている画像やテキスト,配信設定のデータが特徴量として用いられています.これによって,クリエイティブの視覚的情報や具体的な内容といった情報からクリエイティブの価値を考慮しているのですが,動画広告に含まれているBGMなどの音響情報は考慮されていません.
音響信号に特化した特徴抽出をするために、何か必要だという仮説が誕生 → 音響特徴を抽出するための事前学習を実施。
ここではCOLAという手法を採用。
これにより、ベースラインよりもval lossが4.9%改善し、offline indexも6%程度向上し、音響特徴をうまく抽出が、広告効果の予測に有効であるという可能性が確かめられた。
このCOLAはかなり単純な手法
以下のように音響信号から何らかの区間をとってきて、同じ信号からのサンプリングを正例、別の信号からのサンプリングを負例とみなして事前学習を行う。
精度
ちなみに、事前学習の際に、encoderの上にprojection headを重ねるのは、画像に限らず音声でも大事なよう。
仮説に沿って段階的に検証を進められていて、とても良い。
広告音声に特化した音響特徴を抽出できるように事前学習を適用してみたら、本当に精度が上がったというのは、domainごとに何らかの事前学習をする重要性をものがっている。
必要最低限のプロンプトのみを与えて、GPT-3に学術論文を書かせてみたら、たったの2時間で前文を書き上げ、それが今まさに査読されているらしい。
ちなみに、論文の投稿には著者ら全員の同意が必要なわけだが、これはGPT-3に以下のように問いかけて同意を取得。
After asking the AI if it had any conflicts of interest to disclose (it said "no") and if it had the researchers' consent to publish ("yes"), Thunstròm submitted the AI-penned paper for peer review to a journal she didn't name.
せっかくなので、実際の論文を見てみよう
すごい。違和感ないし、意味も通っている...
いくつかの候補promptから最も良さげなものを選んでいる模様
全文を読んでみるとわかるのだが、全く新しい知見を提唱しているかと言われるとそうでもなく、概念としてはsurvey論文に近い。
数式などを扱えるミネルバとかと組み合わせると、新しい知見の提唱までできるようになるのだろうか...?
少なくとも人が頑張っってsurvey論文各時代は終わりなのかもしれない...
チームパフォーマンス向上のためにzozoで実践されているコードレビューの取り組み紹介。
業務のサイロ化やチーム内でのレビュアーの固定化などの弊害を緩和し、チーム・ユニット間のコラボレーション濃度を上げるために実践。
Findy Temasを活用しgithub上の活動をモニタリングする。 以下の活動量を重点的にチェック
これらの指標をマネージャー陣だけではなく、チーム全員で確認するようにすることで、組織目標との紐付けを実施する。
レビュアーの負担を減らすための各種tips
チームの文化としてコードレビューを根付かせるための各種取り組みが網羅的にまとまっていて良い。
特にダッシュボードを活用して、コードレビュー活動をチーム共通の目的にするとことが大事なのかもしれない。
物体検出アルゴリズムでよく用いられるmAPの性質と問題点を指摘し、Optimal Correction Cost(OCC)という新しい評価指標を提案した論文がCAから発表された。
mAPが持つ性質
- 物体検出をデータセット全体における検出物体のランキングとして扱っている
- confidence scoreの低い誤検出の影響は小さい
- 各画像のAPに対する影響は平等ではない
- クラス識別が位置推定よりも重視される
- 評価時に参照する真値アノテーションが最適でない場合がある
mAPとは、クラスごとにデータセット全体で検出された物体をconfidence score順に並べてprecision recall curveを描いた時の下の面積を求めたAPをクラスで平均した指標。
ここで重要なのが、画像ごとではなく、データセット全体というところで、confidence score順に並べて精度評価していることから、データセット全体でランキング問題を解いているということに相当する。
mAPは物体検出をデータセット全体から見つけたオブジェクトのランキング問題として評価しています。この前提は物体検出を開発しているコミュニティでもあまり意識されていない点ではないでしょうか。この「データセット全体における」「ランキング問題」として物体検出を評価するという姿勢は、なかなかに強い前提です。
この性質が悪さをする例
detector Bは2番目の画像と3番目の画像に全く汎化できていないのに対して、detecor Aと評価指標上は区別がつかない。
detecotr cはアヒルの検出が全くうまくいっていないが、ロバの検出だけうまくいっているので、mAP上は評価が上にくる。 (confidenceが小さい誤検出に対するペナルティが甘い)
mAPが適しているケース: データセット全体からconfidence score上位何%をとってくるようなユースケース。
画像一枚一枚に対しての検出が成功することが大事なユースケースでは適当ではない。
誤差を含む検出結果を正解に修正するためのコストを元に検出結果を評価する手法。
ベースとなっている論文: OTA: Optimal Transport Assignment for Object Detection
一度修正コストを定義した後に、最適な修正コストを求めて、それを評価指標とする。
False positiveはdummyへと転送する
False positive detections are represented by a transportation from a detection to the dummy ground truth, and false negatives are represented by transportation from the dummy detection to a ground truth.
修正コストは以下のように定義
GIoUとはGeneralized Intersection over Union: A Metric and A Loss for Bounding Box Regressionという論文で提案された以下のような指標
どんな感じになるか?
いたずらに検出すると精度が悪化する感じ
mAP / OCCそれぞれでチューニングした結果
これまで提案されてきたモデルを再評価してみる
mAPが画像単位ではなくデータセット単位の指標であることは目から鱗だった。
OCCの方が一般的な物体検出のユースケースにあってそうではあるが、実装コードはどこかに公開されないのだろうか?
実装コードはこちらのページの[supp]にあった
detectronで学習したモデルに対して、元の解像度のまま入力するのと、リサイズ後に入力したのとで、全く精度が変わってしまった事例の紹介。
原因は以下
cv2.resize と detectron2 resize の、リサイズ後のピクセル補間方法の違いが原因だった。cv2の方がピクセル値がよりシャープになってた。そこからBlur かまして推論すると精度が良くなった。なるほどねぇ
根本原因としては、どんな水増しして学習してるかで、推論もそれに合わせろよと。今回の学習ではそんなシャープなピクセル学習してねえよって状態だったから、推論精度が悪かった。
問題設定
扱っているデータが白黒書類のデータで、文字や図形のピクセル値に敏感に学習してしまった、という背景
NNが学習する際に、resize特性も加味して学習してしまっていることがわかる。
これ系の話題で他に有用な記事は一足早い初夏のML怪談😱〜深層学習を使った画像の異常検知編かな。
Googleの働き方に関する研究から判明した、4つの重要事項の紹介
このブログが参考になるDevOps 文化: Westrum の組織類型
ここ数年ネットで見聞きしてきたような内容が、改めてまとめられている。 定量的になっている点は他社に説明する際に役立ちそう。
VSCode上でexcelファイルやcsvファイルをいい感じに可視化してくれる拡張 Excel Viewer の紹介。
表形式で見やすくしてくれるだけでなく、項目のソートや、フィルター機能もある。
普通に開くとこんな感じだが、
Excel Viewerを使うとこう
ソート機能など
コーディングしつつさくっとデータを確認したいときに便利そう。
機械学習システムを構成する際に検討すべき、ETL処理、デプロイ、リリース方法、運用監視方法がまとめられている。
aws glueはETL処理に関する諸々の機能を内包しているため、使い勝手が良さそう。
基本的にはバッチ処理 or 同期処理から考えるのがよく、データベースを境界に責任分解がしやすいバッチ処理が最も楽。
カナリアリリースなどを用いてユーザー影響をモニタリングしながら、徐々に対象ユーザーを広げていくアプローチが良い。
検討すべき事項がまとまっていて助かる。
議事録作成アプリ「CLOVA Note」がどのような技術要素を用いて開発されたかのインタービュー記事。
データセットの購入、LINEのプロダクトから取集されるデータ、人間による書き起こしをそれぞれ活用して、データが供給される仕組みを構築。
ここで収集されたデータを大量のGPUを用いて構築された学習基盤を使って、学習している。
木田: 精度向上のため、LINEは大量にデータを収集する体制を構築しています。たとえば特定の企業や機関からデータを購入したり、音声や動画を取り扱うLINEプロダクトのデータを活用したりと、さまざまな方法で音声の資源を集めてAIの学習に使っています。 とはいえ、やみくもにデータを集めれば音声認識の精度が向上するわけではありません。人間が書き起こした正解データもセットで用意する必要があります。LINEのグループ会社には書き起こしの作業を専門にしている組織があるのですが、それらのチームからデータ供給を受けており、正解データを用意する体制も整っています。
議事録作成の前段である、音声認識AI「CLOVA speech」ではSSLを用いて音声認識の精度向上を行っている。
LINEでも流石に教示ありデータを無尽蔵に作ることはできないので、音声データだけで学習が可能なSSLが活用されている。
Pre-trainingのフェーズでは、音声の一部を意図的に隠してその部分を周りの情報から予測させる、いわば穴埋め問題を解かせるようモデルを学習します。そうして学習したモデルを初期モデルとして、次のFine-tuningのフェーズで通常通り音声からテキストを予測するようモデルを学習します。
また、作成した教師有りデータ部分にも品質が微妙なものがこんにゅすることがあるので、それらを自動的にチェックする機構も作成した。
中込: Self-Supervised LearningにおいてFine-tuningを行なった際、学習データの中に品質が悪い音声や誤った正解ラベルが存在し、効果的に学習できないことがありました。そのため、それらの品質や正誤をチェックする必要があるのですが、学習にはトータル数千時間ほどの膨大な量の音声データを用いるため、人間がすべてを確認するのは不可能です。このような課題を解決するため、品質の悪いデータや正解ラベルの誤りを自動的に判定して削除するようなクリーニング処理も実装しました。
「CLOVA Note」では読み取った文字列に対して、自然な句読点を付与する機能がある。
その開発にもラベル無しの大量データでSSLを行ったBERTが活用されている。
ミヒャエル:話し言葉向けの句読点付与のモデルを開発する際に、私たちは自然言語処理の手法として、Self-Supervised Learningの一種であるBERTを用いています。この手法も、ラベルなしの文章データを大量に利用します。
ただし、ここで使用するデータはできるだけ自然な話言葉である必要があるため、ネット上から収集できる書き言葉を用いた事前学習ではあまりうまくいかなったらしい。
ここで、LINEのデータ収集フロート学習基盤が大事になるとのこと。必要なデータ数がえぐい。
さらに、学習に用いるデータはなるべくクリーン(ノイズ情報のない綺麗なデータ)である必要があります。つまり、なるべく話し言葉そのままの文章に近く、かつ綺麗なデータを大量に集めなければなりません。
テキストだけで数十〜数百ギガバイトくらいの規模のデータを学習に用いなければ、話し言葉の書き起こしに適切に句読点を付与するモデルは開発できません。また、それほど大量の文章データを処理するとなると、膨大な量の計算のためのマシンリソースが必要になります。
具体的にどう言った手法を用いてるかまでは明かされていなかったが、用途を限定しない音声認識アプリを開発するために何を整えていくべきかの方向性がわかる記事だった。
本番に強いモデルを作るために
訓練時とサービング時でモデルの性能が変化してしまう原因と応策をまとめている記事。
性能が変化する理由
対応策
distribution skew: 基本的には都度再訓練することになるが、何らかの仮定を置くことで訓練中にdistribution skewの影響を鑑みた学習を行うことできる。
その一つの方法が訓練時の特徴量分布とサービング時の特徴量分布を用いた重み付け。 (サービング時によく現れる特徴は重点的に学習し、そうでもない奴は軽くあしらう)
実際には重みβを求めることはできないので、例えばロジスティック回帰モデルを用いて訓練時とサービング時の判別を行わせ、スコアリングファンクションを用いて以下のような重み付けを行うことがある。
コメント
vertex AIは機械学習システムに必要なコンポーネントの実装が早いように感じる。AWSも負けないで欲しい。
出典
本番に強いモデルを作るために