論文読み会 / Socio-Technical Anti-Patterns in Building ML-Enabled Software: Insights from Leaders on the Forefront

社内論文読み会、PaperFridayでの発表資料です

Transcript

1. Socio-Technical Anti-Patterns in Building ML-Enabled Software: Insights from Leaders on the Forefront 24/11/29 PaperFriday, Yuki Iwazaki@AI Lab
2. 2 Point: 機械学習プロジェクトの社会実装におけるアンチパターンの紹介 ICSE 2023: acceptance rate 22.3% Authors: Alina Mailach, Norbert Siegmund Reason for selection: Labで社会実装機運が年々高まっているため
3. Introduction 3
4. MLプロジェクトは難しい : 技術的な負債 ML特有の技術的負債 • モデルの説明可能性の低さ • 実験設定 • フィードバックループ • リアルデータの変化 • システム実装・テストの難しさ 4 Hidden Technical Debt in Machine Learning Systems [Sculley, 15] (和訳)
5. Bad practices in ML: 技術的な負債 5 この論文ではこのような技術的な負債ではなく文化的な負債について議論 https://refactoring.guru/refactoring/what-is-refactoring https://hoxominc.hatenablog.com/entry/2020/07/06/100000
6. MLプロジェクトは難しい : 文化的な負債 6 • MLプロジェクトは技術以外の理由で失敗することが多い • ビジネス背景やマネジメント力など企業文化が重要 • ResearchとEngineeringには大きなギャップがある • 締め切り vs コードの品質 • 日頃から品質を高める技術を身に着け時間に余裕を持つ
7. Methodology 7
8. MLOps Community https://mlops.community/ 8 世界的なML技術者コミュニティ Podcast, YouTubeも毎週更新 ここで公開された73/210 videosから MLプロジェクトの文化的な課題を分析
9. Reflexive Thematic Analysis (RTA) 構造化されていない雑多なデータに 含まれるテーマを体系的に抽出、 俯瞰する質的データ分析手法の 1つ 右の6つのプロセスで構成される 1. Familiarization with the Data 2. Generating Initial Codes 3. Searching for Themes 4. Reviewing Themes 5. Defining and Naming Themes 6. Writing the Report 9 https://delvetool.com/blog/reflexive-thematic-analysis
10. Induction phase 1. 210 videos (YouTube Transcripted) 2. 210 videos -> 82 videos (Full Talks playlist) 3. 82 videos -> 37 videos (字幕に“Team”を含む) 4. 37 videosに含まれるテーマを分担して 書き起こす (Open coding) 5. 問題・原因・解決策の 3軸でテーマを まとめていく 6. 分担した結果をまとめる 10
11. Deduction and refinement phase 11 1. Induction phaseで省いた128 videos (210 - 82) から、 induction phaseで抽出したテーマに関連する動画を 字幕から抽出 2. 128 videos -> 36 videos(字幕に1で抽出したテーマ含む ) 3. Induction phaseで集めた37 videosと 2で集めた36 videosから17 anti-patternsとして整理
12. Demographics 73 videos, 66 hours, 628 views (avg.) Date: 2020/04-2022/05 Speaker: US and EU team leaders 12
13. Extract ML Anti-Patterns from Meetup Videos 動画で議論される頻度から 各テーマの重要性を重み付けし アンチパターンにまとめた 13
14. MLプロジェクトにおける 3つの文化的負債 1. Organizational silos 組織の縦割り化 2. Communication within an organization コミュニケーション不足 3. Organizational leadership vacuum リーダー不足 14
15. Organizational Silos 15 組織の縦割り化
16. Model to production integration AP1: Long release cycles ➔ リリースサイクルが長い。 DSとDev間で責任が行ったり来たりしてプロダクト導入に 時間がかかってしまう。モデル全体を Dev側で再実装しないとならない。 AP2: Tension between teams ➔ チーム間の緊張。DSとDev間でお互いのアウトプットを理解できていない。 AP3: Blocked data scientists ➔ DS業務のブロック。DSが開発タスクに悩殺されてモデルの最適化ができない状態。 16 ※AP: Anti-Patterns
17. Model to production integration C1: Clash of cultures and tools ➔ DSとDev文化の衝突。DSが作ったモデルはテストやコード規約に従わない。 使うツール・プログラミング言語・フレームワークの壁がある。 C2: Missing engineering competence ➔ 開発力の欠如。DS側はSoftware Engineeringの知識が足りない（e.g. コードの品質 ・デザインパターン・パイプライン化・仮想化・スケーラブルなインフラ） 一方、Dev側はモデルをブラックボックス化してしまう 17 ※C: Causes
18. Model to production integration R1: Model registry and feature store ➔ モデルレジストリ（e.g. HuggingFace）やフィーチャーストア（ e.g. Vertex AI Feature Store）に よってガイドラインに頼らずモデルの連携方法を標準化する R2: Restructure teams to be cross-functional ➔ 専門チームで分業化せず横断で開発チームを組む R3: Pair data science and software engineers ➔ DevがDSとペアを組みコードレビューを行う R4: Translation work between the different roles and common understanding of the goal ➔ お互いに専門用語を説明するようなドキュメントを用意し DevとDSの共通言語化を進めるべき 18 ※R: Recommentations
19. Data producer to consumer integration AP4: Requesting data is hard ➔ データへのアクセスが制限されていたり提供を渋られる。データ連携にリソースが取られる上 に、提供側にメリットが少ないと優先順位を下げられてしまう。 AP5: Tight technical coupling between consumer and producer team ➔ データ連携が複雑。難解な SQLを渡されたり、暗黙的にデータが変更されたりする。 AP6: Partial data availability ➔ 学習データと本番データでギャップが生まれ、モデルの性能が再現できなくなる。 19
20. Data producer to consumer integration C3: Lack of awareness and common goals ➔ データの提供側と利用側のモチベーション不一致。提供側がそのデータがどう利用されている か関心がない。 C4: Missing documentation and unclear responsibilities ➔ データの作成・保守責任者が不明確。ドキュメントの欠如によってデータは利用されず、誤動作 するリスクも上がる。 20
21. Data producer to consumer integration R5: Raise awareness of data producers ➔ データ提供者の社内外の広いスコープでの責務の具体化。利用者からデータの有用性や、 データが変更されることによる影響をフィードバックできる仕組みが重要。 R6: Central platform as a contract between producer and consumer ➔ データの共通基盤化。適切なメンテコストを持ってデータのドキュメント化や品質を担保する組 織体にすることが重要。 21
22. Communication 22 コミュニケーション不足
23. Redundant development AP7: Features are not discoverable, accessible, or reusable ➔ モデルや特徴量の再利用性を考えずに、 連携するよりは異なるチームが似たようなものを作ってしまう AP8: Redundant ML infrastructure and tools ➔ ビジネスKPIではなく新技術の導入が目的になっている。 ツールのためのモデルではなく、モデルのためのツールを作ってしまう。 AP9: Shadow IT ➔ 各チーム独自でこっそりデータやサービスのホスティングまでやってしまう。 結果、組織的なブランディング・セキュリティリスクが上がる。 23
24. Redundant development C5: Missing intersections between teams, documentation and trust ➔ データやモデル・コードの仕様の共有が少ない。 締切ファーストでその後のことを考えていない。 ドキュメント作成や利用者に使ってもらう（≒引用してもらう）ための 労力を後回しにしてしまう。 24
25. Redundant development R7: Unification and discovery through centralization ➔ 提供する際のツールを共通化する。 Feature Storeの利用やモデルコードのテンプレ化、インフラの一元管理など。 R8: Showcase meetings ➔ 定期的に共有会を行う。進捗報告や新技術・ Tipsなどを紹介し合える場が重要。 25
26. Management vs. Data Science AP10: Data scientists struggle in their roles and get burned out ➔ 一般的な開発と比べ DSは結果が出づらく疲弊してしまう。 AP11: Tension between management and data science ➔ データやモデルといった DSの成果物が直接ROIにどう影響を与えているか （投資が回収できたか）が見えにくい。 多くのDS (Researcher) はROIという文字を嫌う。 26
27. Management vs. Data Science C6: Missing data science process ➔ Softwareと比べDS業務は不確定要素が多すぎる。そんな ML Projectの理 解が弱い経営層とDS側のやっていることの共有の難しさの両方が原因 C7: Communication mismatch between technical and non-technical people ➔ DS/Researchの成果を専門でないメンバーへわかりやすく説明できない 27
28. Management vs. Data Science R9: Strong processes ➔ 今何をやっていてどういう成果が得られるかを理解できる形で経営層に翻訳、 説明できるようにしておく。 DS業務にマッチしたアジャイル開発などができれば有効だが未だ研究不足の分野。 R10: Documentation and reporting ➔ うまくいってもいかなくてもとにかくドキュメント化する。 誰向けに作るドキュメントなのか読者を意識して書く。 28
29. Leadership Vacuum 29 リーダー不足
30. Headless-Chicken-Hiring AP12: Staff with insufficient skills ➔ MLや統計のプロとして採用されたのにアプリ実装や保守に悩殺されてしまっ ている。逆にモデリングは得意だが ML Systemの運用経験がない。 AP13: No product for data scientists ➔ 適切なDSタスクが存在しない。古典的な手法や No MLで解決できるとわ かった場合、DSとしての仕事をしていない人とみなされてしまう。 30
31. Headless-Chicken-Hiring C8: Unclear roles and titles ➔ Web業界柄、役割が明確でない業務が多い。次々と新しい肩書きが生まれる ML Scientist, ML Engineer, Site Reliability Engineer, MLOps Engineer… C9: Uneducated hiring ➔ 新しい分野なため優秀なリーダーの採用が難しい C10: Skill shortage on the market ➔ 優秀な人材の需要が高い一方、スキルのミスマッチ人材を採用してしまう 31
32. Headless-Chicken-Hiring R11: Hire for the skills and potential rather than roles ➔ 役割ではなくスキルとポテンシャルで採用する。 採用要項で必要なスキルを明確化し、 DS FirstよりもEngineerに重きをおいた人材のほうが将来性がある。 プロダクトの発展が読めない場合は、 DSは契約社員やコンサルで雇ったほうがいい。 32
33. Resume-driven-development AP14: Developed tools and models do not match the team or product goals ➔ 使われている言語やツールが、プロダクトで解決したいことや 将来的な保守のしやすさに関わらず、立ち上げ期のメンバーの好みに強く影響される。 コアメンバーが退職した場合、保守の難しい負債になる。 33
34. Resume-driven-development C11: Data scientists do not identify with the business value ➔ ビジネス価値ではなく技術にのみ興味がある技術者が多い C12: Missing decision maker ➔ 将来性を加味した今のタスクに最適な技術スタックを決める意思決定者がいない 34
35. Resume-driven-development R12: Rely on organizational knowledge ➔ 他チームの詳しい人に頼る。セカンドオピニオン的な効果もある。 35
36. Hype-driven product creation AP15: Stuck with proof of concepts ➔ PoCのほとんどはプロダクトに導入されない（ "PoC-Hell"）。 性能指標にこだわり続けて社会実装にたどり着かない。 AP16: Perception of ‘Everything can benefit from ML!’ ➔ とにかくAIを使いたい、なんとかしてくれるという考え。 プロダクトのマネタイズ戦略を度外視して目的を履き違えてしまう。 AP17: Product is not feasible due to missing data or talent ➔ やりたいことはたくさんあるが、それができるデータや人材がいない。 プロダクトが動き出してからデータ集めから始めることも多い。 36
37. Hype-driven product creation C13: Missing organizational strategy, governance, and structure ➔ データが一番重要なのが Software開発前にわかっているのに 検証不十分なまま開発が進み出してしまう。 C14: Management lacks knowledge about ML ➔ 経営層のML知識不足。会社の競争力を維持するためにコストやリスク度外視で AIを組み込まないとというプレッシャーに駆られてしまっている。 C15: Missing translation between different stakeholders ➔ マネジメントと技術両方を持つ人材採用・育成の難しさによって、 多くのProjectでその２つのドメインギャップが更に大きくなってしまっている。 C16: Missing production metrics ➔ KPIに近いモデル評価ができておらず、 PoCの事業的な影響が読めない。 37
38. Hype-driven product creation R13: Process to identify feasible use cases and product roadmap ➔ 複雑なML手法ほど負債が凄まじいのでシンプルな手法から始め、 MLを使わなくていいなら使 わない。Sales, DS, Dev各専門からの理解を得たロードマップを引く。 R14: Understand customers and keep them close ➔ 利害関係者（研究社会実装でいうプロダクトメンバー、プロダクトでいうユーザや顧客）と密に連 携する R15: Education ➔ 経営層や技術者含めお互いに Workshopや研修を通じた教育を進める。 38
39. Conclusion 39
40. Conclusion MLOpsコミュニティから得られたML Projectにおける アンチパターンとその対処方法をまとめた この論文はDS/Researcher/Engineerだけでなく ProductのManager層にも役立てて欲しい 40
41. Comment 普段読む論文と異なり根性論的なところはあるものの 社会実装の難しさが言語化されていた リスキリングやこのPaperFriday、進捗共有会、Monthly Reviewなど弊社 で既に実行できている具体案もあってよい 読んでいて耳が痛いがあるあるで終わらせないように、 Labとしてはプロダクトから研究相談・社会実装の際に このアンチパターンを思い出したい 41
42. 42 Thanks! Any questions? You can find me at: ◂ @chck ◂ #times_chck ◂ iwazaki_yuki@cyberagent.co.jp
43. Appendix 44
44. Best practices in ML: 技術的な負債 45 The 25 Best Practices in one place (和訳)