機械学習に必要なエンジニアリングの量は将来大幅に削減されるだろう

機械学習に必要なエンジニアリングの量は将来大幅に削減されるだろう

将来的には、ML 製品の構築がより楽しくなり、これらのシステムはより良く機能するようになります。 ML 自動化ツールが進化し続けるにつれて、データ サイエンティストや ML エンジニアは優れたモデルの構築に多くの時間を費やすようになり、実稼働レベルの ML システムに関連する面倒だが必要なタスクに費やす時間は減っていきます。

[[315891]]

AIはシステムエンジニアリングの問題です。

有用な機械学習製品を構築するには、多数のエンジニアリング コンポーネントを作成する必要がありますが、そのうち ML コードが関係するのはほんの一部です。本番環境レベルの ML システムを構築するには、データ パイプラインの構築、クラウド リソースの構成、サービス インフラストラクチャの管理など、多くの作業が必要です。

伝統的に、ML 研究は、より優れたモデルを作成し、言語モデルや画像処理などの分野で最先端の技術を推進することに重点を置いてきました。システムレベルで本番環境レベルの ML アプリケーションを設計および実装するためのベスト プラクティスにはほとんど注目が集まっていません。あまり注目されていませんが、ML システム レベルでの設計とエンジニアリングの課題は依然として非常に重要です。有用なものを作成するには、優れたモデルを構築するだけでなく、優れたシステムを構築する必要があります。

現実世界

ML2015 では、Google のチームが次の図を描きました。

これは、モデリング専用の実際の ML システム (小さなブラック ボックス) のコード量と、ML アプリケーションのサポート インフラストラクチャとパイプラインに必要なコード量を比較したものです。このグラフはそれほど驚くべきものではありません。ほとんどのプロジェクトでは、実稼働システムの構築に伴う頭痛の種のほとんどは、過剰適合や不足適合などの典型的な ML の問題から生じるのではなく、モデルが期待どおりに機能できるようにシステムに十分な構造を構築することから生じます。

実稼働レベルのMLシステム

本番環境レベルの ML システムを構築するには、データの取り込みからモデルの提供までの一連のステップであるワークフローを構築する必要があります。各ステップは相互にリンクされており、本番環境で実行できるほど堅牢です。

ワークフローはいくつかのデータ ソースから始まり、入力データの前処理、特徴エンジニアリング、モデルのトレーニングと評価、サービス環境へのモデルのプッシュ、運用環境でのモデル エンドポイントの継続的な監視など、モデル エンドポイントの作成に必要なすべての手順が含まれます。

このワークフローの特徴エンジニアリング > トレーニング > チューニングの部分は、機械学習の「芸術」とみなされることが多いです。ほとんどの問題では、特徴設計、モデルアーキテクチャ構築、ハイパーパラメータ調整に対するアプローチが非常に多く、データ サイエンティストや ML エンジニアは直感と実験の組み合わせに頼るしかありません。モデリングプロセスも機械学習の興味深い部分です。

モデリングとエンジニアリング

このモデリング プロセスは、アプリケーション シナリオや問題領域によって異なります。 Netflix でコンテンツを推奨するモデルをトレーニングする場合、モデリング プロセスは、顧客サービス用のチャットボットを構築する場合とは大きく異なります。基礎となるデータの形式が異なるだけでなく (スパース マトリックスとテキスト)、前処理、モデル構築、チューニングの手順も大きく異なります。ただし、モデリング プロセスはアプリケーション シナリオや問題領域によって大きく異なりますが、エンジニアリングの課題はほぼ同じです。

どのタイプのモデルを本番環境に導入するかに関係なく、そのモデルを中心に本番ワークフローを構築する際のエンジニアリング上の課題はほぼ同じです。

