RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

トップ > かみせん > 機械学習をコモディティ化する AutoML ツールの評価

機械学習をコモディティ化する AutoML ツールの評価

かみせん 機械学習

こんにちは、開発エンジニアの amdaba_sk（ペンネーム未定）です。

昨年度まで、ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「開（か）発の未（み）来に先（せん）手をうつプロジェクト（通称：かみせんプロジェクト）」というプロジェクトがありました。本年度からは規模を拡大し、「技術推進プロジェクト」と名称を改めて再スタートされました。

本記事では、昨年度かみせんプロジェクトとしての最後のテーマとなった機械学習テーマの延長として 2020 年度上期に行った「AutoML ツールの調査と評価」について取り組み結果を報告します。 （ちなみに機械学習テーマは前年度から継続していたこともあり、上期で終了となってしまいました。残念……）

なお過去の報告記事はかみせんカテゴリからどうぞ。技術推進プロジェクトでは機械学習だけではなく、他にもいろいろなテーマで検証を行っています。どれも面白そうなテーマですので是非そちらの報告もご覧ください。

tech-blog.rakus.co.jp

はじめに

AutoML とは、簡単に言えば機械学習のプロセスを自動化し、データセットと最重要視する評価指標を指定するだけで最適なモデルを構築する仕組みのことです。

機械学習を使用して良いパフォーマンスを得るためには、通常、データ収集、特徴量エンジニアリング、モデルやアルゴリズムの選択といった作業に人手による試行錯誤が必要となり、コストがかかります。AutoML では、Figure 1 に示すように機械学習アプリケーションの構築パイプラインの一部を自動化することで、手動でのモデル学習よりも高い性能を持つ機械学習モデルの効率的な構築を目指します。

Figure 1. 機械学習アプリケーションの典型的なパイプラインと AutoML の活用範囲（Q. Yao, et al., "`Taking the Human out of Learning Applications: A Survey on Automated Machine Learning`" より引用）

今回の技術推進プロジェクトでは、そんな便利そうな AutoML を、公開されたデータセットに対して実際に使ってみることで、効率的にモデル学習ができることを確かめました。また AutoML を提供するサービス、ライブラリを複数試用し、それぞれを比べてみました。

検証の方法

特定のデータセットについて、選定したサービスやライブラリを用いて実際にモデル学習を行い、モデル学習のための作業時間と得られたモデルの性能について調べました。また同じデータセットについて、従来の方法でモデル学習スクリプトを作成し、その作業時間と得られたモデルの性能を AutoML を使用した場合の結果と比較しました。

データセット

検証のためのデータセットとして Bank marketing データセットを用いました。

このデータセットはクリエイティブ・コモンズ CC0: Public Domain のライセンスで利用できるオープンデータであり、テーブル形式になっています。

今回検証の対象としたサービスの中にはデータセットの最小サイズが設定されているものがあり、有名な Titanic dataset や Iris flower dataset はサイズが足りずに使うことが出来ませんでした。Bank marketing は 後述する Google Cloud AutoML Tables のチュートリアルで用いられているデータセットであり、サイズも充分であるためこれを用いました。

Bank marketing データセットはポルトガルのとある銀行が行ったダイレクトマーケティングキャンペーンの結果です。職業、年齢などの顧客データとキャンペーン商品を購入したかどうかが記録されています。

Table 2 に示したようにクラスごとのデータ件数にはかなりの偏りがあるデータです。

  • データ件数 :: 45211 件

Table 1. カラム情報

No. カラム名 データタイプ 説明
1 age 数値 年齢
2 job カテゴリ 職業の種類
3 marital カテゴリ 婚姻状態
4 education カテゴリ 学歴
5 default カテゴリ 債務不履行の有無
6 balance 数値 年平均残高（ユーロ）
7 housing カテゴリ 住宅ローンの有無
8 loan カテゴリ 個人ローンの有無
9 contact カテゴリ 連絡先端末の種類
10 day 数値 月の最後の連絡日
11 month カテゴリ 年の最後の連絡月
12 duration 数値 最後の連絡時の通話時間（秒） 1
13 campaign 数値 キャンペーン中の連絡回数
14 pdays 数値 前回のキャンペーンでの最後の連絡からの経過日数
15 previous 数値 前回のキャンペーンでの連絡回数
16 poutcome カテゴリ 前回のキャンペーンでの結果
17 y バイナリ 顧客が定期預金に加入したかどうか（1 : 非加入、2 : 加入）

