55
62

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

[MLOps Tips] 社会実装・業務適用に向けた機械学習プロジェクトの進め方

Posted at

はじめに

  • 昨今、様々な機械学習(深層学習を含む。以降、ML)の手法が提案されるとともに、社会実装や業務適用に向けたプロジェクトが開始されています。
  • しかし、現実問題をMLで解き、社会的・実務上の価値に繋げることは容易ではなく、多くのプロジェクトがPoC(Proof of Concept, 技術の概念検証)で止まっています。(PoC疲れ、PoC地獄、PoC貧乏といった単語すら登場しています...)
  • ここ数年で多くのPoCが行われた結果、様々な反省点や改善手法が提案されてきており、本記事では、特に有意義だった下記の2論文+個人的な経験を踏まえて、社会実装・業務適用に向けた機械学習プロジェクトの進め方について、まとめてみたいと思います。

参考文献

Using AntiPatterns to avoid MLOps Mistakes

How to avoid machine learning pitfalls

MLプロジェクトの全体像

  • MLプロジェクトは以下のフェーズで進められます。
  • また、各フェーズごとのポイントを箇条書きで示しています。

image.png

  • 以降ではまず、MLプロジェクトの一般的な失敗理由を整理したのち、それらを回避するためのTipsをフェーズごとにまとめます。

MLプロジェクトの失敗理由

  • MLプロジェクトが失敗する理由は様々ですが、技術的・プロジェクト管理上の問題では以下の3要因が代表的だと思います。(組織起因の事情は除く)
  1. パフォーマンスの問題:MLモデルのパフォーマンスが目標値に達しない。特に、開発環境(訓練データ)では上手くいくが、本番環境(テストデータ)ではパフォーマンスが向上しない。
  2. 作業効率の問題:MLモデル開発に想定以上の工数がかかっている。
  3. 安定性・再現性の問題:MLモデルの予測結果のパフォーマンスが不安定であったり、再現性が担保できず、結果の信頼性に問題がある。
  • 次に上記の失敗を避けるために必要な注意点をフェーズごとにMLOPs Tipsとして整理していきます。

MLOPs Tips

1. 設計フェーズ

1-1. 問題設定について考え尽くす・関係者と議論を尽くす

  • MLで解こうとする問題が本当に値する問題なのかよく議論・検討する
  • その問題を解くのに本当にMLが必要なのか考える
  • その問題を解くために十分なデータが存在するのか確認する

1-2. ドメインの専門家との会話する

  • 専門家(例:対象の問題を有する業務に長年携わる担当者)は多くのことを知っている
  • 当該問題をMLで解決することによる価値をレビューしてもらう必要がある
  • また外部からは見えない背景事情や制約条件が存在することが多々ある

1-3. 先行研究をよく調査する

  • 多くの問題は類似研究が先行研究として存在している
    (完全に同一テーマである研究は存在しなかったとしても、抽象化すれば同じ研究は多く存在する)
  • その研究結果について深く調査を行い、実現可能性を熟考する
  • また新たに提案された手法について注視する必要があり、特定の条件や環境でのみ高いパフォーマンスが発揮されるだけの可能性が高い(近年、先行研究の欠陥を指摘する論文も登場している)

1-4. 目標値と制約条件を設計する

  • 価値創出につながる目標値を適切に設計する(過度に高い目標はその実現も困難であり、本当に必要なのか考える)
  • 業務上の制約条件だけでなく、運用システム上の制約条件も含めて情報を整理する
  • 上記が整理された状態で真にMLプロジェクトとして推進すべきが判断を行う

1-5. モデル開発におけるデータ設計を行う

  • MLモデルの開発を行うにあたっての訓練・バリデーション・テストデータの分割設計を行う
  • 得に、テストデータの管理については慎重に行う必要があり、テストデータの情報が暗にモデル開発者に伝わることは、モデルの汎化性能の評価に問題を引き起こす(Data leakage 問題)
  • 必要に応じて、モデル開発者と評価者を体制上分離するガバナンスの設計も必要になる

2. 実装

2-1. データに対する深い理解を行う(EDA)

  • データからルールを学習するMLプロジェクトについては、取り扱うデータの質については十分に注意を払う必要がある
  • 悪いデータで学習したしたモデルは悪いモデルとなる
  • 遅かれ早かれこの作業は必要になるので、モデル構築前に行った方がスムーズである
  • この際にテストデータについてはEDAを行なってはならない(テストデータの情報漏洩につながる)

2-2. 小さく・シンプルなモデルから開始する(KISSの原則)

  • 昨今、フレームワークの普及により複雑なモデルでも簡単に構築できる様になっている
  • しかし、複雑なモデルはその複雑性に至った背景理由が存在しており、無闇に複雑なモデルから開始することが多くの問題を引き起こす
  • 挙動の理解しやすく、開発効率も高い小さくシンプルなモデルから開始して徐々に複雑なモデルに発展させていく必要がある
  • また、古典的な確立したモデルは最新モデルより十分に機能することもある

