Tan Zhongyi: モデル中心からデータ中心の MLOps により、AI をより迅速かつコスト効率よく実装できるようになります

ゲスト: Tan Zhongyi

編集者: Qianshan

Ng Enda は、AI がモデル中心の研究パラダイムからデータ中心の研究パラダイムに変化したと何度も表明しています。データは AI の実装における最大の課題です。高品質のデータ供給をどのように確保するかが重要な問題であり、この問題を解決するには、MLOps のプラクティスとツールを使用して、AI を迅速、効率的、コスト効率よく実装できるようにする必要があります。

最近、51CTO が主催する AISummit グローバル人工知能テクノロジー カンファレンスで、Open Atomic Foundation の TOC 副会長 Tan Zhongyi が基調講演「モデル中心からデータ中心へ - MLOps は AI を支援します」と述べました。これは、MLOps の定義、MLOps で解決できる問題、一般的な MLOps プロジェクト、MLOps の機能と AI チームのレベルを評価する方法を参加者と共有することに重点を置いています。 皆さんにインスピレーションを与えていただければと思い、スピーチの内容を以下のように整理しました。

モデル中心からデータ中心へ

現在、AI業界には「モデル中心からデータ中心へ」というトレンドがあります。正確にはどういう意味ですか?科学と産業からの分析から始めましょう。

AI 科学者の Andrew NG は、現在の AI 実装の鍵はデータ品質をいかに向上させるかであると分析しました。

• 業界のエンジニアやアナリストは、AI プロジェクトは失敗することが多いと報告しています。失敗の理由はさらに調査する価値があります。
• Andrew Ng はかつて「MLOps: モデル中心からデータ中心へ」というスピーチを共有し、シリコンバレーで大きな反響を呼びました。同氏は講演の中で、「AI = コードデータ」（コードにはモデルやアルゴリズムが含まれる）と考えており、コードではなくデータを改善することでAIシステムを改善すると述べた。

具体的には、モデル中心の手法が採用されています。これは、データを変更せずに、より多くのネットワーク層の使用やより多くのハイパーパラメータの調整など、モデルのアルゴリズムを継続的に調整することを意味し、データ中心の手法を使用することを意味します。つまり、モデルを変更せずに、データラベルの改善やデータ注釈の品質の向上など、データの品質を向上させます。

同じ AI の問題でも、コードを改善するのとデータを改善するのでは効果が全く異なります。

経験的証拠は、データ中心のアプローチによって精度を効果的に向上できることを示していますが、モデルの改善またはモデルの置き換えによって精度を向上できる範囲は非常に限られています。例えば、以下の鋼板の欠陥検出タスクでは、ベースラインの精度が76.2%でしたが、モデルの変更やパラメータの調整などを行っても精度はほとんど向上しませんでした。ただし、データセットの最適化により精度は 16.9% 向上しました。他のプロジェクトの経験もこれを証明しています。

# その理由は、データが想像以上に重要だからです。 「データは AI の食料である」ことは誰もが知っています。実際の AI アプリケーションでは、時間の約 80% がデータ関連コンテンツの処理に費やされ、残りの 20% がアルゴリズムの調整に使用されます。この工程は料理に似ていて、材料を準備し、さまざまな材料を加工し調整することに時間の80％が費やされますが、実際に調理するのはシェフが鍋に入れるまでの数分だけです。料理の美味しさを決める鍵は、素材とその加工にあると言えます。

Ng 氏の見解では、MLOps (つまり、「生産のための機械学習エンジニアリング」) の最も重要なタスクは、データの準備、モデルのトレーニング、オンライン モデル、モデル開発を含む、機械学習のライフ サイクルのすべての段階にあります。 . モニタリングや再トレーニングなどのさまざまな段階において、常に高品質なデータ供給が維持されます。

上記は、AI 科学者による MLOps の理解です。次に、AI エンジニアや業界アナリストからの意見をいくつか見てみましょう。

まず、業界アナリストの観点から見ると、現在の AI プロジェクトの失敗率は驚くほど高いです。 2019 年 5 月の Dimensional Research の調査では、AI プロジェクトの 78% が最終的にオンライン化されなかったことが判明し、2019 年 6 月の VentureBeat レポートでは、AI プロジェクトの 87% が実稼働環境に導入されていないことが判明しました。つまり、AI科学者やAIエンジニアは多くの仕事をしてきたものの、最終的にはビジネス価値を生み出すことはできなかったのです。

