<p>メルカリで写真検索とEdge AIチームに所属している澁井（しぶい）です。機械学習のモデルを本番サービスに組み込むための設計やワークフローをパターンにして公開しました。<br />
GithubでOSSとして公開しているので、興味ある方はぜひご笑覧ください！<br />
PRやIssueも受け付けています。私の作ったパターン以外にも、有用なパターンやアンチパターンがあれば共有してみてください！</p>
<ul>
<li>
<p>GitHub：<a href="https://github.com/mercari/ml-system-design-pattern">https://github.com/mercari/ml-system-design-pattern</a></p>
</li>
<li>
<p>GitHub Pages：<a href="https://mercari.github.io/ml-system-design-pattern/README_ja.html">https://mercari.github.io/ml-system-design-pattern/README_ja.html</a></p>
</li>
</ul>
<h2>なぜ機械学習システムのデザインパターンが必要なのか</h2>
<p>機械学習モデルが価値を発揮するためには本番サービスや社内システムで利用される必要があります。そのためには機械学習のワークフローおよび関連ソフトウェアと運用を設計し、ソフトウェアに組み込むのですが、これらの開発には機械学習以外のスキルや知見が用いられます。たとえば、設計にもデータ取得、前処理、モデルによる推論、後処理、エンドユーザへの見せ方やUI/UX、学習パイプライン、リリース判定基準、監視通報など様々な知見が必要になります。<br />
機械学習エンジニアや研究者がImageNetを使って正解率の高い画像認識モデルを開発していていても、ソフトウェアエンジニアリングのスキルを身につけることは難しいでしょう。中にはシステム開発やソフトウェアエンジニアリングに興味がない方もいるでしょうし、職務上不要な場合もあるかもしれません。他方でソフトウェアエンジニア（アプリエンジニア、バックエンドエンジニア、SRE含む）が機械学習に詳しいと限りませんし、機械学習とシステム開発の両方でスキルや経験を持ったエンジニアは至極稀でしょう。</p>
<p><figure class="figure-image figure-image-fotolife" title="猫か犬か判定する機械学習システム全体像の例"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20200422172511.png" alt="f:id:shibui-yusuke:20200422172511p:plain" title="f:id:shibui-yusuke:20200422172511p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>猫か犬か判定する機械学習システム全体像の例</figcaption></figure>
</p>
<p></p>
<p>機械学習システムデザインパターンでは機械学習エンジニアとソフトウェアエンジニアの間のスキルギャップを埋め、機械学習の作法とシステム開発の作法を統合するためのノウハウを整理します。機械学習を用いたシステムを開発するゴールは、多くの場合、機械学習モデルを本番システムで稼働させてビジネスに貢献するというものになると思います。そのためには機械学習独特の技術やワークフローを理解し、事業運営できる形でシステムに組み込む必要があります。「機械学習のモデルやワークフローを本番システムで稼働させる」作法をパターン化して説明するのが機械学習システムデザインパターンの目的です。</p>
<p><a href="https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf">“Hidden Technical Debt in Machine Learning Systems”</a> という論文に以下の図が掲載されています。機械学習をシステムとして動かすために必要なコンポーネントと規模の概念図になります。機械学習のコア部分は小さな黒四角で、その他のシステムが周囲に大きく描かれていることがわかると思います。</p>
<p><figure class="figure-image figure-image-fotolife" title="機械学習システムの隠された技術的負債"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20200422172657.png" alt="f:id:shibui-yusuke:20200422172657p:plain" title="f:id:shibui-yusuke:20200422172657p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>機械学習システムの隠された技術的負債</figcaption></figure>
</p>
<p>本論文は、機械学習を有益に使うためには機械学習以外の部分を開発し運用する必要がある、ということを説いています。機械学習自体が重要ではないと主張したいのではなく、機械学習の効果を発揮するためには機械学習以外の要素が必要になる、ということです。ビジネスで機械学習を使うためには、機械学習のロジックをWebサービスやシステムに組み込まれなければなりません。全てのシステムにはビジネス評価と運用が必要になります。システム一般として、リソース管理やインフラが必要になりますが、これに加えて監視通報やバックアップがあると良いでしょう。機械学習システムには、機械学習モデルを稼働させる推論システムと推論システムへのアクセスが必要になります。更にデータロギングと分析、可視化、学習パイプライン基盤があると、より高度な開発、運用が可能になるでしょう。全てを揃える必要はありませんが、機械学習モデルを本番システムで稼働させるために、どのリソースをどう組み込むか、コスト対効果や関連システムとともに設計して構築することが肝要です。</p>
<h2>機械学習システムデザインパターンの構成</h2>
<p>機械学習システムデザインパターンは以下のカテゴリに分類して執筆しています。</p>
<ul>
<li>
<p>学習パターン：学習パイプラインの作り方</p>
</li>
<li>
<p>QAパターン：テストやQAの方法</p>
</li>
<li>
<p>サービングパターン：推論器を本番システムに組み込むパターン集</p>
</li>
<li>
<p>運用パターン：モデルやシステムの運用方法</p>
</li>
<li>
<p>ライフサイクルパターン：上記各パターンを組み合わせた機械学習システムの全体構成</p>
</li>
</ul>
<p>各カテゴリではシステムとしての機械学習のライフサイクル（学習、品質検証、サービング、運用）を実現する構成を説明しています。加えてライフサイクルパターンでは学習、QA、サービング、運用を組み合わせた機械学習システムの全体設計例を説明します。</p>
<p>各パターンを以下の項目で説明します。</p>
<ul>
<li>
<p>ユースケース：パターンの使いどころ</p>
</li>
<li>
<p>アーキテクチャー：パターンが解決しようとしている課題や説明および設計方法</p>
</li>
<li>
<p>図：パターンの全体像を図解</p>
</li>
<li>
<p>利点：パターンによって得られるメリット</p>
</li>
<li>
<p>難点：パターンによって発生するデメリット</p>
</li>
<li>
<p>検討項目：パターンを使う際に気をつけるべき項目</p>
</li>
</ul>
<p>本番システムで機械学習を使うために必要な情報を使いどころから設計指針、メリット・デメリット含めて整理しました。加えて、各カテゴリにアンチパターンを用意しています。</p>
<h2>機械学習システムのデザインパターンが目指しているもの</h2>
<p>機械学習システムデザインパターンではプラットフォームや言語、ライブラリにとらわれず、一般的なクラウドサービスまたはKubernetesクラスターで機械学習システムを構成することを想定したパターンを用意しました。クラウドサービスやKubernetesクラスター、または社内環境によって選択するリソースは異なるでしょうが、どの基盤でも可能な限り基本的なアーキテクチャは変わらないようにパターン化することを目指しています。</p>
<p>私はメルカリに2018年7月に入社し、MLOpsエンジニア（またはSysMLエンジニア）として働き始めて以降、多様な機械学習のシステム開発と運用に携わってきました。約2年弱でメルカリで稼働している機械学習システム（モデリングおよびインフラ含む）のほとんどに、何らかの形で参加してきています。企画段階から携わっているプロダクトもあれば、リリース後に運用から参加したシステムもあります。いきなり障害対応から入ったプロダクトもあります（笑）。そうした経験から得てきた知見をドキュメント化したのが機械学習システムデザインパターンです。メルカリというWebサービスビジネスで、基盤にはクラウドサービスとKubernetesを使うという条件に特化した知見になっている箇所も多くあるでしょう。今後は各クラウドサービス（AWS、GCP、MS Azure…）を使った構成パターンやKubeFlowを使った場合のワークフローを整理し、より汎用的かつ実用的なパターンを揃え、機械学習界隈を盛り上げていきたいと思います！</p>

