大規模機械学習システムでは無料のランチはない

[[205684]]

Tu Weiwei 氏は、Fourth Paradigm Prophet プラットフォームのコア機械学習フレームワークである GDBT の設計者として、大規模な分散型機械学習システムのアーキテクチャ、機械学習アルゴリズムの設計とアプリケーションにおいて豊富な経験を持っています。屠衛衛氏は演説の中で、ますます多くの企業が機械学習技術を利用してデータをインテリジェントな意思決定エンジンに変換し始めていると述べた。企業の機械学習アプリケーションシステムにおけるコアモデルトレーニングシステムには、どのような設計と最適化の考慮事項がありますか? 教科書の機械学習アプリケーションと比較して、実際の企業の機械学習アプリケーションで見落とされがちな落とし穴は何ですか? Tu Weiwei は自身の経験を共有し、参考となるいくつかの解決策を提供しました。

業界における大規模分散機械学習コンピューティングフレームワークの設計経験

機械学習の典型的な定義は、経験 (データ) を使用してシステムのパフォーマンスを向上させることです。申請プロセスでは、まず機械学習の目標の定義、つまり機械学習で何を行うのかを明確にする必要があります。 Googleの検索広告収入の増加を例にとると、Googleはまず収益増加の目標を次のように分解しました。広告収入=平均クリック単価×クリック率×広告表示回数。ここで、「広告表示回数」は厳密に制御され（ポリシー、規制、ユーザーエクスペリエンスを考慮）、一方、「クリック単価」は広告主の積極的な入札によって影響を受けます。上記2つとは異なり、「クリック率」には明確な目標があります。検索エンジンは大量の表示クリックログを記録しますが、広告候補セットは大きく、異なる広告のクリック率は大きく異なります。Googleの広告プラットフォームは、広告表示回数を制御する自主性を持っています。したがって、Googleの検索広告収入の増加の問題に対して、「広告クリック率」を最適化するには機械学習が最も適しています。機械学習の具体的な最適化目標が広告のクリック率であると判断した後、Google の機械学習システムは、データ収集 → データ前処理 → モデルトレーニング → モデルサービング (モデルサービングによって生成されたデータは、次のサイクルでデータ収集システムによって収集されます) という 4 つのシステムをループで実行します。これら 4 つのシステムのうち、機械学習アルゴリズムに最も関連しているのはモデル トレーニング システムです。

Tu Weiwei 氏の意見では、コンピューティング フレームワークの設計には普遍的に最良のフレームワークは存在せず、実際のコンピューティングの問題に最適なフレームワークだけが存在するということです。

開発効率と実行効率の両方を考慮した機械学習向け大規模分散並列コンピューティングフレームワーク

産業用アプリケーションでは、有効なデータと特徴の次元が急速に増加しています。データ量に関して言えば、かつては機械学習タスクには数万のデータしかありませんでしたが、現在では企業のデータ量は簡単に数千億に達することがあります。特徴次元に関して、従来の機械学習は「大きなものを把握し、小さなものを無視する」アプローチを採用しています。つまり、トレーニングには高頻度のマクロ特徴のみを使用し、多くの情報を含む低頻度のマイクロ特徴を無視します。しかし、アルゴリズム、コンピューティング能力、データ収集機能が継続的に強化されるにつれて、より多くの低頻度のマイクロ特徴が機械学習トレーニングに追加され、モデルの有効性が高まります。

特徴的な頻度分布

機械学習技術は、産業応用においても絶えず発展しています。機械学習の最も初期の産業応用では、マクロ機能と単純なモデルのみが使用されていました。その後、マクロ機能のみを使用し複雑なモデルを使用するマイクロソフトとヤフーに代表される学派と、単純なモデルを使用しマイクロ機能を使用するグーグルに代表される学派の2つの異なる流派に発展しました。現在までに、複雑な関係をより細かく特徴付けるために、より多くのマイクロ機能と複雑なモデルを使用することが一般的な傾向となっています。これにより、モデルのトレーニングに対する要求が高まります。

