一般的なソフトウェア開発と、統計分析や機械学習との違い

これについてはQuoraでのやり取りの中でも書いた通りで、極めて大雑把に言えばこんな感じでしょう。

• 一般的なソフトウェア開発では、原則としてプロダクトはコードを書いた通りに確定的に動く
• 統計分析や機械学習モデルのアウトプットは、原則としてどのようなコードを書きどのように実装しようとも、与えられたデータやモデルの構造や特性はたまたハイパーパラメータに応じて確率的に変動する

勿論それぞれに程度問題ながら例外はあると思いますが、一般にソフトウェアは原則としてコードを書いた通りに動くものである一方で*1、統計分析のアウトプットや機械学習モデルのアウトプットは必ずしもコードを書いた通りにはならない、ということが言えると思います。それは後者が与えられたデータやモデルの性質はたまたハイパーパラメータの設定といったコード以外の部分次第だからです。しかも、ソフトウェア開発と違って「エラーが出なかったからと言って正しい結果を返しているとは限らない」のです*2。

故に、例えば往々にして「統計分析や機械学習で狙い通りの結果を得たければ、綺麗で理想的なデータを集めよ」ということが言われるわけですが、現実はそんなに簡単ではありません。むしろ、汚く理想からは程遠いデータにまみれることの方が大半であり、そんな綺麗とは言い難いデータが相手であってもそれなりの結果が得られるように工夫しなければいけないのが実務データ分析の現場の常です。

そして、特に予測のために統計的学習モデル（つまり統計モデルでも機械学習モデルでも）を構築する際には、汎化性能を確保することを考えなければなりません。即ち、過去の学習データのみならず未来の未知のデータに対しても良く当てはまるモデルでなければ、予測の役には立たないのです。これはデータの良し悪しのみならず、モデルの構造や性質さらにはハイパーパラメータを初めとする学習ステップにおける設定までもが影響してきます。

以上の点を鑑みるに、一般的なソフトウェア開発に比べると統計分析＆機械学習モデルの開発においては「確定的でなく手順化や標準フレームワーク化の難しいパートが少なくない」ということが言えると個人的には考えています。そして、それらにどのように対応していくかというのは漫然とOJTで学んでいるだけではダメで、ある程度体系立てて身につけていく必要があるというのが僕個人の意見です。

統計分析や機械学習を仕事にするなら、その「振る舞い」を体系立てて学ぶ必要がある

以前MLデザイン*3という概念をブログにまとめたことがありますが*4、機械学習一つ取ってもこの程度の「コーディングでも実装でもモデルのアルゴリズムでもないが重要なポイント」というのがあったりします。

それでもAutoMLなどの出来合いのツールを使うだけなら十分だと思いますが、データサイエンティスト（もしくは機械学習エンジニア）というプロの専門家としてある程度しっかりやっていきたいのであれば、相応に統計学や機械学習の理論やアルゴリズムについてきちんと体系立てて学ぶべきだと個人的には思うのです。その理由は既に述べた通りで、コードを書いて実装するという領域の外側にうまくいかない理由があることが統計分析や機械学習では多いからです。言い換えると「コーディングや実装だけではコントロールできない統計分析や機械学習の『振る舞い』を理解する」べきだ、ということですね。

それらは互いに複雑に絡み合う要素が多いので、どれか一つをただ「手順」として覚えてもうまくいかないことがよくあります。例えば機械学習を用いた予測モデルの汎化性能を確認するためには交差検証が重要なわけですが、holdout (dev/val)データセットを用意する際に「ランダムサンプリングして取ってくる」としか覚えていないと、自己相関の強い時系列データに対してはうまくいきませんし（前後のサンプルからのバイアスがかかってしまう）、テーブルデータであっても層化が必要なケースではやはりうまくいきません（そもそも交差検証されない分類クラスが出てきたりする）。それは「バイアスを避けながら」やらなければいけないという本質的なポイントを押さえていなければならないのです。

統計分析でも似たようなことが言えて、例えばwebサービスなどで記録されたクリック数を様々な特徴量と合わせてそのままポアソン回帰するとおかしな結果になることがあり、その場合はインプレッション数（表示回数）をオフセット項に入れる必要があったりします。これは「カウントデータを回帰するならポアソン回帰」としか覚えていないと辿り着かない解です。「クリックはインプレッションの中から発生する」という原理を踏まえていれば、「分母」をポアソン回帰モデル内で表現する方法が欲しくなるのが自然だと思うのですが、どうでしょうか。

この辺のトピックは、それこそ「東大出版会基礎統計学シリーズ（三部作）」「みどりぼん」「はじパタ」「カステラ本」「PRML」といった古典的なテキストでも触れられることの多い話であり、ある程度きちんと体系立てて習得していればそれなりに気づくことができるはずです。最低でも、一旦分析を回した後で「この結果はちょっとおかしいな」と思った段階で、不具合があることに気づくと思うんですよね。

これらはあくまでも一例ですが、「きちんと体系立てて学ぶことで回避できるがそれをしないと嵌まってしまう落とし穴が多い」のがデータサイエンス実務の世界です。なればこそ、データサイエンティスト（もしくは機械学習エンジニア）は体系立てて学ぶべきだと考える次第です。これを「PythonとSQLを3ヶ月ガチれば*5誰でもデータサイエンティストになれる！」などというその辺の怪しげな業者やメディアの売り文句に煽られて、上っ面だけ覚えた程度でデータサイエンス実務に参入するのは危ういことこの上ないです。

