機械学習で泣かないためのコード設計 2018

Copyright © TIS Inc. All rights reserved.
機械学習で泣かないためのコード設計 2018
戦略技術センター
久保隆宏
Don't cry anymore when creating machine learning model

Copyright © TIS Inc. All rights reserved. 2
◼ はじめに
◼ 機械学習モデルの開発における問題点
◼ 原因の特定が難しい
◼ コード上で管理できない依存が発生する
◼ 処理に必要な静的ファイルが多い
◼ 設計による問題の解決
◼ 機械学習モデル開発におけるモジュール構成
◼ 構成のポイント
◼ vs問題の切り分けが難しい
◼ vsコード上で管理できない依存が発生する
◼ vs処理に必要な静的ファイルが多い
◼ おわりに
目次

本資料では機械学習モデルの開発における問題点を整理し、それを設計に
より解決するための方法について提案します。
◼ 要件定義については触れていません。要件に沿っていないモデルはど
れだけうまく設計しても効果が出ないため、注意してください。
◼ 設計だけでなく、運用により問題解決を行う方法もあります(特に機械
学習モデルのホスティングサービスの活用など)。これについては、簡
単に触れます。
はじめに

久保隆宏
TIS株式会社戦略技術センター
◼ 化学系メーカーの業務コンサルタント出身
◼ 既存の技術では業務改善を行える範囲に限界があるとの実感から、戦
略技術センターへと異動
◼ 現在は機械学習や自然言語処理の研究・それらを用いたシステムのプ
ロトタイピングを行う
自己紹介
kintoneアプリ内にたまった
データを簡単に学習・活用
(@Cybozu Days 2016)
チュートリアル講演：深層学習
の判断根拠を理解するための研
究とその意義(@PRMU 2017)
機械学習をシステムに組み込む
際の依存性管理について
(@MANABIYA 2018)

chakkiのミッション
Summarize data for human
あらゆるデータを、人間にとってわかりやすく要約
することを目指します。
chakkiが目指す機能:
◼ 要約の観点を、なるべく少ないデータで学習する
◼ 自然言語以外の、画像や数値データの要約も扱う
◼ 図や表といった表現形態にも挑戦する
この機能の実現を通じ、最終的にはいつでもティー
タイム(15:00)に帰れる(=茶帰)社会を目指します。
2018年度より具体化

観点を指定した自然言語処理
観点単位にまとめることで、情報の欠落を
防ぐと共に図表化を行いやすくする。
モデルにお任せで「こんなん出ました」で
なく、利用者が出力をコントロールする。
ex: 観点要約
ペンギンのサイズは小さくて、手触りは冷たい。
◼ 「サイズ」は「小さく」
◼ 「手触り」は「冷たい」
サイズ手触り
ペンギン小さい冷たい
ライオン大きい温かい
ウサギ中くらい温かい
業務要件により観点は異なる。そして、観点の学習データは少ない。
⇒自然言語処理における転移学習に注力し、「少ないデータでカスタマ
イズ可能な分類/生成器の作成」を目指している。
(2/3)

(3/3)
◼ 研究開発活動は基本オープンに行っている(GitHub★総計 800以上)。
◼ 研究に関することであれば、個人のブログ/リポジトリも評価される。
機械学習関連の論文のまとめをGitHubのIssueを使って行っ
ています。月一での輪講も開催中です。

機械学習モデルの開発における問題点

機械学習の開発におけるプロセスは、以下のように図式化できる。
今回扱う問題は、この各プロセスで発生するものとなっている。
機械学習モデルの開発における問題点(1/3)
モデル定義コードパラメーター設定
予測
学習用コード
予測(API用)コード
開発学習配置(デプロイ)
学習データ
モデルファイル学習