Table 2. クラスごとの件数比率

クラス 件数 比率
1 39922 0.88
2 5289 0.12

モデル学習の従来手法について

従来手法として、以下の工程を経てモデル学習と性能指標の算出を行うスクリプトを自作しました。

  1. データセットの読み込み
  2. データの前処理
    • 使用するデータ列の取捨選択
    • カテゴリデータのダミー変数化
    • 数値データの整形
  3. 学習データとテストデータの分割
  4. モデル学習
    • 学習データに対する CV 検証を用いたハイパーパラメータ調節
    • 調整されたハイパーパラメータでの学習データによる学習
  5. テストデータによる性能測定

言語は Python 3 を用いました。ライブラリとして Pandas、scikit-learn を用い、Jupyter Notebook として作成しました。データセットは CSV ファイル形式で作成しておき、スクリプト内で読み込んで使用しました。

また 4 のモデル学習の際、いくつかのアルゴリズムで学習したモデルの性能を比較し、最も高い性能を示したアルゴリズムを結果として採用しました。その際の候補となる学習アルゴリズムは scikit-learn のアルゴリズム選定チートシートをもとに第一候補を決め、加えてよく用いられる代表的なアルゴリズムを選びました。最終的に試したアルゴリズムは以下の通りです。

今回使用するデータセットは前述の通り偏りが大きいため、ハイパーパラメータ調整と各アルゴリズムでのモデルの性能比較において正答率ではなく F1 値のマクロ平均を最適化の基準として用いています。

調査対象とした AutoML サービス

クラウドサービスを使って AutoML を行う例として、以下の 4 つのサービスを試しました。

AutoML の実行の際、最適化の基準となる指標には F1 値ないしそれに近い用途の指標を用いました。他の設定は各サービスのデフォルトの設定のまま行っています。サービスによっては F1 値が選択できないものもあり、そのためサービスごとに異なる指標が最適化の基準として用いることになりました。

調査対象とした AutoML ライブラリ

ライブラリを使って AutoML を行う例として、以下の 4 つのライブラリを試しました。

ライブラリについてもサービスの場合と同様、最適化の基準となる指標には F1 値ないしそれに近い用途の指標を用いました。他の設定は各ライブラリのデフォルトの設定のままで行っています。ライブラリによっては F1 値が選択できないものもあり、そのためライブラリごとに異なる指標が最適化の基準として用いることになりました。

結果

モデル学習の作業時間と性能

Table 3 に今回試した各手法での作業時間（時間）、最良モデルのアルゴリズム、基準とした評価指標、最良モデルの正答率、F1 値マクロ平均をまとめました。以下、この結果をひとつずつ見ていきます。

Table 3 モデル学習の結果。「Kaggle 投稿」は本検証で用いたものと同一のデータセットに対して Kaggle に投稿された従来手法でのモデル学習結果。H. Yamahata, "Bank Marketing + Classification + ROC,F1,RECALL..." より引用

エントリー 作業時間 (h) 基準指標 最良アルゴリズム 正答率 F1 値マクロ平均
従来手法
自作スクリプト 2.5 F1 値マクロ平均 GNB 0.80 0.58
Kaggle 投稿 - 適合率 KNN 0.90 0.88
AutoML クラウドサービス
Amazon SageMaker AutoPilot < 1.0 F1 値マクロ平均 XGBoost N/A 0.71
Google Cloud AutoML Tables < 0.5 AUC ROC GDBT 0.90 0.65
IBM Watson Studio AutoAI < 0.5 F1 値マクロ平均 XGB 分類器 0.88 0.70
Microsoft Azure AutoML < 0.5 加重 AUC ROC VotingEnsemble 0.89 0.61
AutoML ライブラリ
auto-sklearn < 2.0 F1 値マクロ平均 Weighted Ensemble 0.86 0.68
H2O.ai < 1.0 AUC ROC StackedEnsemble 0.87 0.72
TransmogrifAI < 2.0 AUC ROC XGBoost 0.90 0.65
AutoKeras < 0.5 F1 値マクロ平均 深層学習 0.89 0.72
従来手法

従来手法でスクリプトを自作した場合の作業時間はおよそ 2.5 時間でした。この時間には Python の書き方の復習や Pandas および scikit-learn の API を確認する時間も含まれています。それによって得られた最良のモデルはガウスモデル単純ベイズ分類器によるもので、正答率 が 0.88、F1 値マクロ平均は 0.58 でした。

