機械学習を「社会実装」するということ 2022年版 / Social Implementation of Machine Learning 2022

Moe Uchiike（内池 もえ）

January 11, 2022

Tweet Share

Transcript

1. ೥൛ ʕ ࣾձ࣮૷Λ્Ήʮ᠘ʯͷͦͷઌ΁ʕ ※この資料は、東京⼤学グローバル消費インテリジェンス寄付講座 (GCI) 2021 Winterの講義で使⽤したものです。

2. 1 誰︖ • 株式会社ブレインパッド アナリティクス本部 アナリティクスサービス部所属 リードデータサイエンティスト • 現在は機械学習案件や数理最適化案件のPM兼モデル開発リーダーとして⽇々奮闘 •

   ⼿掛けたアルゴリズムのグローバルでのリリースにPMとして貢献した実績を持つ • 松尾研究室主宰 DL4USの2期⽣。最終課題は 「おでんの需要予測」 ⾃⼰紹介 - 内池 もえ - 本⽇は、現在進⾏系で 「使える機械学習システム」 の開発に奔⾛している実務家の⽴場からお話しさせていただきます︕ Copyright © Moe Uchiike All Rights Reserved.

3. 2 注意事項 Copyright © Moe Uchiike All Rights Reserved. 本講義では、特に断りがない場合

   「法⼈向けの機械学習システム」 を想定して話を進めます。 BtoCなどのビジネス形態の場合は、また違った難しさがあるかもしれません。

4. 3 ⽬次 アイスブレイク パンデミック時の需要予測、どうする︖ 第１章 2022年の機械学習プロジェクト 第２章 社会実装までのプロセスと 「罠」 のマッピング

   第３章 社会実装を阻む 「罠」 と、その解決策 まとめ 本⽇お伝えしたかったこと Copyright © Moe Uchiike All Rights Reserved.

5. 4 Copyright © Moe Uchiike All Rights Reserved. アイスブレイク︓パンデミック時の需要予測、どうする︖

6. 5 アイスブレイク︓パンデミック時の需要予測、どうする︖ まずは１つ課題を出します。以下の状況を踏まえ、考えたことをアウトプットしてみてください。 状況 • 皆さんは、世界中に店舗を展開している和⾷チェーンにおいて、機械学習による需要予測プロジェクトのPMを務めています。 • このプロジェクトでは、翌⽉に必要になる⾷材の需要量をモデルで予測し、その予測結果をもとに⾷材が発注・納品されることを⽬指します。 • 既に皆さんは数々の試練を乗り越え、いよいよ本番稼働というタイミングになりました。

   • ところが、このタイミングでパンデミックが起こってしまいました。このパンデミックはいつ収拾がつくかわかりません。 • 学習データは過去３年分しかなく、かつ過去３年間に類似のパンデミックは起こっていません。 皆さんならPMとして、この問題にどう⽴ち向かいますか︖ ３分間で考えてみてください Copyright © Moe Uchiike All Rights Reserved.

7. 6 アイスブレイク︓パンデミック時の需要予測、どうする︖ 思いつくこと (例) • そんな時期に予測が当たるはずがないじゃないか︕ • そもそも店舗は開いているのか︖ • 需要予測が

   「⼤外れ」 した場合の経済的損失やフードロスは︖ • その責任は⼀体誰が取るのか︖ • そもそもこの期間にモデルを稼働させるのか︖ 我々が⽴ち向かわなければならないのは、まさにこのような問題の数々︕ Copyright © Moe Uchiike All Rights Reserved. • 仮に稼働させるとして、予測値は 「後処理」 するべきではないか︖ • その 「後処理」 は何が適切か︖ルールベースなのか︖ • ローンチを遅らせてみるのはどうか︖ • ローンチを遅らせたとして、パンデミックの期間のデータはモデルに学習 させていいのか︖ いかがでしたでしょうか。この問題に明確な答えがあるわけではありません。 ですが、ありとあらゆることを考えなければならないことがわかります。 この事実に気づくことが機械学習の 「社会実装」 に直結します。

8. 7 Copyright © Moe Uchiike All Rights Reserved. 第１章︓2022年の機械学習プロジェクト

9. 8 第１章︓2022年の機械学習プロジェクト ほとんどのプロジェクトが社会実装されずに終わっていた GCI 2020 Summerの段階では、多くの機械学習プロジェクトが社会実装されることなく終わりを迎えている*1 とお伝えしました。 上流フェーズ PoC 開発フェーズ

   本番稼働 *1: Rob van der Meulen and Thomas McCall. Gartner Says Nearly Half of CIOs Are Planning to Deploy Artificial Intelligence. Gartner. 2018. https://www.gartner.com/en/newsroom/press-releases/2018-02-13-gartner-says-nearly-half-of-cios-are-planning-to-deploy-artificial-intelligence *2: Proof of Conceptの略語で、実証実験 (実際に上⼿くいくか確かめる活動) のこと Copyright © Moe Uchiike All Rights Reserved. ü PoC*2 はそう簡単に上⼿くいくものではなかった ü PoCが上⼿くいったとしても、その後のフェーズも⼀筋縄ではいかなかった ü 遡って、「上流フェーズでの問題設定が適切ではなかった」 ということも多々あった

