サービス横断で機械学習のデータを使いやすく整形　LINEのMachine Learning室のお仕事

Machine Learning室とは

菊地悠氏（以下、菊地）：Machine Learning室の菊地と申します。私からは全体の概要をお伝えして、この後の発表における理解の助けになればと思っています。

LINEでは2つのビジネスドメインで仕事をしています。このうちMachine Learning室は、大量のデータが日々生成される事業領域を主にターゲットにして、コア事業と呼ばれる大勢のユーザーがいる部分であったり、あとはすでにいるユーザーベースをテコにし、新しい事業領域に拡大していくところでも仕事を進めようとしています。

また、サービスがたくさんあるということは、サービスで共通化したり、横断的に何かをやりたいというニーズも当然生まれてくるわけで、こうしたものも開発の対象としていろいろ仕事をしています。

ちなみに、月1回でもLINEを使ってくれるユーザーのうち、毎日利用してくれる人の割合は80パーセントくらいあります。

利用するデータプラットフォーム

たくさんデータがあるということは、これを下支えするような大きなシステムというのが必要です。このために、LINEにはデータプラットフォームがあり、ML室も利用させてもらっています。

こちら2020年のLINE DEVELOPER DAYで発表された数字になりますが、ストレージサイズは270PB（ペタバイト）、毎日入ってくるレコード数でいうと7,000億レコードのような規模のデータがあります。

簡単に説明すると、いろいろな事業のデータがHadoopのクラスタに流れ込んできて、こうしたデータをHiveやSparkなどで前処理し、機械学習の高負荷な計算はKubernetesクラスタにいったん移動させてGPUノード上で並列計算し、結果物をもう一回Hadoopに書き戻す、ということをやることが多いです。その後、サービスにデータを提供する、というような処理が、典型的な仕事のパターンになっています。

更に、データがリアルタイムで流れ込んでくるようなケースや、オンラインでサービングをするケースだと、KafkaやElasticsearch、Redisのなどを使います。

あと、Business Intelligence（BI）系についてもいくつか描いてありますが、内製のWebアプリケーションやtableauのような一般的なものを利用しています。

SMART CHANNEL

ここで2つほど、プロジェクトの例を紹介します。まず1つ目、サービス横断系でやっているMachine Learningで、スマートチャンネルというものがあります。トークの画面の上のほうに、コンテンツや広告が出てくる枠がありまして、ここにいろいろなコンテンツ、例えば天気、スタンプ、ニュース、マンガなどが連携されています。

どのように連携されているかというと、各サービスに関して「このユーザーにはこういうコンテンツを出したい」という、個人化されたコンテンツとユーザーの対応関係の情報（ルールベースでもMachine Learningでもよい）が提供されます。

表示する枠は1つしかないため、スマートチャンネルでは、「あるユーザーに出せるコンテンツの中から、ある1つのコンテンツを選ぶ」という処理を行っており、この計算は、ユーザーがこの画面を訪問したタイミングで行われています。

私たちMachine Learning室では、MLエンジニアの人たちが、さまざまなサービスに複数、計数十に上るターゲティングのロジックを提供しています。また、表示するコンテンツを1つだけ選ぶという2番目の処理に関しても、ロジックを提供しています。

SMART CHANNELの表示画面におけるコンテンツのインプレッション数は、1日およそ10億インプレッションになっていて、この訪問のたびになんらかの機械学習の推論理が裏で走っていたりします。これが1つ目の例です。

コンテンツの情報を使いやすく整形

もう1つの例は、サービス横断でユーザーの行動ログやコンテンツの情報を使いやすく整形する例です。こちらは、どちらかというと機械学習を下支えするような取り組みになります。

ユーザーはいろいろなサービス利用しているので、さまざまなサービスに向けて機械学習を提供していると、入ってくるログのデータなどを共通化して使えるようにしたいというニーズが出てきます。

