CLOSE

"Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod"がベストプラクティスだと思う理由(全2記事)

なんのためにMLを使うのかを意識する メルカリアプリにおけるエッジAIの実装・運用のポイント

Machine Learning Casual Talks #12 (Online)は、機械学習を用いたシステムを実運用している話を中心に、実践的な機械学習に関して気軽に話せる会です。メルカリのバーコード出品機能を例に、TensorFlow Liteを使ったエッジAIの実装・運用のポイントについて、大嶋氏が語りました。後半は運用について。前回の記事はこちら。

計測改善

大嶋悠司氏(以下、大嶋):結果です。アプリをリリースしましたが、タップしてくれる人は想定以上に少なかったです。さらにバーコード出品の増加率もほとんどなかったです。タップしてくれる人が少ないので、そもそも機能が使われていないので当たり前ですよね。

ここにいる方には当然かなというふうに思いますが、じゃあそのあと計測して改善していこうというフェーズが当然出てきますよねという話です。

今回、機械学習のモデルは、本かどうか。正確には本・DVD・ゲームか、それ以外かという二次分類でしかなくて、Image Classificationのタスクとしては非常に簡単なものでした。なのでちゃんとテストデータセットを用意して精度検証しても90パーセント近いPrecisionが出ています。なのでおそらくはモデルの精度をがんばるフェーズではないだろうという話になります。

じゃあモデルのレイテンシーはどうなのか。ということでいろいろな端末で検証してみましたが、それなりに古い端末でも30ミリsec前後で動いていることがわかりました。ということはそれほど体験を毀損しているとはこの段階では言えないということになります。

じゃあユーザーインターフェースがおかしいんじゃないの? という話になるわけです。まず一番簡単なところでは、ポップを表示している表示時間ですね。最初はデザインの段階で、あんまり長いこと出てくると邪魔に感じるお客さまも多いんじゃないですかねということで、4秒くらいかなというふうに感覚で決めましたが。

4秒って長いの短いの? ということを考えます。実際に各秒数でタップしたお客さまの数を計測します。4秒表示した場合だとこんな感じです。2秒が一番多いんですが、4秒以降ももしかしたらもっといるんじゃないの? という感じのグラフなわけですね。実際に8秒表示してみるとこんな感じに。ああやっぱり。半分くらいのお客さまは4秒じゃ足りなかったんじゃないの。というような結果になるわけです。なので表示時間は延ばしたほうがよさそう。

デザインの改善

さらに疑問が出てくるわけです。8秒くらいでタップしているお客さまがいるということは、お客さまってけっこう文言しっかり読んでいるんじゃないの? それでちゃんと伝わっていないんじゃないの? ということが仮説として出てきます。お客さまとのインタラクションは十分ですか? ということですね。最初のバージョンで表示しているポップはこんな感じでした。「本・CD/DVD・ゲームの場合はバーコードで出品できます」と。なるほど。我々はこれでもわかります。なぜならメルカリを作っている人間なので。

でもそもそもバーコード出品をしたことがないお客さまにバーコード出品を使ってほしいという意識からこれを作っていたはずで、バーコードで出品できますってそもそも何を言っているのかわからないじゃないですか? っていうこと。

あとデザインとして、「使用する」というボタンがあるんですけれども、これはボタンだと認識されていないんじゃないの? という非常に単純なところから疑問というか、仮説が立つわけですね。なのでデザインを改善しました。

まず文言を変えました。「商品のバーコードを読み取ると出品に必要な情報を登録できます」と。バーコード出品できますではなくて、バーコード出品するとこんなにいいことがありますよというような文言に変える。ここにボタンがありますよということをわかりやすくする。

改善の結果

非常に簡単な変更ではあります。ただこの改善でもAndroid、iOSともにバーコード出品数増加に貢献しました。実際、デザイン改善前と比べて改善後はその効果が倍以上になっていることが確認できています。改善版はすでにリリースされてすべての端末上で動いているはずなので、ぜひお手元の端末で確認してください。

UXを考えていくということ

つまり我々EdgeチームはもともとMLをモバイル上で使う営みをしていたわけではなくて、UXを改善する営みをしているんだということをきちんと意識しようねという話です。

ただそのときに、今回はモデルの精度とかモデルのレイテンシーというのはとくに影響は大きくないだろうという結論になりましたけれども、それらも含めてデザインとすべてを総合的にモニタリングしていきましょうということになります。

一応今やっている話もこのあとにあるんですけれども、時間がちょっとあれなので。駆け足でちょっと。

もっと前の段階から、UXってどういうふうに作っていけるんだろうという話を考えたときに、Googleが出しているPAIRと呼ばれるPeople + AI Researchで言われている話で……。

