LINEの機械学習チームが語る、「おすすめのLINEスタンプ」のレコメンドアルゴリズム

LINE Data Labsという組織

菊地悠氏：LINE Data Labsの機械学習チームで、マネージャー兼PMをやっています、菊地と申します。今日はよろしくお願いします。

今日の発表では、大きく3つのトピックに関してお話をしたいと思っています。

我々のチームは、実際には10名くらいの非常に小さいチームです。Data Labsという組織があって、その中でML（Machine Learning）にフォーカスして仕事ができるというところをきちんと説明したいと思っているので、組織の話をしたいと思います。

また、MLの技術を、さまざまなサービスにどういうふうに提供しているかというインフラの話もします。この2つの話のあとで、個別の事例をご紹介します。

では、最初にData Labsという組織がどういうものかについてです。すでにお聞きになっているかもしれないんですけれども、簡単に振り返ると、ざっと80名ぐらいのエンジニアが在籍していて、ほかにデータサイエンティストなどのメンバーも入っています。

組織としては、LINEのメインとなるメッセンジャーアプリのほかに、例えばLINEスタンプやLINE NEWS、広告系、LINEマンガなどいろいろあるのですが、こうした別々の組織があるなかで、独立してData Labsという組織があり、さまざまなデータを一括して扱っています。

そのデータが、Data Labsが持っているData Lakeというところに流れてきて、さまざまなエンジニアが、蓄積されたデータを分析、レポーティングしたりといったかたちで活用しています。我々は、その中で機械学習に関係するソリューション、代表的なものとしてはレコメンドエンジンなどを提供しています。

3つの役割

機械学習のチームは、実際には3つの役割があります。

まずは機械学習エンジニアがいます。機械学習エンジニアは、ケースバイケースなんですけれども、レコメンドエンジンをフルスクラッチで組んでいく場合もあれば、有り物をうまく使って、なるべく早くサービス側に提供するようなことを行う場合もあります。

機械学習のチームのメンバーは、統計や数学、ディープラーニング、自然言語処理など、みんながなんらかの得意なものを持っています。

次は、この機械学習エンジニアを支える、サーバーサイドやインフラのエンジニアがいます。

サービスを提供するにあたっては、当然、機械学習のエンジンを継続的に動かし続けて、なんらかのAPIを用意して、データが入ってきたら結果を返せるようにするということが必要なので、そういうサーバーサイドの開発も発生します。また、機械学習の処理を走らせるために、ある種のハイパフォーマンスコンピューティングを扱うための独自の計算機環境も持っていたりするので、それを管理するエンジニアもいます。

最後に、PMについてです。機械学習のプロジェクトをうまくサービスの中で活用してもらうための企画をしたり、実際に開発が走り始めてからは、開発範囲や仕様を決めていったりします。また、プロダクトを提供したあとには、それが継続的によいものになっていくようにアフターケアまでしたいという意味合いもあって、PMが別のロールとして存在しています。

ロールは3つあるんですけれども、ケースバイケースで、1人の人が複数の役割を果たすこともあります。

扱うデータの量と4つの流れ

我々MLチームが、日々どれぐらいのデータを生成しているかというお話がこのスライドになります。

冒頭にお話ししたとおり、LINEの中にはさまざまなサービスがありますが、我々は10ぐらいのサービスに対して、データやエンジンなどを提供しています。

どれぐらいの機械学習の処理が走っているのかを表すのが（スライドの）右側の2つです。機械学習の訓練や学習と言われるようなモデルを生成するものに関して言うと、1日に100以上。その用意できているモデルに対して、なんらかの未知のデータが入ってきたときに予測や推定をする処理に関して言うと、日々1,000以上のジョブが走るようなシステムを運用しています。

では、こうしたものをどういう環境で動かしていくかというインフラのお話に入っていきます。

