ML プロジェクトの計画は、一般的なソフトウェア エンジニアリング プロジェクトの計画とは異なります。ML プロジェクトは非線形で、不確実性の度合いがさまざまです。反復的なアプローチと実験的なマインドセットが必要です。
プロジェクトの不確実性
通常、プロジェクトの開始時に最適なアプローチが明らかではないため、初期段階の計画は困難な場合があります。この不確実性から、タイムラインの予測が困難になります。
最近の Kaggle コンペティションでは、ML プロジェクトの不確実性が明らかになっています。コンテストの最初の数週間で、350 のチームが参加しました。一部のチームでは、ベンチマーク予測品質を 35% から 65% に向上させることができました。次の 2 週間で、この問題に取り組むチームの数は 350 から 1, 400 に増加しました。しかし、最良のモデルは 68% の予測品質しか達成できませんでした。
図 3 は ML 開発の不確実性を示しています。作業量は大幅に増加したが、モデル品質の向上は最小限にとどまっています。
図 3. 2 週間で、問題に取り組むチームの数は 4 倍に増加しましたが、モデルの品質はほぼ変わらず、ML ソリューションの労力を見積もるのが困難でした。
つまり、1,000 を超えるチームがさまざまなデータ変換、アーキテクチャ、ハイパーパラメータを試しながら、予測品質が 68% のモデルを作成することができました。
業界の例は、出力が入力に比例しない ML プロジェクトの非線形性を示しています。2 つのチームが、予測品質が 90% になるようにモデルをトレーニングするのに数か月かかりました。しかし、モデルを 99.9% の予測品質で本番環境に対応させるまでに、数チームによる 5 年以上かかりました。
これらの例から、本番環境対応の ML は探索的プロセスであり、科学的な考え方とエンジニアリング的な考え方の両方を必要とすることを示しています。
実験的なアプローチ
ほとんどの場合、ML 開発は従来のソフトウェア エンジニアリングの実践ではなく、テストの実施に似ています。ML では、さまざまな特徴をテストし、複数のアーキテクチャを試して、ハイパーパラメータを適切に調整する必要があります。定義上、テストの成果が保証されるわけではありません。そのため、試験運用版のフレームワークを使用して計画することをおすすめします。
一般的なソフトウェア エンジニアリング計画と ML プロジェクト計画の違いを見てみましょう。
ソフトウェア エンジニアリング プロジェクトの計画
一般的なソフトウェア エンジニアリング計画では、要件の定義、コンポーネントの概要、作業量の見積もり、作業のスケジュール設定を行います。解決策が明確に定義されています。たとえば、エンジニアは多くの場合、設計仕様を満たすアプリケーションを構築するために完了する必要があるタスクを高い精度で把握しています。
タスクの完了にかかる時間を予測する場合、同様のプロジェクトに基づいて作業量を見積もることができます。不明な依存関係や要件の変更などの課題が常に発生するため、見積もりが困難になる場合がありますが、通常はソリューションへの明確な道筋があります。
一方、ML プロジェクトは通常、成功への明確な道は 1 つではありません。
ML プロジェクトの計画
ほとんどの ML プロジェクトでは、試行錯誤のプロセスで複数のアプローチを試すことで最適なソリューションを見つけることができます。通常、問題の解決を試みる前に、その問題の最適な解決策を知ることはできません。たとえば、最適なソリューションのアーキテクチャは、単純な線形モデル、ニューラル ネット、ディシジョン ツリーなどです。それぞれのアプローチを試すだけで、最適なソリューションを見つけることができます。
この曖昧さが計画を難しくします。前述のように ML プロジェクトに必要な労力を予測することは 困難です問題の解決に取り組むだけで、解決に要する時間とリソースを把握しやすくなります。
ML 作業の計画に推奨される戦略は次のとおりです。
処理のタイムボックスを設定する。タスクを完了する、または特定の解決策を試すための明確な時間枠を設定します。たとえば、適切な種類のデータにアクセスできるかどうかを判断するために 2 週間を割り当てるとします。データを取得できた場合は、さらに 2 週間を指定して、単純なモデルで ML ソリューションが実現可能かどうか確認できます。単純なモデルで問題が生じた場合は、さらに 2 週間、ニューラル ネットを試してみましょう。各期間の終わりに、問題にリソースを適用し続けることの意義を判断するための情報が手に入ります。
プロジェクト要件の範囲を特定します。ML ソリューションが有望に見えても、プロダクトやサービスにとって不可欠な機能ではない場合は、その要件を確認します。たとえば、次の四半期の作業を計画するときに、非常にシンプルなソリューションを試すことを計画できます。その後の四半期では、ソリューションを繰り返し改善する可能性があります。多くのチームが、影響の大きい ML ソリューションにたどり着くまでに、長い期間をかけて段階的に改善して ML ソリューションを実装してきました。
インターンまたは Noogler プロジェクト。インターンや Noogler に ML ソリューションを試すように指示することは、成果の出ない新しい領域の探索を始める良い方法です。プロジェクトが終了すると、ML ソリューションに必要な労力と、将来有望なアプローチの可能性、あるいはリソースを別の場所に配置すべきかどうかについて、よりよく理解できるようになります。
どのような戦略でも、早期に失敗することが賢明です。コストは最も低いものの、潜在的に最も大きな見返りが得られる可能性のあるアプローチを最初に試します。この方法がうまくいけば、良いソリューションが見つかるはずです。そうでなければ、多くの時間とリソースを無駄にしているわけではありません。
チームが経験を積み、テストを実施するにつれて、テストに必要な労力をより正確に見積もることができ、計画をより予測しやすくなります。ただし、テストの結果はほとんど常にわからないため、最適なソリューションを見つけるために必要なテストの数を事前に見積もることはできません。
実験的な考え方を持つアプローチを計画することで、チームを成功に導くことができます。アプローチが行き止まりに陥った場合、チームメンバーは諦めるのではなく、それが ML ソリューションを見つけるプロセスの一部であることを理解します。さらに重要なのは、ML 開発に固有の不確実性について関係者と話し合うことで、より現実的な期待値を設定できるようになることです。
留意点
複数の ML アプローチを計画することを学習すると、確率論的には時間と経験が必要になります。プロジェクト計画を頻繁に更新する必要がある場合があります。チームが複数のアプローチをテストするため、絶えず進化する動的なドキュメントと考えてください。次の重要なアイデアに重点を置くことで、成功の可能性が高まります。
- 各アプローチの費用と成功の可能性を見積もります。
- さまざまなアプローチを試します。
- 得られた教訓を見極め、一度に 1 つずつシステムの改善に努めます。
- 障害に備える。
ときには、初期のアプローチがブレークスルーにつながることもあります。データ生成パイプラインまたはトレーニングと検証の分割でバグが見つかる可能性があります。適切な計画と詳細なドキュメントがあれば、ビジネス上の問題を予想よりも早く解決するモデルが見つかる可能性が高くなります。