機械学習におけるコード設計のベストプラクティスについて

1. Copyright © 2016 TIS Inc. All rights reserved.
機械学習で泣かないためのコード設計
戦略技術センター
久保隆宏

2. 2
Agenda
• Who are you
• TIS株式会社について
• 戦略技術センターについて
• 機械学習あるある物語
• 機械学習で泣かないための設計(案)
• Model
• Trainer
• DataProcessor
• ModelAPI
• Resource
• Appendix: API一覧

3. 3
Who are you

4. 4
業務コンサルタント出身。
化学系メーカーへのパッケージ導入や周辺業務システム開発
を手掛ける(ASP.NET VB.NET/C#)。
現在は「人のパートナーとなれるアプリケーション」の研究
開発(Python/機械学習)。
サイボウズ公認kintoneエヴァンジェリスト
Qiitaのストック数ランキング
機械学習: 1位
Python: 2位
(8/18時点)
icoxfog417
後輩

5. 5
TISとは？

6. 6
会社紹介
TISはTISインテックグループの中核会社となります。
TISインテックグループは多様な得意分野をもつ企業の総体であり、一体感のあるグル
ープフォーメーションの下お客様のニーズにお応えします。
TIS INTEC GROUP（59社 19,393名）
お客様

7. 7
TISとは？

8. 8
戦略技術センターについて(1/2)
ミッション
・中長期(3~10年)的な視点からのサービスのプロトタイプ開発・検証
・技術プレゼンスの向上(=研究活動の対外発信)
サービスのプロトタイプ開発
技術プレゼンスの向上
薬剤師BOT
会議診断AI
観光ルート自動生成
etc・・・
カンファレンスへの
登壇、ハッカソンへ
の参加、勉強会の開
催etc・・・

9. 9
戦略技術センターについて(2/2)
ロボット 販売員
店頭での呼び込み、
定型的な商品説明を
担当
自動応答と遠隔操作の組み合わせで、接客の分業を実現
遠隔操作による
応対の引き継ぎ
ロボットから応対を
引き継ぎ、一人一人
に合った接客を行う
ダッシュボード
ロボットの接客状況
(顧客数、商品説明へ
の反応など)を確認
自動応答の
状況を報告
・自動応答により、人の接客負荷を低減
・遠隔操作により、東京にいながら北海道の店舗の応対を行う、と
いったことが可能になる＋多言語対応が可能な販売員が様々な店舗で
応対するといったことも可能になります。

10. 10
機械学習あるある物語

11. 11
MNISTとかのExampleを動かしてうまく動いているとき
→NEXT: 自分のデータで試してみよう！

12. 12
自分で集めたデータでうまく動かなくて戸惑っている時
→NEXT: でもここから本番、がんばるぞい！

13. 13
修正したら繰り出される謎の例外
初期化の方法・学習率・レイヤ数・・・いろいろなパラメーター
精度が出ない・・・データがないせい？モデルが自分のデータに合わないせい？
データの前処理→こんにちは線形代数

14. 14
まあ(Example)動いたしな？
中途半端だけどおしまいにする(完)

15. 15
機械学習の難しさ
機械学習は、うまくうごかないときに考えられる理由がたくさんある。
・データが悪いのか
・そもそものデータが良くない(データの量・データの質)
・前処理に問題がある
・モデルが悪いのか
・バグがある(伝搬が上手くいっていないなど)
・構成が悪い
・(逆に間違っててもそれなりに動くことがあり、混乱を助長する)
・学習方法が悪いのか
・ノードの初期化方法、学習率、学習率低減のタイミングetc→職人芸
・辛抱が足りない(明日になれば学習が進んでるかも？)
モデルや学習方法の書き換えには、機械学習の理論的な理解が必要になる場
面も多い。それぞれのフレームワークのクセにもかなり翻弄される(Example
だけでなく、ライブラリ内部のコードを読まないといけないことになること
も多い)。

16. 16
ただでさえ難しい＋原因の切り分けができない

17. 17
機械学習で泣かないための設計(案)

18. 18
ただでさえ難しい＋原因の切り分けができない
まずこっちを解決

19. 19
構成
Model
DataProcessor
Resource
ModelAPI Trainer
・Modelは、機械学習モデルの定義を行う
・ModelAPIは、外部に向けて予測機能などのAPIを公開する。
・Trainerは、Modelの学習を担当する。
・DataProcessorは、データの読み込みと前処理を担当する
・Resouceは、全体で必要になるパラメーターを管理する

20. 20
構成のポイント(1/2)
・TrainerとDataProcessorの分離
Trainerからデータに関する処理を独立させる。
忘れがちだが、予測を行う際もデータの前処理は必要
になる（例：画像の平均化など）。この処理を
Trainerに含めていると、学習以外の処理でもTrainer
を呼び出すことになるほか、Trainerはおおむねバッ
チでデータを入れるので予測処理(データ一件)と処理
が合わない。
・パラメーターはResourceで一元管理を行う
learning rateを始めとした学習パラメーター、また
学習モデルの保存先、データのロード元など、機械学
習では色々なパラメーターが必要になる。
これらはyamlやjsonといったファイルにまとめて管
理するようにし、その読出しを行う担当として
Resourceを置く。
最重要

21. 21
構成のポイント(2/2)
・学習はTrainerが管理し、Modelは関与しない
具体的には、lossやoptimizerの定義をModelに含めな
い。これをModel管轄にしてしまうと、予測しかしな
いときにもbatch sizeやlearning rateを指定する羽目
になる。これは好ましくない。
・アプリケーションからModelを隠蔽する
直接Modelを利用すると、ChainerならVariable、
TensorFlowならTensor/Sessionとフレームワーク依
存のコードがアプリケーションに混ざることになり、
実装担当者の負担が大きくなるほかフレームワークの
スイッチが難しくなる。
そのため外部公開するAPIはModelとは別個に作成し、
アプリケーションからModel本体を隠蔽する。
※predictのコードがTrainerとModelAPIで重複するが、
この重複は許容する(思ったよりは違った実装になる)
重要

22. 22
テストの実施
・モデルのテスト
ModelAPIと一体でテストし、入力からきちんと値が出力されることを確認。
・データ、またデータ前処理のテスト
DataProcessorを単独でテストする。可能であれば、baselineとなるモデル
(SVMなど)でデータそのものの分類性能を測ったりする。scikit-learnの
Feature Selectionを使えばこのあたりのテストを簡単に実装できる。
・学習のテスト
モデル、およびデータ処理のテストがパスすることを確認した後にテストす
る(これによりモデルのバグ・データ処理に起因するバグを想定から外せる)。
lossがきちんと下がるかなどを確認する。このあたりでGPUがないと辛抱が
足りない問題が顕在化するので、GPUの使い方(Amazon GPU Instanceな
ど)はしっかりマスターしておく(Terraform/Ansibleはこの助けになる)。
複数パラメーターの設定でいろいろ回すことになるので、この際Resourceと
いう形で、どこでどのパラメーターの学習が動いているのかがわかるのはと
ても安心できる。

23. 23
ただでさえ難しい＋原因の切り分けができない
だいぶ解決
これで・・・

24. 24
ただでさえ難しい＋原因の切り分けができない
・・・

25. 25
おすすめ
単純なモデルからはじめる(scikit-learnなど)
• どのみちDataProcessorのところで必要になる
• 最終的にChainerやTensorFlowでやるにしても、ベースラインのモデルは
必要になる
• 自分でデータを用意するなら、Deepの恩恵が得られるほど集められないこ
とが多い(=使うだけ徒労になる可能性も高い)。
基礎知識はCourseraのMachine
Learningをおすすめ(英語という壁はあ
るが、現時点出ているどの書籍よりもわ
かりやすい＋日本語字幕もある)

26. 26
ぜひ
new
machine learning
life!

27. THANK YOU

28. 28
Appendix: API一覧(1/3)
Model
• constructor: モデルに必要な構成要素(隠れ層)などの定義
• forward(inference): constructorで定義した構成要素を利用し、入力を出
力にする(伝搬)プロセスを定義する。
• 学習中とそうでない場合で構成が変わる場合(Dropoutなど)、それを引数
に取る。※ここでlossを出さないこと(出してもいいが、outputもちゃんと
返す)
ModelAPI
• constructor: 最低限Modelのパスを取得し、読み込む
• predict: 配列などの一般的な変数から、Modelを利用した予測値を返す

29. 29
Appendix: API一覧(2/3)
Trainer
• constructor: modelと学習に必要なパラメーターを受け取る。
DataProcessorは、この段階か、trainのメソッド内で作成する。
• calc_loss: 最適化の対象となる誤差の計算プロセスを定義する
(TensorFlow的にはtrain_op)
• set_optimizer(build): calc_lossの最適化プロセスを定義する
• train: 学習データ、または作成済みDataProcessorを受け取り、学習の実
行(set_optimizerで作成したoptimizerのupdate)を行う。この過程で、進
捗状況を定期的にreportする。
• report: 学習の進捗状況の出力、また学習モデルの保存などを行う
DataProcessor
• constructor: データへのパスなど
• prepare: データを読み込み、後処理で必要な統計量(平均など)を計算する
• format(preprocess): 生のデータを学習・予測用にフォーマットする
• batch_iter(feed): batch size/shuffleするかどうかなどを受け取り、要求
に応じたデータを返す。iteratorとして機能する。

30. 30
Appendix: API一覧(3/3)
Resource
• constructor: 設定ファイルの保存先パスを受け取る
• get_xxxx: 設定ファイル内の所定の項目を取得する。※get(“data_path”)
というように、文字列でパラメータを受け取らないこと(利用側が環境変数
名を覚えていないといけなくなるので)。
• get_data_root
• get_model_path
• get_log_folder
• などなど
• create_trainer/create_dataprocessorという感じで、読み込んだパ
ラメーターを元に各インスタンスを生成するメソッドを持たせるとい
う手もある。