Bonfire Data & Science #1 に参加しました。

こんにちは
2019年10月25日に開催された Bonfire Data & Science #1 に参加しました。
今回はその感想記事です。

イベント概要

コンパスページから

Bonfire Data & Science は データとサイエンスに関わる人たちが、情報共有を定期的におこなう勉強会/交流会です。

一言でデータサイエンスと言っても応用領域は広範囲であり、企業によっても働き方が異なります。 毎回、異なるテーマを設定し、各社のデータサイエンスの取り組みや課題について、気軽に意見交換ができる場を目指します！

ヤフーさんは最近よく勉強会を企画されていて素敵だなぁと思います。
ちなみに今回のテーマは「画像検索」でした。

約3行感想

• Approximate Nearest Neighborhood はどこも使っている気がしますね。
• スピードはやっぱり課題。
• エッジでのMLが進みつつある。
• コンテナ。
• DNNの後にフィルタ処理をするところも大事です。

メルカリの画像検索

最初はメルカリの方です。東大原田研で、インターンから19新卒だそうです。

ロジック

メルカリの画像処理には画像登録フローと画像検索フローがあって、検索フローは主に次のように進みます。

1. 物体検知
2. 特徴の抽出
3. 類似アイテムの提示

関連する3つの論文があり、それはメモれていません。こちらの記事 あたりを参考にしたらいいのかもしれません。

そもそも課題として、ファッション雜誌に載るような、人が服を着ている画像がでてくると、ユーザーの出品意欲が下がるそうです。ユーザーを考えてデザインするあたりサービス作っている感じがありますね。ですので、関連画像を検索する際に、以下の処理を行うことで、非着用画像の提示精度が向上しました。

• 画像から人の特徴量を差し引く
• 人の特徴量 = 着用画像 - 非着用画像
• 画像に人がいなかったら余計なので、ワントリックはさむ
  • ワントリックは覚えていません、笑
  • Min をとるか、正規化するとか素直な処理をしていたと思います。

画像を検索する際は、ANN で作ったインデックスを元に関連画像を見つけます。

インフラ

環境は Docker + Kuberbetes、GKE & EKS
学習にはバッチ処理の各工程をコンテナで行います。

• 依存の解消
• リソースは cron job で custom resource を作成する
• バッチ処理がログに残る、再実行しやすい

Next Future

• リアルタイムサーチしたい
• エッジで物体検知と特徴量選択やりたい

とのこと。実際にデモで検索がグリグリ動いている感じは便利そうでした。

その他

面白かったのは、全アイテムで同じモデルを使っていて、画像で足がクロスされていると学習精度が下がるそうです。物体検知がうまくいっていないということでしょうか。

ZOZOの画像検索

データ分析基盤とかをやっていた人で、主にML基盤の話でした。というかCloud Composerのツラミ。ちなみに ZOZO もヤフーグループになりましたね。

画像検索のプロセスはメルカリ同様でした。

• 物体検知
• 特徴量抽出
• ANN (またお前か、Spotify 製)

Google Cloud Next '19 Tokyo で発表もしているので、技術的な詳細はそちらも参照してほしいとのことです。

インフラ

• 基本
  • コンテナと Kubernetes
  • Dev と Ops の切り分け
• タスク管理
  • Cloud Composer
• 監視
  • Stackdriver
  • datadog
  • Sentry
  • k8s pod warning log

課題

キャッシュがあれば使っているものの、根本的にGPU部分で実行に時間がかかります。

• レイテンシーが大きい
  • 推論が長い
• トラフィックの増加に対応できない
  • GPU のスケールアウト

ですので、特徴量を返す部分で改善した、らしいです。詳細は資料を参照してください。

ツラミ

Composer のバージョンは上がっても中身の Airflow が上がらない...。Airflow は特定バージョン以降でないと GPU が使えないらしいです。Composer も比較的最近のサービスなので、仕方ないのかなと思います。GKEPodOearator と nvidia.com/gpu の相性問題を、BashOpで頑張ったり、DAG の SLA をタスクランナーで頑張ったりと、色々ツラミを聞きました。

Data Pipeline Casual Talk 向けですね、笑

ちなみに、福岡に ML プロトタイプの開発研究所があるんですね。
メルカリも LINE も福岡に拠点ありますし、盛り上がってますね。

ヤフーショッピングにおける画像検索

発表者の佐藤さんは、類似画像検索を使って、社内ハッカソンでも同じようなプロジェクトをやっているそうです。ウユニ塩湖に似た湖の紹介とか面白いです。

ヤフーショッピングのファッションで画像検索の仕組み

• 物体検知
  • Chainer
• 特徴抽出
• インデックス
  • ANN (またお前か、NGT)
  • そのうち Vald に移行する予定らしい
  • ベクトル最近傍探索エンジン
• 検索

NGT

NGT: Nearest Neighbor for Graph and Trees という OSS だそうです。Spotify が作った Annoy より高速・高精度らしいです。

学び

佐藤さんが大事だと思ったこと。

• 小さな変更、PR & リリース
• 自動デプロイ、自動テスト
• 制度の確認ツール
• 復旧可能な仕組み
• 監視、可視化

その他

物体検知で Chainer 使っていて、ZOZO も使っているらしいので、TensorFlow 以外も結構活用されていますね。最近だと、PyTorch もよく聞きます。
また、ML外だけど重要だと思った点として、類似画像検索API部分で、商品の削除や在庫の有無、などサービスとして必要な部分をきちんと作り込んでいるとことです。

NGT

登壇者の方は、元複写機メーカーの研究員で類似画像検索技術をヤフーに提供していたそうです。そして今はヤフーで研究開発しています。

髪を黒染めしてたけど、面倒になって脱色したら金髪になったとかいう、超個人的な話にクソワラタ

Neighborhood Graph and Tree for High-Dimensional Indexing

近似近傍法。量子化版もあるよ。昨今はデータも次元も多いから、ナイーブな KNN とかもはや使えないですよね。Gunosy も ANN 使ってるってブログで読んだ気がします。

ANN のベンチマークには　Spotify の Annoy 作った人のものがあるそうです。結果としては、グラフベースの検索が系統的に優秀で、だいたい NGT がいい、Annoy は悪い。ANN も勉強したいなぁ。

仕組み

ヨクワカラン

• DVP-tree で階層的に分割していく
  • ツリーができる
  • グラフの生成が全く分からなかった (イメージは分かるよ、イメージは)
• AkNNGraph
  • 無向
• ONNG
  • 有向
• 入次数を均一にすると検索精度が上がる
• 出次数を減らすと検索時間が減る

とはいえ、最適な次数はデータセットに依存するので、厳密には探索・最適化する必要があります。エンティティ間の近さを測るという、グラフの効果的な使い方の勉強でした。

要するに、DNNでベクトルデータの生成が容易に!! ANN でベクトルデータの類似度計算が容易に!!ってことですね (強引)。

終わり

久しぶりにこの手の勉強会に参加したので、新鮮でした。やっぱり、実務的な知見を得ることができていいですね (分かっていないことも多いですが)。ヤフーさんの勉強会はデザインとかもあって面白そうです。

ちなみに、知り合いが Data Gateway Talk とかいうデータサイエンティスト・データエンジニア・機械学習エンジニア向けのイベントやっているらしいです。興味があったらご参加ください、笑。