データ分析で失敗したこと ④分析結果の咀嚼

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

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

内容

  • 分析結果の咀嚼の概要
  • Case1: モデルの妥当性検証の前にモデルの特徴解釈をした
  • Case2: レコードレベルでの確認を怠った

分析結果の咀嚼の概要

このフェーズでは、分析結果の良し悪しや意味合いを分析目的に照らして解釈します。

ここでは、機械学習モデルを用いた分析を前提に、以下のような工程を想定しています。

  • モデルの妥当性の確認
    (正しく予測できているの?)
  • モデルの特徴の確認
    (作ったモデルはどんな特徴を持っているの?)
  • モデルの予測精度が意思決定・経済指標にもたらす影響の評価
    (その予測はビジネス上どんな意味を持つの?)
  • モデルの改善余地の模索
    (どうすれば予測精度が高められるの?)

ここでは、「モデルの妥当性の確認」にフォーカスして失敗事例、確認ポイントを紹介できればと思います。というのも、なびなびは、初歩段階である、「モデルの妥当性の確認」で躓くことが多いからです。。

「モデルの特徴の確認」に関しては、分岐構造(ツリー系のアルゴリズムのみ)、特徴量の寄与度(Permutation ImportanceSHAP value等)、部分依存等を確認することで対処しています。

「モデルの予測精度が意思決定・経済指標にもたらす影響の評価」は、ビジネス課題特定や、分析課題設計がクリアできていると、そこまで躓く要素はない気がしています。こちらに関しては、「戦略的データサイエンス入門」に体系的に整理されているように思います。

「モデルの改善余地の模索」では、ドメイン知識やデータ観察による特徴量エンジニアリングで解決します。こちらに関しては、「Kaggleで勝つデータ分析の技術」に基本的な内容が整理されていると思います。

Case1: モデルの妥当性検証の前にモデルの特徴解釈をした

予測モデルを構築した際に、「モデルの特徴の確認」を焦ってしまうことがあります。しかし、特徴を確認して意味があるのは、モデルによって正しく予測ができていることが前提となっています。分岐構造や特徴量の寄与度、部分依存などの特徴は、非常に示唆深いのですが、モデルが正しくなければ、その示唆の信憑性も疑われてしまいます。

とある分析案件で、決定木を使って、継続率が高い顧客の特徴を分析した結果を報告していた時のこと。同僚のデータサイエンティストに指摘され、モデルの妥当性を確認したところ、非常に妥当性が低いモデルであることが発覚し、分析をやり直すことになったことがありました。以降、モデルを作ったら、まず真っ先にモデルの妥当性を確認するようになりました。

モデル妥当性の確認ポイントは、以下2点だと思っています。

  • 予測精度
  • バイアス

まずは予測精度に関して。AUCやMAPEなどの指標を確認し、最低限の精度が担保できていることを確認します。例えば、AUC=0.55の決定木の結果を見せられても、信用して良いのか怪しいですよね。

次にバイアスに関して。ここでは、予測と実測の分布のズレを確認するようにしています。私はリフトチャートを確認することが多いです。白黒の線引きが難しいところですが、直感的に予実比較できるので、業務部門にも説明しやすいと感じています。

Case2: レコードレベルでの確認を怠った

レコードレベルでデータを確認することは、非常に大事です。

例えば、継続率が高いと予測された顧客上位10件と、下位10件を抽出し、それぞれ違和感がないかを確認するのです。

レコードレベルで確認を行う狙いは以下の通りです。

  • 業務部門への説明しすい
  • 特徴量のアイディアが湧きやすい
  • 列方向のリークに気付きやすい

転職当初、私はレコード単位でデータを確認するという習慣すら知らずに取り敢えず、AutoMLで分析を回して、業務部門に報告していました。特徴量インパクト等のAutoMLの出力を使って、モデルの説明を試みるのですが、どうしても業務導入となると納得してもらえませんでした。

そこで同僚に相談したところ、「レコードレベルでデータを見せたらどうか」というアドバイスを受けたのでした。業務部門に、継続率が高いと予測された顧客上位10件と、下位10件のレコードを見せたところ、具体的な顧客のイメージが持てたため、納得してもらえたことがありました。さらには、こんな特徴量を追加したら良さそうだ、と新しいアイディアが出てきて、モデルの改善にもつながりました。

また、私自身の経験として、列方向のリークに気付けたこともありました。特徴量の値もセットで確認することになるので、特徴量の項目の羅列を見ている時よりも、注意の感度が高まるように感じています。

AutoMLでモデル構築や解釈が簡単になってくると、レコードレベルでの確認を怠りがちです。大事な分析では、丁寧にレコードを確認するようにしたいですね。

必要な視点

  • モデルの特徴を把握する前に、モデルの妥当性が確認できているか
  • レコード単位で違和感がないか確認できているか

最後に

「モデルの特徴の確認」は分析してる感があるので、ついそちらを優先してしまいがちなのですが、焦らず、「モデルの妥当性の確認」を行うようにしたいですね。

以上!

コメントを残す