2-3. モデル管理を徹底する(No free lunch 定理)

  • 一般的に、常にベストのMLモデルというものは存在しません(No Free Lunch定理)
  • そのため、問題設定によっては複数のモデルを利用する必要があり、それらを適切に管理する仕組みの構築が必要である

2-4. ハイパーパラメータ管理を徹底する

  • 多くのモデルにはハイパーパラメータがあり、その調整はモデルの性能に大きな影響を与える
  • 一方で、一般的に常に最適なハイパーパラメーターは存在せず、状況に応じて調整する必要がある
    • そのため、運用を見据えたMLモデルでは常にデータサイエンティストがパラメーター調整する方法は非効率であり、パラメータ探索を自動化する方法を用意しておく必要がある

####2-5. 例外管理を徹底する

  • 現実のデータは想定外のデータが入力される(センサーの想定外の誤差、人間の入力ミス等)
  • 適切なアサーションをソースコード内に組み込み、想定外のデータが入った際はアラートをあげる仕組みを導入する必要がある
  • 特に複雑なパイプラインで構築されるMLモデルはアサーションがないと、想定外データが逐次的に処理されている、どこで問題が発生しているのか追跡できなくなる

2-6. 再現性の管理を徹底する

  • 結果のレポーターやトラブル時の原因追求において、再現性の担保は重要となる
  • 想定外のトラブルが発生することは止むを得ないが、その原因追求ができないことは大きな問題となる
  • MLモデルの構築時は乱数設定(乱数シードの固定)や計算サーバー側の設定を確認し、再現性に問題ないか注意する

3. 評価・レポート

3-1. 評価の前提条件を理解する

  • 評価の前提条件(特にテストデータのサンプリング条件等)を明らかにして評価指標を考察する
  • そのテストデータで評価した結果がどの程度、一般性を保証するのか注意する
  • 過度に一般化したMLモデルの結果のレポートや特定条件化だけで上手くいった結果のレポートを避ける

3-2. 複数実験と複数評価指標で評価する(パフォーマンス評価と不確実性評価)

  • MLモデルの学習には変動があるので、同一モデルでも複数回の学習を行い評価を行う(アンサンブル実験による不確実性の評価)
  • 評価指標は1つの観点しか提供しないので、複数の評価指標を用意して総合的にモデルのパフォーマンスを評価する
  • モデルの変動性を評価するために必要に応じて統計的検定を利用する

3-3. ドキュメント化を怠らない

  • エンジニア主導のMLプロジェクトはドキュメント化を怠りがちになる
  • MLモデルの前提条件、結果・解釈、マニュアル作業等の情報を正しく文章に残す

4. 運用

4-1. MLオペレーションの業務プロセス

  • 従来に業務プロセスを見直し、Human-in-the-Loop(人とAI/MLが統合されたプロセス)のプロセスを設計する
  • 業務運用は定期的に変更や例外が発生し、それらはMLモデルに影響を与える可能性がある
  • それらの各種変更履歴(入力データや関連するヒューマンプロセスなど)を管理する方法を設計しておく

4-2. MLオペレーションのITシステム

  • モデル出力をそのまま出力するのではなく、異常な出力結果に対してはアラートをあげる仕組みを導入する
  • MLモデルのエラーが発生した際にでも運用を継続するために必要なバックアッププロセスを設計しておく
  • 開発環境と本番環境、モデルの学習環境と推論環境が異なる場合は、環境によるモデルへの影響も事前に検証を行う

4-3. MLオペレーションの運用体制

  • MLオペレーションを行うには以下の様な役割の人が必要になる
    • (i) データスチュワード(データセットの品質管理をする人)
    • (ii) モデル開発者(アルゴリズムを開発する人)
    • (iii) モデルエンジニア(モデルを本番環境に配置し、性能を評価する人)
    • (iv) 品質管理者(パフォーマンスとリスクの観点で品質保証をする人)
  • 特に、MLモデルが重要な意思決定システムに導入されるようになると、モデルの精度だけでなく、信頼性やリスクを適切に評価する品質管理者が重要になる
  • これらの関係者が円滑に議論を行なっていくためにも、適切なドキュメント化のうえでMLモデルに関する十分な理解が重要となる

さいごに

  • 本記事ではMLモデル開発における様々なポイントを整理してみました
  • 実証実験のみであれば、厳密な管理なしでも検証を突き進めることはできてしまいますが、社会実装を見据えるとなると、プロジェクト期間も長期化し、関係者も多岐に渡るので、適切な管理手法の導入が必須になるかと思います
  • 今後、MLが多くの業務で当たり前に使われるようになるにつれて、こういった方法論の重要性は更に増していくのではないかと思います
55
62
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
55
62

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?