データ分析で失敗したこと ③分析実行

「失敗したことシリーズ」の分析実行パートです。各工程での失敗談を通して、読者の皆様に「視点」のイメージを持っていただくことを狙いとしています。

よりメタな(抽象的な)説明については、「データ分析における視点」シリーズをご覧ください。
→ データ分析における「視点」 a. 企画編(準備中)
→ データ分析における「視点」 b. 実行編(準備中)

内容

  • 分析実行の概要
  • Case1: レコード粒度が不適切で精度評価をミスった
  • Case2: 学習・テスト・検証データが不適切でリーケージが発生した

分析実行の概要

分析実行といいながら、弊社ではモデル構築作業はAutoMLにお任せしているので、機械学習プロジェクトの文脈ですと、人間が行う作業としては以下2つがメインとなります。

  • データマートの設計
  • 学習・テスト・検証データの設計(パーティション)

Case1: レコード粒度が不適切で精度評価をミスった

みんなが一度は通るであろう「離職予測」の案件で発生した失敗です。B2Cビジネスの離反予測、解約予測でも同じような失敗が発生し得ると思いますので、分かりやすい事例に置き換えて読んでいただいて構いません。

ここでの主張は、最終的に検証したい事象(例:1年間の離職)と、検証のために用いる予測モデルのデータマートとで、正解データの比率が異なる場合、予測精度にバイアスがかかってしまうので注意が必要、ということです。

以下、ちょっと長くなるので、次のような章立てでお話しします。

  • なびなびのプラン
  • 問題点
  • 解決策
  • 必要な視点

なびなびのプラン

なびなびの勤め先のとある事業では、離職者が多く出ていることが課題となっており、離職可能性が高い人を特定することにより、手を打とうと考えていました。

なびなびが考えた分析プランは以下の通りでした。

  • ある人が3ヶ月後に離職するかどうかを予測する
    (目的変数に3ヶ月後に離職するかどうかを取る)
  • 説明変数は、離職者・現役社員に関して以下のように取る
    • 離職者:従業員の基本属性、離職の3ヶ月〜6ヶ月前の行動に関する変数
    • 現役社員:従業員の基本属性、現在から3ヶ月〜6ヶ月前の行動に関する変数

上記を実現するためのデータマートの設計は以下のようなものになります。

データマート設計図(なびなび作成)

結果、どうなったかというと、めちゃくちゃ精度が良いモデルが出来上がりました。AUC、正解率、適合率、再現率など、主要な評価指標はいずれも0.8~0.9程度を達成しており、関係者からも「すごいじゃん!」とお褒めに預かりました。

さて、何が問題なのでしょうか。

多くの方が気づいたと思うのですが、退職者が退職日を起点としてるのに対して、現役社員は現在を起点にしていることに違和感を感じますよね?
なびなびもうっすら違和感を感じていましたが、見て見ぬふりをしていたのです。

問題が発覚したのは、モデル構築が終わり、効果検証方法を設計している時のことでした。

モデルの検証段階では、適合率1)を90%とした場合に、再現率2)も90%程度見込めると考えていました。
1) 離職すると予測して、実際に離職した割合
2) 離職者全体のうち、離職することが予測できた割合

しかし、翌年1年間に見込まれる離職者数3)と、モデルで当てられそうな離職者数4)の割合が明らかにおかしいのです。
3) 前年の離職率から翌年の離職率を概算
4) モデルを使って翌年の離職者数を予測

問題点

そこでようやく気がつきました。
データマート上の離職者/現役社員の比率と、1年間の離職者/現役社員の比率が明らかに異なるのです。

データマートには過去に退職した全社員が含まれているので当たり前と言えば当たり前なのですが。。。

ただ、「検証したい事象に対して、データマートの正解/不正解の比率が歪んでいる場合、データマートで算出した精度指標は、検証したい事象には当てはめられない」、ということを理解しておかねば大変なことになってしまうのです。

このことを説明したのが、以下の図です。データマートでは、離職した人の比率が80%あったのに対して、検証したい事象(例えば1年間の離職)では離職した人の比率が10%だった場合を想定しています。

データマートで算出した予測精度は、適合率、再現率、正解率ともに80%以上となっています。

しかし、検証したい事象では適合率12%、正解率32%と、データマートで計算した結果と大きく乖離してしまうのです(再現率を93%で維持すると仮定)。再現率を下げれば、適合率、正解率をあげることができますが、データマートで計算した精度指標を再現することはできません。

正解データ比率の歪みによって精度指標の課題評価が発生する過程(なびなび作成)

なお、同じような問題は、不均衡データをダウンサンプリングした際にも起きるようです。
→ ダウンサンプリングによる予測確率のバイアス

解決策

解決策は、以下2つあると考えています。今回のケースでは、1点目のアプローチをとります。不均衡データの場合には2点目のアプローチを使うようです。

  • 正解データ比率が歪まないようにデータマートの設計を見直す
  • データマートから算出された精度指標に正解データ比率によるバイアス補正をかける