きちんと体系立てて学ばなかった結果として陥りがちな罠

と、いうような脅し文句ばっかりだらだら書いていても仕方ないと思うので、以下に「担当者がきちんと体系立てて統計学や機械学習を学ばなかったことが原因と思われるトラブル」の例を挙げておきます。ちなみにこれらは実例そのものではありませんが、実際に見聞したことのある実例を差し支えない範囲で改変しているというだけで限りなく実例に近いと思ってください。

1. 「分類モデルを構築して学習データに再予測をかけたらaccuracyが82%と優秀だったので採用したいと思います」
   • 単純に交差検証自体を怠った
2. 「過去データへの当てはめがR^2 = 0.99と素晴らしい需要予測モデルを社長臨席の役員会での意思決定のために使っていたのですが、ある時期からモデルに基づいて施策を決めても売り上げが上がらなくなっていて困っています」
   • 原因調査が入った結果「毎年新たにモデルの精度を上げるのに役立ちそうな変数を少しずつ足していった」上に「交差検証を一切していない」ことが判明。モデルの回帰係数だけ見て施策を決めていたので、途中から過学習が酷くなって以降はその施策も当たらなくなってしまった
3. 「新薬の副作用の有無を予測するモデルを構築して、対応する遺伝子の『名前』をモデル変数に含めたらaccuracyが100%に達しました」
   • 典型的なleakage事例。以前にもこのブログで論じたことがあります
4. 「気候変動の時系列データを予測するモデルを構築して、random splitして交差検証したら素晴らしく高い精度が得られました」
   • 典型的な時系列データに対する交差検証方法の誤り。適切に「時系列で後ろの方からvalidation setを取ってきた」ら精度がガクンと下がったらしい
5. 「予測モデルの変数を重要なものだけに絞りたいと思ってPCAで上位のものだけを残したら、却って予測精度が下がってしまいました」
   • 変数選択をするならむしろL1正則化(Lasso)を使った方が無難なケースが多い（PCAがダメだというわけではないが一緒に試してみる価値はある）
6. 「施策の効果をA/Bテストしてみたのだけど、サンプルサイズが小さかったせいかp< 0.05にならなかったので、サンプルサイズをもう2倍に増やしたいです」
   • サンプルサイズを事前に決めておかず、後からサンプルを増やすと有意になったとしても効果量が小さく無意味な結果になる可能性が高い
7. 「同一の施策を複数のユーザーカテゴリごとでA/Bテストしてカイ二乗検定をしたらp< 0.05とp< 0.1という結果が半々ぐらいになってしまいました、半分は有意ではなかったというのは格好悪いので閾値をp< 0.1にしましょう」
   • これはメタアナリシスを活用すべき。カイ二乗検定が複数ある場合はCochran-Mantel-Haenszel検定で統合すれば単一のp値で評価できる

1番目は単純に交差検証自体を怠ったという事例でこれぐらいならまだ可愛いものですが、2番目なんかは笑えません。これらはあくまでも氷山の一角で、ここに挙がっていない中でも「ちょっとでもきちんと体系立てて学んでいればそんなことにはならなかったのに」という話は冗談じゃなくて枚挙に遑がないというのが実態です。

それでもまだ「PoCやプロトタイプ段階の話だったので事前に気づいて良かった」というのはまだマシで、実際に外部に向けてプロダクトや成果物として公開してしまったり、はたまた役員会として決定を下してしまった後になってから誤りに気づいて、もはや今更手の打ちようがない……なんてことになってからでは、本当に目も当てられません。

ということで、既にデータサイエンティストとして働き始めている人であっても、これからデータサイエンティストを目指す人であっても、とにかく「きちんと体系立てて統計学や機械学習を学ぶ」ということを大事にして欲しいと思います。それは、いざ何か問題が起きた時に自分自身は勿論のこと、同僚・上司・お客さん・ユーザーといった全ての関わりある人たちを守る*6ことにもなるのですから。

なお手前味噌ですが、このブログでも「きちんと体系立てて学ぶ」ための指針として僕個人が考える推薦書籍リストとスキル要件定義を記事にして公開しています。勿論これ以外にも優れた教材や資料は沢山あるので、是非きちんと体系立てて学んでくだされば幸いです。

余談

冒頭の写真は、僕が閉鎖中のオフィスから一時的に引き上げてきた専門書の一覧です。現在では必ずしも参照する必要のないものが多いのですが、やっぱり忘れたり思い出せなかったりで改めて調べたいことがあった場合に備えて、常に手元に置いておきたい書籍たちです。まぁ、手元に置いてあるだけでただの積ん読になっているものもありますが……ということで、僕もこの記事を書いたのを機に自戒してちゃんと勉強し直そうと思います。

追記

*1:必ずしも確定的な挙動をするものばかりではないことは承知しています：例えば大規模システムにした場合のパフォーマンスの変動には数多くの要因があり得ます

*2:テストがエラーなく走ったにもかかわらず正しく動作しない、というのはTensorFlowなんかでは良くある話

*3:実は"ML design"という名称の企業さんが日本国内にあると気付いたので、最近はカナで「デザイン」と書くようにしています

*4:ちなみに最近アップデートした公開記事を書きました

*5:この「ガチる」という表現自体僕から見ると謎なのですが

*6:利益や資産を守るだけでなく、もしかしたら生命や安全を守ることになるかもしれない

手を動かしながら学ぶ ビジネスに活かすデータマイニング

• 作者:尾崎 隆
• 技術評論社