Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

36,707 views

Published on

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

Published in: Data & Analytics
  • Be the first to comment

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

  1. 1. Copyright © 2016 TIS Inc. All rights reserved. 機械学習で泣かないためのコード設計 戦略技術センター 久保隆宏
  2. 2. 2 Agenda • Who are you • TIS株式会社について • 戦略技術センターについて • 機械学習あるある物語 • 機械学習で泣かないための設計(案) • Model • Trainer • DataProcessor • ModelAPI • Resource • Appendix: API一覧
  3. 3. 3 Who are you
  4. 4. 4 業務コンサルタント出身。 化学系メーカーへのパッケージ導入や周辺業務システム開発 を手掛ける(ASP.NET VB.NET/C#)。 現在は「人のパートナーとなれるアプリケーション」の研究 開発(Python/機械学習)。 サイボウズ公認kintoneエヴァンジェリスト Qiitaのストック数ランキング 機械学習: 1位 Python: 2位 (8/18時点) icoxfog417 後輩
  5. 5. 5 TISとは?
  6. 6. 6 会社紹介 TISはTISインテックグループの中核会社となります。 TISインテックグループは多様な得意分野をもつ企業の総体であり、一体感のあるグル ープフォーメーションの下お客様のニーズにお応えします。 TIS INTEC GROUP(59社 19,393名) お客様
  7. 7. 7 TISとは?
  8. 8. 8 戦略技術センターについて(1/2) ミッション ・中長期(3~10年)的な視点からのサービスのプロトタイプ開発・検証 ・技術プレゼンスの向上(=研究活動の対外発信) サービスのプロトタイプ開発 技術プレゼンスの向上 薬剤師BOT 会議診断AI 観光ルート自動生成 etc・・・ カンファレンスへの 登壇、ハッカソンへ の参加、勉強会の開 催etc・・・
  9. 9. 9 戦略技術センターについて(2/2) ロボット 販売員 店頭での呼び込み、 定型的な商品説明を 担当 自動応答と遠隔操作の組み合わせで、接客の分業を実現 遠隔操作による 応対の引き継ぎ ロボットから応対を 引き継ぎ、一人一人 に合った接客を行う ダッシュボード ロボットの接客状況 (顧客数、商品説明へ の反応など)を確認 自動応答の 状況を報告 ・自動応答により、人の接客負荷を低減 ・遠隔操作により、東京にいながら北海道の店舗の応対を行う、と いったことが可能になる+多言語対応が可能な販売員が様々な店舗で 応対するといったことも可能になります。
  10. 10. 10 機械学習あるある物語
  11. 11. 11 MNISTとかのExampleを動かしてうまく動いているとき →NEXT: 自分のデータで試してみよう!
  12. 12. 12 自分で集めたデータでうまく動かなくて戸惑っている時 →NEXT: でもここから本番、がんばるぞい!
  13. 13. 13 修正したら繰り出される謎の例外 初期化の方法・学習率・レイヤ数・・・いろいろなパラメーター 精度が出ない・・・データがないせい?モデルが自分のデータに合わないせい? データの前処理→こんにちは線形代数
  14. 14. 14 まあ(Example)動いたしな? 中途半端だけどおしまいにする(完)
  15. 15. 15 機械学習の難しさ 機械学習は、うまくうごかないときに考えられる理由がたくさんある。 ・データが悪いのか ・そもそものデータが良くない(データの量・データの質) ・前処理に問題がある ・モデルが悪いのか ・バグがある(伝搬が上手くいっていないなど) ・構成が悪い ・(逆に間違っててもそれなりに動くことがあり、混乱を助長する) ・学習方法が悪いのか ・ノードの初期化方法、学習率、学習率低減のタイミングetc→職人芸 ・辛抱が足りない(明日になれば学習が進んでるかも?) モデルや学習方法の書き換えには、機械学習の理論的な理解が必要になる場 面も多い。それぞれのフレームワークのクセにもかなり翻弄される(Example だけでなく、ライブラリ内部のコードを読まないといけないことになること も多い)。
  16. 16. 16 ただでさえ難しい+原因の切り分けができない
  17. 17. 17 機械学習で泣かないための設計(案)
  18. 18. 18 ただでさえ難しい+原因の切り分けができない まずこっちを解決
  19. 19. 19 構成 Model DataProcessor Resource ModelAPI Trainer ・Modelは、機械学習モデルの定義を行う ・ModelAPIは、外部に向けて予測機能などのAPIを公開する。 ・Trainerは、Modelの学習を担当する。 ・DataProcessorは、データの読み込みと前処理を担当する ・Resouceは、全体で必要になるパラメーターを管理する
  20. 20. 20 構成のポイント(1/2) ・TrainerとDataProcessorの分離 Trainerからデータに関する処理を独立させる。 忘れがちだが、予測を行う際もデータの前処理は必要 になる(例:画像の平均化など)。この処理を Trainerに含めていると、学習以外の処理でもTrainer を呼び出すことになるほか、Trainerはおおむねバッ チでデータを入れるので予測処理(データ一件)と処理 が合わない。 ・パラメーターはResourceで一元管理を行う learning rateを始めとした学習パラメーター、また 学習モデルの保存先、データのロード元など、機械学 習では色々なパラメーターが必要になる。 これらはyamlやjsonといったファイルにまとめて管 理するようにし、その読出しを行う担当として Resourceを置く。 最重要
  21. 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. 22 テストの実施 ・モデルのテスト ModelAPIと一体でテストし、入力からきちんと値が出力されることを確認。 ・データ、またデータ前処理のテスト DataProcessorを単独でテストする。可能であれば、baselineとなるモデル (SVMなど)でデータそのものの分類性能を測ったりする。scikit-learnの Feature Selectionを使えばこのあたりのテストを簡単に実装できる。 ・学習のテスト モデル、およびデータ処理のテストがパスすることを確認した後にテストす る(これによりモデルのバグ・データ処理に起因するバグを想定から外せる)。 lossがきちんと下がるかなどを確認する。このあたりでGPUがないと辛抱が 足りない問題が顕在化するので、GPUの使い方(Amazon GPU Instanceな ど)はしっかりマスターしておく(Terraform/Ansibleはこの助けになる)。 複数パラメーターの設定でいろいろ回すことになるので、この際Resourceと いう形で、どこでどのパラメーターの学習が動いているのかがわかるのはと ても安心できる。
  23. 23. 23 ただでさえ難しい+原因の切り分けができない だいぶ解決 これで・・・
  24. 24. 24 ただでさえ難しい+原因の切り分けができない ・・・
  25. 25. 25 おすすめ 単純なモデルからはじめる(scikit-learnなど) • どのみちDataProcessorのところで必要になる • 最終的にChainerやTensorFlowでやるにしても、ベースラインのモデルは 必要になる • 自分でデータを用意するなら、Deepの恩恵が得られるほど集められないこ とが多い(=使うだけ徒労になる可能性も高い)。 基礎知識はCourseraのMachine Learningをおすすめ(英語という壁はあ るが、現時点出ているどの書籍よりもわ かりやすい+日本語字幕もある)
  26. 26. 26 ぜひ new machine learning life!
  27. 27. THANK YOU
  28. 28. 28 Appendix: API一覧(1/3) Model • constructor: モデルに必要な構成要素(隠れ層)などの定義 • forward(inference): constructorで定義した構成要素を利用し、入力を出 力にする(伝搬)プロセスを定義する。 • 学習中とそうでない場合で構成が変わる場合(Dropoutなど)、それを引数 に取る。※ここでlossを出さないこと(出してもいいが、outputもちゃんと 返す) ModelAPI • constructor: 最低限Modelのパスを取得し、読み込む • predict: 配列などの一般的な変数から、Modelを利用した予測値を返す
  29. 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. 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という感じで、読み込んだパ ラメーターを元に各インスタンスを生成するメソッドを持たせるとい う手もある。

×