まず、トレーニング システムを分散かつ並列化する必要があります。パワーウォール（チップ密度は継続的に増加できない）とレイテンシーウォール（光速には限界があり、チップサイズとクロック周波数は継続的に増加できない）の制限により、ムーアの法則は徐々に無効になりつつあります。現在、コンピューティング能力を向上させる方法は主に並列コンピューティングに依存しており、実行レイテンシーの削減に重点が置かれていた初期の頃から、スループットの向上に重点が置かれています。モデルトレーニングの高性能コンピューティング要件では、単一のマシンの IO、ストレージ、コンピューティング機能だけでは不十分であり、機械学習モデルトレーニング システムには分散並列処理が必要です。もちろん、アムダールの法則も念頭に置く必要があります。

パワーウォール、消費電力は集積回路の密度に応じて指数関数的に増加する

第二に、トレーニング フレームワークには高い開発効率が求められます。機械学習の分野では、No Free Lunch [Wolpert and Macready 1997]と呼ばれる有名な定理があります。これは、あらゆるアルゴリズム（ランダムアルゴリズムを含む）のすべての問題に対する期待パフォーマンスは同じであることを意味します。普遍的なアルゴリズムは存在しないため、さまざまな実際の問題に対してさまざまな機械学習アルゴリズムを開発する必要があります。これには、機械学習コンピューティング フレームワークの開発効率が非常に高いことが求められます。

典型的な機械学習モデリングプロセス

第三に、トレーニングシステムには高い実行効率が求められます。実際の問題に直面すると、データ、特徴表現、モデル、モデルパラメータなどに対して複数回の試行を行う必要があり、各試行には個別のモデルトレーニングが必要になります。したがって、モデルトレーニングは機械学習モデリングプロセス全体の中で最も繰り返し実行されるモジュールであり、実行効率が最優先事項になります。

コア機械学習システムのコンピューティングリソース要件の比較

4 番目に、基礎となるフレームワークには無料のランチはありません。コンピューティングの問題によって、コンピューティング モードとさまざまなコンピューティング リソースの要件は異なります。したがって、すべての問題に最適なアーキテクチャはなく、実際の問題に最適なアーキテクチャのみがあります。機械学習タスクの特性に基づいてフレームワークを設計することによってのみ、大規模な機械学習モデルのトレーニングの計算上の問題をより効果的に解決できます。

開発効率の最適化

開発効率の向上という点では、コンピューティングとプログラミング モードの選択と、プログラミング言語の選択という 2 つの側面について説明します。

並列コンピューティング パラダイムには 2 つのタイプがあります。1 つは共有メモリに基づく並列コンピューティング パラダイムで、異なるコンピューティング ノードが同じメモリを共有します。基盤となるレイヤーでは、メモリ アクセスの競合などの問題を処理する必要があります。このモデルは、通常、単一マシンのマルチプロセッサなどの小規模プロセッサの状況で使用されます。もう 1 つはメッセージ パッシングに基づく並列コンピューティング パラダイムで、各コンピューティング ノードは独自のメモリを使用し、コンピューティング ノードはメッセージ パッシングを通じて並列コンピューティングを実行します。実際の分散並列システムでは、複数のマシン間の通信は一般的にメッセージ パッシングに基づいており、単一のマシン内の通信は一般的に共有メモリに基づいています (一部のシステムもメッセージ パッシングに基づいています)。

機械学習の分散モードは、データ分散とモデル分散に分けられます。データ分散とは、トレーニング データを複数の部分に分割し、異なるマシンでデータの一部を処理することを意味します。しかし、一部の大型モデルでは、1 台のマシンではモデル全体の計算を完了できない場合があるため、モデルは複数の部分に分割され、異なるマシンがモデルの異なる部分を計算します。実際のアプリケーションでは、通常、シナリオの要件に応じて 2 つが共存します。

データ分布とモデル分布

機械学習モデルトレーニングにおける一般的な分散並列コンピューティングモデル