なぜこのような結果が生じるのでしょうか? 2015年に生理研で発表された論文「機械学習システムの隠れた技術的負債」では、実際のオンラインAIシステムにはデータ収集、検証、リソース管理、特徴抽出、プロセス管理、モニタリングなど多くの内容が含まれると述べられています。しかし、実際に機械学習に関連するコードは AI システム全体の 5% に過ぎず、95% はエンジニアリング関連のコンテンツとデータ関連のコンテンツです。したがって、データは最も重要であると同時に、最もエラーが発生しやすいものでもあります。

実際の AI システムに対するデータの課題は、主に次の点にあります。

• スケール: 大量のデータを読み取るのは課題です;
• 低レイテンシ: サービス提供中に高 QPS と低レイテンシの要件を満たす方法;
• データ変更はモデルの減衰を引き起こします :現実世界は常に変化しており、モデル効果の減衰にどう対処するか;
• タイムトラベル: 時系列特徴データの処理は問題を起こしやすい;
• トレーニング/サービングのスキュー: 使用されるデータトレーニングと予測が矛盾しています。

上記は、機械学習のデータに関連するいくつかの課題です。さらに、実生活では、リアルタイム データはさらに大きな課題を引き起こします。

では、企業の場合、AI を大規模に実装するにはどうすればよいでしょうか?大企業を例にとると、1,000 を超えるアプリケーション シナリオと 1,500 を超えるモデルが同時にオンラインで実行されている可能性があります。これほど多くのモデルをサポートするにはどうすればよいでしょうか? AI の「より多く、より速く、より優れた、より安価な」実装を技術的に実現するにはどうすればよいでしょうか?

多数: 主要なビジネス プロセスに関して複数のシナリオを実装する必要があり、その数は 1,000、大企業の場合は数万にも及ぶ場合があります。

高速: 各シーンの実装時間は短く、反復速度は速い必要があります。たとえば、推奨されるシナリオでは、フル トレーニングを 1 日に 1 回実行し、増分トレーニングを 15 分ごと、場合によっては 5 分ごとに実行する必要があることがよくあります。

良い点: 各シーンの着地効果は期待に応え、少なくとも実装前よりは改善されている必要があります。

節約: 各シナリオの実装コストは、予想どおり比較的経済的です。

「より多く、より速く、より良く、そしてより安く」を真に実現するには、MLOps が必要です。

従来のソフトウェア開発分野では、展開の遅さや品質の不安定などの同様の問題を DevOps を使用して解決しています。 DevOps により、ソフトウェアの開発と立ち上げの効率が大幅に向上し、最新のソフトウェアの迅速な反復と開発が促進されました。 AI システムの問題に直面した場合、DevOps 分野の成熟した経験から学び、MLOps を開発できます。したがって、図に示すように、「機械学習開発最新のソフトウェア開発」は MLOps になります。

MLOps とは正確には何ですか

現在、業界には MLOps についての標準定義はありません。

• ウィキペディアからの定義: MLOps は、本番環境で機械学習モデルを信頼性高く効率的にデプロイし、
  維持することを目的とした一連のプラクティスです。
• Google Cloud からの定義: MLOps は、機械学習システムの開発と運用を統合するために設計された機械学習エンジニアリングの文化と実践です。
• Microsoft Azure の定義: MLOps は、データ サイエンティストやアプリケーション エンジニアが実稼働環境で機械学習モデルをより効果的にするのに役立ちます。

上記の記述は非常に複雑ですが、これについての私の個人的な理解は比較的単純です: MLOps は、「コード モデル データ」の継続的インテグレーション、継続的デプロイメント、継続的トレーニング、継続的モニタリングです。

#上の図は、典型的な機械学習のライフ シーンを示しています。プロジェクトのフェーズを定義した後、処理データの定義と収集を開始します。現在の問題の解決にどのようなデータが役立つかを観察する必要があります。処理方法、特徴エンジニアリングの方法、変換して保存する方法。

