Prophetを、リクルートグループWebサイトの数カ月先の日次サーバコール数予測で活用してみた話：非統計家が高精度な時系列予測を行えるProphet（後編）（1/2 ページ）

Facebookが開発した時系列予測のOSSライブラリ「Prophet」が近年注目を集めている。本連載ではProphetの概要と理論的背景、案件で使ってみた経験から得られた知見を紹介する。後編はチューニングのテクニックや運用時の注意点などについて。

[羽鳥冬星，リクルートテクノロジーズ]

　Facebook製の時系列予測オープンソースソフトウェア（OSS）であるProphetを紹介する本連載。前回は、主に時系列予測そのものの歴史とProphetの概要を紹介しました。

　今回は、Prophetを使用するに当たって非常に重要であるチューニングのテクニックや、予測エンジンとしてProphetを搭載したプロダクトを運用する際に気を付けるべき点について、具体的な案件とともに紹介します。

活用事例の概要

　今回は、あるWebサイトの数カ月先の日次サーバコール数を予測する案件を例として挙げます。

　リクルートグループには多種多様なサービス、サイトがあり、それが多種多様な環境で動いています。サイトへのアクセスやAPIのコールなどを総称して「サーバコール」（以下「sc」と略記）といいますが、scのボリュームを可能な限り正確に見積もることは非常に重要なタスクです。集客観点で今後のビジネス計画を立てる上でも、リクエストを受けるサーバやサイト上の行動を記録するデータベースの設計、運用計画においてもscの見積もりは不可欠となります。

　また、この観点はサービスの規模が大きくなればなるほど影響範囲が大きくなってくるので、大規模サイトのscを予測することは非常に重要なテーマです。

Prophet活用を、どのように進めたか

　上記のような課題の下、あるサイトを対象として下記のように案件を進めました。

1. データ確認、EDA（Exploratory Data Analysis：探索的データ解析）
2. Prophetで予測モデル実装、チューニング、オフライン精度検証
3. モニタリング要件定義
4. モニタリングシステムとして実装

　今回はProphetに関係のある1.と2.について説明します。

1.データ確認

　ここでは、ざっくりとしたデータの全体感を確認するとともに、季節性の波やイベント効果による突出が起こっているかを確認しました。

データ全体のイメージ図

　ここから下記のことなどが分かります。

1. 年末年始や春先にスパイクが起こる
2. 年間通して季節性の波がありそうだ
3. 全体のトレンドが上昇傾向である

　もう少しデータを細かく見ていくと、正月やクリスマス、販促イベントやサイトリニューアルの時には時系列が特殊な動きをしていそうであることが分かります。

2.Prophetで予測モデルを実装、チューニング、オフライン精度検証

　EDAで分かったポイントを基にProphetでモデルを実装していきます。

　季節性のチューニングポイントとして、デフォルトでは投入されていない月単位の季節性を追加しました。Prophetでは、どんな長さの周期性も追加できますが、月の中の季節性は30.5日周期の波として以下のように投入します。

　ここで、「フーリエ級数の階数を、どのように置くか」は悩ましいところだと思いますが、週単位の波は「3」、年単位の波は「10」とそれぞれ設定されていることから、間を取って「5」と設定しました。もちろん、この数字を大きくすれば表現能力は高まりますが、過学習のリスクもあるので、慎重に設定する必要があります。

　トレンドのチューニングポイントとして、「changepoint_prior_scale」「n_changepoints」があります。詳細については後述します。

　最後にイベントのチューニングポイントとして、ゴールデンウイーク、お盆、正月、クリスマス、サイトリニューアル日などの特殊なイベントを追加しました。これらのイベントは全体の時系列への効果が大きく、投入することで精度が大きく改善しました。

　過去の一定期間で学習し、その時点から1年半を予測するバックテストを行うオフライン精度検証の結果、平均予測誤差率で目標を達成し、ビジネス要件的にも満足のいくモデルが完成しました。

　上記のような形で初期開発から運用設計までは比較的うまくいきました。このように、本案件やProphetを用いた別の案件を運用してみて得られた知見は多々あるので、幾つか紹介します。

ハイパーパラメーターのチューニング方法

　Prophetに限らず機械学習のモデリングでは、精度に大きく影響することがあるため、ハイパーパラメーターのチューニングが重要です。特にProphetは、季節性の事前分布の分散、トレンドの事前分布の分散、イベント効果の事前分布の分散、「季節性を時間に依存させるか」「変化点検出にデータの何％を用いるか」「変化点の候補を何点作るか」……などチューニングできるパラメーターが多くあります。

　また、ハイパーパラメーターの一つ一つがとても大きい影響力を持っており、少し値を操作しただけで予測値が大きく変わり得ます。このような事情からProphetを使ったモデリングでは特に、慎重にチューニングを行う必要があります。

　本案件でも当初は「3年前から1カ月前までのデータで学習、1カ月前から直近までのデータで評価」という方針でハイパーパラメーターをチューニングしようとしていました。しかし実行してみると、「ハイパーパラメーターの探索空間が大きい場合には評価データのロスがかなり小さい組み合わせで見つかるものの、そのモデルを使ってみると、その期間以外の予測はうまくいかない」という現象が起こってしまいました。

　そこで今回は、下図の「Time series cross-validation」で示されるように、直近のある期間を「評価用」、それ以外の期間を「学習用」として分割し、複数期間にわたって学習と評価を繰り返す方法を採用しました。

Time Series Cross-Validation

　このようにしてデータを分割すれば、複数の期間にわたって最も精度が良いモデルを選択しやすくなり、ある一定の期間にだけ強いようなモデルを選択するリスクが少なくなります。数値実験を行ったところ、直感に反するハイパーパラメーターの組み合わせはあまり選ばれなくなり、安定的に高精度な予測ができるようになりました。

　もちろん、この辺りの内容はデータに依存するので、このように「複数期間の評価用データを取る方法が常に正しいわけではない」ことは注記しておきます。

イベント効果

　Prophetにイベント効果を入れるときは、イベント日付の入ったDataFrameを「holidays」引数に渡します。

　この際、予測期間については将来のイベント日付を直接指定する必要があります。クリスマスやお盆など将来にわたって変更がないものであれば問題はありませんが、広告出稿や販促キャンペーンのように年度ごとに変わり得るものの場合、その日付に合わせてholidays引数に渡すDataFrameの中身を書き換える必要があります。

　システムにProphetを導入してしまった後にこの作業を行うことは非常に大変になると予測されるので、イベント日付は設定ファイルとして外部から与えられるような仕組みにしておくといいでしょう。