機械学習の開発におけるプロセスは、以下のように図式化できる。
今回扱う問題は、この各プロセスで発生するものとなっている。
開発学習配置(デプロイ)
モデル定義コードパラメーター設定
予測
学習用コード
予測(API用)コード
学習データ
モデルファイル学習
原因の特定が
が難しい
コード上で管
理できない依
存の発生
処理に必要な
静的ファイル
が多い

今回扱う課題は、以下の3つとなる。
◼ 開発時: 原因の特定が難しい
◼ 学習がうまくいかないなどの問題が発生した際に、その原因を特定
するのが難しい
◼ 学習時: コード上で管理できない依存が発生する
◼ 学習させる時だけ指定するパラメーターが数多くあり、それらが
(モデルの再現に必要な情報にもかかわらず)どこにも残らない。
◼ 配置時: 処理に必要な静的ファイルが多い
◼ 予測処理を行う際、機械学習モデルだけでなく前処理のパラメー
ターを保存したファイルや入力/出力を変換するための辞書など、
多くのファイルに依存する。

原因の特定が難しい(1/6)

機械学習モデルの開発では、うまく動かない際にその原因として考えられ
る要素が数多くある。
◼ モデルに原因がある
◼ 選択したモデルが問題に適していない
◼ モデルの構成(レイヤ構成など)に問題がある
◼ データに原因がある
◼ データの量、あるいは質に問題がある
◼ 前処理に問題がある
◼ 学習方法に原因がある
◼ 目的関数、初期化方法、学習率、オプティマイザとその設定etc
◼ 辛抱が足りない(明日になれば学習が進んでいるかも)
◼ 蜃気楼の学習結果(あの時はたまたま収束した)
◼ その他
◼ 実装に使っているフレームワークの差異

原因の特定が難しい: 実例(3/6)
前処理に問題があった例 (from OpenAI Baselines: DQN)
ゲームの学習を行う際、前処理として画像をグレースケールにしたら敵
キャラのアイコンも消えてしまった。

蜃気楼の学習結果の例 (from Deep Reinforcement Learning that
Matters)
同じハイパーパラメーターでも、乱数のシードで結果に差が出る。
調子がいい時のスコア
調子が悪い時のスコア
※強化学習で顕著な例で、画像や自然言語処理など他ではここまでひどく
はない(体感的に)。

実装に使っているフレームワークの差異の例(Keras vs TensorFlow)
正規乱数で初期化を行う際の、平均/分散のデフォルト値がフレームワー
ク間で異なる。
kerasで使う時とtf.kerasで使う時で挙動が異なる罠
あれ？論文通り/公開実装と同等に実装をしたのに？と思った際はこうし
たところが原因の可能性もある(他にもPyTorchのLSTMにおけるforget
biasの初期値などいろいろある)。
平均0/分散0.05 平均0/分散1

機械学習がうまくいかない=モデルの問題と思いがちだが、実際はあらゆ
る箇所に落とし穴がある。
穴の数が多く、回避方法(調整するパラメーターの数と値の範囲)も多く、
結果を確認するのにも時間がかかるため、原因の特定が難しい。

コード上で管理できない依存が発生する(1/3)

コード上で管理できない依存が発生する(2/3)
学習の結果生成される「機械学習モデル」は、ソースコード以外の要素へ
の依存を内包することになる。
◼ 学習に使ったデータ
◼ 学習時のハイパーパラメーター
つまり、コードがあるからといって機械学習モデルが再現できるとは限ら
ない。同じコード(モデル)でも、実行条件により精度は大きく異なる。
> model.train --dataset=./data/faces/20180101 --epoch 25 --
lr=0.0002 --batch_size=64

コード上で管理できない依存が発生する: 実例(3/3)
同じモデル(4層のLSTM)を使用し、異なるハイパーパラメーターで言語モ
デル(Penn Treebank)を学習させた際の結果。
On the State of the Art of Evaluation in Neural Language Models
赤い線のパラメーターの組み合わせが良好なもの。ここから外れると精度
が落ちる。