ML ドメイン全体にわたるこれらのエンジニアリング課題の均一性は、大きなチャンスです。 将来的には(そしてほとんどは現在でも)、これらのエンジニアリング上の課題は大部分が自動化されるでしょう。 Jupyter Notebook で作成されたモデルを本番環境レベルの ML システムに変換するプロセスが容易になります。これらの課題を解決するために特別なインフラストラクチャを作成する代わりに、データ サイエンティストや ML エンジニアがすでに使用しているオープン ソース フレームワークとクラウド サービスが、これらのソリューションを内部的に自動的に実装します。

大規模データの取り込み

すべての本番レベルの ML ワークフローはデータ ソースから始まります。通常、データの来歴に関連するエンジニアリング上の課題は、大規模なデータの取り込み、つまり、データが大きすぎてメモリに収まらないため、さまざまなデータ ソースからデータセットをインポートして前処理する方法を中心に展開されます。

オープンソースの機械学習フレームワークは、データローダーを開発することでこの問題に主に対処してきました。 TensorFlow の tf.data API や PyTorch DataLoader ライブラリなどのこれらのツールは、データを部分的にメモリにロードし、ほぼあらゆるサイズのデータ​​セットに使用できます。また、動的な機能エンジニアリングも提供し、実稼働環境に合わせて拡張できます。

モデルのトレーニングを加速

ML コミュニティは、大規模なモデルのトレーニングに必要な時間を短縮するために多くの作業を行ってきました。大規模なトレーニング ジョブの場合、トレーニング ジョブをマシンのグループ (トレーニング クラスター) に分散するのが一般的です。モデルのトレーニングに必要な時間をさらに短縮するために、専用のハードウェア (GPU や現在では TPU) を使用することも一般的です。

従来、トレーニング操作を複数のマシンやデバイスに分散するには、モデル コードを変更する必要があり、これは簡単ではありません。マシンのクラスターと特殊なハードウェアを使用することで効率性の向上を真に得るには、コードでマトリックス演算をインテリジェントに分割し、各トレーニング ステップのパラメーター更新を組み合わせる必要があります。

最新のツールにより、このプロセスははるかに簡単になります。 TensorFlow Estimator API は、分散クラスターでトレーニングするためのモデル コードを構成するプロセスを大幅に簡素化します。 Estimator API を使用すると、単一のパラメータを設定するだけで、トレーニング グラフを複数のマシン/デバイスに自動的に配布できます。

AI Platform Training などのツールは、オンデマンドのリソース プロビジョニングを提供し、分散クラスターでのモデル トレーニングを可能にします。 bash シェル コマンドを使用して、トレーニング ジョブ用にさまざまなマシンとデバイス タイプ (高性能 CPU、GPU デバイス、TPU) をプロビジョニングできます。

ポータブルでスケーラブル、再現可能な ML 実験

実験プロセスを標準化しながら迅速なプロトタイピングを可能にする環境を構築するには、多くのエンジニアリング上の課題が伴います。

過去の実験を繰り返し、モデルのメタデータ(パラメータ値)を観測された評価指標に関連付ける明確な方法がなければ、ハイパーパラメータ調整(モデルパラメータの値を変更して検証エラーを減らす)のプロセスは信頼できません。迅速に反復処理を行い、実験を効率的に実行するには、分散およびハードウェア アクセラレータによってサポートされる大規模なトレーニングが必要です。さらに、ML コードが移植可能でない場合、実験プロセスが管理不能になります。つまり、他のチーム メンバーや関係者が実験を複製できず、新しいデータが利用可能になっても運用中のモデルを再トレーニングできなくなります。

私自身、AI Hub 用のコンテナを構築するチームに所属しており、これらの課題の解決に尽力しています。私たちは、ML アルゴリズム (XGBoost、ResNet など) の高性能実装を Docker コンテナとして構築します。コンテナは AI プラットフォームのネイティブ サポートを提供し、デフォルトでモデル メタデータを保存して、実験を実行するための繰り返し可能なプロセスを提供します。これらのコンテナは分散トレーニングをサポートし、GPU または TPU デバイス上で実行できます。また、コンテナはポータブルであり、Docker がインストールされていれば、誰でもどこでもコンテナを実行できます。