で、私たちはz-featuresと呼んでいるサービス横断のユーザーの行動ログデータを開発・運用しています。dtype（データ種別）としては45、データの次元数は6,000万を超える規模のデータになっています。あとはユーザーID数（のべ数）では、9億6,000万ユーザー分のデータが格納されています。

このサイズのデータをそのまま扱って機械学習することもありますが、いろいろなところで同じような処理を繰り返すのは非効率ですし、また次元の大きい大規模データはやや扱いづらいという問題もあります。このため、z-featuresを事前に加工するというようなこともしています。

具体的には、表現学習などを利用して、データを3,600次元くらいまで圧縮し、提供しています。このデータは自分たちでも使いますし、他の組織にも提供しています。具体的にどうやって使っているかの事例に関しては、この後の発表でいくつか紹介されると思います。

ロールとプロジェクトの体制

こうした仕事を実際どういうふうにやっているか、役割やプロジェクトの体制などの組織という観点で、少し紹介したいと思います。

今までお話してきたとおり、LINEの中にはデータプラットフォームがあって、それを管理・運営するプラットフォーム系のエンジニアがたくさんいます。

私たちはこの環境を利用してMachine Learningの機能を開発し、サービス側に提供することをしています。サービス側には企画者も、開発者がいます。また、作ったものがいいかどうかとか改善を継続的にしていくという観点で、効果検証に協力してくれるるデータサイエンティストがいます。

こうしたさまざまな人たちと連携し、仕事を進めていくため、ML室では、メンバーを複数のロールを定義し、プロジェクトを組んで仕事をやっていく方法を採用しています。

ここに大きく4つ、色分けしていますが、まずMachine Learningエンジニアという丸が2つ（青色・黄色）あります。よりプラットフォームとかシステムに近いレイヤーで仕事をしてもらうMachine Learningエンジニア（青色）と、サービスに寄り添うい、アプリケーションとかサービスに近いMLをやるエンジニア（黄色）が存在します。

また、Machine Learning自体もなんらかのプラットフォームやフレームワーク、あるいはライブラリを開発する必要があるので、インフラ周りを見てもらったり、API部分を開発してくれるエンジニアもいます。

最後に、こうした人たちを全員取りまとめてプロジェクトを成立させたり、作るものを決めていくため、プロジェクトマネージャー、プロダクトマネージャーの人もいます。

以上が役割（ロール）の簡単な説明になりますが、プロジェクトを推進していく際は、プロジェクトの規模感によって、参加するメンバーをそれぞれ変えています。

例えば、個別のサービス向けにMachine Learningのエンジン開発を行うようなケースだと、割と業務の型のようなものがあるので、比較的小規模の人数で短い時間で開発を進めていきます（一番左）。Machine Learningのモデル自体の開発に注力する場合には、機械学習エンジニアがメインで仕事をするようになります（左から2番目）。

Machine Learningを提供しようとすると、当然Machine Learningのモデルだけでは足りないので、周辺のシステムがいろいろと必要になりますが、そういう場合にはインフラ周りやサーバーサイドのシステムが開発できるエンジニアが入ってくれますし（右から2番目）、大規模なサービスになればみんなで開発する（右から1番目）、というように比較的弾力的にプロジェクトに対して人をアサインしています。

チームの構成は、基本的にはロール別になっていて、この後の発表で、各チームのマネージャーがいろいろなプロジェクトに関して紹介します。

Machine Learning室でオープンになっているポジション

最後に私からは、Machine Learning室でオープンになっているポジションを紹介します。今日の発表の中では、この左側4つがメインの発表内容になっています。

冒頭お話したとおり、この資料後ほど共有するので、ぜひ自分のポジションがどこにマッチしてそうかを見ていただきつつ、今日の話でいろいろ疑問に思ったところは質問していただいて、この後の発表を楽しんでもらえたらなと思っています。私からの発表は以上になります。

司会者：はい、菊地さん、ありがとうございました。