簡単に、図を4つぐらいに分けていますが、まず一番左に、LINEのなんらかのアプリケーションがあります。LINEのメッセンジャーアプリや、LINEマンガ、LINE MUSICなどで、それぞれ別のアプリが存在していたり、一つのアプリに沢山のサービスが入っている場合もあります。

アプリ上でサービスを提供するためには、当然対向するサーバーが必要なので、個々のサービスごとにサーバーが立っていて、各事業部と一緒に仕事をしている開発メンバーが、日々運用や開発を行っています。

そして、サービスに関するデータが、我々が「Data Lake」と呼んでいるHadoopクラスタに流れ込んでくるようになっています。

上から順番に、ご説明します。まず、クライアントのアプリから直接入ってくるクライアントのログがあって、LINEのメッセージング関係のサービスに関するデータが入ってくるのが2番目の矢印ですね。そして、LINEのその他の関連サービスに関するデータが入ってくるサーバーログというのが、3番目の矢印です。

一番下は、個々のサービスです。例えばLINE NEWSであれば、ニュース記事のタイトルや件名など、いわゆるマスターデータと呼ばれるものが、スナップショットのようなかたちで日々入ってきます。以上が、4つのデータの流れになります。

Data Lakeに入ってくるデータに関しては、基本的に「分析にかけていいですよ」という点が担保されたデータとなっていて、それ以外の情報に関してはきちんとフィルタリングされています。例えば、LINEのメッセンジャー上での会話の内容とかは、分析してはいけないので、Data Lakeには入ってきません。

ここからようやく、我々のチームが行っている仕事の話に関わってきます。内部で「Z-Features」と呼んでいる巨大なテーブルのようなものを作っています。

なにをしているかというと、個々のユーザーに対して、その人の行動ログが紐づくようにしたデータを、後段の機械学習で取り回しやすいように管理しているものになります。

簡単な例でいうと、例えば「どのスタンプを買った・買っていない」という情報や、「どういう音楽を聴いた・聴いていない」といった情報が入っていて、それがLINEの全ユーザー分、データとして管理できているテーブルだとお考えいただければ、あながち間違いではないと思います。

機械学習を使ってデータを処理する

ここまできてようやく、機械学習を使ってなんらかのデータの処理をするという話になります。

処理系として、Data Lake自体もHadoopクラスタなので、Hiveが走りますしSparkも動きます。これとは別に、我々はML用の計算機クラスタをもう1つ作るという構成でやっています。

まずはこのMLの計算機クラスタに関して、コンポーネント単位で簡単にお話をしていきます。

計算機クラスタはなにを目的にしているかというと、ハイパフォーマンスコンピューティング用途というイメージです。ですので、データを持っていない作りになっていて、プロセッサを100パーセント使い切るような処理を行うために用意しています。

分散環境で学習を並列で走らせたい場合には、SparkやHadoopの仕組みを使わずに、MPIで直接データをやりとりするようなアルゴリズムを実装したり、計算機のリソースとしてはCPUもGPUも両方用意していたりといったかたちになっています。Sparkも別で一応持っています。

2番目の箱、「ML Batch Jobs」と書いてあるところは、実際にどういうジョブを管理しているかを表しています。画像やオーディオに関わるDeep Learningのジョブや、レコメンドエンジンのバッチなどがあります。

あとは「ユーザーのデモグラ推定」と書いてますが、ユーザーの年代や性別などを推定して、いろいろなサービスで使いやすいようにするという処理も、この上で走っています。

また一番下の「long-running」というのは、いわゆるAPIサーバーやCMSのようなものですね。Apache Mesos上でリソースを管理していて、なんらかのバッチが走る場合は、都度必要なリソースをリクエストして、完了したらリソースを解放するという挙動になっています。

ですので、ずっと動き続けるシステムというのは、Mesos上で「Marathon」と呼ばれるメタフレームワークがあるので、そちらで動かすということを行っています。

あとは少し細かい話になるんですけれども、我々が内部でMLのエンジンを開発したり、検証していくために使うJupyter Hubを自前で用意していたりします。