10. 9 第１章︓2022年の機械学習プロジェクト ほとんどのプロジェクトが社会実装されずに終わ…らない︕︖ 2022年現在、機械学習プロジェクトが社会実装のフェーズを迎える機運が⾼まっています。 しかし、依然として社会実装を阻む 「罠」 は多数潜んでおり、ノーガードで⽴ち向かうことは困難です。 上流フェーズ PoC 開発フェーズ

    本番稼働 ü 「とりあえずPoC」 の時代が終わりつつあり、明確にシステムリリースや横展開を⽬指すプロジェクトが増加 ü 経験知の蓄積やアンチパターンの整理、プラットフォームの整備が急激に進んでいる ü 機械学習モデルのアウトプットを意思決定に導く⽅法 (数理最適化との組合せ 等) が洗練されてきている Copyright © Moe Uchiike All Rights Reserved. ü しかし、依然として社会実装を阻む 「罠」 は多数潜んでおり、ハードルは⾼いまま

11. 10 Copyright © Moe Uchiike All Rights Reserved. Ͳ͏͢Ε͹͍͍ͷ͔ʁ

12. 11 第１章︓2022年の機械学習プロジェクト 業界トレンドと求められるスキル 機械学習は実際に使うフェーズに。知識や経験を⼟台にして柔軟に思考し、想像⼒を働かせながら試⾏錯誤を続けることが求められます。 • システム化やDXの流れで、プロジェクトは⼤規模化・複雑化 • ツールや⼿法、⽅法論の急速な進化と多様化 • 「持続可能な機械学習システム」

    のニーズの⾼まり 業界トレンド 1. 3つの⼒を跨いだ経験知と、アンチパターンをフル活⽤する⼒ 2. ツールや⼿法、⽅法論の膨⼤な組合せから課題に適したアプ ローチを選び抜き、組み合わせて応⽤する⼒と、常識にとらわ れずアイデアを⽣み出す思考の柔軟性 3. ゴールを 「持続可能な機械学習システムの開発」 に定め、実 際に何が起きるか︖を広い視野で (論理的に) 想像しなが ら試⾏錯誤する⼒ 4. これらの⼟台となる統計学や機械学習の本質的な理解 (理屈がわからなければ想像や応⽤はできない) 求められるスキル 参考: ⼀般社団法⼈データサイエンティスト協会. データサイエンティストに求められるスキルセット. 2014. p.2. http://www.datascientist.or.jp/files/news/2014-12-10.pdf (参照2021-12-24) S データ サイエンス⼒ E データ エンジニアリング⼒ B ビジネス⼒ S データ サイエンス⼒ E データ エンジニアリング⼒ B ビジネス⼒ これまで • 3つのスキルを駆使してデータを活⽤する • どれか⼀つが⽋けると成り⽴たない これから • 個別のスキルは更に磨いていく︕ • 但し、内側にも磨いて重なる領域を増やしていく︕ → まずは、4を駆使して 「違和感に仕事をさせること」 から始める︕ Copyright © Moe Uchiike All Rights Reserved.

13. 12 Copyright © Moe Uchiike All Rights Reserved. ͱ ͸

    ͍ ͏ ΋ ͷ ͷ

14. 13 Copyright © Moe Uchiike All Rights Reserved. ʮ ཧ

    ૝ ͱ ݱ ࣮ ͷ Ϊ ϟ ο ϓ ʯ ͸ ଘ ࡏ ͠ ɺ ࣮ ࡍ ʹ ͸ ૝ ૾ Λ ௒ ͑ ͯ ༷ ʑ ͳ ग़ དྷ ࣄ ʹ ௚ ໘ ͠ · ͢ ɻ

15. 14 Copyright © Moe Uchiike All Rights Reserved. ͦ Ε

    Β ʹ ཱ ͪ ޲ ͔ ͏ ͨ Ί ʹ ɺ ʮ ࢹ ໺ Λ ޿ ͛ ͯ ʯ ʮ ࢹ ք ͷ ղ ૾ ౓ Λ ্ ͛ ͯ ʯ ʮ ࣌ ʹ ͸ ట ष ͘ ʯ औ Γ ૊ Μ Ͱ ͍ ͘ ͜ ͱ ͕ ٻ Ί Β Ε Δ ঢ় گ ͸ ม Θ ͬ ͯ ͍ · ͤ Μ ɻ

