機械学習における品質保証のチャレンジ～産学連携による突破...

機械学習における品質保証のチャレンジ

～産学連携による突破への期待

国立情報学研究所石川冬樹[email protected] / @fyufyu

http://research.nii.ac.jp/~f-ishikawa/

トップエスイーシンポジウム 2018/03

2018/03/23 f-ishikawa@TopSE Symposium 2

国立情報学研究所准教授ソフトウェア工学および，先端自律・スマートシステムに関する研究・教育

電気通信大学客員准教授社会人博士学生の指導（在学中も含め計9名）

産業界向け教育トップエスイー（形式手法，クラウド等）日科技連SQiP研究会（要求と仕様のエンジニアリング）電通大ウェブシステムデザイン（クラウド）興味：要求や仕様、設計に関する様々なモデルを活用した検証・推論・最適化・自動テスト生成・自己適応など

自己紹介

ERATO-MMSDプロジェクトグループ３リーダー物理世界や確率などの連続値や微分方程式を含み複雑なシステムの検証・品質保証（主に車）形式検証・テスト自動生成・最適化・機械学習などの技術を適宜活用・併用する実用的検証手法の追求

機械学習（や広くAI）を含むシステムの品質保証コミュニティ活動，概念や技術の整理検証・品質保証のための具体的な技術の研究

形式手法における工学的支援・応用形式仕様の段階的詳細化における保守や再利用IoTプラットフォームにおける自己適応機構

最近の主な活動


日本ソフトウェア科学会機械学習工学研究会主査2018年4月から（3月までは「有志一同」での活動）5/17：キックオフシンポジウム（一橋講堂）7月：合宿形式ワークショップ（三浦半島）https://sites.google.com/view/sig-mlse/

AIプロダクト品質保証コンソーシアム副運営委員長ガイドラインや保証レベルの策定など来週プレスリリース予定4月活動開始（月例）http://www.qa4ai.jp/

AI・機械学習に関するコミュニティ活動


イメージをもつための事例


ソフトウェアシステムの「品質」残念ながら個人・組織・社会に損害をもたらす問題も多々起きてしまっている

とはいえ技術的な進歩・累積も大きい

機械学習あるいはAIを用いたシステムは何が違うのか？？

はじめに