処理に必要な静的ファイルが多い(1/2)

処理に必要な静的ファイルが多い(2/2)
機械学習モデルを利用して予測を行う際は、多くの静的ファイルに依存す
る。
◼ モデルファイル
◼ 学習の結果生成されたモデルファイル
◼ 前処理のパラメーター(データの平均/分散など)
◼ 学習時に前処理をしていれば、予測時も前処理が必要。
◼ 入力/予測結果を変換するための辞書
◼ モデルへの入力/モデルからの出力は数値(0,1,2...)なので、数値が
表す意味を変換する辞書(0=>猫、1=>犬など)が必要。
これらの静的ファイルはサイズが非常に大きい場合もあり(数Gなど)、
ソースコードと同じリポジトリに含めて管理することが難しい。

機械学習モデルの開発における問題点
機械学習モデルの開発における問題点を解決するには、「学習」はもちろ
んそれに使用されるデータやパラメーターなど、機械学習を取り巻く要素
を含めて設計を行う必要がある。
機械学習は「機械」だけで完結しない
機械=モデルを定義したソースコード、モデルファイル

設計による問題の解決

構成(2018年版)
Storage
Dataset
Model
train
Transform
er
fit
load
save
save
load
feed
transform
batch
Trainer
Experiment
ModelAPI
Model
Transform
er
data
transform predict
■Dataset
データセットの取得を行う
■Transformer
前処理/後処理を行う
■Trainer
モデルの学習を行う
■Model
機械学習モデルを定義する
■ModelAPI
モデルによる予測を行う
■Experiment
学習条件を記述する
■Storage
ファイルの配置を管理する

◼ Transformer: 前処理を独立させる
前処理は学習時も予測時も必要となる。そのた
め、独立したモジュールとしておく。
予測時には前処理済みのデータをキューにた
めてそこから推論する、というパイプライン構
成をとることもありうる。そのためにも、独立
させておくことが肝要。
構成のポイント: vs問題の切り分けが難しい(1/4)
◼ Dataset: 学習データを管理する
学習/評価に使用するデータを、コードの世界で
管理する(例: sklearn.datasetsなど)。これによ
り、学習におけるデータへの依存をコードの静
的解析で把握できるようにする。
なお、データロードの機能だけでなく簡単な統
計情報の算出や可視化の機能を付属させると◎。

◼ ModelAPI: 利用側からモデルを隠ぺいする
生のModelは実装に利用したフレームワークで
書かれており、予測を行う際もそのフレーム
ワークの作法に則る必要がある(特に
TensorFlowの場合のsess.runなど)。
利用する側への負担を少なくするため、利用側
は一般的な変数から利用できるようにする。
REST API化なども選択肢になる。
◼ Trainer: 学習とモデル定義を分離する
最終的にモデルを利用する際は予測だけできれ
ば良いので、モデルの定義に学習のための要素
(具体的には目的関数やオプティマイザの定義、
ましてや学習のためのハイパーパラメーター)を
含めてしまうと、予測の際もそれらが付随して
しまう。

モジュールを分割することで、責任範囲を明確にすることができる。
◼ モデルに原因がある
◼ Modelの確認
◼ データに原因がある
◼ Datasetを通じたデータの分析
◼ Transformerの単体テストによる動作チェック
◼ 学習方法に原因がある
◼ Trainerの確認
◼ Experimentsの実行(次スライド)
◼ その他: API経由で利用するとうまく動かない
◼ Model APIの確認
特に、「データに原因がある」ケースについてはDataset/Transformerの
チェックにより事前に洗い出すことが可能。

OpenAI Gymには、先ほどの失敗の反省から「play」という機能が追加さ
れた。これは、エージェントが実際見ている画面(前処理済み画面)でゲー
ムをプレイしてみることができる機能。
前処理前のPong 前処理後のPong
※Atari以外のゲームでは使いづらい

