機械学習プロジェクトはなぜ失敗するのか

著者のRahul Agarwal氏はインドで活躍するデータサイエンティストであり、AINOW翻訳記事『データサイエンスを過度に民主化するな』の著者でもあります。同氏が最近Mediumに投稿した記事『機械学習プロジェクトはなぜ失敗するのか』では、機械学習システムを製品化する際に失敗してしまう原因が解説されています。
同氏は、機械学習システムの製品化に失敗する原因として以下のように5項目を挙げ、合わせて対策も解説しています。

機械学習プロジェクトが失敗する5つの原因とその対策

失敗原因	対策
現実的なベースラインが設定されていない。	現行のモデルのパフォーマンス、あるいは機械学習システムが実行するタスクの人間が実施した場合のパフォーマンスのような現実的な指標をベースラインにする。
完璧を目指して、いつまでも本番環境に実装しない。	基本的なモデルを本番環境に早期に実装してから、継続的インテグレーションを実施する。
本番環境に実装したら、どこかしらがうまくいかない。	A/Bテストを実施して、モデルの弱点を特定する。弱点が判明した時に備えて、旧モデルを用意しておく。
パフォーマンスはよいが、実装や運用にコストがかかり過ぎる。	知識蒸留を使ってモデルのサイズを小さくするか、若干のパフォーマンスを犠牲にして小さいサイズのモデルを実装する。
モデルのパフォーマンスが低下する。	モデルの再学習をあらかじめ計画したり、低精度の事例を使って再学習したりする。

以上のような同氏の分析は、どちらかというとエンジニアリング的な見地から解説されたものです。対してAINOW翻訳記事『ほとんどのデータサイエンスプロジェクトが採用にいたらない5つの理由』では、プロジェクトマネジメント的見地から機械学習システムを含むデータサイエンスプロジェクトが製品化に至らない原因が解説されています。
以上のように、機械学習またはデータサイエンスのプロジェクトを成功させるノウハウが着々と蓄積されています。こうしたノウハウは、近い将来、MLOps運用のガイドラインとして整備されていくのではないでしょうか。

なお、以下の記事本文はRahul Agarwal氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。また、翻訳記事の内容は同氏の見解であり、特定の国や地域ならび組織や団体を代表するものではなく、翻訳者およびAINOW編集部の主義主張を表明したものでもありません。

画像出典：Pixabayのlisa runnelsから

機械学習プロジェクトが崩壊してしまわないように、その製品化の前に考えること
1.最初にベースラインを確立する
2.継続的インテグレーションこそが進むべき道
3.A/Bテストを確実に行う
4.あなたのモデルは製品化されないかも知れない
5.メンテナンスとフィードバックのループ
結論

機械学習プロジェクトが崩壊してしまわないように、その製品化の前に考えること

データサイエンティストとしての仕事のひとつには、与えられた機械学習プロジェクトの全体設計を作成することがある。分類、回帰、またはディープラーニングのプロジェクトに取り組んでいるかどうかに関わらず、データの前処理ステップ、特徴エンジニアリング、特徴量の選択、評価指標、アルゴリズム、および当該アルゴリズムのハイパーパラメータのチューニングを決定するのがデータサイエンティストの仕事となる。そして、これらの問題に頭を悩ますのに多くの時間を費やしている。

以上に挙げた仕事は、それだけで結構なものである。しかし、優れた機械学習システムを構築する際には、他にも考慮すべき重要なことがたくさんある。例えば、モデルを手に入れたら、どのように実装するのかを考えたことがあるだろうか。

私は多くの機械学習プロジェクトを見てきたが、その多くはプロジェクトの開始時点で製品化に向けての計画が決まっていなかったため、始める前に失敗する運命にあった。私の考えでは、機械学習プロジェクトを成功させるためのプロセス要件は、モデルがいつ、どのようにして製品化されるかを考えることから始まるのだ。

・・・

1.最初にベースラインを確立する

