sam_yusukeの日記

機械学習について書きます。

データセットのロードや前処理まとめ

自分で収集したデータを使いSkorchやPytorchで学習や評価をさせるのに必要な知識をまとめます。

 

データセットを扱う際の機械学習の基本的な知識

データセット強化の意味と注意点

 機械学習では、テストセットと学習セットがi.i.dに生成されていると仮定されています。となると、データセット強化の意味は学習セットの標本では表現しきれない本来の分布を表現できるように既存の標本から新しい標本を作ることです。図の誤差1を減らす作業に相当すると思います。なので、本来の分布を意識してデータセット強化を考えるべきです。また、誤差2に関しては何度か実行した結果の平均をとったりなどして減らせるのではないかと思います。(数学的にどうなのか調べる。)

 また、データセット強化が正しく元の分布を表現できてることを性能指標の計算に反映するために、テストセットにはデータセット強化を適用しないほうが良いことも想像出来ます。

f:id:sam_yusuke:20181212125531p:plain

 

データの標準化・中心化

基本的に入力データには何らかの処理をします。

画像の場合は中心化すれば十分なようですが、それぞれの特徴量の分散が大きく異なる場合は標準化する必要もありそうです。

標準化・中心化する際の統計量はテストセットや学習セットを生成する本来の分布であるべきなので(数学的に)訓練データと評価データに対して計算するべきかと想います。(できる限り本来の分布の統計量を再現できるように)

 

データセットを扱う際の実装上の基本的な知識

データセットを扱う場合、Linux上かつ大きいメモリ上であればページングがうまく行って、大体データセットはキャッシュされている。心配ならvmtouchなどのツールを使って調べたりキャッシュさせればよいです。

また、Pythonでデータセットに対する処理を並列化する場合、結果が大きいとpickle+unpickleのオーバーヘッドが大きくなって、より多くの時間がかかることがあります。分散化させたい処理の入出力を小さくしたり、分散化されている処理にできるだけ処理を詰め込む工夫が必要になります。

 

データセットに関するライブラリの機能

クラスや関数をざっと説明します。

Pytorch/Torchvision

DataSetクラス

データセットを表すクラスです。独自データセットを扱う場合は、

画像の多クラス分類ならImageFolder、任意のデータの多クラス分類ならDatasetFolder、他クラス多ラベル問題ならなどその他の問題の場合はDatasetクラスを継承して、__len__, __getitem__メソッドを実装すれば良さそうです。

また、Datasetをtorch.util.data.Subsetで部分集合をとったり、, torch.util.data.ConcatDatasetで結合したりも可能です。

(このあたりはもう少し今後便利になることを期待したいです。)

DataLoaderクラス

データセットをシャフルしたりしてバッチにしてくれるクラスです。

ただ、並列ロードは曲者で、TensorDatasetに使うと、pickle/unpickleが遅くなるという問題などもあり、自前で実装したり、並列化をしないほうが早いこともあると思います。

Skorch

PytorchのDatasetクラスをImageClassifierなどに渡してそのまま使えます。

データセットのロード部分はPytorchとSkorchでうまく共通化できそうで、

さすが親和性も高そうです。

OSSのAutoML AutokerasでCifar100タスクを学習

前回のCifar10に引き続き、Autokerasを使ってCifar100タスクの学習もやってみました。

実験に使ったソースコードcifar10のものに少しパラメータを追加してsacred対応したものです。

 

探索の進み方を見る

それぞれの畳み込みネットワークの学習にかける最大エポック数は7に設定し、20時間なんどか学習させてみたところ、探索1サイクルごとの正解率の変化は7割程度まで到達しました。resnetcifar100に適用した場合は160層程度で約75%の正解率だったようなので、まぁまぁ健闘しているように思えます。

この正解率が近いので探索の進み方は似ているのでは?ということです。

おそらく、acquisition functionによる次の探索ポイントの決定が確率的だが、結果として同じような成果が出ているということなのでしょう。探索の上限が同じ20時間かけているにもかかわらず、探索された構造が10個位上違うのは性能が似ているが学習に時間がかかる構造が選択されているから?それとも探索打ち切り周りにバグがあるから?このあたりはソースコードを読む必要がありそうです。

f:id:sam_yusuke:20181211204301p:plain

 

最大レイヤ数を変えてみた場合の性能の違い