AutoML クラウドサービス

AutoML サービスを用いた場合の作業時間にはアカウントの開設などの周辺作業のための時間は含めていませんが、AutoML の実行に関する操作や設定項目の確認は作業時間に含まれています。

Amazon SageMaker AutoPilot を使った場合の作業時間はおよそ 1 時間以内でした。また得られた最良のモデルは XGBoost によるもので、F1 値マクロ平均は 0.70 でした。最適化の基準として F1 値マクロ平均 を用いました。正答率は画面から確認する術を見つけられませんでした術

Google Cloud AutoML Tables を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは勾配ブーストディシジョンツリーモデル（GDBT）によるもので、正答率 が 0.90、F1 値マクロ平均は 0.65 でした。最適化の基準として AUC ROC を用いました。

IBM Watson Studio AutoAI を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは XGB 分類器によるもので、正答率 が 0.88、F1 値マクロ平均は 0.70 でした。最適化の基準として F1 値マクロ平均を用いました。

Microsoft Azure AutoML を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは StackEnsemble によるもので、正答率 が 0.89、F1 値マクロ平均は 0.61 でした。最適化の基準としては加重 AUC ROC を用いました。

AutoML ライブラリ

AutoML ライブラリを用いた場合の作業時間にはライブラリの実行環境を構築するための時間は含まれていませんが、ライブラリの使い方の確認などの調査の時間は含まれています。

auto-sklearn を使った場合の作業時間は 1 - 2 時間程度でした。また得られた最良のモデルは正答率 が 0.86、F1 値マクロ平均は 0.68 でした。最適化の基準として F1 値マクロ平均を用いました。なお auto-sklearn はアルゴリズムとして常に Weighted Ensemble を用いるようになっています。得られた最良のモデルでアンサンブルに使われたアルゴリズムとそれぞれの重み係数は Table 4 のようになっていました。

Table 4 auto-sklearn の最良モデルにおける Weighted Ensemble の詳細

重み アルゴリズム
0.82 sgd
0.04 random_forest
0.02 random_forest
0.02 random_forest
0.02 random_forest
0.02 random_forest
0.02 gradient_boosting
0.02 adaboost
0.02 extra_trees

H2O.ai を使った場合の作業時間はおよそ 1 時間以内でした。また得られた最良のモデルは StackedEnsemble によるもので、正答率 が 0.87、F1 値マクロ平均は 0.72 でした。最適化の基準として AUC ROC を用いました。

TransmogrifAI を使った場合の作業時間は 1 - 2 時間程度でした。また得られた最良のモデルは XGBoost によるもので、正答率 が 0.89、F1 値マクロ平均は 0.65 でした。最適化の基準として F1 値マクロ平均を用いました。

AutoKeras を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは正答率 が 0.89、F1 値マクロ平均は 0.72 でした。最適化の基準として F1 値マクロ平均を用いました。

考察と所感

従来手法と AutoML

自作スクリプトの従来手法で得られたモデルと AutoML で得られたモデルを比較した場合、正答率や F1 値マクロ平均といった性能指標で AutoML で得たモデルの方が良い性能を示しました。一方で Kaggle に投稿されたモデルと AutoML で得られたモデルを比較すると、AutoML で得たモデルの性能は F1 値マクロ平均で大きく劣っていました。AutoML による機械的なモデル探索によりある程度の性能までは達成できることが分かりますが、いまだそこには限界があり、経験を積んだデータサイエンティストには敵わないようです。ただしこの記事によると、他のデータセット、問題設定によっては Kaggle 投稿のモデルよりもよい性能を示すモデルが構築されるようです。AutoML にも得手不得手があることが分かります。

モデル学習の実行までにかかる作業時間を比較すると、従来手法は AutoML サービスを利用した場合の 2 倍以上、AutoML ライブラリを用いた場合の 1.5 倍程度の作業時間を要しています。従来手法でも scikit-learn の API を用いてかなりの部分が自動化されているとは言え、アルゴリズムの選定やハイパーパラメータ候補セットの検討、それらの記述にどうしても時間がかかりました。一方で AutoML では従来手法で時間を要したそれらの工程が自動化されており、作業時間が短縮できています。

AutoML サービスとライブラリの比較