構成のポイント: vsコード上で管理できない依存(1/3)
◼ Dataset/Experiment: 学習をコード化する
Model/Trainerに対する単体テスト的に、各学
習をExperimentとして実装する。
Datasetとしてサンプルデータを使用し
forward/backwardの確認、Modelとしてベー
スラインとなるモデルを使用することで結果比
較なども行える。
from datasets import face_image
from trainer import Trainer
from model import Model
data = face_image.load(“v1”)
trainer = Trainer(Model())
trainer.train(data=data, epoch=25, lr=0.0002, batch_size=64)
experiments_1.py

◼ コマンドライン引数ではだめなのか？
画面はCloud MLのもの
◼ 確実にログを残す方法がない。
◼ ただ、機械学習のホスティング
サービスが提供する機能で賄え
るようになる可能性はある。

◼ 指定するハイパーパラメーターのバリエーションは無数にあり、それ
毎にExperimentを用意すると膨大な数になってしまうのでは?
◼ 本当に効くパラメーターの数と範囲はそれほど多くない。
◼ パラメーターサーチが必要な場合は、パラメーターサーチを行う
Experimentを作る。
◼ 実験をスクリプト化することで、開発者の時間の浪費(ちょっとパ
ラメーターを変えてlossを眺める無限ループ)を防ぐことができる。
◼ ファイルにパラメーターをまとめて読み込ませるのではいけないのか?
◼ ソースコードで記述することで、ソースコードの静的解析により
DatasetやModelの使用先(依存関係)を洗い出すことができる。

構成のポイント: vs処理に必要な静的ファイルが多い
◼ Storage: ファイルの配置を管理する
どこに何をどういうネーミングで保存するかを
一元的に管理する。適当な場所、適当な名前で
ファイルが散在することを防止する(ファイルは
基本的にクラウドストレージで管理する)。
ローカルでも稼働する必要がある場合は、仮想
パス的な機能を提供する(同じパスだが、クラウ
ド/ローカルでアクセス先を変える)。
ファイル配置・ネーミングルールをコードという形で体現しておくことで、
運用ミスを防止する。

構成のポイント
紹介した構成は、基本的にはソフトウェア設計の基本原則である「単一責
任原則」に則り設計されている。
機械学習モデルの開発もソースコードを通じて行われるものであり、既
存のソフトウェア設計論は十二分に通用する。
むしろ、「機械学習だから」という形で特別扱いしないことが重要。
◼ 機械学習だから1ファイルに全部処理をまとめていい
◼ 機械学習だからグローバル変数を気軽に使っていい
◼ 機械学習だから単体テストできない
...ということはない。システム開発者として「おかしい」と感じたら、そ
れは本当におかしいので、対策を考える。

おわりに(1/3)
はじめにで述べた通り、本資料では「機械学習モデルの開発」における
「設計」にフォーカスしており、前段階である要件定義や後段階である運
用については触れていない。
要件定義が終わった後の「機械学習モデルの開発・運用」という場面にお
いて、本資料が触れた範囲はというと・・・

おわりに(2/3)
機械学習モデル
のスケール
動作環境
プロジェクト
構成
学習基盤
テスト
モデルの
API化
コード管理
デプロイ
パイプライン化
学習データ管理
デプロイ時
テスト
パフォーマンス
のスケール
耐障害性
のスケール
稼働監視
評価データ管理
バージョン管理
のリリース
の作成
コード設計
ここ

おわりに(3/3)
もちろん、設計は多くの箇所に影響するため部分的に他の箇所の話題につ
いても触れてはいる。ただ、それを差し引いてもまだ方法論が確立してい
ない箇所は多い。
機械学習工学の道のりは始まったばかりだ！

Appendix1:機械学習モデルの開発/運用に関する課題の整理

機械学習モデルの開発/運用に関する課題の整理(1/2)
のスケール
動作環境
プロジェクト
構成
学習基盤
テスト
モデルの
API化
コード管理
デプロイ
デプロイ時
テスト
のスケール
耐障害性
のスケール
稼働監視
のリリース
の作成
コード設計