データを収集した後、モデルのトレーニングと反復を開始します。継続的にアルゴリズムを調整し、トレーニングを続けて、最終的に期待を満たす結果を得る必要があります。結果に満足できない場合は、上位層に戻る必要があります。このとき、より多くのデータを取得し、そのデータに対してさらに変換を実行し、再度トレーニングするというサイクルを、より満足のいく結果が得られるまで繰り返す必要があります。モデル アルゴリズムを変更してから、再度開始し、オンラインで展開します。

導入およびモニタリングのプロセスにおいて、モデルの効果に一貫性がない場合は、トレーニングおよび導入でどのような問題が発生したかを観察する必要があります。一定期間デプロイした後、モデルの劣化の問題に直面する可能性があり、再トレーニングが必要になります。場合によっては、展開プロセス中にデータに問題が発生し、データ処理レイヤーに戻る必要があることもあります。さらに、導入効果はプロジェクトの期待には遠く及ばず、原点に立ち返る必要があるかもしれません。

ご覧のとおり、プロセス全体は周期的で反復的なプロセスです。エンジニアリングの実践には、継続的な統合、継続的なデプロイ、継続的なトレーニング、継続的なモニタリングが必要です。その中でも、継続的なトレーニングと継続的なモニタリングは MLOps に特有のものです。継続的トレーニングの役割は、コード モデルが変更されない場合でも、データの変更に備えて継続的にトレーニングする必要があることです。継続監視の役割は、データとモデルのマッチングに問題がないかを常に監視することです。ここでのモニタリングとは、オンラインシステムのモニタリングだけでなく、再現率や正解率など、システムや機械学習に関連する指標のモニタリングも指します。要約すると、MLOps とは実際には、コード、モデル、データの継続的インテグレーション、継続的デプロイメント、継続的トレーニング、継続的モニタリングであると思います。

もちろん、MLOps は単なるプロセスとパイプラインではなく、より大規模でより多くのコンテンツも含まれています。例:

(1) ストレージ プラットフォーム: 機能とモデルのストレージと読み取り

(2) コンピューティング プラットフォーム: 機能処理のためのストリーミングとバッチ処理

(3) メッセージ キュー: リアルタイム データの受信に使用されます

(4) スケジューリング ツール: さまざまなリソース (コンピューティング/ストレージ) のスケジューリング

(5) フィーチャー ストア: 登録, さまざまな機能の発見と共有

(6) モデル ストア: モデルの機能

(7) 評価ストア: モデルのモニタリング/AB テスト

フィーチャー ストア,モデル ストアと評価ストアは、機械学習の分野における新しいアプリケーションとプラットフォームです。複数のモデルがオンラインで同時に実行されることがあるためです。迅速な反復を実現するには、反復をより効率的に行うために、この情報を保持する優れたインフラストラクチャが必要です。時代の要求に応じて、新しいアプリケーションや新しいプラットフォームが登場します。

MLOps のユニークなプロジェクト - Feature Store

次に、機能プラットフォームである Feature Store について簡単に説明します。機械学習の分野におけるユニークなプラットフォームとして、Feature Store には多くの機能があります。

まず、モデルのトレーニングと予測の要件を同時に満たす必要があります。フィーチャ データ ストレージ エンジンには、シナリオごとにまったく異なるアプリケーション要件があります。モデルのトレーニングには優れたスケーラビリティと大規模なストレージ スペースが必要で、リアルタイム予測には高性能と低遅延の要件を満たす必要があります。

第 2 に、トレーニング段階と予測段階での特徴処理間の不一致の問題を解決する必要があります。通常、AI サイエンティストはモデルのトレーニング中に Python スクリプトを使用し、その後 Spark または SparkSQL を使用して特徴処理を完了します。この種のトレーニングは遅延の影響を受けにくく、オンライン ビジネスを扱う場合には効率が低いため、エンジニアはより高性能な言語を使用して機能処理プロセスを翻訳します。ただし、翻訳プロセスは非常に面倒で、エンジニアはロジックが期待どおりかどうかを科学者に繰り返し確認する必要があります。少しでも期待と乖離がある限り、オンラインとオフラインの不一致という問題が生じます。

