国内月間アクティブユーザ数8,400万人
メッセンジャーだけではなく、
サービス上で提供される情報やコンテンツのデータサイズ、
日々データが大量に蓄積・
LINE社内における機械学習を活用した企画やプロジェクト・
菊地 悠 氏
今回、
前編では、
LINE全社のデータ戦略を担うDSEセンターとは
- ――今年3月に行われた組織再編と絡めて、
LINEのDSEセンターや、 その傘下にあるData Labs、 ML1チームについて、 組織体制や概要に関してお教えください。 DSEセンターは、
2019年3月に発足しまして、 データ活用系の組織である 「Data Labs」、 情報セキュリティや法務などとも連携し、 データのガバナンスと活用を推進する 「Data Management室」、 インフラ系システムおよびデータ関連の各種システムを開発管理する 「Data Platform室」、 という3つの組織から構成されています。 DSEセンターは、
LINE全社・ 全事業のデータを集約し、 全社のサービス横断でのデータ活用やガバナンス・ インフラの構築や保守運用を推進しています。 その中でData Labsは、
集約されたデータを使って何かしらのアウトプットを行い、 事業貢献をしていくデータ活用を担っており、 私たちML1チームもData Labsの傘下に属しています。 Data Labsのファンクションとしては、
大別して、 マシンラーニング系のML1チームとデータ分析系のData Science1〜4チーム （以下、 DSチーム） があり、 また今年3月の組織再編を経て、 OCR, Speech, NLPなどの特定分野に特化したチームや、 リサーチを中心に取り組んでいるMachine Learning2チームなども合流しました。 DSチームとML1チームは、
いずれもデータ活用を通して事業に貢献することを目指していますが、 技術的な強みや関わる相手、 あるいは事業側のメンバーとの連携のフェーズなどに違いがあります。 DSチームは、
事業の企画、 戦略を立てて推進する経営層など、 事業側の企画者や意思決定者などとコミュニケーションをする機会が多いです。また、 事業が成長フェーズに入ってきてある程度データが集まり始めたときに、 次に何をすればよいのか？ をデータ分析でアプローチする、 といった業務もしています。 一方のML1チームは、
機械学習を用いたシステムを開発し、 保守運用しながらエンジニアリングプロダクトを提供することをおもな業務としています。たとえばあるサービスでレコメンデーションをしたいという要望があった場合、 規模の大きなサービスで十分にデータがあるケースもあれば、 ローンチ前でユーザのログデータなどが存在しないケースもあります。 誰と一緒に仕事をするかという観点では、
ML1チームは、 事業側の開発者との仕事も多いです。仕様を決めるために企画者ともコミュニケーションは取りますが、 最終的にはシステムの開発を行い、 ローンチ後も機械学習のシステムを運用し続けるというエンジニアリングに集中しています。 - ――DSチームが集約してきたデータを、
ML1チームが、 システムをブラッシュアップするため活用する、 といった業務の流れが一般的なのでしょうか？ ケースバイケースです。先に述べたように、
それぞれ独立に業務を行う場合もありますし、 大きなプロジェクトでは、 一緒に企画段階から仕事を行う場合もあります。
データを横断的に活用し、機械学習で事業貢献するMachine Learning1チーム
- ――ML1チームのミッションをお教えください。
ML1チームのミッションは、
LINEの提供するさまざまなサービスのデータを横断的に活用して、 機械学習で事業貢献することです。この際に、 我々は個別の事業に属さない組織として、 開発したノウハウを 「社内で広く横展開できるかどうか」 を強く意識しています。 どういうことかというと、
たとえばLINEでは、 メッセンジャーだけではなく、 スタンプや、 ニュース、 マンガなど多種多様なサービスを展開しています。 さまざまなサービス個別に要望を聞いていくと、
似通ったニーズや課題が出てくるのですが、 エンジニアリング観点で考えると、 1度開発したソリューションを、 その他のサービスでも使うことができれば、 開発効率や保守性の観点でもメリットがあります。したがって、 何かを作るときには、 共通化ができるか、 横展開ができるか、 などを必ず考えるようにしています。 - ――ML1チームでは、
どのように機械学習を活用したソリューションを社内のサービスに提供しているのでしょうか？ 過去には、
サービスの企画者から 「コンテンツをたくさん用意したので、 それらをユーザにパーソナライズして提供したい」 といったかたちで要望をもらい、 個別に推薦システムを作ることが中心でした。 最近では、
DSEセンターの外も含めて、 機械学習を取り入れて開発を行うチームがいくつか立ち上がってきているので、 我々は、 スタンプやマンガなど、 いくつかのサービスにも注力しつつ、 特定のサービス向けではない、 よりプラットフォーム的な推薦システムなどを開発する、 といった方向に変わってきています。 ちなみに、
過去に開発し、 既に運用しているレコメンドエンジンなどは、 DSチームと連携してA/ Bテストを行い、 新しいアルゴリズムに置き換えるなどの改善も行っています。最近では、 A/ Bテストを通じて、 他の組織に開発を引き継ぐようなケースも出てきています。
Machine Learning1チームが携わった開発事例
- ――ML1チームの具体的な開発事例を教えてください。
LINEスタンプのレコメンデーション機能についてご紹介します。LINEスタンプに関しては、
アプリ内の表示領域によって、 異なるアルゴリズムを使い分けています。 LINEアプリ内からアクセスできるスタンプショップでは
「あなたへのおすすめ」 という画面がありますが、 ここでは過去にリリースされたほとんどのスタンプを対象にして、 レコメンデーションを生成しています。 一方でトークリスト最上部にある
「Smart Channel」 （スマートチャンネル） という、 スタンプのほかにも、 天気、 ニュース、 マンガなど、 さまざまなコンテンツ情報を横断的に表示させる領域では、 上記とは異なる手法でレコメンデーションを行っています。 たとえば、
リリースされて間もないスタンプには、 販売実績のログデータがそれほど集まっていません。Smart Channelの場合は、 普段チャットをするために開くトークリストの最上部に 「わざわざコンテンツを露出」 するので、 基本的には 「新しいコンテンツ」 を届ける、 ということを行っています。このため、 ログデータが十分に蓄積されていない段階でもユーザへ効果的にレコメンデーションを提供できるように、 ユーザからのフィードバックをリアルタイムに活用しながら表示するコンテンツを選択する仕組みを導入しています。 少しややこしいのですが、
LINEには既存のサービス向けに提供済みの、 各種レコメンデーションやターゲティングロジックが存在していました （図4 「Layer #1」 参照）。この1層目の個別ロジックは、 「各ユーザにパーソナライズしたコンテンツ」 を、 表示候補としてSmart Channelに提供します。たとえば、 先に述べたスタンプのレコメンドもこうしたロジックの1つです。 そのうえで、
Smart Channelは、 さまざまなサービスから集められたコンテンツのうち、 何をユーザに表示するかをリアルタイムに最適化する仕組み （図4 「Layer #2」 参照） を提供しています。
Smart Channel開発の裏側
- ――LINE DEVELOPER DAY 2019でエンジニアフェローである並川淳氏のセッション
「LINEサービス全体でスマートなレコメンダーシステムを構築する」 で解説されたSmart Channel開発の裏側ですね。
当セッションでは、販売実績などのデータが十分に蓄積されてないローンチ段階で起こり得る 「Cold Start問題」 についても述べられています。 このCold Start問題に対処するため、 Smart Channelの開発では、 バンディットアルゴリズムの 「Bayesian Factorization Machine」 といったモデルが利用されたそうですが、 このモデルを採用したのはなぜでしょうか？ Smart Channelの場合、
とあるコンテンツが表示されたとき、 ユーザは 「『タップして詳細ページに遷移する』 というポジティブなフィードバック」、 もしくは 「『右上にある×ボタンで閉じる』 というネガティブなフィードバック」 を行うことができます。 裏側にあるアルゴリズムは、 このフィードバックを事前に予測し、 「どのコンテンツを出すと、 ユーザがポジティブなフィードバックをしてくれそうか」 を都度計算しています。 この予測の問題は複数のアルゴリズムが選択可能な設計になっているのですが、
「Bayesian Factorization Machine」 で、 計算しているものが多いです。 「Factorization Machine」 は、 多項式で表現される一般化された線形モデルに、 スパースな特徴ベクトルを次元圧縮した項を加え、 相互作用あるいは交互作用と呼ばれる非線形性をうまく組み込んだモデルです。Smart Channelでは、 クリックなら1、 ｘボタンクリックなら0、 どちらでもなければ0. 5、 という値を予測する計算が行われています。 さらに、
Factorization Machineの数式の各項の係数が取りうる値に制約を設けており、 ベイズ確率を採用したパラメータ更新を行っているため 「Bayesian Factorization Machine」 という呼び方になっています。あるコンテンツがユーザに露出した後、 リアルタイムに集まってくるフィードバックが増えれば増えるほど、 推定された係数の確からしさが高まる、 といったイメージでしょうか。 さらに並川は、
「計算量を減らす」 ため、 上記のベイズ更新を一部近似計算に置き換え、 解析的に実装することで効率化する、 といった工夫も加えています。 これは、
日本、 海外の複数リージョンに対して、 全ユーザのリクエストに対し、 都度、 どのコンテンツを返却するとよさそうかをリアルタイムで計算処理する必要があるからです。どれほどのトラフィック量かというと、 大体1日に5億件程度のリクエスト量になります （図6）。 並川は、
技術フェローという肩書の通り、 弊社内でも稀有な人材ではあるのですが、 本人に話を聞くと、 当時参考にできる論文がなかったので、 複数のモデルを実装してさまざまなパラメータでの収束性能を検証するシミュレーションを行ったり、 計算を高速にするため数式レベルでの修正を行ったりしながら、 実装したそうです。 - ――LINEの開発環境は、
エンジニアの裁量が大きく自由度も高く開発できる環境ということでしょうか？ はい、
企画段階から機械学習エンジニアが関わってプロジェクトを立ち上げていく、 ということは可能ですし、 今後も増えていくとは思います。Smart Channelの推薦システムに関しては、 サービス開発序盤から、 並川はじめML1チームのエンジニアが、 別組織のサーバーサイドのエンジニアと連携し、 開発を進めていました。 その後、
事業側で企画をリードするプロダクトマネージャが合流し、 企画と開発、 更に分析を行うデータサイエンティストが一緒になって開発が進められたので、 エンジニアの裁量が大きく発揮された開発事例といえます （※）。
以上、
続く後編