数億のユーザーデータを使って作る機械学習の仕組み　LINEのエンジニアが開発するサービス横断型レコメンデーション

LINEアプリにおける機械学習を担当

菊地悠氏：LINEのData Scienceセンターという組織のMachine Learning室（以下、ML室）で室長をしています、菊地と申します。今日はよろしくお願いします。

今日みなさんに何をお伝えしたいかというと、やっている仕事がおもしろそうだなと思ってもらいたい、というのが何よりも一番大きくあります。そこでまずは、開発事例の紹介をしたいと思っています。

続けて、どうやって開発してるのか、どの部分を開発しているのかをお話したいと思っています。体制、組織、業務の進め方について触れながらお話しようと思います。

LINEのアプリを開くとだいたい5つくらい大きな面があります。（スライドの）左からホーム、トーク、タイムライン（※発表当時　2022年1月時点では、voomというものに変更）、ニュース、ウォレットとタブが並んでいますが、これを見ていただくと、いろいろなコンポーネントが中に埋め込まれています。

例えば、下図で青く色付けした表示箇所には、何らかの機械学習の仕組みが入っています。どの面に対しても、上部には検索用のテキスト入力エリアがあります。ほかにも、例えばホーム画面の中には、サービスのアイコンの下に入れ替わり立ち替わりさまざまなサービスのコンテンツが出てくるエリアがあります。トーク画面の上にも、コンテンツや、あるいは広告が1個だけ出てくる場所があります。

機械学習を導入している領域は、このようにたくさんあります。LINEの中では私たちの組織もかなりたくさん開発していますが、他の組織もこのように機能を提供しています。

やっていることその1　スタンプのレコメンデーション

では、具体的に何やっているのか、AI開発をやっているメンバーと私たちでは何が違うのか、具体的にやっているもので紹介していこうかなと思います。

まず1つ目。スタンプのレコメンデーションです。例えば、先ほどのホームタブの画面から飛んで、スタンプショップに入ると「あなたへのおすすめ」が枠として出てきます。

いわゆるUser-to-Item （ユーザーごとに個人化されたアイテム）でのレコメンデーションが出てきたり、このスタンプに興味がある、あるいは買っている人に対して「こちらもおすすめです」というかたちで行う、Item-to-Itemレコメンデーションがあります。

私たちは機械学習（以下、ML）を専門とする組織で、この時に使うレコメンデーションのロジックを決めて、実装します。そして実際にパフォーマンスが出るかをオンラインやオフラインで評価して、リリースして、会社に貢献するという仕事をしています。

例えば、「データサイエンティストとMLエンジニアの何が違うんですか？」という質問を受けることが多いのですが、私たちは、分析などデータサイエンティストのフィードバックを受けて、MLのロジックやエンジン、あるいはチューニングを変えるといった仕事をしています。

実際に扱うデータの規模ですが、スライドの左下にDATA VOLUMEというところに記載しています。スタンプの販売単位であるパッケージというもので数えると、現在は1,000万くらいあります。この中から1ユーザー当たりに100個くらいのパッケージ推薦リストを作ります。

一方、ユーザーの数は、実際にはアクティブなユーザー以外も含めて推薦リストを生成するので、数億という単位のユーザーに対して、レコメンデーションを生成します。

スタンプに関しては、ほかにも画像からこのスタンプの意味を類推するという、分類のタスクを解く仕事もしています。直近だと、ロジックをEfficientNetに置き換えています。この場合の入力は画像で、スタンプの意味的なタグが2、300種類定義されているのですが、それを予測するという仕事です。

やっていることその2　オフィシャルアカウントのレコメンデーション

続いて、LINE公式アカウントのレコメンデーション。こちらは今日このあとに出てくる他の2年目の社員が、開発を進めてくれています。

LINE公式アカウントは、LINEのB2B2Cのサービスですね。私たちは、このLINE公式アカウントをぜひフォローしてほしい、といろいろな面に出すロジックを考え、実装し、提供するということになります。

ロジックを作ることももちろん大事ですが、利用者の目線に立って、意味の無い情報が出てくるようなアカウントはなるべくフィルタリングしています。

洗練されたレコメンデーションではなく、ランキングのようなロジックも欲しいなど、さまざまなニーズがあるので、データ分析をやってくれる人や、企画者と連携して、頻繁にリリースや改善を繰り返しています。

やっていることその3　サービスを横断するシステムの開発

ここからは、個別のサービスやレコメンデーションから少し離れて、サービス横断で使うレコメンデーションの話をします。