探索範囲の最大レイヤ数を増やすことで、より高い性能のニューラルネットを発見できることが期待できます。やってみたところ、レイヤ数100くらいで性能が最も高くなっているような気がします。(まだ、データ数が少ないのでわからない。)

探索の上限時間が固定であれば、探索範囲が広くなりすぎると、逆に性能が劣化するという解釈もできますが、探索方法によるため原因は不明です。(例えば、最適化手法の勾配探索では、探索範囲の広さよりも、関数の形のほうが探索時間に影響しそうです。)

f:id:sam_yusuke:20181211204359p:plain

 

探索一回あたりの最大エポック数を変化させた場合

アーキテクチャ探索のパラメータではないが、探索する際の最大エポック数を上げて試してみました。最大エポック数を上げることで、探索数が増えています。

最大エポック数を30まで上げると、振動している様子が見えて、ベイズ最適化による探索が出来ているような気がします。

f:id:sam_yusuke:20181211204424p:plain

 

まとめ

探索範囲や探索アルゴリズムのパラメータだけでなく、学習の仕方も自動的に色々と変えてくれなければアーキテクチャ探索アルゴリズムで探索する際の手間が増えます。利用するには何らかの工夫が必要な気がします。例えば、目標性能を設定して、n時間工夫して出来なければ探索範囲を緩和したり、学習の仕方を変えるなどと行った方法が必要かもしれません。学習の仕方はハイパーパラメータとして本来は探索すべきな気もします。

 

組織などで内製AutoMLとして導入する場合、探索アルゴリズムのパラメータの調整、フロントエンドの開発、計算クラスタの準備や運用などが必要となりそうです。

その場合に重要なのは機械学習の専門知識を持った開発者も当然ですが、機械学習の試行錯誤を低コストでするために安価に計算クラスタを構築運用できる人も重要になりそうです。

5.2 モデルをデータに合わせる:Capacity, Overfitting, Underfitting

ディープラーニング.2

モデルの選択、データセットの収集をする際に必要になる基礎的な話でした。

モデルの表現力であるCapacity、回帰タスクに下げる対象であるGeneralization誤差、テストデータセットのサイズの関係とそれぞれの詳細について述べられています。

ディープラーニングのモデルの性能を改善させていくために参考になる基礎知識だと思います。データセットを増やすべきか、モデルを変更すべきか、どのモデルに帰るべきか判断する際の参考になると思います。

 

統計的機械学習に置かれている仮定

f:id:sam_yusuke:20181209042134p:plain

機械学習で置かれている仮定は「訓練データと評価データはi.i.d」ということで、この過程が満たされていることで訓練データを使って未知データに対応できるモデルを学習できます。(本書内のtest errorの定義がわかりませんが、アプリを適用する先の未知のデータもi.i.dであると仮定しているはずです)i.i.dを仮定することで、

  • 同じパラメータのモデルの訓練誤差と評価誤差の期待値は同じ
    • → 十分に多いデータがあれば、両方の誤差平均はほぼ同じ
  • 評価誤差と未知のデータに対する誤差の期待値はほぼ同じ

回帰タスクの文脈で書かれている章なので、誤差という言葉が使われていましたが、accuracyF scoreでも同様です。

 

underfittingoverfitting

実際のモデルの学習では、訓練誤差を計算し、訓練誤差を下げるようにパラメータを少し調整するということを繰り返しをし、(SGDなどの最適化手法)、調整のたびに評価誤差を記録していく、評価誤差は訓練誤差よりも大きくなるとのことです。(理由不明。i.i.dならパラメタ調整後の評価誤差のほうが低くなりそうですが、おそらく、標本を使うことから来る誤差が原因?)

 

この訓練誤差と評価誤差の差が大きい状態をoverfitging, 訓練誤差が大きい状態をunderfittingと呼びます。

  • underfittingを防ぐにはタスクの複雑さにあったCapacityのモデルを選択する
  • overfittingを防ぐには訓練データの量にあった大きすぎないCapacityを選び、必要に応じてデータ収集が必要になります。

訓練誤差の差には下限があり、モデルのcapacityと訓練データの数によって決まってくるとのことです。また、モデルのcapacityはタスクの複雑さによって決まるらしいです。

従来ディープラーニングでは、非凸最適化の理論的な理解が難しかったことが原因でモデルの実効表現力が低かったのが問題でCapacityの選択が困難でした。(学習ができないのにCapacityの選択ができるはずがない。)

 

データ量、CapacityOverfittingUnderfittingの関係