AutoML で得られたモデルの内、クラウドサービスを利用して構築したものとライブラリを利用して構築したものを比較すると、正答率や F1 値マクロ平均といった性能指標では大きな差は見られませんでした。

モデル学習の実行までにかかる作業時間を比較すると、クラウドサービスを利用した場合はライブラリを利用した場合の半分程度の時間で作業を終えることが出来ています。クラウドサービスは多くの場合、データ前処理、特徴量エンジニアリングの自動化もなされており、サービスが受け付けられる形式でデータセットを用意すれば、後は数ステップの GUI 操作によってモデル学習を実行できます。一方でライブラリではデータ前処理部分は自分でコードを記述し実装しなければならず、その点でクラウドサービスよりも時間がかかりました。

クラウドサービスとライブラリでは、モデル性能や作業時間の違いはさほど大きな問題ではなく、むしろ学習の実行環境にこそ違いがあるように思われます。

クラウドサービスであれば数クリックで計算リソースの確保ができます。予算があれば高性能なインスタンスを選択し短時間で学習を終わらせることもできるでしょう。一方でライブラリは実行環境は自前で用意することになります。より速い計算速度、より大きなメモリが必要となった場合に即調達できるとは限りません。

一方でデータセットをクラウド上にアップロードすることが諸事情によりどうしても許容できないとなった場合は、クラウドサービスはそもそも使用できません。この場合はライブラリを使うことで対処することになると考えられます。

AutoML サービス間の比較

AutoML サービスで得られたモデル同士を比較した場合、正答率はどれも 0.9 程度とあまり違いは見られず、F1 値マクロ平均で見ても 0.1 程度の差しかありませんでした。モデル学習の実行までにかかる作業時間も、どのサービスを用いたとしても 30 分か 1 時間以内には終了しており顕著な差は見られません。

ただ各サービスごとに機能のラインナップや画面デザインに違いがあり、プロジェクトやチームごとの重視するポイントによって最適な選択は異なると考えられます。以下ではこれらのサービスの長所や短所の所感を述べます。

Table 5. 機能比較表 / 学習時の機能; ○：対応、△：一部対応、×：非対応

サービス 前処理の自動化 統計情報の表示 特徴量の自動作成 交差検証
Amazon SageMaker AutoPilot ○ △ ○ ○
Google Cloud AutoML Tables ○ ○ ○ ○
IBM Watson Studio AutoAI ○ △ ○ ○
Microsoft Azure AutoML ○ ○ ○ ○

Table 6. 機能比較表 / 評価時の機能; ○：対応、△：一部対応、×：非対応

サービス 特徴量の寄与率表示 結果の可視化 学習済みモデルのダウンロード API 接続先の作成
Amazon SageMaker AutoPilot △ △ ○ ○
Google Cloud AutoML Tables ○ ○ ○ ○
IBM Watson Studio AutoAI ○ ○ ○ ○
Microsoft Azure AutoML ○ ○ ○ ○
Amazon SageMaker AutoPilot

Amazon SageMaker AutoPilot は UI からできることがあまりなく、ローコード・ノーコードという観点からは使いにくさを感じました。しかしコードを読み書きする前提に立てば、AutoML の実行コードが記述された Notebook が生成されるため、解釈性やカスタマイズ性が高いとも言えます。検証作業時に確認方法のわからなかった正答率など最適化基準ではない性能指標も、Notebook を変更すれば実行ログから確認できるだろうと思われます。データサイエンティストとして知識を持った人をターゲットに、その作業を簡略化することを目的とするサービスだと感じました。

長所

  • AutoML 実行用の Notebook が生成される
    • Notebook を編集することで細かなカスタマイズができる
    • Notebook には説明が豊富に記載される（英語）

短所

  • データが 1000 件以上必要
  • データセットの管理が SageMaker 単体で完結できない（S3 が別途必要）
  • UI からできることが少なく、作業フローがわかりにくい
  • 手動でリソースを閉じる必要がある（閉じ忘れると課金される）
  • Amazon SageMaker AutoPilot はプレビュー版であり、使えるリージョンが限られる
Google Cloud AutoML Tables

Google Cloud AutoML Tables は GCP でいくつか提供されている AutoML サービスの一つで、テーブル形式のデータを扱うことに特化した AutoML サービスです。データセットのインポート、学習の設定、実行、モデルの評価の確認、デプロイまで GUI で操作できます。各画面もシンプルな構成になっており、わかりやすいと感じました。ただシンプルな反面、モデルの構造など画面上から確認できる情報は他サービスと比べ少ないように思います。