16. 15 Copyright © Moe Uchiike All Rights Reserved. 第２章︓社会実装までのプロセスと 「罠」

    のマッピング

17. 16 第２章︓社会実装までのプロセスと 「罠」 のマッピング ⼀般的な機械学習プロジェクトのプロセス ⼀般的な機械学習プロジェクトでは、Kaggleのように初めから 「綺麗な問題」 が⽤意されているわけではありません。 EDAやモデル構築だけでなく、それを⽀えるインフラの構築、問題設定やUI/UXの検討など、必要なタスクは多岐にわたります。 Copyright

    © Moe Uchiike All Rights Reserved. 業務理解 課題抽出 データ収集 基礎集計 基礎分析 問題設定 PoC 予算確保 要件定義 設計・開発 ・テスト UAT パイロット稼働 本番稼働 効果測定 保守・運⽤ 1 2 3 4 5 6 7 8 9 10 11 12 13

18. 17 第２章︓社会実装までのプロセスと 「罠」 のマッピング 現実 前スライドで機械学習プロジェクトの膨⼤なタスクについてお話しさせていただきました。 しかし、それだけではありません。これらのプロセスには、たくさんの 「罠」 が待ち構えています。 Copyright

    © Moe Uchiike All Rights Reserved. 業務理解 課題抽出 データ収集 基礎集計 基礎分析 問題設定 PoC 予算確保 要件定義 設計・開発 ・テスト UAT パイロット稼働 本番稼働 効果測定 保守・運⽤ 1 2 3 4 5 6 7 8 9 10 11 12 13 現実のデータは汚い︕ (データが 「印刷物」 で 「間違っている」 ことも……) 問題設定は難しい (できること≠利益) モデルの性能、どう測る︖ (モデルの性能≠説得⼒) 様々な制約 (インフラ、政治 等) その開発、誰がやる︖ (分析のプロ≠開発のプロ) 信頼を得るのは難しい (利害の不⼀致) 思わぬところに考慮漏れ (未知のデータのIF 等) 学習データにない未来 (⾃然災害、どうする︖) ビジネスインパクト、どう測る︖ (モデルの性能≠利益) 順⾵満帆とは限らない (継続の難しさ) その課題は本質か︖ (課題感の偏り) ふりだしに戻る (報われない集計・分析) 進むも地獄、退くも地獄 (曖昧な出⼝戦略)

19. 18 Copyright © Moe Uchiike All Rights Reserved. 第３章︓社会実装を阻む 「罠」

    と、その解決策

20. 19 第３章︓社会実装を阻む 「罠」 と、その解決策 【業務理解・課題抽出】 その課題は本質か︖ Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 効果の⾒込める施策が明らかであり、かつ組織内の⼤半が同じ⽅向を向いている 罠 解決策 • 特定のレイヤーの関係者へのヒアリング結果を鵜 呑みにして課題をリストアップしてしまう • 本質的 (あるいは潜在的) な課題を認識できず、 表⾯的な課題への対症療法的なアプローチに終 始してしまう • コスト削減などの守備的な課題へのアプローチが 優先されてしまう ü 複数のレイヤー・役割の関係者へのヒアリング結果 を集め、フラットに評価する ü ヒアリング結果を踏まえて深く考察し、本質的な課 題にたどり着くための取組みを⾏う ü 検討範囲を 「攻めの投資」 の領域まで拡張し、 効果の⾒込める施策を幅広く検討する この段階で何を課題とするか︖がプロジェクトのその後を左右します。 企業であれば、掲げているビジョンや果たすべき社会的使命との整合性も⾮常に重要です。

21. 20 第３章︓社会実装を阻む 「罠」 と、その解決策 【データ収集】 現実のデータは汚い︕ Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 構造化されたデータがクラウド上の列指向DBに格納されており、容易に収集可能 罠 解決策 • 「利⽤できるデータがたくさんある」 と聞いていたが、 そのデータは実は印刷物であった • データはあるが、同じデータなのにデータ取得断⾯ によって数字が違う • データはあるが、データ保有部⾨との関係が悪く、 データを渡してもらえない • データはあるが、常に上書き処理されており、蓄積 されていない ü 現状のデータの品質について、関係者⼀同で事前 に認識を合わせる ü 知恵を絞ってデータクレンジングを⾏い、なんとか利 ⽤できる形にする ü 役職者からトップダウンで業務命令が下るように関 係者との調整に奔⾛する ü データを定期的に蓄積するスキームを作り、すぐに データの蓄積を開始する 多くのデータは、そもそも⾼度なデータ活⽤を想定した作りになっていません。 データ整備を推進していく気概 (あるいは戦略的に専⾨の⼈材を配置するような⽴ち回り) が求められます。

