AI技術の実応用と実験環境の整備 （DRIVE CHARTの脇見検知）

DRIVE CHARTではドラレコ映像からAIで危険行動を検知しますが、実サービスにAIを導入するには様々な課題があります。誤検知ゼロを目指す脇見運転検知での実例やその実験環境についてご紹介します。

Transcript

1. 笹木 陸・大西 健太 1
2. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 2
3. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 3
4. 経歴 2019/4 DeNA 新卒入社 2020/4 Mobility Technologies へ出向 笹木 陸 / Riku Sasaki Mobility Technologies 開発本部 AI技術開発部（DeNAより出向） DRIVE CHART データサイエンスチーム @losveria (Kaggle Expert) 4
5. • 実データから傾向や構造などを 理解し、知見を引き出す • それを基に適切な指標を設定し 新たな入力に対する予測などを 行うモデルを構築する パターンの モデル化 新たな知見・ パターンの発見 • 数学・統計学 • ドメイン知識 • データエンジ ニアリング力 など データの 理解 5 統合
6. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 6
7. 7 「移動で人を幸せに。」
8. 8 「移動で人を幸せに。」
9. 引用：警察庁交通局「令和元年中の交通事故の発生状況」 9 法令違反別交通事故割合（2019年）
11. 危険シーンの動画や 運転行動の分析結果を フィードバック 危険シーンの検知と 運転行動の分析 11
12. • 前方車両検出結果 • レーン検出結果 深層学習 モデル イベント検知 12 内カメラ映像 外カメラ映像 加速度・角速度 GPS エッジ サーバ 地図 各種モデル • 顔ランドマーク検出結果
13. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 ◦ 脇見検知の概要 ◦ 脇見検知のモデル ◦ モデル作成上の課題と対策 ◦ テストと運用 • 実験環境の整備 13
14. 視線が正面から下方にそれる状態が ある運転速度以上で一定時間継続 14 正常運転 脇見運転
15. • ユーザー体験 ◦ 誤検知ゼロ ◦ シチュエーションや利用者の 違いに対しロバストな検知 • コスト ◦ 将来的な導入台数の拡大を見据え 処理できる計算コスト 15
16. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 ◦ 脇見検知の概要 ◦ 脇見検知のモデル ◦ モデル作成上の課題と対策 ◦ テストと運用 • 実験環境の整備 16
17. 機械学習 モデル コンピュータビジョンを用いた 直接的なアプローチ 17 • 顔向き • 目の開き具合 • 顔の大きさ など 動画 脇見検知 特徴量 視線方向と 関連していると 仮定
18. TechCon 2020 「コンピュータビジョン技術の実応用」 CNNやRNNなどのコンピュータビジョン(CV)技術 18 時系列データと捉えて脇見確率を推定
19. 1. エッジで間接的な特徴量（ランドマーク）を作る 2. 特徴量を基にサーバで脇見候補を絞り込む 3. 脇見候補にのみ高性能なモデルを使う • （サーバ）多くの計算コストと通信コストが必要 • （エッジ）計算量制約・オンラインの脇見予測 • 深層学習は様々なシチュエーションのデータが必要 19 課題
20. 脇見検知 モデル 軽量な 深層学習 モデル 脇見候補 20 内カメラ動画 エッジ サーバ ランドマーク センサデータ 脇見検知 高性能な 深層学習 モデル 脇見候補動画 リクエスト ① ② ③ ④
21. • 顔向き • 目の開き具合 • カメラとの距離 • 加速度 • 速度 などの特徴量 誤差（損失関数） 最小化 21 残差 残差 ︙ 入力 モデル 出力 脇見確率 (0〜1) アノテーション 脇見 (1) または 脇見ではない (0)
22. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 ◦ 脇見検知の概要 ◦ 脇見検知のモデル ◦ モデル作成上の課題と対策 ◦ テストと運用 • 実験環境の整備 22
23. 誤差（損失関数） 最小化 23 残差 残差 ︙ 入力 モデル 出力 脇見確率 (0〜1) アノテーション 脇見 (1) または 脇見ではない (0) • 顔向き • 目の開き具合 • カメラとの距離 • 加速度 • 速度 などの特徴量
24. 24 車線変更や カーブ時の 左方確認 or 脇見 前傾姿勢で 前方注視 or 脇見 脇見運転の定義が曖昧かつ、 類似事象との見分けが困難 類似事象の誤検知が発生 課題 カーブ、車線変更、前傾姿勢、目線のみ前方等
25. 車線変更や カーブ時の 左方確認 or 脇見 脇見運転の定義が曖昧かつ、 類似事象との見分けが困難 類似事象の誤検知が発生 顔との距離・速度・加速度など 脇見と一見関係ない特徴量導入 25 課題 前傾姿勢で 前方注視 or 脇見 顔とカメラの 距離で判定 加速度で 判定 カーブ、車線変更、前傾姿勢、目線のみ前方等
26. 26 デバイスや利用者ごとに 固有なデータ 統一的に扱うと検知に偏りが発生 課題 カメラの位置、シート位置、目の大きさ等
27. 顔向きや目の大きさのデータ蓄積で デバイス、利用者ごとのモデル作成 デバイスや利用者ごとに 固有なデータ 統一的に扱うと検知に偏りが発生 • 画像処理を考慮した特徴量 • デバイス、利用者ごとに データを蓄積し特徴量作成 27 課題 カメラの位置、シート位置、目の大きさ等
28. 誤差（損失関数） 最小化 28 残差 残差 ︙ 入力 モデル 出力 脇見確率 (0〜1) アノテーション 脇見 (1) または 脇見ではない (0) • 顔向き • 目の開き具合 • カメラとの距離 • 加速度 • 速度 などの特徴量
29. 脇見は低頻度で、大部分が 脇見でないデータ ランダムなデータを用いると 意味の無いモデルになる 29 正常運転 脇見運転 課題
30. ダウンサンプリングで かたより無いモデル作成 30 脇見でないデータを間引く ダウンサンプリング 脇見は低頻度で、大部分が 脇見でないデータ ランダムなデータを用いると 意味の無いモデルになる 課題
31. GBDTモデルによる２クラス分類 モデルを複雑にすると 精度向上するが、計算コスト増加 各フレーム の特徴量 各フレーム の予測 31 残差 ︙ 0.1, 0.7, 0.8, 0.1, 0.2, 0.1, 0.9 残差 木 木 課題 予測値とラベルとの残差を次の木で予測する
32. 大部分は 脇見でないため サンプリング後 に予測で高速化 32 残差 ︙ 残差 • 非走行時の予測を飛ばす • 全フレームではなく、 サンプリングと重点的予測 −, , , −, , −, 木 木 モデル複雑化で 精度向上 課題 GBDTモデルによる２クラス分類 モデルを複雑にすると 精度向上するが、計算コスト増加 予測値とラベルとの残差を次の木で予測する
33. 誤差（損失関数） 最小化 33 残差 残差 ︙ 入力 モデル 出力 脇見確率 (0〜1) アノテーション 脇見 (1) または 脇見ではない (0) • 顔向き • 目の開き具合 • カメラとの距離 • 加速度 • 速度 などの特徴量
34. 34 課題 サービス展開まではデータが少なく 多様性に欠け、リソースも不十分 誤アノテーションも発生する 収集効率が悪く、データに偏りと劣化 正常 脇見
35. 曖昧な部分の 重点収集で高精度化 35 課題 サービス展開まではデータが少なく 多様性に欠け、リソースも不十分 誤アノテーションも発生する 収集効率が悪く、データに偏りと劣化 • 収集用ロジックの作成 • 境界データのアノテーション 正常 脇見
36. 間接的な特徴量から、 高性能な深層学習モデルと 遜色ない検出精度を達成 36 実際に脇見区間で 高い確率を出力 一定間隔の 予測で高速化 非運転時は 予測せず高速化 一定時間 閾値以上で 重点的に予測
37. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 ◦ 脇見検知の概要 ◦ 脇見検知のモデル ◦ モデル作成上の課題と対策 ◦ テストと運用 • 実験環境の整備 37
38. 実験環境での 検証 • 実験環境での検証（後半） ◦ 精度が想定通りか • 本番環境での検証 ◦ 検知の分布と精度が想定通りか • 展開後のモニタリング ◦ 誤判定が発生していないか ◦ 長期的に精度が劣化していないか 展開後の モニタリング 本番環境での 検証 データ収集 アノテーション モデル作成 38
39. 展開後の モニタリング 本番環境での 検証 実験環境での 検証 データ収集 アノテーション モデル作成 39 • 実験環境での検証（後半） ◦ 精度が想定通りか • 本番環境での検証 ◦ 検知の分布と精度が想定通りか • 展開後のモニタリング ◦ 誤判定が発生していないか ◦ 長期的に精度が劣化していないか
40. • 実験環境での検証（後半） ◦ 精度が想定通りか • 本番環境での検証 ◦ 検知の分布と精度が想定通りか • 展開後のモニタリング ◦ 誤判定が発生していないか ◦ 長期的に精度が劣化していないか 展開後の モニタリング 本番環境での 検証 実験環境での 検証 データ収集 アノテーション モデル作成 40
41. • ユーザー体験 ◦ 誤検知ゼロ ◦ シチュエーションや利用者の 違いに対しロバストな検知 • コスト ◦ 将来的な導入台数の拡大を見据え 処理できる計算コスト 41 ほとんどゼロ 特定の人やシーンでの 検知の偏り無し 許容可能なコスト 更なる低下を目指す データの徹底的な分析により 各課題に対応したデータや モデルを作成することで、要件を 満たす脇見検知システムが完成
42. • DRIVE CHARTではCV・データサイエンス 技術をフル活用した脇見検知モデルを開発・運用 • 実データでは様々な課題が存在し、精度以外の 要件も考慮したデータ・モデルの設計が重要 • 脇見特有の課題にはデータ整備、分析が特に重要 42
43. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 43
44. 44 経歴 2019/7 DeNA 入社 2020/4 Mobility Technologies 入社 大西 健太 / Kenta Onishi Mobility Technologies 開発本部 AI技術開発部 DRIVE CHART MLOpsチーム
45. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 ◦ 評価実験の位置づけと実験環境の要件 ◦ 採用した解決策と実験環境の全体像 ◦ Amazon EKS環境へのKubeflow Pipelinesの導入 ◦ ETL systemとFeature storeの内製 45
46. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 ◦ 評価実験の位置づけと実験環境の要件 ◦ 採用した解決策と実験環境の全体像 ◦ Amazon EKS環境へのKubeflow Pipelinesの導入 ◦ ETL systemとFeature storeの内製 46
47. • 実験環境での検証（後半） ◦ 精度が想定通りか • 本番環境での検証 ◦ 検知の分布と精度が想定通りか • 展開後のモニタリング ◦ 誤判定が発生していないか ◦ 長期的に精度が劣化していないか 展開後の モニタリング 本番環境での 検証 データ収集 アノテーション モデル作成 47 実験環境での 検証
48. 48 • サービスで実デバイスから収集されたデータを入力とし て検出処理を行う ◦ 検証データとサービスのデータで収集条件や分布が異なる場合がある • 大量の運転データを用いて検出処理を行う ◦ 誤検知ゼロの達成には十分なデータ数で評価実験することが重要 ◦ 評価実験でも大量のデータを高速に処理できる必要がある • Jupyter notebookなどではなく、サーバのコードを実行 して検出処理を行う ◦ サービスと同じコードを動かし、デプロイ後も同じ挙動を保証する
49. 49 • エッジとサーバの一貫試験 • 実験データの収集・生成の自動化 • 前処理済みの特徴量を使った開発・検証 • 動作要件の異なるコンポーネントの連携 • 複数の実験の並行 • 実験手順が簡便
50. 深層学習 モデル イベント検知 50 内カメラ動画 外カメラ動画 加速度・角速度 GPS エッジ サーバ 地図 各種モデル • 前方車両検出結果 • レーン検出結果 • 顔ランドマーク検出結果
51. 深層学習 モデル イベント検知 51 内カメラ動画 外カメラ動画 加速度・角速度 GPS 地図 各種モデル 特徴量の 変更も... ロジックの 変更も... 最終結果に影響を与える • 前方車両検出結果 • レーン検出結果 • 顔ランドマーク検出結果
52. 深層学習 モデル イベント検知 52 エッジ サーバ 各種モデル • • •
53. 誤差（損失関数） 最小化 53 残差 残差 ︙ 入力 モデル 出力 脇見確率 (0〜1) アノテーション 脇見 (1) または 脇見ではない (0) • 顔向き • 目の開き具合 • カメラとの距離 • 加速度 • 速度 などの特徴量
54. 誤差（損失関数） 最小化 54 残差 残差 ︙ 入力 モデル 出力 脇見確率 (0〜1) アノテーション 脇見 (1) または 脇見ではない (0) 前処理済みの特徴量で、 モデルの開発や分布の検 証などを行いたい • 顔向き • 目の開き具合 • カメラとの距離 • 加速度 • 速度 などの特徴量
55. 脇見検知 モデル 軽量な 深層学習 モデル 脇見候補 55 内カメラ動画 エッジ 検出サーバ ランドマーク センサデータ 脇見検知 高性能な 深層学習 モデル 脇見候補動画 リクエスト ① ② ③ ④ 動画推論サーバ
56. 脇見検知 モデル 軽量な 深層学習 モデル 脇見候補 56 内カメラ動画 エッジ 検出サーバ ランドマーク センサデータ 脇見検知 高性能な 深層学習 モデル 脇見候補動画 リクエスト ① ② ③ ④ 動画推論サーバ Python実装 Rust実装 軽量なGBDTモ デル 多段の PyTorchモデル Python実装
57. 57 • 複数人が異なるイベント種別 (脇見や急後退など) を同時 に実験 ◦ イベント種別ごとに開発チームや開発フェーズが異なる • 同じイベント種別でも異なるパラメータで同時に実験 ◦ Ex. モデルのバージョン間の比較 • ある実験が他の実験に影響を与えてはいけない ◦ 実験に用いた特徴量や実験結果は、実験ごとに独立して保存 ◦ 他の実験でコンピューティングリソースが割かれて実験完了が遅れる、 なども避けたい
58. 58 • 多様なバックボーンのスペシャリスト約30名が開発従事 ◦ コンピュータビジョン ◦ エッジAI開発 ◦ データサイエンス ◦ サーバサイド開発 ◦ 経験してきた分野や技術スタック、開発フェーズなどが異なる • 実験は全員が平等に行えるようにしたい ◦ 自分が行った変更に対して、自分で結果まで確認できるようにする ◦ イメージビルドなどの定型作業は自動化する
59. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 ◦ 評価実験の位置づけと実験環境の要件 ◦ 採用した解決策と実験環境の全体像 ◦ Amazon EKS環境へのKubeflow Pipelinesの導入 ◦ ETL systemとFeature storeの内製 59
60. • Amazon EKS + Kubeflow Pipelinesを導入 ◦ ✅ エッジとサーバの一貫試験 ◦ ✅ 動作要件の異なるコンポーネントの連携 ◦ ✅ 複数の実験の並行 ◦ ✅ 実験手順が簡便 • ETL systemとFeature storeを内製 ◦ ✅ 実験データの収集・生成の自動化 ◦ ✅ 前処理済みの特徴量を使った開発・検証 60
61. 61 Test Y Test X データセッ ト ETL System Feature store エッジ 検出サーバ 推論 前処理 出力 検出 前処理 出力 可視化 集計・可 視化 動画 ロジック開発 サービス環境 AI環境 カメラファイル デプロイ デプロイ S3 (ファイルストレージ ) Aurora (RDB) SageMaker (≒ Jupyter Notebook) ECS (コンテナ実行環境 ) Lambda (サーバレス環境 ) 推論 出力 カメラファイル センサファイル テーブル EKS 動画推論 サーバ サービスデータ の収集を集約 前処理済み特徴 量を使って開発 実験ごとに独立した実行環境を構築
62. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 ◦ 評価実験の位置づけと実験環境の要件 ◦ 採用した解決策と実験環境の全体像 ◦ Amazon EKS環境へのKubeflow Pipelinesの導入 ◦ ETL systemとFeature storeの内製 62
63. • (k8s) はコンテナアプリケーション環境の 構成管理プラットフォーム ◦ アプリケーション環境は全てコンテナ化されているため、導入が容易 ◦ オートスケーリングやセルフヒーリングをサポート ◦ ワークロードが多様で今後も変化していくため、制約の多いマネージド サービスの組み合わせでは、拡張性の担保が難しい • でk8sクラスタを構築 ◦ サービスおよびAIの環境にAWSを採用しているため ◦ コントロールプレーンを自分で管理しない 63
64. 64 • は機械学習に関わるワークロードをk8s上で 実行するためのツールキット群 ◦ 開発、学習、ワークフロー、サービング等 • ワークフローを担う を採用 ◦ 実験管理に特化したパイプラインを構築できる ▪ SDK (Python) も提供されているので簡単に実装できる ◦ k8sインフラの恩恵 (スケーラビリティなど) をそのまま受けられる ◦ リッチなWebインタフェースがデフォルトで提供される ▪ Apache AirflowやAWS Step Functions等も検討したが、UIの点で 最も使い勝手が良かった
65. 65 Web UIのためブラウザで完結できる 実験の一覧 過去の実験履歴が 一覧化されている 実験パラメータの入力 パイプラインの実行状況 進行状況がグラ フでわかる ボタン1つでス タート ボタン1つでス タート
66. • ユーザとデモを繰り返しながら開発 • 実験条件は可能な範囲でパラメータ化することで、ユー ザがコントロールできるようにする ◦ 有効にする機能のトグル (エッジ+サーバ や サーバのみ などのバリエー ションに対応) ◦ 実験に用いるエッジやサーバのバージョン • 定型作業はパイプライン上で自動化 ◦ データコピー、ビルド・デプロイなど • 特徴量や途中結果の可視化、AWS Cloudwatch Logsへの ログの集約、実験完了のSlack通知など
67. • DRIVE CHARTの概要 • 脇見検知へのデータサイエンス応用 • 実験環境の整備 ◦ 評価実験の位置づけと実験環境の要件 ◦ 採用した解決策と実験環境の全体像 ◦ Amazon EKS環境へのKubeflow Pipelinesの導入 ◦ ETL systemとFeature storeの内製 67
68. 68 • DRIVE CHARTリリース初期はAI開発者が必要なデータを 毎回収集してから実験を行っていた ◦ データソースが多岐 (センサファイル、動画ファイル、テーブルなど) に わたるため、実験ケースごとに要否を適切に判断する必要がある ◦ データの重複保持によるストレージコストの圧迫 ◦ データガバナンスの面でも問題 • データセット管理の仕組み (ETL system) を開発・運用 ◦ 実験データの収集自動化・永続化・共有を実現
69. 69 API Gateway AI環境 サービス環境 ファイル テーブル コピー コピー Lambda (API) Lambda (Enq) SQS ECS メタデータ run run update データセット化 実験のタイミングで実 行開始 スケジュールで実行 手動実行 CLI + APIで汎用的なインタフェースを提供 サーバレスで オートスケール AWSマネージドサービスの組み合わせで実現
70. 70 • “Feature store”は前処理された特徴量を入出力・永続化 するためのデータストア ◦ 主に実験の再現性の担保、前処理済みのデータの共有などが目的 ◦ Uber, Airbnb, NetflixなどのMLシステムで同様の仕組みを持っている ◦ CHARTでは前処理済みのセンサデータ (= CSVデータ) などが対象 • プロジェクト用にFeature storeを内製 ◦ OSSのFeature store (feastなど) も候補に上がったが、高機能な一方、 想定環境のミスマッチや運用ハードルの高さのため、採用を見送り
71. 71 • センサデータを入出力・永続化に特化した最小構成 ◦ KubeflowやJupyter NotebookからPythonクライアントでアクセス ◦ gRPCサーバをRustで実装 ECS Aurora (メタデータ) S3 (rawデータ) SageMaker Pandas DataFrame と Apache Parquet を相互変換 (通信高速化 + ストレージ削減) 負荷に応じてオートスケール
72. 72 • (実験数の増加) ◦ 環境やデータの準備が自動化され、計画したときにすぐ実験を回せる ◦ 実行環境が分離され、複数の人・複数の条件で同時に実験できる • ◦ 実験で生成された特徴量へ簡単にアクセスできる ▪ 結果の分析 ▪ 特徴量を使った検出処理の改善
73. 73 • DRIVE CHARTではAIの品質の最終チェックとし て評価実験を行っている • Kubeflow Pipelines + ETL system + Feature storeで実験環境を構築・運用 • 実際の運転で生成された大量のデータを使った実 験が、誰でも実行できるようになった
74. Mobility Technologiesでは 共に働く仲間を 積極的に募集してます 74 https://hrmos.co/pages/mo-t