[ https://www.standard.co.uk/news/world/passengers-face-chaos-after-airport-checkin-systems-crash-across-globe-a3645816.html ]

一例：2017/09/28


いつかあるかもしれない社会的大事件

[ http://www.dailymail.co.uk/news/article-3677101/Tesla-told-regulators-fatal-Autopilot-crash-nine-days-happened.html ]

2016年のテスラ自動運転車の事故テスラの発表：「まぶしい空に対してトレーラーの白い側面を認識できず」（「運転者すら」ともある）

2017年11月の調査報告での論点に上記は全くなく，「そもそも自動運転の対象外状況だが運転者が長らく操作していない」という過信や，アラートの効力が中心

[ https://www.tesla.com/jp/blog/tragic-loss ]


[ https://dms.ntsb.gov/pubdms/search/hitlist.cfm?docketID=59989 ]

ここが機械学習


Uberの自動運転車（試験運転中）による死亡事故数日前の事故なので，調査詳細を待たずに，何かの判断や結論などは出さないで下さい暗がりから突然道路を横断する歩行者「人間の運転手だろうが，これは避けられないのでは」（レーダー搭載有無は不明）

その２（現時点では仮情報）

[ https://headlines.yahoo.co.jp/hl?a=20180322-00000037-zdn_n-sci ][ https://www.recode.net/2018/3/21/17149428/uber-self-driving-fatal-accident-video-tempe-arizona ]車載カメラの映像がそのまま出ているので要注意

社会的影響の大きな例・技術的限界の例

[ https://www.theguardian.com/technology/2018/jan/12/google-racism-ban-gorilla-black-people ]

Googleフォトの画像認識被写体の自動タグ付け機能黒人を「ゴリラ」とタグ付け2年経って本質的には直せていない（ゴリラを禁止ワード扱いにして対策）


[ https://www.theguardian.com/technology/2015/jul/01/google-sorry-racist-auto-tag-photo-app ]

最近のTweetより（Honda SENSING）

おまけ： Google画像類似検索ロゴイラスト部のみ切り取って検索「たぶん ”lip” 」といいつつ，デンマーク国旗と（その赤白逆の）イングランド国旗をまず推してくる

画像認識あれこれ（１）


[ http://www.tenkaippin.co.jp/company.html ]

（←これは40位くらい）

（進入禁止標識は出ず）

[ https://twitter.com/_gyochan_/status/938240168078622720 ][ https://twitter.com/Bleu_kakeru727/status/937680760491753473 ]

[ https://www.google.co.jp/imghp ](2017/12/11)

注：利用者への注意ありhttp://www.honda.co.jp/hondasensing/feature/srf/

Deep Learningに関する論文より

画像認識あれこれ（２）


[ Huang et al., Safety Verification of Deep Neural Networks, 2017 ]

[ Goodfellow et al., Explaining and Harnessing Adversarial Examples, 2015 ]

有名な例「パンダ」が「テナガザル」に

Twitter Botによる（ユーザを真似た結果の）不適切発言

訓練データに関する例


[ https://www.nytimes.com/2016/03/25/technology/microsoft-created-a-twitter-bot-to-learn-from-users-it-quickly-became-a-racist-jerk.html ]


要求と不具合・運用について考える例

[ https://twitter.com/RapidUTL/status/932189705088598017/photo/1 ](2017/11/19)

[ https://translate.google.co.jp/ ](2017/12/11, 2018/3/21)

以下で同時期（11月中旬）に話題になったような「他の変なもの」も挙動が変わっている？https://togetter.com/li/1173236

「あら」の扱いが修正？？

“Fish Soup”になるわけではない？


でも「似たような」技術で，皆さんビジネスや実世界の制御やるのですよね？物体認識に基づく自動運転音声認識に基づくAIスピーカー・AI家電など商品の売上げ予測に基づく生産・発注制御などバグ予測や工数予測に基づくプロジェクト管理判断など・・・

（「あら汁」で損害賠償請求されることはないだろうが）

皆さんのシステムではどう「品質」に向き合っていく？

後半の例題チョイスは遊びすぎました

これらすべて「バグ」か？潰さなければならないのか？そもそも潰せるものなのか？それとも技術的限界？どうやってこれらに気づくのか？他に対処すべき「同種」や「類似」の状況は列挙できるのか？どうやって？そもそも何を持って「品質保証」「完成」とするのか？「仕様」は何なのか？事前に見積・合意できるのか？修正内容をどう決めてどれだけの頻度で更新するのか？顧客やユーザには何をどうやって説明するのか？こんな挙動の原因を把握したり，予測し踏まえてテストしたりできるのか？どうやって？開発者ならわかるものなのか？外部品質保証者は何ができるのか？

・・・

何を考えますか？



従来のソフトウェアとはだいぶ性質が異なる「技術的負債」の存在

品質の観点・指標やその担保施策が大きく異なるCASE： Changing Anything Changes Everything（コードではなく）データに対する依存性分析や保守・管理などのエンジニアリング統計のパラドックス，フィードバックループの影響など固有の留意点

「何とかVer. 1.0リリース」は借金の始まり・・・

さらに・・・保守もこれまでよりさらに難しい

[Sculley et al., Machine Learning: The High-Interest Credit Card of Technical Debt, 2014]

Googleでの経験から14個の負債を紹介けっこう刺激的なタイトル

本質的な違い（１）：実世界アプリケーション



Zave/Jacksonのモデル

マシン（開発の成果物）の仕様 S は，要求 R を満たす

例：

「システムが何をするか」のそもそも

S, E R

[Zave et al., Four Dark Corners of Requirements Engineering, 1997]

[ http://www.fujitaka.com/ ]

R • enter 発生回数 ≦ pay 発生回数

S • pay の発生を検知したら，unlock する• push の発生を検知したら， lock する

RE S

World (Environment) Machine


Zave/Jacksonのモデル

マシン（開発の成果物）の仕様 S は，想定環境（ドメインの性質） E の下で，要求 R を満たす

例：

「システムが何をするか」のそもそも

S, E R

[Zave et al., Four Dark Corners of Requirements Engineering, 1997]

[ http://www.fujitaka.com/ ]

R • enter 発生回数 ≦ pay 発生回数

S • pay の発生を検知したら，unlock する• push の発生を検知したら， lock する

E• push と enter は交互にしか起きないと仮定• lock が起きてから unlock が起きるまでは

push は起こせないと仮定

RE S



先の例は古典的なもの（20年前）しかし，ソフトウェアづくりにおいて，そこまで実世界における真の R と向きあっていなかったかも

先の例では，その気になれば，V&Vは可能SとEがRに対して十分であるかの正当性検証Eの仮定の下考えることが現実的かの妥当性確認

消える境界

RE S



実世界に踏み込むCPS，IoT（自動運転が象徴的）しかし，ソフトウェアづくりにおいて，そこまで実世界における真の R と向きあっていなかったかもソフトウェア制御の範囲（Sの範囲）が広がり，実世界における真のRを直接扱うことが可能に・必要に先の例では，その気になれば，V&Vは可能

SとEがRに対して十分であるかの正当性検証Eの仮定の下考えることが現実的かの妥当性確認

RとEにおいて「扱う範囲の境界」が不明確で，さらにRやEの完全・網羅的な把握や予測は不可能

消える境界

RE S


本質的な違い（２）：振る舞いの帰納的な決定



演繹諸前提から論理の規則にしたがって必然的に結論を導き出すこと。普通、一般的原理から特殊な原理や事実を導くことをいう。

帰納個々の特殊な事実や命題の集まりからそこに共通する性質や関係を取り出し、一般的な命題や法則を導き出すこと。

参考：演繹と帰納

[大辞林（三省堂） via https://kotobank.jp/ ]


演繹的システム開発（従来）計算や判断を行うための知識・規則（モデル・アルゴリズム）を，人が決めてプログラムという形で書き下す

帰納的システム開発（というか機械学習）計算や判断を行うための知識・規則（モデル・アルゴリズム）を訓練データから獲得し生成するそれを行うプログラムを人が書き下す

※ 広く「AI」というだけだとどちらの作り方もありうるが，後者の場合，開発・運用・品質保証が大きく変わる

演繹的システム開発と帰納的システム開発


同じ場所で摂氏・華氏両方を計ることを大量に行うという手段でも，「摂氏・華氏変換」の実装はできる（嬉しいかどうかはともかく）

例（PFN丸山さん資料より）

[丸山宏，PPL 2018，演繹から帰納へ～新しいシステム開発パラダイム～https://www.slideshare.net/pfi/20180305ppl2018 ]


別の例

[ http://free-photos.gatag.net/ ]

35 24 210 20 121 24 122 81 20

211 54 42 12 222 90 88 79 116

24 36 98 98 181 31 66 31 198

0 245 231 20 121 24 122 101 0

211 54 42 12 222 90 88 79 114

24 56 78 98 199 14 66 31 198

0 245 231 20 121 24 122 101 0

211 54 42 12 222 90 88 79 114

24 56 78 98 199 14 66 31 198

0 245 231 20 121 24 122 101 0

211 54 42 12 222 90 88 79 114

24 56 78 98 199 14 66 31 198

0 245 231 20 121 24 122 101 0

211 54 42 12 222 90 88 79 114

24 56 78 98 199 14 66 31 198

0 245 231 20 121 24 122 101 0

211 54 42 12 222 90 88 79 114

24 56 78 98 199 14 66 31 198

パンダテナガザル

この線引きを訓練データから作るイメージ

※ 数値データ表現は画像によりもちろん違うはずですが面倒なのでコピペしてしまっています


すごいこと人が明確に規則として書き出せないことも，訓練データが大量にあれば判断・予測などの計算ができる「この画像はパンダの画像だ」「本Aを買った人は，きっと本Bにも興味がある」

訓練データを更新していけば，新しいことに対応できる今月デビューした芸能人の画像も判別可能にユーザごとのクセがある音声指示も認識可能に

※ なぜ最近この点が持ち上げられるようになったのか，関連してディープラーニングとは何なのか，は省略

機械学習（帰納的システム開発）


大変なこと大量かつ「適切な」訓練データが必要

正面写真しか見せなければ，横からの写真を判別できるようにはならない

Twitterbotによる暴言の例

訓練データがあればうまくいくとも限らない訓練データ外のデータでどう振る舞うかは未知何がなぜ起きるのかは前もって説明できず，後付けで説明することすら難しい・できないことがあるパンダとテナガザルの例Googleのゴリラの例

機械学習（帰納的システム開発）

根本的なスタンスの変化


本質的な難しさの要因（の一部）（１）


１．入力・適用状況，および出力への要件が無数にある

２．絶対的なオラクルがない

４．動かすまで挙動や精度，変更影響が十分に予測できない

データに基づき帰納的に

部品を構築する

３．出力は学習データに強く依存し，出力が得られた理由を

演繹的には説明できない

実世界や人の感覚により深く踏み込む応用事例を扱う

本質的な難しさの要因（の一部）（２）


何が実際実現できているのか把握・説明できず，問題の原因同定・修正も難しい

テスト入力を多数用意しても成否判定が困難・高コストで，明らかなコーディングミス等すら気づかない可能性がある

１．入力・適用状況，および出力への要件が無数にある

２．絶対的なオラクルがない

４．動かすまで挙動や精度，変更影響が十分に予測できない

３．出力は学習データに強く依存し，出力が得られた理由を

演繹的には説明できない

実行時に想定外のことが発生することが原則になる

要求の実現可否・実現コストや変更の影響を事前に把握しての分析・意思決定は難しい

本質的な難しさの要因（の一部）（３）


ん？全部「不確かさ」の話じゃないか！

要求と評価指標，入力，実装，出力が不確か






自然に必要となるだろうスタンス





より上位のシステム全体で失敗の対応策を打つ

実行時に継続的な監視・評価を行いフィードバックする

構築過程から部分部分に対し確信が持てる構築方法を用いたり検証手段を設けたりする（想定する性質のアサーション等）

探索的・試験的に仮説・分析・評価を繰り返す

システムの上位の目的（ユーザ体験や安全性）の観点からフィードバックを得る

疑似オラクルを用意し大量に（ゆえに自動）テストをする

ヒント



NIPS，ICML等の機械学習系国際会議特に併設ワークショップの”Reliable Machine Learning in the Wild”や”ML Systems”など，アルゴリズムよりも実用システム構築上の課題に着眼したものGoogleなど企業の招待講演が多く参考になる

ソフトウェア工学系国際会議では最近急に間接的にヒントになりそうなものは昔から：[email protected]，疑似オラクルを用いたテスティング，サーチベースドテスティング，メタモルフィックテスティングなどなど

先人のヒント


機械学習における「技術的負債」（前述）従来のソフトウェアにおけるものに加えて，固有の負債が多数ある難しさとその対策例： Changing Anything Changes Everything

ベストプラクティス集例：問題が顕在化しない失敗を見張れ

どれだけ監視・テストできているかの評価スコア例：個々のfeatureの分布が予想と合っているかどうか

機械学習コミュニティで出ている原則・指針

[ Sculley et al., Machine Learning: The High-Interest Credit Card of Technical Debt, 2014 ]

[ Zinkevich, Rules of Machine Learning: Best Practices for ML Engineering, 2016 ]

[ Breck, What’s your ML Test Score? A rubric for ML production systems, 2016 ]


[email protected]アプローチが代表的

要求，仮定・想定や，設計に関する意思決定の論理などのモデルを明示化し，システムが実行時にも活用現実とモデルのずれを検出・同定しやすく，また意思決定の論理をたどり直して自動設計変更などのフィードバックも可能に

CPSや自己適応に関連するソフトウェア工学研究において2010年代盛んに取り組まれている一つの方向性ただし帰納的な振る舞いを主眼においてはこなかった

ソフトウェア工学と不確かさ


Before

After

[email protected]

……

…

……

…

………

要求，想定，設計などのモデル（ときに暗黙）

人が解釈しコードとして表現

開発時実行時

様々なことがらの結果としての不具合が表出（機械学習だとここで不具合に気づかないかも）

想定などを掘り起こしつつ，人の理解により原因追求

要求，想定，設計などのモデル

（明示・形式化）モデルをシステムに持たせる

システムが常に想定などを監視，違反や例外を検出（可能なら自身でモデル・コードを同期しつつ更新）

出力やログ

出力やログ


様々な言葉“Models need to continue to live at run-time and evolve as changes occur while the software is running”

“Run-time reasoning over requirements is necessary where design-time decisions about the requirements are made on incomplete and uncertain knowledge about the domain and the stakeholders’ goals”

“a runtime model can be seen as a live development model”

[email protected]

[Baresi et al., The Disappearing Boundary Between Development-time and Run-time, 2010]

[Sawyer et al., Requirements-Aware Systems - A research agenda for RE for self-adaptive systems, 2010]

[Blair et al., [email protected], 2009]


（V字モデルなど眺めるよりむしろ・・・）

制御工学におけるフィードバックループ「自己適応システムのためのソフトウェア工学」の人たちには常識

参考になるアプローチ？？（１）

[ https://en.wikipedia.org/wiki/Feedback ]

制御したい対象：思い通りにできない不確かなもの

何かの「外乱」の影響があるずれを計って

制御の仕方に反映

[ Filieri, Control theory for software engineering: technical briefing, 2016 ]


（V字モデルなど眺めるよりむしろ・・・）

例：車におけるエンジン周り監視の「3レベル」アウディ，ダイムラー，ポルシェ，フォルクスワーゲンで「差別化要素がない」として標準化

参考になるアプローチ？？（２）

[ Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units Ver. 6.0, 2015 ]

機能

機能の監視

独立した監視

機械学習システムの検証・テスティング研究動向



メタモルフィックテスティング多数の入力を用いてテストをしたくても，各出力の正しさ（テスト成否）を判定するのが困難または高コスト「入力を変えると出力はこう変わるはず」という関係を検証，既存テストケースから多数のテストケースを生成

背景技術：メタモルフィックテスティング

Software Under Test入力1 出力1

Software Under Test入力1’ 出力1’

これを見てもテスト成否判断が困難

ある変換TTに応じた変換M(T)

[ Segura et al., A Survey on Metamorphic Testing, 2016 ]例： sin(x) = sin(π - x)

出力1’期待値

照らし合わせ


サーチベースドテスティング最適化技術（メタヒューリスティック）を用い，「欲しいテストケース・テストスイート」を表すスコアを最大化するようテストスイートやテストケースを生成例：「車が人に最も近づくような危ういテスト」ケースを生成例：「前バージョンと比べ出力が大きく変わる」入力を発見例：「高カバレッジで小さい」回帰テストスイートを生成

背景技術：サーチベースドテスティング

テストケーステストスイートの候補群（第n世代）スコア評価

淘汰・進化（突然変異・勾配など）

テストケーステストスイートの候補群（第n+1世代）

[ S. Ali et al., Systematic Review of the Application and Empirical Investigation of Search-Based Test Case Generation, 2010 ] [ http://www.evosuite.org/ ]


メタモルフィックテスティングの適用時系列分析で入力に一定の幾何学変換をかけるドローンシステムで地図を回転など変化させるより分類が難しいコーナーケースを生成する

ディープラーニングのホワイトボックステストサーチベースドテスティングニューロンのカバレッジを上げるとともに，比較対象の別実装との出力差分を上げるように，テストスイート（テスト入力セット）を最適化

機械学習システムへの応用例

[ Pei et al., DeepXplore: Automated Whitebox Testing of Deep Learning Systems, 2017 ]

[ Jarman et al., Metamorphic Testing for Adobe Data Analytics Software, 2017 ]

[ 中島,データセット多様性のソフトウェア・テスティング, 2017 ][ Lindvall et al., Metamorphic Model-based Testing of Autonomous Systems, 2017 ]


GAN（Generative Adversarial Networks）機械学習コミュニティでは盛ん（ここでは軽く）雑には，品質保証・向上対象の機械学習部品に対して，「敵対的」な機械学習部品をぶつけ，同時に育てる（「失敗のさせ方」を学ぶテスターも同時に育てる）

形式検証技術（SMTソルバー）の応用画像認識において，「一定範囲の画像操作」を行っても認識結果が変わらないかどうかを網羅的に検証

他の技術

[ Goodfellow et al., Generative Adversarial Networks, 2014 ]

[ Huang et al., Safety Verification of Deep Neural Networks, 2017 ]


システム全体の要求を踏まえるのが重要なのでは機械学習部品（生成されたモデル）の精度だけむやみに突き詰めても例：遠くの物体を誤認識しても衝突には至らないかも

システムレベルの要求に基づくテスティング

[ Dreossi et al., Compositional Falsification of Cyber-Physical Systems with Machine Learning Components, 2017 ]

１．完璧な機械学習部品を用いると要求を満たすが，常に失敗する機械学習部品を使うとそうならないような入力パラメータ領域を絞り込む

２．その領域に限定して機械学習部品が誤認識するような画像を探す

３．その画像を用い要求を満たさないケースを探す

例題：自動ブレーキシステム（人の操作や先行車の位置が入力，「先行車との距離が一定以上ある」ことが要求）

テスティング技術マップ（更新中）対象学習・推論

コンポーネントテストアプローチ

モデルシステム

系統的網羅的

特定観点でのあぶり出し

テストデータ量増加仮説確認

画像生成による系統的テスト[Dreossi@MLWild_ICML’17]

ニューロンカバレッジ[PEI@SOSP’17]

疑似オラクルとの差異最大化[PEI@SOSP’17]

システムレベルオラクルに基づくモデルのテスト[Dreossi@NFM’17]

深層学習のメタモルフィックテスティング[Ding@MET’17]

Adobe Anomaly detectionのメタモルフィックテスティング[Jarman@MET’17]

ドローン制御のメタモルフィックテスティング[Lindvall@MET’17]

故障学習器のメタモルフィックテスティング[Murphy’08]

2018/03/23 f-ishikawa@TopSE Symposium

SVMの分類困難なデータの生成[中島@JSSST’17]

48

おわりに



MLSE meet-up #1 での議論をまとめた結果

問題はたくさん

[ 吉岡ら, SEチャレンジ: 機械学習 x ソフトウェア工学 = 機械学習工学, 2017 ]


企業では学びにくいことを学び試していただいた例：形式手法（理論や一般論をおさえないといけない部分もあり，教える側になるのはなかなか難しい？）

先端の論文を調べ，先端手法を試していただいた例：サーチベースドテスティング

目の前の問題から離れ，現状にとらわれず，あるべき手法やプロセスを検討していただいた例：「5年後も今のやり方，では無理，それでは？」

トップエスイーで起きてきたと思うこと（１）


普段よりも広い視点から，厳しい意見も受けて，方向性の検討や評価をしっかりできた講師となる人はたいてい活動範囲がとても広く，特定の「常識」「しがらみ」にとらわれたりしていない人がほとんど

会社の外での情報収集や議論が当たり前になったという人もいる（日々の仕事にまた埋もれてしまう人もいる）

トップエスイーで起きてきたと思うこと（２）


別に企業だからできないこと，ってないはず形式手法ものすごく詳しい企業の方はたくさんいる今日出したテストの話など，私より速くフォローしている人ももちろんいる前述のことは当たり前な企業さんもある

Googleは「開発と研究を離さず一体化」これが機械学習の難しさに効いているという話研究チームが出したものを，開発チームにとって「ブラックボックス」にしないなど

企業の皆さんだけでいいんじゃない？

[ Spector et al., Google’s hybrid approach to research, 2012 ]

[ Sculley et al., Machine Learning: The High-Interest Credit Card of Technical Debt, 2014 ]


現状「学」にも頼っていただけている点はとても嬉しく思い，頑張っていますトップエスイー13期生過去最大の受講生数

きっと「学」が得意なことがある先々のことを自由に考え，あるべき姿を描いている？概念整理や，知見の一般化，それらを目的とした実験などをすることが（企業よりも）「仕事」になる？一見離れた（目の前の問題には出て来ない）昔の思想や技術などをおさえている？中立の立場で相談を受けられる？

機械学習やAIについてもきっと活きる！

とはいえ・・・


※ 改めて機械学習（AI）の話

今までソフトウェア屋さんがサボってきた・やりきれてなかったことが突きつけられているのかも画面の外の実世界での意義や安全性，ユーザの感性的な満足の追求や評価，探索的・試験的な投資や問題解決，仮説と検証による科学的な判断や評価，常に測定，数学の理解・活用，Correctness-by-Construction，現実問題の数学的問題（最適化等）への帰着，実行時検証やテスト自動化（入力生成・疑似オラクル），といったことへの本気のパラダイムシフト，・・・

産学で楽しんで切り拓いていきましょう！

おわりに

機械学習における 品質保証のチャレンジ ～産学連携による突破...

Documents

機械学習における品質保証のチャレンジ～産学連携による突破...