大量のユーザーデータを横断的に使うために　LINEのデータサイエンティストが気をつけているいくつかのこと

LINEにおけるデータ活用の取り組み

並川淳氏（以下、並川）：本日は「LINEではどのようにサービス横断でのデータ活用を実現しているのか」というタイトルで、並川が発表いたします。私は、LINEではふだん機械学習に関わる開発全般を担当しています。ですが、今日は機械学習に限らず、LINEにおけるデータ活用の取り組みについて幅広く紹介させてもらえればと思っています。よろしくお願いします。

LINEは、みなさんの生活の中のあらゆるシーンをサポートすることを目指し、さまざまなサービスを提供しています。そして、それらのサービスをLINEのMessengerプラットフォームを通じてつなぐことで、個々のサービス単独では実現できない快適なユーザー体験を提供したいと思っています。便利なサービスを提供するためにLINEでは多くのエンジニアが新しいサービスを開発していますし、AI技術の研究開発にも力を入れています。

そしてそれらと同じぐらい重要な要素がデータの有効活用です。各々のサービスから集められたデータをつなぎ合わせ、分析や最適化に用いることでみなさんに有益なコンテンツを推薦したり使いやすいUXを提供したいと、そのように考えています。

先ほど「さまざまなデータを集めて活用する」という話をしましたが、LINEではどれぐらいのデータが日々生み出されているのでしょうか。それを示したのが、こちらの数字です。現在私たちは53のサービスについてデータを収集し、そのテーブル数は17,000を超えています。そして日々追加されるレコード数は7,000億レコードとなっています。これらのデータを集めて保持し、活用するのが私たちの日常となっています。

先ほど紹介したような規模のデータを扱うため、LINEにはData Science and Engineerring センター、略してDSEセンターという組織があります。ここでは詳しい紹介はしませんが、データ活用に対する戦略的な意思決定を担当するData Management室、HadoopやKubernetesクラスタを運用管理するData Platform室。分析や機械学習を担当するData Labs、そしてインフラ面を担当しているEngineering Infrastructure室があります。

これらの組織が連携することでユーザーのプライバシーを最大限守りながら、データによって新たな価値を生み出すことを日々目指しています。

DSEセンターのミッションを簡単に図式化したものがこちらです。各サービスのデータが独立のシステムで管理されていると、当然管理コストが高くなりますし、サービスをまたいでインサイトを探すような分析や機械学習も難しくなります。そこで私たちは、各サービスのデータを1つのプラットフォームに集約し、サービス間で差異がない統一的かつセキュアなデータ分析環境を提供することがミッションになりました。

そしてデータに関する戦略的な意思決定を行い、分析や機械学習をサービス横断で行うことで、バラバラにデータを扱っていては見えてこない知見を得て、LINEのユーザー体験を向上させることをゴールにしています。

アジェンダ

こちらが本日のアジェンダです。最初にデータプラットフォームの話と、その上で動く機械学習の話をします。私たちはサービスのログを集めるだけではなく、それらを機械学習で統一的に扱えるように特徴量化したFeature Storeを作っているので、その紹介もします。

次に、さまざまなサービスのデータをつなぐことで実現できるクロスドメインレコメンデーションという機械学習の話をします。これは、他のサービスの利用履歴を用いて推定することで、よりユーザーが望むコンテンツが発見しやすくなるという話です。こちらについては、どのような改善が得られたかについて事例とともに紹介します。

3つ目が、データ分析とデータマネジメントの話です。最初にデータサイエンティストたちが、ふだんどのような環境やツールを使って分析しているかを紹介し、次に分析に基づくサービス改善の事例を紹介します。その後、そういったデータ活用と同じく、それ以上に重要なセキュリティやガバナンスについてのData Management室の取り組みをご紹介します。

データプラットフォーム「IU」

まずは1つ目。データプラットフォームの紹介から始めたいと思います。LINEのデータプラットフォームの名前はInformation Universe、略してIUと呼びます。IUはいくつかの要素から構成されています。その1つが分散システムで、みなさんもよくご存知のKubernetesとHadoopを使っています。