機械学習システムの設計パターンを公開します。

<p>こんにちは。AIチーム所属ソフトウェアエンジニアの<a href="http://twitter.com/chahan69">@shido</a>です。</p>
<p>機械学習は様々なサービスの中で強力な武器となりますが、データパイプラインの構築や学習のための計算リソースの確保など、リーズナブルにシステムに組み込むには機械学習特有の困難を克服しなければなりません。</p>
<p>またその困難は機械学習の応用先によっても様々だと思っています。今回の記事ではデータパイプラインの構築に「<b>Human-in-the-Loop (HITL)</b>」と呼ばれる機構を違反出品検知のための機械学習システムへ取り入れた実例と、この仕組みについての考察をお話します。</p>
<p></p>
<p>もくじ</p>
<ul class="table-of-contents">
<li><a href="#違反出品検知システムについて">違反出品検知システムについて</a>
<ul>
<li><a href="#メルカリの安心安全公正な取引環境への取り組み">メルカリの安心・安全・公正な取引環境への取り組み</a></li>
<li><a href="#ポリシーの変更について">ポリシーの変更について</a></li>
<li><a href="#不正取引の潮流の変化について">不正取引の潮流の変化について</a></li>
</ul>
</li>
<li><a href="#機械学習システムによる違反出品の検知">機械学習システムによる違反出品の検知</a>
<ul>
<li><a href="#機械学習による違反出品検知の強みと課題">機械学習による違反出品検知の強みと課題</a></li>
<li><a href="#継続的なモデルアップデートの重要性">継続的なモデルアップデートの重要性</a></li>
</ul>
</li>
<li><a href="#Human-in-the-Loopについて">Human-in-the-Loopについて</a>
<ul>
<li><a href="#違反出品検知システムにおけるHITL">違反出品検知システムにおけるHITL</a></li>
<li><a href="#どのような機械学習システムがHITLを必要とするのかについての考察">どのような機械学習システムがHITLを必要とするのかについての考察</a></li>
</ul>
</li>
<li><a href="#最後に">最後に</a></li>
</ul>
<h2 id="違反出品検知システムについて">違反出品検知システムについて</h2>
<p>本題の違反出品検知システムの話をする前に、我々メルカリが機械学習を違反出品検知に利用している目的やシステム化する際に考慮しなければならない事柄について説明させて頂きます。</p>
<h3 id="メルカリの安心安全公正な取引環境への取り組み">メルカリの安心・安全・公正な取引環境への取り組み</h3>
<p>メルカリではお客さまに安心・安全・公正なマーケットプレイスを提供するために様々な取り組みを行っております。(詳しくは<a href="https://about.mercari.com/sustainability/safe-secure-and-fair-transactions/">会社HP</a>にて)<br />
そのような取り組みの一つが機械学習システムによる違反出品の検知となります。<br />
このようなシステムを活用しメルカリでは違反商品をお客さまの目に触れる前に可能な限り早く、出品者様に理由をお伝えすると同時に出品停止・削除させて頂いております。</p>
<h3 id="ポリシーの変更について">ポリシーの変更について</h3>
<p>メルカリでは法令・社会的変化に合わせて出品物に対するポリシーをアップデートしています。これは不正な取引の検知の質を高めるためには必要不可欠なことですが、機械学習エンジニアリング的には最も辛いポイントとなります。</p>
<p>一般的に機械学習モデルは学習データが多ければ多いほど良いものとなりますがポリシーの変更はときにデータのラベルの定義の変更を意味することになります。実運用ではこのような時に人手でラベル付け直し！というわけにはいかないので、なかなか難しい課題です。</p>
<p>対策としては階層的ラベリングのような予め変更をある程度吸収できるようなラベルの付け方を設計できると良いのではないかと個人的には考えています。</p>
<h3 id="不正取引の潮流の変化について">不正取引の潮流の変化について</h3>
<p>上記の通りメルカリでは社会的変化に合わせポリシーをアップデートしていますが、プラットフォーム上で行われる不正取引の数や分布も日々変化しています。</p>
<p>下の図はシステムが検知したある違反種別の違反出品数と時系列を描画した図になります。線が上にあるほど違反数が多かったことを表します。</p>
<figure class="figure-image figure-image-fotolife" title="違反出品数と時間"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20200319183638.png" alt="f:id:mercari-shido:20200319183638p:plain" title="f:id:mercari-shido:20200319183638p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>違反出品数と時間</figcaption></figure>
</p>
<p>ある日突然平常時の30倍以上の値を観測したため、弊チームでもざわめきが起こりました。<br />
調べてみると日本国内でとあるイベントが開催されていたことが原因でした。<br />
このケースでは我々のMLシステムが検知できましたが、もしカバーできないような新たな不正があった場合は可能な限りMLシステム側でも対応できるよう対応したいものです。</p>
<h2 id="機械学習システムによる違反出品の検知">機械学習システムによる違反出品の検知</h2>
<p>ここまで違反出品を検知するシステムの一部に機械学習を組み込んでいることに触れてきましたが、実際どのようなメリットと課題があったかについてまとめました。</p>
<h3 id="機械学習による違反出品検知の強みと課題">機械学習による違反出品検知の強みと課題</h3>
<p>機械学習を違反出品検知に実運用する一番のメリットはやはり精度の向上です。メルカリでは機械学習システムの他にもルールベースによる検知など他の仕組みも存在しますが、これらの仕組みでは検知しきれなかった商品も機械学習を用いることで検知することができています。</p>
<p>では機械学習特有の課題に目を向けると、冒頭で触れたデータの確保、計算資源のマネジメント<a href="#f-e97a3084" name="fn-e97a3084" title="我々のML違反検知システムでは内製のMLプラットフォーム「Lykeion(リュケイオン)」を利用し、計算資源を動的に割り当てながら行う学習をGitOpsにより実現しています。
Lykeionについては過去の投稿「メルカリの写真検索を支えるバックエンド」で紹介されています。
">*1</a>、再学習の必要性、ルールベースよりはるかに重い推論コスト、解釈性の欠落、テストの設計などが思い浮かびます。</p>
<p>特にデータに関しては機械学習システムの性能に直結するため細心の注意を払い設計しなければならない部分です。先程ポリシーの変更や不正取引の潮流の変化について触れましたがこのあたりをデータパイプラインに入れる工夫が非常に重要でした。ポリシーの変更は正解ラベル定義の変更と同義ですので、変更があった場合は変更前のデータは一切使われるべきではありません。一般的にこの正解とすべき変数が移り変わってしまう問題は「<a href="https://en.wikipedia.org/wiki/Concept_drift">Concept Drift</a>」と呼ばれています。我々のデータパイプラインではこのような変更を機械的に処理し、データセットのラベルを変更する仕組みが実装されています。</p>
<p>DNNのような表現力の高いモデルを利用する場合はおかしなデータが少量混じるだけでBoostingTree系のような頑健なモデルに簡単に負けてしまいます。したがってデータのパイプラインは我々が最も慎重に考えていることの一つです。</p>
<p>また、機械学習システムの評価も非常に重要です。メルカリは2020/02/07時点、累計11億出品と、多くのお客さまに利用頂いています。その中で不正が疑われるのはこの中のごく少数であり、そのためテストの設計も通常の機能と同じ様に行うことができません。</p>
<p>一般的に、機能や機械学習モデルの評価をする場合ABテストなどを行いメトリクスの変化を測ることが多いと思いますが違反検知の場合はそもそも検知の対象が少ないため、メトリクスの分散が非常に大きくなりがちです。そのため、違反検知モデル間での評価を正しく行うためには一般的な機能のABテストに比較して統計的に妥当性があるかどうかをより緻密に考慮しなければならないと思っています。</p>
<h3 id="継続的なモデルアップデートの重要性">継続的なモデルアップデートの重要性</h3>
<p>先程データパイプラインの設計に触れましたが、ポリシーの変更をハンドルできたとしても実際に取引プラットフォームで行われている不正取引の潮流の変化にも対応する必要があります。</p>
<p>これは定期的な再学習によってある程度解消することができます。下の図はモデルの性能を時系列で描画した図になります。上にあるほど性能が良いことを表します。色の違う線はそれぞれ別のバージョンとなります。</p>
<figure class="figure-image figure-image-fotolife" title="機械学習モデルの性能と時間"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20200319182504.png" alt="f:id:mercari-shido:20200319182504p:plain" title="f:id:mercari-shido:20200319182504p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>機械学習モデルの性能と時間</figcaption></figure>
<p>少しわかりにくいかもしれませんが、2つのモデルが同時に予測している期間を除くと、モデルがリリースした時点が一番性能が良く、その後徐々に下がっていることが分かるでしょうか。これは取引の潮流の変化により、過去のデータセットの分布から正解の分布がずれてくることによるものだと考えられます。</p>
<p>このことより、最新のデータで継続的に再学習を行っていくことの重要性が分かるかと思います。我々のシステムではCronJobにより定期的にモデルの再学習が行われています。</p>
<h2 id="Human-in-the-Loopについて">Human-in-the-Loopについて</h2>
<p>ここまでにデータに関する課題について何点か触れましたが、これらの解決に必要不可欠だと考えているものが<a href="https://livebook.manning.com/book/human-in-the-loop-machine-learning/chapter-1/v-5/8">Human-in−the-Loop(HITL)</a>という仕組みです。</p>
<p>Human-in-the-Loopとは本来機械学習に限らずシミュレータなどのシステムの中に実際の人間が入り込みモックアップなどを果たすことを指すようですが、近年では機械学習の文脈で、機械学習モデルと人間が補完し合いながら動作するシステムを指して使われているのをよく目にするかと思います。</p>
<h3 id="違反出品検知システムにおけるHITL">違反出品検知システムにおけるHITL</h3>
<p>下の図はメルカリで動作している違反出品検知システムの概略を示した図です。</p>
<figure class="figure-image figure-image-fotolife" title="違反検知システムの概略"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20200319182756.png" alt="f:id:mercari-shido:20200319182756p:plain" title="f:id:mercari-shido:20200319182756p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>違反検知システムの概略</figcaption></figure>
</p>
<p>我々のシステムによって検知された違反商品はカスタマーサポートのオペレーターが必ずすべて確認します。これは違反検知システムのミスで商品が違反ではないにも関わらず通報されてしまった商品(False Positive)を実際に消してしまわないためのものでもあるのですが、このときのログを利用することで機械学習モデルの性能を大きく向上させることができます。</p>
<p>メルカリにおける違反検知のように予測を行いたい対象が時間経過によって頻繁に変化する場合、固定されたデータセットから学習を行うだけでは長期的に精度を維持することは難しいでしょう。しかし我々のシステムではデータの流れに人間が介入するため、判定するべき対象とその他との境界に位置するデータに対してのアノテーションを継続的に入手することができます。このように蓄積された正確で新しいデータを用いてモデルの再学習を行うことで機械学習システムの精度が保たれています。</p>
<p>次に全く新しい違反が現れた場合の話をします。違反検知システム全体で機械学習の他にルールベースなどのシステムも存在しており、人手により変更を加えることで新しい違反に対応します。機械学習はデータが無い状態からの対応は難しいですが、ルールベースシステムがCSオペレーターに候補を送信することでMLモデルへのラベルを新たに蓄積し、このラベルからMLモデルが新しい違反を学習することができます。</p>
<p>更にもうの1つ大きな利点はオペレーターの作業ログを設計することでポリシーの変更にも対応できることです。ポリシーの変更に伴い無効となってしまう教師データがどうしても存在してしまいますが、予めうまく切り分けられるログを残すことで急なポリシーの変更に対して無効となったデータを最小限の大きさでデータセットから除外することができます。これも大きな利点の1つです。</p>
<p>このように我々の機械学習違反検知システムではHITLが機能することで良い性能を保っています。</p>
<h3 id="どのような機械学習システムがHITLを必要とするのかについての考察">どのような機械学習システムがHITLを必要とするのかについての考察</h3>
<p>個人的にはConcept Driftが頻繁に発生するプロジェクトではHITLによる継続的な教師データの修正が大きく性能を向上させると思っていますが、一般的なWeb系の機械学習プロダクトは”Human”の部分がサービスのお客さまであり、お客さまの行動データがうまくラベルなどになるように設計されているものが多いのでは無いかと思います。例えばリコメンドなどは予測したいものが顧客が買いそうなものや観そうなものとなるはずですが、これらのデータはアノテーションのコストをかけずとも実際のお客さまの行動データを参照すれば明らかになるはずです。</p>
<p>当然ですが人を介入させる場合にはコストもかかりますし、実際に第三者の導入を検討する前にお客さまの行動がそのままデータとなるループが作れないかを検討するべきなのかもしれません。</p>
<h2 id="最後に">最後に</h2>
<p>大雑把かもしれませんが、機械学習におけるHuman-in-the-Loopとデータ周りについてメルカリにおける実例を交えて紹介いたしました。今後ともメルカリではお客さまの安全な取引のために努力して参りますので、安心してご利用頂ければと思います。</p>
<p>もちろんメルカリではデータ周り以外にもML違反出品検知システムについて様々な努力を行っています。以下の過去記事にて触れておりますので、ご一読頂ければ幸いです。</p>
<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.mercari.com%2Fentry%2F2019%2F05%2F10%2F120000" title="マルチモーダルNeural Architecture Searchを用いて出品違反検知モデルの作成を高速化したお話 - Mercari Engineering Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://tech.mercari.com/entry/2019/05/10/120000">tech.mercari.com</a></cite></p>
<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.mercari.com%2Fentry%2F2019%2F09%2F12%2F130000" title="Multimodal Information Fusion for Prohibited Items Detection - Mercari Engineering Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://tech.mercari.com/entry/2019/09/12/130000">tech.mercari.com</a></cite></p>
<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.mercari.com%2Fentry%2F2018%2F04%2F24%2F164919" title="マルチモーダルモデルによる不正出品の検知 - Mercari Engineering Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://tech.mercari.com/entry/2018/04/24/164919">tech.mercari.com</a></cite></p>
<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.mercari.com%2Fentry%2F2019%2F02%2F28%2F142843" title="複数の機械学習モデルが動くシステムをモデルごとにマイクロサービス化したお話 - Mercari Engineering Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://tech.mercari.com/entry/2019/02/28/142843">tech.mercari.com</a></cite></p>
<div class="footnote">
<p class="footnote"><a href="#fn-e97a3084" name="f-e97a3084" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">我々のML違反検知システムでは内製のMLプラットフォーム「<b>Lykeion(リュケイオン)</b>」を利用し、計算資源を動的に割り当てながら行う学習をGitOpsにより実現しています。<br />
Lykeionについては過去の投稿「<a href="https://tech.mercari.com/entry/2019/03/25/120000">メルカリの写真検索を支えるバックエンド</a>」で紹介されています。<br />
</span></p>
</div>