自動化っていうのと拡張っていうのがあります。AIによって自動化していいタスクと、ユーザーに主導権を任せるんだけれどもAIがサポートするようなUIがありますよね。というような話があります。今回我々はどちらかと言うと拡張というのにフォーカスしてやっていこうとしています。

例えば今メルカリではAI出品というのがあって、写真を撮るとカテゴリとかブランドとか商品名というのを自動で入力してくれます。これは自動化の例ですね。

ただそれだと、何を書くのかわからないお客様には非常に有効になるんですが……。実際出品行動のサポートはは責任を伴う。自分の売上に関わるし。どういうふうな文言を考えたいかというお客さまもビジョンを持っている話になるので……。もうちょっと拡張的なサポートができないかということで、Mercari IMEという機能を現在開発しています。

すでにABテストの最中で、一部のお客様にはこれが表示されている感じです。メルカリ特有のワードをIMEのようなかたちでサジェストする。それによって商品の入力とかを簡単にしていくという機能です。これについては今後どこかで話す予定ですのでまたみなさまにお話できればと思います。

駆け足になりましたが、以上です。ありがとうございます。

Q&A:サーバーサイドでのTensorFlow Lite

上田隼也氏(以下、上田):ありがとうございました。質問です。TensorFlow Liteなどはエッジ文脈で語られることが多いですが、サーバーサイドでも普通にけっこう便利なんじゃないでしょうか? サーバーサイドもTensorFlow Liteでやろうというチャンスはありますか?

大嶋:そうですね。TensorFlow Liteをサーバーサイドでも使うことは可能ではありますが、現状だと、普通にという言い方はアレかもしれないですけれども、TensorFlow Servingでチューニングしたモデルを動かしたほうがサーバーサイドではレイテンシーが低いはずなので、現状サーバーサイドで使うという予定はないですね。

上田:そうですね。あと量子化して速度が短くなっても、うまみがそこまであるのか感もありますね。

大嶋:そうですね。実際、量子化しちゃうと、サーバーも普通のIntelのx86 CPUだと量子化したものよりも普通にFLOAT32でやったほうが速いということになります。ARMのCPUでチューニングされたランタイムだからUINT8のほうが速いということになっていたはずですね。

Q&A:機械学習を使った理由

上田:なるほど、なるほど。次の質問です。わざわざ機械学習を使わなくてもほかのUI/UXの工夫でバーコード出品の利用率をもっと増加できそうな気がするんですけれども、機械学習を使うという意思決定はどういうふうにされたのでしょうか? という質問です。

大嶋:UI/UXの工夫でバーコード出品の利用率を増加できるという施策も、もちろんあります。ただこの施策についてはそもそも我々がまずエッジAI技術を使えるところはないかということで、今紹介したようなかたちで使えるんじゃないかという話で開発が始まったところがあります。

機械学習を使わないでUIのみでバーコード出品を増加させる施策も並列して走っていて、最終的に両方食い合うことはなくて、2つとも機能として載せたほうがバーコード出品の増加率は高いという結果になっているので、両方とも現状は乗せています。

なので機械学習のみでいく意思決定というのは、そもそも回っていなかったです。まあ難しいですよね。機械学習でやったほうがいいということって、実はそんなに多くないので……。意思決定は難しいと思いますね。

上田:そうですね。今回はいい感じに結果が出たからよかったねっていう感じですね。

大嶋:そうですね。

Q&A:full quantizationの大変な点

上田:次の質問です。full quantizationの大変な点を伺いたいですという質問ですね。

大嶋:full quantizationだと、さっき言ったように活性化関数が、この値が来たらこれを返すみたいなふうにマップを作らないといけないんですね。その際にRepresentation Datasetっていう、実際に来るであろうデータセットを表現するようなデータのサブセットを作って、それを入れて活性化関数の値を記録していくという作業があります。

そこでちゃんとしたデータセットを作れないと最終的な精度に大きく影響してしまうのと、メルカリの出品の画像のドメインが変わっていたときにそれをやるとモデルのメンテコストが上がるとか、いろいろな問題があったので今回は選んでいません。実際速度的に問題がある場合には、それをやる必要があるかなと思っています。

Q&A:FLOAT16やUINT8に変換したときの向上はどのぐらい?

上田:ありがとうございます。次の質問です。FLOAT32からFLOAT16、もしくはUINT8に変換したモデルの場合、学習速度や予測速度はどれくらい向上するのでしょうか? という質問です。

大嶋:学習時はFLOAT32なので、学習速度は同じです。FLOAT32で学習したモデルをUINT8だったりFLOAT16に落とすということをしますが、推論速度は、モデルの構造にもよりますが、どれくらいだったかなぁ……。すみません、ちょっと私の記憶ですが30パーセントから40パーセントほど高速化したはずです。

