機械学習プロジェクトにおける本番環境レベルのガバナンスの実現は、現在、特有の課題を抱えています。MLOpsという名称で、新たなツールとプラクティスの領域が出現しつつあります。この領域はDevOpsに類似していますが、機械学習のプラクティスとワークフローに合わせてカスタマイズされています。
MLOps が必要な理由
機械学習モデルは、学習済みのデータに基づいて新しいデータの予測を行います。このデータを実環境で安全に使用できるように管理することは困難であり、ガートナーの推定によると、データサイエンスプロジェクトの80%が本番環境に移行しない主な理由の一つとなっています。
データはクリーンで正確であり、プライバシーやバイアスの問題がなく安全に使用できることが不可欠です。また、現実世界のデータは絶えず変化するため、入力データと予測データを監視し、モデルに問題を引き起こす可能性のある変化がないか確認する必要があります。これらは、従来のDevOpsとは異なる複雑な課題です。
MLOps は DevOps だけではない
DevOpsの実践は、「ビルドとリリース」プロセスと継続的インテグレーションを中心としています。従来の開発ビルドは、ソースコードからコンパイルされた実行可能な成果物のパッケージです。これらのビルドに含まれる非コードサポートデータは、比較的小さな静的な設定ファイルに限定される傾向があります。本質的に、従来のDevOpsは、特定の入力に応じて特定の出力を生成する、明示的に定義された一連のルールで構成されるプログラムの構築に重点を置いています。
対照的に、機械学習モデルは、すべてのルールを定式化するのではなく、データから間接的にパターンを捉えることで予測を行います。機械学習の特徴的な問題の一つは、既知のデータに基づいて新たな予測を行うことです。例えば、既知の住宅価格と寝室数、面積、所在地などの詳細情報を用いて住宅価格を予測するといったことが挙げられます。機械学習ビルドでは、データからパターンを抽出し、重み付けされた機械学習モデル成果物を作成するパイプラインを実行します。これにより、これらのビルドははるかに複雑になり、データサイエンスワークフロー全体がより実験的なものになります。結果として、MLOpsの課題の重要な部分は、大量のデータとさまざまなパラメータを伴う多段階の機械学習モデルビルドをサポートすることにあります。
プロジェクトを本番環境で安全に実行するには、問題発生状況を監視し、問題が発生した際に適切な修正方法を把握できる必要があります。コードビルドを記録して古いバージョンに戻す方法については、DevOps の標準的なプラクティスが存在します。しかし、MLOps では、あるバージョンのモデルをトレーニングするために使用されたデータを記録し、それに戻る方法についてはまだ標準化されていません。
実稼働環境では、MLOps特有の課題にも直面します。エラーコードやレイテンシーの増加を監視するためのDevOpsアプローチは、広く認められています。しかし、予測の誤りを監視するのは別の課題です。予測の正確性を直接的に判断する方法がない場合があり、代わりに顧客の行動（コンバージョン、サイトを離脱する顧客の割合、送信されたフィードバック）などの間接的なシグナルを監視する必要があるかもしれません。また、トレーニングデータが実稼働データをどの程度正確に反映しているかを事前に把握することも困難です。例えば、全体的なレベルではよく一致しているかもしれませんが、特定の種類の例外が発生する可能性があります。このリスクは、新バージョンのロールアウトを注意深く監視し、慎重に管理することで軽減できます。
MLOpsツールシーン
MLOpsの課題解決にかかる労力は、プラットフォームを活用し、特定のケースに適用することで軽減できます。多くの組織は、既製の機械学習プラットフォームを使用するか、オープンソースのコンポーネントを組み合わせて自社プラットフォームを構築するかという選択に直面しています。
AWS SageMakerやAzureMLなど、一部の機械学習プラットフォームはクラウドプロバイダーのサービスに含まれています。これは、組織のクラウド戦略に応じて魅力的かどうかが変わります。他のプラットフォームはクラウドに特化されておらず、セルフインストールまたはカスタムホストソリューションを提供しています（例：Databricks MLflow）。
組織は、プラットフォームを選択する代わりに、独自のプラットフォームを構築するという選択肢もあります。これは、他の社内システムとの統合が必要な場合や、データを特定の場所や形式で保存する必要がある場合など、要件がニッチすぎて既存のプラットフォームに適合しない場合に好ましい選択肢となる可能性があります。社内プラットフォームを構築することを選択するには、MLツールの環境をうまく利用する方法を学ぶ必要があります。この環境は複雑で、様々なニッチに特化したツールが存在し、場合によっては、同様の問題に異なる方法でアプローチする競合ツールが存在することもあります（Linux FoundationのLF AIプロジェクトの視覚化、またはInstitute for Ethical AIの分類リストをご覧ください）。
Linux Foundation の MLOps ツールの図 ... クリックして詳細を表示
Kubernetesを利用する組織にとって、kubeflowプロジェクトは興味深い選択肢となります。このプロジェクトは、オープンソースツール群をキュレートし、それらをKubernetes上で連携させることを目指しています。このプロジェクトはGoogleが主導しており、IBMが挙げている主要コントリビューターには、IBM、Cisco、Caicloud、Amazon、Microsoftに加え、MLツールプロバイダーのSeldon、中国のテクノロジー大手NetEase、日本のテクノロジーコングロマリットNTT、ハードウェア大手のIntelなどが名を連ねています。
ガバナンス
機械学習システムの再現性と監視に関する課題は、ガバナンス上の問題です。本番環境の維持管理を確実に行い、監査人や顧客からの異議申し立てにも対応できるようにするためには、これらの課題に対処する必要があります。多くのプロジェクトでは、顧客が自分に関する予測がなぜ行われたのかを尋ねることを当然期待しているため、これらの課題だけが課題となるわけではありません。場合によっては、欧州連合（EU）の一般データ保護規則（GDPR）において、「データ主体」は自身に関連するあらゆる自動化された意思決定における「関連するロジックに関する有意義な情報」を得る権利を有すると規定されているため、これは法的要件となることもあります。
説明可能性は、それ自体がデータサイエンスの課題です。モデリング手法は、その手法を自然に検証して特定の予測の理由に関する洞察を提供できるかどうかによって、「ブラックボックス」と「ホワイトボックス」に分けられます。独自のニューラルネットワークなどのブラックボックスモデルでは、結果を解釈するための選択肢は、ホワイトボックスの線形モデルを解釈するための選択肢よりも制限され、使いにくくなります。規制の厳しい業界では、説明可能性をサポートせずにAIプロジェクトを前進させることは不可能です。例えば、医療診断システムは、問題が発生したときに調査できるように、またはモデルが人間の医師を支援できるように、高度な解釈可能性が求められる場合があります。これは、プロジェクトが許容できる解釈可能性を許容するモデルの使用に制限されることを意味する場合があります。ブラックボックスモデルの解釈可能性を高めることは急成長分野であり、新しい手法が急速に利用可能になっています。
機械学習の普及が進むにつれ、MLOps の分野も進化しており、様々なユースケースにおけるベストプラクティスについて理解が深まっています。組織によって機械学習のユースケースは異なり、ニーズも異なります。この分野が進化するにつれて、標準化が進み、より高度なユースケースにも対応できるようになるでしょう。®
さらに詳しく知りたいですか?
ライアン・ドーソンは、Seldonオープンソースチームのコアメンバーであり、Kubernetesへの機械学習デプロイメント用ツールを提供しています。彼はロンドンのJava開発現場で10年間、様々な業界で活躍してきました。
DevOpsの原則を機械学習に適用すると、ワークフローやアーティファクトが大きく異なるなど、いくつかの特有の課題が生じます。ライアンは、 The Registerの母体であるSituation Publishingが主催するカンファレンス「Continuous Lifecycle London 2020」で、5月にこのトピックについて詳しく解説します。
詳細の確認とチケットの予約は、こちらから行えます。
