システムテスト自動化カンファレンス2019 での発表内容です

1. AIを活用した交通事故削減支援
サービスでのテスト自動化
鈴木 翔太
AI本部AIシステム部MLエンジニアリング第二グループ
株式会社ディー・エヌ・エー

2. Who am I
• 鈴木 翔太
• DRIVE CHARTのAIシステムリードエンジニア
• モデル構築部分以外を幅広く担当
• 学習・分析環境の整備
• AI/MLモデルの本番組み込み
• データの前処理・パイプラインの開発運用
2

3. DRIVE CHART
3
2019年6月4日にサービススタート

4. DRIVE CHART概要
• 交通事故削減は喫緊の社会課題
• 年間47万2165件※1、商用車(事業用)3万2655件※2
• 事故削減はビジネス観点でも重要
• 営業車、タクシー、運輸業者等
• 安全はもちろん、評判、修理費用、保険料観点でのニーズ大
• 高齢ドライバーも増えている
• 危険運転の効果的な改善方法が求められている
• ドライバーが行動を改善しなければ事故は減らない
4
※1 平成30年度版 交通安全白書「平成29年度中の交通事故発生件数」
※2 警察庁交通局 平成29年中の交通事故の発生状況

5. DRIVE CHART概要
危険運転をAIで検知、レポートし、運転行動の改善指導を行うための
ツール
5

6. DRIVE CHART概要
6

7. 危険運転行動の検知
車載カメラ画像、GPS、地図データから様々な危険運転を検知
7
入力情報 検知する危険運転
外向きカメラ 車間距離不足
内向きカメラ 脇見
加速度センサ/GPS 急ブレーキ、急加速、急ハンドル
加速度センサ/GPS/地図データ 一時不停止、制限速度超過

8. 8
DEMO

9. 9
Test/QA for AI/ML

10. 10
AI/MLシステムについてのテスト/QA
は何をすればいいのだろうか・・・

11. ミッションクリティカル領域でのAI/ML活用
11

12. まず考えてみた
• モデルの精度テスト
• AIモデル以外のシステム全体としてのテストも当然必要
• 前処理、後処理など
• テストに用いるデータセットは適切か？
• テストデータをどうやって作る？
• テストがFail == リリース不可？
• 技術的に潰せるものなのか
• そもそも何を持って品質保証というのか
• 特定のデータセットでの精度〇〇％
• 絶対失敗できないケースに通らない
12

13. Hidden technical debt in machine learning systems
13
Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing systems, 2015.

14. ソフトウェア開発との違い
14
https://docs.google.com/presentation/d/1T8JF6h_DFnBAWz8LJvK0miFWsVovKyP0BDuXk3cVo2Q/edit#slide=id.g78eae58cb4_0_6

15. ソフトウェア開発との違い
15
https://hackernoon.com/why-is-devops-for-machine-learning-so-different-384z32f1
伝統的なソフトウェア開発フロー 機械学習の開発フロー
• User Story
• Write Code
• Submit PR
• Tests run automatically
• Review and merge
• New version builds
• Built executable deployed to
environment
• Further tests
• Promote to next environment
• More tests etc.
• PROD
• Monitor - stacktraces or error codes
• Data inputs and outputs. Preprocessd.
Large.
• Data scientist tries stuff locally with a
slice of data.
• Data scientist tries with more data as
long-running experiments.
• Collaboration – often in jupyter
notebooks & git
• Model may be pickled/serialized
• Integrate into a running app e.g. add
REST API(serving)
• Integration test with app
• Rollout and monitor performance
metrics

16. CACE性
• Changing Anything Changes Everything
• 少しでも変更すると全体に影響が及ぶ性質
• 学習や変更が行われるたびに品質を保証する必要がある
• コンポーネント全体に対して全ての条件で高頻度にテストを行う全
体全数高頻度検証が必要となる
• テストや構成管理といった品質保証技術の自動化が欠かせない
16

17. MLOps
• DevOpsのML版?
• Data Scientist/ ResearcherとDeveloper(Operation)との協業
• Data/model versioning != code versioning
• 学習の再現性
• 実験結果の記録
• 学習データ、モデルサイズが大きく単純にはGit管理できない
• AI/MLのCI/CD
• 前処理の自動化
• モデルの再学習の自動化
17

18. • AI技術は進化途上であるとともに、ハードウェアや従来型のソフトウェア、サービスなどに
比べ、その技術的特質により、品質の把握、評価、説明、管理など品質保証が非常に難しい。
特に機械学習ではデータの学習によりふるまいが帰納的に決定されるため、従来型のソフト
ウェアに対する品質保証手段が利用できない。開発プロセスの管理による品質保証が寄与す
る割合も小さい。したがってAIプロダクトの品質保証技術が確立されたとは到底言いがたい
状況にある。すなわち我々の生活や社会、経済には、AIプロダクトの品質事故という甚大な
リスクが内在されているのである。
• 同時に注意すべきなのは、AI技術が持つ技術的特質を無視しAIプロダクトの品質に社会が過
度の期待を持つことが、品質保証のための過度な活動を要請し、AI技術の適切な活用やさら
なる進化を妨げる圧力を与えてしまう点である。我々はAIプロダクトの品質リスクを軽減す
るとともに、過度の品質圧力を予防し、AI技術が安心して活用され進化できるようにする必
要がある。
18
http://www.qa4ai.jp/sample-page/
AIプロダクト品質保証ガイドライン

