Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MLOpsとエンジニアの進化

 MLOpsとエンジニアの進化

[データブリックス レイクハウス プラットフォームにおける最新動向 LT大会 登壇資料]
長谷川 亮 氏 (データブリックス)

イベント開催日:2023年7月26日

イベントの趣旨:
データブリックス社とエーピーコミュニケーションズ共同開催のLTイベントです。
6月にサンフランシスコで行われたDatabricks社主催の世界最大のデータ&分析&AIをテーマにしたカンファレンス「DATA+AI SUMMIT 2023」の内容から、関連した情報や今後のDatabricksにおける技術情報などをテーマとしています。
データ分析基盤に少しでも興味のある方、データブリックスやLLM(大規模言語モデル)、AIなどデータ分析基盤の導入を検討中のユーザー様を対象にしています。

アーカイブ動画:https://youtu.be/RDcjUBjygBI

More Decks by AP Communications Co., Ltd.

Other Decks in Technology

Transcript

  1. ©2023 Databricks Inc. — All rights reserved Databricks The data

    and AI company LT7 MLOpsとエンジニアの進化 お問合せ先 [email protected]
  2. ©2023 Databricks Inc. — All rights reserved 2 Agenda AI/MLの本番稼働の難しさ

    1 MLOpsとエンジニア組織の設立 2 2 & AP Communications
  3. ©2023 Databricks Inc. — All rights reserved AI/MLシステムの特性 AI/MLはこれまでのシステム開発と異なる SI

    通常のシステム AI/ML AI/ML Codes Codes DATA Models Systems • コードが固まれば、決まった動きをするシステムとなる • 潜在的なバグや想定外の操作などから生じる障害を監視 • 動いて当たり前、システム費用はコスト • モデルは、コードとデータの組み合わせによって挙動が異なる • モデルはドリフトが発生するため、 日頃から監視と改修が必要 • AI/MLはビジネス価値・インパクトに直結しており、 コストではなくビジネスインパクトを得るための投資
  4. ©2023 Databricks Inc. — All rights reserved ML Code Configuration

    Data Collection Data Verification Feature Extraction Machine Resource Management Analysis Tools Process Management Tools Serving Infrastructure Monitoring “Hidden Technical Debt in Machine Learning Systems,” Google NIPS 2015 Figure 1: Only a small fraction of real-world ML systems is composed of the ML code, as shown by the small red box in the middle. The required surrounding infrastructure is vast and complex. AI/MLシステムにおいて、必要な要素は多岐に渡る
  5. ©2023 Databricks Inc. — All rights reserved Lakehouse Unified Analytics

    Platform BIツール・レポーティング ストリーミング データサイエンス / 機械学習 データウェアハウス ジョブ実行 オーケストレーション Big Dataの進化を 全て取り込んだプラットフォーム
  6. ©2023 Databricks Inc. — All rights reserved プラットフォームだけでは解決できない問題 なんだかやることがたくさん!!! POCの実施と判断

    プロトタイプ構築の中で検討・検証 システムとしての非機能要件と検証内容 • 性能 ◦ データ量とモデル粒度の妥当性 ◦ バッチ実行時間 ◦ APIレイテンシー • 修正可能性 ◦ MLシステムは、モデルを定期的に改 善することが前提のシステム • 検証可能性 ◦ 問題が発生した場合などに事後的に 当時の状況を再現できる • 保守性 ◦ 監視・バックアップ ◦ 問題発生時の対処 • 可用性 ◦ 稼働時間・停止 ◦ モデルの学習や推論時のデータの異 常への対応 • セキュリティ:アクセスコントロール • データ品質 ◦ データの揺らぎ ◦ 欠損 ◦ 季節変動 • POCを実施した時のデータ(期間、粒度) ◦ 数ヶ月分か数年分かなど • POCでのモデル精度 ◦ 精度指標と判断基準 • ビジネス要求と POC時点のモデルとプラットフォー ムアーキテクチャデザインの見通し • POCの結果とプロダクションに進んだ判断基準 モニタリングの仕組み • プロトタイプ構築初期に作る必要 ◦ 実際の発注量・廃棄量の推移 ◦ モデルの推論結果 • モデル開発とモニタリングの連携 モデルとしての非機能要件と検証内容 • ビジネス要求とモデル粒度の妥当性 • 精度指標の妥当性  ◦ Ex) ME, RMSE, MAE • 汎化性能 ◦ 学習・テストデータに関わら ず安定した精度を出せるか • ロバスト性 ◦ ノイズや外れ値がデータとし きた場合でも安定した精度 が出るか • 解釈可能性 ◦ どのようにモデルが特徴量を 判断し、予測結果を出力した のかを解釈できる • (公平性) ◦ 偏見や差別に基づいてない か POCから本番化までのGAP:プロトタイプとモニタリングまでの非機能要件
  7. ©2023 Databricks Inc. — All rights reserved ビジネスインパクトを継続させる仕組みを作る 組織的な課題:AI /MLを誰が運用するのか?

    企業 (ビジネスユーザー) 運用保守 ベンダー (外部?) 開発 ベンダー (外部?) 企業 (ビジネスユーザー) In-house team • ビジネスの責任は内製化チーム • 足りないピースを外部から調達 (准委任?、派遣?) 通常システムのビジネスへの寄与 AI/MLのビジネスへの寄与 • 開発/運用/保守をワンチームで実施 • AI/MLはコアビジネスそのもの • 開発/運用/保守を内製化することで、 スキルと知見が蓄積され、 次のユースケースへの取り組みが加速 体制 • 開発/運用/保守で、役割が企業単位で分断 • システムは業務効率化のための手段 ◦ あくまでもシステムはコスト ◦ 売上やコストの増減には寄与しない • 開発ベンダーの役割 ◦ 瑕疵担保が設定され、動作を保証 • 運用保守ベンダーの役割 ◦ 予め定義された対応マニュアルにて実行 特徴
  8. ©2023 Databricks Inc. — All rights reserved 仕組み:人・プロセス・プラットフォームが連動 ビジネスユーザーとエンジニアのコラボレーションが重要 People

    Process Platform ? • アーキテクチャ ◦ プラットフォーム ◦ アーキテクチャ • 開発運用に関わる働き方 ◦ ビジネスユーザーからエンジニアまで • ユースケース • ビジネスインパクト • チームの組織構造 人・プロセス・プラットフォームと関連するもの
  9. ©2023 Databricks Inc. — All rights reserved 人:コラボレーションの重要性 プロジェクト単位で、必要な人材が集まる必要がある 9

    ビジネスサイド テクノロジーサイド ビジネス担当者 ビジネス・経営の意思決定  データアナリスト データ分析, BI データサイエンティスト 機械学習、AI MLエンジニア 機械学習、AI、MLOps プラットフォームエンジニア クラウド等のインフラ管理 データエンジニア データパイプライン開発・本番化 (データ取込、ETL開発など) 働き方 • ウォーターフォールのように、 要件定義、設計、開発、運用と フェーズを分けない、 アジャイ ル型が望ましい • 企画段階から開発運用まで、 ビジネス担当者からアナリス ト、サイエンティスト、エンジニ アが常に協業する(分散型の 方が機能しやすい?) • お互いがお互いの特性を理解 する必要がある • 失敗と改善が前提
  10. ©2023 Databricks Inc. — All rights reserved • ユースケース候補洗い出し ◦

    価値発見 ◦ 実現時期 ◦ インパクト算定 • ポテンシャル特定 • ユースケースの優先順位付け • ロードマップ策定 (初期版) • 組織的な準備 ◦ 混成チームの組成 ◦ アサイン計画 ユースケース特定後 • 評価基準を定義 ◦ ベースライン設定 • データ調査 ◦ データ整合性や抜け漏れ評価 • 仮説設定 ◦ ビジネス仮説 ◦ デジタル仮説 * • 技術検証と準備 • ROI算出 テクニカルPoCの実施 • データ抽出・統合 • 初期モデル構築 • 事業成長要素の特定 • インパクト測定 ビジネスPoCの実施 • マニュアルでのモデル実装 • ROI算出 テクニカルプロトタイプ • システム全体としてのアーキテク チャ構築・実装 ※MVPとして必要な範囲 • 施策実行とモニタリングの 仕組み構築( DevOps導入) ビジネスプロトタイプ • 業務プロセスの見直し • インパクト検証 • 業務変革ロードマップ策定 テクニカルプロダクト • システム全体開発 ※Agileに継続改善 ビジネスモデルの確立 • 業務プロセスとシステム改善 プロセスの確立 ※ビジネス側も Agileに • ガバナンス体制の確立 • 各種トレーニングの作成と展開 構想策定・企画立案 初期調査 PoC プロトタイプ構築 本番化開発と運用 プロセス:AIプロダクト開発のプロセス *QuantumBlack 5i protocolを参考に作成 https://medium.com/quantumblack/the-protocol-series-articulating-the-lifecycle-of-an-analytics-use-case-with-the-5i-framework-9959b0306eee • ユースケース一覧 • ロードマップ アウトプット • ユースケース評価 • Go/No Goの意思決定 • 課題とインパクト • PoC評価 • Go/No Goの意思決定 手法・プロセス・環境 • MVP • DevOps設計 • プロダクトロードマップ • 業務変革ロードマップ • 初期版プロダクト • 各種ロードマップ更新版 • トレーニングの実施 • アジャイル文化の醸成 • Ideationワークショップ等 アイデアの収集 • ポテンシャルマップとロードマップ作 成(2週間程度) • Agile/Kanban方式での調査 • 既存アーキテクチャ検証 • データ分析基盤の導入 • データ収集とアドホック分析(1ヶ月 程度) • 週次での検討会 • Agile Kanban方式での試行錯誤 • MLOps開発環境の導入 • 週次もしくは隔週での検討会 • Agile/Scrumの導入 • MLOpsステージング環境の導入 • Agile/Scrumでのスプリントプラン ニング・レビュー • Agile/Scrumの定着 • DevOps/SREの導入 リードチーム • ビジネスユーザー • DX推進チーム(補佐) • ビジネスユーザー • データサイエンティスト • ビジネスユーザー • データサイエンティスト • アーキテクト/エンジニア/IT(補佐) • ビジネスユーザー • データサイエンティスト(補佐) • アーキテクト/エンジニア/IT • ビジネスユーザー • データサイエンティスト • IT ビジネス側とテック側のコラボによるアジャイル開発 ステージゲート管理 継続・撤退判断
  11. ©2023 Databricks Inc. — All rights reserved プラットフォーム: ProductionレベルのMLOps/LLMOpsアーキテクチャ セキュリティとペルソナ別の使い方を考慮し、ワークスペースの数が決まる

    ワークスペースの役割 特徴 POC用の環境 AI/ML用の開発検証環境 Datapipeline用の開発検証環境 本番環境 ペルソナ • 誰もがアクセスでき、様々な実験ができる • 生データにアクセスでき、試行錯誤が可能 ◦ 要件の確認、認識合わせ ◦ 内容が固まれば、開発検証へ進む • POCで構築したモデルのエンジニアリング • 特徴量テーブルのみ利用可能 • 必要があれば、Data Pipeline側で新規特徴量作成を 依頼する • POCで構築した前処理部分のエンジニアリングをし、本 番化の準備を実施 • • Data PipelineおよびAI/MLのコード・モデルの本番稼 働場所 • 本番環境のインフラおよびモデル(データ、精度)のモニ タリングを実施する • ビジネスユーザ • データサイエンティスト • データエンジニア • MLエンジニア • データサイエンティスト • データエンジニア • MLエンジニア • MLエンジニア データエンジニア • ビジネスユーザ(モニタリングのみ) • データサイエンティスト(モニタリングのみ) • データエンジニア • MLエンジニア
  12. ©2023 Databricks Inc. — All rights reserved 13 Agenda AI/MLの本番稼働の難しさ

    1 MLOpsとエンジニア組織の設立 2 1 3 & AP Communications
  13. ©2023 Databricks Inc. — All rights reserved MLOpsとビジネスインパクト ビジネスインパクトを実現するための要素 People

    Process Platform ビジネスチームに必要なタレント - トランスレーター - データオーナー データチームに必要なタレント - データアナリスト - データサイエンティスト - エンジニア - データエンジニア - MLエンジニア - プラットフォーム管理者 データプラットフォーム - DWH(ビジネスインテリジェンス) - Data Lake(機械学習プラットフォーム) - データガバナンス機能 プロセスやガバナンス - AI開発プロセス - データガバナンスポリシー - AIガバナンスポリシー 14 Use Case ユースケース単位のビジネスインパクト実現 - ビジネスインパクト - クイックWin - アジャイル開発 - データ活用
  14. ©2023 Databricks Inc. — All rights reserved 専門組織(Center of Excellence)の設立と活性化

    • CoEをリードするための 主な任務 • 当初は、社内外からの混成 チーム(DBXの支援含む) • 長期的に社員による内製化 COEサービスリード CoE、ビジネス、テクニカルのオーナー。CoEの全体的な成功を管理する プラットフォーム エンジニア データ エンジニアリング BAUサポート L&Dカリキュラム プログラムMgr スプリントリード イネーブルメント SME チーフデータ/テクニカルオフィサー ビジネスパートナーのアカウンタビリティとサービスアシュアランス ビジネス価値に見合った 適切なワークロードの設計 プラットフォーム、自動化、 ロードマップ管理 PoCとユースケースを 本番実装 - 再利用可能な アセットを蓄積 トレーニング、育成、ゲー ミフィケーション、ハッカソ ン、 マーケティング サポートする役割/リソースの例 AIエバンジェリスト ユースケース デリバリー データ& AIブループリント レイクハウス オペレーション ユースケース アクセラレーション 組織活性化 イネーブルメント データ アーキテクト ガバナンス バリュー トラッキング データサイエンティスト /ML エンジニア 任務 概要 人材 取組み
  15. Use Existing Model or Build Your Own Model Serving and

    Monitoring Data Collection and Preparation DATA PLATFORM UNITY CATALOG LLMOps and Model Management Curated AI Models AutoML for LLM training Models in Unity Catalog Unified Governance/Lineage Features in Unity Catalog Feature + Function Serving Vector DB MLflow AI Gateway Mlflow Evaluation Databricks CLI for MLOps Model Serving LLM optimized Lakehouse Monitoring Automagic Feature Serving Lakehouse AI AIとデータを統合したプラットフォーム
  16. ©2023 Databricks Inc. — All rights reserved 1 7 エンジニア組織が、LLMOpsへの拡張をリードする

    MLOpsに加えて、何を追加する必要があるか: - 人間のフィードバックによる強化学習 - ベクトルデータベース - LLMチェーンとLLMエージェント - プロンプトエンジニアリング - LLMセキュリティ問題、アライメント問題、幻覚問題 - 微調整とモデル評価 MLOpsは当たり前の世界 LLMOpsの実現に向けて
  17. ©2023 Databricks Inc. — All rights reserved Take a way

    MLOpsとエンジニアの進化(する必要がある) • AI/MLは、従来型のシステム開発とは異なる • 人・プロセス・プラットフォームが密接に関係する • 新しいプラットフォームで、 • コラボレーションを重視し、 • 新しいプロセスの定義を! • COE組織の設立がキーとなる可能性 • LLMOpsを実践するには、MLOpsが前提 • エンジニアの進化が必須!!