さらにCephという分散ストレージも利用しています。こちらは、画像や音声、動画などを保存することで、そのようなコンテンツに対する機械学習をやりやすくなるようにサポートしています。

次の構成要素はコンピューティングフレームワークです。IUではデータをストレージから呼び出し、必要な処理を施してストレージに書き戻す際に、Spark、Hive、Flinkなどを使っています。ストリーミング処理がFlink、幅広く汎用的に使われているのがSpark、SQLでTezを使いたいときにHive、といった使い分けが多い気がします。

これらの分散処理フレームワークは、ただIUのデータを処理するためだけではなくサービス側が使っているストレージにデータを提供したり、逆にサービス側からデータを集めてきてIUに保存する際にも利用されています。

そして最後の構成要素がビジネスインテリジェンスです。データサイエンティストや企画者がインサイトを得るために、また機械学習エンジニアがモデルを開発するために、TableauやOASIS、yanagishimaなどのツールが提供されています。この部分については、データサイエンティストの活動を紹介するときに分析環境の紹介というかたちで再度説明する予定です。

IUは、データプラットフォームとしてはかなり大きな部類に入っているのではないかと思っています。その大きさは、現時点でサーバ台数が2,500台以上、ストレージのサイズは270ペタバイト、日々のワークロードは30万を超えています。このような大きなクラスタを安定に運用するのもDSEセンターの重要な役割の1つです。

IUのユーザー特徴量

次に、IUの上に構築しているユーザーの特徴量について説明します。IUは各サービスのログやコンテンツのデータを直接サービスのDBを参照して、またはKafkaを通じて収集しています。収集の方法は、ストリーミングもあればバッチの場合もあります。IUでは、過去1年間のデータを見て季節性の要因を探すような、そういう分析が行われることもありますし、ストリーム処理で得られたデータに対して、機械学習をしているようなケースもあります。

そのためIUには、リアルタイム性と過去のデータを長期間保存するという両方の性質が必要になってきます。IUに入ってきたデータは整形され、サービスごとの差異を吸収して横断的に利用できるFeature Storeに格納されます。LINEではそれをZ-Featuresと呼んでいます。機械学習にはユーザーの行動ログとコンテンツの情報の両方が必要なので、それらを連携できるかたちで保存しています。

またディープラーニングで使いやすいように、特徴量を埋め込みベクトルに変換したデータも提供していて、機械学習のタスクによってはそちらを利用しています。得られた特徴量は、コンテンツの推薦やクラス分類、CTR予測のようなタスクのインプットとして利用されて、各々のサービスに反映されています。このとき、サービス側は自らのサービス以外のデータを使った機械学習の結果も得ることができます。

これは、LINEのような多くのサービスをもつプラットフォームにおいては大きな利点となります。実際にどれぐらいのメリットがあるかについては、後ほど事例とともに紹介したいと思います。

ここに載せているのは、機械学習で共通して利用できるデータの一覧です。LINE公式アカウントやタイムライン、OpenChat、LINE広告やLINE NEWS、LINE MUSICやLINEマンガなど、さまざまなサービスのデータが一元管理されていて、共通のフォーマットで呼び出して、機械学習のモデルに入れることができます。

このZ-Featuresがもつ情報ですが、現時点で特徴量の次元は6,200万以上、ユーザー数についてはノンアクティブなものも含めてグローバルで9億以上になります。次元もレコード数も多いのですが、仕様が共通化されているので、LINEの機械学習エンジニアはデータを読み込んで自分の作ったモデルに簡単に投入できるようになっています。

サービス横断でデータを最適化に使っている事例

ここまでは、データプラットフォームについての話をしてきました。ここからはそういったプラットフォームを使ってサービス横断でデータを最適化に使っている事例について、紹介していきたいと思います。

