ML プロジェクトには、ML に関連するさまざまなスキル、専門知識、責任を持つメンバーが参加するチームが必要です。一般的な ML チームで最も一般的なロールは次のとおりです。
ロール | 知識とスキル | 主な成果物 |
---|---|---|
ML プロダクト マネージャー | ML プロダクト マネージャーは、ML の長所と短所、ML 開発プロセスを深く理解しています。ML チーム、エンドユーザー、その他の関係者と直接連携して、ビジネス上の問題を ML ソリューションに適合させます。プロダクトのビジョンを策定し、ユースケースと要件を定義し、プロジェクトを計画して優先順位を付けます。 |
プロダクト要件ドキュメント(PRD)。 |
エンジニアリング マネージャー | エンジニアリング マネージャーは、チームの優先事項を設定し、伝え、達成することでビジネス目標を達成します。ML プロダクト マネージャーと同様に、ML ソリューションをビジネスの問題に合わせます。チームメンバーに明確な期待値を設定し、業績評価を行い、キャリアと専門能力の向上を支援します。 |
設計ドキュメント、プロジェクト計画、パフォーマンス評価。 |
データ サイエンティスト | データ サイエンティストは、定量的分析と統計分析を使用して、データから分析情報と価値を抽出します。特徴の特定とテスト、モデルのプロトタイプ化、モデルの解釈に役立ちます。 | 統計分析によってビジネス上の疑問に答えるレポートとデータ ビジュアリゼーション。 |
ML エンジニア | ML エンジニアは、ML モデルの設計、構築、本番環境への移行、管理を行います。ML テクノロジーとベスト プラクティスに関する深い知識を持つ優秀なソフトウェア エンジニアです。 | ビジネス目標を達成するのに十分な予測品質を持つデプロイ済みモデル。 |
データ エンジニア | データ エンジニアは、大量のデータを保存、集約、処理するためのデータ パイプラインを構築します。データ エンジニアは、元データを収集してモデルのトレーニングとサービングに役立つ形式に変換するためのインフラストラクチャとシステムを開発します。データ エンジニアは、ML 開発プロセス全体のデータの責任を負います。 | 必要なモニタリングとアラート機能を備えた、完全に本番環境化されたデータ パイプライン。 |
デベロッパー オペレーション(DevOps)エンジニア | DevOps エンジニアは、ML モデルのサービス提供インフラストラクチャを開発、デプロイ、スケーリング、モニタリングします。 | モデルの動作のサービング、モニタリング、テスト、アラートを自動化するプロセス。 |
成功する ML プロジェクトでは、各ロールが適切に代表されるチームがあります。小規模なチームでは、1 人で複数の役割の責任を負う必要があります。
チームのプラクティスを確立する
ML 開発ではロール、ツール、フレームワークが大きく異なるため、優れたプロセスのドキュメント化を通じて一般的なプラクティスを確立することが重要です。たとえば、あるエンジニアは、適切なデータを取得するだけでモデルのトレーニングを開始できると考えますが、より責任感のあるエンジニアは、データセットが正しく匿名化されていることを検証し、メタデータと来歴を記録します。エンジニアがプロセスと設計パターンの共通の定義を共有することで、混乱を軽減し、チームの速度を向上させることができます。
プロセスのドキュメント
プロセスのドキュメントには、チームが ML 開発に使用するツール、インフラストラクチャ、プロセスを定義する必要があります。優れたプロセスのドキュメントは、新旧のチームメンバーの調整に役立ちます。次の種類の質問に回答する必要があります。
- モデル用のデータはどのように生成されますか?
- データを調べ、検証し、可視化する方法
- トレーニングデータの入力特徴またはラベルを変更するにはどうすればよいですか?
- データ生成、トレーニング、評価のパイプラインをカスタマイズするにはどうすればよいですか?
- 入力特徴やラベルの変更に対応するようにモデル アーキテクチャを変更するにはどうすればよいですか?
- テスト例を入手するにはどうすればよいですか?
- モデルの品質を判断するために使用する指標
- モデルを本番環境でリリースする方法
- モデルに問題があるかどうかを把握するにはどうすればよいですか?
- モデルはどのアップストリーム システムに依存していますか?
- SQL をメンテナンス可能で再利用可能にするにはどうすればよいですか?
その他の質問
モデルファインチューニングなど、同じパイプラインで異なるデータセットでモデルをトレーニングできますか?
新しいテストデータセットをパイプラインに追加するにはどうすればよいですか?
手動で作成した例でモデルの予測を確認するにはどうすればよいですか?
モデルが誤った例を見つけて調べ、可視化する方法を教えてください。
特定の予測に最も寄与した特徴を特定するにはどうすればよいですか?
特定のサンプル内の予測に最も影響を与えている特徴を把握するにはどうすればよいですか?
選択したデータセットまたはサンプルでモデルの予測を計算またはプロットするにはどうすればよいですか?
選択したデータセットに対するモデルの予測の標準指標を計算するにはどうすればよいですか?
カスタム指標を開発して計算するにはどうすればよいですか?
モデルをオフラインで他のモデルと比較するにはどうすればよいですか?
1 つの開発環境で複数のモデル評価のメタ分析を実行できますか?
現在のモデルと 10 か月前のモデルを比較できますか?
良いモデルを作成したと思います。本番環境でリリースするにはどうすればよいですか?
新しいモデルが本番環境で正しく実行されていることを確認するにはどうすればよいですか?
モデル評価の履歴を取得できますか?
モデルに問題があるかどうかはどのようにわかりますか?
モデルに関するページ/バグが割り当てられました。 どうすればよいですか?
データ生成/トレーニング/評価パイプラインをカスタマイズするにはどうすればよいですか?
まったく新しいパイプラインを作成するタイミングと方法を教えてください。
SQL を使用してデータを生成する必要があります。どこに置けばよいですか?
モデル サービングの仕組み図はありますか?
モデルが依存しているアップストリーム システムにはどのようなものがありますか?
解決策が見つかりません。どこに連絡すればよいですか?(連絡方法も含めて)
留意点
「ML のベスト プラクティス」の内容は、企業、チーム、個人によって異なる場合があります。たとえば、一部のチームメンバーは試験運用版の Colab を主な成果物と見なす一方で、他のチームメンバーは R で作業することを望む場合があります。ソフトウェア エンジニアリングに情熱を持っている人もいれば、モニタリングが最も重要だと考える人もいます。また、優れた機能の製品化手法を知りながら、Scala の使用を希望する人もいます。誰もが自分の視点から「正しい」判断を下します。正しい方向に導けば、その組み合わせは強力な武器になります。そうでない場合、混乱が生じる可能性があります。
コードを 1 行も記述する前に、チームが使用するツール、プロセス、インフラストラクチャを確立しておくことで、2 年後にプロジェクトが失敗するか、予定より 4 か月早くリリースに成功するかの違いが生じます。
パフォーマンス評価
ML には曖昧さと不確実性がつきまといます。そのため、人事マネージャーは明確な期待値を設定し、成果物について早い段階で定義する必要があります。
期待値と成果物について決定する際は、プロジェクトやアプローチが成功しなかった場合にどのように評価されるかを検討してください。つまり、チームメンバーのパフォーマンスがプロジェクトの成功に直接結び付かないことが重要です。たとえば、チームメンバーが解決策を調査するために数週間を費やしても、最終的に失敗に終わることも珍しくありません。このような場合でも、質の高いコード、徹底したドキュメント、効果的なコラボレーションは、評価にプラスに働くはずです。