テストによってプロジェクトが実現可能に。これらはテスト可能で再現可能な仮説です。テストを実施する際の目標は、さまざまなモデル アーキテクチャと機能を評価して、継続的に段階的に改善を行うことです。テストする際は、次のことを行います。
ベースライン パフォーマンスを決定する。まず、ベースライン指標を確立します。ベースラインは、テストを比較する際の基準となります。
場合によっては、現在の非 ML ソリューションで最初のベースライン指標を提供できます。現在ソリューションが存在しない場合は、シンプルなアーキテクチャといくつかの機能を備えた ML モデルを作成し、その指標をベースラインとして使用します。
1 つの小さな変更を加える。ハイパーパラメータ、アーキテクチャ、特徴など、一度に 1 つの小さな変更のみを行います。変更によりモデルが改善されると、そのモデルの指標は、今後のテストと比較するための新しいベースラインになります。
わずかな変更を 1 回行うテストの例を次に示します。
- 特徴 X が含まれている。
- ドロップアウトに 0.5 を使用します。
- 特徴 Y の対数変換を取得します。
- 学習率を 0.001 に変更します。
テストの進捗状況を記録する。多くのテストが必要になりますベースラインと比較して予測品質が低い（または中立的な）テストも追跡に役立ちます。どのアプローチがうまくいかないのかを知らせます。通常、進捗状況は非線形であるため、ベースライン品質の向上状況に加えて、うまくいかなかった方法をすべてハイライト表示し、問題に取り組んでいることを示すことが重要です。
実際のデータセットでは、完全なトレーニングを行うのに数時間（または数日）かかることがあるため、空間をすばやく探索するために、独立した複数のテストを同時に実行することを検討してください。イテレーションを続けることで、本番環境に必要な品質レベルに徐々に近づいていくことでしょう。
テスト結果のノイズ
テスト結果では、モデルやデータの変更以外のノイズが検出されると、変更によってモデルが実際に改善されたかどうかを判断することが困難になります。テスト結果でノイズが発生する可能性があるものの例を次に示します。
データ シャッフル: データがモデルに表示される順序は、モデルのパフォーマンスに影響する可能性があります。
変数の初期化: モデルの変数の初期化方法もパフォーマンスに影響する可能性があります。
非同期並列処理: 非同期並列処理を使用してモデルをトレーニングする場合、モデルのさまざまな部分を更新する順序もパフォーマンスに影響する可能性があります。
評価セットが小さすぎる: 評価セットが小さすぎると、モデルの全体的なパフォーマンスを表していないため、モデルの品質に不均一なばらつきが生じる可能性があります。
テストを複数回実施すると、テスト結果を確認できます。
テストの実施方法を調整する
チームは、定義されたプラクティスとアーティファクトを使用して、「テスト」とは何かを明確に理解する必要があります。次のことを説明するドキュメントが必要になります。
アーティファクト。テストのアーティファクトほとんどの場合、テストは再現可能なテスト済みの仮説です。通常は、テスト間の変化とそれがモデルの品質に与える影響を示すメタデータ（特徴量やハイパーパラメータなど）をログに記録することで再現できます。
コーディングの実践。全員が独自の実験環境を使用することになりますか？ 全員の作業を共有ライブラリに統合することはどの程度可能ですか（または簡単ですか）？
再現性とトラッキング。再現性にはどのような基準がありますか？たとえば、チームは同じデータ パイプラインとバージョニング方法を使用するべきか、プロットのみを表示しても問題ないか、などです。試験運用版データは SQL クエリとして、またはモデル スナップショットとして、どのように保存されるか。各テストのログは、どこに文書化されますか。ドキュメント、スプレッドシート、テスト管理用の CMS ですか。
予測が間違っている
実世界のモデルが完璧とは限りません。システムは誤った予測をどのように処理しますか？ そうした問題に対処する方法について、早い段階から考えてみましょう。
ベスト プラクティスの戦略は、誤った予測に正しくラベル付けすることをユーザーに奨励します。たとえば、メールアプリは、ユーザーが迷惑メールフォルダに移動したメールと、その逆のメールをログに記録することで、誤って分類されたメールを取得します。ユーザーから正解ラベルを取得することで、データの収集とモデルの再トレーニングのための自動フィードバック ループを設計できます。
UI に埋め込まれたアンケートはユーザーのフィードバックを取得しますが、データは通常定性的であり、再トレーニング データに組み込むことはできません。
エンドツーエンドのソリューションを実装する
チームがモデルをテストしている間に、最終的なパイプラインの一部の構築を始めることをおすすめします（そのためのリソースがある場合）。
データ取り込みやモデルの再トレーニングなど、パイプラインのさまざまな要素を確立することで、最終モデルを本番環境に簡単に移行できます。たとえば、データの取り込みと予測の提供のためのエンドツーエンドのパイプラインを取得することで、チームはモデルをプロダクトに統合し、初期段階のユーザーテストを開始できます。
停止したプロジェクトのトラブルシューティング
プロジェクトの進行状況が停滞することがあります。チームが有望なテストに取り組んでいるものの、モデルの改善に数週間が成功していないという場合も考えられます。どうすればよいでしょうか。次のような方法が考えられます。
戦略。問題の再構築が必要になることもあります。テストフェーズに時間を費やすと、問題、データ、可能な解決策についてより深く理解できるようになります。分野をより深く知ることで、問題をより正確に捉えることができます。
たとえば、当初は線形回帰を使用して数値を予測したい場合があります。残念ながら、有効な線形回帰モデルをトレーニングするには、データが十分ではありませんでした。さらなる分析により、例が特定の値を上回るか下回るかを予測することで問題を解決できることが明らかになるかもしれません。これにより、問題をバイナリ分類の問題として再構築できます。
進行が予想より遅い場合でも、あきらめないでください。時間の経過に伴う段階的な改善が、問題を解決する唯一の方法である場合があります。前述したように、前週と同じ進捗は期待できません。多くの場合、本番環境に対応したバージョンを得るには、かなりの時間がかかります。モデルの改善は不規則で予測不可能なことがあります。進捗が遅い期間の後で改善が急増することもあれば、逆に改善がみられることもあります。
技術。誤った予測の診断と分析に時間をかける。場合によっては、いくつかの誤った予測を切り分け、それらのインスタンスでのモデルの動作を診断することで、問題を見つけることができます。たとえば、アーキテクチャやデータの問題を特定できます。または、より多くのデータを取得すると役立つ場合があります。正しい経路を進んでいることを示す明確なシグナルが得られる場合があります。また、アプローチに他の問題が存在することを示すノイズが多くなることもあります。
人間がラベルを付けたデータセットを必要とする問題に取り組んでいる場合、モデル評価用にラベル付きのデータセットを取得するのが困難な場合があります。評価に必要なデータセットを取得するためのリソースを見つけてください。
解決策がまったくない可能性があります。アプローチをタイムボックス化し、期間内に進まなかった場合は停止します。しかし 問題を明確に示せば 解決策が必要になるでしょう