たけのこブログ

凡人が頑張って背伸びするブログ

失敗しないために、AutoMLを使うときに試している三つのこと

GCP AutoML 機械学習

簡単な深層学習タスクはAutoMLで実装できるけど...

(まだ研究してる博士後期課程の院生だけど、)業務委託で複数の企業の案件に携わっていると、いろんな要望があります。例えば、 ・HTTPレスポンスで良いからSageMakerやcloud functionsとかでUI意識せずに気軽に機械学習ウィジェット作ってよ ・モバイルに組み込みたいから、それに対応した形で出力してよ(TFLite形式とかで作ってよ) ・いろんな前処理も導入させたいから、関数じゃなくてEc2やGCE、GAEとかで定期実行するように実装してよ

特に上記二つに関しては、簡単な深層学習タスクであればAutoMLで簡単に作成可能ですし、自分も面倒臭くてAutoMLで解決できそうなものはAutoMLで素早くデプロイまでやってしまうことが多いです(機械学習の「UberEats」みたいな感覚で使ってます)。AutoMLは機械学習の知識がない方でも簡単に学習器を作れると唄ってる通り、実際に知識がなくてもデータさえあれば簡単に機械学習モデルが作れます(機械学習エンジニアの仕事を奪うとか言ってる人もたくさん居るみたいだし)。しかし、例えば誤ったデータを入力として入れると「過学習」と呼ばれる、端的に言えば「入力データに過剰に適合しすぎて、実際のサービスに移植した時に汎用性に欠ける挙動をしてしまう」ことが(知識があっても)度々あります。

そこで、今回は自分自身の経験を踏まえた上でAutoMLを実際に使用する時にチェックしてることを大きく分けて三つ紹介したいと思います。

知識があろうがなかろうが、PoC検証は必要

これを言ったら元も子もないじゃないかと言われても仕方がないのですが、必要だと思います。

AutoMLは確かに便利です。HTTP形式でもモバイル形式でもデプロイできますし、並列にいろんなモデルを学習させる環境を作ってジョブ投げる必要もないし、コスパよくやって評価指標まで出してくれる。特徴量が見えないのが難点ですが、それでも実用に早く移したいプロジェクトにおいてはそこまで重要視しないので、かなり有用なツールだと思います。

しかし、AutoMLを実行すると当然ながら(無料期間の範囲でなければ)お金が発生します。データが少ない場合は並列処理させる(あくまで推奨なので変更できますが)ノードの数は1~2個くらいで済みますし処理時間も1時間くらいで終わったりしますが、全体のデータ量が多かったりするとノードが1,2個じゃ済まないし処理時間も3時間以上が当たり前のようになるので、2000円のはずが数倍以上になっちゃったというケースがあります。この場合、事前にPoC検証して使用するデータや性能評価の当たりをつけておかないと、その訓練データで本当に大丈夫か分からない状態で実機で試してはダメでまたAutoMLでモデルを作って...という負の連鎖でコストが発生していきます。特に性能評価は重要で、過学習してしまうようなデータセットなのか見極めるために必要です。潤沢に予算があればAutoMLで逐一結果を確認していくのでも良いかもしれませんが、ハッキリ言ってもったいないです。

例えば画像処理なら簡単に事前学習されたモデルを使ったCNNなどの検証で構わないと思うので、知識がなくてもちゃんと判定できてるのか事前に最低限の検証をした方が良いと思います(ウェブサイトのコピペで挙動を試すのでも良いと思うので...汗)

そのデータ、本当にロバスト？

これは適当にPoC検証やってたりデータの仕様を眺めてると直ぐに気付き出すのですが、「データのサイズが統一されてるけど実サービスではリサイズされてないデータが対象」とかの自体が発生した時に、スケール不変性が保証されてないデータで学習して詰んだりとかが例としてあります。

AutoMLを使用する際にもこれは共通で、統一されたデータを使うのは良いことですが、ちゃんと実サービスに沿った入力・出力を意識して対応づけることをオススメします。自分は一回ミスった経験から、画像処理の場合は「スケール不変性は必要？回転不変性は必要？」と実サービスの設計と睨めっこしながら逐一確認する癖がつきました。

独立したテストデータで確認

これもPoC検証の一環といえばその通りなのですが、実際にサービスで動いて欲しい挙動が評価できるようなテストデータを用意しておいた方が良いです。これも実際に機械学習の解析してる方からすると当たり前なのですが、事前にテストデータを用意しておくことをオススメします。

自分もいきなり「こういうAPIのための学習器モデル作ってよ」とかテストデータがない状況でお願いされた時は、自分で勝手に独立性を検証できるようなデータを半自動でスクレイピングできるソースコードを作って収集して、一部ラベル付けしてみたいなことをやってたりします(収集を定期実行させてもラベル付けは手動になりがちなので、地味で怠いんですけどね笑)。

これをしないと汎化性能を確認できないし、精度改善のために何が足りないのかAutoMLのテストなどから推定するのも難しいと思うので、テストデータは訓練データと別途違う形で用意して評価することをオススメしたいと思います。

まとめ

今回は、業務でAutoMLを使うときに気をつけている三つのことについてまとめてみました。正直にいうと、「機械学習で解析する時に気をつけてること」とほぼ同じ注意点だったりするのですが、コスト面などの問題もあるので最低限のPoC検証はできた方が良いかなと思います。

よくよく考えたら、こういうネタを喋るのって初めてかもしれない笑