長所

  • 同じモデルで判定の閾値を変えた場合の性能指標が見られる
  • 処理完了をメールで通知してくれる
  • ドキュメントが丁寧かつ豊富

短所

  • データが 1000 件以上必要(分類ならさらにクラスごとに 20 件以上必要)
  • モデルの内部構造を確認するために別サービス（Cloud Logging）を利用して生のログを見なければならない
  • Google Cloud AutoML Tables はベータ版
IBM Watson Studio AutoAI

IBM Watson Studio AutoAI は今回対象としたサービスの中では唯一正式サービスとして提供されています。データセットのインポート、学習の設定、実行、モデルの評価の確認、デプロイまで GUI で操作できます。各画面もシンプルな構成になっており、わかりやすいです。

学習ジョブの進行状況やモデルがツリー状の UI でグラフィカルに表現されている点が特徴的で、学習のどの段階でどのようなモデルが試されたのかを視覚的に把握できるようになっています。また特徴量エンジニアリングでどのカラムにどのような変換がなされたのかが確認でき、学習済みモデルを説明するための情報が豊富だと感じました。一方で特徴量エンジニアリングの変換では非合理的な変換が行われているように感じる部分もあり、不安になってしまうことがあります。

長所

  • グラフィカルな表現でわかりやすい
  • 特徴量エンジニアリングの詳細が確認できる
  • IBM Watson Studio AutoAI は正式サービス

短所

  • 特徴量の変換が非合理的に思えることがある
Microsoft Azure AutoML

Microsoft Azure AutoML もデータセットのインポート、学習の設定、実行、モデルの評価の確認、デプロイまで GUI で操作できまする。データセットの指定から学習の実行までは、フロー状の UI で設定ステップが示されており、今回対象としたサービスの中で最もわかりやすいと感じました。逆にモデルの評価画面は初見では少しわかりにくいと感じるかもしれません。表示される情報は豊富だが、ほしい情報がどこにあるのかが少し探しにくいように思えます。

また特徴的な機能として、学習に使用したデータセットの品質を評価してくれるデータガードレールという機能があります。Amazon SageMaker AutoPilot や Google Cloud AutoML Tables のようなデータセットに関する制約ではなく、データセットに含まれる欠損値やクラス不均衡といった問題を検出し警告してくれることで、データセットの品質改善に役立ち、かつ実行の手軽さも保っていると思います。

長所

  • 学習実行条件を細かく指定できる
  • データセット自体の問題を検出してくれる
  • モデル性能評価のグラフが豊富

短所

  • 出力されるモデル性能が他サービスと比べ少し悪い
  • Microsoft Azure AutoML はプレビュー版
AutoML ライブラリ間の比較

AutoML ライブラリで得られたモデル同士を比較した場合も、クラウドサービスの場合と同じく性能的な違いはあまり見られません。モデル学習の実行までにかかる作業時間も、どのライブラリを用いたとしても 2 時間以内には終了しました。

ただやはり各ライブラリごとに特徴があり、プロジェクトやチームごとの重視するポイントによって最適な選択は異なると考えられます。以下ではこれらのライブラリの長所や短所の所感を述べます。

Table 7. 機能比較表 / 学習時の機能; ○：対応、△：一部対応、×：非対応

ライブラリ 前処理の自動化 統計情報の表示 特徴量の自動作成 交差検証
auto-sklearn △ × × 〇
H2O.ai △ × × 〇
TransmogrifAi △ × △ 〇
AutoKeras 〇 × × 〇

Table 8. 機能比較表 / 評価時の機能; ○：対応、△：一部対応、×：非対応

ライブラリ 特徴量の寄与率表示 結果の可視化 サマリの表示
auto-sklearn × × △
H2O.ai 〇 〇 〇
TransmogrifAi 〇 × 〇
AutoKeras × × △
auto-sklearn

auto-sklearn は scikit-learn をベースにしており、インターフェースも基本的に scikit-learn と同じです。そのため scikit-learn に慣れた人間であれば最もとっつきやすくなっていると思われます。

一方で auto-sklearn は入力データが全て数値でなければならないという制約があり、文字列データは全て手動で数値に変換してからでないと学習を実行できないため、他のライブラリに比べて手軽に試すにはややハードルが高いと感じました。