最も一般的なのは、分散データフロー コンピューティング モデルです。データフロー モデルは、データ駆動型の並列コンピューティング実行モデルです。データフロー計算ロジックは、データフローグラフに基づいて表現されます。 ユーザーは、計算フロー グラフを記述して計算を完了し、計算フロー グラフ内の計算ノードを定義します。通常、ユーザーは特定の実行プロセスを指定する必要はありません。データフローグラフ内のさまざまなデータの計算は通常非同期で完了し、上流の準備が整っている限り、計算ノードは計算ロジックを実行できます。 Hadoop、Spark、Flink などの現在主流の ETL (抽出、変換、ロード) データ処理フレームワークはすべて、データ フロー コンピューティング モデルに基づいています。ただし、機械学習のコンピューティング タスクには、モデル パラメーターという、常に消去および書き込みが行われている共有の中間状態があります。コンピューティング プロセスは、中間状態を継続的に読み書きします。データ フローの計算モデルは一般に実行中に非同期であるため、共有される中間状態 (モデル パラメータ) に対して適切な一貫性制御を実行することは困難です。したがって、データフローコンピューティングモデルに基づく一貫性モデルは、一般的に同期的であり、データフロー内の強力な一貫性を保証します。ただし、同期ベースのシステムの実行パフォーマンスは、最も遅いコンピューティングノードに依存し、コンピューティング効率は比較的低くなります。

データフローコンピューティングモデルにおけるモデルパラメータの混乱

もう 1 つの一般的な分散並列コンピューティング モデルは、パラメーター サーバーに基づく分散コンピューティング モデルです。パラメータ サーバーは、機械学習モデルのトレーニング計算における共有状態であるモデル パラメータ管理の直感的な抽象化です。モデル パラメータの読み取りと書き込みは、統合パラメータ サーバーによって管理されます。パラメータ サーバーは、本質的には、複数の整合性モデルをサポートする高性能なキー値ストレージ サービスです。パラメータ サーバーに基づいて、さまざまな一貫性モデルを実装できます。 1 つの極端な例は BSP (Bulk Synchronous Parallel) です。このモデルでは、すべてのコンピューティング ノードが計算プロセス中に一貫したモデル パラメータを取得し、アルゴリズム実装の一貫性を保証しますが、同期によってリソースが浪費されます。 もう 1 つの極端な例は ASP (Asynchronous Parallel) です。このモデルでは、すべてのコンピューティング ノードが計算プロセス中にモデル パラメータの一貫性を保証せず、コンピューティング ノードは完全に非同期です。 この一貫性モデルは計算効率が高いですが、モデル パラメータの一貫性が保証されません。 異なるノードが異なるバージョンのモデルを取得し、トレーニング プロセスが不安定になり、アルゴリズムの効果に影響します。 CMU の Eric Xing 教授は、BSP と ASP の中間に位置する SSP (Stale Synchronous Parallel) を提案しました。 これは、最も一貫性のないパラメータ バージョンの数を制限することで、全体的な同期リズムを制御します。 これにより、同期によって引き起こされる実行効率の問題を軽減できるだけでなく、アルゴリズムの収束特性を ASP よりも向上させることができます。さまざまな一貫性モデルにより、実行速度とアルゴリズムのパフォーマンスのバランスを適切に取ることができます。

実際、データフローコンピューティングモデルとパラメータサーバーコンピューティングモデルは、機械学習モデルのトレーニングコンピューティングプロセスの異なる側面を特徴付けています。機械学習におけるサンプルデータの流れをデータフローで記述するのは自然であり、モデルトレーニングプロセスにおける中間状態はパラメータサーバーコンピューティングモデルによって自然に記述できます。したがって、全体的な開発の傾向は、データ ストリーム内の読み取りパラメータ サーバーと書き込みパラメータ サーバーを組み合わせることです。たとえば、Intel は Spark 上でパラメータ サーバーを開発しました。ただし、データ ストリーム コンピューティング モデルとパラメータ サーバー コンピューティング モデルの整合性モデルは完全に同じではありません。BSP や SSP などのパラメータ サーバーの整合性モデルは、データ ストリームの元の非同期コンピューティング ロジックを破壊します。パラメータ サーバーとデータ ストリームを組み合わせた災害復旧戦略と一貫性管理戦略は、適切に統一および統合されるように慎重に設計する必要があります。

データフローとパラメータサーバーを組み合わせたアーキテクチャ

プログラミングモデルとプログラミング言語の選択