22. 21 第３章︓社会実装を阻む 「罠」 と、その解決策 【基礎集計・基礎分析】 ふりだしに戻る Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 データ分析基盤とデータ定義書が整備されており、偏りのない正確なデータが容易に利⽤可能 罠 解決策 • ⼀部のデータのみを受領しており、⺟集団に偏り がある • ある程度分析を進めた後に、オペレーションミスと思 しき異常値の存在が確認された • 同⼀IDの商品が複数存在するように⾒えるが、 データ定義書がなく理由がわからない • データの性質上、合理的に補完 (補間) すること が不可能な⽋損値の存在が確認された ü 偏りのないデータを⺟集団として集計・分析できる ように事前に⼿を打っておく ü 「初⼿・データを⾒る」 を重要視する (データ収集 の段階で実施しておくのが望ましい) ü テーブル間 (あるいはファイル間) の関係性につい て推測しつつ、関係者に事実関係を確認する ü ⽋損値の取扱い⽅針について関係者と協議し決 定するとともに、影響について整理し、関係者間で 共通認識にしておく 前提が誤っていれば、いかなる集計・分析結果も台無しです。 正しい解釈と作業の効率化のため、事前の準備に万全を期しましょう。

23. 22 第３章︓社会実装を阻む 「罠」 と、その解決策 【問題設定】 問題設定は難しい Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 解くべき問いと解ける問いが⼀致しており、特段疑問を抱かずに機械学習の問題に落とし込める 罠 解決策 • 賞味期限の⻑い 「かんぴょう」 の需要量を完璧に 予測できるモデルが完成したが、ビジネス的に意味 があるとは到底思えない • 実はMAE等の指標よりも 「⼤外し」 をなくすこと が重要であることを後から指摘された • 問題⾃体は解けるが、解けば解くほど⾚字が拡 ⼤する⾒込みである • 99%の精度を達成したが、そもそも厳密に解ける 必要があり、実⽤化が⾒込めない ü 本当に解くべき問いは何か︖について、必要なス テークホルダーを巻き込んで議論する ü 機械学習の問題としての解きやすさと、ビジネス的 な効果のバランスのとれた問題を設定する ü 現実的なコスト感で対応できる⾒通しが⽴つかを 考える (スケーラビリティ等も重要な要素) ü 機械学習にこだわらず、解くべき問いに適した⼿法 を選択する (ルールベース/数理最適化) 「解くべき問い」 と 「解ける問い」 は往々にして⼀致しません。 時には機械学習以外の⽅法を検討する必要があります。 (数理最適化等も課題解決のための強⼒な⼿段です)

24. 23 第３章︓社会実装を阻む 「罠」 と、その解決策 【PoC】 進むも地獄、退くも地獄 Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 特に躓くことなく予定通りにPoCが進捗し、実⽤化できることが誰の⽬にも明らか 罠 解決策 • 結果の良し悪しを判断できず、出⼝が⾒えないま まずるずるとPoCを継続してしまう • なかなか成果が出ず、いわゆる 「PoC死」 に⾄っ てしまう • モデル⾃体の改善にのみ全⼒を注いでしまう • リッチな検証の仕組みを整えてPoCに挑んだが、 PoC終盤で⼤きな仕様変更を余儀なくされる課 題が⾒つかってしまい、対応できなくなった ü 事前にPoCのゴールを定量・定性の両⾯で定義し、 期間を区切って評価する (⽐較対象を決めて相 対評価するのも⼿) ü できないことがわかるのも⼀つの成果と捉え、解く問 題やアプローチを再考する ü モデルそのものだけでなく、モデル周辺のあらゆる部 分を⼯夫する (劇的に改善することがある) ü PoC期間中に新たな課題が⾒つかることを⾒越し、 ⼩回りの利く仕組みで複数回の検証を回す (Quick & Dirty) ゴールを明確に定めてPoCに取り組み、結果が出なければ戦略的撤退を図るのも勇気です。

25. 24 第３章︓社会実装を阻む 「罠」 と、その解決策 【PoC】 モデルの性能、どう測る︖ Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 どこからどう⾒てもモデルの性能、およびビジネス上の効果に疑いの余地がない 罠 解決策 • 機械学習に過度の期待をされており、意思決定 者の期待を意図せず裏切ってしまう • 意思決定者が性能指標を理解できない、あるい はモデルの性能がビジネス上の利益に結びつく実 感が湧かず投資判断ができない • 予測値をどれくらい信⽤できるかがわからない • モデルの解釈性が低く、そのモデルを信頼する根 拠として不⾜がある ü 「良いモデル」 を緻密に定義し、事前に役職者を 含めて合意を取っておく ü 誰にでもわかりやすく、かつ本質を損なわない指標 を定義した上でバックテストする ü 予測の不確かさを扱える⼿法を選択する ü 無理に深層学習に寄せず、回帰⽊などのモデルも 候補に⼊れた上で、性能と解釈性のバランスをとる ü モデルの 「逆解析」 を試みる 基本的に、「交差検証しました。はいOK︕」 とはならないと考えておくべきです。 納得感のある性能評価と解釈性の確保は、まさに 「社会実装」 できるかどうかを左右する重要事項です。

