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

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

機械学習プロジェクトが失敗する9つの理由

f:id:TJO:20180802205223p:plain
(Image by Pixabay)

勉強が進まないので、今回は与太記事でも書いてお茶を濁すことにします(笑)。ネタはこちらです。

読んで字の如し、「あなたの機械学習プロジェクトが失敗する9つの理由」というグサグサ刺してくる論評記事です。あまりにもオリジナルの記事が素晴らしかったということか、KDnuggetsに誘われてrepostされた模様です*1


最近は機械学習の学術・技術的研究開発も極めに極まったところで一息つく感じになってきている印象で、どちらかというとインダストリーサイドではML Opsという考え方が提唱されるようになってきています。その内容については我らがid:rindai87さんのブログ記事が分かりやすいかなと。

ML Opsという名前で皆さんが期待している、課題に思っている内容は以下4つっぽい印象でした。

  1. そもそもシステムやサービスのどこにどのように機械学習を利用しているのかの話
  2. 機械学習のコードのテスト、モデルのデプロイ、モデルとデータの監視、自動化、などのいわゆるシステム運用の機械学習版っぽい話
  3. 機械学習のコード、あるいはシステム全体の高速化(GPUなどのハードウェア的な話や分散処理を含む)の話
  4. 機械学習システムの開発/運用体制の話

ということで、Dev Opsと呼ばれている話の機械学習版+活用パターンというのがニーズなのかな、とぼんやり考えています

こういうOps系の話が出てくると必然的に出てきがちなのがいわゆる「アンチパターン」リストなんですが、意外とその辺って周囲のMLerたちと話した限りでは暗黙知的な要素が濃いんですよね*2


とは言え、まともにきちんとしたアンチパターン集とかバッドノウハウ集とかそれこそ"Bad Machine Learning"みたいなものを編もうとしたら大変な手間になるので、今回はそこまで本格的なことはやらずに*3たまたまKDnuggetsで見つけた上記の記事の抄訳紹介をしてみようと思います。改めて、題して「機械学習プロジェクトが失敗する9つの理由」です。なお、そのまま抄訳だけ書いても素っ気ないので適宜僕自身のコメントも加えてあります。


1. 課題設定が間違っている (Asking the wrong question)


ここでは金融業界における不正検知というテーマを例に挙げています。悪い例として挙げられているのが「その取引は不正かどうか?」という課題を立ててそれを解くために「ヒトの不正取引監視役のラベリングを使う」こと。これだと過去に知られておらず、ヒトの監視役が見逃すような新たなタイプの不正は検知できません。なので本来立てるべき課題は「その取引は『異常値』かどうか?」というものであるべきだ、と言っています。つまり純粋に統計的な異常検知アルゴリズムを使った方が良いという話ですね。余談ですが、異常検知系は「肝心の異常データ自体が僅かにしか手に入らない」という性質上この手の「課題設定自体を工夫する」ネタが結構多くて、例えば「正常値データで学習させたAutoencoderで入力データを復元できたら正常値、復元できなかったら異常値」というやり方などは好例かと。


2. 間違った問題を解くために機械学習を使っている (Trying to use it to solve the wrong problem)


端的に言うと「その課題を機械学習を使って解いたとしてビジネス上の価値が出せるのか」という問い。ここでは「全身画像から洋服のサイズの採寸をするAIアプリを作る」*4という例を挙げています。機械学習エンジニアだと真っ先に学習データを集めてCNNを組んで実際に全身画像を撮るアプリを作って。。。と行きそうですが、筆者はそこに待ったをかけます。「そもそもそういう需要がマーケットにあるかどうか調べるのが先だろ?」と。優秀な機械学習エンジニアほど、そこにあまり注目せずいきなり機械学習プロダクトを作ってしまいがちである、と。個人的には「費用対効果が考えられていない」ケースもそうかなと。「2000万円の人件費を浮かせるために1億円かけて機械学習システムを作ったのに、売上高はたったの3000万円」とかだと目も当てられません。


3. 十分なデータがない (Not having enough data)


データ分析業界あるあるですが「そもそもその分野ではデータが手に入りにくい」みたいなケースをここでは指摘しています。代表例として挙がっているのが、ヘルスケアと金融。どちらも個々人から得られるデータが極端に強いプライバシーに当たるため、どれほど優れた機械学習モデルを使って優れた結果が得られると期待されたとしても、データ自体が取れないのでお話にならんということを言っています。こういう「そもそもデータの準備が難しいand/or不可能」な分野に遮二無二機械学習を導入しても、成果が出せないということはこの空前の人工知能ブームの中にあっては意外と忘れられがちな印象です。


4. 適切なデータがない (Not having right data)


これまたデータ分析業界あるあるの、"Garbage in, garbage out"(ゴミみたいなデータを入れても返ってくるのはゴミだけである)という格言の再掲です。人手でラベリングした学習データを使ったものの、実はその人手のラベリングの3分の1が間違っていたとしたら。。。どれほど完璧な機械学習モデルを使っても、たとえ99.9% ACCを達成したとしても、「必ず3分の1ぐらいは間違えてしまう」わけです。それではいかんということですね。この辺の問題を解決するためにdata validation processというものを定義してそこだけを担当するチームをわざわざ置く企業もあるようです。


5. データが多過ぎる (Having too much data)


