AutoML は人間に取って代わるのでしょうか? 4 人のエンジニアと 2 つのデータ セットがそれを打ち負かしました。

ここ数年、ますます多くのテクノロジー大手が独自の AutoML サービスを立ち上げており、こうしたサービスに対する市場の注目と認知度が高まっています。データ サイエンティストは、常に「AutoML が私たちに取って代わるのだろうか?」という自問自答に直面しています。 この記事では、4 人のデータ サイエンティストがペアになって 2 つのデータセットを使用して AutoML サービスと直接競合し、最終的に AutoML がゆっくりとエンジニアに取って代わることができることを証明しました。

現在どのような AutoML プラットフォームが存在しますか?

AutoML を理解するには、まず機械学習プロジェクトのライフサイクルについて説明する必要があります。このライフサイクルには、データのクリーニング、機能の選択/エンジニアリング、モデルの選択、パラメータの最適化、そして最後にモデルの検証が含まれます。急速な技術進歩にもかかわらず、従来のデータ サイエンス プロジェクトには、依然として時間がかかり反復的な手動プロセスが多数含まれています。

画像ソース: R. Olson 他 (2016)。自動化されたデータ サイエンスのコンテキストにおける TPOT (ツリーベースのパイプライン最適化ツール) の評価。

AutoML は、データのクリーニングからパラメータの最適化までの全プロセスを自動で完了できるため、時間とパフォーマンスを大幅に改善し、さまざまな機械学習プロジェクトに大きな価値をもたらします。

1. Google Cloud AutoML

2018 年にリリースされた Google Cloud AutoML は、ユーザーフレンドリーなインターフェースと非常に高いパフォーマンスにより、市場で急速に人気を博しました。下の図は、Google と他の AutoML プラットフォームのパフォーマンス比較を示しています (青いバーは Google AutoML)。

出典: 「構造化データに AutoML を適用して価値の高いビジネス問題を解決する」、Cloud Next Conference 2019

2. Microsoft Azure AutoML

同じく 2018 年にリリースされた Azure AutoML は、プログラミングの知識に詳しくないユーザーにも、非常に透明性の高いモデル選択プロセスを提供します。

3. H2o.ai

「H2O は大規模モデル構築の分野で大きな力を持つようになりました。数十億のパラメータに直面すると、標準的なオープンソース技術は無力になります。」 — H2o.ai

H2o は 2012 年に設立され、オープンソース ソフトウェアと商用 AutoML サービス (Driverless AI) の両方を提供しています。 H2Oは発売以来、金融サービスや小売業などの業界で広く利用されてきました。

4. TPOT

TPOT (ツリーベースのパイプライン最適化ツール) はペンシルバニア大学によって開発された無料の Python パッケージです。このソフトウェアは完全に無料ですが、機能性に妥協はなく、さまざまなデータ セットで優れたパフォーマンスを発揮します。Iris データ セットの精度は約 97%、MNIS デジタル認識データ セットの精度は 98%、ボストンの住宅価格予測は 10 MSE です。

AutoML 対 データ サイエンティスト

これで、AutoML の基本的な定義と利用可能なオプションを理解しました。核心的な質問に移りましょう。これらのプラットフォームは人間のデータ サイエンティストを完全に置き換えるのでしょうか?

納得のいく答えを見つけるために、AutoMLと人間の分析能力の違いを客観的に評価するハッカソンを実施します。

コスト比較

Indeed.com によると、米国のデータサイエンティストの平均年収は 121,585 ドルです。企業が年間を通じて継続的に AutoML を使用する場合 (週 40 時間、年間 52 週間)、実際のプラットフォーム オプションに応じて、コストは年間 4,160 ドルから 41,600 ドルの間になります。

確かに、データ サイエンティストにはモデル操作以外にも対処すべきタスクがあることは周知の事実であるため、このような直接的な比較は公平ではありません。しかし一方で、この迅速で簡単な方法は、データ サイエンティストと AutoML の間のコストの違いをある程度反映しています。

データ サイエンティストと AutoML のコスト比較