これらの関係に関する面白い図があったので載せておきます。

 f:id:sam_yusuke:20181209042300p:plain

多項式モデルで次数を大きくする(Capacityを大きくするに相当)と、評価誤差はU字を描く。(おそらく)このU次は似たようなモデルのCapacityを変更場合に成り立ち、このCapacityの選択と(同じCapacityでも構造が違うネットワークの選択)がモデルを選択する作業となる。

 

f:id:sam_yusuke:20181209042241p:plain

データを十分に集めると訓練誤差は上がり、評価誤差は下がる。

双方ともベイズ誤差に近づく。

この中でも、Capacityやモデルの選択に関しては、ベイズ最適化や強化学習で自動化する手法が出てきていてGoogleはAutoML、オープンソースのものではAutokerasが出てきている。また、学習についてもOverfittingが発生した時点で学習をやめる方法などもある。まだ自動化がされていないのはデータ収集の必要、不要の判断な気がします。(調査必要)

一人用簡単な機械学習の実験結果と実験スクリプトジョブ管理環境を構築

背景

機械学習アルゴリズムを開発していると、複数サーバーを使って学習したり検証したりすることになります。その際に、

  • 複数の異なる引数で同じスクリプトを空いているサーバで実行するのが手間。
  • サーバーが空いたか定期的に確認して、空いたサーバーでスクリプトを実行するのが手間
  • 過去のスクリプトの実行結果を探すのが手間

といったことがあったため、今回、暫定的に対処してみた。

解決法として挙げられるのは

  1. 実行したいスクリプトの数に応じて、AWSインスタンスを起動。AnsibleやDockerで自動的に環境構築して、その上で実行する。不要になったらインスタンスを落とす。
  2. インスタンス数固定で実行したいスクリプトをキューで待たせて、空いたインスタンスに自動的に割当てる。
  3. 1インスタンス数上限付き

今回は2にしました。2を選択することで最悪サーバの構築を手作業でできること、AWSインスタンス立ち上げやサーバ構築PlaybookやDockerfileのメンテナンスが最悪不要なことが挙げられます。また、機械学習の基盤に関して考える機会をもちたいので今回は自前で構築します。

 

簡単な説明

スクリプト実行状況と結果の確認

f:id:sam_yusuke:20181207134534p:plain

実行中のジョブやジョブの終了の確認ができるので少し便利になりました。

指定の辞書オブジェクトにキーを追加すると、詳細情報タブに追加されるので、

そこに、指定したパラメータや結果ファイルのパスなども入れれば少し便利になりそうです。検索周りが少し弱いですが、

スクリプトの実行

 f:id:sam_yusuke:20181207134559p:plain

 

Jupyterで実験ごとに実行スクリプトの定義とパラメータを書いて実行するようにしています。

結果の分析

f:id:sam_yusuke:20181207134647p:plain

Jupyterでpandasのデータフレーム形式で結果を取れるようにして、分析作業をするようにしています。

 

サーバの構成

f:id:sam_yusuke:20181207134615p:plain

実行用サーバが複数あり、管理サーバーがある。

管理サーバは

  • 実行用サーバから実験結果の収集
  • Jupyterによる分析環境の提供
  • 実行スクリプトCeleryによるキューイングと実行サーバへの割り当て
  • デバッグ環境

という感じです

 

