

akebonoの構成¶

akebonoが管理する構成は、物理的には大きく２つに分けられ、それぞれprocessor,storageと呼んでおきます。

processorは、akebonoを使った開発における処理に関わる全ての領域です。例えば、config.pyやカスタムモデルが書かれたpythonモジュールファイル、BigQuery loaderが読むSQLファイルなどがこれにあたります。

storageは、ファイル、ディレクトリ、これらの要素に対するオペレーション等のファイルシステム相当の機能を持った外部記憶システムを抽象化したものです。例えば、各種OSが持つファイルシステムと記憶領域がこれにあたります。また、Google Cloud PlatformのGCSやAWSのS3もstorageにあたります。 storageは、訓練済みモデルを保存したり、データセットのキャッシュを置いておくといった使い方をします。

akebonoが管理する構成は、論理的にはトップレベルにまずprojectがきます。設定はprojectごとに存在します。ストレージもprojectごと独立した領域が存在し、storage_root_dirとstorage_typeが同じ２つのプロジェクトの場合は同じストレージの中にprojectごと別のパスが割り当てられ、区別されて管理されます。

akebonoの内部コンポーネントは、大きく分けて Settings,Dataset,Preprocessor,Model,Operatorがあり、これらを組み合わせたCommandがあります。

Settings¶

Settingsは、akebonoの設定を管理するためのコンポーネントです。config.pyに設定した内容は実行時にSettingsに反映され、akebonoに存在する各コンポーネントは Settingsを参照して動作します。Settingsが管理するプロパティはconfig.pyとほぼ同一で、詳細はakebonoの設定を参照してください。

Dataset¶

Datasetは、教師あり学習で利用するデータを管理するためのコンポーネントです。具体的には、以下のような役割を持ちます。

外部記憶システムに保存されたデータやあるルールに基づいて生成されたデータを読み込む。読み込むためのコンポーネントをloaderと呼びます。
- 様々な形式に対応(csv,BigQueryなど)
- sklearn.datasets等に含まれる自動生成されるデータや広く使われるデータセットの読み込みに対応
名前の管理
- Datasetには、各プロジェクトごと、loaderごとに一意に名前をつけることができます。例えば、dataset1という名前のDatasetのloaderをBigQuery loaderとすると、 dataset1.sqlというファイルにSQLを書くことができて、別のSQLで記述されるdataset2とは区別されます。
読み込んだデータに対する前処理。これは、何らかの理由によりloaderの後に処理を加えたものをDatasetとして管理したく、かつ後述のPreprocessorとは区別したい場合に利用します。ありそうなユースケースとしては、SQLでは書くのが難しかったり不可能な前処理を加えた後に説明変数として意味のある形式になるデータに対する適用です。この場合は、次元削減等のチューニングのための前処理（こういった目的ではPreprocessorの利用を推奨します）とは区別する意味があります。
目的変数のカラム名設定
キャッシュ利用の有無
- Datasetはキャッシュを作成することができ、具体的にはloaderで読み込んだ後、前処理後のpandas.DataFrameをpickle化してストレージに保存しておき、次の読み込み時にはpickleから読むようになります。キャッシュはDatasetについた名前と前処理関数の名前のハッシュ、loaderへ渡したパラメータ、前処理関数に渡したパラメータの組み合わせから一意に生成され、これらの組み合わせが一致するとキャッシュヒットします。

Preprocessor¶

Preprocessorは、データの前処理の役割を担うコンポーネントです。 Preprocessorは、大きく２つに分けることができ、それぞれStatelessPreprocessor、StatefulPreprocessorと呼びます。 StatelessPreprocessorは訓練データに依存しない前処理、StatefulPreprocessorは訓練データに依存する前処理です。 StatelessPreprocessorの例としては、カラム選択処理があります。あるモデルをチューニングするに際し、データのカラムの一部だけを使ってノイズを減らそうとするアプローチがあります。カラム選択の処理は訓練データの値に依存しないのでこれはStatelessPreprocessorになります。一方、StatefulPreprocessorの例としてはデータの標準正規化があります。この変換処理は訓練データの平均・分散が必要になるため、訓練データの値に依存し、StatefulPreprocessorになります。

StatefulPreprocessorは、訓練、予測のフローの中でやや複雑な振る舞いをし、以下のとおり留意すべきポイントがあります。

訓練データに依存して振る舞いが変わるということは、評価に際してデータを分割するたびに振る舞いが変わる。交差検定の場合は分割するたびモデルを訓練しなおすだけでなく前処理を実行する必要がある。
予測の際は、訓練に使ったデータに依存した前処理が必要になる。このため、訓練時にStatefulPreprocessorの振る舞いを決定するパラメータを保存しておく必要がある。

1,2に対して、後述のOperator経由で実行する場合は自動で配慮されます（チュートリアルで使っているコマンド経由でも同様です）。

また、PreprocessorにはPipelineという仕組みがあり、これは複数のPreprocessor連結を１つのPreprocessorとして扱う抽象化機構です。 OperatorはPipelineとしてPreprocessorを扱うため、config.pyには複数のPreprocessorを記述することが可能です。

Formatter¶

Formatterは、データ整形の役割を担うコンポーネントです。Preprocessorが説明変数の前処理に使われ、その結果モデルを変えてしまうほどの意味を持っているのに対し、 Formatterはあくまでデータフォーマットを整えるためのみに使われます。例えば、モデルが受け付ける目的変数のフォーマットが手法や使われるフレームワークによって異なるケースで、差分を吸収するために使います（クラス分類の目的変数として、scikit-learnが(n_samples,)型なのに対しKerasでは(n_samples, n_classes)のone-hot型です）。

Model¶

Modelは、教師あり学習用モデルのインタフェースと共通実装を扱うコンポーネントです。 scikit-learnのモデルに似たインタフェースを持っていますがakebono独自の部分もあります。例えば、akebonoのModelにはmodel_typeというプロパティがあり、これはモデルが二値分類器(binary_classifier)なのか、多値分類器(multiple_classifier)なのか、回帰器(regressor)なのかを区別するために使われます。二値分類器と多値分類器どちらでも使えるモデルについては、model_typeの決定はデータから決めることもできればconfig.pyで指定することもできます。 akebonoを使ったモデル評価では、評価項目はmodel_typeに依存し、利用者に評価項目選択の自由を与えない一方で、モデルごとに最適な評価方法を考える手間を省けるようにしています。

また、akebonoが標準でscikit-learnやXGBoost、LightGBMのような広く使われるライブラリをサポートするのに加え、必要あれば利用者が独自にカスタマイズしたモデルを追加する手段を提供しています。

Operator¶

Operatorは、訓練や予測などの機械学習の目的を達成するために、akebonoの各種コンポーネントを連動させるためのコンポーネントです。　

Command¶

Commandは、コマンドラインツールを作成する場合に使われ、主に細々とした調整役としての役割を担うコンポーネントです。