自己紹介＆アジェンダ
Lu Yan氏：LINE FukuokaのData Science Team、データサイエンティストのLu Yanといいます。今日は「サービス運用のための時系列データ予測」についてお話しします。特に我々同様、データ予測ツールを作る方のお役に立てればと思います。
まずは、プロジェクトの背景とプロジェクトのメンバーを紹介します。次に、時系列予測ツールについて紹介し、最後に、達成事項および将来の目標についてお話ししていきます。
最初に、プロジェクトの背景とプロジェクトのメンバーです。プロジェクトは3人で構成されています。私以外のYifanさんとTerryさんは機械学習エンジニアで、予測システムも担当してくれています。
典型的なユースケース
まずは、なぜこのプロジェクトがスタートしたかについてです。典型的なユースケースを紹介します。
まず、ユーザーが新しいiPhoneを買います。すると古いデバイスから新しいデバイスにLINEのアカウントを移行することになります。でも問題が発生しました。その時どうするでしょう。
LINEのWebサイトにある問い合わせフォームで、我々にコンタクトを取ります。問い合わせフォームは、スライド右にあるようなかたちです。
では、この問い合わせフォームの背景には何があるのでしょうか？ 実は、LINE Fukuokaカスタマーケアチームがこの問い合わせを担当しています。しかし彼らも、問題に直面します。各LINEサービスに対して毎月、毎日、毎時、何件の問い合わせに対応すればよいのでしょうか？
なぜそれが重要なのかというと、作業量とリソースの計画を立てる必要があるからです。来月何人で対応する必要があるのか。iPhoneがリリースされたら人員増が必要になるのだろうか。作業を増やす必要があるのだろうか。
この答えを出すために、我々LINE FukuokaのData Science Teamと、バリューマネジメントセンターは、「Inquiry Count Forecasting」というプロジェクトを立ち上げました。
先ほどの例はLINEアプリのみでしたが、そのほかのサービスもサポートしています。LINE STOREやLINE Creators Marketなどです。問い合わせ対応は、サービスごとにチームが分かれています。つまり、予測もチームごとに行います。
何が問題なのか
すでに何が問題かおわかりかと思います。毎月部署ごとに10を超える予測が必要となるのです。プロジェクトのコミュニケーションコストも高くなります。なぜ高いのかと思うかもしれません。先ほどのユースケースを例に挙げましょう。
iPhoneの新リリースは、機能に大きなインパクトを与えます。リリース直後に多くの人がスマホを乗り換えます。つまり、問題が増えます。新規登録やアカウント移行が起こり、問い合わせのアカウント数も増えます。新学期も同じ傾向です。データを予測する上で、この手の情報はとても必要です。
そうした影響を把握する必要はあるものの、部署が変わればその影響も変わります。だからこそ、チーム間でのコミュニケーションが必要となります。しかし、我々のデータサイエンティストの数は限られています。つまり、ギャップがあるのです。そのギャップの解決が、今回の動機づけともなっています。
データサイエンティスト以外のユーザー向けにツールを作る
幸運なことに、我々のデータは、同様のWebフォームからすべてできています。そのため、データ構造も非常に似ています。しかし、データの前処理やモデルトレーニングに、反復作業が多くあります。
そこで、新しい考えが生まれました。データサイエンティストだけではなく、LINEの業務や運用サービス部門のデータサイエンティスト以外のユーザー向けにもツールを作成して、データサイエンティスト以外の人たちにも、自分たちで予測をしてもらいたかったのです。
それが可能になれば、先ほどのギャップが解決されます。また、データサイエンティストは、反復作業が自動化されることで、作業の効率化が図れます。我々の任務は、コードの作成レベルや統計知識に関係なく、システムの援助で比較的正確な予測をしてもらうことでした。
こちらは、私たちのデザインです。データサイエンティスト以外のユーザーにはUIを提供しました。必要な情報を入力し、ステップを追っていくことで予測ができるようにしました。データサイエンティストに対しては、数行のコードでシステムを使い、すべてが可能になると期待しました。
ツールの詳細
では、ツールの詳細に入っていきましょう。ツールは4つの要素からなっています。データ予測パイプラインの一般的なステップと同じです。
まずは、プロジェクトを追加します。そして、そのプロジェクトにデータセットを追加します。CSVファイルでも直接接続したデータベースでもOKです。
データセットがアップロードされたら、そのデータセットでモデルのトレーニングをします。モデルトレーニング終了後、予測をします。こちらは、データ予測の一般的なパイプラインです。
では、詳細をステップごとに見ていきましょう。こちらはプロジェクトのWebフォームです。プロジェクトの追加時点でユーザーに必要な情報の入力を依頼します。ほかのITプロジェクトと違う点が1点あり、ユーザーに「Slack」のチャンネル名の入力を依頼しています。Slackのチャンネル名を入れることで、ユーザーは通知を受け取れます。このようにです。
なぜこれを作ったのか。モデルトレーニングには時間がかかるからです。ユーザーにトレーニングが終わったかどうか、わざわざ戻ってチェックしてもらいたくありません。そのため、この入力ボックスを作りました。
プロジェクトの準備が整ったら、データセットを追加します。
さまざまなデータソースをサポートしています。CSVファイルアップロードや、MySQL DBに接続してもかまいません。「Presto」や「Spark SQL」なども使えます。
社内ツールなので、社内DBへの直接接続を推奨しています。こちらでユーザーに異常検知と補完機能を提供しています。私は、これが重要だと考えています。データの前処理に、データサイエンティストは多くの時間を費やします。毎日の作業の70パーセントから80パーセントを占めるという人もいます。かといって、データサイエンティスト以外の人が、この作業をするのは難しいです。
ということで、ユーザーにこのボックスをチェックしてもらうことで、すべてが終わるようにしました。異常検知や不足データの検知機能により、データの品質も向上します。右側にはSQLインプットボックスがあります。このインプットボックスでDBに接続できます。
データをアップロードしたあとに、モデルのトレーニングができます。「Prophet」「LSTM」「ARIMA」などさまざまなモデルタイプをサポートしています。「Temporal Fusion Transformers」のような新しいモデルもサポートしています。
ここで、どの部分がデータサイエンティストにとって最も難しいのでしょうか。私にとっては、各モデルに対してのパラメータ入力です。
ということで、ハイパーパラメータチューニングを用意しました。こちらにチェックを入れれば、パラメータの入力は必要なくなります。各ソースパラメータの中でベストなパラメータを選択してくれるのが、ハイパーパラメータチューニングです。このファンクションを使うことで、データサイエンティスト以外もモデルを使って予測できるようになります。
また、モデルの説明、モデル評価のファンクションも用意しました。次のスライドで詳細を説明します。
モデルのトレーニング終了後、ユーザーは予測を始めます。予測に必要な情報を入力する必要がありますが、こちらが結果のページのスクリーンショットです。予測結果のファイルをダウンロードできますし、システム側で結果をプロットしてくれています。データサイエンティスト以外の方も、我々のUIを使って、ステップに沿ってデータを予測できます。
データサイエンティスト向けのツール
では、データサイエンティスト向けのツールはどのようなものでしょうか。データサイエンティスト向けには、Pythonクライアントを提供しました。データサイエンティストはバッチジョブも使えます。また、のちほど詳細を説明しますが、高度な機能も使えます。社内ツールなので、新しい要件が出た場合には、新しい機能を柔軟に追加していきます。
最初の例です。こちらは、バッチジョブのスクリーンショットです。バックエンドは「Airflow」です。データサイエンティストは、こちらのツールでモニタリングやジョブのスケジューリングを簡単に行えます。
ハイパーパラメータチューナーの例です。各モデルのパラメータを選択するのは、データサイエンティストにとって難しい作業です。そこで、この機能をPythonクライアントで提供しました。これによって、ハイパーパラメータチューニングを簡単に行えます。
こちらは、Prophetの使用例です。通常ですと、データサイエンティストのプロットは、左のスクリーンショットのようになります。また、モデル式の分解もユーザーに提供しています。これでモデル式を直接的に見ることができ、additive_termsと、multiplicative_termsによる影響をよりよく理解できます。
Temporal Fusion Transformersを使った時のスクリーンショットです。こちらのモデルでは、エンコーダとデコーダパラメータ変数の重要性がよくわかります。
右側では、Temporal Self-Attentionレイヤーから前のタイムスタンプの重要性がわかります。モデルの説明を、データサイエンティストが行う時には便利だと思います。
こちらが、私の大好きな機能です。標準SQLクエリの仕様をサポートしたことで、モデルを走らせ、予想を行うことが可能になりました。つまり、ユーザーがデータの抽出のためにSQLコードを書くと、ユーザーはモデルを走らせるSQLコードも書けます。これで予測に必要なステップを減らせます。データサイエンティストにとって効率的なものだと思います。
こちらのスクリーンショットは、最近実装した新しい機能です。あるユーザーが、前の予測結果のプロットをしてほしいと依頼してきました。
ツールの紹介をしてきましたが、そのツールのシステムアーキテクチャはどうなっているでしょうか？実は単純です。主なフレームワークを紹介したいと思います。Web APIの仕様には「Django」を使っています。Djangoはとてもパワフルで、このフレームワークの大きなメリットとなっています。
タスクの分配には、「Celery」を使っています。モデルトレーニングやハイパーパラメータチューニングは、演算コストや時間がかかります。ユーザーが、小さく軽量なタスクでデータをアップロードしている時は、特にレスポンスを遅くしたくはありません。
ログシステムもあります。「Elasticsearch」を用いています。ご覧のように、システム全体はシンプルで維持管理しやすくなっています。
まとめ
最後に、最近の達成事項および将来の目標についてお話をします。プレゼンの最初にInquiry Count Forecastingのプロジェクトで、課題の解決をしようとしたというお話をしました。
最初の課題は、予測タスクの量とデータサイエンティストの数に開きがある、ということでした。2番目の課題は、データの前処理とモデルトレーニングにかかわる反復作業でした。それは解決されたのでしょうか？
私は、解決されたと思っています。1つ目に関して、我々が開発したUIおよび機能によって、データサイエンティスト以外のユーザーも自分たちで予測ができるようになりました。彼らがモデルに関して提言を我々にするようになり、自力で予測をしています。各チームと連絡を取り、チームごとの予測をするというのも、我々には必要がなくなりました。
データサイエンティストも、API開発によるメリットを受けています。我々の作業効率も上がり、「Kubernetes」クラスタやデータの可視化をどう作成するかなど、考える必要がなくなりました。
Inquiry Count Forecastingについては、バリューマネジメントセンターからフィードバックを受けました。
ツールの使用後、作業時間が83パーセント削減され、予測の精度が高くなり安定しました。システム実装以前は、「Excel」を用いてデータ予測を行っていて、典型的な手作業だったので、人事異動があると、運用が前ほどうまくいかなくなっていました。季節変動や大きなイベントにおいての精度も、今ほどよくはありませんでした。
こちらのお話は、LINE Fukuokaのブログにも書いてあります。興味のある方はご覧ください。
将来の目標
将来の目標についてです。より多くの事業部署にこのツールが開放されればと思っています。現在、UIの改善作業を進めています。データサイエンスのプロジェクトをするための機械学習エンジニア2人とデータサイエンティストが1人のため、シンプルなWebフォームしか対応できていませんが、これからはLINE Fukuokaのほかのエンジニアとも協力をしていきたいと思います。このツールを、よりユーザーフレンドリーにしていきたいと思います。
より多くのタイプのデータ可視化も望んでおり、ライブラリを構築中です。事実、データの可視化は、ユーザーの方からの大きな要望の1つです。
モデル作成のページにおいて共通の特徴量がほしいという要望も出ています。「休日」についてはすでに実装しましたが、「天気」についても対応したいと思っています。「multi-horizon forecast」も将来的にサポートしたいと思っています。
以上となります。ご清聴ありがとうございました。
