Cookiecutter Data Scienceの改善案
Cookiecutter Data Science
Pythonプロジェクトのひな型を作成する際にcookiecutterというツールが用いられることが多く、機械学習用（分析用かもしれないが、機械学習システムの用途でも使われている気がする）のテンプレート（cookiecutter data scienceも存在する。
cookiecutter data scienceで作成されるテンプレートは以下のような構成になっている。
├── LICENSE
├── Makefile <- Makefile with commands like `make data` or `make train`
├── README.md <- The top-level README for developers using this project.
├── data
│ ├── external <- Data from third party sources.
│ ├── interim <- Intermediate data that has been transformed.
│ ├── processed <- The final, canonical data sets for modeling.
│ └── raw <- The original, immutable data dump.
│
├── docs <- A default Sphinx project; see sphinx-doc.org for details
│
├── models <- Trained and serialized models, model predictions, or model summaries
│
├── notebooks <- Jupyter notebooks. Naming convention is a number (for ordering),
│ the creator's initials, and a short `-` delimited description, e.g.
│ `1.0-jqp-initial-data-exploration`.
│
├── references <- Data dictionaries, manuals, and all other explanatory materials.
│
├── reports <- Generated analysis as HTML, PDF, LaTeX, etc.
│ └── figures <- Generated graphics and figures to be used in reporting
│
├── requirements.txt <- The requirements file for reproducing the analysis environment, e.g.
│ generated with `pip freeze > requirements.txt`
│
├── setup.py <- makes project pip installable (pip install -e .) so src can be imported
├── src <- Source code for use in this project.
│ ├── __init__.py <- Makes src a Python module
│ │
│ ├── data <- Scripts to download or generate data
│ │ └── make_dataset.py
│ │
│ ├── features <- Scripts to turn raw data into features for modeling
│ │ └── build_features.py
│ │
│ ├── models <- Scripts to train models and then use trained models to make
│ │ │ predictions
│ │ ├── predict_model.py
│ │ └── train_model.py
│ │
│ └── visualization <- Scripts to create exploratory and results oriented visualizations
│ └── visualize.py
│
└── tox.ini <- tox file with settings for running tox; see tox.readthedocs.io
基本的にはsrc以下に実験用のスクリプトを格納し、その他のデータ（モデルファイルなども）、レポート、notebookなどは各ディレクトリに置くような配置になっている。
この構成は一見良さそうに見えるが、実際に使ってみると機械学習プロジェクトの推論（実運用）の段階でかなり行き詰ってしまうように思える。
その理由として、実験コード（モデル、前処理など）が再利用できないことが挙げられる。
分析・学習フェーズ
機械学習プロジェクトにおいて、分析・学習のフェーズでは上記ディレクトリ構成のほとんどの部分を使用することになる。
- 分析：
notebook,report,docs,data - 学習：
src/*,models
おそらく、「分析・学習をする」という面で見れば、上記のディレクトリ構成はかなり管理しやすくてよいと思うが、次に挙げる「推論（運用）フェーズ」に進む際に大幅な再実装が必要になってくる。
推論（運用）フェーズ
先ほどほぼ全てのディレクトリを使用したため、こちらでは新たに推論API用のディレクトリを作成する必要が出てくる。
- 推論（API）：
app
加えて、推論に必要な”前処理”、”モデル予測”などのコードはbuild_features.py、predict_model.pyなどのスクリプトとして書いてしまっているので、おそらくAPIから使うには難しそう（クラス化などおそらくしていないだろうし...）。
そうなると、学習時とは別に推論用の前処理・モデルクラスなどを再実装する必要があり、単純に時間がかかるうえに、「学習時と同じ処理をしていることを担保するテストコード」を追加で書く必要がある。
改善策
では、分析・学習時も管理しやすく、なおかつ、推論時に再実装の必要がないような構造にするにはどうすればいいか。
一つの改善策として、src以下を下のように変更するといいかもしれない。
├── src
│ ├── __init__.py
│ ├── train.py <- 学習の際にmodels配下のモデルを切り替えるようにする
│ │
│ ├── data
│ │ └── make_dataset.py
│ │
│ ├── models <- モデル毎に形式を統一
│ │ │
│ │ ├── base <- 抽象クラスの定義
│ │ │ ├── __init__.py
│ │ │ ├── model.py
│ │ │ └── preprocess.py
│ │ ├── lightgbm <- モデルのロジック（前処理・予測など）をまとめる
│ │ │ ├── __init__.py
│ │ │ ├── model.py
│ │ │ └── preprocess.py
│ │ └── cnn
│ │ ├── __init__.py
│ │ ├── model.py
│ │ └── preprocess.py
│ │
│ └── visualization
│ └── visualize.py
models配下にbaseのような形式でモデル毎にディレクトリを作り、その中にモデルに依存する処理をまとめる（学習コードなどにも一切含めない）ことで、学習・推論時ともに同じ実装を利用することが出来る。
また、工夫点としては、base配下のような基底抽象クラスを作ることで新しいモデルを容易に追加できるようにしているところで、モデルの切り替えのロジックを書くことでその他はいじる必要がなく非常に管理がしやすいと思う。
Discussion