渋谷駅前で働くデータサイエンティストのブログ

元祖「六本木で働くデータサイエンティスト」です / 道玄坂→銀座→東京→六本木→渋谷駅前

何故データサイエンティストになりたかったら、きちんと体系立てて学ばなければならないのか

f:id:TJO:20210513211022p:plain

先日、Quora日本語版でこんなやり取りがありました。

基本的にはここで述べた通りの話なのですが、折角なのでブログの方でも記事としてちょっとまとめておこうと思います。題して「何故データサイエンティストになりたかったら、きちんと体系立てて学ばなければならないのか」というお話です。

問題意識としては毎回引き合いに出しているこちらの過去記事で論じられているような「ワナビーデータサイエンティスト」たちをどう導くべきかという議論が以前から各所であり、それらを念頭に置いています。なお毎度のことで恐縮ですが、僕も基本的には独学一本の素人ですので以下の記述に誤りや説明不足の点などあればご指摘くださると幸いです。

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


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

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

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


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


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


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


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


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


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


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


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


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


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


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


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

  1. 「分類モデルを構築して学習データに再予測をかけたらaccuracyが82%と優秀だったので採用したいと思います」
    • 単純に交差検証自体を怠った
  2. 「過去データへの当てはめがR^2 = 0.99と素晴らしい需要予測モデルを社長臨席の役員会での意思決定のために使っていたのですが、ある時期からモデルに基づいて施策を決めても売り上げが上がらなくなっていて困っています」
    • 原因調査が入った結果「毎年新たにモデルの精度を上げるのに役立ちそうな変数を少しずつ足していった」上に「交差検証を一切していない」ことが判明。モデルの回帰係数だけ見て施策を決めていたので、途中から過学習が酷くなって以降はその施策も当たらなくなってしまった
  3. 「新薬の副作用の有無を予測するモデルを構築して、対応する遺伝子の『名前』をモデル変数に含めたらaccuracyが100%に達しました」
  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にしましょう」

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


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


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



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


余談


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


追記

その1


こういう質問のブコメをいただきました。

何故データサイエンティストになりたかったら、きちんと体系立てて学ばなければならないのか - 渋谷駅前で働くデータサイエンティストのブログ

参考に。当ブログに『社会人が統計学機械学習を学ぶなら「落下傘方式」で』(14年)という記事があり、そちらのアプローチとの関連も言及があるとさらにありがたかった。

2021/05/15 07:58

言及されているのはこちらの過去記事ですね。

一見すると今回の記事と言っていることが矛盾するように見えるかもしれませんが、実は7年前の記事でもこう書いていたりします。

「落下傘方式」がいかに強力だとはいえ、勉強が進めばそれなりに覚えたことも多くなってきて次第にこんがらがってくると思います。そういう時に、自分の「理解」の「体系化」を、実際の学術体系と照らし合わせながら進めていくことも大切です。つまり、「覚えた知識同士の関連性を学ぶ」ということですね。

基本的には「背後にある巨大な学術体系」を意識しながら「落下傘方式で必要なところだけを学び」「少しずつ空白を埋めていく」ということを意図した話だったのです。なので、今回の記事の内容が「全体の方針」で、落下傘方式の記事の内容が「各論としての実践方法」だと受け取ってもらえると有難いです。

その2


何故データサイエンティストになりたかったら、きちんと体系立てて学ばなければならないのか - 渋谷駅前で働くデータサイエンティストのブログ

重回帰分析からはじまり、いろんな論文参考にモデルを作ったけど、結局クライアントが理解しないと未来予測に意味がなくて、結局重回帰分析しかしなくなった。

2021/05/15 06:45

これも業界あるある談義の代表みたいな話で、似たような議論を去年書いたことがあります。

「出来る限り枯れた技術」で「多少専門が違う人たちでも労せず管理できる」ということを優先した上で、「とにかく扱うデータとモデルはコンパクトかつシンプルに」「非専門家でも直感的に分かりやすく」「完全な自動化ではなく人手との協働を」目指すというのが、僕の処方箋でした。今でもこの考え方は通用すると思っています。

その3

NewsPicksで取り上げられているなぁと思っていたら、旧知のシバタアキラさんのコメントがありました。光栄かつ有難い限りです。

体系どうのこうのではなく、学び続ける姿勢が重要だと思います。体型立ててというと大学などの専門教育機関で学ぶとイメージがありますが、ここでTJO氏(日本を代表するデータサイエンティスト)が指摘しているようなポイントはむしろ「学校では教えてくれないこと」も多いです。ここでは検証を正しく実行・解釈する方法が特に指摘されていますが、今後はさらにどのような課題の解決にどのようなアプローチが有効なのか、などももちろん重要な知見でしょう。例えば時系列の機械学習モデルで、入力特徴量を派生させて作った場合には、入力特徴量の変化をシミュレーションするようなモデルの使い方はうまくいかない、とか。こういうことはまだ教科書に書いてないことも非常に多いですので、現場から学ぶ、同僚から学ぶ、TJOさんから学ぶ、など、学び続ける姿勢こそがプロフェッショナルを作っていくと思います。

僕は断じて日本を代表できるようなデータサイエンティストではございませんが(汗)、「体系どうのこうのではなく、学び続ける姿勢が重要だと思います」という一文に僕がこの記事に盛り込み切れなかった全てが詰まっていると感じました。

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

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

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

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

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

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