19. AIプロダクトの品質保証において考慮すべき軸
• Data Integrity
• データがきちんとしていること
• Model Robustness
• モデルがきちんとしていること
• System Quality
• システム全体として何かが起きても何とかなる
• AIプロダクト全体の品質が確保できている
• Process Agility
• プロセスが機動的であること
• Customer Expectation
• 顧客との良い関係性
19
http://www.qa4ai.jp/QA4AI.Guideline.201905.pdf

20. 20
これといった方法論はなくまだ手探り感
が満載。
(1年前は先のガイドラインもなかった)
できる範囲のことをやっていくしかない。

21. 主な取り組んでいるテスト/QA内容
• モデル部分以外（前処理や周辺システム）は普通のソフトウェア開
発手法をなるべく行う
• CI/単体テスト/結合テスト
• モデルの性能試験は過去のデータを自動で大量に実行できるように
しておき差分を見る
• 想定されるケースを洗い出しリスクの把握をする
• 毎日モデルを更新するところはパイプラインにバリデーションを入
れ精度が悪いモデルがデプロイされないようにしている
• エッジデバイスへの組み込みの工夫
• モニタリングの仕組みを整え異常に早く気づけるようにする
21

22. 22
テスト条件を洗い出してみる

23. • カメラの取り付け位置
• シートの角度
• ドライバーの性別
• ドライバーの年齢
• ドライバーの人種
• マスク
• メガネ
• サングラス
• 化粧
• カメラに複数人が映り込む
• 車種
23
• 高速道路
• 一般道路
• 坂道
• 悪路
• 鏡面
• 走行中
• 停車
• 低速走行
• 二輪
• 逆光
• 雨

24. テストケース再考
• 特に注意してテストを考えたいのはエッジケース
• 通常観測できる事象については豊富にデータある
• それぞれのシーンをなんらかの方法で見つける必要はあり
• 一方エッジケースは意識して集めないとデータそのものがないこ
とが多い
• テストコースなどを使って収集する
• とはいえ現実世界の全ての事象をカバーするのは現実的には不可能
• False Positive/False Negativeの影響を考える
24
過剰品質にならないように関係者間で合意を取る

25. アノテーションの品質問題
• アノテーション
• 画像やテキストなどに何らかのタグをつける
• モデルの学習はアノテーションを正しいものとして行うのでそもそ
ものデータが間違っていると学習結果もおかしくなる
• 精度が悪いのは学習データのラベルが間違っているせいで、データを綺麗にし
たら精度が上がったことは実際にあった
• 複数人でのアノテーションなどである程度防げる可能性は上がるが
その分コストがかかってしまう
• 逆に人による基準のぶれもある
• 1次フィルタを複数人で行い最後はドメインに詳しい人が判定などしていると
ころもある
25

26. エッジへの組み込み
• DRIVE CHARTではエッジデバイスでも推論を行なっている
• Rustを採用
• https://docs.google.com/presentation/d/1HOL9jheJnKkh2q7w3hU_px-
je1qL7lxrSXV-0P1hces/edit#slide=id.p1
• リファクタがしやすくインクリメンタルな開発がしやすい
• エコシステムは十分で、本質的な実装に注力できた
• 既存のC/C++ライブラリをbindingできる
• 他の言語で書かれたシステムと結合しやすい
• 画像でモデル推論のE2Eテスト。ある時点の出力を期待値として、
リグレッションしている
• webcamで検証できる環境をつくり、目視で検証できるようにして
いる
26

27. テスト環境
• AWSでData Scientistが大量のデータを処理できる環境を用意
• モデル変更時にはリリース前に過去の様々なデータを処理して性能
の検証を行う
27
S3
EFS
EC2 Auto Scaling RDS
テストデータセット
結果の書き込み・比較
動画
センサーデータ
処理の中間データ保存
処理対象のエンキュー
SQS
CVモデル処理
危険運転検知
ECR CodeBuild

28. テスト環境
• 使用するモデルやコードはパラメータとして設定
• それぞれのテストに対応するidを払い出し
• CVモデルを本番はエッジで動かしているがサーバサイドで動くよう
にして画像処理も再現
• EC2はオートスケールの設定を組むことで数百台単位でデータ処理
• スポットインスタンスの積極活用でコストを抑える
• 大量のデータを頻繁に処理するので少しでも安くする工夫
28

29. モニタリング
• 一般的なエラーログやステータスコードに加えて事業KPIや中間指標
をモニタリング
• 内製のBIツール
• Slackへの通知
• 新しいモデルのデプロイ時の変化
• 外部要因によるモデルの性能劣化
29

30. まとめ
• 従来のソフトウェア開発とはAI/MLシステムの開発はフローがことなる
• AI/MLシステムのQAについてこれといった方法論はまだ定まっていない
• 発生しうる状況、リスクなどは洗い出し関係者で合意を取っておく
• モデルの再学習や変更などにより頻繁にテストは流すことになるので極
力自動化
• 自動化できていないところも多いのでより自動化を進めAI/MLの開発サ
イクルを早くしていきたい
30

31. 31
ご静聴ありがとうございました