その他、A／Bテストの環境を自分たちで作って、CMSも提供したりというようなことも行っています。

これはもともと、我々が作ったエンジンを新しいものに変えたいときに、オンライン環境で性能が「上がっている・上がっていない」ということを検証したいという目的で作ったものです。せっかくなので、同じものをデータサイエンティストの人や、社内横断で使ってほしいということで、運用ルールを整備したり、CMS含めて用意しました。

「おすすめスタンプ」のレコメンド

以上がシステムの概要になります。ここからは、個別のML事例を4つほどご紹介していきたいと思います。

1つ目は、コンテンツのレコメンドです。（スライドを指して）これはスタンプのレコメンドに関して我々が提供している機能になります。

スタンプショップのページに行っていただくと、画面の上のほうに「あなたへのおすすめ」という表示枠があります。この中に「もっと見る」という部分があるんですけれども、それをタップすると、画面中央に「あなたへのおすすめ」という画面に遷移し、もう少したくさんのスタンプが出てきます。

個々のスタンプのパッケージを選択すると、一番右側の画面に遷移して、中に入っているスタンプの画像がリストで表示され、その一番下に「おすすめスタンプ」という枠が出てきます。

一番右の「おすすめスタンプ」は、「この商品を買っている人は、この商品も買っています」のような、Item2Itemといわれるレコメンドです。左側の2つがUser2Item、つまり特定のユーザーに対してその人へのおすすめを生成するものになります。

スタンプのレコメンドのデータの規模感ですが、ジョブの数としては10ぐらいです。実際は国によってそのレコメンドを生成するジョブを分けているので、今はこれぐらいの数が動いています。

スタンプのパッケージ数に関しては、ちょうど3年ぐらい前に別のメンバーが発表したことがあるんですが、その当時は9万セットと言っていました。今は300万セット以上のスタンプのパッケージがあります。

それから、実際に生成しなければいけないユーザーの数ですね。これはInactiveなユーザーも含めてデータを生成するようにしているので、1つのリージョンで見ても1億を超えるユーザー数を対象にしないといけなくなります。

協調フィルタリングの仕組み

そこで協調フィルタリングを使っているんですが、どんな感じで活用しているのかを簡単にご紹介します。処理は大きく2つに分かれています。まずItem2Itemを実行したあとに、User2Itemを実行するという動きになっています。

Item2Itemにあたっては、最終的に「このスタンプを買った人は、このスタンプを買っています」という情報を作りたいので、「あるスタンプを持っている人がほかに持っているスタンプはなんなのか？」というデータを作るのが基本的な処理になります。それが中央に書いてある「Similarity among items」のあたりです。

一度その情報ができたら、あるアイテムを持っている人が持っていそうなTop-Nのスタンプのパッケージを計算します。（スライドの）中央のデータで言うと、「300万×300万」の行・列みたいなものをイメージしていただければと思います。それを、一番右上に持ってくると「300万×たかだか数百」ぐらいのデータの規模になるというイメージですね。

そして、一度こういうデータを作ってあげたあとに、User2Itemの処理に移ります。今度はあるユーザーに着目した場合、仮にそのユーザーが10個のパッケージを持っているとすると、その10個のパッケージに関連するものの中から先ほど計算した右上のTop-Nのアイテムだけを持ってきて、最終的に「10×N」のパッケージの中から「Top M」を計算するというやり方で処理を軽くする仕組みになっています。

計算処理がどこで行われているかという話なんですが、実はこの処理は、最初のバッチを起動するところ以外はすべてData Lakeで動くようになっています。必要なデータは先ほどお話ししたZ-Featuresというところに入っていて、このスタンプのレコメンドをするために必要な情報だけを持ってきます。

そのデータを持ってきたあとに、Item2ItemやUser2Itemを計算します。実際に計算する場合には、個々のHadoopの計算機ノードに処理を分割したら、あとは最後まで処理を走らせ切って、最後に結果を合わせればいいという挙動なので、ノード間でのデータを何度も同期する必要がありません。Sparkや通常のHiveのような処理が比較的スムーズに流れるので、Data Lakeで処理をしています。