パフォーマンス比較: ハッカソン

次に、両方のデータセットをカバーするハッカソンを開催し、人間のデータ サイエンティストと AutoML プラットフォームのパフォーマンスの違いをさらに比較します。各データセットには、人間のデータ サイエンティストのチームと複数の AutoML プラットフォームが存在します。両者は、データ処理、特徴選択/エンジニアリング、モデル選択、パラメータ調整を同時に実行し、最終的に所定のパフォーマンス指標を満たす最良の予測結果を提供することを目指します。

ハッカソンデータセット1: 迅速な分類

ハッカソン データセット 2: ASHRAE (回帰)

データセット 1: 高速分類データセット

データセットの概要

このデータセットは、実験的なスピードデートイベントに参加した人々から収集されました。これらのイベントでは、参加者は個人情報や理想のパートナーに求める特徴を含むアンケートに回答します。たとえば、自分自身、自分の仕事、パートナーに求める資質を 1 から 10 のスケールで評価します。このデータセットの目的は、個人の好みに基づいて適切な相手を見つけられるかどうかを予測することです。これは典型的な分類問題であり、「一致」変数が従属変数として存在します。

データ サイエンティストのためのデータ前処理と特徴エンジニアリング

AutoML プラットフォームよりも優れた結果を達成するには、人間のデータ サイエンティストがデータセットに対して特徴エンジニアリングを実行し、クラスの不均衡を処理し、欠損値を処理し、カテゴリの変更に対してワンホット エンコーディングを実行する必要があります。データはアンケートから収集されたため、値が欠落しているという重大な問題があるはずです。これは、インタビュアーが質問に答えたくない場合は、単に空白のままにできるためです。これらの欠損値は、平均値、中央値、または最頻値を適切に推定することによってのみ対処できます。データはいくつかの独立変数間で共線性があったため、いくつかの変数は削除されました。すべてのラベルのうち、バイナリ値が 1 であるのは 29% のみで、残りはバイナリ値が 0 です。この問題に対処するために、SMOTE (Synthetic Minority Oversampling Technique) を採用します。 SMOTE は、単にデータをコピーするのではなく、少数クラスから合成サンプルを作成できます。 Google プラットフォームでは抽出された情報を意味のある形でグループ化できないため、ワンホット エンコーディングを実装するのは困難な場合がよくあります。

ここでは、生データと機能エンジニアリングされたデータの両方を使用して、Azure と Google の AutoML プラットフォームの全体的な有効性を分析します。

データ サイエンティストと AutoML プラットフォーム

データ サイエンティスト: さまざまなモデルを試した結果、XGBoost とニューラル ネットワーク モデルが最も優れたパフォーマンスを発揮することがわかりました。ここでは主に AUC ROC スコアに焦点を当て、モデルの結果を AutoML プラットフォームによって作成されたモデルと比較します。 XGBoost モデルは AUC ROC スコア 0.77 を達成しましたが、ニューラル ネットワーク モデルは AUC ROC スコア 0.74 を達成しました。

生データを使用する AutoML プラットフォーム: XGBoost も使用しており、Google のパフォーマンス レベルは Azure よりもわずかに優れています。 Google の AUC ROC スコアは 0.881 ですが、Azure は 0.865 です。関連情報は独自の情報として分類されているため、Google プラットフォームがどのモデルを選択したかを知る方法はありません。一方、Azure は、実行したモデルの数、各モデルのスコア、各モデルのトレーニングにかかった時間などを正確に伝えます。

処理済みデータを使用する AutoML プラットフォーム: ここで、機能エンジニアリングされたデータセットで AutoML がどの程度のパフォーマンスを発揮するかを測定します。 Google のパフォーマンスは低下し、Azure のパフォーマンスは向上したことがわかりました。前述したように、Google AutoML はワンホット エンコーディングの処理に問題があり、特徴エンジニアリングを自律的に実行するように設計されています。したがって、ワンホットエンコードされた変数の形式で特徴エンジニアリングデータを提供すると、全体的なパフォーマンスが低下します。このテスト ラウンドでは、Azure のパフォーマンスが 0.865 から 0.885 に向上しました。