私はほとんどの企業において機械学習プロジェクトがどのように始まるか知っているのだが、その始まり方に嫌気がさしている。もし読者諸氏が次のようなことを聞いたことがあるなら、ぜひ知らせてほしい。いわく「我々は95％以上の精度で機能する最先端のモデルを作成するのだ」と。あるいは、こんなことも聞いたことがあるだろうか。「ゼロに近いRMSE（※訳註1）を持つ時系列モデルを構築しよう」。私たちが住んでいる世界は不確実なものなので、そのようなモデルへの期待は馬鹿げている。例えば、明日雨が降るかどうか、あるいは顧客が何らかの製品を好むかどうかを予測するモデルを作ろうとしていることを考えてみよう。これらの質問に対する答えは、私たちがアクセスできない多くの特徴に依存しているかも知れない。高尚な期待に応えられないモデルは、たいてい放棄されてしまうので、こうした無理な戦略はビジネスにも悪影響を及ぼす。このような失敗を避けるためには、プロジェクトの開始時にベースラインを作成する必要がある。

（※訳註1）RMSE（Root Mean Squared Error：二乗平均平方根誤差）とは、予測モデルの精度を測定する指標のひとつ。以下のような手順で誤差を算出する。数式で表すと、以下のようになる。

画像出典：AIZINE『RMSEを楽々理解！二乗平均平方根誤差を実装しながら学ぼう』より引用

以上の数式にもとづいたRMSEの算出手順は、以下の通り。

1．各データの実績値に対する予測値の誤差を計算し二乗する。
2．二乗した誤差を合計する。
3．二乗誤差の合計値をデータ件数で割って二乗誤差の平均値を算出する。
4．二乗誤差の平均値の平方根を算出する。

類似の誤差測定手法に平均絶対誤差（MAE：Mean Absolute Error）があり、この手法では誤差を二乗しないで誤差平均の平方根を算出する。RMSEは算出過程で誤差を二乗するので、MAEより誤差を大きく評価できる。

ビジネス上の指標あるいは現在のモデルのパフォーマンスを考慮してベースラインを設定すること。画像出典：Pixabay

では、ベースラインとは何だろうか。それは、特定のタスクに関してビジネス的見地から見た現時点のパフォーマンスを理解するのに役立つ単純な指標である。モデルが基準値を上回るか、少なくとも基準値と一致していれば、利益が上がる領域に入っていることになる。タスクが現在手動で行われている場合、この指標（としての手動業務）に勝てば、自動化が可能であることを意味する。

そして、モデルの作成を始める前に、成果とすべきベースラインを取得したほうがよい。例えば、時系列モデルの評価指標としてRMSEを使用し、その結果がXになったとする。Xという値はよいものなのか。この時点では、それは単なる数値だ。測定値Xの良し悪しを把握するためには、前のモデルや他のヒューリスティックな手法よりも良いか悪いかを確認するためのベースラインRMSEが必要となる。

ベースラインは、現在同じタスクで使用されているモデルから決められる。単純なヒューリスティックもベースラインとして使用できる。例えば、時系列モデルでは凌駕すべき指標として具合のいいベースラインは、最終日の数値を予測して、その予測値にもとづいてベースラインRMSEを計算することだ。もしあなたのモデルがこの素朴な基準にさえ勝てないならば、そのモデルは何の価値も付加していないことがはっきりとわかる。

それでは、画像の分類タスクではどうだろうか。1,000個のラベル付けされたサンプルを人間に分類させ、人間の精度をベースラインとできる。（分類すべきクラスが多数あるために）タスクが非常に複雑であったり、（人の顔から感情を予測するなどのように）タスクがかなり主観的であったりするため、人間が70%の予測精度を得ることができない場合は、モデルが人間と同じようなパフォーマンスレベルに達したら、いつでもプロセスを自動化できる。

モデルを作成する前に、どのようなパフォーマンスが得られるのかを意識してみよう。世界の常識を覆すような成果を期待しても当てにならず、あなたとクライアントは裏切られ、プロジェクトが製品化に向かうのを止めてしまうだけなのだ。

・・・

2.継続的インテグレーションこそが進むべき道

モデルを作成し、ローカルのテストデータセットを使っている限りではベースラインや現在のモデルよりも優れたパフォーマンスを発揮していたとする。この場合、製品化に移行するべきだろうか。この時点で、以下のような2つの選択肢がある。