上記の3に対する皮肉っぽくて面白いのがこれ。そもそもデータサイエンティストや機械学習エンジニアの主要なタスクの一つが「特徴量削減」であることを挙げて、「ストレージから溢れるほどの大量のデータを手に入れてきたとしてもその大半は機械学習の予測の役に立たないということでガンガン削らざるを得ない」ということを言っています。例として挙がっているのは「新生児の体重を母親のデータから予測する」モデル。当たり前ですが、母親の身長や体重は特徴量たり得ますが「母親の名前」は要らないわけです。けれども「母親の生まれ月(場合によっては月齢)」は関連するかもしれない。。。となると、データがちょっと多いだけでも容易に前処理プロセスが地獄絵図になります。ちなみにほぼML Opsというか最近僕が時々言及しているMeta ML(機械学習そのもの以前のメタな周辺関連領域)みたいな話題のこのセクションですが、珍しくPCAとかt-SNEといった技術系の単語が出てきます。ただし言わんとすることは「そういう次元削減のための手法があっても『どれ』を削るかは結局ヒトの判断による部分が大きい」ということで。


6. 適材適所でない人材を雇っている (Hiring the wrong people)


のっけから「車の修理を頼むのにどれほど優秀であっても医者を呼ぶ奴はいないだろ?普通は自動車整備士を呼ぶだろ?」ということを言っていて面白いこのパート。理想としては、チームが小さいうちはデータ収集・手配・前処理や特徴量エンジニアリングはたまたモデリングそして本番デプロイまでできるオールマイティなスーパーマンが数人いれば十分だけれども、チームが大きくなればなるほどETLだけとかNLPだけというような一点突破型のエキスパートがいた方が良い。とは言え「実際にはドメインエキスパートとコミュニケーションの達人を兼ねるデータサイエンティストさえいれば十分」。この辺が全部逆さまになると確かに効率悪そうですね。。。なお個人的に思うのが、ある程度組織が大きくなってきたら絶対にデータ基盤整備を担当する「データアーキテクト」は置くべきだということ。これがいるといないとでは大違いだと思います。


7. 間違ったツールを使っている (Using the wrong tools)


これは筆者の喩えがあまり適切でないと思うんですが「MySQL固執するあまりにデータ基盤に容量上の制約がかかってしまうのを優先しても仕方ない、MongoDBなどNoSQLでいくかクラウドDWHを使うべき」みたいなことを言っています。個人的には、どちらかと言うとこの事例を思い出します。

Rのstlとauto.arimaで動かしていた異常検知システムが非効率なので、PythonのProphetにリプレースしたという@さんの体験談で、これはまさに端的にこの問題点を表した事例だと思います。「そのままではいずれ技術的負債になるような特定の従来型の技術・フレームワーク固執せず、できるだけ新しくスケーラブルな技術を使え」ということですね。もっとも世の中には「アプリの本番環境がPHPだから」という理由でPHP機械学習のコードを書く界隈もあると聞くので、それ以前の問題みたいなところもありそうですが。。。


8. 適切なモデルを使っていない (Not having the right model)


ノーフリーランチ定理機械学習の世界では有名ですが、どちらかと言うと「線形分離可能パターンに樹木モデルやカーネル法など非線形分類器を当てはめると逆におかしくなる」「線形分離可能パターンには餅は餅屋でロジスティック回帰などの線形分類器が良い」みたいな話を想定した方が良いのかなと*5。要は「機械学習も万能ではない、学習モデルも適材適所」ということですね。このご時世放っておくとチューニングできもしないのにDeep Learningを投入したがる人もいたりするので*6、これは大事な話だと思います。


9. 適切な評価方法を使っていない (Not having the right yardstick)


これは流石にちゃんと機械学習できている現場なら大丈夫だろう。。。と思いきや、過去にはこういう話もあるので注意が必要なのかなと。

過学習を見逃して平気な評価方法を使うのは論外としても、例えば不均衡データに対して馬鹿正直にACCだけで評価するというのもいかんわけです。特に不均衡データの機械学習分類器でP:N = 1:1の検証用データではなく本物の新規テストデータに対して評価する際は、学習データと似たような状況にならざるを得ない*7ので注意が必要という。


感想


ML Opsに比べるとMeta ML的な話題の多いまとめ記事だったなと思いました。「どれもデジャヴのある話ばかりでそれほど大したこと言ってないよね」というのが率直な感想ですが(笑)、言い換えるとそれだけ海外でも日本とあまり変わらない問題意識があるんだなということかなと。今後も面白そうな海外記事を見つけたらちょくちょく取り上げてみようかと思います。

*1:実は僕も英語ブログの記事の一つがGregory先生からの要請がありrepostされてます

*2:某くんと話した時も産学双方のアンチパターンのリストが出てきたものの、こういうのってシェアされないよねという話題になった

*3:これはこれで非常に大事なテーマなのでそのうち腰を落ち着けてやりたいと思ってます

*4:何とかTOWNがもうやってなかったっけ笑

*5:そういや去年某所で一席やった時にその話をしました:https://youtu.be/PARsDyRJMWE?t=15m22s

*6:ただし画像認識など黙っていてもDeepの方が良いとか、そういう課題もゴロゴロあるのでこの辺は割と微妙

*7:学習データが1:9だった場合は仮に検証用データを1:1で用意したとしても実際にやってくる新規テストデータはまた1:9になるケースが多い