weekly useful materials -05/25-

ドライブレコーダの動画を使った道路情報の自動差分抽出

サービス概要: 車両の検出や運転手の視線計測などを行い交通事故削減支援を行う。

追加PJTとしてZENRIN社と地図情報が古くなったかの情報提供を行っている。

技術的にはそこまで難しくない(大嘘)と思うけど、まずこのPJTの話を通せたことがすごいと思う。

このシステム作る上での工夫点が興味深かった。

複雑な処理を行うために、AWS Batchを利用。ECS, EKSもありだが管理コスト上の問題で除外したとのこと。

さらに、処理に依存関係があるので、オーケストレーションも工夫している。

インスタンスの選択は一枚の画像あたりのコストから選定している。 GPUはg4dn.xlarge, CPU処理はc4.xlargeが最もコスパがよいとのこと。

開発体制にもついても考えさせられる点が多い。我々ができているところ/出来そうなところなど整理したい。

出典リンク

ドラレコ映像を使った地図メンテナンスを支えるコンピュータビジョン技術

上の話題に関連して、どうやって2次元画像のdetection結果を地図情報と照合しているかについて。

Visual SLAMをつかって、車載カメラからの相対的な位置情報を算出する。

計算コストは高いが制度の高い手法としてStructure from Motionという手法もあるが、今回のケースだとVSLAMで十分とのこと。

私たちはVisual SLAMを採用しました。一般にVisual SLAMの精度はSfMに劣るとされますが、私たちは自前のデータで両者を比較し、私たちのユースケースでは大きな精度差がないことを確認しています。

それぞれライブラリは以下が良いらしい。

Visual SLAMの著名なOSSとしては、ORB-SLAM2やLSD-SLAMがあります。SfMのOSSではCOLMAPなどが有名です。

VSLAMで相対位置の軌跡がわかったら、GPSとの情報とマッチングをおこなってリアルワールドの座標に変換する。

タイムスタンプ粒度の差などはあるが、後処理かけたあとに、回転や並進、拡大縮小などのパラメータを最小二乗法で求めてやれば良い。

地図との比較

MLベースの手法なので当然誤差がでるが、「4m以上の誤差は地図が古いとみなす」的なことをやっている。やれてはいないが、複数回走行した結果の重ね合わせなども検討してるとのこと。

課題

VSLAM周りの課題が大きいらしい。

Visual SLAMについて様々な課題が見えてきました。最も大きな課題は、周囲環境の影響による処理の不安定性です。なんらかの理由により途中で追跡が途切れてしまうとそこからなかなか復帰できなかったり、あるいは時間方向に逐次的に推定していく過程で誤差が蓄積し、最終的に処理が破綻したりするようなことがあります。

対策として以下のようなことをしている。

映像を5分後おにわけて、独立にVSLAMを行う。

入力されたドラレコ映像をそのまま処理するのではなく、一旦短い映像の集まりに分割したうえでそれぞれに対して独立にVisual SLAMを適用するなどの工夫をしています。こうすることで例えば5分の映像の冒頭で特徴点追跡に失敗し、その後復帰できないことで5分全てが無駄になるような事態を避けることができ、また誤差の蓄積も小さく抑えることができます。その他、計算リソースに余裕がある場合は分割した映像単位で並列に処理すれば全体の処理時間も削減できます。

移動物体(他車両)のマスキング

Visual SLAMの原理的に、周囲に動くものがたくさんあると正しい推定ができないという課題があります。あらかじめ映像中から自車両以外の移動物体（他車両など）を検出し、その領域をVisual SLAMにおける特徴点追跡から除外することが考えられます。ここではディープラーニングを使った画像認識技術の1つであるセマンティックセグメンテーションが効果を発揮します。

感想

ML + 周辺技術の組み合わせが大事なんかなと。機械学習+地道な問題処理(アルゴリズムに)による課題解決を描けるようになりたいところ。

出典リンク

リヴァプールFCがDeepMindがサッカー x AI を模索している件

リヴァプールは2017～19年に戦ったプレミアリーグの全試合データをDeepMindに提供している。

センサー/GPS/CVを利用して、分析の幅を広げている。