長所

  • scikit-learn と同じインターフェースなのでわかりやすい

短所

  • 文字列データを受け付けない（カテゴリデータは数値に変換が必要）
  • アンサンブルに使われたアルゴリズムの取得方法が公式に用意されていない（プライベート API を使えば可能）
H2O.ai

H2O.ai は Java で実装されたバックエンドを Python、R、REST API、Java、Scala などから操作する機械学習プラットフォームです。ライブラリという枠とはすこし異なりますが、Python などでスクリプトを作成することになるという点でライブラリの一つとして取り上げました。

AutoML ライブラリとして見た場合、他のライブラリに比べ評価指標の取得・可視化が簡単で、情報量が多いという点が特徴です。モデルの評価指標を調べる場合にも、コード 1 行で各種評価指標と混同行列が出力できます。ROC 曲線や特徴量重要度などのプロットは、他のライブラリであれば matplotlib 等の別ライブラリを用いることになりますが、H2O.ai の場合は単体で簡単にプロットが可能です。

長所

  • 複数の言語の SDK がある
  • 結果の可視化が簡単

短所

  • scikit-learn ほど流行っていない
TransmogrifAI

TransmogrifAI は Salesforce が開発しているオープンソースの AutoML ライブラリで、Apache Spark 上で AutoML を実行できるライブラリです。実装言語は Scala です。ビッグデータ解析などで使用されている Spark 上でそのまま AutoML を構築できるのが強みとされています。サポートする機能は特徴量エンジニアリング、モデル選択、ハイパーパラメータチューニングと、AutoML の基本的な機能は網羅しています。

使用した所感としては、ライブラリというよりもむしろ言語ならではのメリットが大きいと感じました。データセットの型や特徴量のタイプの指定などで型システムの恩恵を受けることができることや、IDE の支援を手厚く受けられます。型が定義されていることでデータセットの持つプロパティが補完される点は、Python にはない利点であると思います。実行環境の構築には多少手間がかかりますが、Spark をバックエンドにした Notebook である Apache Zeppelin を使用すれば、Jupyter Notebook のような形で開発を進めることも可能です。チームやプロジェクトの置かれた環境次第では十分に選択肢に入るだろうと感じました。

長所

  • 特徴量触るのが簡単
  • 結果の説明がやさしい

短所

  • 細かいチューニングを行うにはライブラリに習熟する必要がある
  • それなりにボイラープレートは多い
  • Spark を使うので環境構築はそれなりに面倒
AutoKeras

AutoKeras は深層学習のライブラリである Keras のハイパーパラメータチューニングを自動化するライブラリです。今回試した他のライブラリとは異なり深層学習であるため、得られる情報が少ないという点が気になりました。また深層学習であるがゆえにモデルの説明可能性などは考慮されていないようです。実際にどのような処理をしているかなどは意識しないように作られているように感じました。一方、試行回数を増やすことで探索を続けることができるため、リソースや時間があればある程度正確なモデルは作成できる可能性があるとも思われます。

長所

  • 少ないコードで実装できる

短所

  • 精度を上げるにはそれなりの前処理が必要
  • 特徴量エンジニアリングはしてくれない
  • 出力されるメトリクスが少ない
  • 学習結果のばらつきが多い

まとめ

公開されたデータセットを用いて学習スクリプトの自作と AutoML によるモデル学習とを行い、両者の作業時間、生成される学習モデルの性能を比べました。また AutoML を提供するサービス、ライブラリを複数試用し、それぞれの長所や短所を調べました。

AutoML は従来手法と比べ、やはり作業効率の点で大きく優れていることが分かりました。一方で構築されるモデルの性能については、データセットや問題設定によって得手不得手があるだろうことが分かりました。目的変数のサンプル数に偏りがあるようなデータセットでは、ある程度までは AutoML で従来手法よりもよい性能のモデルが得られますが、作業者にデータ分析の十分なスキルがある場合は従来手法でモデルを構築したほうが良い性能のモデルが得られるようです。

AutoML を利用する場合、クラウドサービスとライブラリを比べるとクラウドサービスの方がグラフィカルな UI で直観的に操作できる分、作業時間はかかりません。またクラウドサービスは特徴量エンジニアリングまで自動化されていることが多いですが、ライブラリではデータの前処理部分を自前で実装しなければならず、その点でも作業時間に差があります。

参考

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.