Twitter見てたら、こちらを見かけました。
Continuous Delivery for Machine Learning
— u++ (@upura0) 2019年9月13日
Automating the end-to-end lifecycle of Machine Learning applicationshttps://t.co/411c9l8e4d
気になるタイトルだったので、最近全然英語読んでなかったリハビリも兼ねて、自分で読んでみたのでそのメモです。
※解釈が間違ってたらごめんなさい。今回あんまり自信ないです。
背景
実世界における機械学習システムは、数ある機械学習のコードのうちのほんの一部に過ぎない。 機械学習の学習は、非常に多くのインフラやプロセスに支えられている。 そして、そのようなシステムを構築する上で技術的負債が蓄積されていくが、これらはデータ依存性、モデルの複雑さ、再現性、テスト、監視、外界の変化への対処に関連している。
似たような悩みは従来型のシステムでも指摘されているが、信頼性のあるプロダクトを継続的にリリースするための自動化・品質、統制の枠組みであるContinus Delivery(CD)の手法が提唱されている。
ところが、機械学習ではコードだけでなくモデルやデータの変更についても気を配らなければならない。
目的とアプローチ
目的
- 機械学習システムにおける小規模かつ安全な更新に対する生産性と信頼性の向上
アプローチ
- CD4ML
- 部隊の垣根を横断するコード・モデル・データに基づいた機械学習アプリケーションにおけるソフトウェア工学的アプローチ
CD4ML
CD4MLにはいくつかの基本的理念で構成されている。
- ソフトウェア工学アプローチ
- 効率よく高品質なプロダクトを作るべきである
- 職能横断チーム
- データエンジニアリング、データサイエンス、機械学習、開発、運用など異なるスキルを持った専門家が一緒になって協調する
- コード・モデル・データに依存するプロダクト
- 機械学習による生産物はそれぞれ個別にバージョン管理されるべき
- 小さく安全なインクリメント
- ソフトウェアのリリースは小さな増分に分割されることで、制御可能な範囲に分散が収まりコントロールできる
- 再現性のあるソフトウェアリリース
- 機械学習モデルのアウトプットは決定論的ではないが、信頼性と再現性、自動化はできる限り推進すべき
- いつでもリリース
- ソフトウェアはいつでもリリースできるべきである
- 短い適合サイクル
- 開発のサイクルは週・月単位ではなく、日単位であるべきである。これによって、プロダクトのふるまいからフィードバックを受けやすくなる。
売上予測アプリケーション
売上予測アプリケーションを用いて、具体的な中身について確認する。 サンプルアプリケーションの説明をすると、教師あり学習によって生成したモデルとwebアプリケーションのコードを組み合わせた機械学習アプリケーションになっている。
データやコードの概念図は下記のようになっている。
画面としてはこのような形になると考えていただきたい。
一般的な課題
この手の話をするとき、一般的に２つ大きな課題に直面することが多い。
まず、一つには組織構造の壁である。
サンプルアプリケーションにおける職種毎の担当範囲は下記のようになる。
このとき、データエンジニアはデータへのアクセシビリティを重要視するが、データサイエンティストは機械学習の精度を向上させることを重視する。機械学習エンジニアやエンジニアはプロダクトとしてどうやってそれらの結果を統合するかに集中する。
こういった、目的の違いはしばしば遅延や摩擦のもとになる。 わかりやすい現象としては、試験的には動いていたシステムが、いざ本番リリースしようとすると稼働しないという事態が発生する。
組織構造については、技術的な問題ではないので、今回は対象外とする。
２つ目の課題としては、バージョン管理しきれない物事を取り扱うことに起因するどうやって再構築・監査可能なシステムにするかという問題がある。
CD4MLの技術的要素
ここでは、データアナリストやデータサイエンティストが探索的データ分析(EDA)によって、データの形状や傾向などを見極める段階について考える。 この段階では、とにかくデータへアクセスでき、情報を引き出せることが最重要となる。
データへのアクセシビリティ
データサイエンティストが高精度のモデルを構築するためには、データへのアクセシビリティは非常に重要なポイントになる。 一般的なデータへのアクセシビリティを高める形式としては、データレイクやデータウェアハウス、ストリーム形式のデータ、最近ではデータメッシュの形式でデータを収集するとアクセシビリティが高いとされている。
データへのアクセシビリティが悪いほど、良質なモデルを構築するのに時間を要するので、エンジニアは入力データの管理には気を配られたし。
実際には、データ元は複数あったりして、複雑なデータパイプラインが必要な場合がある。 今回の事例では、テーブルの正規化等は行わず、単一のCSVファイルで対応できたとして話を進める。 こうしたファイルに対して、クレンジング処理を施したあと、Amazon S3やGoogle Cloud Strage、Azure Storage に配置することを想定する。
再現性のあるモデル構築
データへアクセスする環境ができあがったら、データサイエンスの作業に移る。 データを学習データと検証データに分割し、アルゴリズムを適用してハイパーパラメータを調整する。 検証データを用いて、学習させたモデルを評価し、精度を上げていく。 こうした機械学習パイプラインが形成されていく。
今回の売上予測の機械学習パイプラインを下記に示す。
この事例では、入力データ、中間データ、出力データの3段階に分けられ、更にモデルまで含めるとデータ量は膨大となる。 そのため、ソースのバージョン管理は困難になる。
また、どの段階でもデータは絶えず変化し続けるので、再現性は非常に難しい問題になる。
この問題に対しては、DVC (Data Science Version Control)を導入することが有望となる。 これは、Gitのような機能に加えてデータサイエンス特有の機能を備える。
- バックエンドを複数完備し、大きなファイルをリポジトリの外部ストレージに配備可能
- データが変化した場合にも、ファイルのバージョンを管理しモデルを維持可能
- 依存関係を分析し、異なる環境での再現性を可能にする
- ブランチを切ることで、様々な検証を可能にする
他にもPachydermでは、コンテナを使うことでこの問題に対応できるし、MLFlowのようにファイルフォーマットを定義することでローカル・リモートで実行可能にすることが可能である。
モデル配信
良さそうなモデルが見つかったら、プロダクトへの提供方法を考える必要がある。
学習結果の配信パターンは大きく３パターン考えられる。
- モデルをシステムに組み込む
- プロダクト配信のコードとモデルのセットでプロダクトとみなす
- サービスとモデルを切離して提供する
- モデルが分離されているので、管理は簡単だが、配信が遅くなる
- モデル自体を配信する
- ストリームやリアルタイムデータを使用するときなどに適する
今回の例では、最も単純な組み込みの方法を採用する。モデルの管理にはpickleを使用して保存・管理する。 Dockerで同じコンテナ上から、モデルをpullして使用する。
pickleの他にもMLeap、PMML、PFA、ONNXなどの選択肢もある。
別のアプローチとして、H2OではJARファイルであるPOJOを出力して管理できるので、JVM上で使用できるモデルにすることができる。
クラウドサービスのMLaaSを使用する方法もある。 KubeFlowなどを使用することでモデル配信の問題を解決できる事がある。 その他、MLFlow Modelなどもモデル管理に取り組んでいる。
いずれの方法にせよ、データ形式など、制約事項には留意されたし。
機械学習における品質とテスト
機械学習におけるテストには下記のように複数ある。
- Validating Data
- インプットデータが期待したもの(スキーマの構造、値の範囲など)になっているか検証するテスト
- Validating component integration
- モデルのデータ形式が異なっても、出力が同じであることを確認するテスト
- Validating the model quality
- モデルの評価(しきい値やラチェット)
- Validating model bias and fairness
- 特定のバイアスにかかっていないかのテスト
仮に同じデータを使用していたとしても、過学習の恐れがある。 また、新しく追加されたデータセットによってモデルの精度が低下することもある。
また、他のアプリケーションとモデルの共有を行っていた場合などには、モデルの改変によってシステム自体の挙動がおかしくなることが考えられる。
このように様々な観点でテストを継続的に行う必要がある。 システム全体としてのテストを採光し直すと下記のような階層関係になると考えられる。
検証のトラッキング
機械学習システムの構築のような、実験的アプローチを取る場合には、大量の検証が必要になる。 そして、それらを比較してより良いモデルを選定する必要がある。
そのためには、検証のトラッキングが必要になる。 特に、検証を自動化する観点では、多数のモデルを検証し、その時の評価を収集して最良のモデルを次のステージに進めるアプローチを推奨する。
MLFlowを使用する場合には、検証を簡単に行う機能が提供されており、下記のような画面を使用して検証をおこなうことが可能になっている。
モデルのデプロイ
今回はモデルは単一になるが、実際には複数のモデルをデプロイすることもある。
- 完全にモデルが分離しているデプロイ
- システムに組み込まれているデプロイ
- 複数モデルを競わせながらデプロイ
- A/Bテストなどを実施して選定
- オンライン学習
- 絶えず学習し続ける
複雑なデプロイが必要になるほど、システムパフォーマンスが重要になる。
オーケストレーション
すべての構成要素が決まったら、統合のためのパイプラインを構成する必要がある。 インフラを構築し、機械学習パイプラインを実行して学習及びメトリクスの収集を行った後、モデル毎の評価を行う。 ビルドとテスト、デプロイはデータパイプラインのために必要になる。 このように様々な統合を自動化する必要がある。
今回はGoCDというツールを使用することでそれを実現した。 GoCDパイプラインの画面は下記のようになる。
上記の例では、大きく２つのパイプラインを構築している。
- 機械学習パイプライン
- モデルの学習と評価、しきい値による検証によって、モデルを確定させるパイプライン。
- アプリケーションデプロイパイプライン
- アプリケーションコードをビルドおよびテストするパイプライン
また、モデルを選定したあとに、精度が低かった際にはそれを切り戻しする機能も必要になる。
モデルモニタリングと可観測性
モデルが正しく稼働したら、その性能を理解し、適切にフィードバックしていくことが求められる。
監視項目としては下記のようなものが挙げられる。
- モデルの入力
- モデルの中間生成物
- モデルの出力と最終的な決定
- ユーザの行動、反応
- モデルの公平性
今回の事例では
- ElasticSearch
- Fluentd
- Kibana
を使用して、ログとしてモニタリング内容の監視を行っている。 下記はその時のKibanaの画面である。
結論
機械学習システムでは、通常のシステムに加え、データやモデルの変化を考慮したCDを行うことが望ましい。 今回は、機械学習システム向けのCD手法で、機械学習システムの信頼性と信頼性向上を目指しCD4MLを提案した。
多分全体像としてはこんな感じ。
(出典：https://www.thoughtworks.com/insights/articles/intelligent-enterprise-series-cd4ml )
感想
久しぶりに英語読んだのもありますが、ソフトウェア工学関係の記事はいつもと勝手が違って読みにくかったです。 それでもずっと興味あった分野なので面白かったです。
