Gonfalonieri氏が経験したところによれば、データサイエンティストがPoC段階の機械学習モデルを開発したものも、本番環境への実装に手間取ったり失敗して放棄されたりするケースが後を絶ちません。こうした失敗事例が生じるのは、機械学習モデルの開発ばかりに注目して、本番環境への実装や実装後のメンテナンスを考慮しないプロジェクト計画の不備にある、と同氏は指摘します。
以上のような問題に対処するために、MLOpsの活用をGonfalonieri氏は推奨しています。というのも、MLOpsは機械学習モデルの実装やバージョン管理をサポートしているからです。さらには機械学習プロジェクトにおいて大きな労力が費やされるデータの収集と管理も、MLOpsを活用することで効率化できます。
Gonfalonieri氏は、機械学習モデルを実装するための戒めとして「モデルをただ漠然と本番環境に投入しない」とも述べて、開発から実装、そして監視にいたるまで計画的に遂行することの重要性を強調しています。
なお、以下の記事本文はAlexandre Gonfalonieri氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。また、翻訳記事の内容は同氏の見解であり、特定の国や地域ならびに組織や団体を代表するものではなく、翻訳者およびAINOW編集部の主義主張を表明したものでもありません。
画像出典：UnsplashのMcDobbie Huより
目次
MLモデルをより速く実装し、新たな競争的優位を生み出すためのショートガイド
さまざまなAIプロジェクトを経験するなかで、効率的な機械学習（ML）モデルの構築と実装が、いかに早く競争的優位の源泉となり得るかを私は実感してきた。データ収集にとどまらず、既存の技術スタックのなかでモデルを構築、実装、デバッグするライフサイクル全体を管理することは、一筋縄ではいかず、予想外の課題を生むことを意思決定者は学びつつある。
私の経験では、データサイエンティストはデータセットの分析に時間をかけ、それから適切なアルゴリズムを探し、新しいモデルを訓練し、それをデータエンジニアに渡して本番で実行させることがよくある。
このような状況では、データサイエンティストは本番環境でモデルを実行する際の課題に気付かず、データエンジニアはモデルがどのように構成されているかを知らないという問題が発生する可能性がある。私は、データサイエンティストが本番環境ではスケールしないアプリケーションを書いているのを何度も見てきた。
データエンジニアがいないような小さな会社では、MLモデルの実装はなおさら難しいだろう。その結果、ML実装パイプラインがうまく構築されないために、MLモデルを更新し続け、本番環境で確実に動作させらないという問題が発生する。
機械学習やディープラーニングのプロジェクトのうち、本番環境に移行できるのは、実装の複雑さ、ガバナンスツールの欠如、データの問題などから、ごく一部に限られている（※訳註1）。
KDnuggetsは機械学習プロジェクトに関する3つの質問のオンライン回答を募ったところ、114人のデータサイエンティストから回答を得られた。1つ目の「機械学習モデルのうち、何パーセントが実際に実装されたか」という質問に対し、最も多かった回答は「0～20%」で58%であった（以下のグラフを参照）。
2つ目の「機械学習モデルが完成しない原因は何か」について質問したところ、1位は「技術的な問題」で35%、2位が「既存業務を変更したくない」が32%であった（以下のグラフ参照）。1位の原因に関してKDnuggetsの記事では、技術的な問題の内実は機械学習プロジェクトにおけるリーダーシップの欠如に起因していることが多い、と指摘している。
なお、以上のグラフはKDnuggetsの発表にもとづいて翻訳者が作成した。
MLモデルを本番稼動させる
私は、多くの企業が明確に定義された製品化計画なしにAIプロジェクトを開始することに気づいた。多くの場合、誰も概念実証の後に何が起こるかを本気で考えていない。このような戦略の欠如は、チームがモデルを本番環境に統合しなければならない時に、しばしば重大な問題を引き起こす。
会社の規模、AIプロジェクトの管理経験、予算、チームによっては、意思決定者が生産性や拡張性を考えずに、概念実証を行うためのモデルの訓練のみに集中するのを決定することがある。
このような場合、データサイエンスチームはモデルをAPIでラップして本番環境に直接出荷することを決定するかも知れない。しかし、こうした場合、本番環境でモデルを更新しデバッグするためのスケーラブルで再現可能な計画が欠けている。それゆえ、エンジニアはシステムを確実に実行するのに苦労した結果、継続的なサポートコストが高くなる可能性がある。
機械学習のライフサイクルには自動化されたタスクが不足しているため、特注のデータパイプラインと、各モデル用の実装環境だけがモデルに残されて終わってしまうことも多い。
以上のように（モデル開発から本番環境への実装までの）一貫した方法論がないため、プロジェクトが断片化することによってエコシステムを改善するためのコストが高くなり、開発が遅くなってしまう。さらに、チームは自分たちの好みの言語（多くの場合RやPython）でモデルを作成し、（Java／Sparkなどで構築された）本番フレームワークで実行するために別の言語に書き換えていることもよくある。
また、MLモデルはデータセット、パラメータ、ハイパーパラメータなどのいくつかの要素で構成されている。これらの構成要素は再現性を確保するために、開発パイプラインを通じて慎重に保管され、バージョン管理される必要がある。
MLモデルをより速く本番環境に導入するためにできること
MLOpsは、機械学習におけるホットトピックだ。MLOpsを要約すると、MLモデルを継続的に開発し、迅速に実装するためのコラボレーション環境を構築しながら、ほとんどのデータサイエンス・タスクを標準化・自動化しようとするロジカルな方法論である。
MLOpsは、あらゆるオープンソース言語で書かれたモデルを簡単に実装し、リアルタイム予測をサポートするために本番品質のREST APIが使える。ソフトウェア工学においてもよく知られているDevOpsのように、（MLOpsに至る）同様の変遷を遂げてきた。
MLops ソリューションを活用して成功している企業は、似たようなベストプラクティスを採用している。これらのプラクティスにはデータ準備／訓練のための標準化された中央パイプラインと、将来の実装のためにアップデート可能で再現可能なワークフローが含まれる。
MLOpsの次に大事なのはモデル管理ソリューションであり、これはさまざまな測定基準で異なるモデルや新しいモデルを簡単に比較できるようにする。最後に挙げるべきはMLOpsフローであり、これはデータとMLアプリケーションの継続的インテグレーションとデリバリー（CI/CD）をベースとしており、TorchやTensorflowなど、企業で使用されているすべてのフレームワークをサポートしている。
さらに一歩進むために考慮すべき要素の一覧：
- アルゴリズム、学習済みモデル、データセット、メタデータ、および使用するハイパーパラメータをすべて追跡するためのバージョン管理。コンテナ（Docker、Kubernetesなど）はモデルを分離してバージョン管理するのに最適な方法なので、コンテナの使用を検討しよう。
- 手動または一貫性のないプロセスに依存しないようにするための自動的なセーフガード。
- （すぐにでも製品化できる）プロダクションレディ（production-ready）なモデルを保存でき、アノテーション、管理もできるセントラルレポジトリのあるモデルレポジトリの用意。この要素は、データサイエンスチームの立ち上げにも関連する。私が気づいたのは、社員が入社してプロジェクトを見て、誰がそのプロジェクトに取り組んでいるのか、データがどこにあるのかを特定することがいかに難しいことであった。
- コンピュータビジョンのプロジェクトでは、事前学習済みモデルを持つAIツールキットの使用を検討してもよいだろう。具体的には、自分のデータを持ち込んで、特定のユースケース向けに事前学習済みモデルをファインチューニングできる。例えば、一般的なAIタスクのためにNVIDIAの多目的かつ製品品質のモデルの1つを使用したり、ResNet、VGG、FasterRCNN、RetinaNet、YOLOv3/v4などのニューラルネットワークアーキテクチャの100以上の組み合わせのうちのひとつを使用したりできるだろう。
- リソース管理（GPU/CPU）を監視するためのダッシュボード
- 導入したモデルのパフォーマンスを監視し、新しいモデルのパフォーマンスが低下した場合のロールバックまでの自動化。多くのモデルは、時間の経過とともに性能が低下するドリフトを経験する（※訳註2）。導入されたモデルは監視され、再フィットさせる必要がある。各実装モデルは、すべての入力、出力、および例外を記録する必要がある。
- モデル構築者には、社内のモデルガバナンスプロセスで承認されたモデルを自分たちで実装する方法を提供する。
- 本番環境に導入する前に、MLモデルのテストとデバッグを行うための開発環境を準備する。
- 本番環境でさまざまなハイパーパラメータの組み合わせをテストするための融通の利くクラスタの用意。
これらの要素は、読者諸氏の会社が多くの反復タスクを処理するのに役立ち、リリースサイクルの高速化につながるだろう。MLOpsの恩恵を受けられるML開発ライフサイクルのもうひとつの本質的な側面とは何か。それはデータだ。
データの問題
MLプロジェクトに詳しい読者ならご存知かも知れないが、手作業によるデータの準備とラングリング（※訳註3）は、MLプロジェクトに費やされる時間の80%にも及ぶ。
データサイエンティストは、この時間を短縮するために、データラングリング、準備、プロトタイピング、可視化のためのツールを必要としている。MLOpsパイプラインを活用することで、データサイエンスチームはこれらのタスクをより速く、より効率的に達成できる。高度なMLOpsソリューションは、データの選択とアノテーションからモデルの最適化までMLプロジェクトをサポートできる。
コンピュータビジョンのプロジェクトでは、このデータ最適化の必要性が非常に重要となる。一部の企業は、MLOpsパイプラインと学習データの最適化に関する独自の専門知識を導入している。
新しいデータの選択、アノテーション、そしてモデルの監視まで、学習データのワークフロー全体をアウトソーシングするエンドツーエンドの学習データプラットフォームを構築している企業もある。こうした企業では、データサイエンティストはモデルの選択と評価に集中できる。
いくつかのエッジケースでは、高い精度が要求されるため、実運用に入る前に対処する必要がある。一部のプラットフォームでは、タスクに存在する可能性のあるあらゆる種類のエラーを予測し、アノテーションプロセスが始まる前にそれに数値的なペナルティ値を割り当てることで、エッジケースを予見的に識別している。この予見的なアプローチにより、データサイエンスチームは包括的で実行可能な指示を出せるようになって、本番環境に早く到達できるようになる。
さらにデータサイエンスチームは、最初のガイドラインにもとづいたサンプル結果を継続的に受け取るべきである。そうすることで、どのデータにアノテーションを施すべきかについて優先順位をつけて目標を定め、繰り返し指示を出すことでより迅速なモデル開発を行えるようになる。
実装戦略
最後になるが、私は企業がモデルをただ漠然と本番環境に投入しないことを強くおすすめする。企業は、AIベースのソリューションを展開するさまざまな方法を模索する必要がある。Christopher Samiullah（※訳註4）が述べたような「シャドーモード」と「カナリア」の実装は、MLアプリケーションに特に有効だ。「シャドーモード」においては、本番環境に実際には投入しないで、製品化した新しいモデルに対する入力とそのモデルが出力する予測を把握できる。このモードでは実装しない代わりに、バグが検出されても大きな影響を受けることなく、自由に結果を分析できる。
MLプロジェクトは、もはやデータサイエンスだけにもとづくものではない。それは、目標（例：許容できる精度レベルなど）を明確に定義し、アジャイルな方法論（例：正しいアルゴリズム、モデル、精度を見つけるまで反復し続ける）を完全に取り入れることから始まるのだ。
企業は、モデルを本番稼働させるまでに必要な時間を真剣に考慮する必要がある。競合他社は、モデルをより早く、より効率的に本番稼働させることで競争的優位を得られるのだ。
また、本番稼働後はモデルの精度が保たれていることを確認する必要がある。実装されたモデルの監視はモデルのパフォーマンスに関して悪い驚きをもたらし、その驚きによってモデルの再訓練（例えば、コンセプトドリフト）が必要になるかも知れない。
もし、この記事や私の文章全般を気に入っていただけたなら、こちらの参照リンクからMediumにサインアップして、私の執筆活動をサポートすることを検討して頂ければ幸いです。ありがとうございました。
原文
『How to Bring Your ML Models to Production Faster』
著者
Alexandre Gonfalonieri
翻訳
吉本幸記（フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得）
編集
おざけん
