目次
■人工知能（AI）と機械学習
2022.09.08 2024.03.12 約4分
国内最大級 ITエンジニア向け勉強会プラットフォーム connpass においてグループ人数 No.1 の Forkwell Community。 機械学習の「つぎの一歩が見つかる、気づきと学びの場」ML Study シリーズから2022.06.14開催のML Study #5「物理空間を扱う機械学習技術」Q&Aセッションをレポート！
【質問全文】ベクトル近傍検索は大変魅力的でしたが、Googleぐらいのデータ量を持っていないと、活躍できないのでは、と勝手に想像してしまいました。どのぐらいの規模から、活用できそうかといった話があれば教えてください。
佐藤： さすがに数百件くらいだと厳しいかもしれませんが、ベクトルをどう作るかによります。
極端な話、機械学習などを使わずにデータベースからベクトルを直接持ってくるようなルールベースで作るのであればデータ量は関係ありません。基調講演で紹介した3次元のベクトルの例であれば機械学習を使わなくてもベクトル検索で使えます。また Deep Learning との組み合わせによって今時ならではの使い方ができます。BERT や Transformer のような大きいものを使わなくても、小さいモデルでも使えます。
こちらのメルカリの事例を紹介します。
「メルカリShops」を支える Google のベクトル検索技術
メルカリショップスはマッチングエンジンを本番導入もしていただいて、使用モデルは Word2vec です。
出品されているメルカリショップスの商品の説明文章のエンベディングを使って、類似検索をするという事例です。通常は Transformer や BERT を使用するという話になると思いますが、実際に試したら Word2vec で十分軽く、それなりの性能が出たので採用しました。
Word2vec は2レイヤーくらいしかないので、 Deep Learning モデルではありません。データ量も数万件くらいあれば十分に学習できます。要件や扱うモデルによってデータ量も決まるので、Google のように何十億件もないと使えないわけではありません。
taguro： 商品のレコメンドなど、ある程度ミスをしても誰も傷つかない部分では近似近傍が使えるかなと思っています。
反対に認証や認可などは、厳密近傍が適しています。例えば iPhone の顔認証で、顔が似ているからといって解除できてしまうと危険ですよね。
佐藤： マッチングエンジンが提供するのは近似近傍なので、取りこぼしがあります。弊社のScaNNというアルゴリズムは Recall Rate が98%とかなり高いものの、残りの2%は取りこぼしてしまう可能性があるので使い方を選びます。
レコメンデーションや YouTube の動画を探したりする場合はいいのですが、ある一定の距離のなかのベクトルを必ず探してこいというような用途には向いていないと思います。
taguro： 顔認証でも厳密近傍にこだわりすぎると、システムやビジネスのスケールが技術的に困難になります。我々のようなユースケースでは、解候補となる大量の特徴をインメモリで保持し、計算ノードを分散させる必要性等が出てきたりします。そういった仕組みを自分たちで研究開発し、メンテナンスし続ける必要性があります。そのため、どこかのタイミングで近似で解けるような問題設定に落としこみ、Vertex Matching Engine のようなものに載せられたらいいなと考えています。
佐藤： 組み合わせ技も面白そうですね。まず近似で（レスポンス性を良くするために）1番目立つ人たちをマッチングエンジンで探して、時間が経ってから厳密解が UI上で更新されるなど、要件によっていろいろ考えられると思います。
pao： 私が参加していたプロジェクトでもベクトルの近傍検索はレコメンデーションや検索系などでおこなっていました。掛け算なので規模が大きくなってくるとパターン数が飛躍的に大きくなります。例えばレコメンドはアイテム1万、ユーザーが1万だと合計1億パターンになります。このようなときに近傍をいかに早くするかはとても大事です。
Vertex Matching Engineはまだ使ったことなかったので、使ってみたいなと純粋に思いましたね。
これまでも Python ライブラリのFace Recognition などを使用することはありましたが、大規模な場合や耐えきれないような場合はかなり使えるのではないかと思いました。
佐藤： 私もScaNNのファーストオーサーの方といろいろ話しましたが、あまりわかりやすい説明ができなくて……。結局インデックス（インデックスコードブック）を作るんですけどそのときに代表として選ばれる真ん中のベクトルがあります。そこからの距離をとって、その領域を決めるんですね。その領域の決め方を機械学習のモデルでやってるわけですね。そのコードブックを作る機械学習モデルの loss の関数の取り方が一般的な距離の取り方じゃなくて、内積を最大化（ミックス）するような、Anisotropic Lossっていうのを使ったところ飛躍的に性能が高くなったって言われて、それってなんかもっとわかりやすい例えなんですかねって聞いたんだけど、「いやいや内積を最大化するんだ」としか言ってくれなくて（笑）
私のブログには、分かりやすい説明は書けませんでしたが、リサーチチームのやっている数理的な改善により、State of the Art が実装できています。
佐藤： 「MatchIT Fast」からどなたでも簡単にお試しいただけますので、画像をアップロードしてみてください。検索品質がいいものと悪いものを体感できると思います。裏側ではモバイルネットをそのまま使ってるので検索品質はあまりよくありませんが、ざっくりレスポンスや動きを確認できると思います。
gepuro： 仕組みをいろいろと試せるのはとても楽しそうですね。
【質問全文】個人を識別できるようなレベルの、顔に関する特徴量を保存することは個人情報の観点から問題ない（同意されている）のでしょうか？ベクトル化しているとはいえ、画像が復元できてしまいそうな気がするので、個人情報として扱うべきなのかなと思いました。
taguro： 技術の進化に対して法整備が追いついていないケースの一つだと感じています。現在は法律ではありませんが、総務省・経済産業省が「カメラ画像利活用ガイドブック」を策定し、国としての考え方・指針が示されています。
ガイドブックでは例えば、以下のような言及がされています。
弊社ではガイドブックに準拠する形をとっています。
我々もガイドブックが公表され、社内のシステムやオペレーションが準拠できたタイミングでサービス（顔特徴量を用いたリピート分析機能）のプレスリリースを打っているので、もしカメラなどを使って世の中にサービスやプロダクトを届けようとしている方がいましたら、カメラ利活用ガイドブックを参考にしてください。
経済産業省：2022年3月30日 カメラ画像利活用ガイドブックver3.0
gepuro： カメラ画像のガイドブックのみならず、AI活用のガイドブックなど種類は豊富ですので、興味のある方は探してみてください。
一方で、データを使う側としては、カメラが置いてあると裏側でいろいろ使うんだろうなってのはすぐ推測できますが、抵抗感がある人から店頭のカメラ設置を見て会社や店舗に問い合わせはくるのでしょうか？
taguro： 件数としてはかなり少ないのですが、問い合わせをたまにもらうことがあります。
カメラの利用目的が「防犯目的」から「マーケティング領域」に染み出しつつある中で、社会の認知や法整備が進み、買い物体験がよくなり、最終的に消費者にもメリットがある形で社会実装が進んでいくことが個人的にベストだと思っています。
gepuro： 画像に限らず個人情報の観点はいろいろあると思いますが、Google さんの場合、画像や個人情報を守るにあたり、どのような取り組みをしていますか？
佐藤： もう本当に Google の AI のサービスって、そういったところを本当に厳しく問われるところなんですよね。個人情報の保護プライバシーと公平性ですよね。両方が厳しく要求され、設計上に反映されています。具体的には最近はスマートスピーカーで顔認識してGoogleアカウント切り替えたりしますが、ああいう認識って全部デバイス側でやったりしてるんですよね。
その中でも、登録されているGoogleアカウントの中で例えば今近くにいる人は誰なのかっていうのを推測したりするんですけども、それがデバイス側だけの閉じた世界でできるようなモデルの縮小などを工夫しています。Googleでは Federated Learning と言われる生データをクラウド側に持っていってそこで学習をガーってやるって方法をしないようになっているんですね、プライバシーのデータなので。エッジ側で特徴量を抽出して個人の特定ができないような統計情報として、または特徴量の情報だけをクラウド側に送ります。全体としてこういう特徴量の人はこういう使い方をしているね、みたいなモデルを学習してまたエッジ側に返すという Federated Learning などの形で本当にできるだけ個人情報を生で扱わないというのが使命や課題になってます。
佐藤 一憲（グーグル合同会社 Google Cloud デベロッパーアドボケイト）
Google Cloudのデベロッパーアドボケイトとして、機械学習やAI系プロダクトの開発者支援を担当。Google Cloud Next、Google I/O、NVIDIA GTC等の主要イベントでスピーカーを務め、Google Cloud公式ブログに多数の記事を寄稿。またGoogle Cloud開発者コミュニティを10年以上にわたり支援している。
taguro（株式会社ABEJA プラットフォームグループ マネージャー）
産業技術高専卒業後、首都大学東京に編入学。高専在学中は、超小型人工衛星の開発、医療機器に関する研究に携わる。理化学研究所では、放射線飛跡観測に関する実験システム構築及び中性子イメージングの画像処理研究、大学では量子効果デバイスに関する研究に従事。2015年ABEJAに入社、小売流通業向け店舗解析サービスABEJA Insight for Retailのサービス基盤の設計開発に従事。現在はABEJA Platformの開発・運用チーム及び技術広報のリーディングを行う。
pao（株式会社ABEJA データサイエンスグループ マネージャー）
趣味で麻雀AIを作ったことをきっかけに機械学習の道に入る。前職では画像認識を用いたアプリの開発や機械学習を用いたユーザプロファイリングに従事。2020年5月にABEJA入社。データサイエンティストとして多くのプロジェクトに携わった後、2021年12月より同マネージャー。業務の他にもデータサイエンスコンペに積極的に参加。KaggleMaster/atmaCup3回優勝。
gepuro（早川 敦士）（株式会社DATAFLUCT）
2010年よりデータサイエンスに取り組み、2015年に新卒でリクルートコミュニケーションズに入社。その後、株式会社FORCAS(現 ユーザベース)にて、アルゴリズムやデータ基盤の開発を担当するリーダーを務める。US事業ではテックリードとして携わった。2022年1月にDATAFLUCTに入社し今に至る。PdM兼テックリードとして勤務。技術評論社よりデータサイエンティスト養成読本, オライリーより機械学習のための特徴量エンジニアリング ――その原理とPythonによる実践などを執筆。
Google Cloud デベロッパーアドボケイト
Google Cloudのデベロッパーアドボケイトとして、機械学習やAI系プロダクトの開発者支援を担当。Google Cloud Next、Google I/O、NVIDIA GTC等の主要イベントでスピーカーを務め、Google Cloud公式ブログに多数の記事を寄稿。またGoogle Cloud開発者コミュニティを10年以上にわたり支援している。
プラットフォームグループ マネージャー
産業技術高専卒業後、首都大学東京に編入学。高専在学中は、超小型人工衛星の開発、医療機器に関する研究に携わる。理化学研究所では、放射線飛跡観測に関する実験システム構築及び中性子イメージングの画像処理研究、大学では量子効果デバイスに関する研究に従事。2015年ABEJAに入社、小売流通業向け店舗解析サービスABEJA Insight for Retailのサービス基盤の設計開発に従事。現在はABEJA Platformの開発・運用チーム及び技術広報のリーディングを行う。
データサイエンスグループ マネージャー
趣味で麻雀AIを作ったことをきっかけに機械学習の道に入る。前職では画像認識を用いたアプリの開発や機械学習を用いたユーザプロファイリングに従事。2020年5月にABEJA入社。データサイエンティストとして多くのプロジェクトに携わった後、2021年12月より同マネージャー。業務の他にもデータサイエンスコンペに積極的に参加。KaggleMaster/atmaCup3回優勝。
;?>/images/ico/ico_blank.svg){kind=spacer}