次の図は、Azure がデータセットに対して実行するさまざまなモデルを示しています。

Google プラットフォームと Azure プラットフォームでは、適合率 - 再現率グラフ、ROC グラフ、混同行列、特徴重要度グラフも確認できます。

クイック（日付）分類データセットテストの結論:

• データ サイエンティストは、機能エンジニアリングされたデータセットを AutoML プラットフォームに提供することで、プラットフォームのパフォーマンス レベルを向上させることができます。
• Azure は特定の使用モデルについてより透明性が高く、Google のプラットフォームはモデルの作成と選択に関する情報の開示を拒否しています。
• Google は、ワンホットエンコードされた変数を適切に処理しません。

データセット 2: ASHRAE

データセットの概要

このデータセットは、ASHRAE Energy Prediction Kaggle コンテストから提供されたもので、参加者は 1,449 棟の建物における温水、冷水、蒸気、メーター数の予測モデルを開発する必要があります。データは、建物の面積、建設日、総階数、計器の種類とタイムスタンプ付きの測定値、気温、雲量、降水量、風速、風向、海面気圧などのタイムスタンプ付きの気象データなど、建物に関するさまざまなメタデータから取得されます。気象データは建物の近くにある気象観測所から提供されます。

データ サイエンティストのためのデータ前処理と特徴エンジニアリング

天気データセットにも、欠損値という重大な問題があります。雲量と降水量の特徴には、それぞれ 50% と 35% の欠損値があることがわかります。気象観測所の中には、雲量や降水量のデータをまったく提供していないところもあります。この障害を克服するために、データ サイエンティストは、気温、露点温度、風速、海面気圧などの特徴を整理して、欠落している部分を補間し、これらの補間を使用して雲量と降水量の予測モデルを構築しようとします。

10 倍のクロス検証を使用して各機能の補間方法を選択し、それをトレーニング データとテスト データに適用しました。雲量と降水量を予測するためにさまざまなモデルを実行しましたが、欠落値を正確に生成する理想的なモデルを見つけることができませんでした。風向の測定にはギャップがあったため、各データセットをカテゴリ変数のセットに再構成しました。明らかに右に偏った分布のため、風速の結果を対数変換しました。さらに、休日や週末などの他の機能を組み込み、影響の遅れを導入します。全体として、13 個のオリジナル機能に加えて 19 個の追加機能を構築し、合計 32 個の変数が作成されました。

最後に、気象観測所が収集した異常気象データを 1 つ削除し、前方回帰、後方回帰、段階的回帰を使用して最適な予測機能を見つけました。そのため、予測に使用された実際の変数の数は 13 でした。

データ サイエンティストと AutoML プラットフォーム

データ サイエンティスト: すべての建物に対して汎用モデルを構築する代わりに、データセット内の各建物に対して個別のライト勾配ブースティング モデルを構築し、トレーニング セットとテスト セットに同じ建物に関する情報が含まれるようにしました。このアプローチにより、0.773 RMSLE が得られました。

生データを使用する AutoML プラットフォーム: 1 時間のトレーニング後、Google Cloud は 1.017 RMSLE を達成しました。さらに 3 時間のトレーニング後、RMSLE はさらに 0.011 向上しました。このテストでは、Google は RMSLE が 2.22 だった Azure を簡単に上回りました。もちろん、RMSLE 結果を返すためにランダム フォレストの使用を強制するように Azure に要求したため、これは完全に公平な比較ではありません。

処理済みデータを使用する AutoML プラットフォーム: 処理済みデータを Google Cloud 経由で実行します。 4 時間のトレーニングの後、Google Cloud は RMSLE 1.7 を達成しました。これは私たちにとって非常に驚くべき結果でした。さらに調査を進めたところ、AutoML プラットフォームが独自の特徴選択を実行する必要があったため、当社の特徴選択アプローチが AutoML のパフォーマンスを制限していることが判明しました。処理されたデータを、前述の 13 個ではなく、32 個すべての変数を使用して、両方のプラットフォームで再度実行しました。今回は、両方のプラットフォームでパフォーマンスが向上しました。 1 時間のトレーニング後、Google Cloud の RMSLE は 0.755 になり、4 時間のトレーニング後には RMSLE はさらに 0.656 に達し、データ サイエンティストが生成した結果をはるかに上回りました。 1 時間のトレーニング後、Azure は RMSLE 3.826 を達成し、4 時間のトレーニング後には 3.653 を達成しました。

