Machine Learning Design Patternsの要約と実務経験からの感想

この記事は？

Machine Learning Design Patternsを読んで内容を要約しました。そのあと、実務でデータサイエンスをしている経験から何か面白いことを書こうと思います。

Machine Learning Design Patternsの概要

章立てとしては、全八章あり、第一章で概要、第二章~第七章で用途別のデザインパターンの紹介、第八章でMLOps総論を述べています。著者のおすすめする読み方は、頭から全部読むのではなく、先に第一、八章を読んでから興味のある章を深読みしてほしいとのことでした。ですので、先に第八章から読んでいきます。

Capter8

MLプロジェクトのパターン

MLのライフサイクル

MLのライフサイクルをDiscovery, Development, Deploymentに分けて考える。

Discovery

ビジネスユースケースの定義、データ探索のステップに当たる。

ビジネスユースケースの定義

  • 立場によって成功の定義が異なるので、評価指標を明確にすることが大事。(Chapter1)
  • ビジネスインパクトを考えるには、従来のシステムをベンチマークにすべき。（Chapter7）

    データ探索

  • データ品質が十分かどうか確かめるため、さまざま図を描き、統計量を確認する。

Development

データ探索、アルゴリズム選択、データパイプライン特徴量エンジニアリング、MLモデル作成、評価、結果プレゼンのステップに対応する。

アルゴリズム選択

データパイプライン特徴量エンジニアリング

  • 特徴量エンジニアリングパイプラインが必要であり、データ表現のデザインパターンはChapter2に詳細がある。
  • パイプラインで保証するMLシステムの再現性とレジリエンスはCapter5とChapter6にある。

モデル作成

  • MLワークフローのベストプラクティスに従うべし。（Chapter6）
  • 典型的なモデルトレーニングのループはCapter4で解説されている。
  • モデルの開発は反復的なものである。このときの再現性を確保するデザインパターンはChapter6にある。

結果のプレゼン

Deployment

デプロイ計画、モデルを運用可能にする、モデルをモニターするステップを含む。

デプロイ計画

  • MLモデルを運用化するときに直面する問題のためのデザインパターンはChapter5で触れられている。

モデルを運用可能にする（MLOps）

  • ワークフロー実行を自動化する。例えば、Kubeflowなどは、UberのMichelangeloやGoogleのTFXで使われている。
  • CI/CDの恩恵はMLモデルにもある。例えば、モデルが更新されるたびに、データクリーニング、バージョニング、データパイプラインのオーケストレーションが行われる。

モデルのモニター

  • モデルは様々な要因で劣化する。継続的なモデルの性能のモニターが必要だが、Chapter5で詳しく議論されている。

AIへの準備レベル

Googleのホワイトペーパーによると、企業のAIへの準備レベルは3段階に分かれる。戦術的、戦略的、適応的である。

戦術的フェイズ：手動デプロイ

  • ビジネスゴールが明確でないPoC段階によく見られる。
  • データは手動でアクセスされ、自動化されたML開発サイクルもない。
  • MLOpsはモデルリポジトリに制限され、テストと商用環境の差はほとんどない。

戦略的フェイズ：パイプラインの活用

  • ビジネス目標と優先度に沿っており、シニアエグゼクティブの助力がある。
  • 開発環境と商用環境の明確な違いがある。
  • モデル開発はきちんと管理された実験であり、組織内で共有されている。
  • データパイプラインはスケジュールに基づいて自動実行される。

適応的フェイズ：完全自動化処理

  • AIはイノベーションを促進し、アジリティを支援し、実験と学習の文化を培う。
  • Chapter5とChpter6の再現性とレジリエンスのデザインパターンが関連する。
  • プロダクトごとにAIチームが存在し、横断的な先進分析チームから支援される。
  • データセットはすべてのチームからアクセスでき、再利用できる。
  • MLパイプラインは自動化され、組織の誰でもアクセスできる。

感想

以下は個人の感想です。不確実な情報が含まれています。鵜呑みにしないでください。

弊社のAIへの準備レベル

弊社の情報

  • コンサル会社で、クライアントから依頼を受けてデータ分析をします。ので、プロダクトとかはないです。
  • 分析案件の大部分は、基礎分析して示唆を出して施策考える系の分析。この種類の案件には、定期的なモデル運用は含まれていない。

弊社のAIへの準備レベル

戦略的フェイズではあるが、大規模には活用されていない状態だと思います。

  • 定期的なモデル運用を含む案件に関しては、運用までのパイプラインは整備されている。分析チームがプロトタイプ開発をした後、運用チームがAirflowで定期バッチ組むという流れです。
  • 上記の通りモデル運用まで行われない案件が多数なので、大規模には活用されていない。

弊社の適応的フェイズとは

こんな風になったらいいなという感想。

  • 各プロジェクトの分析内容が、社内のだれでもトレースできる。さらに、その分析に対して気軽にコミットできる。（特徴量追加してみたら性能上がったよとか、こっちのアルゴリズム使ってみたら学習時間短くなったよとか）
  • プロジェクトを横断的に見て、全体の分析レベルを上げる組織がある。
  • 分析チームと運用チームが分かれるのでなく、ひとつのチームで分析から運用まで全部やる。それにより、コミュニケーションコストが下がり、アジリティが上がる。そのために、全自動パイプラインにより、運用の属人化を防がなくてなならない。

  • むしろプロダクト開発側のチームとも一体になる。どのような分析で価値を出すかという観点も含めてプロダクトをデザインする。DataMesh構造を作る。 watanta.hatenablog.com

  • ...とはいえ、そもそもモデル運用しない案件が今は多数なので、効果は限定的な気がする。

この本の重点的に読みたい点

  • 各プロジェクトの分析内容が、社内のだれでもトレースできる。さらに、その分析に対して気軽にコミットできる。

特にこの世界実現したいですよね。各プロジェクトのモデルがKaggleコンペになるようなのができたらすごく面白そう。ビジネス得意な人はクライアントと相対して、案件全体の分析設計する人がいて、モデリングは社内に任せるみたいな。で、一番性能出せた人はボーナスもらえるんですよ。絶対面白いでしょ。

このためには、分析内容がノーコストで再現できないといけないですよね。Chapter5とChpter6に書かれてるようなので、ここから読みたいと思います。