26. 25 Copyright © Moe Uchiike All Rights Reserved. 考えてみよう︓モデルの品質、どこまで保証できる︖

27. 26 考えてみよう︓モデルの品質、どこまで保証できる︖ 以下の状況を踏まえ、考えたことをアウトプットしてみてください。 状況 • 皆さんは法⼈向けに受託分析サービスを提供する企業に勤務しており、機械学習による与信審査プロジェクトのPMを務めています。 • プロジェクトのミッションは、あらゆるデータを活⽤し、より良い与信審査システムを構築することです。 • クライントの⾦融機関における、過去の顧客のID、年齢、性別、居住地、雇⽤形態、勤続年数、家族構成、貸し倒れの有無などに加え、

    有償の市況データなども収集し、これらのデータを利⽤して貸し倒れリスク予測モデルを構築しました。 • 幸いなことに、PoC時に構築したモデルの予測性能がそれなりの⽔準に達しているように⾒えたため、ステアリングコミッティで検証結果を報告 したところ、システムリリースを⽬指してプロジェクトを前進させるように依頼されました。 • プロジェクトはクライアント企業の社⻑直轄で、「最終的に精度90%を達成すること」 「品質が保証されること」 「SLA* の提⽰」 を強く求め られています。 皆さんなら、どのように判断し、どのように⾏動しますか︖ ３分間で考えてみてください Copyright © Moe Uchiike All Rights Reserved. *: Service Level Agreementの略。提供するサービスの品質保証レベルに関する合意事項。

28. 27 考えてみよう︓モデルの品質、どこまで保証できる︖ いかがでしたでしょうか。この問題に明確な答えがあるわけではありません。 ですが、ありとあらゆることを考えなければならず、思考停⽌させてもらえないことがわかります。皆さんはどこまで想像できたでしょうか︖ 思いつくこと (例) • 精度90%の根拠はあるのか︖達成すると何が嬉しいのか︖ • 精度とは何を指しているのか︖*

    • データさえ増やしていけば改善され続けると誤解されていないか︖ • 機械学習モデルの精度を保証するのは現実的なのか︖ • 検証時の前提条件は本番環境で満たせるのか︖ • 有償の市況データを調達し続けられる保証はあるか︖ • モデルの検証結果に嘘はないか︖ (想定外のリーク) 我々が⽴ち向かわなければならないのは、まさにこのような問題の数々︕ Copyright © Moe Uchiike All Rights Reserved. • この先市況が⼤きく悪化した場合、モデルの予測性能に再現性 はあるのか︖ • 予測性能そのもの以外にも、可⽤性や処理速度、モデルの解 釈性や公平性などが保証対象となり得るのではないか︖ • 動作保証ならできる可能性があるが、そのためには前提条件や 免責事項を明⽰する必要があるのではないか︖ • 性別を特徴量とする与信審査システムは公平性を⽋いており、 社会的要請を満たしていないのではないか︖ *: ⼆値分類の正解率、適合率、属性別の貸し倒れ率の誤差、これらに貸し倒れ時の損害規模で重みづけする必要の有無、あるいは属性別の貸し倒れリスクをある程度の幅で予測できればいいのか 等が考えられる。

29. 28 第３章︓社会実装を阻む 「罠」 と、その解決策 【要件定義】 様々な制約 Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 ベストプラクティスに基づき、⼀般的に良しとされる要件を過不⾜なく定義していける 罠 解決策 • 既存のデータ基盤との兼ね合いやセキュリティ上の 制約により、クラウドコンピューティングへのスムー ズな移⾏が難しい • 既存の仕組みを変えたくない部署の発⾔権が社 内で強い • 要件がオーバースペックで⾚字を⾒込んでしまう • 個別要件の対応に追われ、横展開が難しくなっ た ü 既存の基盤をある程度活かした仕組みを構築し、 段階的に移⾏していくプランを⽴てる ü 役職者を巻き込み、定期的にディスカッションの場 を設けて意思決定を促す ü 最終的に達成したいことから逆算し、要件を取捨 選択。⾒送った要件は後続フェーズで検討する ü 横展開を⾒越して、汎⽤的な要件と個別要件を 分けて管理・開発する 本番稼働を⽬指すとなると、個別の事情と汎⽤性のバランスを意識して要件を定義していく必要があります。 「理論の理解」 や 「実装⼒」 では太⼑打ちできない領域もあります。得意な⼈に任せてしまうのも⼿です。