スタンプのレコメンドが事業的にどういうインパクトがあるのかという話なんですけれども、表示位置が上のほうにあることもあり、今はスタンプショップの売上の25パーセントぐらいがこの「あなたへのおすすめ」起点で生み出されています。

「スタンプショップの面のどこに、あなたへのおすすめを置くとその売上が最大化されるか？」という最適化の話やA／Bテストは、Data Labsのほかのメンバー（データサイエンティスト）が一緒に動いてくれました。また、「これで有意差がきちんと出ている」という検定をしてくれたりと、こういうところに関しては、ほかのメンバーの力を借りながら、一緒に仕事をしています。

ほかのサービスに関してはどうかという話です。ケースバイケースにはなるんですけれども、先ほどご紹介したアルゴリズムが、ほかのサービスでも同様に動いていたりします。ニュースのレコメンドでも、基本的にはここで話したことと同じようなアルゴリズムを使っています。

こういうふうに、一度作ったアルゴリズムをいろんなところで再利用できるようにするとか、先ほどお話ししたZ-Featuresというところにニュースの購読ログみたいなものも入ってくるようになっているので、こういうものを駆使して少ない労力で開発して、たくさんのサービスにこれを提供できるようにするというかたちで仕事をしています。

（注：過去の発表はこちら）

ユーザーのレコメンドをする「Look a like」

では、2つ目のレコメンドの事例のご紹介に移ります。ユーザーのレコメンドをするというものですね。（LINE DEVELOPER DAYの）午前中のセッションでも「Look a like」というキーワードが出てきたかと思うんですけれども、あらためて簡単にご説明します。

例えば、自動車業界の広告主がいるとします。LINEで過去に広告を使ってキャンペーンやプロモーションを打ったことがある場合だと、キャンペーンをした結果、しっかり反応してくれたユーザーと、反応してくれなかったユーザーがわかるようになります。

2回目以降のキャンペーンをしたい場合には、「“過去に反応してくれたユーザー”とよく似ている“広告を配信していないユーザー”をうまく割り出して、その人たち向けに広告をターゲティングしたらものすごく効果が高いんじゃないか？」ということが考えられるわけですが、「Look a like」がまさにやるのがこれです。既存のなんらかのデータ……スライドでは「Customer」（顧客）と書いていますが、これをシードデータ（種となる情報）として与えた場合に、それとよく似た別のユーザー群を引っ張ってこれるようにするものです。

この問題は（先ほど紹介した事例と）何が違うかというと、先ほどの例の場合、作るモデルの数はせいぜいリージョンの数ぐらいでした。しかし今度は、お客様単位でモデルが全部変わります。

例に出した自動車業界向けのユーザー群、もし対象が化粧品に変わったら、あるいはフィットネスだったら、保険業界だったら……と考えてみると、当然シードユーザーは全部異なるので、違う予測モデルを用意してあげる必要が出てきます。

これが、我々がたくさんのモデルを日々生成している理由なんですけれども、では「実際はどのぐらいのデータのボリューム感か？」というのがこちらですね。

一番左に書いてあるとおり、シードユーザーがどれぐらいの数からスタートできるかというと、最小だと100人くらいからスタートできるようになっており、最大で100万人ぐらいのデータになります。これをもとに、よく似たユーザーを作ります。

「似ている・似ていない」を判断するために使えるユーザーの特徴の情報は、何度もお話ししているZ-Featuresで……計算の処理を軽くするためによく効くフィーチャーを絞ったサブセットを使っていますけれども、元のZ-features自体は次元としては1,000万次元というようなオーダーになってきます。

では、予測するためのモデルをどのぐらい生成しているのかというと、直近ではだいたい300ぐらいです。毎日更新する必要は必ずしもないんですけれども、更新しなければいけないのがこれぐらいの数となります。