サービスインフラストラクチャ

プロダクショングレードの ML システムは、大規模なデータの取り込みとモデルのトレーニング、および大規模なモデルの提供という両方の側面で拡張できます。モデルをトレーニングしたら、推論を生成するために使用できる環境にエクスポートする必要があります。消費者向け Web サイトが Web トラフィックの大きな変動を処理する必要があるのと同様に、モデル エンドポイントは予測リクエストの変動を処理できる必要があります。

AI Platform Prediction などのクラウド ツールは、モデル提供のためのスケーラブルなソリューションを提供します。クラウド サービスの弾力性により、予測されるリクエスト数に基づいてサービス インフラストラクチャをスケールアップまたはスケールダウンできます。これらの環境では、モデルを継続的に監視することも可能で、本番環境でモデルがどのように動作するかを確認するためのテストを作成することもできます。

未来のより良いMLシステム

将来的には、ML 製品の構築がより楽しくなり、これらのシステムはより良く機能するようになります。 ML 自動化ツールが進化し続けるにつれて、データ サイエンティストや ML エンジニアは優れたモデルの構築に多くの時間を費やすようになり、実稼働レベルの ML システムに関連する面倒だが必要なタスクに費やす時間は減っていきます。

<<:  MacBookのグラフィックカードがAIモデルを実行できないのはもったいない:このディープラーニングツールはすべてのブランドのGPUをサポートしています

>>:  10回!マイクロソフトは、1000億のパラメータをトレーニングできる史上最大のNLGモデルをオープンソース化しました。

ブログ    

推薦する

AIは近い将来自己認識できるようになるのでしょうか? Facebook がメタバースへの扉を開く「Ego4D」を発表

ある日、ヘルメットをかぶると、SFのような美しい世界が目の前に浮かび上がるのを想像したことはありませ...

OpenAI COO: AIが一夜にしてビジネスに大きな変化をもたらすとは期待しない

12月5日、OpenAIは企業ユーザーの開拓に力を入れているものの、同社の幹部の一部は、この技術がす...

...

PythonコードからAPPまで、必要なのは小さなツールだけ:GitHubには3,000以上のスターがある

機械学習開発者にとってアプリを構築するのはどれくらい難しいのでしょうか?実際、Python コードを...

感情コンピューティングは人間とコンピュータの相互作用の中核となるのでしょうか?感情分析におけるディープラーニングの応用について

人間とコンピュータの相互作用における感情コンピューティングの役割感情コンピューティングについて話す前...

GPT-5が稼働を開始しました!ウルトラマン:月7億では足りない。マイクロソフトがもっと投資してくれることを願う

月収7億元でもGPTのトレーニングへの巨額の投資を賄うことはできません。これはOpenAIのCEO、...

アフリカはパンデミックの最中に包括的な接続性を構築しており、明確な投資方針を持っている

テクノロジーと通信の急速な進歩により、自動化革命の時代において、アフリカの大規模かつ急成長中の人口は...

...

建設業界における人工知能のメリット

建設における AI は、設計、入札、資金調達、調達、建設、運用、資産管理、ビジネス モデルの変革など...

分散型AIで製造業を強化

家庭内の新しい仮想アシスタントから、受信トレイから迷惑メールを削除するスパムフィルターまで、人工知能...

人工知能は医療現場の診断や治療の決定に役立つ

必要な変更。医療制度と支払者(政府と民間の両方)において、この用語は患者への不必要なリスク、医療の質...

于聖奇:顔認識技術のリスクと法的規制

デジタル時代の到来により、顔認識技術の開発は大きく進歩しました。顔認識技術は普及し、多くの分野で広く...

...

...

AI、ビッグデータ、データサイエンス向けトップ10アルゴリズム

AI は私たちの職業、働き方、そして企業文化を変えています。 AIを活用することで、本当に重要なスキ...