プログラミングパラダイムは、命令型と宣言型の 2 つのタイプに分けられます。命令型プログラミングとは、特定の実行プロセスを明示的に指定してプログラミングすることです。一般的な命令型言語は C/C++ などですが、宣言型プログラミングでは、命令型プログラミングとは異なり、特定の実行プロセスを明示的に指定せず、コンピューティング タスクの目標を定義および記述するだけで、具体的な実行は基盤となるコンピューティング フレームワークに任せます。命令型プログラミングは、特定の実行プロセスを明示的に指定するため、より柔軟です。一方、宣言型プログラミングの基盤となるコンピューティング フレームワークは、実行プロセスのより詳細な最適化を実行できるため、より効率的になる可能性があります。実際の機械学習モデルトレーニングコンピューティングフレームワークでは、MxNet、Tensorflow など、この 2 つが共存するのが一般的です。

合計演算の命令型実装と宣言型実装の比較

運用効率と使いやすさのバランスをとるために、機械学習モデルトレーニングコンピューティングフレームワークのプログラミング言語の選択では、一般的にフロントエンドとバックエンドを分離するアプローチを採用しています。つまり、システムの運用効率を確保するためにバックエンドとして C/C++、Java/Scala などを使用し、よりユーザーフレンドリーなプログラミングインターフェイスを提供するためにフロントエンドとして Python、R などを使用します。バックエンド言語の選択に関しては、Java と C++ が主流ですが、どちらにも長所と短所があります。

エコロジーの観点から見ると、Java は開発が容易であるため、C++ よりもはるかに優れています。多くのビッグデータ コンピューティング フレームワークは、Java または Java のような言語に基づいて開発されています。

移植性の点では、JVM が多くの根本的な違いを隠蔽するため、Java は C++ よりも優れています。

メモリ管理の面では、ビッグデータや同期分散並列処理の場合、GC ベースの Java の効率は、最適化された C++ の効率よりもはるかに低くなります。これは、ビッグデータの場合、GC の確率が非常に高いためです。サーバーが GC を開始すると、その計算能力は大きな影響を受けます。特に同期の場合、クラスター全体の計算効率も大幅に低下します。マシンの数が増えると、特定の瞬間に GC がトリガーされる確率も大幅に増加します。

言語の抽象化の面では、C++ テンプレート メカニズムがコンパイル時に拡張され、コンパイルの最適化がさらに可能になります。実際の実行では、生成されたプログラム ファイルが大きくなることを除き、全体的な実行効率は非常に高くなります。対応する Java ジェネリックは型消去を使用して実装されており、実際の実行時にデータ型のキャストを実行すると、多くの追加オーバーヘッドが発生し、全体的な実行効率に大きな影響を与えます。

実際の機械学習モデルトレーニングシステムの設計では、具体的な選択はフレームワーク設計者の好みと実際の問題のニーズ（システム展開要件、開発コストなど）によって異なります。

実行効率の最適化

実行効率の最適化に関しては、主にコンピューティング、ストレージ、通信、フォールト トレランスの 4 つの側面での最適化を共有する例が示されています。

コンピューティングの観点から、最も重要な最適化ポイントはバランスです。バランス調整には、異なるマシン間および異なるコンピューティング スレッド間の負荷分散だけでなく、算術および論理演算リソース、ストレージ リソース、通信リソースなど、さまざまなコンピューティング関連リソース間のバランス調整も含まれます。その最終的な目標は、すべてのコンピューティング リソースの利用率を最大化することです。実際の最適化プロセスでは、プログラムを注意深くプロファイリングし、パフォーマンスのボトルネックの可能性を見つけ出し、パフォーマンスのボトルネックを最適化し、ボトルネックの問題を解決する必要があります。ただし、この時点でパフォーマンスのボトルネックが変化する可能性があるため、プロファイリング → ボトルネックの発見 → ボトルネックの解決という繰り返し作業を続ける必要があります。

典型的な計算パフォーマンス最適化サイクル

CPUとGPUのアーキテクチャの比較

