【Dll171201】深層学習利活用の紹介 掲載用
•Download as PPTX, PDF•
1 like•587 views
Deep Learning Lab 12/1 Nagoya AisinAW Presentation
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 【Dll171201】深層学習利活用の紹介 掲載用
Similar to 【Dll171201】深層学習利活用の紹介 掲載用 (20)
More from Hirono Jumpei
More from Hirono Jumpei (20)
Recently uploaded
Recently uploaded (7)
【Dll171201】深層学習利活用の紹介 掲載用
- 2. 2017/12/1 製品設計開発から製造までの開発業務全体の『情報と行動』を集約して知見として活用できる事を目指した業務アプリケーション開発プラットフォーム 1. 全開発プロセス、成果物に対しトレーサビリティを確保し、海外拠点を含む全拠点に対しリアルタイムでの見える化を実現する 2. 開発プロセス100%遵守をシステムで担保すると同時に、継続的プロセス改善を迅速に支援する 3. クラウドの活用、APIの実装により海外拠点、顧客とのシームレスでセキュアな連携を実現する。また最新の開発環境を準備し、スピード開発を実現する 開発支援システム v.Platform Product Development Project Management 全社基盤 人事情報基盤 チケット基盤 承認基盤 構成管理基盤 v.Spec DNA EDI v.Project 課題管理 進捗管理 リスク管理 コスト管理 品質管理 要求 仕様 要件定義 設計・開発 テスト・評価 v.Reporting (BI) v.Platform v.Entry v.PlatformAPI v.DocMgr ・・・設計帳票④ 設計帳票① 設計帳票⑤ 設計帳票⑥ 設計帳票② 設計帳票③ v.Issue v.Progress v.Risk v.Cost v.Quality v.Traceability v.Box 5つの指標(進捗、リ スク、課題、コスト、 品質)を可視化 5W2Hの明確化と 成果物の管理 要求・要件単位で 成果物をトレース プロジェクト情報の 一元管理 設計帳票の管理 (各アプリと連携) データ管理 全社基盤との連携 データ授受 個人Binder
- 3. 2017/12/1 Activity Log 次の行動を示唆 人の行動から、次の行動を支援 する 問題・課題状況を見える化 リアルな進捗状況が分かる、進 捗の遅れの理由が分かる 基本情報 ◦ 4W1H ◦ Who(誰が) ◦ When(何時) ◦ Where(どの情報) ◦ What(件名) ◦ How(Create、Read、Update、Delete、Search ⇒ CRUDS) 作成(C)、更新(U)、削除(D)した場合の詳細項目 ◦ 共通項目 ◦ 期日(From-To) ◦ 状態(From-To) ◦ 担当者(From-To) ◦ Why(どんな理由で) ◦ コメント内容 ◦ 添付内容 ◦ 検索条件 人の働き方を分析する 情報に対する変化に気づき、次 の行動がしやすくなる 人の行動をログとして全て残し、人の活動を見える化し、分析し、行動支援に活用する ■ログとして残すアクティビティ ■活用方法(案) 見える化 分析 行動支援 e.g. 機能ごとの作成工数 e.g. 工数大の要因分析 e.g. 参考になりそうな既存ドキュ メントを候補として挙げる RDBだけでなく、Graph DBも使用することで高速検索の実現 し、またデータの繋がりから新しい知見を得ることが可能になる ＋位置情報
- 5. 2017/12/1 目次 ・自部署の紹介 ・画像認識の取り組み ・まとめ・今後の課題 ・ChainerMN with Azure の環境構築で苦労したこと
- 8. 2017/12/1 実走シミュレータにより信頼性コースを周回させ、試験記録を残す (定時後～翌朝出勤まで約15時間) 信頼性試験の詳細 ～実走シミュレータ自動試験機と検出方法～ 動画のビデオチェックで画像・音声の良否を判定 挙動撮影 試験記録 属人的な検出方法となっており、自動判定技術を確立できていない”描画異常”を自動化したい 発生し得る異常 (検出したい異常) 異常例 要求機能が動作しない アイコン押下しても動作しない レスポンス時間を満たさない アイコン押下した後、次の画面への遷移が遅い 映像系 リセット 不意の再起動 黒画 ロック フリーズ 描画異常 不要な文字・矩形，砂嵐，何本も案内ルートが描画される 音声系 無音 爆音 音切れ 音色 イントネーション ナビ画面 ナビ画面 現在地マーク
- 10. 2017/12/1 問題設定 深層学習を利活用し、正常画像の回帰問題(AutoEncoder)とした 当初、静止画パターンマッチングによる自動判定も考えた ⇒ 煩雑になりそうなので、一旦保留 ・マッチングさせたい正常画像が無い区間(撮影間隔)がある ・マッチングさせたい正常画像を探し出すのに時間がかかる 12,000枚×？周回分 マッチング 画像無し区間画像無し区間 ボトルネック 汎化性能に期待して、 深層学習を選択 判定速度に期待して、 深層学習を選択 ナビ画面 ナビ画面 ナビ画面 ナビ画面A ナビ画面A’
- 11. 2017/12/1 問題設定 犬 人 猫 車 顔 分類の概念 判定結果 正常：96% 異常： 4％ ・正常画像を学習させた ・異常画像は学習させない 次に、正常画像と異常画像を使った分類問題を解くことも考えた ⇒ 異常を正常と判断するので、失敗 (一旦保留) 分類問題 ⇒ あるデータを確率的にクラスに分ける ・出力値(確率値)の高いクラス(正常，異常)がそのまま答え(判定結果)となる ・各クラスのデータ(正常画像，異常画像)が同程度あった方が良い [結果] 信頼性の確保フェーズでは、基本的に正常であることの確認のため、 正常画像：多い，異常画像：少ない データセットとなるが、実験してみた 深層学習を利活用し、正常画像の回帰問題(AutoEncoder)とした ナビ画面 異常 (不要な矩形)
- 13. 2017/12/1 ナビ画面ナビ画面 画像の良否判定 F分布の確率密度 閾値 正常 異常 前処理 F検定AutoEncoder 画像収集 学習 予測 良否判定リサイズ F検定 正常 or 異常 の分散 V1 (入力) と、正常の分散 V0 (出力) から、 検定統計量 F値=V1/V0 を計算し、有意水準 α=0.01 の閾値と比較して、 小さければ、正常，大きければ、異常 と判定する F 値 分散 V1 分散 V0 正常正常 or 異常 𝐹 = 𝑉1 𝑉0 F < 閾値なら、 閾値 ≦ F なら、 検定統計量 正常画像のみを学習させた
- 14. 2017/12/1 データセット データセット1 データセット2 画面の種類 7種類 (地図，目的地設定など) 2種類 (地図，高速略図) 画像枚数 10,000枚 12,490枚 画像サイズ 800×480 1,280×480 画像リサイズ 256×256 256×96 (縦横比を保持)
- 15. 2017/12/1 Step1．正常画像を出力する生成器を作る 学習モデル モデルの概念図 パラメータのパターン数 MLPモデル ・AutoEncoderの初歩的モデル ・全層MPLによるモデル ・ノイズ除去などに使われています 5パターン ・構造：9層,11層 ・パラメータ：素子数 25～210 個 AlexNetモデル ・分類問題を解く著名なモデル ・Encoder部分(モデルの前半)を 畳込み層化。画像の空間的情 報を特徴化し、判定性能UP 1パターン FCNモデル ・Seg-Net，U-NETを参考 ・Decoder部分(モデルの後半)を 逆畳込み層化。空間的情報を 復元し、性能UP 4パターン ・構造：畳込み層・逆畳込み層 9層,11層,13層 ・パラメータ：特徴マップ数 24～ 211 枚 入 力 ： ：： 出 力： 畳込み層 逆畳込み層 入 力 出 力 入 力 出 力 ： 畳込み層 画像生成器のモデル構造
- 16. 2017/12/1 Step1．正常画像を出力する生成器を作る ～データセット1～ 学習回数20,000回の学習誤差カーブ ⇒ 徐々に下がることで、モデルの成熟度を確認 学習モデル 学習誤差カーブ(代表) MLPモデル ・GPU：4基 ・バッチサイズ：500枚/GPU AlexNetモデル ・GPU：2基 ・バッチサイズ：100枚/GPU FCNモデル ・GPU：4基 ・バッチサイズ：75枚/GPU epoch 平均二乗誤差 epoch 平均二乗誤差 epoch 平均二乗誤差
- 17. 2017/12/1 Step2．学習データを正しく正常と判定するかを確認する ～データセット1～ 学習モデル 判定性能 結論 参考 (代表) 目標 結果 F値グラフ MLPモデル 90％ 以上 74％ × AlexNetモデル 90％ 以上 79％ × FCNモデル 90％ 以上 94％ ○ 時系列に取得される画像番号 時系列に取得される画像番号 時系列に取得される画像番号 正常 異常 FCNモデルのみ、判定性能目標をクリア
- 18. 2017/12/1 学習モデル 判定性能 結論 参考 (代表) 目標 結果 F値グラフ FCNモデル 90％ 以上 62％ × Step3．未学習データを正しく良否判定するかを確認する ～データセット1～ 時系列に取得される画像番号 学習データにないパターンの画像について、良品判定できていない 考察 同じ走行させ、同じ操作をしても、微妙な処理タイミングの差で、良品と判定できない (例) ・画面遷移 ・POI描画 (画面遷移に伴いアニメーション表示される) ・地図スクロール (スクロール途中に更にスクロールさせる) ・縮尺変更時 ・リルート 仮説 もし、左記が無ければ、判定性能が上がるのか？ ⇒ もっと単純なデータセット2で実験してみる 正常 異常
- 19. 2017/12/1 実験結果 ～データセット2～ 回帰問題(AutoEncoder)を解くことで、解決する目途が立った epoch 平均二乗誤差 時系列に取得される画像番号時系列に取得される画像番号 データセット2 画面の種類 2種類 (地図，高速略図) 画像枚数 12,490枚 画像サイズ 1,280×480 画像リサイズ 256×96 (縦横比を保持) 学習モデル FCNモデル ミニバッチサイズ 45枚/GPU 学習回数 20,000回 Step1．正常画像を出力する生成器を作る Step2．学習データを正しく正常と判定するかを確認する ⇒ ○ 目標 90％ 結果 100％ Step3．未学習データを正しく良否判定するかを確認する ⇒ ○ 目標 90％ 結果 99％
- 20. 2017/12/1 実験結果 ～データセット2～ 過剰判定気味ではあるが、人工的に作った描画異常の検出もできた 時系列に取得される画像番号 Step3．未学習データを正しく良否判定するかを確認する (詳細) ⇒ ○ 目標 90％ 結果 99％ 実走シミュレータ走行S G 正常 異常 異常 (青い矩形) 正常を異常 と過剰判定
- 21. 2017/12/1 学習時間 方策 ・開発環境の積極的なVerUp ⇒ Chainer，CUDA，cuDNNのVerUp 実施済 ・ChainerのTrainerの利用 ⇒ データ読み込みの並列化など高速化のための工夫が入っている 実施済 ・GPUを増やす ⇒ ChainerMN with Azure を使う 実施中 ・画像の前処理を工夫する ⇒ 画面の種類毎に判定器を作れれば、問題の難易度は下がる 検討中 Step1．生成器作りにおける問題 ～学習時間の短縮化～ データセット 学習モデル 学習時間 データセット1 ・256×256 ・10,000枚 MLPモデル 7日 AlexNetモデル 14日 FCNモデル 33日 データセット2 ・256×96 ・12,490枚 FCNモデル 19日 評価運用を鑑みると可能な限り学習時間を短縮したいので解決策を調査 ⇒ MS様×PFN様と意見交換 (’17/8/25)
- 22. 2017/12/1 ChainerMN with Azure を使う Step1 Step2 (https://github.com/azmigproject/ChainerMN/tree/master) Step3 ChainerMNによるMNIST学習の確認 ChainerMN with Azure の環境構築は簡単です cmn4 Infini Band K80×4基 K80×4基 K80×4基 K80×4基 jumpbox cmn1 cmn2 cmn3 VPN+SSH接続
- 24. 2017/12/1 学習完了までの予測時間 ※ 利用料金 学習時間短縮の目途付け 学習時間(日) GPUを増やすことで、ナビ静止画でも学習完了までの時間短縮の目途が立った！ GPUs GPUs ノード数 料金 8基 2ノード 約2万円/日 16基 4ノード 約4万円/日 32基 8ノード 約8万円/日 48基 12ノード 約12万円/日 データセット2 画面の種類 2種類 (地図，高速略図) 画像枚数 12,490枚 画像サイズ 1,280×480 画像リサイズ 256×96 (縦横比を保持) 学習モデル FCNモデル ミニバッチサイズ 45枚/GPU 学習回数 20,000回
- 25. 2017/12/1 実験結果 with Azure×ChainerMN 学習時間は速いが、モデルが未成熟で誤判定が多い ⇒ 今後、GPU数・バッチサイズのバランスを目指す epoch 平均二乗誤差 時系列に取得される画像番号 時系列に取得される画像番号 Step1．正常画像を出力する生成器を作る Step2．学習データを正しく正常と判定するかを確認する ⇒ 参考値 目標 90％ 結果 80％ Step3．未学習データを正しく良否判定するかを確認する ⇒ 参考値 目標 90％ 結果 73％ ・48GPUs(12ノード) ・バッチサイズ：45 ・48GPUs(12ノード) ・バッチサイズ：16 https://research.preferred.jp/2017/02/chainermn-benchmark-results/
- 26. 2017/12/1 まとめ・今後の課題 ・回帰問題(AutoEncoder)を解くことにより、正常画像のみで異常検知できる目途が立った ⇒ 複雑な画像データセット(信頼性試験)へのレベルアップを目指す ・FCNモデル以外のモデルを検討 ⇒ Variational AutoEncoder にトライ ・ChainerMN with Azure を使うことで、学習時間の短縮の目途が立った ⇒ 判定性能との両立は、GPU数・バッチサイズのバランスを目指す ・画像の前処理を工夫 ⇒ RGBからグレースケールに変更することで、学習時間の更なる短縮化
- 27. 2017/12/1 ChainerMN with Azure の環境構築で苦労したこと > export PATH=/opt/anaconda3/bin:${PATH} > export LD_LIBRARY_PATH=/usr/local/lib: ${LD_LIBRARY_PATH} > source /opt/intel/compilers_and_libraries/linux /mpi/intel64/bin/mpivars.sh intel64 > mpirun -hosts 10.0.0.5,10.0.0.6 -ppn 4 -n 8 -env I_MPI_DAPL_TRANSLATION_CACHE=0 -env I_MPI_FABRICS=shm:dapl -env I_MPI_DAPL_PROVIDER=ofa-v2-ib0 -env I_MPI_DYNAMIC_CONNECTION=0 -env I_MPI_FALLBACK_DEVICE=0 python train_mnist.py -g --communicator non_cuda_aware 実行コード 実行結果 ⇒ エラーが発生し、上手くいかない Azure×ChainerMNを使う際、今後も発生しそうなリスクを共有
- 28. 2017/12/1 ChainerMN with Azure の環境構築で苦労したこと CUDAとCuPyの不整合 ⇒ CuPyの修正 Deploy Templateの修正 MS様、迅速かつ丁寧なサポート、ありがとうございます！ Azure×ChainerMNを使う際、今後も発生しそうなリスクを共有