異なるサービスで得られたデータを、自分のサービスにうまく転移させて推薦の精度を上げる話として「クロスドメインレコメンデーション」というものがあります。厳密には、ここでいうドメインにはいろいろな解釈があるのですが、ここでは一番シンプルな「アイテムの種類が違う」という話を考えます。あるサービスで、ユーザーがどういうものを好むかがわかれば、他のサービスでもその情報を活かして推薦できるというわけです。

LINEでは、そのようなサービスをまたいだ情報を使った推薦は、至るところで行われています。例えば、タイムラインでは投稿の好みを推定するのに、LINE NEWSやLINE LIVEのサービスログを使っていますし、着せかえショップのおすすめではLINEスタンプの購買履歴を使っています。ここで、タイムラインのディスカバーと着せかえの推薦については、それぞれ今回のLINE DEVELOPER DAYでも発表があるので、そちらも興味があればぜひご覧ください。

今日この場では、3つ目のSmart Channelの事例について紹介いたします。

Smart Channelとは何か

最初に、Smart Channelとは何かについて簡単に説明します。Smart Channelは、LINEのトークタブの最上部にさまざまなサービスのコンテンツを表示するサービスです。ユーザーが好むサービス・好む情報は、一人ひとり異なるので、その人に合ったコンテンツを適切なタイミングで表示することが必要です。そのためSmart Channelの裏側では、推薦システムが動いています。

それではユーザーの元にコンテンツが届くまでに推薦システムはどのような処理を行っているのでしょうか。それを理解するために用意した概念図がこちらです。Smart Channelは、2段階の推薦システムを採用しています。最初のステージでは、左側に書かれた各サービスの推薦システムが、それぞれのサービスにおける推薦リストを作ります。

この例ではLINE NEWS、LINE占い、LINEスタンプの推薦リストが描かれています。実際にLINE NEWSやLINEスタンプは独自の推薦システムをもっているので、そのシステムの出力を使用しています。これらの推薦リストの情報は生成され次第、Smart Channelの推薦システムへと送られます。

そして、2段目の推薦システムである「CRSエンジン」が、複数の推薦リストに含まれるコンテンツの中からユーザーに届けるコンテンツを1つ選びます。選ばれたコンテンツはチャットタブの上部に表示され、例えばクリックしたかどうかなど、ユーザーのフィードバックを経てCRSエンジンは何をユーザーに表示するべきかを学習していきます。

CRSエンジンはどのようにコンテンツを選ぶのか

CRSエンジンが、どのようにコンテンツを選ぶのか。その最適化の特徴を3つ紹介します。1つ目はユーザーのセグメントです。CRSではZ-Featuresに集められたユーザーの行動ログを基に、ユーザーの属性を推定し、それを特徴量として利用しています。

2つ目はContextual Banditsです。Smart Channelは最新の情報をユーザーに届けることを目標にしているため、多くのコンテンツが最大24時間しか表示されません。そのため、十分なログデータがない状態でのコールドスタート問題に対処することが必須になります。その解決のためユーザーが好むコンテンツは何かというのを探索する部分と、実際にユーザーが好むコンテンツを選ぶ適用の部分、この探索と適用のバランスを上手に行うことができるバンディットアルゴリズムを採用しています。

さらに同じコンテンツであってもそれを好むかどうかはユーザーごとに異なるので、そういったユーザーごとの違いなどを最適化にうまく反映するために、Contextual Banditsを採用しています。Smart Channelはリアルタイム性の高い最適化が必要なため、この部分はオンラインで学習されています。

3つ目は、クロスドメインでの埋め込み、表現学習です。ユーザーはSmart Channelにおいてさまざまなサービスのコンテンツを見て、場合によってはクリックしたり、×ボタンを押してミュートにしたりします。そういった、ユーザーがコンテンツに対してどのようなアクションを取るかを予測するために、ユーザーとアイテムの表現学習を行い、先ほど説明したContextual Banditsの特徴量に利用しています。

この部分も、バンディットと同様にオンライン学習されています。この学習により、ユーザーのベクトル表現、アイテムのベクトル表現ともに、さまざまなサービスを横断して学習されるため転移学習の効果で、最適化がされやすくなっています。

