目次
Bonfire Data & Science #1にブログ枠で参加してきました。 ということで、メモです。
- 日時 : 2019/10/25 19:00 - 21:30
- 場所 : Yahoo! Japan
- サイト : https://yj-meetup.connpass.com/event/148121/
- ハッシュタグ: #yjbonfire
概要
Data & Scienceとは? データとサイエンスに関わる人達の情報共有のための勉強会/交流会
サイトから引用です。
第1回のテーマは「画像検索」です!
最近EC系のサイトで類似画像検索が出来るようになったけどどうやってるの?
画像検索のモデルってどうしてるの?
画像検索のインフラはどうしてるの?
私たちの会社でも画像検索を用いたサービスを構築できるだろうか?
こういった疑問に答えたり、いま抱えている悩みを解決するヒントを得る場になればと思っています。
今回は、画像検索を行なっているヤフー, メルカリ, ZOZOテクノロジーズの3社に事例と基盤技術について登壇いただきます。
QAはこちら。https://app.sli.do/event/w3wayjmv/live/questions
Mercari画像検索について(仮)
-
発表者:荒瀬晃介(株式会社メルカリ / AIエンジニアリングチーム)
-
AIエンジニアチーム
-
写真検索プロジェクトのTech Lead
-
iOSのみで提供の写真検索
-
システムオーバービュー
- MobileNet v2で特徴抽出
- ANNのインデックスを使ってDBに入れる
-
論文も発表済み(3本)
- 今日の発表はこの内の2本を元に話をします。
C2Cでの問題点
- 商品は床やテーブル上で撮影
- クエリは着用(着ている)画像が使われやすい。
- 人が写ってる写真が結果に多いと業者が出展しているように見えてしまう。
提案手法
- 人が写ってるものから人の代表ベクトルを抜き取る (クエリ時にのみ処理を実施しているので変更が容易)
- 特徴変換ベクトル
- トップスなど、分類ごとに学習させてからベクトルを構成
- なんでMobileNet v2?
- エッジデバイスでの処理を見据えて選択
インフラ
-
Docker + k8s
-
CRDを使ってる?
-
training
- コンテナベースパイプライン
- いくつかのバッチ処理を工程ごとにパイプライン化
- バッチ実行情報をカスタムリソースとしている=再実行が簡単(復旧作業が容易)
- 画像を扱う=ダウンロードが時間がかかる -> 復旧しやすいようにPVにある程度キャッシュさせている
- コンテナベースパイプライン
-
Serving…
- GCP側
-
なぜ2つに別れてるんだろう?実際のサービスも2つに分かれてたりするんだろうか?
将来の展望
- Realtime Image Search
- カメラでものを写している状態でそれが何かを検索できる。
- 物体検出+特徴抽出をエッジで行うためできる
- エッジの性能により違いが出てきたりするっぽい
QA
- Q: 業者が想定されると、購入意欲を下げるというのは実験した結果?それとも想像?
- A: 実験はしていないが、e-commerceにおいての研究がある
- Q: どういう理由でマルチクラウドにしたんでしょう?
- A: 画像のマスターがAWS。メルカリのマイクロサービスはGKEなので、サービング環境がGCP
- Q: 画像の内、服のエリアが大部分で体の面積が少ない場合と、メガネや帽子のように、アイテムの方の面積が少ない場合で、トレーニングに必要なデータ数は変わりましたか?
- A: カテゴリによる性質の違うはある。ので、改善は必要。
ZOZO画像検索について(仮)
-
発表者:平田拓也(株式会社ZOZO / AIエンジニアリングチーム)
-
(聞き逃した。。。)
-
WEAR
-
マルチサイズ
チーム構成
- 研究所+ML Opsチーム
使用しているアルゴリズム
- 物体検出アルゴリズム
- 特徴量抽出アルゴリズム
- 近似最近傍探索(approximate nearest neighbor, ANN)
インフラ
- GCPを採用。
- BigQuery上にデータ基盤がある
- Managed GPUが必要
- なんでk8s?
- コンテナ
- Cloud Runがなかった
アーキテクチャ
- マイクロサービス化されている
- Google Cloud Next 2019 Tokyoでsonotsさんの発表があるよ
監視項目
- CPUなどは見ていない
- レスポンスタイムとステータス監視
- リクエスト数
- APM
- 使ってるものStackdriver + Datadog + Sentry
- Warningが30分で続けたら通知などができるのがStackdriver
画像検索の改善のためにやっていること
- 課題
- レイテンシーが大きい
- 推論が大変?
- 急激なトラフィックの増加に対応できない
- GPUのスケールアウトが問題 -> 先行投資が必要
- レイテンシーが大きい
- 流れ
- キャッシュありなし
- 物体検出 (GPU)
- 特徴量抽出 (GPU)
- 近似最近傍探索
- DBから取得
2と3が問題
- 2と3を特徴量DBという形でデータが登録された時点で特徴量などを計算してしまうことでGPUへの依存をなくした。
- Apache AirFlowが便利?
Cloud ComposerとApache AirFlow
Cloud Composerに関するいくつかのTipsがありました。
QA
- Q: 推論をCPUでやったらどれぐらい遅いんだろう
- A: GPUインスタンス代金 < それと同等の速度を出すためのCPUインスタンス代金
- Q: k8sスケールアウト時のリソース割当を最適化する為、resource limit / request標準化 or 時系列分析などから自動調整するなどはされていますか?
- A: …聞き逃した
- Q: (TCOを考慮したクラスタ構成) Cloud Composerの値段が高いようなパプリッククラウド利用の課題対策としてプライベートクラウドとのハイブリッド構成にされているのでしょうか?もしハイブリッド構成でしたら、パブリック or クラウドを切り分ける基準はございますか。
- A: GKEオンリー
- Q: cloud composerでairflowを使う辛い点は?
- A: 不安定さ。。。
Yahoo!ショッピングにおける画像検索(仮)
- 発表者:佐藤 純一(ヤフー株式会社)
- 商品検索APIの開発とか検索エンジンの保守とか
- 類似画像検索システムの開発が直近の仕事
類似画像検索
- ヤフーショッピング
- 3億の商品
- ファッション系はビジュアルが重要=言語による表現が難しい
- iOSとAndroid
- Androidだとカメラで撮影してから検索みたいなことも可能
システム概要
- 物体検出
- ノイズ除去
- 特徴抽出
- インデックス(NGT) -> https://github.com/yahoojapan/NGT
- 1000万件を超える
- 検索
- アプリの画像をAPIに投げてベクトルから、近いものn件を取得
ベクトル化/インデックス更新
- GPUマシン
- Kafka使ってる
- クラウドストレージに日次?バックアップみたいに保存
- 差分更新の仕組みがある
- メンズとレディースは分けている
- 絞り込み検索のために分離(インデックスのメタデータとしてタグがある)
システム構成
- Python
- Kafka
- TensolflowServing
- 可視化?監視?はGrafana+Prometheus
開発を通しての学び
- 自動デプロイとかテスト
- 検索精度の確認ツールを作る
- コレ重要だよね。何が変更してるかとか、何が正しいかってのが必要だし。。。
- 復旧可能、早期復旧の仕組みを容易
今後の方針
- 対象商品の拡大
- 物体検出特徴抽出モデルの性能改善
- NGTの検索システムをValdに移行
- Vald
- k8s上で動作、分散検索、分散インデキシングなどの機能を提供予定
- Vald
QA
- Q: iOS(既存の画像)とAndroid(カメラで撮る)で画像検索の方式が違うのはなぜ?
- A: アプリの違い
- Q: 1枚の写真に沢山写っている中で、対象の商品をどう識別しているんでしょう。靴もトップスもボトムスも写っていたら、かなり難しそう
- A: Yahooブラウザの場合は1番大きな領域のものを選択。Yahoo shoppingだと選択可能
NGTについて(仮)
- 発表者:岩崎 雅二郎(ヤフー株式会社)
- 類似画像検索を20年くらいやってる
近傍検索ライブラリ
-
https://github.com/yahoojapan/NGT
- 高次元ベクトルの近傍検索
- ツリーとグラフによるインデックス
-
近傍検索とは?
- 距離空間上でのクエリの近傍のオブジェクトを取得
- k最近傍検索(通常はこっち)
- 範囲検索(あんまり使われない)
- 距離空間上でのクエリの近傍のオブジェクトを取得
-
NGTの特徴
- 世界トップレベルの高速高精度な近似近傍検索
- OSS
- 追加削除が可能(削除がとくに難しいらしい)
- 多様な利用形態(Python、C++、C、Go、コマンドライン)
- サーバ版NGT(ngtd、vald)を提供
- 共有メモリ版でメモリサイズ以上のデータ登録可能
- 量子化版NGT(NGTQ)により。。。
-
ANNベンチマークによりテスト
- 実行環境が決められているらしい。誰が実行しても比較可能
- グラフベースの検索の仕組みのほうが性能がいいというのがベンチマーク結果からわかる
なんではやいの?
- インデックス生成
- ツリー(グラフの探索起点の取得に利用する。DVP-tree)
- グラフ(ANNG)
- ノードを逐次追加しつつ、近傍ノードを検索してから接続するというのを繰り返している
- 検索
- ツリーから絞り込みつつ、グラフを検索する
- ANNGに課題があるのでONNG(Optimized Nearest Neighbors Graph)に
- ノード単位の次数(入出)を最適化
- データセットによって有効な次数が違う。。。
NGTを利用した深層学習で。。。
- Yahoo!ラボ FavNavi
- 特徴量の構成(低次特徴量(300次元)、カテゴリ特徴量(128次元)、領域アスペクト比(1次元))
- 個別の特徴量だけだとイマイチな結果になるが、組み合わせるといい感じになる
モデル性西洋学習データ
スライドがあればいいなぁ(表書くの大変だし。。。)
QA
- Q: 実際のお客さまの利用を考えると、近似近隣の密度が異なるので、近いものばかりの検索結果や遠いものも含んでしまった検索結果が出ると思うのですが、遠いものが含まれてしまうと、閾値でフィルタしたりするのでしょうか?
- A: NGTは近いものしかないので、外れ値ってなんでしょう。。。
- 検索のフィルタリングをある程度している(カテゴリとか)。
- A: NGTは近いものしかないので、外れ値ってなんでしょう。。。
まとめ
慣れない分野の話を聞きながらざっとメモを取ったものなので役に立つかはわかりませんが。。。
アルゴリズムとかまでは得意ではないんですが、画像「検索」ということで参加してみました。 実際に画像検索の仕組みがどんな感じでできているのか、どんな技術がつかわれているのか?ってのがわかったのは 面白かったです。確かに検索のためのキーワードって出てこないことあるしなぁと。 あー、こんなかばんほしいとか、これなんだろ?みたいなのあるからなぁ。
comments powered by Disqus
See Also by Hugo
- 第11回Solr勉強会を主催しました。#SolrJP
- 第12回Solr勉強会を主催しました。#SolrJP
- Riak Meetup Tokyo #2に参加しました。#riakjp
- 第5回Elasticsearch勉強会を開催しました。#elasticsearchjp
- 今年もオンラインでBerlin Buzzwordsに参加した