このシステムは一人で分析に使うには十分ですが、複数人で利用するには、

  • サーバのリソース管理が非効率(1サーバ1スクリプト
  • ジョブキューの高速化・安定化
  • ユーザ管理、ユーザ作成時のユーザ用環境構築
  • セキュリティ(ユーザ間、サーバ管理者とユーザ)
  • Dockerとかである程度スケールするようにする。

などなど様々な課題はあります。

よく知られた深層学習手法の独自アプリへの適用を目指して(Deep Learning Chapter 11)

この章では、機械学習を使ったシステムを構築する際のアプローチとテクニックを紹介しています。この記事は11章の内容を独自アプリ用にNNモデルを作ることをゴールにして、ざっくりまとめたものになります。

機械学習システム構築時のアプローチ(推奨)

  1. アプリのゴールに合わせて評価指標と指標の値のゴールを設定する
  2. データ収集から評価までのEndToEndのシステムを構築。(ベースラインとなる程度のアルゴリズム
  3. 内部の状態とか調査して、パフォーマンス上のボトルネックを探す
    • どのコンポーネントが期待以下か?
    • それは、データの問題?バグ?underfitting? overfitting?
  4. 上記の調査結果に基づき繰り返し改善の手を打っていく

どのプロセスも重要ですが、深層学習では学習に時間がかかったり、データ収集にも時間がかかります。どの改善の手をうつべきか見極める3, 4の質は最終性能に大きく影響を与えそうですし、1を正しく行わなければほしくないものができてしまいそうです。
(この記事では2までカバーしています)

パフォーマンス指標の決定

評価指標が機械学習のシステム構築における指針となります。ポイントは2つで、

  • 100%を目指すのは難しい
    • 例:確率的で本質的に100%の予測が不可能な問題
    • 例:部分的な情報から推測する場合
  • 指標と指標のゴールはアプリのゴールから作る
    • 安全性を満たせるライン、や顧客への魅力が出る最低ライン
  • 複数指標があれば、指標には優先度をつけてどれを始めに達成するか考える必要がある。(理由)

指標に関する知識が少ないうちは、似たような問題を説いていいる論文やブログ記事などを参考にして、基本そのまま使えばいいと思います。アプリのゴールに応じて指標と目標値は決めるために問題に対する様々な指標とその性質に対する理解を増やしていく必要があるでしょう。

  • 作成中:様々なパフォーマンス指標

ベースラインのモデルを使ったシステム構築

ベースラインのモデル構築時には次のようなことをします。

  • モデルの選択
    • NNを使うかシンプルな手法にするか決定
    • どのNNモデルを使うか選択
      • 例:CNN or FNN or LSTM or GRU???
    • CNNならLeaky ReLUs, PreLus, maxout、ReLUなどを使うところから始めるべき
  • 最適化手法の選択
    • 学習率DecayのモメンタムSGD
      • 指数関数Decay、線形Decay、ValidationError変化しないときに10分のDecay
    • Adam
    • 最適化に問題がありそうなら、BatchNormalizationはすぐに導入すべき
  • 正則化手法の選択
    • Early Stoppingは常に使うべき
    • Dropout, Batchnormalizationも有効
  • 非教師学習など、他の学習手法を使うか考える
  • よく知られた手法ならモデルをそのまま持ってきて高い性能がでるはず。また、学習済みモデルに対して転移学習するのはよくある話。

当面はCNNなど簡単なモデルを使って色々と試すのが良さそうです。並行して、LSTM、GRUなど他のモデルに対して理解を深めていって幅を増やすのがいい気がします。最適化、正則化手法はレパートリーは増やしていくとして、上で挙げられている基本的なものだけ抑えて、論文通りに実装する方針で行くといいでしょう。

  • 作成中:基本的な最適化、正則化
  • 作成中:様々なNNモデル
  • 作成中:最適化手法の種類
  • 作成中:正則化手法

デバッグ戦略

イメージ通りですが、NNを使ったシステムのデバッグは難しいです。
例えば、最適化実装で出力層のバイアスの更新にバグがある場合、データセットによっては出力層の重みがカバーしてしまいバグが隠れてしまうそうです。
また、私が実際に実装してみた結果、原因の切り分けも難しいと感じています。

デバッグの方針は

  • 単純なケースを使って期待どおりの結果になることを確認する
  • 部分部分に分けてテストする

となっていますが、中身の動作をきちんと理解していないと難しく思えます。

メモ

Visualize model in action
• See the result of task, output
• detect evaluation bug
最も悪いケースの可視化
• 分類が間違っており、間違ったクラスの値が1に近い(自身が高い)ケースを見ることで、データ自体の問題がわかることがある。

  • 学習損失と評価の損失を見る
    • 学習損失が低くて評価損失が高い
      • 評価の損失計算のバグか、overfitting
    • 学習も評価も損失が高い
      • 別の方法で調査
    • 学習と評価の損失が近い
      • underfittingか学習データになにか問題がある

小さいデータセットで実験して学習できることを確認
• 1個のデータセットor Sufficiently small Datasetsで学習してそれを分類できるようになるのは簡単
○ by settings biases of the output layer correctly
逆誤差伝搬の微分係数数値計算微分係数比較
活性と傾きを見る
• ユニットが飽和しているか確認
○ ReLU,tanh
• 勾配消失や勾配爆発の確認
○ Check weight magnitude and weight grad magnitude
○ grad should be around 1% of the weight
○ しかも、データが疎(例:NLP)だと挙動が異なる。
ディープラーニングで使うアルゴリズムは各イテレーションである保証がある
• 例えば、いくつかの最適化アルゴリズムでは、
○ 目的関数の値はステップごとに絶対増加しない
○ 変数の一部の勾配は各ステップごとにゼロになる
○ 収束時には全変数の勾配はゼロになる。

デバッグ手法は色々とあるが、これは深層学習関連のアルゴリズムなどを一通り理解していないと思いつかない。なので、使っているものの性質などを論文や他の文献から理解し、一つ一つチェックしていく必要がある。実装方法だけではなく、性質を理解しないとフルスクラッチの開発は困難そう。

Omniboard + Sacred, Jupyter、実験実行コマンド実行ツールを導入

問題意識

最近、複数の機械学習プロジェクトに並行して取り組むことが多くなり、もう少しスマートに実験結果の管理をしたいと思っていました。例えば、古い実験結果をもう一度見るために再度学習から実行し直したりと効率が悪くなっているので、実験結果の分類と検索をうまくして、過去の実験再度実行したり、過去の実験結果を再度分析したりできるようにしたいなと考えています。

ライブラリと使い分け

 ざっくり見た感じだと、実験結果を長期的に(プロジェクトをまたいで)管理し続けるためにはSacredOmniboardが役立ちそうで、プロジェクトごとにまとめられた結果を見たりするにはTensorboardが適していそうです。Sacredは実験再現性を向上することを目的として作られたライブラリで、実行中・実行後の実験をDBとかで管理してくれます。OmniboardはSacredのフロントエンドです。OmniboardとSacredを使うと、スクリプトを実行した時点から管理されるので、サーバ上で実行されている実験を管理したりするのにも役立ちそうです。

サーバ構築

実験の実行と管理をするサーバを立てました。構成要素は次の通りです。

  • Jupyter

  • Sacred + Omniboard

    • サーバの実行からあとで検索する用途まで

  • 自前のプログラム実行プログラム

    • paramikoを利用

スクリーンショット

f:id:sam_yusuke:20181205142228p:plain

f:id:sam_yusuke:20181205142932p:plain



今回調査したライブラリに関するメモ

Tensorboard

TensorboardはTensorflow専用というイメージがありますが、Tensorflow以外でTensorboardを使うためのTensorboardXなるものがあるらしいです。

Dockerイメージを使った導入記事もあり、参考にしてみました。

Windowsですが、Dockerは使わずに、WSL上に導入してみました。手順Ubuntuとほぼ同じです。

f:id:sam_yusuke:20181205142544p:plain

tensorboardでは、tesnorboard起動時のlogdirに指定したディレクトリ内でサブディレクトリで整理する感じになりそう。Tensorboardはサブディレクトリを読んで、別のデータとして表示非表示を変更できるようにしてくれて、(実験一回分はTensorboardでは、runと呼ばれている。)この機能を使うとユーザはrunごとの結果の比較や縮尺を変更した比較などがやりやすくなる。また、画像のように正規表現で絞り込んで、狙ったそれぞれのrunの表示非表示を変更できる。下の画像では、runは一つだが、groupが複数あるので複数runsが表示されている。

  • Tensorboardで可視化の省力化

    • Tensorboardで実験するときの設定

      • サブディレクト=パラメタ設定の違いがわかる名前をつける

      • グループ設定=ロス関数とかで分類 (data/loss/focal_lossなど)

      • やりたい実験ごとにディレクトリを区切る

      • それぞれのディレクトリ以下に実験を再現できるパラメタすべてを入れる。

Sacred

  • sacredによる実験再現性確保の省力化
    • 実験をクラスとしてもコマンドとしても定義可能
    • 実験のパラメータを定義可能
    • 実験に関する情報(パラメタ、依存パッケージやそれらのバージョン、マシンに関する情報など..)

パラメータを関数間で引き回さなくていいのがすごいいい気がする。

スクリプトのメインファイルでパラメータの名前の定義だけしちゃって、

任意の関数にcaptureデコレータで設定を突っ込める。

また引数定義がargparseと比較して楽にできる。

ただ、関数を呼び出す場合に、どの引数が設定されていて、どの引数を与えないと行けないかわかりにくくて、バグを生んだり開発スピードが下がりそう。

dictionaryを引き回すほうがわかりやすいかも。

 

Omniboard

SacredにあるMongoDBに実験結果を保存する機能のフロントエンド。

実験結果の一覧を見れる。結構便利だし、導入も楽。タグとステータス以外で検索が出来ない。issueに上がっているので今後サポートされる可能性はある。

 






OSS AutoML:AutokerasでCifar10の画像分類を試してみた

Autokerasとは

Autokerasニューラルネットワークの構造やハイパーパラメータを自動的に探索してくれるPython製のライブラリです。

The ultimate goal of AutoML is to provide easily accessible deep learning tools to domain experts with limited data science or machine learning background.

 

From <https://github.com/jhfjhfj1/autokeras>

 

のように書かれていて、Googleのいう「AIの民主化」のようなものを目指しているようです。そのうち簡単なUIなども作られそうですね。テキサスA&M大学に開発されています。

GoogleのAutoMLやソニーのNeural Network Consoleが競合でしょうか。

まだまだアルファ版ということでIssueがさばききれてなかったり、チュートリアルがコードと一致していないなど、不完全なところも多く、使うには試行錯誤が必要そうです。

この記事の内容も古くなるかもしれません。

簡単な実験

とりあえず、学習してテストするところまでやります。データセットには、Cifar-10を使いました。画像分類タスクでベンチマークとしてよく使われるデータセットです。データセットの説明は他のサイトに任せます。

 

次のような設定をして学習と評価をしてみました。

  • データ強化あり
  • いくつかの制約を設定(現実的な時間で終わりGPUのメモリ量をオーバーしないように…)
    • 一つのモデルあたりミニバッチ勾配法による学習は最大7エポック
    • NNの層の数の最大値は64
    • ミニバッチ勾配法のバッチ最大数は64
  • 10時間でハイパーパラメータの探索を打ち切り

Accuracyの変化

合計25種類のNNが学習されたようで最大で約94%のAccuracyとなっています。

f:id:sam_yusuke:20181201115835p:plain

Autokerasの論文より性能が良くなっているが、Resnetの論文の正解率とトントン。

ハイパーパラメータチューニングされたResnetに適当に使って追いついているので、この結果だけ見るとそれなりにうまく行ってそうですが、今後、データセットを変えたりしてテストしたいです。

Accuracy最大の分類器の性能

実際に生成されたNNの分類器のCifar10に対するConfusion Matrixを見てみます。

Confusion Matrixで見てみると結構分類ミスされているように感じる。チューニングされた手法でどの程度なんだろう…

 

array([[925,   4,  21,   7,   4,   1,   2,   3,  26,   7],

       [  5, 958,   0,   0,   0,   0,   0,   0,   5,  32],

       [ 34,   0, 863,  20,  34,  14,  18,   7,   6,   4],

       [ 14,   3,  31, 798,  33,  85,  16,  11,   2,   7],

       [  3,   1,  20,  12, 924,  14,   9,  17,   0,   0],

       [  5,   0,  14,  82,  19, 850,   8,  20,   2,   0],

       [  2,   2,  23,  24,  12,  12, 923,   1,   1,   0],

       [  6,   0,   7,  12,  13,  24,   0, 936,   0,   2],

       [ 20,   8,   3,   5,   0,   0,   0,   1, 955,   8],

       [ 11,  21,   1,   0,   1,   0,   1,   0,   6, 959]])

 

ソースコード

現時点で最新のmasterのautokerasを使って実行確認してみます。

autokerasの現時点のコミットハッシュは21994919156aac15558f77555538346fb702bcbcです。使ったコードはgistに貼りました。

ただ、autokeras.image.image_supervised.PortableImageSuperviseのpredictメソッドがCPU計算になっていて遅いので、私はGPUを使うように書き換えました。

気になったこと

  • ENASとの比較がされていなくて本論文のベイズ最適化によるハイパーパラメータ探索がどの程度うまく行っているかわからない。
  • ハードウェア制約内でギリギリのモデルまで作ってくれるようにしてもいいのでは。GPUに応じて最大レイヤ数や各層の最大重み数などを計算するのが手間だし、必要な探索空間を削ってしまいそう。(特に計算速度やモデルサイズより性能を良くしたい場合に)
  • 時間打ち切りはなく、性能目標に達するまで試行錯誤するなどの設定があっても良さそう。
  • 4回の試行で90%近いAccuracyになっていて、探索空間が結構小さめに設定されているのでは?と思ってしまう。他のデータセットで試したり、同じ条件でENASと性能比較してみたい。
  • どの程度画像の分類に失敗しているかみたい。
  • チューニングされた手法との比較