30. 29 第３章︓社会実装を阻む 「罠」 と、その解決策 【設計・開発・テスト】 その開発、誰がやる︖ Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 データサイエンスとエンジニアリングの両⽅に⻑けた⼈材が、プロジェクトを⼀貫して主導する 罠 解決策 • PoCが終わり、いよいよ開発フェーズとなったものの、 いざ本番環境で開発するとなるとどのように開発し ていけばいいかわからない • データサイエンスに⻑けたメンバーと本番環境での 開発に⻑けたメンバーがそれぞれいるが、コミュニ ケーションに難があり両⾞輪が動かない • PoCで書いたコードを本番環境に移植したいが、 中途半端に抽象化されており取扱いに困る ü データサイエンスの担当者の他に、機械学習まわり のエンジニアリングの担当者 (機械学習エンジニア 等) をアサインする (可能であれば初期段階からア サインしておき、スムーズに本番環境の開発に⼊れ るように準備しておく) ü チーム内で最低⼀⼈が 「翻訳者」 となり、メンバー 間のコミュニケーション促進の役割を担う ü PoCの段階からシステムリリースを⾒越してクラス設 計等を丁寧にしておくか、あるいは敢えてJupyter Notebookで書き下す以上のことをしない オールマイティーな⼈材のアサインが理想ですが、そう上⼿くはいきません。 分業を前提として翻訳者を配置するなど、現実的な解を出すことが求められます。

31. 30 第３章︓社会実装を阻む 「罠」 と、その解決策 【UAT】 信頼を得るのは難しい Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 モデルの性能が良く、現場からの評判も上々。スムーズに次のフェーズに移⾏できる 罠 解決策 • 性能の良いモデルを提供しても現場担当者には 旨味がなく、既存のオペレーションを変えたくない層 からネガティブな意⾒が出る • 予測が外れたごく⼀部について現場担当者に固 執されてしまい、モデルを信頼してもらえない • やらされている感や、利⽤者のプライドを傷つける ことに繋がってしまう • 確かにモデルの性能は良いが、実際に現場のオペ レーションに組み込んでみたところ、使いにくい部分 があることがわかった ü 予測が当たった場合のメリットについて、経営⽬線 だけでなく、現場⽬線で整理する ü 予測が外れた原因を可能な範囲で分析し、説明 して納得してもらう ü 「選択の⾃由」 を残し、最終的な意思決定を利 ⽤者に委ねるサービス仕様を検討する ü UI/UXの設計・開発⼯数を確保し、システム利⽤ 時のハードルを下げる ü ユーザーからの意⾒を漏れなく吸い上げ、改善すべ き点については改善を試みる 利⽤者に 「使う側のメリット」 を提⽰し、Win-Winの関係でプロジェクトを進めていくのが正解です。 いかに⾼度なモデルも、結局のところ使ってもらえなければ宝の持ち腐れです。

32. 31 第３章︓社会実装を阻む 「罠」 と、その解決策 【パイロット稼働】 思わぬところに考慮漏れ Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 PoCと同様の性能が出ており、⽬⽴ったバグもなく順調に稼働している 罠 解決策 • PoC時と同等の性能が⽰せず、本番稼働に踏み 切れない • マスターの内容が変化しており、存在しないはずの カテゴリカル変数が特徴量として投⼊されてしまう • 定められた時刻までに必要なデータがIFされてこず、 必要な特徴量がNULLのまま予測処理が⾏わ れてしまう • 連携されたデータの不備が原因で不具合が⽣じ たにもかかわらず、モデルの責任にされてしまう ü PoC時と同じ品質のデータが使えるとは限らないこ とを認識し、可能な限り⼿を打っておく ü 本番に近い形でバックテストを実施し、ある程度の 性能が出ることを担保しておく ü 機械学習モデルによる予測値を過信せず、セーフ ティーネットとして異常値を回避するための仕組み を複数⽤意しておく ü 各関係者が責任を持つべき領域 (責任分界点) をあらかじめ明確にしておく たった⼀度の失敗で、機械学習モデルのような 「わかりにくいもの」 に対する信頼は崩れ去ります。 そうならないために、「事故が起きない仕組みづくり」 を徹底しましょう。

33. 32 第３章︓社会実装を阻む 「罠」 と、その解決策 【本番稼働】 学習データにない未来 Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 ローンチ後、システムは順調に稼働。社会情勢に⼤きな混乱はなく、モデルは質の⾼い予測をし続けている 罠 解決策 • 学習データの期間に存在しないイベントが⾏われ ることとなった • 観測史上最⼤の台⾵が⽇本列島に上陸し、猛 威を振るう⾒込みである • 突然のパンデミック。モデルはパンデミック時の需要 量の傾向を学習しておらず、妥当な⽔準の予測が できる保証がない ü 解釈性の⾼いモデルやルールベースのアルゴリズム との2段構えの仕組みを予め構築し、必要に応じ てスイッチできるようにしておく ü 緊急時に運⽤回避できるよう、緊急時⽤のオペ レーションを組み、⽇頃から周知しておく ü 現場の状況を丁寧にヒアリングしつつ、モデルの利 ⽤可否や再開タイミングについて⼀つひとつ判断す る 今まさに起きている状況で、様々な機械学習プロジェクトが苦戦を強いられていることは想像に難くありません。

