なんのためにMLを使うのかを意識する　メルカリアプリにおけるエッジ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をかけ続けるみたいなストリーミング処理を行わせるときは、デモアプリですらけっこうメモリリークを起こしたりしているので注意して見たほうがいいですね。

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