上田:なるほど。1.5倍、1.34倍くらいですね。

大嶋:そうですね。なのでFLOAT32だと80ミリsecとかでちょっときつかったのが……あ、違うか。50ミリsecくらいで、もうちょっと短くしたいねということで30ミリsecに落とせたということになります。

Q&A:TensorFlow Liteは端末やバージョンの違いを吸収するか

上田:次の質問です。iOS、Android、いろいろなバージョンや端末の差分があると思うんですけれども、TensorFlow Liteはそういった違いも全部吸収してくれているのでしょうか? という質問です。

大嶋:そうですね、問題なくと言うか、どちらも一定以上の新しさは必要になります。本当に古い端末だと動かないです。iOSはまだマシなんですよね。バージョンいくつ以上だったらオッケーというくらいになりますけれども。

Androidはそもそも使われているCPUが違ったりするのでアプリ側で、Androidのこのバージョンで、かつCPUがこういうアーキテクチャであるものという指定を書いています。なのですべて吸収してくれるっていうことはないですね。

上田:逆にTensorFlow Lite側は、アプリが落ちるとか、メモリリークしちゃうとか、そういうネガティブなポイントとかってあるんですかね? けっこう扱いに気をつけないといろいろ起きちゃうみたいな……。

大嶋:まず単純に電池消費が激しくなるので、電池消費量はめっちゃ気をつけないといけないポイントです。かなり恐れていたんですけれども、TensorFlow Lite起因での障害というかアプリの劣化というのは、現状は大きくは見られていません。とはいえ今回は写真を撮ってその画像を推論するというワンショットの推論なんですけれども。

例えば、動画にずっとobject detectionをかけ続けるみたいなストリーミング処理を行わせるときは、デモアプリですらけっこうメモリリークを起こしたりしているので注意して見たほうがいいですね。

上田:なるほど、なるほど。

Q&A:エッジ側のモデルのアップデート方法

上田:なるほど。では残り2つの質問でちょうどいい感じですかね。エッジ側のモデルをアップデートしようとする場合にどうやってデプロイするんでしょうか? 何が必要なのでしょうか? 

それからモデルのマネジメント。エッジで例えば、たぶんこういう質問だと思うんですけれども、モデルをアップデートしたい場合にどうやってコントロールするのかとか。という質問です。

大嶋:エッジ側のモデルのアップデートはそうなんですよ。そのとおりで難しい問題ですよね。今現状、実はさっきのバーコード出品のサジェスト機能は、アプリにモデルを同梱して配布しています。なので単純にアプリのサイズが増えています。

ただモデルのアップデートにアプリのアップデートも必要になるのは今後あまり良くないだろうという話になっているので。そこはあとからCDNから配布するとかする必要があるというふうに考えています。

その場合、なにかしらのメタデータをこちらで用意して、この端末はこういうアトリビュートの、例えばCPUはなにで、Androidバージョンはなにだよみたいな情報をサーバー側に送信して、それにちょうどいいモデルを配布するというような仕組みを現状考えています。

ただ、まあ、これは今考えているところなので、実際運用してみたらどうなるかはちょっとまだわからないですね。

上田:iOS用のTensorFlow LiteとかAndroid用のTensorFlow Liteみたいな?

大嶋:そうですね。それはやっぱりモデルもそれによって違うとかだとかっこいいじゃないですか(笑)。

上田:AIっぽいですよね(笑)。

Q&A:Mixed Precisionについて

上田:最後の質問です。学習時にMixed Precisionとかは試されましたか? と質問です。

大嶋:やっていないです。そこらへんまで十分にキャッチアップができていないのでMixed Precisionがどれくらい効果があって、どれくらいよいものなのかというのは、まだちょっと我々のチームでも検証が十分できていないので今回はとくに試していません。

上田:なるほど。じゃあもしみなさんがメルカリをインストールされると、手元に、もう自動的にTensorFlow Liteのモデルがインストールされると。

大嶋:そうですね。10年前とかの端末じゃなければたぶん動くと思います。

上田:いいですね! TensorFlow Liteで最低のAndroidのバージョン保証とかってAndroid5以上とか、そういう感じなんですかね?

大嶋:すみません、今ちょっとすぐには出てこないですが、まあそれくらいです。あとはAndroidのCPUが64じゃないと動かないという制限をかけています。そっちのほうがたぶん強いですね。それで最近のそれなりに新しいスマホということになります。

上田:みなさんもTensorFlow Liteの動きを確かめるためにメルカリをインストールしてもいいかもしれません。

大嶋:ぜひ使ってみてください。

上田:今日はありがとうございました。

大嶋:ありがとうございます。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!