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.
本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物です。
2004	
|	
2011	
2011	
|	
2014	
2014	
|	
SEサービス プリセールス 	
@	So+ware	Research	Associates,	Inc.	
システム構築、客先のシステム運用、提案でキャリアをスタート	...
様々なステージとルール	
•  16のステージ、4つのルール	
•  勝利に向けチームで立ち向かう	
	
多様な楽しみ方	
•  90以上のブキから好きなものを	
選んでプレイ
シューティングゲームの一種	
–  第三者視点(TPS)	
スプラトゥーンの特徴	
–  自分たちの“ナワバリ”を広げないと進めない	
–  「銃」タイプ以外に「バケツ」「ローラー」など、様々なブキがある	
様々なプレイ層	
–  小学校(クラ...
Wii	U用ゲーム「スプラトゥーン」支援ソフト	
– HDMIキャプチャを介して情報を自動取得	
– 数値・文字列データとして認識	
– お好みの方法で蓄積、出力	
Nintendo	WiiU	
& スプラトゥーン	
データ化	
{	“kill...
HDMI	
キャプチャデバイス	
IkaLog	実行用PC
ARM搭載	
FPGAボード	
10月より開発開始
録画ソフト 自動制御	
AmaRecTV	
カラーLED連動	
Fluentd	転送	
スプラトゥーン戦績記録SNS	
CSV/JSONファイル保存	 スクリーンショット保存	
SNS投稿	
IkaLog
•  IkaLogユーザのひとり	@fetus_hina	さんが開発、
運営する	Web	サイト	
•  IkaLog	からのプレイデータを受け取り、	
表示・集計する	
•  IkaLogからの投稿を分析し	
統計情報、トレンドを表示
17	https://stat.ink/
自分が倒されて	
行動不能だった時間	
イカ(味方/敵 計8匹)の生死状況	
チームのスペシャル発動、キル/デス	
自分の塗り面積	
https://stat.ink/
目標物の	
確保状況	
敵チームの	
ポイント	
自チームの	
ポイント	
逆転の瞬間	
https://stat.ink/
https://stat.ink/
https://stat.ink/	
ナワバリバトル – 互いの干渉が少ない	
ガチエリア – “相手を倒しつつ生存”がカギ	
ガチホコ – 全体的に乱戦になりやすい	
ガチヤグラ – 全体的に乱戦になりやすい
https://stat.ink/
https://stat.ink/	
.96ガロンデコ	
アップデートをきっかけにユーザー数が激減	
ロングブラスターカスタム	
夏以降、人気を博しているブキのひとつ
データソース	hbps://stat.ink/endre/user	
【ピーク】	24時間あたり370ユーザ、約15,000ゲーム	
2016年11月時点にて	
24時間あたり 平均100ユーザ超が利用、平均2500ゲームを処理	
最後の“フェ...
•  2014年INTEROPでの”Chainer”デモがきっかけ	
–  深層学習のプレゼンテーションみて「凄いな」と思った	
–  “何か面白いソフトウェアを作りたいな”	
–  ちょうどスプラトゥーンの発売直後だった	
•  未経験からの...
0"
2"
4"
6"
8"
0" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10"
Kill 	
 Win/Lose
Win" Lose"
0"
1"
2"
3"
4"
5"
1" 2" 3" 4" 5" 6" 7" 8" 9" ...
ここまでするなら	
自動化できるツールを作ろう!
ソース映像	 マスク画像	 加算画像	
+	
=	
=	
正しいマスクを加算すると画像が真っ白になる	
違うマスクを加算すると画像が真っ白にならない
32
34
•  ゲーム中で使われているフォントは2種類	
–  画面上に現れる数字フォントは1種類	
–  フォントが判っているのだから、認識できるはず	
•  試行錯誤の後、既存OCRエンジンの利用は断念	
–  機械学習ベースの認識エンジンを実装
• 
• 
– 
– 
– 
– 
– 
文字として	
認識されないことも
●	
●	●	
●	
■	
■	
■	
■	
?	
▲	
▲	
▲	
▲	
?	
?	
?	
?	
とてもシンプルな機械学習	
	
標本    の傍にあるサンプルがどれかで	
	
分類する。	
	
	
K=1	の場合は最寄りのサンプルがある	
...
•  GitHub にソースあり	
–  https://github.com/hasegaw/opencv_knn_example/	
•  三つのパターン ○ △ □ で画像を生成し、

kNNで学習する	
•  ランダムに ○ △ □ か...
問題図形をランダムに
生成	
K近傍法を用いて、学習済みの	
図形から、もっとも近い図形を調べる	
仕分ける	
○	 △	 □	
○	学習済み図形	
○	 △ □
1)画面上の数字部分(位置固定)を切り抜き	
2)縦・横のヒストグラムを生成し各文字の位置を特定	
	
	
3)文字を検出用サンプルのサイズ(等幅)にリサイズ、

	 	 	二値化	
	