ここ数年でセンサーやGPSトラッカー、コンピューターヴィジョンのアルゴリズムなどを用いて選手とボールの動きを追跡できるようになり、サッカーの分析に利用できるデータの量が大幅に増加している。チーム側にとってAIは、コーチが気づけないパターンを発見する助けになる。

特定の場面での選手の行動予測などが可能。

特定のチームとそのフォーメーションのデータを基にAIのモデルを学習させ、ある状況において選手がどのように反応するかを予測させる手法が紹介されている。例えば、マンチェスターFCと対戦する場合、右サイドにロングボールを蹴り込めば、同チームのカイル・ウォーカーが特定の方向へ走り、その間にジョン・ストーンズが別の動きをすることが予測される。戦術を変更した際の影響や、主力選手が負傷した場合の相手チームの行動などを予測する歳に有効だ。

AIキャッチャーよろしく、AI PKもやられている。

欧州全土で実施された過去数シーズン分の試合のデータから、12,000本を超えるペナルティーキック（PK）を分析している。選手をプレイスタイルやポジション別に分類し、その情報を基にPKを狙う場所や得点の可能性を予測したのだ。例えばストライカーはバランスのとれたアプローチをするミッドフィルダーよりも左下を狙う傾向があった。また、キッカーにとって最適な戦略は、当然ながら各自が最も得意とする側に蹴ることだと判明している。

反実仮想を用いた、理想的なプレーの推測は面白そう。

起きる可能性があったが実際には起きなかった「反事実」の状況に関する数値を高速で処理できる可能性もある。例えば、パスを出したりタックルをかわしたりといった特定のアクションがどれだけ得点に貢献するのかを示す指標「xG（ゴール期待値）」を推定したり

日々のトレーニングデータを用いた怪我の予測は実際にDeepMindとは別の事例がある。

選手のパフォーマンスデータ（体力や健康状態などの情報）を学習させたAIモデルなら、選手の疲労度を人間のコーチよりも正確に把握し、けがをする前に休息を促すことも可能

出典リンク

特徴選択にK-Foldを使ってはいけない。

某kaggle grand masterのツイートから引用

K-Fold CV、特徴選択時に使うと激しくoverfitするという地獄に気付いてからあまり使わないようになった。

holdoutだとimportanceで特徴選択しても別にoverfitしない（何故ならvalidの情報を使ってないので）んだが、K-Foldだとimportanceで特徴選択すると他のfoldのvalidの情報を使うことになるのでoverfitする。

mportanceを使わずに純粋な平均のスコアで特徴選択するのであれば悪くないと思うけど、そもそも特徴選択は計算時間を減らすために行うものなので本末転倒だし、計算時間も長過ぎる。よってhold out。

言われてみると当然だけど、タメになった。

別のgrand masterからの続き

自分は、基本K-Fold CVなので、その分特徴選択には毎度かなり気を遣っていて、Importanceで機械的に特徴選択するようなことはあまりやらないようにしてる。（自分は、特徴選択は計算時間を減らすため、という認識があまり無いので、結構時間をかけている。）

単純な例だけど、様々なパターンの集約特徴量を作って、なんとか_mean、なんとか_medianみたいな特徴量がたくさんできたとき、Importanceで切ると、一部の特徴は_meanだけ、一部の特徴は_medianだけ、一部の特徴は両方残る、みたいな状況が生じうる

よほどの理由付けが無い限りそれは気持ちが悪いし、それがCVに対するoverfitを生じるという認識。なので、上記の例であれば、特徴量全体に渡ってどちらかのみを採用するとか、

この辺りに気を付けてさえいれば、評価の意味ではCVの方が信頼に足ると思っているので、自分はそうしてる。ただしこれはsoloの場合。今回Indoorでteam組んで、アンサンブルさせる際の評価軸としてはhold outの方が圧倒的に安全（個人のCVスキルに依存しないので）と思ったりした。

K-fold CVによるoverfit = 「同じカラムから派生する、別特徴量」という認識のようだ。
ここら辺しっかり、CVできるようにならねば。。。

出典リンク

サイバーエージェントにおけるMLOpsに関する取り組み at PyDataTokyo 23