機械学習とHuman-in-the-Loopで優勝する違反検知の話

<p>皆さん、こんにちは機械学習エンジニアの <a href="https://twitter.com/hurutoriya">@hurutoriya</a> です。</p>
<p>2018/05/09 にメルカリが開催した Kaggle Competition である「Mercari Price Suggestion Challenge」の閉会式を行いました。<br />
「Mercari Price Suggestion Challenge」では実際に米国版メルカリで販売された商品データを公開して、参加者の皆様に商品の値段推定精度を競い合っていただきました。</p>
<p><a href="https://mercari.connpass.com/event/84299/">Mercari Kaggle Competition: Closing Ceremony 2018 &#8211; connpass</a></p>
<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20181109005757.png" alt="f:id:hurutoriya:20181109005757p:plain" title="f:id:hurutoriya:20181109005757p:plain" class="hatena-fotolife" itemprop="image"></span></p>
<p>この閉会式は「Mercari Price Suggestion Challenge」の上位者(ロシア・ポーランド・中国)と日本人上位入賞者を招待して、各種上位者の解法やKaggleに対する考え方をパネルディスカッション形式でお話を聞かせていただきました。<br />
今回はカーネルオンリー(計算機資源と計算時間の制約)というルールも相まって、面白いコンペになったのではないかと思います。</p>
<p>当日のパネルディスカッションの動画も公開準備を終えたのででこの場をお借りして共有させていただきます。</p>
<p></p>
<h3>Part1</h3>
<p><iframe loading="lazy" width="480" height="270" src="https://www.youtube.com/embed/1ZIFPu0T1iM?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><cite class="hatena-citation"><a href="https://www.youtube.com/watch?v=1ZIFPu0T1iM">www.youtube.com</a></cite></p>
<h3>Part2</h3>
<p><iframe loading="lazy" width="480" height="270" src="https://www.youtube.com/embed/7SX6v2hIKbc?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><cite class="hatena-citation"><a href="https://www.youtube.com/watch?v=7SX6v2hIKbc">www.youtube.com</a></cite></p>
<h2>メルカリにおける値段推定</h2>
<h3>メルカリにおける値段推定の重要性</h3>
<p>まず、なぜ値段推定がメルカリにおいて重要なのかを解説します。<br />
フリマアプリ「メルカリ」は、お客さまが自由に値付けを行った後にメルカリ上で出品されます。</p>
<p>この値付けに関連する問題として分かりやすい例では</p>
<ul>
<li>メルカリの相場から外れて、高い値段で出品した場合売れない</li>
<li>逆にメルカリの相場より低い値段で出品してしまった場合、お客さまが損をする</li>
</ul>
<p>が考えられます。</p>
<p>解決策として、</p>
<ul>
<li>自分が出品予定の商品をメルカリ内で検索して相場を調査して調べる</li>
</ul>
<p>などがありますが、これでは</p>
<ul>
<li>お客さまに大きな手間がかかる</li>
<li>そもそもメルカリに登録直後のお客さまはそんなことを思いつかない</li>
</ul>
<p>そのため、<code>出品時に商品情報から適切な値段を自動的に提示する</code>ことで出品時の手間を削減し、更に出品が簡単になります。</p>
<h3>値段推定についての解説</h3>
<p>現在は機械学習チームインターン <a href="https://twitter.com/lain_m21">@lain_m21</a> さんに日本版メルカリの値段推定プロジェクトに取り組んでもらっています。</p>
<p>値段推定タスクにおいては、Root Mean Squared Logarithmic Error: RMLSE で評価しています。</p>
<p>定義は</p>
<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20181114122755.png" alt="f:id:hurutoriya:20181114122755p:plain" title="f:id:hurutoriya:20181114122755p:plain" class="hatena-fotolife" itemprop="image"></span></p>
<ul>
<li><img src="https://chart.apis.google.com/chart?cht=tx&#038;chl=%20%5Cepsilon" alt=" \epsilon"/>: RMSLE スコア</li>
<li><img src="https://chart.apis.google.com/chart?cht=tx&#038;chl=%20n" alt=" n"/>: 予測したデータの数</li>
<li><img src="https://chart.apis.google.com/chart?cht=tx&#038;chl=%20p_i" alt=" p_i"/>: 予測した値段</li>
<li><img src="https://chart.apis.google.com/chart?cht=tx&#038;chl=%20a_i" alt=" a_i"/>: 真の値段</li>
<li><img src="https://chart.apis.google.com/chart?cht=tx&#038;chl=%20%5Clog%28x%29" alt=" \log(x)"/>: xの自然対数</li>
</ul>
<p>で、このスコアが低ければ低いほど、小さい誤差で値段を推定できたということになります。</p>
<p>RMLSEは直感的にわかりにくい指標なので、可視化して説明します。<br />
以下の図は¥3,000の値段の対するRMSLEの誤差の範囲を可視化したものになります。</p>
<p>(2018/11/15 11:37~<br />
<a href="https://plot.ly/">https://plot.ly/</a> を使って可視化していたのですが無料閲覧数枠を超えてしまったので、普通の画像に差し替えました。無念です)</p>
<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://storage.googleapis.com/prd-hatenaa-engineering-asset/20181115113703.png" alt="f:id:hurutoriya:20181115113703p:plain" title="f:id:hurutoriya:20181115113703p:plain" class="hatena-fotolife" itemprop="image"></span></p>
<p>横軸がRMSLEの値、縦軸が対応するRMSLEの誤差範囲となっています。<br />
ログ基準での指標になっているので、RMLSEが1.0の場合、</p>
<ul>
<li>真値: ¥3,000</li>
<li>推定値の誤差範囲: ¥1,103~¥8,156</li>
</ul>
<p>となり実際のプロダクト上で稼働させるには難しい精度です。</p>
<p>今回開催したKaggle Competition 1st winner が公開しているモデルは RMLSE: 0.3875 (<a href="https://www.kaggle.com/lopuhin/mercari-golf-0-3875-cv-in-75-loc-1900-s">公開されている75行のカーネル</a>) を叩き出しており、</p>
<ul>
<li>真値: ¥3,000</li>
<li>推定値の誤差範囲: ¥2,051~¥4,387</li>
</ul>
<p>となり、実際のプロダクション環境にも耐えうる精度です。</p>
<p>1位のチームによる100行未満で書かれた Code Golf が公開され、機械学習チーム全員がこのコードの簡潔さと美しさに驚きました。</p>
<p><a href="https://www.kaggle.com/lopuhin/mercari-golf-0-3875-cv-in-75-loc-1900-s">Mercari Golf: 0.3875 CV in 75 LOC, 1900 s | Kaggle</a></p>
<p>100行に満たない短さですが、洗練されたPythonコードでMLPのモデルを実現しています。<br />
実際に1位のチームの解法を米国版メルカリ最新データに対して適用しても、米国版メルカリで既に運用されている値段推定手法よりも圧倒的な高精度を達成することができました。</p>
<p>彼らの最終的なコードもGitHubで公開されています。</p>
<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fpjankiewicz%2Fmercari-solution" title="pjankiewicz/mercari-solution" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/pjankiewicz/mercari-solution">github.com</a></cite></p>
<p>同じく解説スライドもGitHub上で公開されています</p>
<p><a href="https://github.com/pjankiewicz/mercari-solution/blob/master/presentation/build/yandex.pdf">mercari-solution/yandex.pdf at master &middot; pjankiewicz/mercari-solution &middot; GitHub</a></p>
<h3>まとめ</h3>
<p>今回我々は <code>日本版</code> メルカリの商品値段推定に取り組んでいます。<br />
Kaggleで提供したデータが英語のデータセットのため、日本版メルカリに適用する際には日本語の複雑性に起因する問題が発生します。<br />
そのため 1位の手法も日本版メルカリのデータセットに適用時には、同程度のスコアは達成しませんでした。</p>
<p>ですが、開催した 「Mercari Price Suggestion Challenge」では商品値段推定のために多くのKagglerにより様々な手法・アイデアが議論されており、その内容は日本版メルカリの値段推定精度向上への大きな資産となっています。</p>
<p>値段推定機能の進展があり次第、詳細技術について技術ブログでご紹介させていただくのでご期待ください!</p>

Kaggleは凄かった! 更に簡単な出品を目指して商品の値段推定精度を改善中

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームのブログです。AI技術や組織にまつわる情報などを日々発信していきます。

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

Articles

機械学習システムの設計パターンを公開します。

機械学習とHuman-in-the-Loopで優勝する違反検知の話

Kaggleは凄かった! 更に簡単な出品を目指して商品の値段推定精度を改善中