「LINEアプリ」「出前館」などサービス横断でマシンラーニングを担当　LINEに欠かせない技術領域を担う専門部隊の業務内容

研究領域での経験が豊富な室長

菊地悠氏：メイン領域の説明をします、菊地と申します。よろしくお願いします。

簡単に自己紹介をいたします。肩書はシニアマネージャーで室長をやっています。今はマシンラーニング領域において、プラットフォームを開発している組織とソリューション系の事業貢献をメインにしている組織の2つを見ています。

私は、エンジニアかと聞かれるとちょっと自信がなくて、プロダクトマネージャーという肩書のほうが、個人的にはしっくり来ます。

少し背景を説明すると、Work Experienceというところに書いてあるとおり、研究の領域でさまざまことをやってきたという経歴で、なんでも屋さんにちょっと近いかなと思います。

左側に貼ってある写真は昔のもので、右下の写真は社会人になってからわりと日が浅い頃、当時米国で仕事をしていた頃に、国立公園に行って撮った写真です。LINEに入った後に、家族や子どもを連れて、もう1度同じ場所に行って、キャンプをしたという思い出です。

具体的な活用事例　スタンプのレコメンデーションとタグ付け

具体的にいくつかピックアップして紹介していきます。まずわかりやすいところでは、スタンプのレコメンデーションというものがあります。データのボリュームとしては、おすすめのアイテム、商品の数が1,000万というオーダーで存在します。また、ユーザー数はアクティブユーザーで数えてもLINEアプリはグローバルのMAUが1.7億人を超えます。

これらのユーザーが、スタンプショップを訪問した時に何をおすすめするかというロジックを作ったり、A/Bテストをして新しいものにどんどん置き換えていったりしています。

もう少し詳しい話が知りたい、という方がいらっしゃれば、右下にリンクも貼ったので、参照していただけたらなと思います。

スタンプに関しては、Auto-Taggingという機能も提供しています。これは、文字を入力すると、その意味に近いスタンプが表示されて選べるというものです。

一部のクリエーターさんが個々のスタンプに、これはこういう意味だよとタグを付けてくれているのですが、その他多数のスタンプにはタグが付いていないので、このようなスタンプ画像に、自動でタグ付けをしています。

具体的な活用事例　広告における性別判定

Smart Channelと呼ばれる、トークタブの上部に出てくるコンテンツや広告に関しては、コンテンツのロジックを数十というオーダーで提供しています。

（スライドを示して）この表示面には、いろいろなサービスが、「この人にはこういうコンテンツを出したい」という情報を独立に提供してくれる作りになっているのですが、表示できるのは1つだけなので、最終的にはその中から1個だけを選んで表示する最適化の仕組みが入っていて、Multi-armed banditと言われる技術を利用しています。このあたりのロジックも開発や改善を検討しています。

続いて、属性推定について。LINEアプリの利用者に対して、年齢や性別などの情報は提供してもらっていないのですが、例えば、「コンテンツを配信したい」とか「広告を配信したい」というニーズがあります。このため、こうした属性情報をマシンラーニングで推定しています。

これも数億というユーザーのデータを扱っていて、最近もモデルを新しいものに置き換えたりしています。

具体的な活用事例　出前館における商品のレコメンドとドライバー向け予測情報

ここ1、2年で新しく始めた話として、出前館の取り組みがあります。2021年の「DEVELOPER DAY」でも発表しているのですが、マシンラーニングの機能をいくつも提供しています。

具体的には、商品のレコメンドに加え、お客さまが実際にオーダーをした後に、どれくらいの時間で配達が完了しそうかというのを予測したり、あるいは配達をしてくれるドライバーとして誰にアサインをお願いすればよいのか、といった処理を提供しています。

ほかにも、ドライバーの方向けに、どのあたりで待っているとお客さんから注文が入りやすいのかを予測した情報も生成しています。

以上が、アプリケーションやサービスという観点での紹介でした。

マシンラーニング開発効率化・DSの検証効率化のためにツールを内製

このように、さまざまなサービスに対してML（マシンラーニング）の機能を提供していくにあたり、共通化部分を増やすための取り組みもいろいろ行っています。

まず「Libra（リブラ）」と呼んでいるツールを紹介します。推薦エンジンを作った時に、今動いているものと新しいものがどう違うか、定性的に把握したいという場面があります。

こういった場合に、単純にデータを覗くと、誰々さんというユーザーIDに対して、アイテムのIDだけが並んだ情報が入っていて、こちらの方が指標が良い、みたいになってしまうのですが、実際にどういうものが推薦されているのかを可視化して、事業部に見てもらったり、内部でどれをA/Bテストに進めるか判断するために使ったりしています。

スライドの中央にあるのは、実際にA/Bテストをする際に設定をするためのCMSです。どれくらいのユーザーに、いつから何種類のパターンで違うコンテンツを出すかということを整理するために使います。また、リアルタイムでA/Bテストの結果を見るダッシュボードなども作ったりしています。

複数のサービスのデータやソリューションを提供していると、機械学習のデータの作り方も共通化したくなります。

z-featuresと書いてあるのが、ユーザーのログをサービスに関係なく同様の形式で加工してマシンラーニングで入力、特徴量として使うためのものです。もう1つ、コンテンツの情報もメタ情報を管理するために共通したテーブルを作っています。

生データそのものに関しては、取り扱いを多少注意しなくてはいけませんし、スパースで非常に次元が大きいデータなので、MLで取り回しが難しいケースもあります。その場合、表現学習という処理をかけて、別の密なベクトル（図中のy-features）に変換し、後段でマシンラーニングの処理を走らせるということもやっています。

