仕事で外部の人に機械学習などの講習をする機会があったのですが、「機械学習モデルの作り方はわかったけど、それ以外のシステム実装などについても知りたい」という声がありました。いわゆるMLOps的な話の包括的な理解を得るために、積読していた下記書籍を読了。
読んだ感想
- とても読みやすく、（コード実装の細かい部分などは読み飛ばしましたが）2－3日程度で読み終えました。
- 本書では、様々な「デザインパターン」が記載されています。自身に関連するデザインパターンを注意深く読むとよいと思います。（逆に他は結構読み飛ばしました）
- 読み終えた上で、下記のような知識を別でつけたいと思いました。
- チャンピオン-チャレンジャーモデルのような、実際のモデル更新のロジック/デザインについて
- データ変化を捉える指標についてなど
- Population stability index
- Kolmogorov-smirnov index とか
機械学習システムを作るときの振り返りリスト
自分への備忘録として、本書内での学びを振り返りのために記載します。私自身は、MLシステムを作る際にリストを眺めて、思考の抜け漏れがないかをチェックしたいと思います。
パート1：機械学習とMLOps
- MLOpsでは、機械学習のモデルのみならず、モデルを学習し、推論するためのワークフローやシステムを開発し運用する。
- MLがプロダクトとして人間の役に立つためには、MLと人間の作業を住み分けることが重要。
- Google社は、人間とAIのかかわり方を『PAIR（People ＋ AI Research）』として公開している。PAIRでは、MLが人間に提供する価値を自動化と拡張と定義づけている。
- MLのコアである推論の品質は、「データの品質」に左右される。
- MLでは再現性のある学習が必要。再現性で求められることは、自分以外の人間が同じデータと同じ学習コード、同じアルゴリズムとパラメータ、同じライブラリとバージョンで学習を実行し、自分と大差ない結果を得ることができること。
- 多くの場合、Productionを模したテスト用のStaging環境を用意して稼働試験するのがよい。
- 推論結果が想定通りかどうかの確認に加えて、パフォーマンス試験や負荷試験も実施するとよい。
- 推論結果から、アクションをおこす必要のある関係者やステークホルダーを含めて受け入れ試験をするのがよい。
- 推論結果が社内プロセスに組み込まれ、人間の介入が必要になる「ヒューマンインザループ」のワークフローを作ることがある。この場合は、人間の作業が可能な範囲で実施する設計にするべき。例えば、すべてを専門家が確認するプロセスは破綻する。
- 最初からすべてのリクエストを推論器に流すことは避けたほうがよい。徐々にリクエストを上げていく。
- すでに推論器が稼働している更新リリースの場合には、A/Bテストして、両方のモデルを稼働させて比較するのがよい。
- 「どう学習させるか」と同じくらい「いつ学習するか」は重要な検討事項。データの傾向の変化が毎日ほど頻繁でない場合、毎日学習する必要はない。
- 推論器のモデルを再学習するタイミングは、モデルのパフォーマンスを計測し評価すべき。なぜなら、推論モデルのパフォーマンスは、時間とともに劣化していくことがあるため。
- エッジサイドでモデルを推論させる場合には、モデルのインストールが必要となるため、モデルに問題があっても簡単にモデルを入れ替えることは難しい。
- モデルの精度とスピード/コストはトレードオフ。
- 機械学習の品質は、リリース前のテストと、リリース後の劣化補修に分けられる。
- ヒューマンインザループのプロセスの場合、人間がタスクを実行可能でない量の推論では、ビジネスにネガティブな影響を与える可能性さえある。
- 推論器の評価には、システムとしての「リリース判定」が必要。
- モデルの推論を定期的に評価するシステムと、評価結果を通知し、異常事態が発生しているようであればアラートを鳴らす監視システムが必要。
パート2：機械学習システムを作る
- 機械学習の評価がよいモデルと、本番システムで使えるモデルは別。
- ヒューマンインザループによって、機械学習の推論結果を人間が使うような仕組みの場合、使用者に推論結果を評価してもらうことによって、モデルに有用かを判断できる。使う視点で評価することが重要。
- 推論では、レスポンススピードも重要。推論システムのパフォーマンステストや負荷テストも実施する。
- モデル開発と本番システム(推論）で共通のOS、言語、依存ライブラリのバージョンをそろえて開発する。
- 機械学習のプロジェクトには、名称が必要。
- モデルのバージョン管理方法を決める。
- 学習に利用したデータも管理する。評価時に、学習済みのデータを使ってしまい、正当に評価されていないモデルがリリースされるリスクがある。
- 機械学習を学習フェーズをパイプラインで開発すると、段階的に実行可能になり、プロセスをテストしやすい。エラー箇所も特定しやすい。逆に、個別jobのリソース管理やコード管理が複雑になる。また、個別にリソースを確保してしまうため、jobが完了したらリソースを開放するのがよい。
- MLモデルの多くは、学習直後がもっとも推論精度がよく、時間の経過とともに精度が劣化する。最新のデータで学習することでその劣化を回避できる。
- バッチ実行パターンでは、推論に失敗した場合に、推論をリトライするか、運用者に通報する仕組みが必要。サービスレベルとの相談。
- 学習環境と推論環境は別物。目的やコスト構造が異なる。モデルをリリースする際に、最初に直面する課題は、学習環境や学習コードと、推論で必要とするシステムに大きな隔たりがあること。
- 障害や問題があった場合に、その障害を検知し、トラブルシューティングして復旧できるようにする必要がある。
- モデルファイルは、通常学習、推論両方で同じものを使う。入出力のデータ型が変わっていないように注意する。
- モデルファイルの配布で難しいのは、モデルファイルサイズや配布先の推論器との互換性。推論器にインストールされているライブラリのバージョンがモデルと一致しないと、推論器を正常に稼働させることができない場合がある。
- 本番システムですでに稼働している場合には、モデルの配布や更新でシステムを止めないこと（または止めてもよい時間に対応する）を検討する必要がある。
- OS、ライブラリ、バージョン、稼働モデル、入力データ形式、モデルの目的は一元管理する
- 開発が終了しているライブラリや脆弱性があるライブラリのバージョンを使用することは避ける。
- より良いモデルができたら、容易にモデルをリリースできる状態にすることが理想。
- バッチ推論パターンは、リアルタイムor準リアルタイムに推論をする必要がないときや、過去のデータをまとめて推論したい場合に利用する。
- バッチ推論パターンでは、バッチジョブを起動するジョブ管理サーバが必要。決められたルール（時間や条件）をトリガーにして、推論のバッチジョブを起動する。
- バッチ推論パターンは、時間に余裕をもってスケジュールすることができれば、サーバ障害等で推論に失敗してもリトライが可能。 バッチ推論パターンでは、1回のバッチジョブで推論対象とするデータの範囲を定義する必要がある。データ量の多寡によって、推論時間が上下するため、推論結果が必要となるときまでに推論が完了するように、データ量やバッチの実行頻度の調整が必要。
- バッチ処理が失敗した場合の方針を決めておくことが重要（全件リトライ/一部リトライ/放置）
- ベースとなる推論器は、テンプレートから作り、必要な箇所のみ変更することで、推論器開発を効率化できる。同一入出力の推論器を大量開発、リリースしたいときにメリットがある。
パート3: 品質・運用・管理
- MLがビジネスにインパクトを与えるのは、その推論結果がスピード、量、精度において人間の予測よりも優れているとき。
- システムが正常に稼働しているかを評価するためにログを収集する。
- 推論器そのものが異常な場合（推論結果が一定時間発生しない/推論数が通常と比較して異常に少ない等）と、推論結果が想定外の場合がある。推論傾向を監視することが必要。
- 推論を視覚化するダッシュボードなどを用意すると便利
- ログデータは、一般的にシステムの利用不可に比例して増大する。全ログデータを記録し続けるが望ましいが、定期的に圧縮してコスト削減することも重要。
- システムにログがないと、エラー検知や障害対応、システム改善を行うことができない。最低限、Fatal, Error, Warning, Infoのログを取得する。
- 機械学習システムが正常であるというためには、推論が正常に動作する（学習時と同様のパフォーマンス）ことと、推論器自体が正常に動作する（レイテンシーや可用性がサービスレベルを保持）が求められる。
- 機械学習の正常性
- 評価管理
- 学習評価、バージョン管理
- モデルの不備検知と修正できる仕組み
- データ管理
- 学習で用いるデータの妥当性管理（必要なデータ構成、評価データに含まれていないこと）
- 評価管理
- ソフトウェアの正常性
- 変更管理（ソフトウェアバージョンが、モデルのバージョンと一致していることを評価する）
- 可用性管理（正常かつ特定時間内にレスポンスされる）
- 運用管理
- 運用システムの用意（ログ収集、監視通知、モニタリング等）
- 運用体制
- 複雑なモデルの方がMLとしての評価は高くなるが、計算量が増え速度は遅くなる。スピードと負荷耐性が求められる。
- A/Bテストパターンでは、新モデルを現行モデルと並列させて有効性を評価する。モデルが現在の本番システムのデータで有効かどうかは、リリースしてみないとわからない。