少ないシードデータで汎化性能を上げる

アルゴリズムのイメージは、いわゆるStacked Auto-Encodersというシンプルなディープラーニングの手法です。

ただし、入力が先ほどのZ-Featuresで、非常にスパースなデータで、次元数が1,000万ぐらいあります。ほとんどの値は空っぽ、あるいはビットが立っているスカスカなデータですね。

2層の中間層を挟んであげて、最終のアウトプットが0〜1のスカラー値を返すようなもの。ここは、先ほどのもとになるシードユーザーのデータに関しては「1」を、シードユーザーに含まれなかったユーザーは「0」を正解データにして、学習をさせたモデルを作ります。

中をもう少し細かく説明すると、実際のレイヤーはこういう風になっています。

見ていただければ非常にオーソドックスなのですが、Batch Normalizationを入れて、Dropoutして、活性化関数にはReLU使います。最後は0〜1の値しか返さないため、Sigmoidで、という普通の流れです。

工夫している点を1つだけお話しすると、もともとのシードユーザーが100人みたいな場合にも対応できるよう、Batch NormalizationのあとにDropoutが入っていて、うまく汎化性能を上げられるように、というのが、ちょっとしたポイントになっています。

あとは、当然100人のデータとそれ以外の大量のデータでは学習がうまく走らないので、100人分の正解のデータを見かけ上多くするため、オーバーサンプリングと、負例の量を意図的に下げるというアンダーサンプリングもしています。

「Look a like」はどこで処理をしているのかという話をします。元データはData LakeのZ-Featuresにあるので、当然Data Lakeから持ってくる必要があります。

学習に関してはニューラルネットワークなので、ミニバッチ学習をするにあたって、頻繁に誤差の逆伝播をしてパラメータの更新をかけていく必要があります。

並列で走らせようとすると頻繁なデータの同期が必要になり、Sparkの仕組みを使うのは効率が悪いということで、MPIで直接通信をしながらうまくパラメータサーバーでデータを扱うことで、MLクラスタ上で実行するようになっています。

Inference（推定）と書いてあるところは、こうしてできたモデルをData Lakeに戻してあげて、Data Lake上のノードにたくさん同じモデルを配置し、それぞれ異なる未知のユーザーに対して、先ほどの0〜1という値を推定して出す処理を並列で走らせる処理をしています。ここはノード間で通信する必要がないので、Data Lakeのたくさんある計算資源を使うという動きになっています（登壇者注：計算機のノード数自体は、MLクラスタよりもData Lakeの方が多い）。

スタンプのオートサジェスト機能

3つ目の事例、ユーザー体験を改善について。この機能は、昔からあるにはあるんですが、スタンプのオートサジェスト機能と呼んでいるものになります。

ユーザーが実際にメッセージを送ろうとした場合に、機能をオンにしていれば、例えば「びっくり」と入力すると「びっくり」という意味に紐付けられたスタンプ画像が選択候補として出てくるようになっています。（スライドの）中央は「ありがとう」と入力しようとしていて、一番右は「ごめんなさい」ですね。

これが実際にどういうふうにラベル付けされているかというと、もともとは個々のスタンプの作者の方が手作業で行っていました。

（スライドを指して）左上にある画像はうちの子どもが描いた絵なんですが、それに私がタグ付けをした例です。

「てへっ」っていうスタンプ画像に「照れる」「えへへ」「てへ」という3種類のタグを手作業で付与しています。

元となる選択可能なタグの数が、日本だと320ぐらいあります。それだけの数の中から3つ選ぶという行為を、1つのスタンプのパッケージに入っている数だけ繰り返し行う必要があります。1つのパッケージに最大40の画像が入っているんですが、全部やろうとすると作業量が多くて負担になるので、一部のスタンプ画像にしかタグがついていない状態でした。

そこで、画像そのものを入力にして、タグをつけるところを自動化できないかということで取り組みを始めました。