クロスドメイン最適化の効果

ここでは、クロスドメインの最適化の効果がどれくらいあったのか、1つの事例を基に紹介します。今日紹介するのは、新しい無料スタンプをSmart Channelで配信したケースです。対象は日本の全ユーザーで、1回目のトライアルはクロスドメインの表現学習を行わないケース、2回目は行ったケースです。

これが2つの実験を比較した結果になります。1回目のテストに対して2回目で数字がどれくらい変化したのかを示しています。まずインプレッション数、つまりユーザーに表示された回数ですが、こちらは36倍に増えました。Smart ChannelのCRSエンジンではContextual Banditsによって、よりユーザーに好まれると判定されたコンテンツが多く表示されます。

クロスドメインの表現学習を適用することで、無料スタンプを好む人と好まない人を素早く学習できて、結果的にインプレッション数が増えています。そして真ん中がCTRのリフトです。表示されている回数が大幅に増えているのにもかかわらず、CTRも40パーセント改善しています。

そして、最後がスコア。これはクリック数と×ボタンを押してミュートした回数の比で、ポジティブな評価とネガティブな評価の比になっているんですが、こちらの数字も大幅に改善しました。LINEのように、多くのユーザーがいるMessengerプラットフォームを軸にさまざまなサービスが存在するケースでは、クロスドメインのような機械学習は、大きな成果をあげやすいと感じています。

今紹介したように、Smart Channelにおいてはクロスドメインレコメンデーションが非常に大きな効果がありました。CRSエンジンでクロスドメインの表現学習ができるようになったことと、またサービス横断データが十分に溜まってきたので、最近ではサービス側の推薦システムなしでも、直接コンテンツを受け取って配信できるようになりました。

図の一番下のService Dから伸びている矢印がそれです。こうすることで、すでに成熟した推薦システムをもつサービスは、これまでどおり2段階の推薦をすることで高い精度を出しつつ、そうではない新規サービスや新しい種類のコンテンツについては、コンテンツを用意するだけで他のサービスの実績から最適化がかかる、といったことが実現できるようになっています。

データ分析とデータマネジメントの取り組み

これまでは、機械学習の取り組みについて紹介してきました。ここからはデータ分析とデータマネジメントの取り組みについて紹介します。

LINEではData Labsに所属するData Scienceチームが各サービスの分析を担当しています。Data Scienceチームは4つに分かれていて、それぞれが担当するサービスに対して分析をしています。

一方で同じData Labsのチームなので、分析事例の共有を頻繁に行うような横のつながりもあって、例えばあるサービスの分析で得られた知見は、他のサービスの分析にも活かされています。

これから、少しデータサイエンティストがふだん使っているツール群を紹介していきたいと思います。1つ目はBIツールです。OASISというSparkやPython、Rが使えてグラフなどを書くことができるツールや、yanagishimaというSQLを素早く実行できるツールがあって、これらを用いて、IUクラスタにあるデータに簡単にアクセスできます。これらのツールは、データサイエンティストだけではなく、エンジニアや企画者も使って日々データを確認しています。

2つ目はアナリティクスのツールです。LINE Analyticsというクライアントのログをグラフにして表示するツールがあって、サービスのデータを素早く確認できるようになっています。

3つ目はA/Bテストのツールです。LibraというCMSでA/Bテストの期間や対象ユーザー、サンプルサイズをサービス共通で管理できて、そのA/Bテストの結果はLibra Reportで自動的に集計されて確認できます。

こういったツール群を使って、データサイエンティストたちは日々インサイトを得るために活動しています。

2つのデータ分析事例

データサイエンティストたちが、ふだんどのような分析をしているのか。イメージしてもらうために分析事例を紹介します。

1つ目はチャットメニューのリニューアルのための分析です。ユーザーの使い勝手を向上させるために、メニュー画面のリニューアルを検討したのですが、その場所はさまざまなサービスの動線にもなっている場所なので、ここを変えると広範囲に影響が出ます。つまりどこかの数字がよくなったが、他の数字が悪くなるといった結果が簡単に得られます。そのため、KPIの設計と分析が非常に複雑なものになります。