34. 33 第３章︓社会実装を阻む 「罠」 と、その解決策 【効果測定】 ビジネスインパクト、どう測る︖ Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 ローンチ後、モデルは期待を上回る性能を⽰し続けており、具体的なアクションにより利益に繋がっている 罠 解決策 • モデルの性能は⾼い値を⽰しているが、それが具 体的にどのようにビジネスに貢献できているかがわ からない • モデルの性能とビジネスへの貢献度に相関はある が、因果がわからず効果を測れない • モデルによる予測結果が具体的なアクションに繋 がっていない ü モデルの性能が必ずしもビジネス上の効果に結び つかないことを認識し、ビジネス上のインパクトを定 量的に可視化する指標を新たに作成する ü A/Bテストや統計的因果推論により、モデルの性 能とビジネスへの貢献度の因果関係を明らかにす る ü モデルによる予測結果を意思決定などのアクション に確実に繋げる 「出⼝」 を⽤意する (数理最適 化なども選択肢の⼀つ) ビジネス上の効果が⽰せなければ、次の投資判断にダイレクトに響いてきます。 そうならないために⼿を打つことが、機械学習の 「社会実装」 の拡⼤に繋がります。

35. 34 第３章︓社会実装を阻む 「罠」 と、その解決策 【保守・運⽤】 順⾵満帆とは限らない Copyright © Moe Uchiike

    All Rights Reserved. 業務理解 課題抽出 1 データ収集 2 基礎集計 基礎分析 3 問題設定 4 PoC 5 予算確保 6 要件定義 7 設計・開発 ・テスト 8 UAT 9 パイロット稼働 10 本番稼働 11 効果測定 12 保守・運⽤ 13 理想 ローンチ後、特に問題なくモデルを運⽤できており、システム改修の必要性も特段ない 罠 解決策 • データ取得元のテーブル定義に認識していない変 更があり、予測前処理時にエラーを吐いてしまう • 特徴量として使っていたデータが諸般の事情で使 えなくなる (データ提供元の⽅針変更、組織の意 向 等) • 機械学習の運⽤に強いチームが存在せず、⻑期 的な運⽤に適したチーム・⼈材が確保できない ü 変更情報をキャッチできないことがないよう、ステー クホルダーとの情報共有のスキームを作っておく ü 複数のリスクの⾼いデータの使⽤を避ける ü 複雑かつ解釈性の低いモデルの利⽤を避け、運 ⽤の難易度を下げる ü 運⽤タスクのテンプレ化・抽象化を進め、⾼度な専 ⾨性を必要としない領域を拡⼤する ü マネージドサービスや、統合機械学習プラットフォー ム (Google Cloud Vertex AI 等) を活⽤する 機械学習プロジェクトでも、“負の遺産” を残さないようにシステム・運⽤を設計することが必要不可⽋です。 また、急速に整備されつつある機械学習プラットフォームの動向に注⽬しておくことも重要です。

36. 35 Copyright © Moe Uchiike All Rights Reserved. まとめ︓本⽇お伝えしたかったこと

37. 36 まとめ 本⽇お伝えしたかったこと Copyright © Moe Uchiike All Rights Reserved.

    ü 機械学習プロジェクトが社会実装のフェーズを迎える機運が⾼まっている 1 ü 依然として 「社会実装を阻む罠」 は多数潜んでおり、ノーガードでは⽴ち向かえない 2 ü 歴史に学び、未踏の領域に 「視野を広げて」 「視界の解像度を上げて」 「時には泥臭く」 取り組む 3

38. 37 Copyright © Moe Uchiike All Rights Reserved. 関連情報 太⽥満久.

    ブレインパッドにおける機械学習プロジェクトの進め⽅. slideshare. 2019. https://www.slideshare.net/BrainPad/ss-149214163 内池もえ. 機械学習を 「社会実装」 するということ. SpeakerDeck. 2020. https://speakerdeck.com/moepy_stats/social-implementation-of- machine-learning 国⽴研究開発法⼈産業技術総合研究所. 機械学習品質マネジメントガイドライン 第2版. 2021. https://www.digiarc.aist.go.jp/publication/aiqm/guideline-rev2.html ⼤城信晃・マスクド・アナライズ・伊藤徹郎・⼩⻄哲平・⻄原成輝・油井志郎. AI・ データ分析プロジェクトのすべて. 技術評論社. 2020. https://gihyo.jp/book/2021/978-4-297-11758-0 BrainPad Inc. SlideShare 機械学習プロジェクトのあれこれについて発信しています https://www.slideshare.net/BrainPad OpenBrainPad Project 株式会社ブレインパッド社内にある技術資料の公開等を⾏っています https://brainpad.github.io/OpenBrainPad/ 澁井雄介. AIエンジニアのための機械学習システムデザインパターン. 翔泳社. 2021. https://www.shoeisha.co.jp/book/detail/9784798169453 今泉允聡. 深層学習の原理に迫る―数学の挑戦. 岩波書店. 2021. https://www.iwanami.co.jp/book/b570597.html