分散コンピューティングには、シリアル化コスト、ネットワーク通信コストなどのコストがかかります。すべてのタスクを分散方式で実行する必要はありません。場合によっては、タスクまたはタスクの一部を単一のマシンで適切に実行できます。分散を単に分散のためだけに使用しないでください。より優れたコンピューティング パフォーマンスを得るには、スタンドアロン システムと分散システムを個別に最適化する必要があります。

CPU、GPU、FPGAなどのさまざまなハードウェアには、それぞれの利点があります。たとえば、CPUは複雑な命令に適しており、分岐予測、大容量キャッシュを備え、タスクの並列処理に適しています。GPUは算術論理ユニットの数が多いですが、キャッシュは小さく、分岐予測がなく、粗粒度のデータ並列処理に適していますが、複雑な命令の実行には適していません。行列演算などの粗粒度の並列コンピューティングタスクを高速化するために使用できます。ディープラーニング予測などの特定のコンピューティングタスクの場合、FPGAは最適化後にCPUとGPUの間にピーク値を持ち、消費電力はGPUチップよりもはるかに低くなります。機械学習タスクでは、さまざまなコンピューティング ハードウェアの利点を最大限に活用し、コンピューティング ハードウェアの利用率を向上させるために、合理的なタスク スケジューリングが必要です。

近年、CPU や GPU などのコンピューティング ハードウェアの効率はメイン メモリの性能よりもはるかに速く向上しており、コンピューティングとストレージ間のパフォーマンス ギャップが広がり、「メモリの壁」が形成されています。そのため、多くの問題においてストレージの最適化がより重要になっています。ストレージに関しては、CPU レジスタから L1、L2 などのキャッシュ、CPU ローカル メモリ、その他の CPU メモリ、外部メモリに至るまで、複雑なストレージ構造とさまざまなストレージ ハードウェアがあり、アクセス効率も桁違いに異なります。 Jeff Dean 氏は、プログラマーに対し、さまざまなストレージ ハードウェアのパフォーマンス データを念頭に置くようにアドバイスしています。

ストレージ階層、パフォーマンスデータ、ストレージウォール

ストレージ階層と各レベルのストレージ ハードウェアのパフォーマンス特性に基づいて、データのローカライズやメモリ アクセス モードなどのストレージ最適化戦略を採用できます。機械学習は反復的であるため、一部のトレーニング データまたは一部の中間計算結果をローカルに配置できます。再度トレーニングするときに、リモート データを要求する必要はありません。また、単一マシンの場合は、さまざまなメモリ割り当て戦略を試したり、計算モードを調整したり、データのローカリゼーションを強化したりすることもできます。メモリ アクセス モードの最適化に関しては、データ アクセスの並べ替え (GPU のテクスチャ レンダリングや行列乗算演算でよく使用される Z オーダー カーブの最適化など)、データ レイアウトの調整 (よりコンパクトなデータ構造を使用して順次メモリ アクセスのキャッシュ ヒット率を向上させるなど) など、さまざまな最適化を実行できます。同時に、マルチスレッド シナリオでは、同じロックをめぐって競合するメモリの解放を申請するスレッド間の頻繁な競合を回避するようにしてください。さらに、ホット データとコールド データを分離してキャッシュ ヒット率を向上させることもできます。たとえば、データのプリフェッチでは、別のスレッドを使用してデータを事前に高速ストレージにプリフェッチし、後続の計算のメモリ アクセス効率を向上させることができます。

通信は分散機械学習コンピューティング システムの重要な部分です。通信には、ポイントツーポイント通信とグループ通信 (AllReduce、AllGather など) が含まれます。ソフトウェアの最適化とハードウェアの最適化により実行効率が向上します。

ソフトウェアの最適化に関しては、シリアル化フレームワークの最適化、通信の圧縮、アプリケーション層の最適化などの方法を通じて最適化を実現できます。

通信はシリアル化に依存します。ProtoBuffer や Thrift などの一般的なシリアル化フレームワークでは、普遍性、一部の前方および後方互換性、および言語間の考慮事項のために、一定の効率が犠牲になります。特定の通信シナリオでは、よりシンプルなシリアル化フレームワークを設計して、シリアル化の効率を向上させることができます。

帯域幅がボトルネックになる場合は、圧縮技術を使用して帯域幅の負荷を軽減するなど、CPU を使用して帯域幅を交換することを検討できます。