さらにモデルを改善する無限ループに入る：現在のシステムをそもそも変えることを検討していなかったり、新システムを実際に本番環境に実装しようとする前にベストなパフォーマンスを発揮するシステムを求めたりするビジネス事例を、私は無数に見て来た。
本番環境でモデルをテストして、何がうまくいかないのかをより深く理解したうえで、継続的インテグレーションでモデルを改善していく。

私は2つ目のアプローチのファンだ。CourseraにおけるAndrew Ng氏のディープラーニング専門講座の素晴らしい第3講座で、彼は以下のように言っている。

完璧なシステムを設計して構築しようとすることから始めないでください。その代わりに、基本的なシステムを素早く、おそらく数日以内には構築し訓練するようにしてください。基本システムが構築可能な「最高」のシステムとは程遠いものであっても、それがどのように機能するかを調べるのは価値あることです。そうすれば、あなたの時間を投資するための最も有望な方向性を示す手がかりをすぐに見つけることができます。

私たちのモットーは、「完璧を目指すよりまず終わらせろ」であるべきなのだ（※訳註2）。

現在稼働しているモデルよりも新型の方が良いとか、ベースラインよりも新型の方が良いとか言って、開発中のモデルを本番環境に投入するのをいつまでも先延ばしにするのは無意味である。

（※訳註2）「完璧を目指すよりまず終わらせろ（Done is better than perfect）」は、FacebookがIPOを実施する際に作成した目論見書に、同社のモットーとして掲げられた標語である。
目論見書には同社独自の文化として「ハッカーの手法（The Hacker Way）」が根付いていることを説明する箇所がある。その箇所でハッキングの本来的な意味として「何かを素早く構築すること」と指摘したうえで、同社は常に何かを改善できると信じており、反復的にリリースすることを目指すと述べている。そして、反復的改善を実行するために「完璧を目指すよりまず終わらせろ」と壁に書かれている、と説明されている。

・・・

3.A/Bテストを確実に行う

ベースラインの重要性はすでに述べたわけだが、あなたのモデルは本当にベースラインよりも優れているのだろうか？確かにローカルのテストデータセットではより良いパフォーマンスを発揮したが、本番環境ではプロジェクト全体でうまく機能するだろうか。

新しいモデルが既存のモデルよりも優れているという仮定の妥当性をテストするために、A/Bテストを設定できる。（テストグループを形成する）何人かのユーザはあなたのモデルから得た予測を見る一方で、（コントロールグループとなる）他の何人かのユーザは以前のモデルからの予測を見る。実際、A/Bテストの実施はあなたのモデルを実装する際の正しい方法なのだ。しかも実のところ、モデルが思ったほど良くないことに気づくかも知れないのだ。

モデルが不正確であることは本当に悪いわけではないことを心に留めておこう。本当に悪いのは、自分が間違っている可能性があることを予見しないことだ。プロジェクトを真に破壊する最も早い方法は、自分自身の誤りを直視することを頑なに怠ることである。

本番環境に設定してモデルの性能が低下してしまう時の正確な理由を指摘するのは難しいかも知れないが、以下のようにいくつかの原因が考えられる。

リアルタイムで送られてくるデータが訓練データと大きく異なること、つまり、訓練データとリアルタイムデータの分布が異なることがわかるかも知れない。こうした差異は、時間の経過とともに嗜好が変化する広告分類モデルで起こる可能性がある。
前処理パイプラインが正しく行われていない可能性がある。つまり、本番時には利用できないいくつかの特徴を学習データセットが誤って含んでいる可能性があるのだ。例えば、「COVID Lockdown(0/1)」という変数をデータセットに追加したとする。しかし、本番環境ではロックダウンがどのくらいの期間有効であるか、実際にはわからないかも知れないのだ。
コードレビューをしても捕捉できなかったバグが実装したなかにあるかも知れない。

原因が何であれ、教訓として学ぶべきは、いきなり全部を本番環境に投入すべきではない、ということだ。A/Bテストは常に前進するための優れた方法である。そして、モデルに欠陥があることがわかったら、前の状態に戻せるように用意しておこう。「前の状態」とは、おそらく古いモデルのようなものだ。たとえ開発中のモデルがうまく機能していても、予想できなかったことが起こるかもしれないので、代替物を準備する必要がある。

・・・

4.あなたのモデルは製品化されないかも知れない