先ほど、Item2Itemのレコメンドの話をしました。1つのスタンプの画像に対して3つのタグがつけられるので、「このタグがついているスタンプ画像は、このタグもついています」というデータが作れます。それをもとに「よく似たタグはなんなのか？」をクラスタリングして表示したものがこれですね。

見ていただくと「恥ずかしい」「もじもじ」というような意味的に似た別のタグが1箇所にまとまって表示されているため、数は少ないけれど、人の手でつけてもらったデータが正解データとして使えそうだと（考えました）。それで作ったモデルによって、タグをつけてもらっていないスタンプにも自動的にタグをつけられるんじゃないかということで実際にやってみました。

転移学習でスタンプに自動タグ付け

これも技術的には非常にオーソドックスなんですが、一般には転移学習と呼ばれる方法を使っています。

学習済みの既存の画像処理向けのDeep Learningのモデルを初期値として持ってきて、あとは入力のデータ・出力のデータを別のものに置き換えたり、間に別の中間層を少しだけ挟んだりして学習を進めてあげると、さらに新しく入れたインプットとアウトプットに適したかたちで中身が変わるというものです。（スライドを指して）この「Xception」と書いてあるモデルを使っています。

処理は、GPUの資源はすべてMLのクラスタ側にしかない状態なので、こちらで進めています。

あとは画像になるもとの入力データに関しても、CDNから直接取ってきているので、（Data Lakeからデータを取ってくる必要がなく）MLクラスタで完結して処理できる問題となっています。

具体的な例をいくつか紹介したいと思います。（スライドの）上から2行ずつ、「True Positives」「False Positives」「False Negatives」と並んでいます。

True Positives（TP）はなにかというと、人手できちんとモデルをつけてもらったものを検証データとして利用しているのですが、ラベルがついていて、それを正しく推定できたものです。

False Positivesは、もともと正解データには付いていなかったタグを、推定時には付与してしまったというものです。最後のFalse Negativesというのはその逆で、もともとの検証用データについていたタグを正しく付けられなかったものになります。

「ありがとう」の例だとこんな感じです。

一番上のTPと書いてあるところで注目していただきたいのは、「Thank You!」と書いてあるところですね。今回この学習を進めるにあたって、どの国の言語が入っているかということを一切気にしない、あるいはOCRのような（文字自体を認識する）機能を入れずに、単純に入力として使ってタグを予測できるかということを実施してみました。

結果的に、日本人であってもちょっとした英語を使ったりするというところで、言語の違いを吸収して、うまく予測できるかたちになったというのがこの例ですね。

中央のFP（False Positives）と書いてあるところに関しては、例えば「ぺこり」というものは「ありがとう」というタグよりも、別のタグのほうがより好ましいんじゃないかといったケースで、実際のクリエイターの人は「ありがとう」というタグをつけていました。

真ん中にタコみたいな絵があります。これはクリエイターの人が「ありがとう」というタグをつけていなかったけれども、実際に学習したモデルは「ありがとう」というタグをつけたケースです。「思ったよりもうまく動いているね」というのが確認できるようなイメージですね。

一番下、FNと書いてあるところは、その逆で、「ありがとう」というタグがついていたけれども、我々が作った推定するモデルではそのタグをつけなかったという事例になっています。

別の「きたー」というタグだと（スライドを指して）こんな感じですね。それぞれ、先ほどお話ししたものと似たような傾向でタグがついています。

ここまで見てもらったのは、実際にユーザーが目にするものとは別で、検証用のデータです。例えば、私の端末でこの機能をオンにするとなにが起こるかというと、「おやすみ」と入力しようとすると土下座のスタンプがなぜかたくさん並んでしまったり、「やった」と入力しても神々しく光っている土下座のスタンプが出てきたりという状況になっています。

ユーザーに選択肢を与えるという意味では、「間違っていても、ここにたくさん出してあげるほうが親切だよね」というポリシーで、現状はこういうモデルの設定になっています。