より重要な最適化は、アプリケーション層の通信モードを考慮することで実現され、より多くの最適化を行うことができます。たとえば、同じ機械学習トレーニングプロセスでは、異なるスレッド間でモデルパラメータ要求が何度も繰り返される可能性が高いため、パラメータサーバーのクライアントは同じマシン内の複数のスレッドの要求をマージできます。または、パラメータサーバーのさまざまな一貫性モデルに応じて、要求のキャッシュを実行してクエリ効率を向上させ、帯域幅を削減できます。または、さまざまなネットワークトポロジにさまざまなグループ通信実装方法を採用できます。

ソフトウェアの最適化に加えて、通信アーキテクチャではハードウェア機能を最大限に活用し、ハードウェアを使用してネットワーク スループットを向上させ、ネットワーク遅延を削減する必要があります。たとえば、複数のネットワーク カードを構成して冗長リンクを確立し、ネットワーク スループットを向上させたり、Infiniband を導入してネットワーク スループットを向上させ、ネットワーク遅延を削減したりできます。

フォールト トレランスに関して言えば、さまざまなシステムのフォールト トレランス戦略の主な違いは、最も適切なトレードオフを選択することにあります。ここでのトレードオフとは、各障害後にタスクを回復するためのコストと、このコストを削減するために支払われるオーバーヘッドとの間のトレードオフを指します。機械学習モデルトレーニング システムのフォールト トレラント戦略を選択するときは、機械学習モデルトレーニング タスクの特性を考慮する必要があります。まず、機械学習モデルトレーニングは、多くの中間状態を伴う反復的なコンピューティング タスクです。次に、モデル パラメーターは、機械学習モデルトレーニング システムで最も重要な状態です。最後に、機械学習モデルトレーニングには、必ずしも強い一貫性は必要ありません。

業界における機械学習トレーニング タスク用の一般的な災害復旧ソリューションには、データ リネージとチェックポイントの 2 つがあります。データ リネージは、データのソースを記録することで、データ ソースの追跡を簡素化します。データ エラーや損失が発生した場合、データ リネージに基づいて以前のデータを見つけ、繰り返し計算することでデータ回復を実行できます。一般的なオープン ソース プロジェクト Spark では、この災害復旧ソリューションが使用されています。データ リネージュの粒度は大きくても小さくてもかまいません。データ リネージュを維持するには、比較的信頼性の高いサービスが必要です。全体的なオーバーヘッドは大きくなります。機械学習モデルのトレーニングにおける共有状態の場合、モデル パラメータは共有され、多くの中間状態を持ち、各中間状態は以前のバージョンのモデル パラメータの計算とすべての中間データに依存するため、モデル パラメータは必ずしも優れた災害復旧方法ではありません。データ リネージュとは異なり、機械学習モデルのトレーニング システムにおけるチェックポイント戦略は、一般的に機械学習モデル パラメータの災害復旧に重点を置いています。機械学習は反復的であるため、これを使用して、機械学習の一貫性モデルを満たしながら、単一または複数の反復間、または反復内で機械学習モデル パラメータとトレーニングの進行状況に対して災害復旧を実行できます。このようにして、障害が発生した場合、前の反復のモデル チェックポイントから次の反復を開始できます。データ系統と比較すると、機械学習モデルトレーニングシステムでは、モデルパラメータとモデルトレーニングの進行状況に対してチェックポイント災害復旧を実行する方が自然で適切です。そのため、TensorflowやMxnetなど、機械学習専用に設計された現在の主流のコンピューティングフレームワークはすべて、チェックポイント災害復旧戦略を採用しています。

上記のフォールト トレランス方式に加えて、従来の災害復旧でよく使用される冗長システムを災害復旧に使用することもできます。災害復旧システムのオンライン状態に応じて、コールド バックアップ方式、ウォーム バックアップ方式、ホット バックアップ方式に分けることができます。実際のアプリケーションでは、実際のリソースとコンピューティング パフォーマンス要件に基づいて、実際の問題に最も適した冗長フォールト トレランス方式を選択できます。

機械学習の実用化におけるよくある落とし穴