印象的な機械学習モデルを作成したとしよう。精度は90%だが、予測を取得するのに約10秒かかる。あるいは、予測するのに多くのリソースを必要とするかも知れない。

そうした性能は受け入れられるだろうか。いくつかのユースケースでは受け入れられるかも知れないが、ほとんどの場合はノーである。

オットーグループ主催のKaggle分類コンペの優勝モデルのアーキテクチャ

（※訳註3）以上の画像は、後述するオットーグループ主催の分類モデルのコンペで優勝したモデルのアーキテクチャを図示している。モデルは3層から形成され、第1層には33のモデルと8つの特徴量が含まれている。この合計41の出力は第2層に渡され、XGBOOST、ニューラルネットワーク、ADABOOSTの3つのネットワークの入力となる。第3層では第2層の3つのネットワークから得た出力の加重平均を算出して、最終的な予測値が出力される。

かつてはKaggleコンペティションの多くの勝者は、リーダーボード上のトップスポットを取るためにモンスターのようなアンサンブルモデルを作成することに徹していた。こちらから、Kaggleにあるオットーグループが出題した分類チャレンジ（※訳註4）に勝利するために使用された特に心に響く事例を閲覧できる。

（※訳註4）ドイツに本社を置く国際的なeコマーズ企業のオットーグループは、2015年3月17日から5月18日に同社の製品を分類するモデルに関するコンペをKaggleで開催した。賞金は10,000ドルで、3,505のチームがエントリーした。
同社が提供したデータセットは20万件を超えるもので、9つのカテゴリーと93の特徴量を持っていた。

もう一つの例として、Netflixの100万ドルの賞金が懸けられたレコメンデーションエンジンチャレンジがある。Netflixチームは、開発コストがかかるため、優勝したソリューションを使うことすらできなかった。このようなことはよくあることだ。複雑なモデルを製品化するためのコストや開発に要する努力が高くつきすぎるため、もはや利益が出ずに先に進めなくなるのだ。

では、どのようにしてモデルを高精度でありながら、かつ簡単にデバイスに実装できるだろうか。

こうした場合には教師-生徒モデルの概念、すなわち知識の蒸留が役立つ。知識の蒸留では、すでに訓練済みのサイズが大きな教師モデルの上に小さな生徒モデルを置いて訓練する。ここでの主な目的はパラメータの少ない生徒モデルを使って、我々が持っている最高のモデルである教師モデルを模倣することである。教師モデルからソフトラベルに含まれる分類確率の分布を取り出し、それを生徒モデルの学習データとして使用できる。こうした手法の背後にある直感は、ソフトラベルの方がハードラベルよりもはるかに情報量が多いことだ。例えば、猫と犬を分類する教師の分類器は、それぞれのクラスの確率は猫が0.8、犬が 0.2と示されている知れない。このようなラベルは、もともとの学習データに付与されたそれより情報量が多い。生徒の分類器はソフトラベルから画像が猫であるが、わずかに犬にも似ていることを知れる。あるいは両方の確率が似ている場合、生徒の分類器は教師を真似るのを学習した結果、特定の事例について分類の信頼度が低下してしまうこともある（※訳註5）。

（※訳註5）機械学習における蒸留では、この記事が解説しているように、サイズの大きい教師モデルから精度を著しく低下させずにサイズの小さい生徒モデルが作成される。生徒モデルの作成の際に学習データとして使うのが、教師モデルの出力である。この出力はソフトターゲットと呼ばれる。そして、もともとの学習データはハードターゲットという用語によって区別される。
ソフトターゲットには教師モデルの出力が反映されているので、それぞれの分類クラスに関して確率が付与されている。この付与された確率がソフトラベルと言われ、もともとの学習データに付与された正解ラベルをハードラベルと呼んで区別される。ハードラベルには正解となる分類クラスのラベルのみが付与されているのに対して、ソフトラベルは各分類クラスに関する確率分布を含んでいるため、ハードラベルより情報量が多い（下の画像参照）。

画像出典：code Craft House『Deep Learningにおける知識の蒸留』より引用

