MLOpsは、アルゴリズム構築とは別の才能だ

Last updated at 2025-01-03Posted at 2024-04-22

主旨

データエンジニアリングのうちMLOPsに代表される部分の技能は、従来の個人作業としてのデータサイエンスでの技能と異なっている。
データサイエンス寄りの人へのアドバイス
- 機械学習の利用の拡大が進んでいく中で、個人作業としてデータサイエンスを推進してきた人は、組織としての、製品・サービス提供の流れの一部として機械学習・データサイエンスを推進できるように、扱える領域を拡大する必要がある。
DEvOps寄りの人へのアドバイス
- DevOPsからMLOPsよりのデータエンジニアリングに入ってきたひとは、データサイエンスよりの才能の持つ人を上手に取り込んで、協力して進められるようにしてほしい。

補足：別の才能ではあるが、しょせんは習得可能な技術である。
いまの時点での推奨のやり方がわかっていれば、それをたどるのは簡単になる。

データエンジニアリングとデータサイエンスの才能は別物だ。

データエンジニアリングは、工学的な視点で捉えたことを指し示しているようです。
「データエンジニアリングとは、分析のためにデータを収集して解釈し、検証することです。特にデータエンジニアは、データウェアハウスを構築することでデータに基づいた意思決定を可能にします。データエンジニアリングは、データサイエンスを現実世界に応用するための基盤となるものです。」

とりわけ、データエンジニアリングの中での固有のDevOPsの部分をMLOpsという言葉で表現されているようだ。Machine Learning の分野でのDevOpsとしてMLOPsは定義されるらしい。

データサイエンスとデータエンジニアリング

データサイエンスには含まれず、データエンジニアリングに含まれるもの

大規模なデータを扱うための技法の構築
特定の開発者だけしか使えないものから、他のメンバーも使えるシステムへ
得手の開発者だけ利用できるデータ環境から、他のメンバーも使えるデータ環境へ
データ解析・機械学習の環境を、環境自体のバージョン管理と対象のデータのバージョン管理をできるシステムへ
特定のバージョンの組み合わせで動いているものから、今後も引き続き動作できるシステムへ
1回限りの処理から、継続的な分析・改良のシステムへ

私見：データエンジニアリングという言葉の指し示す範囲

データエンジニアリングには、データサイエンスという言葉では抜け落ちている範囲をも含んでいるようだ。
また、データエンジニアリングという言葉は、データサイエンスで指し示している範囲を含んでいても問題のない使われ方をしているようだ。
この文章の中では、データエンジニアリングという言葉で、従来のデータサイエンスの視点では抜けているものに着目する使い方をする。ほぼほぼMLOpsという言葉で表されている領域だ。

データサイエンス（機械学習を含む）の側に属するもの

機械学習で個別分野によらず共通に用いられるアルゴリズム
- 分類問題
- クラスタリング
- 回帰
- 次元削減
個々のデータサイエンスのアルゴリズム
- 例：　画像認識分野
  - 検出
  - セグメンテーション
  - 追跡
  - 顔照合
  - 属性推定
  - 奥行き推定（画像計測）
    これらのアルゴリズムは、データサイエンスの側に属している。
    どちらかというと、それぞれの分野のデータサイエンティスト（＝画像認識屋も画像認識という分野のデータサイエンティストとみなせる）の側が、自身の開発環境上で動作させて、その結果の妥当性を示してきた分野である。

機械学習の進展が、エンジニアリングを必要とするようになった。

機械学習が近年成果を上げてきたため、それを事業の中で絶えず改良して維持していく必要を生じるようになった。
かつての状況：
- ある時点での機械学習の成果を固定した版でリリースする。
- リリースした製品は、ネットワークで更新されることはなかった。
現在の状況：
- 製品中のライブラリを、ネットワーク越しに更新する必要を生じている。
- そのために、継続的な開発と継続的なテストが必須になっていった。
- 機械学習そのものの部分も、データセットを含めてバージョン管理をすることが必須になった。
- 事業として継続させるためにも、複数の開発メンバーに引き継げるようにすること。
- データセットを拡充して、改良をする仕組みをとりこんでいくこと
データサイエンスの分野から入った場合には、次第にデータエンジニアリングを習得していく。
- 昔からの機械学習屋が開発に着手したときには、DevOpsもMLOPsもなかった。
- 個人芸としての機械学習から、組織としての機械学習に変化してきた。

機械学習をつかったサービス・モジュールが利用上の価値を持つことを確かめないうちは、MLOpsの大規模なシステムに開発をするのは価値がない。(個人的見解)

deployの自動化は、利用価値が成立してからでないと意味がない。
ある機械学習が性能が出たとしても、それを利用する側が必ず価値が出るわけではない。
パスポートでの顔照合のためには、斜め顔での顔照合など不要だ。（むしろ、斜め顔で顔照合しようとして、間違った結果を返される危険が増えるのは許されないだろう。）
あなた方が提供しようとしているサービスの中で、その機械学習結果が価値がある利用方法にたどり着いたと確信できるようにすることの方が先決だ。
利用する価値にたどりつかないうちに、デプロイの自動化は無駄な作業でしかない。

機械学習が利用可能になるまでに必要な才能

機械学習を利用するとよい対象を見つけ出すこと。
機械学習の課題の定式化すること
- 例：分類問題なのか、検出問題か、レコメンデーションなのか
その定式化にそってアルゴリズムを選択すること。もしくは開発すること。
実現しようとする構想に対して、うまくいきそうだと確信させる初期の結果をえること。
学習が必要か、既存のモデルで十分かどうかを見極めること。
学習データの収集のプランニングとアノテーションの実行
データの前処理の実行
学習の遂行と評価
学習済みのモデルの利用する推論を利用するシステムコードの作成