Cythonによる高速化あれこれ

Cython Complier Directivesに関しては公式ドキュメントが一番丁寧

cythonでc++ライブラリをラップする方法やメモリ管理の方法ものっていたのだが、難しすぎて理解できず。

optunaまわり

正直毎週自動でモデルを学習させ、かつそのモデルのチューニングをがをガンバらければいけないケースはかなり少ないと思うが、参考になった。こういう自動構築系は、train/val/testのスキームがマジでしっかりしてないといけない。

過去の探索をもとにCMA-ESの効率化を行うwarm start CMA-ESが提案されoptunaでも使えるようになった。

出典リンク

Mediapipeを活用したストリーミング推論の事例紹介

MediaPipe

ストリーミングメディアの推論に特化Google製のOSSで、tracking, detectionなどのpretrainedモデルが揃ってる他、前処理、モデルの推論、データ変換、図形描画等のcalculatorが準備されており、それらを組み合わせたパイプラインをグラフとして作成することが可能。
google meetsの背景ぼかしにも使われているとのこと。

MediaPipeにはsynchronization機能があり、読み込み→推論→描画の各タスクをスケジューラが管理されており、並列実行されるため、処理がスタックすることによる遅延が発生しづらい。

例えば30fpsで動作させたい場合、MediaPipeがないと前処理から描画まで全てを1/30secで実行する必要があるが、MediaPipeにスケジューリングされると、最も時間のかかる処理が1/30secで処理できれば、他の処理は並列計算することで30fps近いパフォーマンスを出すことができるというイメージ

独自の推論処理をパイプラインにも組み込むことができる。今回の事例だと物体の選別/商品のチェックが独自モジュール。

実装場の課題

計算負荷を減らし、端末が熱くなる

物体の追跡は毎フレーム行うが、物体検出は数フレームに一度だけ行うようにした

物体追跡は検出ほど重い処理ではありませんが、フレームレートを落とすとカメラの動きに追跡が間に合わず、カクカクとした動きに直結します。一方物体検出は数フレーム遅れても違和感はそれほどありませんでした。

さらに、特徴量抽出も新しいアイテムが検出された場合に一度だけ行うようにした。

工夫として、物体が検出されてはじめの数フレームは物体がブレがちなため、物体が検出されてから数フレーム後に特徴量抽出を行っている。

モデルサイズが大きい

精度とサイズのバランスからSSDLite-movilenetv2を使用。

さらに他クラス分類から物体の有無だけの検知(つまりクラス数を1にする)へ変更することで、モデルサイズと推論速度を向上。

これに＋αとして、モデルの量子化も実施。

TFLiteに用意されているモデルの量子化は以下。

ただし、uint8系の量子化は、quantization awate trainingを行わないと、場合精度が下がる。

今回はMedia Pipe的に、CPUしか使用出来ないことから、Float16 quantizationを利用した。

出典リンク

pinterestで行われているスパム判定

スパムURL / スパムユーザーをそれぞれ判定するのに加えて、クラスタリング、二部グラフによるラベルプロパゲーションを実施

スパムURL

モデルは手作業でラベリングしたデータを用いて反復的に訓練され、recallを高め、false positiveが少なくなるように訓練している。
URLのtokenは分かち書きを行うが、頻出tokenのみを使う。
URLの行動特徴量として、一定期間内のユーザーのアクセス動向を使っている。
PySpark, Tensorflow, Spark SQL, and a UDFをつかってデプロイしている。

UDFって何...?

スパムユーザー

最低限のハンドラベリングから人工的に作ったデータで学習している。特徴量としては、userの属性 / 過去の行動に加えて、スパムドメインに対するアクセス行動を特徴量とする。各ドメインがスパムかどうかは、一個上のモデルの出力も利用する。

こちらもPySpark, Tensorflow, Spark SQL, and a UDFをつかってデプロイしている。

クラスタリング

トレーニングスケジューラーが走る前の未知の流行パターンに対応するために、クラスタリングを行う。専門家が選定した秘伝のユーザー属性を特徴量に使用している。こちらはPySpark と SparkSQLを使って、1日ごとにバッチ処理している。

2部グラフの利用

