国内月間アクティブユーザ数8,400万人
メッセンジャーだけではなく,
サービス上で提供される情報やコンテンツのデータサイズ,
日々データが大量に蓄積・
LINE社内における機械学習を活用した企画やプロジェクト・
そのDSEセンター傘下にある,
後編では,
Machine Learning1チームの周辺組織との関わり
社内ツール「LIBRA」を活用したA/Bテストでのチーム間連携
- ――LINE DEVELOPER DAY 2019で,
DSチーム高口太朗氏のセッション 「コミュニケーションアプリ では,「LINE」 の機能改善を支えるデータサイエンス」 「LIBRA」 や 「Shiny」 といったツールを使用した, MLチームとDSチームの業務上のコミュニケーションの一端が解説されていました。
MLチームの方は,これらのツールを使用して, 周辺のメンバーの方々とどのようなコミュニケーションを取りながら業務に取り組んでいるのでしょうか? 「LIBRA」 は, A/ Bテストを行うための設定情報を管理・ 定義する, かなり簡素なシステムです。社内のサービスに推薦システムの導入が進んできて, 新たなエンジンへの改善ニーズが高まってきたこと, DSチームのデータサイエンティストが個別にA/ Bテストの設計を行っており, 共通化のメリットが高そうなことから, 2017年末くらいから, 検討・ 導入を進め, 最近では社内の標準的な環境になりつつあります。 たとえば,
より使いやすいUIを決めるにあたり, 実験計画と実際のA/ Bテストの実施・ 検証をDSチームだけで行う場合もありますし, 機械学習が関わるSmart Channelのようなプロジェクトにおいて, エンジンの変更や機能追加・ 設定変更などに関して, A/ Bテスト実施のサポートをお願いするようなこともあります。 A/
Bテストの設計というのは, たとえば1%のCTRが見込まれる表示領域の修正を行うにあたって, 「どれくらいの変化量を, どれくらいの確からしさで検出したいか」 を決めた上で, 「どれくらいのユーザに, どれくらいの期間, 試してもらうか」 を決めることに相当します。 また実験計画という観点では,
試したいパターンが複数存在するような場合に, 1度にまとめて行うべきか, 複数回に分けて実施すべきか, といった検討をすることもあります。LINE DEVELOPER DAY 2019のセッションで, 弊社の高口が解説しているように, 1回にまとめてA/ Bテストを実施しようとすると, 多重比較の問題による偽陽性の可能性や, 偽陽性を抑えるためにサンプルサイズが大きくなりすぎる問題が生じることもあります。 高口のセッションでの例は,
LINEのメッセンジャーにおけるグループ作成手順のわかりにくさを改善させるために, 「招待するユーザの友だちリストの並び順」 「手順の画面数」 を変更させる改善を組み合わせた, 4パターンのテストについて, 2回に分けて, 3パターンのテストにする, という内容でした。 たとえば2つの機能のテストをまとめて行おうとすると,
4群のA/ Bテストになります。A~Dの4パターンで考えると, 有意差に関する検定は, AとBの比較, AとCの比較…, という風に数えることになり, 合計で6つのペアを比較しなければなりません。 このような場合は単純に2群
(2パターン) でのA/ Bテストを2回行う方が, サンプルサイズも小さくて済む上に, 結果の解釈もシンプルになります。 UIの検証の例は,
ML1チームは関与していませんが, 前回紹介したSmart Channelについては, DSチームに協力してもらいながら, A/ Bテストを行っています。 当初は単なるテストの設定情報のみを提供していたLIBRAですが,
Smart Channelでは, システム的な連携をかなり盛り込んでもらいました。このため, 前編で紹介したバンディットアルゴリズムのA/ Bテストを行いながら, 同時に個別サービスのロジック, たとえばSmart Channel向けのスタンプのレコメンドのA/ Bテストも実施する, といったことが可能になっています。 また,
A/ Bテスト実施の際のログがリアルタイムで出力されることから, LIBRA上でも, リアルタイムのテスト結果が確認できるような機能追加を行いました。 A/
Bテスト実施時の分析の実務にあたっては, DSチームに協力を仰ぎながら, A/ Bテストの仕組み自体を導入したり, 社内の他システムとの連携をしたりなどを含め, 開発に関わる部分はML1チームがメインで担当しています。
エンジニアやデータサイエンティストの裁量に委ねられた開発ツール選定
弊社では,
さまざまなサービスのデータをきちんと取ったら, それをダッシュボードなどで常に確認できるようにする, という文化が根づいています。個人的におもしろいと思うのは, この際に使われるツールが1つだけではなくて, かなりの部分がデータサイエンティストの裁量に委ねられている点です。 たとえば,
Shinyは統計ソフトR上での分析結果をWebアプリとして公開するためのRのパッケージですが, 弊社のデータサイエンティストにはRをメインで利用しているメンバーも多く, こうしたメンバーはShinyを使っています。 その他,
Tableauを使ったり, 内製の 「OASIS」 というツールを使ったりもしています。OASISは PythonもRも使える上に, SQL (SparkSQLやPrestoなど) も利用できるので, ML1チームでも, 他組織に何かを共有する際に, OASISを使うことは多いです (チーム内部の検証ではJupyterを利用しています)。 他にも
「conflr」 というLINE発のオープンソースソフトウェア (OSS) で, R Markdownで書いた分析内容を直接Confluenceのwikiページへと出力できるツールもあります。DSチームの中にも, エンジニアリング指向の人が混ざっていたりする点は, おもしろいと思います (※)。