IkaLog_20161125_nsstudy

IkaLog_20161125_nsstudy

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. 様々なステージとルール •  １６のステージ、４つのルール •  勝利に向けチームで立ち向かう 多様な楽しみ方 •  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. 18 https://stat.ink/
11. 11. 自分が倒されて 行動不能だった時間 イカ（味方／敵　計８匹）の生死状況 チームのスペシャル発動、キル／デス 自分の塗り面積 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. データソース h_ps://stat.ink/enare/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. 33
23. 23. 35
24. 24. •  ゲーム中で使われているフォントは２種類 –  画面上に現れる数字フォントは１種類 –  フォントが判っているのだから、認識できるはず •  試行錯誤の後、既存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. １）画面上の数字部分（位置固定）を切り抜き ２）縦・横のヒストグラムを生成し各文字の位置を特定 ３）文字を検出用サンプルのサイズ（等幅）にリサイズ、
 二値化 ４）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. 48
32. 32. スプラトゥーンのブキ　５９種類（スライド作成当時）
33. 33. •  •  •  •  他の装備品が被っている 保護色（まだマシ） 保護色（マジつらい）
34. 34. （まだバグがあった頃のバージョンの表示なので色がずれているけども） こんなかんじで特徴量を抽出していた
35. 35. 入力画像 ラプラシアン フィルタ適用 グレースケール K近傍法による クラス分類 Thanks @itooon sschooter_collabo スプラシューター コラボ 特徴画像
36. 36. 53
37. 37. 長所 – 色の違いに鈍感 – 画像の「形」でざっくり認識 短所 – 解像度の違いに弱い – 似た形の画像を正しく分類できない
38. 38. スクリーンでは視認しにくいが、ユーザーが様々な解像度の画像を送ってくる「現実」
39. 39. 57
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 １年以上のデータを蓄積 総データ量 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未満（画面１枚あたり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. 70
52. 52. •  Azure ML上でアルゴリズムの事前検証 –  小さなデータセットを使用し分類器を作成 –  入力層: ピクセル情報（をPCAにかけたもの） –  隠れ層: 1層、150ユニット（暫定） –  出力層: 各クラス（のはず） •  この方針でトレーニングすれば、精度が高い分類器を 得られるだろうと判断 –  特に何も考えなくても９８％以上の精度が得られた –  各種ボケ画像も、おおよそ問題なく判定できた
53. 53. 73
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 (_l) 15,988 25.8s (103 / 4) 9.08X Core i7-4790S 定格3.2GHz GeForce GTX 1080 4 (_l) 30,320 6.25s (25.0s / 4) 37.52X ※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。 ※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。
56. 56. 76 目的と手段が入れ替わる瞬間
57. 57. 77
58. 58. 78
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 (_l) 15,988 25.8s (103 / 4) 9.08X Core i7-4790S 定格3.2GHz GeForce GTX 1080 4 (_l) 30,320 6.25s (25.0s / 4) 37.52X 2X E5-2630L v3 定格 1.80GHz Tesla P100 4 (_l) 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 Validaaon テストの所要時間を含む –  第一弾として第617エポックの重みを採用 → 数時間の作業、約48GPU時間で21GB のデータ・セットを用いて学習した 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ユーザ対策） – 高度な機能を実装すると面倒なため、最低限の 機能を絞り込んで実装（LinearFuncaon, ReLU） h_ps://github.com/hasegaw/IkaLog/commit/3238b67749334a3c4254aa6f25c005f83e210895 –  IvyBridge 2.0GHzで20ms以下、 PYNQ-Z1 (Cortex-A9 650MHz) で200ms以下で順伝播可能
63. 63. •  ニューラルネットを他の用途にも適用 –  ブキ分類器のほか、ギアパワー分類器を作る（優先度 高） –  ガチホコのタッチダウン分類器を作る –  戦況評価関数にRNNが使えるのではないか •  本当に必要なデータセットの選定 –  21GBのデータセットには大量の重複データが含まれている –  重複データをうまく取り除くと学習時間、効率ともに メリットがあると考える –  PCA-based anomaly detecaon が使えそう
64. 64. •  IkaLogでは、複数の機械学習アプローチを適用している –  リアルタイム処理では、おもにK近傍法(KNN)を利用 –  入力画像にロバストな分類器を作るため、深層学習を利用 •  特徴量の自動抽出、何十万の画像から自動的な学習 •  IkaLogとディープラーニング –  Windowsアプリケーションにそのまま組み込めるような 深層学習のフレームワークは限られている –  しかし、関数や機能を限定すれば、比較的容易に実装可能 –  学習には既存の深層学習フレームワークやGPUを活用
65. 65. らぴす (2000-2014)
66. 66. © 07strikers