機械学習モデルの開発/運用に関する課題の整理(2/2)
のスケール
のリリース
の作成
動作環境
プロジェクト
構成
学習基盤
テスト
モデルの
API化
コード管理
デプロイ
デプロイ時
テスト
のスケール
耐障害性
のスケール
稼働監視
コード設計
やらないと死ぬ
やるべき
要件次第

1. 機械学習モデルの作成
◼ 機械学習モデルの開発・学習・評価を行う
◼ 生産性(学習時間・原因の特定)/再現性の高い開発プロセスの構築が課題
コード管理
プロジェクト
構成
動作環境
テスト/
学習データ
モデルのパッ
ケージ化
学習基盤
機械学習モデルのソースコードを管理する。
■ソースコードの共有を可能にしデグレードを防止する
機械学習モデルを開発する際の、プロジェクト構成を統一する。
■共有のバッチスクリプトなどの開発を行いやすくする。
機械学習モデルを開発する環境を管理する。
■ある環境で動いて別の環境で動かないという事態を防止する。
機械学習モデルをテストするためのテストケースを管理する。
■短い時間・コストで動作や精度を評価できるようにすることで、
開発速度を上げる。
機械学習モデルのソース・環境をパッケージ化する
■デプロイや学習環境への配置を行いやすくする
機械学習モデルの学習を行うための高火力環境
■学習にかかる時間を短縮し、開発速度を上げる
コード設計
機械学習モデルの実装を適切なモジュールに分割する。
■モジュールに分割することで、個別のテストを可能にする。

2. 機械学習モデルのリリース
◼ 機械学習モデルを、既存のプログラムやサービスから使えるよう配置する
◼ 前処理や後処理が絡むAPIをどう構成するのかが課題(単一点API/パイプライン)
バージョン
管理
モデルのAPI化
パイプライン
化
デプロイ
デプロイ時
テスト
現在稼働しているソースコードのバージョンを管理する
■ソースだけでなく、学習時のパラメーターやデータなどを管理
できるとベター
機械学習モデルを外部から使えるAPIに仕立てる
■Web APIやライブラリ内の関数にするなど、方法は様々
機械学習モデルによる予測処理を、前処理などを含めたパイプラ
イン処理(JOBなど)にする
■前処理がある場合、APIに含めるかパイプライン化するか要件等
機械学習モデルを本番環境に配置する
■ダウンタイムを回避する場合はその対策も必要となる。
本番稼働する前に機械学習モデルをテストする
■精度はもちろん、パフォーマンス等のチェックを行う。

3. 機械学習モデルのスケール
◼ 機械学習による予測をサービスとしてスケールさせる
◼ 高速化や耐障害性の向上、モデル再学習のタイミングの検知などが課題
耐障害性の
スケール
パフォーマン
スのスケール
稼働監視
予測を行うサーバーの耐障害性を高める
■サーバー停止を補い合えるようなインフラを導入する
機械学習モデルによる予測の速度を高める
■分散実行基盤や、オートスケールの導入など
機械学習モデルの稼働状況をチェックする
■特に再学習のタイミングを検知したりするために必要

Appendix2:開発をサポートするツール/サービス

◼ CometML
◼ 機械学習モデルの学習ログを記録しておけるサービス(ログ管理の
みで、演算機能はなし)。GitHubとの連携機能もあるため、コード
と実験結果をひもつけて管理することができる。
◼ Data Version Control
◼ Gitライクにデータのバージョン管理ができるツール。データはもち
ろんクラウドストレージに保管可能。ファイル・コマンドの紐つけ
管理もでき、データと学習コマンドをセットで管理しておくといっ
たことが可能。
◼ Polyaxon
◼ 機械学習モデルの構築、学習、結果監視ができるオープンソースの
フレームワーク。Kubernetesベースで、モデルのバージョン管理
や、クラスタ構成を活かした分散学習、ハイパーパラメーター探索
もサポートしている。
開発をサポートするツール/サービス(1/2)