1つ言い訳をすると、土下座はしているんだけれども、「夜だよね？」「王様のマントがふとんっぽいよね？」といったところはあるので、機械学習のメンバーとしては正直に言って「まあまあ、うまくいってるね」というのはあるかなというところです（笑）。

（会場笑）

2つのモデルを使った「似ているスタンプで探す」機能

4つ目として、「Content Recomendation」の事例をご紹介します。

これも技術的にはあまり変わらないんですけれども、10月の中頃ぐらいにリリースされた機能です。

先ほどのスタンプショップの中段ぐらいに「似ているスタンプで探す」という機能があります。これをタップすると、見た目と意味が似ているスタンプが大量に出てくるようになっています。

まず「似ている」には「意味的に似ている」と「見た目が似ている」の2種類があって、両方ともいい感じの塩梅でバランスを取りたいわけです。そこでなにをしているかというと、2つのモデルを持ってくるようにしています。

（スライドの）左側のSemantics、意味的に似ているものは先ほどと同じものだと思っていただければいいのですが、見た目が似ているという右側のモデルを、もう1個横に並べています。

「見た目が似ているって、どうやって正解データを作ればいいの？」ということに関して言うと、「『同じスタンプのパッケージを作る人をうまく当てられたら、きっと同じ作家さんは似たようなスタンプを作るはずだから、見た目が似ている』というモデルが作れるんじゃないか？」という考え方で、正解データを、スタンプのクリエイターを予測する問題というかたちで表現しています。

さらに、見た目の「似ている・似ていない」を測るときに、個々のスタンプを2つ、任意で選んできたら、それに対して類似度を測るような、なんらかの計算をする必要があります。

その元になるベクトルとして、出力層の少し手前の中間層をそのまま持ってきて、ベクトルを横にがっちゃんこして並べたデータを、スタンプの特徴表現といいますか、Representationにするということを行っています。

例えばこれを、コサイン類似度みたいなもので比較してあげると、あるスタンプとあるスタンプの画像の類似度が計算できます。その類似度が高いものを選んでくるということを行うと、先ほどのサービスができます。

計算機の処理がどこで起こるかというと、先ほどと同様で、すべてMLクラスタ側で処理されるというかたちです。

「似ているスタンプで探す」の事例

これも事例をご紹介したいなと思います。

（スライドの）左側の一列が元になる画像で、右側がそれに対して類似度が高いと出てきたものです。

そして、上のほうが意味的に似ているというウェイトが大きいもので、下のほうがどちらかというと、見た目しか考えていないものというかたちで並べています。

いくつか例をご紹介すると、このようなかたちになっています。

例えば「おめでとう」の最初の1行を見ていただくと、「Happy Birthday」という意味が似たようなものがたくさん出てきます。一番下は「ありがとうございます」「がんばって」など、まったく別のものが出てくるというかたちです。

2つ目の例だとこんな感じです。

もう少し緩い絵だとこんな感じです。

「笑笑笑」と書いてあるものだとこんな感じです。

ということで、実際には上から2行目のエンジンを選択して、これも先ほどと同様に、同じ作者のデータは取り除いた上でおすすめするということで、実際のサービスで提供しています。

恵まれた環境で機械学習に集中して仕事ができている

まとめになります。今日ご紹介したかったのは、個々の事例もそうなんですけれども、Data Labsという組織やLINEという会社の中で、いろんなエンジニアと一緒に仕事をしながら、我々はとくに機械学習に集中させてもらって仕事ができており、非常に恵まれた環境にいるということです。

プラスアルファで、データを使い回しやすいようにあらかじめ設計しておくといったことや、「データ量がものすごく増えても、同じアルゴリズムで計算し続ければ大丈夫だよね」といったことなど、たくさんのサービスをサポートしていく中で担保しておくべき点はケアしているというお話をしたくて、いろいろとご紹介しました。

今日プレゼンしたのはこういう内容でした。