4)KNNにより既知の検出用サンプルと照らし合わせて

...
•  基本は数字の認識と一緒	
•  認識率はそれほど高くないが、認識回数で精度を確保	
–  IkaLogは現在毎秒10フレームほど解析している	
–  下記例では、死因のメッセージ合計49fを解析し、

最多頻度は96gal_deco (1...
47
スプラトゥーンのブキ 59種類(スライド作成当時)
• 
• 
• 
• 
他の装備品が被っている	 保護色(まだマシ)	 保護色(マジつらい)
(まだバグがあった頃のバージョンの表示なので色がずれているけども)	
こんなかんじで特徴量を抽出していた
入力画像	 ラプラシアン
フィルタ適用	
グレースケール	 K近傍法による	
クラス分類	
Thanks	@itooon	
sschooter_collabo	
	
スプラシューター	
コラボ	
特徴画像
52
長所	
– 色の違いに鈍感	
– 画像の「形」でざっくり認識	
短所	
– 解像度の違いに弱い	
– 似た形の画像を正しく分類できない
スクリーンでは視認しにくいが、ユーザーが様々な解像度の画像を送ってくる「現実」
56
オリジナルのブキ	
(longblaster)	
カスタムバージョン	
(longblaster_custom)	
更に追加(Apr	2016)	
(longblaster_necro)	
出力される特徴量に被りが発生し、	
特徴量算出アルゴリ...
longblaster_necro	
longblaster_custom	
longblaster	
IkaLog内部で使用する特徴量を	
主成分分析(PCA)で2次元空間に	
投影したもの	
出力される特徴量に被りが発生し、	
特徴量算出ア...
ゲーム終了時に表示される別の画面	
画面上に表示される「ギアパワー」画像を分類する	
	
KNNの問題点	
・「メイン」ギアパワーと「サブ」ギアパワーで	
 画像の大きさが異なる	
・ユーザー環境によって解像度が異なる	
・ブキ画像同様、状況に...
• 
•  ❌ ⭕
– 
– 
– 
• 
• 
(本スライド中の画像の一部はイメージであり実際のものとは異なります。)	
	
オブジェクト	
ストレージ	
	
作業用	
インスタンス	
on	IaaS	
1年以上のデータを蓄積	
総データ量 4TB以上	
	
IkaLogユーザ	 stat....
•  機械学習/深層学習の精度は前処理の精度に影響を受ける	
•  画像のズレ/ゆがみ対策(自動補正)を実装し、対策

テンプレートマッチング、最小二乗法を用いて最適候補を選定	
アスペクト比が壊れている	 なぜか画像がズレている	リファレンス...
Thanks	@itoooon
長所	
– ニューラルネットワークにより認識率が大幅に向上	
短所	
– データが大きくなる(例:100MB~400MB)	
– Windows版に組み込みしづらい	
PythonスクリプトをEXE化する「Py2EXE」と

ディープラーニング...
ゲーム終了時のスクリーンショット	
stat.ink	から投稿データを深夜バッチで受け取り	
約4000枚/日	
認識対象となるブキ画像	
約24000サンプル/日	
Chainer	による	DNN	で自動的に分類	
スクリーンショットからサン...
•  入力値と出力値	
–  入力値: RGBもしくはHSVの色情報	(47*45*3=6,345	units)	
–  出力値: 各クラスの出力値(91	units,	So+maxを適用する)	
–  使用する結合:全結合のみを使用(理由は後...
0	
1	
2	
3	
..	
..	
n	
0	
1	
2	
3	
…
89	
90	
Input	Layer	 Output	Layer	Hidden	Layer	
52gal	
52gal_deco	
96gal	
96gal_deco	...
69
•  Azure	ML上でアルゴリズムの事前検証	
–  小さなデータセットを使用し分類器を作成	
–  入力層:	ピクセル情報(をPCAにかけたもの)	
–  隠れ層:	1層、150ユニット(暫定)	
–  出力層:	各クラス(のはず)	
•...
72
•  Azure	MLで得た結果をベースに、IkaLogに組み込む
モデルを作成する	
–  stat.inkに投稿された90万点のブキ画像を教師データとして用意	
–  フレームワーク「Chainer」を使用	
–  GPUの恩恵も受けられる...
CPU	 GPU	 #	of	
jobs	
Throughput	
(images/s)	
GPU	Time	
/epoch	(s)	
RelaJve	
perf.	
(virtual)	
Core	i7-4790S	
定格3.2GHz	
使用...
75	
目的と手段が入れ替わる瞬間
76
77
CPU	 GPU	 #	of	
jobs	
Throughput	
(images/s)	
GPU	Time	
/epoch	(s)	
RelaJve	
perf.	
(virtual)	
Core	i7-4790S	
定格3.2GHz	
使用...
パラメータチューニングのための事前学習ジョブ	
–  様々な隠れ層の構成(パーセプトロン数)で学習を行い、	
モデルファイルサイズが小さくなるような構成を探索	
–  4ジョブ同時投入(バッググラウンドプロセス化→	wait)	
–  ジョブ実...
K近傍法	 既存ImageNet	 新ニューラルネット	
認識効率	 一部ユーザでは	
低い	
99.99+%	
	
99.99+%	
	
モデルサイズ	 20MB(現時点)	 400MB	(AlexNet)	
100MB	(GoogleNet...
•  ニューラルネットの順伝播処理を新規実装	
– 既存のフレームワークは組み込まない	
(Windowsユーザ対策)	
– 高度な機能を実装すると面倒なため、最低限の	
機能を絞り込んで実装(LinearFuncdon,	ReLU)	
hbp...
•  ニューラルネットを他の用途にも適用	
–  ブキ分類器のほか、ギアパワー分類器を作る(優先度 高)	
–  ガチホコのタッチダウン分類器を作る	
–  戦況評価関数にRNNが使えるのではないか	
•  本当に必要なデータセットの選定	
–...
•  IkaLogでは、複数の機械学習アプローチを適用している	
–  リアルタイム処理では、おもにK近傍法(KNN)を利用	
–  入力画像にロバストな分類器を作るため、深層学習を利用	
•  特徴量の自動抽出、何十万の画像から自動的な学習	...
らぴす	(2000-2014)
©	07strikers
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
#IkaLog によるスプラトゥーンの画像解析と機械学習
Upcoming SlideShare
Loading in …5
×

#IkaLog によるスプラトゥーンの画像解析と機械学習

7,734 views

Published on

https://nsstudy.connpass.com/event/42602/
「ディープラーニングとGPUコンピューティング」&「スプラトゥーン画像解析」 #NSStudy 9

対バンが NVIDIA さんでした。

Published in: Technology
  • Be the first to comment

#IkaLog によるスプラトゥーンの画像解析と機械学習

  1. 1. 本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物です。
  2. 2. 2004 | 2011 2011 | 2014 2014 | SEサービス プリセールス @ So+ware Research Associates, Inc. システム構築、客先のシステム運用、提案でキャリアをスタート → プリセールス〜PMを担当するインフラエンジニア システムアーキテクト @ Trigence Semiconductor, Inc. 、ほか エンベデッド開発支援、ITシステム管理、機械学習支援まで 多岐に対応 セールスエンジニア @ Fusion-io, Inc. 高速半導体ストレージ ioDrive / ioMemory シリーズの SE として活動
  3. 3. 様々なステージとルール •  16のステージ、4つのルール •  勝利に向けチームで立ち向かう 多様な楽しみ方 •  90以上のブキから好きなものを 選んでプレイ
  4. 4. シューティングゲームの一種 –  第三者視点(TPS) スプラトゥーンの特徴 –  自分たちの“ナワバリ”を広げないと進めない –  「銃」タイプ以外に「バケツ」「ローラー」など、様々なブキがある 様々なプレイ層 –  小学校(クラスで半分がスプラトゥーン所有)〜大人まで –  塗らないと勝てない (“相手を倒す”ことが最終目的ではない) –  本気でやってる人たちは怖い
  5. 5. Wii U用ゲーム「スプラトゥーン」支援ソフト – HDMIキャプチャを介して情報を自動取得 – 数値・文字列データとして認識 – お好みの方法で蓄積、出力 Nintendo WiiU & スプラトゥーン データ化 { “kills”: 5, “deaths”: 1 } IkaLog 外部ツールへ出力 (棒読みちゃん等) 出力例
  6. 6. HDMI キャプチャデバイス IkaLog 実行用PC
  7. 7. ARM搭載 FPGAボード 10月より開発開始
  8. 8. 録画ソフト 自動制御 AmaRecTV カラーLED連動 Fluentd 転送 スプラトゥーン戦績記録SNS CSV/JSONファイル保存 スクリーンショット保存 SNS投稿 IkaLog
  9. 9. •  IkaLogユーザのひとり @fetus_hina さんが開発、 運営する Web サイト •  IkaLog からのプレイデータを受け取り、 表示・集計する •  IkaLogからの投稿を分析し 統計情報、トレンドを表示
  10. 10. 17 https://stat.ink/
  11. 11. 自分が倒されて 行動不能だった時間 イカ(味方/敵 計8匹)の生死状況 チームのスペシャル発動、キル/デス 自分の塗り面積 https://stat.ink/
  12. 12. 目標物の 確保状況 敵チームの ポイント 自チームの ポイント 逆転の瞬間 https://stat.ink/
  13. 13. https://stat.ink/
  14. 14. https://stat.ink/ ナワバリバトル – 互いの干渉が少ない ガチエリア – “相手を倒しつつ生存”がカギ ガチホコ – 全体的に乱戦になりやすい ガチヤグラ – 全体的に乱戦になりやすい
  15. 15. https://stat.ink/
  16. 16. https://stat.ink/ .96ガロンデコ アップデートをきっかけにユーザー数が激減 ロングブラスターカスタム 夏以降、人気を博しているブキのひとつ
  17. 17. データソース hbps://stat.ink/endre/user 【ピーク】 24時間あたり370ユーザ、約15,000ゲーム 2016年11月時点にて 24時間あたり 平均100ユーザ超が利用、平均2500ゲームを処理 最後の“フェス“ (ゲーム内イベント)
  18. 18. •  2014年INTEROPでの”Chainer”デモがきっかけ –  深層学習のプレゼンテーションみて「凄いな」と思った –  “何か面白いソフトウェアを作りたいな” –  ちょうどスプラトゥーンの発売直後だった •  未経験からのチャレンジ –  OpenCV経験 3時間ぐらい –  機械学習/ディープラーニング経験 なし
  19. 19. 0" 2" 4" 6" 8" 0" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10" Kill Win/Lose Win" Lose" 0" 1" 2" 3" 4" 5" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10" 11" Death Win/Lose" Win" Lose" 0.0%$ 2.0%$ 4.0%$ 6.0%$ 8.0%$ 10.0%$ 12.0%$ 14.0%$ *5$ *4$ *3$ *2$ *1$ 0$ 1$ 2$ 3$ 4$ 5$ K*D
  20. 20. ここまでするなら 自動化できるツールを作ろう!
  21. 21. ソース映像 マスク画像 加算画像 + = = 正しいマスクを加算すると画像が真っ白になる 違うマスクを加算すると画像が真っ白にならない
  22. 22. 32
  23. 23. 34
  24. 24. •  ゲーム中で使われているフォントは2種類 –  画面上に現れる数字フォントは1種類 –  フォントが判っているのだから、認識できるはず •  試行錯誤の後、既存OCRエンジンの利用は断念 –  機械学習ベースの認識エンジンを実装
  25. 25. •  •  –  –  –  –  –  文字として 認識されないことも
  26. 26. ● ● ● ● ■ ■ ■ ■ ? ▲ ▲ ▲ ▲ ? ? ? ? とてもシンプルな機械学習 標本    の傍にあるサンプルがどれかで 分類する。 K=1 の場合は最寄りのサンプルがある クラスに分類される。 K=3 の場合は近くに3つのサンプルがある クラスに分類される。
  27. 27. •  GitHub にソースあり –  https://github.com/hasegaw/opencv_knn_example/ •  三つのパターン ○ △ □ で画像を生成し、
 kNNで学習する •  ランダムに ○ △ □ から画像を生成し、その画像 の種類を判定する –  KNN を用いてそれに近い画像を見つけ出す –  見つけた画像の種類から、問題図形の種類を特定
  28. 28. 問題図形をランダムに 生成 K近傍法を用いて、学習済みの 図形から、もっとも近い図形を調べる 仕分ける ○ △ □ ○ 学習済み図形 ○ △ □
  29. 29. 1)画面上の数字部分(位置固定)を切り抜き 2)縦・横のヒストグラムを生成し各文字の位置を特定 3)文字を検出用サンプルのサイズ(等幅)にリサイズ、
 二値化 4)KNNにより既知の検出用サンプルと照らし合わせて
 認識する
  30. 30. •  基本は数字の認識と一緒 •  認識率はそれほど高くないが、認識回数で精度を確保 –  IkaLogは現在毎秒10フレームほど解析している –  下記例では、死因のメッセージ合計49fを解析し、
 最多頻度は96gal_deco (18f, 36%) だった → 結果的に正解 votes={ 'supershot': 6, 'carbon_deco': 1, 'bucketslosher': 1, 'octoshooter_replica': 1, 'splashshield': 1, 'sshooter_collabo': 5, 'hotblaster': 2, 'pablo': 1, 'nzap89': 6, 'sharp_neo': 3, 'hotblaster_custom': 2, '96gal_deco': 18, '52gal': 1, 'hokusai': 1 }
  31. 31. 47
  32. 32. スプラトゥーンのブキ 59種類(スライド作成当時)
  33. 33. •  •  •  •  他の装備品が被っている 保護色(まだマシ) 保護色(マジつらい)
  34. 34. (まだバグがあった頃のバージョンの表示なので色がずれているけども) こんなかんじで特徴量を抽出していた
  35. 35. 入力画像 ラプラシアン フィルタ適用 グレースケール K近傍法による クラス分類 Thanks @itooon sschooter_collabo スプラシューター コラボ 特徴画像
  36. 36. 52
  37. 37. 長所 – 色の違いに鈍感 – 画像の「形」でざっくり認識 短所 – 解像度の違いに弱い – 似た形の画像を正しく分類できない
  38. 38. スクリーンでは視認しにくいが、ユーザーが様々な解像度の画像を送ってくる「現実」
  39. 39. 56
  40. 40. オリジナルのブキ (longblaster) カスタムバージョン (longblaster_custom) 更に追加(Apr 2016) (longblaster_necro) 出力される特徴量に被りが発生し、 特徴量算出アルゴリズムの見直しが必要に
  41. 41. longblaster_necro longblaster_custom longblaster IkaLog内部で使用する特徴量を 主成分分析(PCA)で2次元空間に 投影したもの 出力される特徴量に被りが発生し、 特徴量算出アルゴリズムの見直しが必要に
  42. 42. ゲーム終了時に表示される別の画面 画面上に表示される「ギアパワー」画像を分類する KNNの問題点 ・「メイン」ギアパワーと「サブ」ギアパワーで  画像の大きさが異なる ・ユーザー環境によって解像度が異なる ・ブキ画像同様、状況によって特徴量が変化 → 「画像サイズの変化に強い分類器がほしい」
  43. 43. •  •  ❌ ⭕ –  –  –  •  • 
  44. 44. (本スライド中の画像の一部はイメージであり実際のものとは異なります。) オブジェクト ストレージ 作業用 インスタンス on IaaS 1年以上のデータを蓄積 総データ量 4TB以上 IkaLogユーザ stat.ink hasegaw
  45. 45. •  機械学習/深層学習の精度は前処理の精度に影響を受ける •  画像のズレ/ゆがみ対策(自動補正)を実装し、対策
 テンプレートマッチング、最小二乗法を用いて最適候補を選定 アスペクト比が壊れている なぜか画像がズレている リファレンス 分類に 使用する画像
  46. 46. Thanks @itoooon
  47. 47. 長所 – ニューラルネットワークにより認識率が大幅に向上 短所 – データが大きくなる(例:100MB~400MB) – Windows版に組み込みしづらい PythonスクリプトをEXE化する「Py2EXE」と
 ディープラーニングフレームワークは相性が悪い – 処理に時間がかかる
  48. 48. ゲーム終了時のスクリーンショット stat.ink から投稿データを深夜バッチで受け取り 約4000枚/日 認識対象となるブキ画像 約24000サンプル/日 Chainer による DNN で自動的に分類 スクリーンショットからサンプルを生成 ブキ精度向上にあたり注目したいサンプル (絞り込み済) 実際に IkaLog が利用するブキ認識モデルの強化、テストに利用
  49. 49. •  入力値と出力値 –  入力値: RGBもしくはHSVの色情報 (47*45*3=6,345 units) –  出力値: 各クラスの出力値(91 units, So+maxを適用する) –  使用する結合:全結合のみを使用(理由は後述) –  目 的:特徴量の自動生成 •  今回の用途であれば、深層学習で特徴量を自動的に見つけ出せるはず •  各ブキの背景色の重みが自動的ゼロに調整されれば、背景色への考慮も不要 –  目標性能値 •  目標性能値: 91クラスのマルチクラス分類が350ms未満(画面1枚あたり3秒以内) •  stat.ink の投稿データに対して99.99%の精度
  50. 50. 0 1 2 3 .. .. n 0 1 2 3 … 89 90 Input Layer Output Layer Hidden Layer 52gal 52gal_deco 96gal 96gal_deco … sschooter_wasabi wakaba
  51. 51. 69
  52. 52. •  Azure ML上でアルゴリズムの事前検証 –  小さなデータセットを使用し分類器を作成 –  入力層: ピクセル情報(をPCAにかけたもの) –  隠れ層: 1層、150ユニット(暫定) –  出力層: 各クラス(のはず) •  この方針でトレーニングすれば、精度が高い分類器を 得られるだろうと判断 –  特に何も考えなくても98%以上の精度が得られた –  各種ボケ画像も、おおよそ問題なく判定できた
  53. 53. 72
  54. 54. •  Azure MLで得た結果をベースに、IkaLogに組み込む モデルを作成する –  stat.inkに投稿された90万点のブキ画像を教師データとして用意 –  フレームワーク「Chainer」を使用 –  GPUの恩恵も受けられる •  学習したモデルの配布用フォーマット –  float32 → float16に変換 –  配布するモデルファイルのサイズが半減
  55. 55. CPU GPU # of jobs Throughput (images/s) GPU Time /epoch (s) RelaJve perf. (virtual) Core i7-4790S 定格3.2GHz 使用せず 1 3,928 234.5s 1X Core i7-4790S 定格3.2GHz GeForce GTX760 1 10,371 39.2s 5.9X Core i7-4790S 定格3.2GHz GeForce GTX760 4 (bl) 15,988 25.8s (103 / 4) 9.0X Core i7-4790S 定格3.2GHz GeForce GTX 1080 4 (bl) 30,320 6.25s (25.0s / 4) 37.5X ※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。 ※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。
  56. 56. 75 目的と手段が入れ替わる瞬間
  57. 57. 76
  58. 58. 77
  59. 59. CPU GPU # of jobs Throughput (images/s) GPU Time /epoch (s) RelaJve perf. (virtual) Core i7-4790S 定格3.2GHz 使用せず 1 3,928 234.5s 1X Core i7-4790S 定格3.2GHz GeForce GTX760 1 10,371 39.2s 5.9X Core i7-4790S 定格3.2GHz GeForce GTX760 4 (bl) 15,988 25.8s (103 / 4) 9.0X Core i7-4790S 定格3.2GHz GeForce GTX 1080 4 (bl) 30,320 6.25s (25.0s / 4) 37.5X 2X E5-2630L v3 定格 1.80GHz Tesla P100 4 (bl) 65,811 2.5s (10.3/4) 93.8X Special Thanks to ※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。 ※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。 自宅の Linux Box
  60. 60. パラメータチューニングのための事前学習ジョブ –  様々な隠れ層の構成(パーセプトロン数)で学習を行い、 モデルファイルサイズが小さくなるような構成を探索 –  4ジョブ同時投入(バッググラウンドプロセス化→ wait) –  ジョブ実行開始 03:08 〜 終了 18:28 (実行時間 15時間20分) 最終的な学習速度 –  550エポック/24時間 ※ ファイルシステム書き込みへのモデルデータ書き込み、各エポックの Test / Cross Validadon テストの所要時間を含む –  第一弾として第617エポックの重みを採用 → 21GB のデータ・セットを用いて、数時間の作業、約48GPU時間で学習した Special Thanks to
  61. 61. K近傍法 既存ImageNet 新ニューラルネット 認識効率 一部ユーザでは 低い 99.99+% 99.99+% モデルサイズ 20MB(現時点) 400MB (AlexNet) 100MB (GoogleNet) 14MB (Float32) 7MB (Float16) 分類にかかる時間 @ IvyBridge 2GHz とても高速 ~300ms ~20ms •  既存のImageNetよりも高速、 より小さなモデルデータ(配布物) •  従来のIkaLogよりも高い認識精度を実現 Special Thanks to
  62. 62. •  ニューラルネットの順伝播処理を新規実装 – 既存のフレームワークは組み込まない (Windowsユーザ対策) – 高度な機能を実装すると面倒なため、最低限の 機能を絞り込んで実装(LinearFuncdon, ReLU) hbps://github.com/hasegaw/IkaLog/commit/3238b67749334a3c4254aa6f25c005f83e210895 –  IvyBridge 2.0GHzで20ms以下、 PYNQ-Z1 (Cortex-A9 650MHz) で200ms以下で順伝播可能
  63. 63. •  ニューラルネットを他の用途にも適用 –  ブキ分類器のほか、ギアパワー分類器を作る(優先度 高) –  ガチホコのタッチダウン分類器を作る –  戦況評価関数にRNNが使えるのではないか •  本当に必要なデータセットの選定 –  21GBのデータセットには大量の重複データが含まれている –  重複データをうまく取り除くと学習時間、効率ともに メリットがあると考える –  PCA-based anomaly detecdon が使えそう
  64. 64. •  IkaLogでは、複数の機械学習アプローチを適用している –  リアルタイム処理では、おもにK近傍法(KNN)を利用 –  入力画像にロバストな分類器を作るため、深層学習を利用 •  特徴量の自動抽出、何十万の画像から自動的な学習 •  IkaLogとディープラーニング –  Windowsアプリケーションにそのまま組み込めるような 深層学習のフレームワークは限られている –  しかし、関数や機能を限定すれば、比較的容易に実装可能 –  学習には既存の深層学習フレームワークやGPUを活用
  65. 65. らぴす (2000-2014)
  66. 66. © 07strikers

×