スマートチャンネルは、トークリストの上のほうにさまざまな種類のコンテンツが出てくる場所ですが、ここには、さまざまなサービスからのコンテンツと、たくさんの推薦ロジックが提供されています。（ロジック数で、およそ100）

ロジックを提供している組織も複数ありますし、ロジックも、ルールベースのもの、MLを用いたものなど、いろいろあります。

なので、1ユーザーに対しては、さまざまなコンテンツが候補として用意されているのですが、どれを選ぶかをユーザーが画面を見た瞬間に選ぶ、というリアルタイムで計算するMLのロジックも入っています。

このようにサービスを横断するシステムを開発したり、その上で動くロジックを提供したりというところも開発の対象になっています。

レコメンデーション以外のMLの例も紹介します。例えば、ユーザーのみなし属性を推定するタスクなどがあります。

広告を打ちたい場合に、これくらいの年代で、男性または女性にリーチしたいという要求があります。LINEではたくさんのサービスを提供していて、それぞれのサービスでユーザーのログが取れているので、そうしたものを使って推定することができます。

データ規模ですが、先ほどのスタンプの例と同様、対象ユーザーの数は数億になります。また、特徴量の次元数でいうと数千万次元、という規模感のデータになります。（実際には、この内特に有効なものに絞って高速化する等もあるため、1桁ほど小さい次元数を利用しています。）

社内要望に沿ってツールを開発

いろいろなサービスに向けて、例えば推薦エンジンやロジックを組んでいくと、ある部分に関しては機能を共通化したいという話が出てきます。次は、そういう話を紹介したいと思います。

これはレコメンドを作る時に使うツールで、私たちの組織で作っているものです。ロジックを新しく置き換えると、例えば自分にはどんなコンテンツが推薦されるのかが見たくなります。そういうデモを簡単に作れるように作ったのが、（スライドの）左側のツールです。

実際の推薦結果が良さそうだとなると、次はオンラインでの評価（A/Bテスト）に進めます。本番環境で一部のユーザーに新しいほうのロジックを試してもらい、どれぐらいのパフォーマンスが出るかを見るのですが、A/Bテストの設定を行うために作ったCMSが（スライドの）真ん中のものです。

A/Bテストが開始したら、当然結果を見たくなります。ユーザーのログをリアルタイムで集計して、結果をダッシュボードに出すもの（スライド右側のスクリーンショット）も私たちで開発しています。

続いて独自ライブラリの話です。MLである程度規模が大きいデータを扱う場合、自社環境に合わせてデータを扱いやすくするため、共通化されたライブラリなども開発しています。

例えばデータアクセスする際、S3互換データにアクセスする場合もあれば、HDFSやHIVEに置かれているデータを取り出すケースがあります。

また、計算機リソースという観点では、HadoopのYARN上のリソースをSparkで利用したり、Hadoopのシステムの外側にあるKubernetesのクラスタ上のGPUリソースを利用したりするのですが、異なるシステム間でデータを扱いやすくするためのライブラリもあります。

MLをやる場合にも、1つのマシンで動かないような規模感のデータを扱う時に、大規模並列で分散して処理ができて、モデルをその上で組めると作りやすいよね、という話もあります。現在は、こうしたニーズをライブラリで吸収しており、徐々に開発がやりやすくなってきているという状況です。

ライブラリ以外に、扱うデータ自体も、なんらかの標準を作っておくと使い回しやすいので、いろいろなサービスのユーザーの行動ログや、あるいはコンテンツのメタデータを共通フォーマットに落とし込んで、標準的に使える所定のフォーマットでデータを扱っています。

データの規模は冒頭で話したとおり、数億ものユーザーのデータが入っていて、数千万次元の特徴量とか、サービスの数でいうと数十というオーダーのデータを共通化して使えるようにしています。また、これらのデータは社内の他組織にも利用してもらっています。

MLは、一度作ったものを継続的に動かし続けるという特徴があります。このため、リリース後のモニタリングも重要です。

すでに多くのロジックやシステムが動いているため、モニタリングに関しても内製で、自分たちのニーズに合ったシステムを組んでいるところです。

AI開発室とML室の違い

ここまで、ML室が取り組んでいる仕事を事例で紹介したのですが、簡単にまとめると、私たちは、たくさんのデータが生成される事業領域に注力し、機械学習でなんらかの価値を作っていくとか、売上に貢献していくというところにフォーカスしています。