3 番目に、無駄を避けて効率的に共有するには、特徴処理における再利用の問題を解決する必要があります。企業の AI アプリケーションでは、この状況がよく発生します。同じ機能が異なるビジネス部門で使用され、データ ソースが同じログ ファイルから取得され、中間で行われる抽出ロジックも似ていますが、異なる部門にあるためです。または、別のシナリオで使用すると、再利用できません。これは、同じロジックが N 回実行されることに相当し、ログ ファイルが膨大になるため、ストレージ リソースとコンピューティング リソースが膨大に浪費されます。

要約すると、Feature Store は主に、高パフォーマンスの特徴ストレージとサービス、モデルのトレーニングとモデルの予測、特徴データの一貫性、特徴の再利用、その他の問題を解決するために使用されます。データ サイエンティストは、Feature Store をデプロイメントに使用できます。共有。

現在市場に流通している主流のフィーチャープラットフォーム製品は、大きく3つのカテゴリーに分類できます。

• 各 AI 企業は独自の研究を行っています。ビジネスでリアルタイムのトレーニングが必要である限り、これらの企業は基本的に、上記 3 つの問題を解決するために同様の機能プラットフォームを開発します。しかし、この機能プラットフォームはビジネスと深く結びついています。
• SAAS 製品、またはクラウド ベンダーが提供する機械学習プラットフォームの一部。例えば、AWSが提供するSageMaker、Googleが提供するVertex、Microsoftが提供するAzure機械学習プラットフォームなどです。ユーザーがさまざまな複雑な機能を管理しやすくするために、機械学習プラットフォームに機能プラットフォームが組み込まれます。
• いくつかのオープンソース製品と商用製品。いくつかの例を挙げると、オープン ソースのフィーチャー ストア製品である Feast、完全なオープン ソースの商用フィーチャー プラットフォーム製品を提供する Tecton、オープン ソースのフィーチャー ストア製品である OpenMLDB などがあります。

MLOps 成熟度モデル

成熟度モデルは、システムの機能目標と一連のルールを測定するために使用されます。DevOps の分野では、成熟度モデルはよく使用されます。企業の能力、DevOps 能力を評価します。 MLOps の分野にも対応する成熟度モデルがありますが、まだ標準化されていません。ここでは、MLOps に関する Azure の成熟度モデルを簡単に紹介します。

機械学習プロセス全体の自動化の程度に応じて、MLOps の成熟モデルは (0、1、2、3、4) のレベルに分割されます。そのうち 0 は自動化がないことを意味します。 (1,2,3) は部分的な自動化、4 は高度に自動化されています。

成熟度レベルは 0、つまり MLOps はありません。この段階は、データの準備が手動で行われ、モデルのトレーニングも手動で、モデル トレーニングの展開も手動で行われることを意味します。すべての作業は手動で行われるため、AI に関する革新的なパイロット プロジェクトを実行する一部のビジネス部門に適しています。

成熟度レベルは 1 です。つまり、DevOps はありますが、MLOps はありません。データの準備は自動的に行われますが、モデルのトレーニングは手動で行われます。科学者はデータを取得した後、完成するまでにさまざまな調整やトレーニングを行います。モデルのデプロイも手動で行われます。

成熟度レベルは 2 で、これは自動トレーニングです。モデルのトレーニングは自動的に完了します。つまり、データが更新された後、自動トレーニング用に同様のパイプラインがすぐに開始されますが、トレーニング結果の評価と起動は依然として手動で行われます。

成熟度レベルは 3 で、これは自動展開です。モデルの自動トレーニングが完了すると、モデルの評価と起動は手動介入なしで自動的に完了します。

成熟度レベルは 4 で、これは自動的な再トレーニングと展開を意味します。オンライン モデルを継続的に監視し、Model DK のオンライン モデルの機能が低下していることが判明した場合、自動的に繰り返しトレーニングをトリガーします。プロセス全体が完全に自動化されており、最も成熟したシステムと言えます。

さらにエキサイティングなコンテンツについては、カンファレンスの公式 Web サイトをご覧ください: クリックして表示

以上がTan Zhongyi: モデル中心からデータ中心の MLOps により、AI をより迅速かつコスト効率よく実装できるようになりますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。