施策を実施する周期(例えば月)×社員でユニークになるようにデータマートを設計しておけば、今回のような失敗は起こらなかったと思われます。

あるべきデータマート設計(なびなび作成)

必要な視点

  • レコードの粒度は適切か

Case2: 学習・テスト・検証データが不適切でリーケージが発生した

ビジネスで扱う分析課題の多くのケースは、時系列の問題であると考えています。時系列データを扱う際には、予測時点で知り得ない将来方向の情報を使わない(リーケージをしない)、という鉄則があります。

ここでの主張は、以下の通りです。

  • 列方向のリケージだけでなく、行方向のリーケージにも注意が必要
  • K-foldでは行方向のリーケージが発生してしまうのでWalk Forward Validationを使う

こちらも章立てしてお話しします。

  • 列方向のリーケージ
  • 行方向のリーケージ
  • なびなびの失敗事例
  • 必要な視点

列方向のリーケージ

列方向のリーケージとは、特徴量に将来データが含まれている状態を指します。

例えば、入会後の初回利用率を予測する際に、特徴量として顧客の利用実績に関する情報を使っているようなケースが当てはまります。このケースでいうと以下2点が問題です。

  1. 入会時点で知り得ない情報を使って予測している
    • 入会時点では、顧客がどんな利用をしてくれるのかなんて分かり得ないので、本来、予測には使えないのです。
  2. 予測精度が「高い」ように思えてしまう
    • 利用実績があるということは、初回利用したということなので、利用実績を用いることで、予測精度を高めることができます。
    • 1点目で指摘した通り、予測時点では使えない特徴量なので、顧客やユーザー部門の期待値を上げるだけ上げておいて、実用段階で残念なことになるリスクがあります笑

上記2点を踏まえ、実務上は、予測に効いている変数から重点的にリーケージを確認するようにしています。予測精度に効いていない変数であれば、リークしていたとしても、最悪は、実用段階でリークに気付き、モデルを修正すれば良いだけの話なので。

行方向のリーケージ

行方向のリーケージとは、モデルの学習に、本来学習時点では取得できていないはずのレコード(行)を使っている状態のことを指します。

例えば、入会後の初回利用率を予測する際に、2017年以前に入会した顧客のデータを学習データ、2018年以降に入会した顧客のデータをテストデータとしたとします。

2017年以前のデータを学習データに、作業上のミスで2019年以降に入会した顧客のデータが含まれていたとしましょう。これが行方向のリークです。

行方向のリークの問題点は、以下2点だと考えています。

  1. モデル作成段階では知り得ない将来のトレンドをモデルに取り込めてしまうこと
  2. 将来のトレンドを取り込むことで予測精度が「高い」ように見えてしまうこと

なびなびは、行方向のリーケージでやらかしてしまいましたので、以下、なびなびの失敗事例を使って説明します。

なびなびの失敗事例

商品の販売数量を予測する案件での出来事です。

対象ビジネスでは、複数カテゴリ(日用品、食品など)、複数品目(歯ブラシ、歯磨き粉、ばバナナ、アイスなど)の商材を扱っており、品目ごとの販売数量に興味がありました。

そこで、同カテゴリ、同品目の過去の販売実績や、商品のスペック情報(重さや、値段など)に関する特徴量から、将来の販売数量を予測するモデルを構築しました。

モデルを作った結果、まあまあの精度が出ていたのですが、同僚に次のような指摘を受けたのでした。。

「時系列データなのに、K-foldでバリデーションしちゃったの?」

K-foldを使うと、ランダムにテストデータをサンプリングしてきてしまいますので、行方向のリーケージが発生してしまいます。

今回のケースでは、行方向のリーケージが非常にマズイ理由がありました。
それは、新商品の販売が予測対象に含まれていたことでした。。

新商品の販売数量の予測は、販売実績が分かっている既存商品と比較して、難易度が高くなります。
K-foldを用いると、新商品についても、将来の販売情報が取り込まれてしまいますので、見かけ上、予測精度が高くなってしまうのです。

その後、Walk Forward Validationを使って検証し直したところ、K-foldを使った場合よりも、予測精度が落ちていることが発覚したのでした。。。特に、新商品に関しては予測精度が落ちていました。

Walk Forward Validationについてはこちらのブログが参考になりました。ドキッとした方はどうぞ笑
→ 時系列データの評価方法

必要な視点

  • 時系列データに対してK-foldしていないか

最後に

以上、分析実行段階でのチェック項目でした。前回ご紹介した、ビジネス課題特定、分析課題設計、は分析によるインパクトと実現性を担保するためのチェック項目でしたが、今回は、分析の品質を担保するためのチェック項目となります。基礎中の基礎らしいので、この段階では極力ミスを避けられるようにしたいですね。。。笑

次回は、分析結果の咀嚼段階での失敗事例とチェック項目をご紹介したいと思います!

以上!

コメントを残す