ASHRAE データセットテストの結論:

AutoML は強力な予測ツールですが、人間ほど効果的にデータの前処理を実行することはできません。

トレーニング サイクルを数時間延長すると、AutoML プラットフォームのパフォーマンスが大幅に向上します。

AutoML プラットフォームが独自に機能を選択できるようにする必要があります。そうしないと、パフォーマンスに重大な影響が出る可能性があります。

データ サイエンティストのビジネス問題に関する専門知識と、AutoML の強力な特徴選択、特徴前処理、モデル選択、ハイパーパラメータ調整機能を組み合わせることで、強力なエネルギーが解き放たれ、貴重な洞察と理想的な予測結果がもたらされます。

結論は

最後に、3 つの質問でこの議論を締めくくります。

AutoML はデータ サイエンティストを置き換えることができますか?

答えはノーです。

AutoML はモデルの構築には確かに優れていますが、ほとんどのデータ サイエンティストが慣れている種類の作業にはまだ十分ではありません。ビジネス上の問題を定義し、その専門知識を活用してより有意義な機能を構築するには、データ サイエンティストに頼る必要があります。現在、AutoML は分類や回帰問題など、限られた数の問題タイプしか処理できません。つまり、推奨モデルやランキング モデルを構築することはまだできません。さらに重要なのは、データから実用的な洞察を抽出するにはデータ サイエンティストが必要であり、これは AutoML だけでは実現できないということです。

ただし、AutoML は、データ サイエンティストが利害関係者に対して多大な価値を生み出すのに役立ちます。次に答えるべき質問は、「AutoML はいつ使用すべきか?」です。どうやって使うの？

データ サイエンティストは AutoML プラットフォームを最大限に活用するにはどうすればよいでしょうか?

ここでは、いくつかの潜在的な使用例を参照できます。

解釈可能性よりもパフォーマンスが重要な場合:

場合によっては、利害関係者は、モデルに明確な解釈可能性を要求せず、モデルの精度のみを気にすることがあります。私たちの実験に基づくと、AutoML に特徴エンジニアリングのための十分な余裕を持たせることがパフォーマンスの向上に役立つようです。しかし、例では、両方のプラットフォームとも、機能の重要性に関して解釈可能性がわずかにしか示されていません。つまり、特徴の重要度を知るだけで十分な場合、AutoML はより高い分析精度を実現するための良い選択肢となる可能性があります。

生産速度が重要な場合:

Google と Azure はどちらも、モデルを本番環境にデプロイする簡単な方法を提供しています。たとえば、Google Cloud を使用すると、ユーザーは数回クリックするだけでバッチ予測とオンライン予測をすばやく実装できます。また、ユーザーは API を通じてモデルを独自の Web サイトにデプロイすることもできます。これらの機能により、データ サイエンティストは生産を大幅にスピードアップし、実際の作業負荷を軽減できるようになります。

時間が限られている場合:

データ サイエンティストにはやるべき仕事がたくさんあるため、彼らの時間は極めて重要です。データ サイエンティストは、日々の業務で、既存のモデルの維持、データの収集/クリーニング、次の会議の準備などのために、製品マネージャー、ビジネス リーダー、従業員、顧客が主催する無数の会議に出席する必要があります。したがって、AutoML は時間を節約するための重要なツールになります。数回のクリックと数ドルで、一定のパフォーマンスを持つモデルをトレーニングできます。このようにして、誰もが最も価値の高い重要なタスクの処理に集中できます (場合によっては、PPT をより美しくすることの方が、モデルの精度を 1% 向上させることよりもはるかに重要な場合があります)。