検索
連載

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

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

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

トレンドのチューニング

 季節性、トレンド、イベントといったProphetの構成要素のうち、予測期間が長期に及ぶ場合において最も重要なのはトレンドです。

 トレンド項がうまく予測できていない場合、季節性やイベント効果をいくらうまく表現していても、全体の誤差は大きくなってしまいます。極端な例を挙げれば、単調減少なトレンドを持つ時系列に対して単調増加なトレンドを持つ予測を行えば、季節性やイベントがどれだけうまく予測できていたとしても、予測誤差はとても大きなものになります。

 ここで幾つかProphetのトレンド項の特徴を紹介します。

デフォルト設定では、直近の変化点を反映しない

 Prophetがトレンドの変化点を推定するのに使用するデータは、デフォルトだと全体の80%です。このため、下図のように直近に変化点があるデータはトレンドをうまく推定することはできません。


デフォルト設定での予測

 この問題は「changepoint_range=1」とすれば解決できます。


「changepoint_range=1」としたときの予測

 「changepoint_range」引数は、「データのうちの何割を用いて変化点検出を行うか」を決定する引数です。これを「1」と設定することで、全てのデータを使って変化点を検出するようになります。このようにすれば上図の通り、正しくトレンドを推定できるようになります。

 ただし、データ全体を使って変化点を検出することは直近のデータに過剰に引っ張られる予測になりがちでもあり、このハイパーパラメーターはデータを見ながら注意深く決定する必要があります。

 ちなみに、古いバージョンのProphetはchangepoint_range引数が存在しません。データ全体の80%が変化点検出に使われることが関数内部にハードコーディングされており、トレンドの変化点推定にデータ全体を使いたければ内部の関数を書き換える必要があります(https://github.com/facebook/prophet/blob/v0.2/python/fbprophet/forecaster.py#L315)。ただし、これは大変面倒です。今回挙げたポイント以外にも新しいバージョンが優れているポイントは幾つか存在しており、できる限り新しいものを使用した方がいいでしょう。

将来のトレンド予測においては直近のトレンド傾向をそのまま用いる

 Prophetは、学習期間においてはトレンドの変化を検出してくれますが、予測期間に関しては直近のトレンドをそのまま引っ張る形で予測します。このため、将来にトレンドの変化が起こったときには、それに対応できません。

 現実の予測問題においては、景気動向やサービスリリースなどによってトレンドが変わることは起こり得ますが、Prophetはこのような事態には対処できないことは認識しておいた方がいいと思います。

トレンド項のハイパーパラメーターチューニング

 トレンド項に大きな影響を与えるハイパーパラメーターとして、前述のchangepoint_prior_scaleとn_changepointsがあります。

 changepoint_prior_scaleはトレンド項の事前分布であるラプラス分布の分散を表しており、大きければ大きいほど変化点が検出されやすくなります。しかし、この項を大きくし過ぎると、かなり多くのポイントが変化点として検知されてしまいます。

 また前述した通り、Prophetは直近のトレンドをそのまま用いて予測を行うため、直近のトレンドを過剰に反映した予測は直感に反するものになりがちです。


「changepoint_range=1, changepoint_prior_scale=10」としたときの予測

 n_changepointsは検出する変化点の候補の数を表しており、大きければ大きいほど多くの変化点が検出されやすくなります。changepoint_prior_scale同様、これを大きくし過ぎると変化点が検出され過ぎてしまい、かなりおかしな予測になることが多々あります。

 特に、n_changepointsとchangepoint_prior_scaleを同時に大きくすることは下図の通り、極端に多くの点を変化点として検出してしまうため推奨できません。


「changepoint_range=1, n_changepoints=100, changepoint_prior_scale=10」としたときの予測

 もしこれらのハイパーパラメーターをチューニングするときは「changepoint_prior_scaleを大きくするなら、n_changepointsを小さく」「changepoint_prior_scaleを小さくするなら、n_changepointsを大きく」というように相補的に設定することをお勧めします。

最後に――個人的な野望

 本連載では2回にわたり、Prophetの概要から、使用する際に押さえておくべきポイントまでを紹介しました。Prophetに興味を持っている方にとって、理解を深めるきっかけとなれば幸いです。

 ここからは、今後の個人的な野望について述べておきます。

 Prophetの活用としては、一般化線形モデルへの拡張を考えています。例えば、カウントデータに対しては誤差分布にポアソン分布を仮定することが自然だと思いますが、現在のProphetでは対応できていません。実データを扱う際にはこのような場面にはよく出くわしますので、これに対応できるような形でProphetを拡張できればと思っています。

 分析者としては、これまで時系列テーブルデータを扱う案件が多かったので、全く異なる質のデータとして画像、音声などの非構造データを扱ってみたいと思っています。特に、画像のタスクにおける、多クラスかつ特定のクラスの枚数が少ないものようなものについては、世界中の統計家やデータ分析者が精度を競い合う「Kaggle」のコンペを通じてトレーニングを積んでいるところなので、実戦で試してみたい思っています。

 最後に、モデルの精度について話す際はKaggleで強い方が説得力があるので、2019年中にKaggleマスターになりたいと考えています。

筆者紹介

羽鳥 冬星(はとり とうせい)

大学院でクラスタリングを研究した後、2015年リクルートホールディングスに新卒入社。リクルートテクノロジーズ配属後、データイノベーション推進部で時系列予測やレコメンドシステムのエンジン部分のチューニングを担当。好きな教師なし学習のアルゴリズムは「fuzzy c-means」。2019年の目標はkaggle masterになること


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る