39. 38 Copyright © Moe Uchiike All Rights Reserved. Appendix︓GCI 2020

    Summerで実施した 「考えてみよう」

40. 39 考えてみよう︓モデルの性能、どう測る︖ 以下の状況を踏まえ、⾃分なりの答えを出してみてください。 状況 • 皆さんは、世界中に店舗を展開している和⾷チェーンにおいて、機械学習による需要予測プロジェクトのPMを務めています。 • 今まさに、解くべき問題を 「来⽉必要な⾷材の需要量」 と設定し、PoCを回そうとしています。

    • ⾷材は⽶、野菜、⾁、かんぴょうなど様々です。 • A国では 「かんぴょう巻」 が絶⼤な⼈気を誇っていますが、B国ではあまり⼈気がありません。 皆さんなら、どのような指標・考え⽅でモデルを評価しますか︖ ３分間で考えてみてください Copyright © Moe Uchiike All Rights Reserved.

41. 40 考えてみよう︓モデルの性能、どう測る︖ いかがでしたでしょうか。この問題に明確な答えがあるわけではありません。 ですが、ありとあらゆることを考えなければならないことがわかります。 この事実に気づくことが機械学習の 「社会実装」 に直結します。 恐らく皆さんが考えたこと • 予測値と実績値の誤差を最⼩化すればよいのだから、素直に

    MAEで評価すればいいのではないか︖ • いいや、「⼤外れ」 は賞味期限の問題で修正がきかないのだから RMSEで評価するべきなのではないか︖ • 「当てるべきもの」 と 「当てなくていいもの」 が存在するのではない か︖ (例えば 「かんぴょう」 の需要量を当てても意味がない) 我々が⽴ち向かわなければならないのは、まさにこのような問題の数々︕ Copyright © Moe Uchiike All Rights Reserved. • 「過剰予測」 と 「過⼩予測」 にどのように重みづけをするか︖ (過剰在庫と販売機会損失の重みを天秤にかける) • 国別、あるいは地域別に必要とするモデルの振る舞いは異なるの ではないか︖ • 最終的に 「良いモデル」 であることをどう定義し、どう証明する か︖ (絶対評価とするか︖何かと⽐べて相対評価とするか︖そ れぞれの場合の効果試算をどのように⾏うか︖) 私ならこういうことも考える

42. 41 考えてみよう︓オリンピックイヤーの需要予測、どうする︖ 以下の状況を踏まえ、⾃分なりの答えを出してみてください。 状況 • 皆さんは、世界中に店舗を展開している和⾷チェーンにおいて、機械学習による需要予測プロジェクトのPMを務めています。 • 様々な困難を乗り越え、ようやくシステムローンチすることができました。 • ひとまず問題なく動いており、現場からの評判も上々です。

    • しかし、100店舗を展開しているヨーロッパのA国で、来年オリンピックが開催されることに気づきました。 • 学習データは3年分しかなく、オリンピック期間の需要量については⾒当がつきません。 (ここではオリンピックに準ずる規模のイベントもなかったと仮定します) Copyright © Moe Uchiike All Rights Reserved. 皆さんならPMとして、この問題にどう⽴ち向かいますか︖ ３分間で考えてみてください

43. 42 考えてみよう︓オリンピックイヤーの需要予測、どうする︖ 恐らく皆さんが考えたこと • オリンピック開催国は、インバウンド需要の増加により売上が⼤幅 増になるはず • 過去のオリンピック、あるいはそれに準ずるイベント時のデータで学 習しているモデルを構築するのがベター •

    ⼀⽅、オリンピック、あるいはそれに準ずるイベント時のデータを持っ ていないため、事実上それは不可能 我々が⽴ち向かわなければならないのは、まさにこのような問題の数々︕ Copyright © Moe Uchiike All Rights Reserved. • 通常通りにモデルが予測をすると、売上の⼤幅増を過⼩評価してし まう可能性がある。どうするべきか︖ • 需要の⼤幅増が⾒込まれる場合、何らかの特徴量として投⼊できる モデルに改良するべきではないか︖ • そこまでしなくても対応できる⼿段は何かないか︖ いかがでしたでしょうか。この問題に明確な答えがあるわけではありません。 ですが、ありとあらゆることを考えなければならないことがわかります。 この事実に気づくことが機械学習の 「社会実装」 に直結します。