もう1つは、new UI biasで、ユーザーは使い慣れたUIを好むので、変更直後はいろいろな数字が悪くなりやすいです。そのため長期的に見たらこの変更はユーザーに受け入れられるいい改善なのか、それとも単純に改悪になっているかを短い時間で見極めるのは、非常に難しい問題になっています。ここの部分はデータサイエンティストの腕の見せどころになっています。

2つ目は、LINE公式アカウントにおけるオープンスコアの取り組みです。これは分析の結果、メッセージを多く受け取るほどユーザーは開封しなくなっていく傾向があるということがわかったため、メッセージを送りすぎずに、効果を最大化するような配信頻度の最適化の取り組みになっています。こういった分析やデータに基づく改善がデータサイエンティストの主な業務です。

なお、ここで紹介した2つの事例については今回のLINE DEVELOPER DAYで発表があるので、もし興味があればそちらもぜひご覧ください。

LINE公式アカウントを使ったターゲティング配信の改善事例

ここでは1つデータサイエンティストが行った改善事例を紹介します。それは金融サービスにおけるLINE公式アカウントを使ったターゲティング配信です。

金融の各サービスにおける役立つ情報を、LINE公式アカウントを通じて配信するという施策なわけですが、先ほどオープンスコアで話をした通り、ターゲティングをせずにただ送るだけでは逆効果ですし、ユーザーにとっても不快です。そこで必要な人にだけメッセージを送る必要があります。この施策の初期は対象者を抽出するルールは配信の度に毎回人が考えて人手で抽出していました。

例えば金融系のLINE公式アカウントをいくつフォローしていて、年齢は何歳から何歳までのユーザーに配信するといったルールを決めていました。ですが現在では、それをLookalikeという手法で置き換えています。その置き換えにまつわる事例について紹介いたします。

まず、Lookalike Audienceターゲティングとはどういうものかについて簡単に説明します。これは与えられたユーザーグループをSeedユーザーとしてそのユーザーに似たユーザー集合を返すようなシステムです。図でいう、黄色で書かれたモジュールがLookalikeエンジンで、ユーザー群から似たユーザー群を推定・計算する処理を行っています。

そしてユーザーが似ているとはどういう意味かということですが、それはLINEのさまざまなサービスを利用したときの行動パターンの類似から判定しています。具体的にはZ-Featuresに溜められた最大6,000万次元の特徴ベクトルを使って、類似性を判定しています。つまりLINEのいずれかのサービスを使ったことがあるすべてのユーザーがターゲティング対象になります。

自サービスを使っている特定のユーザーに似たユーザーたちを、まだサービスを使ったことがない人たちにまで拡大してターゲティングできるのが、このシステムの特徴です。

こちらが、人手でマニュアルでターゲティングした場合と、Lookalikeターゲティングをした場合とでA/Bテストした結果になります。画像は実際に配信したメッセージで、丸の中にLookalikeターゲティングをしたことで向上したCTRとCVRのリフト値を載せています。結果を見るとわかるように、Lookalikeターゲティングで精度が改善していることがわかります。

それに加えて、ターゲティングを自動化できるようになったことで、これまでユーザーの抽出に使われていたデータサイエンティストの時間をより発展的な分析に回すことができるようになりました。

データマネジメントの3つの取り組み

さてここまでは、データをどのように活用していくのかという話でしたが、一方で私たちはデータの安全性やクオリティを守っていく必要もあります。そのようなデータマネジメントの取り組みについても紹介します。

1つ目はもっとも重要なセキュリティの話です。まずはシステム的な話ですが、IUクラスタの認証はLDAPとKerberosを使っています。そして認可はApache Rangerを使っています。さらに監査対象のためのAuditログも取っていて、こういったシステム的な対応があることを前提に、Data Management室が情報セキュリティ室とコンタクトを取りながらデータ使用のガイダンスの作成や教育を行っています。