少量のラベルデータと二部グラフをベースにしたlabel propagationを用いることで、半教師あり学習を行っている。

こちらはsparkを利用している。

出典リンク

Shopee - Price Match Guarantee の 10位解法の共有

タスク説明

画像とテキストから同じ商品を抽出するタスク。訓練データ中の同一商品であるペアがほとんど1しかなく、Private LBのほとんどが訓練データにない商品であった模様。

スクリーンショット 2021-05-29 10 35 02

基本的な解法

画像モデル：(何かしらのbackbone) + ArcFace テキストモデル： (BERT+ ArcFace) + TF-IDF

TF-IDFでもそこそこの性能が出るが、検索系ではBERT特徴量を使うのが最近のトレンドだとか

記事で紹介されていた解法

imageとtextのmodelを複数それぞれ学習させ、それらからEmbeddingを取得
1で抽出したEmbeddingを組み合わせたりしたものに対してQuery Expansion (QE)を行い、その結果に対してK近傍法 (KNN)で商品ペアの類似度を50近傍まで取得
2で取得した類似度を特徴量にしてLightGBMを学習
3で学習したLightGBMの予測値を重みとしたQuery Expansion (DQE)を図のABCとABCDEにのみ行う。
4の結果やLightGBMの予測値、TF-IDFの結果を組み合わせる + postprocess

その他Tips

ラベルクリーニング埋め込み表現で類似度0.9以上のラベルをまとめるなどの戦略が考えられるが今回は効果なし
画像特徴量 MultiScaleな特徴を抽出することで小さい物体にも大きい物体にも頑健なモデルをとするために、ResNet101Dの最終層の特徴mapだけでなく、中間層の特徴mapも抜き出してconcatさせたモデルが一番強かったです。さらに、modelの多様性のためにVision Transformerの一種であるswinを使用。普通のVision Transformerよりも遥かに精度が良く、アンサンブルにも一役かったとのこと。ただし、Vision TransformerをはNormalizeの値が通常のImageNetと違う点に注意。
テキストのクリーニングエスケープ文字, kgやmlなどの単位を抽出しその前の数字とのスペースを埋めるといった基本的なことに加えて、数字と単位を引っくるめて一つの単語としてTF-IDFに認識させることで、精度が向上
BERTの学習 BERTは画像モデルに比べてCatastrophic Forgettingという現象が起きやすいため、学習率のwarmupや学習率を小さめ(e-5オーダー)に取るといったことが必要となる
Metric LearningのTips 学習率のwarm upは大きめのほうが学習が進みやすい模様。 ← 学習の序盤だと普通のsoftmaxよりもクラス間の予測値の差が顕著に出ないため？

その他のTipsとして

marginを学習の間で徐々に大きくする
ラベルの個数で重み付けを行った学習をする
cosine softmaxを計算する部分の学習率を大きくする
勾配clippingを行う

ラベルの個数による重み付けは、今回の様なラベルの個数が少ない様なサンプルが多い場合には有効な模様。

それと、embeddingのアンサンブルをするときは、単純にEmbeddingの平均を取るやり方などが考えられるが、それぞれのベクトルをL2 Normalizeしてからconcatするという方法が最も効果が良かったよう。

Query Expansion (クエリ拡張) 画像検索系では定番の手法で以下のような関数用いて表現できる。
今回のタスクでは自分と同じ商品が必ずもう一つあるため、そいつベクトルとのquery expansionを用いることで、精度が向上。

(ベクトル自体は画像由来でもテキスト由来でもどちらでもOK)

def query_expansion(embeddings, similarity, alpha=3):
    """
    入力のshapeは、
    embeddings: [n_neighbor, n_feature]
    similarity: [n_neighbor, 1]
    を想定。
    """
    weights = similarity ** alpha 
    expanded_embedding = (embeddings * weights).mean(0)
    return  expanded_embedding

LightGBMの利用ベクトルの類似度 + 閾値では限界があるので、機械学習による判定を思いついたとのこと。

ただし、70000C50というふざけたペア数で普通には推論でいないので、cumlのForestInference[6]というライブラリを用いた。

出典リンク

GENZITSU / UsefulMaterials