Data Driven Developer Meetup #5 (2019.3.7) の発表資料です スライド中のリンクを参照したい場合はPDFをダウンロードすると便利です。
深層学習を実運用システムに組み込むということ(画像データによる製造現場での異常検知システムを例に)BrainPad Inc. 吉田勇太Data Driven Developer Meetup #5
View Slide
自己紹介- 吉田勇太/ysdyt(@yutatatatata)- 株式会社ブレインパッド- リードデータサイエンティスト- 学生時: バイオインフォマティクス- 業務: 画像分析・機械学習システムの導入- 個人: 病理画像分類システム・某webサービスの自然言語処理分析- 白金鉱業 Meetup, Data Analyst Meetup Tokyo- WEEKLY人工無脳, MSゴシック絶対許さんマン
- DSがたくさんいる会社です- 受託分析の老舗- データがあるあらゆる業界- 1案件3ヶ月~- 1案件につきPM1名, メンバー1~2名, 営業1名, 技術アドバイザー1名が一般的なチーム構成- 2015年後半くらいから深層学習(AI) のビジネス活用が出始めるhttps://ai.brainpad.co.jp/people/list/
受託分析は難しいけど、やりがいのあるお仕事(続くツイートをまとめると)- 機械学習システムはPoCが必要- PoC費用はR&D費から出ることが多く、一般的にR&D費は少額でかつ真っ先に削られる予算- 継続的開発が難しい- 各社の課題, データ, 仕様が違うので技術的にもアセットになりにくい- SaaSにもしにくい- SaaSパッケージにしたり技術特化しないと, 分析・AIの技術はレッドオーシャンになる一方そんな中、2019/3/18でブレインパッド社は創業15周年
- 社員による対外向け趣味活動チーム- 「技術の無駄使い」作例- MSゴシック絶対許さんマン- 機械学習で50フォントの中からMSゴシックを見つけて床に捨てるロボット(※MSゴシック大好き!)- 麻雀牌のリアルタイム検出- 画像解析によるリアルタイムでの麻雀点数の自動計算を目指して。Google DevFest Tokyo2018でも登壇。- オフトゥンフライングシステム- ダジャレの面白さを機械学習で判定。一定スコア以上で布団が吹っ飛ぶ!ホリエモン万博にも招待され展示。
(宣伝)白金鉱業 Meetup- ブレインパッド有志メンバーで運営しているDS, MLエンジニア向けの交流会兼勉強会イベント- だいたい各月開催- 弊社DS、DS部門の部長・副部長、営業部も発表- 社外スピーカー(業界不問・同業welcome)- ABEJA齋藤さん, マスクド・アナライズ氏,メルペイ藤原さん, Classi伊藤さん, u++さん- 弊社卒業生の人に喋ってもらったり- GROOVE X アレさん, PFN菅原さん- 次回Vol.7は4月末予定!
本日の内容■ 話さないこと- 実際のプロジェクト内容- 深層学習アルゴリズムの詳細- 機械学習システム導入はなぜ失敗するか←■ 話すこと- 異常検知システム構築にまつわる概要- 「不良品検知精度さえ高ければ良い」の罠- 半機械・半人力なシステムを目指して- 機械学習システムを”高利子クレジットカード”にしないために- MLOpsの前にやるべきことをフォローしましょう
深層学習ベースの異常検知について
深層学習ビジネス活用の主戦場は”画像”- ビジネスでは特に製造現場の異常検知系の製品が多い印象- 弊社も受託でやってる- キユーピーさんの不良ポテト検知事例- 現場によって全てが違う。SaaS提供しにくい分野- PFNさんは最近サービス提供を始めた- PFN Visual Inspection図引用: https://pvi.preferred-networks.jp/
(背景)製造現場は想像以上に目検が多い- 良品にもバリエーションがある- ルールベースでは弾けない不良- “例外”の存在- ある面からは不良に見えても総合的には良品判定 とか- 人間は高性能の割に安い- 良品にも微妙な個体差がある- 人間でも「不良」の定義が曖昧
(ニーズ)目検を減らしたい- 単純労働は人の確保が難しい- 労働人口減少- 人件費削減したい- 定量評価を求める発注主AIで自動化して人をゼロにしたい図引用: https://www.youtube.com/watch?v=9Zja1INR4l4評価結果と共に定量値も表示
製造現場の異常検知- キューピー- 不良品ポテトの除去- PFN- PFN Visual Inspection図引用: https://www.businessinsider.jp/post-108027
製造現場の異常検知- 不良品を発見できればミッション完了?- そう単純でもない- 難しさは現場のオペレーション・製造体制・不良定義に寄るところが大きい- アルゴリズムの精度さえ高ければいいわけではない
Precision, Recallの厄介な話
『Precision, Recallはトレードオフである』- 機械学習初心者が習うやつ- Precision(誤検知)とRecall(見逃し)
自動運転車事故の話トレードオフといいつつ、結局両方高くないとまともに走る車ができない記事: https://gigazine.net/news/20180508-uber-fatal-crush-software-bug/- Uberの自動運転車が人をはねた話- 道の先に見えている物体は「人」か「ゴミ」か?- ゴミを人間と誤検知してしまう→ 動かない車- 人を見逃してしまう→ 事故を起こす車- 人間を見逃さないようにRecallを高める- ブレーキを掛けがちな車になる
不良品を見逃したくないのでRecallが重要?- ではPrecisionを下げてでもRecallを徹底的に上げれば問題解決?- そうじゃない- 良品の誤検知問題(Precisionを低くした場合)- 製造現場では良品の方が圧倒的に多いという事実- 1日に数万~数十万個生産- 検知精度が高くとも、誤検知されたものは絶対数として少なくない
良品の誤検知問題- 良品の誤検知自体がコストになる場合もある- 単価の高い商品の場合- 不良品を再度原料に戻して再利用する場合(ex. 不良ネジを溶かして再度成形)- 不良品を精度良く検知できても、良品誤検知が増えてコストが減らせないなら導入する意味がない!- Recallを上げる代償にPrecisionを下げる、ということは実は出来ないという現実のジレンマ- PrecisionもRecallも8割あるのに!不良品検知精度十分高いのに!オペレーションに乗せられない!、ということが起こる。ではどうする?
目的と現場に合った「ちょうどいい塩梅」を探す- 誤検知を許容する(不良品は見逃さない)- 誤検知・見逃しを多少許す- 人間に一部判断を任せる図引用: https://www.slideshare.net/pfi/20181018-ceatec-picking-robot
目的と現場に合った「ちょうどいい塩梅」を探す- 誤検知を許容する(不良品は見逃さない)- 誤検知・見逃しを多少許す- 人間に一部判断を任せる「これをAIがいい感じにしてくれるのではなかったの?」と思われがち図引用: https://www.slideshare.net/pfi/20181018-ceatec-picking-robot
「半機械半人力」システムの中で人間がやるべきこと
- 人の介在を前提とした機械学習の仕組みづくり- ex. 難しいところだけ人間が判断- 全量目検と比較すると大幅コストダウン- ex. 機械が判断したものを人間が抜き打ちチェック(ダブルチェック)- 機械学習の精度の「ラストワンマイル」を埋めようとすると大きなコストがかかるが、人間なら比較的簡単に行える- Human-in-the-loopで精度改善していく- オペレーションを工夫して割り切りも大切(目的を明確に!)機械学習システムと人の役割分担
オペレーションも環境も変化が必要どれを選択するかで現場オペレーションも変わる- 誤検知を許容する- 誤検知・見逃しを多少許す- 人間に一部判断を任せるオペレーションが変わると現場環境(ハードウェア)も変わる可能性高- 撮影システムの変更- ベルトコンベアシステムの変更- 不良品を除去する装置の変更 など←誤検知はどう扱う?←不良品をその後どう取り除く?←システムが判断した部分は盲目的に信じる?機械学習システム導入は、人的なコスト(AIのお守り)も設備投資も必要⇒ システム導入インパクトの試算はもちろん大切
機械学習システムを高利子クレカにしないために- 保守・運用- Human-in-the-loopで人を設置する- 人的コストを完全にゼロにはできない- システム担当者にはそこそこリテラシーが必要(結果の見方、何をしていうのか理解、うまく動かない場合の原因イメージ)- 現場の人でも扱える再学習(他製品展開)機能が必要- DSが張り付くわけではない- 現場人がパラメータチューニング的なことをしないといけない- 定量評価結果を理解するためのリテラシーが必要(Precision/Recall)- ちょっとしたトラブルには現場だけで対応できないといけない- 社内に機械学習担当者が必要orリテラシーを現場で高める
- 技術面- アルゴリズムの汎化性能- 新商品にも全部1商品1model作るのはちょっと…- 良品が「完全な定形」ではない物体に対する検知の難しさ- ex. 完全な定形: ネジとか- しかし意外にそういった製品は多い- アノテーションの質を一定にし続ける難しさ機械学習システムを高利子クレカにしないために
MLOpsの前に当たり前の設計を当たり前にやる必要な業務フローを書き出し、それぞれで検討すべき課題を一つづつきちんと潰す
まとめ- 製造現場の機械学習異常検知システムの話をしました- 深層学習(AI)が全自動でよしなにやってくれるわけではない- 不良品検知精度が高いだけで課題解決というわけではない- 良品の誤検知問題 など- 人間も関与するHuman-in-the-loopなシステムが健康的- 検知方法・オペレーション・ハードウェアを目的に則して変化させる- MLOps的なことも考えないといけないが、その前に業務フロー整理や課題の洗い出し、システム設計などの当たり前をきちんとやるのが大切
その他、BP社の機械学習システム開発関係スライド併せて読みたい、弊社メンバーがこれまでに公開したわかりみが深いオススメの資料たちです大東建託さんにおける、深層学習を活用した画像自動分類の業務システム構築案件についてhttps://www.slideshare.net/BrainPad/ss-125027959八千代エンジニヤリングさんにおける、コンクリート護岸の劣化をAIで自動判定するサービス「GoganGo」の開発エピソードについてhttps://www.slideshare.net/BrainPad/20181115-125027419
その他、BP社の機械学習システム開発関係スライド併せて読みたい、弊社メンバーがこれまでに公開したわかりみが深いオススメの資料たちですBP社DS部門副本部長による弊社機械学習システム案件のあれやこれやが整理された全部盛り資料!https://www.slideshare.net/BrainPad/ss-131876455
ではデータ分析や、機械学習の社会実装を通じて社会を良くしていく仲間を大募集中です!分析のことでも会社のことでも、超気軽に話しかけてください~!Follow me @yutatatatata
(追記)会場からの質問- Q: プロジェクトのどの段階で業務フローの洗い出しや課題検討を行う?- A: 理想はプロジェクトの一番最初。- しかし現実は「AIプロジェクトをやるぞ!」というクライアントに「では業務フローの洗い出しから…」とお願いするとプロジェクト全体の士気が下がることも。- なので、PoCで良い結果を出したり、試作機など動くものを作ってチームの熱量が高まったところでお願いをするというのも一つのやり方。(※何かと連携することが決まっているor工場ラインのように後から修正が難しいものものはそれでも早めに要件定義が必要)- AIプロジェクトでは長い期間に渡って泥臭い作業が沢山発生するので、チーム全体のモチベーションを高く保てるかどうかも重要なポイント(だってにんげんだもの)