ソフトラベルを含むソフトターゲットを使えば、ハードターゲットのみを使うより効率的に学習できるため、小さいサイズで教師モデルと同程度の精度が期待できる（下の画像参照）。もっとも、この記事で指摘されているように、ソフトラベルの確率分布によっては、精度が劣化する場合もある。

画像出典：code Craft House『Deep Learningにおける知識の蒸留』より引用

予測時の実行時間とリソース使用量を減らすもう一つの方法は、よりシンプルなモデルを使用することで、精度と性能を少しだけ犠牲にすることだ。

場合によっては、予測時に利用可能な演算能力があまりないこともある。時にはエッジデバイスでも予測しなければならないので、より軽量なモデルが求められることもある。このようなユースケースでは、よりシンプルなモデルを構築するか、知識蒸留の使用を試せる。

・・・

5.メンテナンスとフィードバックのループ

世界は一定ではないし、あなたのモデルの重みもまた一定ではない。私たちを取り巻く世界は急速に変化しており、2ヶ月前に適用できていたことが今は関係ないかも知れない。ある意味では、あなたが構築するモデルは世界の反映であり、世界が変化しているならば、構築したモデルはその変化が反映され得るべきなのだ。

（※訳註6）上の画像は、機械学習モデルの精度が劣化する様子を示した模式図となっている。縦軸が精度、横軸が（稼働）時間である。時間が経過すると精度が低下する右肩下がりのグラフとなる。

モデルの性能は一般的に時間の経過とともに劣化していく。このため、メンテナンスサイクルの一環としてモデルをアップグレードする方法を、モデルの稼働開始時から考えなければならない（※訳註7）。

（※訳註7）機械学習システムの予測精度が稼働後から劣化する現象については、AINOW翻訳記事『なぜ機械学習モデルは製品化すると劣化するのか』で詳しく論じられている。こうした性能劣化はコンセプトドリフトと呼ばれ、その原因は開発時の学習データと稼働後に投入されるデータのあいだで特徴上の差異が生じるためである。
コンセプトドリフト対策としては、精度の劣化が認められた度に再訓練する、精度をモニタリングしたうえで劣化が認められた場合に自動的に再訓練する機能を実装する等が考えられる。

このアップグレードサイクルの頻度は、解決しようとしているビジネス上の問題に完全に依存する。例えば、ユーザが気まぐれな傾向にあり、そんな気まぐれな購買パターンが継続的に認められる状況で実装される広告予測システムでは、アップグレードサイクルの頻度はかなり多くする必要がある。反対に、レビューのセンチメント分析システムでは、言語の構造がそれほど頻繁に変化しないため、頻度はそれほど高くなくてもよい。

また、機械学習システムにおけるフィードバックループの重要性を私は認めている。犬と猫に関する分類器で、特定の画像が犬であることを低確率で予測したとしよう。このような低確率の事例から何か学べるだろうか。その事例を人間によるレビューに送って、モデルの再訓練に使えるかどうかを確認できる。このようにして、分類器の信頼度が低い事例を使って分類器を訓練するのだ。

製品化を考える際には、フィードバックも活用してモデルの訓練・メンテナンス・改善の計画を考えてみよう。

・・・

結論

以上の解説は、モデルの製品化を考える前に、私が重要だと思うことのうちのいくつかである。考えなければならないことや生じ得る問題点を網羅したリストではないものも、次に機械学習システムを作るときの思案の糧にしてほしい。

機械学習プロジェクトを構造化する方法とベストプラクティスについての詳細をもっと学びたい場合は、ディープラーニング専門講座における機械学習プロジェクトの構造化という名前のAndre Ng氏の優れた第3講座をすすめる。その講座をチェックしてみよう。

読んで頂いてありがとうございます。私はこれからも初心者向けの記事を書いていくつもりです。Mediumで私をフォローしたり、Mediumへの投稿について通知されるように私のブログを定期購読したりしてください。いつものように、私はフィードバックや建設的な批判を歓迎しており、Twitterの@mlwhizでコンタクトできます。

最後に小さな免責事項 – 知識を共有することは決して悪いことではないのですが、この記事に示された関連リソースのなかにはアフィリエイトリンクが含まれているかも知れません。

MediumコミュニティのひとつであるThe Startapに感謝を捧げる。

原文
『Why Do Machine Learning Projects Fail?』