Developer Summit 2023 Inspiredの登壇資料。 https://event.shoeisha.jp/devsumi/20230209/session/4140/
Developers Summit 2023 Inspired機械学習を実用化するエンジニアリングスキル2023/02/09 Yusuke Shibui
View Slide
自己紹介shibui yusuke● もともと文学部の大学院卒。● いろいろ → Launchable（いまここ）● MLOps & リサーチ & データ基盤 & バックエンド &インフラ & セールス & マーケティングエンジニア○ エンジニア採用中！● もともとクラウド基盤の開発、運用● Github: @shibuiwilliam● FB: yusuke.shibuicat : 0.55dog: 0.45human : 0.70gorilla : 0.30物体検知2https://www.launchableinc.com/careers/senior-software-engineer/
● 発売中！● https://www.amazon.co.jp/dp/4798169447/● 発売中！● https://www.amazon.co.jp/dp/4798173401/
今日話すこと● 機械学習によってユーザに価値を届けるための○ 企画○ 技術○ チーム失敗談と学びをベースに話します。
今日話さないこと● 機械学習やAIの理論や作り方● 機械学習基盤の作り方や MLOpsの実践方法● エンジニアの採用・育成方法
クラウドを作っていた時代の私の原体験● 2010年、新卒入社した日本のSIerで最初の仕事は会社初のパブリッククラウドの開発と拡販。○ AWSの東京データセンター設置が2011年3月。○ まだ国産クラウドがグローバルカンパニーと戦える可能性の合った時代。● 物理サーバビジネスで商売していたエンジニア、営業から社内競合として反発。○ 「インフラエンジニアはどうなってしまうんですか・・・？」● 機械学習エンジニアやデータサイエンティストが将来、新しい技術に置換されない理由はない。● 新しい技術の実用化、運用、拡販は常に発生する課題である。
ユーザに価値を与える機械学習を目指して
機械学習を使う必要がないなら使わないほうが良い● 「機械学習で改題解決するコスト」 ＞ 「ソフトウェアで課題解決するコスト」● ただし、「機械学習で解決する価値」 「ソフトウェアで解決する価値」＞＝＜
機械学習で解決したほうが良い課題課題：人間や社会にとって不都合なこと、手間なこと、遅いこと、不正確なこと・・・ソフトウェアで解決できる課題：解決方法をコンピュータシステムに組み込めるもの機械学習で解決できる課題：解決方法に関連するデータとモデルが存在するもの機械学習で解決したほうが良い課題：機械学習を使うことで得られる効果が他の手法より大きいもの
機械学習で解決するために必要なもの
なにから手を付けて良いのかわからない
最初から必要なスキルセットを見通すことは難しいデータを集めるモデルを学習するオフライン評価する課題を決めるここまで一人でできたここから先どうしよう・・・
● 条件：人、金、時間は有限● 必要：○ 企画：最初の課題解決を成し、再現性を証明する○ 技術：変更できるシステムを作る○ チーム：スキルとモチベーションを一致させる● 有効な場合はあるけど、必要とは限らない：○ MLOpsや機械学習基盤○ Kaggleの知識○ 知名度機械学習を実用化するためのエンジニアリングスキル注目されることが多いこっちのほうが重要
課題に対する企画、技術、チーム課題企画技術チームゴール
企画とプロダクト
最近よく聞かれること「機械学習を使うためにはMLOps（または機械学習基盤）が必要なんですか？」
はじめての機械学習プロジェクトあなたは日本全国に小売店を展開する「AI商店」で働く機械学習エンジニアです。企業初の機械学習プロジェクトを立ち上げようとしています。発注納入購入
AI商店の評価できる課題から始める発注納入購入需要予測納入遅延予測レジ自動化在庫管理自動化導線分析温度管理自動化防犯分析発注自動化
失敗例（経験談）● tl;dr 価値が出るかわからないのにすごい作り込む● 「最高の」需要予測モデルを作るのに半年かかった● その学習コードが100,000行、100Pythonファイル、10コンフィグファイルで構成され、1学習にCPU 100coreで12時間かかる● 経過時間のほとんどはデータの集計● オフライン評価は高いが、オンラインでは検証していない● 時系列データをランダム分割している● 反リーダブルコード、非テスト駆動開発● 最初から高度な自動化と基盤運用が求められる● 作ったエンジニアは運用しない（開発だけ外部に委託契約）● 安定運用するまでに開発物の納入から1年かかった
機械学習を使うプロダクトを企画する● 評価できる課題から始める● 手間≠価値● 実験（評価と失敗と修正）をプランニングする● やらないことを決める
手間 ≠ 価値little effort huge effortsmall impactlarge impactMUSTWait until youneed itAre you sure?Low riskstarting pointここを目指す 必要になってからここから始めて
機械学習の施策におけるEffortとImpactlittle effort huge effortsmall impactlarge impact実績のある既存手法の実用化例：ECや検索の推薦共通基盤やR&Dの伴うモデル開発例：MLOps、ML基盤既存システムの再構築や間違った技術選択例：基盤の移行、Fortranで機械学習既存モデルの活用例：コピペ、再学習ここを目指す 必要になってからここから始めて
手間≠価値発注納入購入インフラクラウド、ネットワーク、アカウントデータ基盤 ML基盤共通基盤（ログ、モニタリング、CI/CD・・・）推論基盤BIMLパイプライン需要予測基本モデル需要予測モデルA需要予測モデルB俺の最強ML基盤
課題を解くための価値ある施策から始める発注納入購入インフラクラウド、ネットワーク、アカウントデータ基盤 ML基盤共通基盤（ログ、モニタリング、CI/CD・・・）推論基盤BIMLパイプライン需要予測基本モデル需要予測モデルA需要予測モデルB今すぐ必要ではないし、必要になるとも限らない最低限のビジネス的な評価すべき価値
実験（評価と失敗と修正）をプランニングする● 解きたい課題に対して既存のデータと手法が有効か否かを調べるためには実験が必要。● 課題が解けていることを証明するためには評価が必要。● 求める評価に至らない場合（実験が失敗した場合）には修正が必要。● 実験は時間的・金銭的制約の中で実施しなければならない。ルールベースや統計手法Logistic回帰等簡単なモデル特徴量の工夫とGBDT資金力と意地とNeural Network諦めるオフライン評価本番システムで評価現状調査とデータ収集本来の実験のゴールはここここが一番たいへんなことが多い諦めも大事ここはまだ過程調査 -> 本番で実験のサイクルを早くしたい
AI商店の需要予測のプランニングPoC・初期フェーズ 発展・拡大フェーズ需要予測の実用化オフライン評価分析と開発オンライン評価需要予測システム開発現状調査課題定義GO/NO GO判断需要予測の自動化開発チーム化、採用オフライン評価分析と開発現状調査課題定義オンライン評価課題の再定義開発・運用スタイルの確立基盤の整備
やらないことを決めるPoC・初期フェーズ 発展・拡大フェーズ需要予測の実用化オフライン評価分析と開発オンライン評価需要予測システム開発現状調査課題定義GO/NO GO判断需要予測の自動化開発チーム化、採用オフライン評価分析と開発現状調査課題定義オンライン評価課題の再定義開発・運用スタイルの確立基盤の整備まずはここで成功させる。 こっちは後回しにする。
どこから作る？● Jupyter NotebookでPoCモデルを作ってオフラインで試す● モデルとコードを作って多様な店舗で試す● 学習をバッチシステムに組み込んで自動化する● 機械学習基盤を作って学習と推論を自動化する● 全店舗にEnd-to-endでMLOpsを導入するlittle effort impact???huge effort
どこから作る？● Jupyter NotebookでPoCモデルを作ってオフラインで試す● モデルとコードを作って多様な店舗で試す● 学習をバッチシステムに組み込んで自動化する● 機械学習基盤を作って学習と推論を自動化する● 全店舗にEnd-to-endでMLOpsを導入するlittle effort impact???huge effort作る作らない
手間を最初から見通すことは難しいエンジニアの手間初の機械学習実用化新しい開発機能企画時に見えている手間 実際に発生する手間機能開発は最初に手間が発生更には機能改善と運用の手間が積み重ねで発生運用再学習調整ディープラーニングに挑戦モデル更改リファクタリング追加の機械学習実用化再学習リファクタリング機械学習基盤構成管理アップデート再学習調整再学習リファクタリング再学習調整モデル更改リファクタリング再学習リファクタリング再学習調整企画時に見えている手間と本当の手間が乖離していくと、エンジニアの生産性が悪く見えてくる
手間を最初から見通すことは難しいが、価値を見通すことはもっと難しいここのどこかここのどこか
AI商店の現状の需要予測システムの全体像（現状） 販売実績発注納入
初期の需要予測システム（Laptopで実行）AI商店の需要予測PoCシステム学習推論評価分析と展開評価と分析予測データ発注納入実績データ
基盤の整備発展させていくための優先順位を考えるPoC・初期フェーズ 発展・拡大フェーズ需要予測の実用化オフライン評価分析と開発オンライン評価需要予測システム開発現状調査課題定義GO/NO GO判断需要予測の自動化開発チーム化、採用オフライン評価分析と開発現状調査課題定義オンライン評価課題の再定義開発・運用スタイルの確立成功どこから手を付ける？
技術
新しいものが出たらすぐ便利になるのではなく、新しいものが再現性を持って実用化されてから便利になるMachine learningDeep learningGenerative AIPlatform2011 2012 2013 20232022202120202014 2015 2016 2017 20192018BigQuerydbtKubeflowAlexNetDCGANTensorFlowDQN AlphaGoAlphaZeroXGBoostLightGBMONNXPyTorchAnacondaGoogleNetResNetKaggleSageMakerKerasCore MLMediaPipeTensorRTNvidia K80JupyterNotebookGoogle ColabWord2VecVertex AIMLflowSparkCLIPBERT GPT-3OpenAIHidden debtpaperDiffusionmodelHuggingFaceAutoMLOptunaKatibChatGPTSnowflakeAirflowCycle GAN Style GANMagentaVAECatBoostFlaxTFServingTorchServeStableDiffusionNvidia A100TPUTransformerイノベーションイノベーションイノベーション イノベーションイノベーションイノベーションイノベーションイノベーションイノベーションイノベーションイノベーションイノベーションCodeXBQML
理論から学習へ、学習から推論へ理論公開コードまたは数式から実装バッチ推論多くの場合学習と同じ技術で可能推論API学習したモデルをサーバにロードして外部リクエストを受けられるようにするEdge AI学習したモデルでデバイスにロードして推論する公開モデル再利用可能な学習済みモデルとして公開される学習数週間〜数ヶ月 数週間〜数ヶ月 数ヶ月〜論文公開ここに至るのは極一部
動物画像SNS
レコメンデーションここになにを表示する？人気の動物写真ユーザが好きそうな動物写真検索条件で人気の動物写真似ている動物写真簡単・安い難しい・高い検索・並び替え協調フィルタリングランク学習類似画像検索？？？効果
失敗例：変更困難な基盤DB Log DWHModelDB学習基盤検索APIAPIANNCI/CDDL監視CThard coded
変更するつもりで作る● 機械学習モデルやライブラリ、基盤は頻繁に更新、変更される。● すべての新しいライブラリや基盤が後方互換性を保っているとは限らないし、新しいモデルが常に良いとも限らない。● 変更頻度と変更難易度を考慮してシステムを設計するスキルが求められる。● 変更がうまくいかない場合はロールバックできるようにしておく。変更難易度変更頻度高低低 高学習データ学習済みモデル推論APIMLライブラリの更新GPUデータ基盤ML基盤永続データ推論ライブラリ評価指標バッチ処理推論を使う外部システムMLライブラリを変更
推論から考える● 常に推論できるモデル（ =本番システムで使えるモデル）を学習する。● 推論の優先順位○ まずはルールベースや統計処理で対応可否を検討する。○ 機械学習が必要な場合はバッチ推論（学習と同じシステム構成で可能）を検討する。○ バッチ推論が利用不可の場合（入力が動的に変わる）、同期推論や非同期処理を検討する。■ ONNXやTensorFlowServing、TorchServeを活用可能なモデルを優先して選ぶ。■ 推論ライブラリを使えない場合はサーバで稼働させた場合のパフォーマンスと安定性を重点的に検証する。○ ユーザ端末でリアルタイム処理が必要な場合は Edge AIを検討する。■ 本当にリアルタイム性が必要か立ち止まって考える。■ Edge AIで使えるモデルは選択肢が少なく、モデルの更新リリースが難しいことを考慮する。● 学習の考慮事項○ 推論で活用可能なモデルを学習する。○ 学習基盤はメンバー数とモデル数に応じて徐々に導入する。一度に全部入れる必要はない。○ 【超重要】以下 4点を疎かにしてはいけない。■ リーダビリティ、テスト、インターフェイス、ライブラリ管理。選択肢 難易度多少 難易
基盤、共通システムをどう選ぶか● 技術選定の方針：安い、早い、簡単なものを選ぶ。「有名」というだけで選ばない。○ 安い、早い、簡単は導入後の生産性を左右する。生産性はエンジニアのモチベーションを左右する。● 導入の手順：安い、早い、簡単かつ取り返しのつかないところから導入していく。○ （前提：DWH、データ基盤）○ 実験管理・モデル管理：MLflow、DVC、Weights&Bias、各種クラウド○ データ・モデルモニタリング：Grafana、Great Expectations、各種クラウド○ 学習パイプライン：Airflow、Argo Workflow、Prefect、各種クラウド○ 統合的な機械学習基盤：各種クラウド○ その他（Feature Store、Explainable AI、アノテーション・・・）安い、早い、簡単NoYes
オフラインで実験● オフラインでモデルの学習を実験する。● 用途例：機械学習のPoCや開発● 必要なスキルセット○ 学習モデル開発、評価○ モデル管理○ GPU等のインフラ管理実験Laptop or Google ColabModelDBDWHレポジトリ
バッチ学習 + バッチ推論● 定期的に学習と推論を実行する。● 推論の利用が固定値かつ定期更新で良い場合に有効。● 学習と同じ方法で推論することが可能であるため、インフラやコードを学習と推論で共有できる。● 用途例：需要予測、推薦等。○ テーブルデータで使うことが多く、逆に画像やテキストデータだと有効でないことが多い。● 必要なスキルセット○ 学習基盤と学習パイプライン○ 推論結果をDBに保存○ 最低限のモニタリング● あると便利なスキルセット○ BI○ ドリフト検知DBバッチ学習ML基盤バッチ推論ModelDBCI/CDDWHCTレポジトリ実験環境ここを変更するのは簡単。推論結果を出力するテーブルはしっかり設計したほうが良い。
バッチ学習 + 同期推論 or 非同期推論● 定期的に学習したモデルを推論器としてデプロイ。● リクエストに応じて推論する用途で有効。● 学習と推論で異なるコード、ライブラリ、インフラ、ライフサイクルが必要になる。● 用途例：推薦、検索、違反検知、異常検知。○ 多様な用途で利用可能だが、ワークフローが複雑になると開発運用が難しくなる。● 必要なスキルセット○ 学習基盤と学習パイプライン○ Web APIや非同期処理○ 推論器のビルドとCI/CD● あると便利なスキルセット○ BI○ ドリフト検知○ API開発と運用実験環境バッチ学習ML基盤CI/CDDWHビルド推論API運用管理CI/CDレポジトリインターフェイスとパフォーマンスが重要。ビルドとCIがボトルネックになることも多い。推論モデルを目標に設計する。ModelDBCT
バッチ学習 + 同期推論 or 非同期推論 + A/Bテスト● リクエストグループに応じて推論するAPIを分散する。● 本番システムで複数の推論モデルを比較する場合に有効。● 学習と推論で異なるコード、ライブラリ、インフラ、ライフサイクルが必要になる。● 学習と推論リリースは比較対象との優位性によって判定する。● 用途例：Webやアプリ等、ユーザ次第で有効なアルゴリズムが変動する用途。○ A/Bグループとモデルの対応次第では複雑なライフサイクルが必要になる。● 必要なスキルセット○ 学習基盤と学習パイプライン○ Web APIや非同期処理○ 推論器のビルドとCI/CD○ A/Bの分割と学習、推論のライフサイクル管理● あると便利なスキルセット○ BI○ ドリフト検知○ API開発と運用実験環境バッチ学習ML基盤CI/CDDWH推論API管理/監視CI/CDレポジトリA/Bproxy推論APIリリースを制御する。振り分けルールとバックアッププランが鍵。ビルドModelDBCT
PoC：機械学習の有効性と有用性を証明するDB Log DWH検索API分析環境Prove ML or not ML
プログラムマネジメントスキルチームマネジメントスキルフェーズによってチャレンジする機能を選ぶ機能によって必要なスキルは異なる● 初期フェーズ：0->1を作るチャレンジ○ ベースラインになる推薦を作る○ 作った推薦アイテムを本番で公開する○ 推薦の価値・可視化を分析する● 発展フェーズ：自動化・共通化・高度化するチャレンジ○ 推薦とシステムの品質を維持・改善する○ 既存の基盤を活用する○ 特定ドメインの専門知識を実用化する● 分割・専門化フェーズ：巨大システムを疎結合にするチャレンジ○ チームを分割しマネジメントする○ 共通課題を仕組みで解決する早く安くリーズナブルな規模と品質で開発、運用するスキル共通化・自動化するソフトウェアスキル複雑なドメインナレッジと分析力Item2Item人気順BIバッチ推薦User2ItemCI/CT/CDA/BテストPersonalize推薦基盤共通基盤R&Dチーム基盤チーム評価
機械学習を実用化するためにMLOpsが必要とは限らないMLOpsを実践するために機械学習基盤が必要とは限らない機械学習MLOps機械学習基盤解決する手段定期的な改善が必要数が増えて共通化自動化したい共通化したい機械学習を使うシステム組み込む解決する共通化したい課題解決に必要データで解決できる課題課題解決に必要とは限らない
初期は小さく成功するためのエンジニアリングDB Log DWH推薦テーブル学習バッチ検索APIBI推薦API定期的に推薦リストを作成して記録しておく推薦テーブルから検索推薦の評価
定期的なモデル改善のためにMLOpsのプラクティスを取り入れる複数モデルの開発と運用を共通化・自動化するために基盤を作る機械学習MLOps機械学習基盤解決する手段定期的な改善が必要数が増えて共通化自動化したい共通化したい機械学習を使うシステム組み込む解決する共通化したいデータで解決できる課題
複雑性・エッジケースを内包するDB Log DWH推薦テーブルModelDB学習基盤検索APIBIA/BproxyMLAPI推薦APICI/CD実験評価管理AutoScale監視CT
チーム
失敗例：理想のチームを作ったはずが・・・ML/DSチーム 6名● データ分析● モデル開発もともとあった
失敗例：理想のチームを作ったはずが・・・ML/DSチーム 6名● データ分析● モデル開発MLOpsチーム 5名● ML基盤開発、運用● MLライブラリ開発● MLの本番システムへの組み込みもともとあった 新設！
失敗例：理想のチームを作ったはずが・・・ML/DSチーム 6名● データ分析● モデル開発MLOpsチーム 5名● ML基盤開発、運用● MLライブラリ開発● MLの本番システムへの組み込みML基盤やライブラリが使いにくい研究できないモデルのリリース・修正が拒否されるML/DSのコードが汚いML基盤とシステムの運用が大変モデルを修正してくれないコスト管理やコードレビューが厳しいML/DSが基盤やライブラリを使わないドキュメントがない新しいML手法が基盤でサポートされてない
PoC理想的なチームの成長とスキルセット・モチベーションの遷移機械学習導入開始実用化自動化・基盤化完全自動化複数システム機械学習エンジニア一人機械学習エンジニア複数 +PM機械学習エンジニア +バックエンドエンジニア +PMプロダクト別チーム一人でML+ドメイン+バックエンド +突破力MLドメインバックエンドMLドメインバックエンドフロントエンドマネジメント基盤SREマネジメントMLドメインバックエンドフロントエンド新しいことが得意な一人から始まる組織化・仕組み化されたチームになるプロダクトごとに自己完結する安定したチームへ疎結合化、サイロ化基盤SREDS新事業R&D研究や新規事業が別チームへ初期の小さなチームになる再現性の証明0->10->1開発1->101->10開発運用修正10->100定型化修正調整定型化研究研究管理管理育成成長研究研究0->10->1研究スキルセットフェーズの説明モチベーション安定開発
PoC失敗例の考察機械学習導入開始実用化自動化・基盤化完全自動化複数システム機械学習エンジニア0->11->10研究MLドメイン1->10バックエンド基盤マネジメントMLOpsチームバックエンドエンジニア +基盤エンジニア開発運用定型化管理新しいMLモデルを開発、実用化したい新しいML基盤で仕組みを作りたい● MLOpsチームの導入目的：○ 人数が増えて開発が非効率になっていたMLプロジェクトを共通化、自動化、効率化する。● MLチームの受け止め方：○ これまでうまくいっていた開発を一方的に変えられる。MLチーム
PoC失敗例の打開案機械学習導入開始実用化自動化・基盤化完全自動化複数システム機械学習エンジニアバックエンド・基盤エンジニア機械学習エンジニア +バックエンドエンジニア +PMプロダクト別チーム1MLチームドメイン別チームMLOpsチームMLチーム試した施策1 チーム統一● 各メンバーのチームを統合して役割・スキルを統一する。● お互いに教え合う文化とリーダーシップが必要。試した施策2 ドメイン分割● ドメイン・プロダクトレベルでチームを分割する。● 「ユーザの課題解決」にフォーカスする目的の共有。● スキルセットは分散する。
PoC・実験フェーズ● モチベーション○ 0->1○ 初めての機械学習プロジェクトを完遂● スキルセット○ 行動力・説明力・調整力○ 機械学習○ バックエンド○ ドメインナレッジ● システム○ データ○ 最悪ラップトップ1台でも良いDB Log DWH分析環境
初期の実用化フェーズ● モチベーション○ 0->1○ 初めての機械学習プロジェクトを完遂○ 運用で安定・改善● スキルセット○ 評価とフィードバックループを作る○ バックエンド○ 機械学習パイプライン● システム○ DWHとワークフロー（バッチ）○ DBと推論サーバDB Log DWH推薦テーブル学習バッチ検索API推薦API
拡張・成長・再現性の証明フェーズ● モチベーション○ 機械学習活用の再現、拡張○ 高度・複雑な課題解決● スキルセット○ 評価とフィードバックループを作る○ バックエンド○ 機械学習パイプライン○ 再利用性● システム○ ワークフローの再利用○ プロキシと推論サーバ○ 管理（モニタリングとBI）○ CI/CD検索API DB Log DWH学習バッチBIA/BproxyMLAPI推薦APICI/CD監視
仕組み化・共通化・自動化フェーズ● モチベーション○ 共通化・自動化・基盤開発○ システマチックな課題解決● スキルセット○ CI/CD/CT○ 評価と品質管理○ 機械学習基盤○ サービスディスカバリと推論 API○ チームマネジメント○ ドキュメンテーション● システム○ 機械学習基盤○ ワークフロー管理○ インフラ管理○ 実験管理DB Log DWH推薦テーブルModelDB学習基盤検索APIBIA/BproxyMLAPI推薦APICI/CD実験評価管理AutoScale監視CT
分割・専任化フェーズ● モチベーション○ 開発・運用生産性の向上○ コミュニケーションコスト削減○ 大規模開発と育成○ 多様性の受容● スキルセット○ マネジメント○ 調整力・俯瞰力○ ドキュメンテーション○ 他人の作った基盤を使う能力● システム○ チームコミュニケーション○ データとインフラの共通基盤○ システムの個別化・独立化インフラクラウド、ネットワーク、アカウントデータ基盤 ML基盤共通基盤（ログ、モニタリング、CI/CD・・・）ユーザインタフェース（Web、スマホ、その他）バックエンド バックエンド バックエンド機械学習 機械学習 機械学習
まとめ
ユーザに価値を与える機械学習を目指して● 企画・プロダクト：課題から始める、 Little effortから始める● 技術：再現性を証明する、変更するつもりで作る● チーム：スキルセットとモチベーションを一致させる
ありがとうございました！
shibuiwilliam
kubukoz
robots
safie_recruit
shimashima35
sumiren
ykanoh
bitkey
aiji42
yayoi_dd
soracom
hirokiotsuka
jordihofc
tammielis
davidbonilla
zakiwarfel
geoffreycrofte
dougneiner
philnash
paulrobertlloyd
sferik
holman
bluesmoon
keithpitt
philhawksworth