一方、AI開発室は、例えば大規模な言語モデルを作るとか、音声領域に特化するとか、画像で最先端なアプリケーションやユースケースを作っていくというドメインに特化していたり、マーケット自体を作っていくというところに注力をしています。

もちろんML室も画像やテキストなどの情報を扱っています。ですが、私たちがより注力している領域は、どんどん生成されるデータを処理して、サービス横断で機械学習の性能を上げていく、というようなことが多いです。

今ちょうど開発を進めている案件についても紹介します。例えば2021年11月10、11日に開催された「LINE DEVELOPER DAY 2021」では、出前館のMLの話を発表してもらいました。ほかにも、Federated Learningに関しても今取り組んでいます。

開発環境

以上がML室の取り組みのお話でした。では、どういう環境でやっているのかを少し駆け足でお話しします。

ちょっと情報量が多い図ですが、LINEのデータプラットフォームというのは、Hadoopがあって、そこでSQLやSparkを使ってデータの加工をして、取り出したデータを今度はGPUが動くKubernetesの環境に持ってきて、何がしかの結果が得られたら、もう1回Hadoopに戻してみたり、Redisにデータを持っていったりして、リアルタイムでリクエストがきた場合にレスポンスを返せるようにする、というようなことをしています。

このHadoopの環境ですが、私たちはユーザーとして使わせてもらう立場にあります。社内には、Hadoopのシステムの開発運用をしてくれる別の組織がきちんとあって、私たちはその人たちの支援をもらいながら使っています。

この環境に合致するように、私たちは足りない部品や便利な機能を作ったりしているのですが、プログラミング言語としてどういうものを使っているか、どういうふうなライブラリを利用しているかは、スライドを参照ください。

例えばアプリケーションを作る際にAPIが必要であれば、GoやPythonで書きます。データの前処理や加工などにはSparkSQLやPySparkを使うことが多いです。実際の機械学習の計算はKubernetes上で行っています。

MLの開発では、PyTorch、TensorFlow、NumPy、などを使っています。直近だと、一部はONNXを使うケースもあります。もし興味があれば、このあと登壇するエンジニアに詳しく聞いてみてください。

職場環境とプロジェクト体制

実際の職場環境ですが、組織としては30人くらいで、10名ほどが新卒で入ってきてくれたメンバーです。ML室が、一緒に仕事をしているほか組織のメンバーは、例えば先ほどのHadoopの環境を開発・保守してくれているプラットフォームのエンジニアなどが一例です。

また、私たちの推薦エンジンなどが生成したデータは、サービス側の開発者に取り込んでもらう必要がありますし、データサイエンティストに分析してもらって改善を進めたりもします。作るものを決める際には、サービス側の企画者とも話をしながら進めます。

ML室では、ロールが大きく4種類に分かれています。マシンラーニングエンジニアは更に2つに分かれていて青色と黄色で色付けしています。システム寄りのことをやっているのが青色、サービス寄りのところをやっているのが黄色、というふうに分かれています。

MLをやる環境自体の開発運用も必要なので、インフラを扱う人たちもいます（図中、緑色の部分）。あとはプロジェクトの管理とか、プロダクトスペックを決めるなどの仕事もあり、プロジェクトマネージャーとかプロダクトマネージャーもいます。

プロジェクトの体制は、期間と規模によって、必要な役割の人をアサインして進めています。短期間のプロジェクトだと数週間で終わるケースもありますし、半年とか1年とか、場合によっては組織自体を作るというパターンもあります。

チームは今6つに分かれています。さっきの色分けに沿っているのですが、システム寄りのところをやっている人たちと、もうちょっとアプリケーション寄りのところをやっている人に分かれています。この人たちがプロジェクトごとに一緒になって、何かをやっていくという感じです。

求めるエンジニアのスキル・マインドセット

最後にどういうスキルセットやマインドセットを持っている人に来てほしいと思っているかをお話しします。私たちはエンジニアリング組織なので、開発・実装を自分たちでやる、という立ち位置で仕事をしています。

サービスとして提供する以上、作っているものは安定して動く必要があります。自分たちが作っているもの以外にも、使っているものの中身を含めて理解したり、場合によっては直したりということが必要になります。

あとは一般的な話が並んでいますが、自発的に仕事をされる方ほど、おもしろい仕事に巡り会えると思います。責任感というのは、何かあった時に責任を取る、という意味ではなくて、メンテナンスやオペレーションを責任感を持ってやってほしい、という意味ですね。ここまでお話してきたように、私たちは継続的にシステムを動かし続ける必要があるためです。