2つ目はデータカタログの用意です。1万7,000以上もあるテーブルに、どういったデータがあるのか。まとまった情報がないと把握することは困難を極めるので、カタログ化の作業と仕組みを用意しています。このカタログの中には、各カラムの意味だけではなく、このデータがどこ由来のデータなのか。またそのデータオーナーが誰なのかなどの情報も含めて載っています。

そして3つ目はデータガバナンスです。誰がデータにアクセスできるべきか、どういったデータの利用方法は許されるのかなどを決めていく仕事になります。

こちらはデータカタログの画面の一例です。各テーブルのそれぞれのカラムについてそれがどういった意味をもつデータなのか、そのデータがETLされる場合はどこのテーブルが由来なのかという情報が、簡単に一目で見れるようになっていて、しかもすべて検索できるようになっています。

そしてData Management室はデータにまつわるすべての問い合わせの窓口にもなっています。サービスの企画者やエンジニア、データサイエンティストや機械学習エンジニアの問い合わせを一手に引き受けています。セキュリティやプライバシーポリシー、リーガルの担当部署とのハブになって、必要な回答をしていくような組織体制を構築しています。

今後の展望

ここまで駆け足でしたが、LINEにおけるデータ活用についてプラットフォーム、機械学習、データ分析、そしてデータマネジメントの観点から紹介しました。最後に今後の展望について紹介したいと思います。

私たちは、IUという統一的なデータプラットフォームを構築してきました。そこで私たちはLINEのさまざまなサービスのデータを統一的に扱えるようになったのですが、今度はその上で機械学習のプラットフォームを統一し、機械学習のエンジニアやデータサイエンティストがより快適に素早く成果を出せる環境を作ることを目標にしています。ここではその主要なコンポーネントについていくつか紹介していきたいと思います。

1つ目は、DeepPocketです。こちらにはOCRやObject detectionなど、やや世間ではAIと呼ばれるケースが多いような機能をAPI提供するサービスです。画像に出ている例は手書き文字をOCRで認識した例です。この謎のオブジェクトは僕の息子が作った人形で、それに手書きで文字を入れたところ、きちんと認識できたという例になっています。

この統一のマシンラーニングプラットフォームでは、このようなAPIのサービングにDeepPocketを使います。

2つ目はJutopiaです。こちらも機能が多くて紹介が非常に難しいのですが、Jupyterを軸にした統合的な開発環境で、実験だけではなくそこからモデルのデプロイまでも目指したプラットフォームになっています。このJutopiaについても今年のLINE DEVELOPER DAYで発表がありますので、もし機械学習の開発環境などに興味がある方はぜひそちらも聞いてみてください。

次は、Datagroundです。これはIUクラスタとつながることを前提に設計されたKubernetesクラスタです。私たちは、もはやふだん、機械学習のタスクはKubernetesで動かすことが非常に多いです。またIUのデータを使うことが基本的にデフォルトの状態なので、そういったKubernetesをIUのデータを使いやすいように作るというインフラ部分をこのDatagroundに統一しようとしています。

これが最後のコンポーネントで、Masalaと呼んでいる機械学習用の分散処理ライブラリです。IUには非常に大きなデータが存在するため、機械学習エンジニアはそれらを効率的に扱う必要があります。しかし、個々の機械学習エンジニアやまたは機械学習に関わる研究者が、独自に並列計算を書くのは非常にコストが高いです。

なので、その部分をライブラリ化して並列計算が簡単に使えることを目指して開発しています。このライブラリの特徴ですが、TensorFlowやPyTorchなど、ふだんよく使われているフレームワークはそのまま使うことができて、かつZeroMQやMPIなど並列計算の高速化、効率化のために使っている少々研究者に難しい部分はユーザーが知らなくてもよいように隠ぺいされる、そういう設計になっています。

こちらについてもGheeというタイトルで、LINE DEVELOPER DAYで発表があるので、もし興味があるようでしたらぜひ聞いてみてください。