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 プロジェクトには通常、明確な成功への道筋はありません。
ML プロジェクトの計画
ほとんどの ML プロジェクトでは、試行錯誤のプロセスで複数のアプローチをテストすることで、最適なソリューションを見つけることができます。通常、問題を解決しようとする前に、問題の最適な解決策を把握することはできません。たとえば、最適なソリューションのアーキテクチャは、単純な線形モデル、ニューラル ネットワーク、またはディシジョン ツリーなどです。最適なソリューションを見つけるには、各アプローチを試す必要があります。
このあいまいさにより、計画が難しくなります。前述のように、ML プロジェクトに必要な労力を予測することは困難です。問題を解決しようとすることで、解決に必要な時間とリソースの量を把握できます。
ML 作業を計画する際の推奨戦略は次のとおりです。
作業に時間制限を設ける。タスクを完了する、または特定の解決策を試すための明確な期間を設定します。たとえば、適切な種類のデータにアクセスできるかどうかを判断するために 2 週間を割り当てることができます。データを入手できる場合は、簡単なモデルで ML ソリューションが実現可能かどうかを確認するために、さらに 2 週間ほど指定します。シンプルなモデルが失敗した場合は、ニューラル ネットを試すためにさらに 2 週間指定できます。各期間の終了時に、問題にリソースを継続して適用する価値があるかどうかを判断するための詳細な情報が得られます。
プロジェクトの要件を絞り込む。ML ソリューションが有望に見えても、プロダクトやサービスにとって重要な機能ではない場合は、要件の範囲を縮小します。たとえば、次の四半期の作業を計画する際に、非常にシンプルなソリューションを試すことを計画できます。その後、次の四半期にソリューションを反復的に改善することを計画できます。多くのチームが、長期にわたって段階的に改善を加えることで ML ソリューションを実装し、効果的な ML ソリューションにたどり着いています。
インターンと新入社員のプロジェクト。インターンや新入社員に ML ソリューションを試すよう指示し、指導することは、結果が不明な新しい分野を探求する良い方法です。プロジェクトが終了すると、ML ソリューションに必要な作業量と、有望なアプローチ、またはリソースを他の場所に配置する必要があるかどうかを把握できるようになります。
どの戦略でも、失敗を早期に検出することが賢明です。費用が最も低く、成果が最も高いアプローチを最初に試します。この方法が機能すれば、適切な解決策を見つけたことになります。うまくいかなかったとしても、時間とリソースを無駄に浪費することはありません。
チームがテストの実施に慣れてくると、テストに必要な労力をより正確に予測できるようになり、計画の予測可能性が高まります。ただし、テストの結果はほとんどの場合不明であるため、最適なソリューションを見つけるために必要なテストの数を事前に推定することはできません。
テストの考え方を取り入れた計画アプローチは、チームを成功に導くうえで役立ちます。アプローチが行き詰まりに至っても、チームメンバーはそれが ML ソリューションを見つけるプロセスの一部であることを理解し、落胆することはありません。さらに重要なのは、ML 開発に固有の不確実性をステークホルダーと話し合うことで、より現実的な期待値を設定できることです。
理解度を確認する
留意点
複数の ML アプローチを確率的に計画するには、時間と経験が必要です。プロジェクト計画は頻繁に更新する必要がある場合があります。チームが複数のアプローチをテストするにつれて、絶えず進化する動的ドキュメントと考えてください。次の重要なアイデアに重点を置くことで、成功の可能性を高めることができます。
- 各アプローチの費用と成功の可能性を推定します。
- アプローチのポートフォリオを試す。
- 教訓を特定し、システムを 1 つずつ改善します。
- 障害に備えた計画を立てる。
早い段階でアプローチすることで、ブレークスルーにつながることもあります。データ生成パイプラインまたはトレーニングと検証の分割でバグが見つかる可能性があります。適切な計画と詳細なドキュメント化により、ビジネス上の問題を解決するモデルを予想よりも早く見つけられる可能性が高まります。