◼ FloydHub
◼ 機械学習におけるHerokuを掲げるサービス。GPUによる計算機能
を提供するほか、β版として機械学習モデルのデプロイ機能を提供
している。
◼ Algorithmia
◼ 元々は開発した機械学習アルゴリズムを公開できるサービスだった
が、そのインフラをプライベートでも使えるよう公開した。
◼ Google Cloud ML
◼ 学習の実行、作成したモデルの管理機能を提供するサービス。
◼ Amazon Sage Maker
◼ 同様に、学習の実行、作成したモデルの管理機能を提供するサービ
ス。
開発をサポートするツール/サービス(2/2)

Appendix3: 各モジュールの基本的なAPI設計
プロジェクトテンプレートを開発中

◼ Dataset
◼ constructor: 接続先のファイルをStorageから取得する
◼ load: 学習データ(データ/ラベル)を取得する
◼ batch_iter: 学習データを指定されたバッチサイズごとに取得するジェネレーター
◼ describe: 基本統計量を出力する(表形式のデータなら、pandasに入れると楽)
◼ Transformer
◼ scikit-learnのBaseEstimator/TransformerMixinを継承して作成することを推奨
(save/loadが楽になるほか、Pipelineで処理できるようになる)
◼ fit: パラメーターの調整を行う
◼ transform: 変換を実施する
◼ inverse_transform: 逆変換を行う
各モジュールの基本的なAPI設計(1/3)

◼ Trainer
◼ constructor: 学習させるモデル、学習に使用するパラメーターを受け取る・宣言す
る(メンバ変数として必要なもの)。
◼ calc_loss: 最適化の対象となる誤差の計算プロセスを定義する
◼ set_updater(compile): calc_lossの最適化プロセスを定義する(lossが複雑でない場
合、calc_lossとまとめる場合も多い)
◼ train: 学習に使用するDatasetを受け取り、batch_iterから取得したデータを
Transformerで前処理しcalc_lossの値をupdaterで更新する
◼ (report): 学習の進捗を記録するが、実務上はTensorBoardに書き込むことが多い。
保存先はtrainメソッド実行時に指定する。
◼ Model
◼ constructor: modelの構築を行う
◼ (forward): modelの伝搬プロセスを定義する(KerasのSequentialのように、定義=
伝搬になる場合も多いため、明示的にメソッドを設けるかは場合による)
◼ predict: modelによる予測を行う

◼ ModelAPI
◼ constructor: Storageから、必要な静的ファイルのパスを取得し内容を変数内(メモ
リ)に展開する
◼ predict: 配列などの一般的な変数からモデルによる予測を行う。
◼ Experiment
◼ constructor: Trainerインスタンスを生成する。
◼ run: Trainer.trainを実行する。
◼ Storage
◼ constructor: local/globalの指定を行う(global=クラウドストレージに接続)
◼ experiment_path: overwriteするか否かとExperimentの型を受け取り、実験結果
の保存先を返す
◼ stage: Experimentの型を受け取り、実験で作成されたモデルファイルをステージ
ングフォルダにコピーする
◼ deploy: stageされたファイルを、新しいバージョンのモデルとしてデプロイする。
バージョンが指定され、force=Trueの場合、上書きを行う(force=Falseの場合既存
のバージョンがあったら例外を投げる)。
◼ path: クラスの型とバージョンを引数に、各種ファイルの保存先を返す

機械学習で泣かないためのコード設計 2018

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 機械学習で泣かないためのコード設計 2018

Similar to 機械学習で泣かないためのコード設計 2018 (20)

More from Takahiro Kubo

More from Takahiro Kubo (20)

機械学習で泣かないためのコード設計 2018