その機械学習がメンテナンス価値をもつことが判明した後

自動化のためのフロー

学習用データの健全性の確認
学習用データの登録
学習の開始
学習後の重みファイルの管理
評価の実行
- シーンごとの評価の実施
学習結果のデプロイ

自動化のためのフローで必要になる技能

MLOpsの構築は、CI/CDの構築と共通した技能が必要になる。
大規模な学習用のデータの管理
- 例：Data Version Controlなど
大規模な学習の実行のための学習用のマシンの環境設定の構築
依存ライブラリ群のバージョンが変化していく中での一連のシステムのメンテナンス
学習結果の評価の自動化
- CicrcleCIやGitHub Actionsの利用のための処理の記述
学習結果の重みファイルのデプロイの自動化
- 学習用の環境からデプロイ先の環境に向けたデータの変換

学習を効果的に実行するための技能

学習・評価用のデータを構築することができるように、学習すべき課題を理解できている。
学習の性能をどのような範囲から確保していくのか立案して遂行できる。
どのような部分での性能の不足が、用途に対して影響がでるのかを理解して対策を実行できる。
手持ちの学習データだけでは、どのような問題点を持つのかを理解できる。

MLOPsのフレームワークを自前で作成しようとするのは得策じゃない。

MLOPs に近づいていく順序

bash やMakefile の使いこなしに慣れていこう

cat $(ls -t *.txt | head -1) での$() の使い方がわかる程度にbash の使い方に慣れよう。
MakeFile 中に make test の動作が書ける程度にMakefile に慣れよう。

リポジトリの中の環境構築する手順を自動化する。

例：Pythonの場合
python3.x のvenv環境を作る。
python3.x のvenv 環境で以下の処理を行う。
~~動作に必要なものをrequirement.txt に記載する。~~
~~pip install -r requirement.txt で、必要なpython モジュールをインストールできるようにする。~~
~~python setup.py install でそのリポジトリのモジュールをインストールできるようにする。~~
~~python setup.py bdist_wheel でwhlファイルを作成できるようにする。~~
pyproject.toml に設定を集約しましょう
python3 -m pip install .　でインストールできるようにします。

自動化テストを作成する。

testディレクトリを作り、pytest *.py でテストが実行できるようにする。
リポジトリのROOTにMakefile を作り make test でテストを実行できるようにする。
テストは２種類の違いを明確にしておく。
- １つは、実装時の性能によらず、固定した戻り値が期待できるもの。
- APIの仕様などはこちらに属する。
- もうひとつは、機械学習の性能などによって、戻り値が期待値と必ずしも一致しないことがあるもの。
- 使用する乱数の状況によっては、毎回同じ戻り値が返ってくるとはかぎらない
- 機械学習の性能の評価においては、失敗し得ないほど明確な典型例を少数用意しておいて、APIのテストに準じるもの、多数のデータによって、性能を見極めるものとが存在する。
- github にPRを上げる際にテストを走らせるようにするためには、性能評価のために大量のデータを必要とするものは、make test で行われるような自動化テストの範囲の外におく。

自動フォーマットで書式をそろえるように環境を作っていく

python の場合PEP8でコーディングスタイルの標準化が意図されている。それにそろえていくことが、複数の人でコードを開発していく際にのぞましい。
はじめの段階：ローカル環境でのフォーマッタの利用(例 black)
次の段階： github との連携
- PRをマージしようとする時点で、フォーマットのチェック・auto formatter の適用をするように設定をする。

多数・大容量のデータを必要とする学習・性能評価の環境を作る

留意すること
- 同じリポジトリを必要とする人のほとんどは、多数・大容量のデータを必要としない。
- git clone; git pull するだけで、それらのデータをローカルにコピーを生じないこと。
あるアプローチ：
- 多数・大容量のデータを別リポジトリで管理する。
- しかも、データの取得方法を、DVCやremote storage からのコピーにする。
- そのデータを所定の場所におき、それを使って学習・性能評価をするようにする。
アプローチの実際の例
- そのデータのリポジトリをgit clone; git pullする。
- そこで、１つのコマンドを実行するだけで、データを準備できるように作る。
- 例： dvc pull で十分とする。
- 例：　gsutil rsync -r dst dst
- そのデータのリポジトリのREADME.md にデータ環境をコピーするための手順を書いておく。
別リポジトリのデータを利用する側の手順の自動化
- make train で学習, make eval で評価できるようにMakefile を書いていく。
- make eval では、評価レポートを自動生成するようにしよう。
- 例：再現率・適合率のグラフの自動生成

学習結果の保存方法とdeploy の方法を構築する。

留意すること
- git clone; git pull をした時点で消費する領域に過去の学習結果を含めないこと。
- LFSでないgit で学習済みの結果を登録しない。（学習を繰り返すとたちまち、履歴を含めると１GBを超えてしまいやすい。）
- deploy　はターゲットデバイスによって必要なファイルが違ってくる。
- あるバージョンの学習結果と別のバージョンの学習結果との比較ができるようにしたい。
- 学習結果を更新するたびに、性能がどう変化したのかをgithub 上のPRで差分を見ることで簡単に比較することができるようにしたい。
- 別PC上で、学習を再現できることを確認すること。
  - 管理されていない部分があるために、別PCでは動かないということが簡単に起こる。
あるアプローチ
- make add_model といったような記述でモデルを登録できるようにすること

追記(2025年）
Co-MLOps Platfrom の機能アーキテクチャ

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up