実際の機械学習アプリケーションでは、見落としがちな落とし穴に遭遇することがよくあります。一般的な落とし穴の例として、一貫性、オープンワールド、依存関係の管理、理解可能性/デバッグ可能性などがあります。

一貫性の罠

一貫性の罠は、見落とされやすい最も一般的な罠です。

まず、一貫性のない特徴表現や一貫性のないターゲットの意味など、トレーニング/推定の一貫性の問題が最も一般的です。一貫性のない特徴表現は比較的一般的であり、その原因はさまざまです。一貫性のない表現は比較的一般的です。たとえば、トレーニング データでは 0 が男性、1 が女性を表しますが、推定データでは 1 が女性、0 が男性を表します。トレーニングと評価の特徴抽出では、一方または両方に論理エラーが発生し、矛盾が生じます。さらに隠れた矛盾として「タイム トラベル」があり、これは時系列データで特に発生しやすいものです。「タイム トラベル」とは、特徴に時系列または因果関係の論理に違反する情報が含まれていることを意味します。たとえば、トレーニング データ セット全体で特徴をとったときの正例と負例の数/割合である特徴があります。ここで、サンプルの注釈情報は実際には暗黙的に使用されますが、推定プロセス中に注釈情報を事前に取得することは実際には不可能です (そうでなければ、推定する必要はありません)。たとえば、一部の特徴は現在のサンプル時点以降の情報を使用しますが、これは現在未来への移動が不可能であるため、実際の推定では不可能です。もう一つのタイプの不一致は、目標の意味の不一致です。たとえば、目標は検索結果に対するユーザー満足度を最適化することですが、機械学習の目標としてユーザーのクリックが使用されます。ユーザーが検索結果をクリックすることは、ユーザーが結果に満足していることを意味するわけではありません。

見落とされがちなもう 1 つの一貫性は、フィールドの意味が時間の経過とともに変化する可能性があることです。

実際のアプリケーションでは、一貫性のテストに重点を置き、特徴の特定の物理的な意味に注意を払い、特徴表現の一貫性の欠如、ターゲットの意味の一貫性の欠如、時間の経過による一貫性の欠如などの問題を回避する必要があります。

オープンワールドの罠

機械学習システムを実際のビジネスに適用すると、オープンな世界に直面します。機械学習システムはもはや静的で孤立したシステムではなく、外部の世界に対処する必要があり、多くの罠が生まれます。その中には、非常に有名な生存者バイアス問題があります。これは、現在のモデルが次のモデルのトレーニング データに影響を与えるためです。干渉がない場合、トレーニング データにはバイアスがかかります。この逸脱の起源は第二次世界大戦にまで遡ります。当時、科学者のチームが戦場での生存率を高めるために航空機を強化する方法を研究していました。彼らは戦場で生き残った航空機の銃弾の痕を分析し、腹部が最も多く撃たれたため、生存率を高めるには強化が必要であるという結論に達しました。しかし、統計学者のエイブラハム・ワルド氏は、破壊された航空機は翼やエンジンなどの重要部品が被弾したため無視されたと指摘。そのため、翼やエンジンなどの重要部品をよりよく保護することで、戦場での航空機の生存率を向上させることができる可能性がある。このような問題は、レコメンデーション システムや検索エンジンなどのシステムでは非常によく見られます。ユーザーに表示される結果は機械学習モデルに基づいて推奨され、これらの結果が次の機械学習モデルのトレーニングのデータになりますが、これらのデータにはモデル バイアスが含まれています。本質的には、これは活用と探索のバランスの問題であり、長期的な効果を目指す必要があります。このような問題を解決するには、強化学習のソリューションを参照できます。生存者バイアスの罠以外にも、実際の業務システムでは機械学習システムが他のシステムと連携することもあります。機械学習システムの出力はデータに応じて変化しますが、機械学習システムの出力に依存する連携システムのしきい値などのパラメータが固定されたままだと、システム全体の有効性に影響する可能性があります。実際のアプリケーションでは、機械学習システムの出力分布と他のシステムへの影響を監視する必要があります。推定分布の修正などの戦略を採用できます。

依存の罠