データ以外に、開発に使うライブラリ等も自作しています。データのレイヤーを抽象化してアクセスを簡単にしたり、なんらかの動的チェックを入れられるようにするものや、Kubernetesクラスタ自体を隠蔽して、Remote Procedure Callが簡単に呼び出せるようにするようなライブラリも作っています。また、MLのモデルの実装も、ghee-modelsという社内で利用しているライブラリに入れていく、という活動を進めています。

Machine Learning室の担当領域

冒頭で、LINEには他にもML組織があるとお伝えしましたが、私たちの組織は、大量のデータが生成される事業領域に注力しています。

あとは、サービス横断でマシンラーニングを扱っているので、さまざまなサービスやデータに触れる機会があります。

開発環境と使用言語の説明

開発の環境に関して紹介をします。LINEにはデータプラットフォームがあり、マシンラーニングをやっている私たちも、1ユーザーとして、この環境を使わせてもらっています。

「Hadoop」にはさまざまなサービスのたくさんのデータが入っており、そのデータを加工するために「Spark」という技術を使っています。

データを加工しMLの処理を行う部分はこの図には描かれていませんが、処理した結果は再度Hadoopに出力したり、「Redis」の環境に入れたりして、サービスに提供しています。

ビジネスインテリジェンスと書かれている部分は、作ったもののデータの中身を確認するダッシュボードやアドホックな分析をするためのツールなどで、これらも利用させてもらっています。

開発に使っている環境や言語は、ここに簡単に書きました。私たちの組織は、サーバーの開発にはPythonとGoを使うことが多く、マシンラーニングのモデルの実装等ではPythonを多く使います。

また、データの加工に関しては、先ほどお話ししたHadoopにたくさん情報が入っているので、「SparkSQL」や「PySpark」を利用しています。

MLのモデルの実装は「PyTorch」をメインで使うケースが多いのですが、「TensorFlow」で動いているものもあります。

その他ライブラリで、低レイヤーで並列で高速に分散処理をするようなところだと、「MPI」や「ZeroMQ」などが使われています。

MLのアプリケーション、ライブラリ、ツールを開発している中で、「もう少し簡単に使えるように」となれば、裏側で動いているシステムやプラットフォームもさらに隠蔽して、API越しにサービスを呼び出せるものもあります。

直近だと、「ML Batch APIs」という名前で、たくさんのMLのモデルにアクセスできる仕組みを整えています。

ちなみに今映している画面は、実際に社内で運用しているシステムなのですが、画面を設計したり作ってくれるUI関係の社内組織と連携して開発を行っています。

チャレンジしている技術領域は、Federated LearningやDifferential Privacy

直近でチャレンジしていることをお話しします。Federated LearningやDifferential Privacyという技術領域があります。

簡単にいうと、処理をサーバーと、クライアント側の両方で行うのですが、クライアント側で学習・推論を走らせ、生のデータがなるべくクライアントから出ないようにしつつ、複数のクライアントから送られてくる学習結果をサーバー側で統合し、1つのMLモデルを更新する、というようなことをやっています。

最近はチームや組織が徐々に大きくなってきているので、新しいことに取り組む際に、チームをまたいでやりたいことが出てきています。そのため、リサーチプロジェクトというものを設定し、やりたい人が手を挙げて、毎週集まって、論文を読んだりサーベイしたりするところから始めて、なんらかの開発案件に落とし込んでいくという活動もしています。

（スライドを示して）今映っているのは、最近やったものや、これから始めようとしている内容です。

Machine Learning Platform室・Machine Learning Solution室のロールの違いとは？

仕事をする環境に関して、少し説明します。2つの組織があり、Machine Learning Platform室と、Machine Learning Solution室に、機械学習エンジニアがそれぞれ配属されています。

名前からイメージできるように、仕事の内容は少し違いますが、プラットフォーム開発、システム、API等を作るのはMachine Learning Platform室が中心になります。一緒に仕事をする相手は、プラットフォーム開発者です。開発したものを使ってもらう人たちは、データサイエンティストやマシンラーニングエンジニアです。

一方、Machine Learning Solution室が一緒に仕事をするのは、サービスの企画者や、サービス側の開発者です。

内部でどういうロールがあるかというと、先ほどお話ししたように、マシンラーニングエンジニアは2種類あり、プラットフォーム寄りかサービス寄りかで異なります。

それ以外に、システム、API、ライブラリ、場合によってはインフラを管理していく必要があるので、DevOpsのエンジニア、サーバーサイドのエンジニア、データエンジニアなども組織の中にいます。

プロジェクトの中では、異なるスキルセットを持った人たちと一緒に仕事をしていくので、PMの役割もあります。

実際にプロジェクトを進めていく際には、プロジェクトの規模や対象によって、アサインは都度変わるのですが、（スライドを示して）例えば一番左、サービス向けにマシンラーニングのエンジンを開発して、レコメンドを提供できるようにしましょうという場合だと、開発は小規模なので、PMが1名立って、場合によってはサーバーサイドのエンジニアがサポートに入りながら、ソリューション系のマシンラーニングをやるエンジニアが主に進めていくという体制をとります。

モデル開発そのものをやる場合には、マシンラーニングのソリューション系をやる人、システム系をやる人のどちらも参画して開発を進めます。

また、周辺システムを開発する際には、サービス寄りのマシンラーニングエンジニア抜きで進めますし、より大きなシステムを開発する場合には、作る人、使う人、全部入り乱れて開発をしたりするケースもあります。