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