不注意な依存は簡単に非常に悲惨な結果につながる可能性がありますが、実際のアプリケーションでは見落とされがちです。一般的な依存関係は次のとおりです。

データ依存性: 従来のソフトウェア システムとは異なり、機械学習システムのパフォーマンスは外部データに依存します。データ依存性は、多くの場合暗黙的であり、検出や分析が難しいため、コード依存性よりも深刻です。

大企業でよくあるのは、モデル間の依存関係です。ビジネス上の問題を解決する際に、機械学習モデル B が確立されます。より高速化するために、別のチームのモデル A の出力に依存します。しかし、依存チームがモデル A をアップグレードすると、B にとって悲惨なことになります。

データの依存関係やモデル間の依存関係に加え、暗黙の依存関係はさらに検出が困難です。一部の機能フィールドは、モデル自体によって変更される場合があります。たとえば、推奨システムにおける「ユーザーが推奨記事をクリックした回数」という機能は、推奨モデルがアップグレードされると変更されます。

実際のアプリケーションでは、データ依存関係に細心の注意を払い、モデル間の依存関係を回避し、暗黙の依存関係を避けるようにしてください。

理解可能性/デブジャー能力の落とし穴

理解可能性/デバッグ性は最も見過ごされがちです。実際のビジネスアプリケーションでは、結果の追求に非常に複雑なモデルがよく使用されており、これらのモデルは理解してデバッグするのが難しい場合があります。

医療アプリケーションや銀行監査などの一部の企業の場合、モデルは理解できる必要があります。包括性に関しては、たとえば、Zhou Zhihua教授が提案する2回の学習方法を実行することは、2回の学習モデルを通じて同様のパフォーマンスを備えた決定ツリーモデルに変換できます。別のアプローチは、モデルの予測結果を説明することです。

可调试性对于实际应用是非常重要的，因为模型几乎不可能100%正确，而为了追求业务效果，容易采用非常复杂的特征和模型，但是在复杂模型和特征情况下没发生了bad case，或者想要提升模型性能，会很难分析，导致模型很难提升，不利于后续的发展，所以在实际的业务中需要选择适合实际问题和团队能力的特征、模型复杂度。

[2回学習とライム]

要約する

機械学習は、システムのパフォーマンスを向上させるためにデータを改善します。実際のビジネスデータのボリュームとデータの寸法の成長、コンピューティングパワーの継続的な改善、および機械学習アルゴリズムの継続的な最適化により、産業用アプリケーションでの機械学習は、初期の単純なモデルマクロ機能から現在の複雑なモデルのマイクロ機能に変わりました。

機械学習アプリケーションのコアシステムには、データ収集、データの前処理、モデルトレーニング、およびモデルのサービングが含まれます。モデルトレーニングシステムの場合、ムーアの法律の失敗により、実際のビジネスの全体的なデータ量とデータの寸法は成長し続け、機械学習アルゴリズムの無料の昼食定理、実際のモデリングプロセスでの頻繁な試みの必要性、コンピューティングフレームワークの無料昼食の必要性は、実際の機械学習システムには、開発学習の両方を説明するために特異的に設計された並行コンピューティングフレームワークを必要とします。この共有は、開発者の開発者の選択を解決する際に、実際のアプリケーションシナリオ、開発コスト、およびチーム機能に基づいてトレードオフと選択を行う必要があります。次に、実行効率の解決に関与するコンピューティング、ストレージ、通信、およびフォールトトレランスの設計と最適化を導入するための例が与えられました。継続的なプロファイリング、ボトルネックの反復除去、さまざまなコンピューティングリソースのバランスの取れた使用、およびさまざまなコンピューティングリソースの最大利用により、全体的な実行効率が向上します。

機械学習が実際のビジネスに適用されるときに見落とすのが簡単な多くの落とし穴があります。この共有は、さまざまな一般的なタイプの一貫性トラップ、オープンワールドに直面している機械学習のtrap、機械学習システムのさまざまな依存関係トラップ、および見過ごされがちなモデルの理解とデバッグ性を簡単に導入し、参照用のソリューションも提供します。実際の機械学習アプリケーションでは、これらのトラップを可能な限り回避する必要があります。