テスト
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
テストは、プロジェクトを実現可能なものに導きます。これらは検証可能で再現可能な仮説です。テストを実行する際の目標は、さまざまなモデル アーキテクチャと機能を評価することで、継続的に改善を進めていくことです。テストを行う際は、次のことを行います。
ベースライン パフォーマンスを決定する。まず、ベースライン指標を設定します。ベースラインは、テストを比較するための測定基準として機能します。
場合によっては、現在の ML 以外のソリューションで最初のベースライン指標を提供できます。現在ソリューションが存在しない場合は、シンプルなアーキテクチャといくつかの特徴を持つ ML モデルを作成し、その指標をベースラインとして使用します。
小さな変更を 1 つずつ行う。ハイパーパラメータ、アーキテクチャ、特徴など、一度に 1 つの小さな変更のみを行います。変更によってモデルが改善された場合、そのモデルの指標が、今後のテストと比較する新しいベースラインになります。
小さな変更を 1 つだけ行うテストの例を次に示します。
- 機能 X を含める。
- 最初の隠れ層で 0.5 のドロップアウトを使用します。
- 特徴 Y のログ変換を取得します。
- 学習率を 0.001 に変更します。
テストの進捗状況を記録します。多くのテストを行う必要がある可能性が高いです。ベースラインと比較して予測品質が低い（または中程度）テストでも、トラッキングに役立ちます。どのアプローチが機能しないかを示すものです。通常、進捗状況は非線形であるため、ベースライン品質の向上の進捗状況に加えて、機能しない方法をすべてハイライト表示して、問題に取り組んでいることを示すことが重要です。
実際のデータセットでの完全なトレーニングは数時間（または数日）かかることがあるため、複数の独立したテストを同時に実行して空間を迅速に探索することを検討してください。反復処理を続けると、本番環境に必要な品質レベルに近づいていきます。
テスト結果のノイズ
モデルやデータの変更以外のノイズがテスト結果に発生し、行った変更が実際にモデルを改善したかどうかを判断するのが難しい場合があります。以下に、テスト結果にノイズを生成する可能性があるものの例を示します。
データのシャッフル: データがモデルに提示される順序は、モデルのパフォーマンスに影響する可能性があります。
変数の初期化: モデルの変数の初期化方法もパフォーマンスに影響する可能性があります。
非同期並列処理: 非同期並列処理を使用してモデルをトレーニングする場合、モデルのさまざまな部分が更新される順序もパフォーマンスに影響する可能性があります。
小さな評価セット: 評価セットが小さすぎると、モデルの全体的なパフォーマンスを代表するものではなく、モデルの品質にばらつきが生じる可能性があります。
テストを複数回実行すると、テスト結果を確認できます。
テスト手法について合意する
チームは、「テスト」が具体的に何であるかを明確に理解し、一連のプラクティスとアーティファクトを定義する必要があります。次の内容を概説したドキュメントが必要です。
アーティファクト。テストのアーティファクトとは何ですか？ほとんどの場合、テストは、テストされた仮説であり、再現可能です。通常は、テスト間の変更とそれがモデルの品質に与える影響を示すメタデータ（特徴やハイパーパラメータなど）をロギングすることで再現できます。
コーディング手法。すべてのユーザーが独自の試験運用環境を使用することになりますか？
全員の作業を共有ライブラリに統合するのはどの程度可能（または簡単）ですか？
再現性と追跡。再現性の基準は何ですか？たとえば、チームは同じデータ パイプラインとバージョニング プラクティスを使用すべきか、プロットのみを提示してよいかなどです。テストデータは SQL クエリとして保存されますか、それともモデル スナップショットとして保存されますか？各テストのログをどこに記録するか（ドキュメント、スプレッドシート、テスト管理用の CMS のいずれか）
予測が間違っている
現実世界のモデルは完璧ではありません。システムは誤った予測をどのように処理しますか？早い段階から対処方法について考え始めましょう。
ベスト プラクティス戦略では、ユーザーが誤った予測を正しくラベル付けすることを促します。たとえば、メールアプリは、ユーザーが迷惑メールフォルダに移動したメールとその逆を記録することで、誤って分類されたメールをキャプチャします。ユーザーからグラウンド トゥルース ラベルを取得することで、データ収集とモデルの再トレーニングのための自動フィードバック ループを設計できます。
UI に埋め込まれたアンケートはユーザーのフィードバックを収集しますが、通常、そのデータは定性的なものであり、再トレーニング データに組み込むことはできません。
エンドツーエンドのソリューションを実装する
チームがモデルをテストしている間、最終的なパイプラインの一部の構築を開始することをおすすめします（そのためのリソースがある場合）。
データの取り込みやモデルの再トレーニングなど、パイプラインのさまざまな部分を確立することで、最終的なモデルを本番環境に移行しやすくなります。たとえば、データの取り込みと予測の提供を行うエンドツーエンドのパイプラインを構築すると、チームはモデルをプロダクトに統合し、初期段階のユーザー テストを開始できます。
停止したプロジェクトのトラブルシューティング
プロジェクトの進行が停滞する場合があります。有望なテストに取り組んでいるにもかかわらず、何週間もモデルの改善に成功していないという場合もあるでしょう。どうすればよいですか。考えられるアプローチは次のとおりです。
戦略。問題を捉え直す必要がある場合があります。テストフェーズで時間を費やした後、問題、データ、考えられる解決策をより深く理解しているはずです。ドメインに関する深い知識があれば、問題をより正確に把握できる可能性があります。
たとえば、最初は線形回帰を使用して数値を予測することを考えていた場合、残念ながら、このデータは有効な線形回帰モデルをトレーニングするのに十分ではありませんでした。詳細な分析により、例が特定の値より上か下かを予測することで問題を解決できることが判明する場合があります。これにより、問題をバイナリ分類問題として再構成できます。
進捗が予想よりも遅い場合は、あきらめないでください。時間の経過とともに段階的に改善していくことが、問題を解決する唯一の方法かもしれません。前述のように、週ごとに同じ程度の進歩を期待しないでください。多くの場合、本番環境に適したモデルのバージョンを取得するには、かなりの時間を要します。モデルの改善は不規則で予測できない場合があります。進捗が遅い期間の後には、改善が急増することもあります。その逆も同様です。
技術的な問題: 誤った予測の診断と分析に時間を費やします。誤った予測をいくつか分離し、それらのインスタンスでモデルの動作を診断することで、問題を見つけられる場合があります。たとえば、アーキテクチャやデータに関する問題が見つかる場合があります。他にも、より多くのデータを取得することで解決できる場合があります。正しい方向に向かっていることを示す明確なシグナルが得られることもあります。また、ノイズが増え、アプローチに他の問題があることを示唆することもあります。
ヒューマン ラベル付きデータセットが必要な問題に取り組んでいる場合、モデル評価用のラベル付きデータセットを入手するのは難しい場合があります。評価に必要なデータセットを取得するためのリソースを見つけます。
解決策がない可能性もあります。アプローチにタイムボックスを設定し、期間内に進展がなければ停止します。ただし、問題の記述が明確な場合は、解決策が必要である可能性が高いです。
理解度を確認する
チームメンバーが、ベースライン モデルの指標を改善するハイパーパラメータの組み合わせを見つけました。チームの他のメンバーはどのように対応すればよいですか？
1 つのハイパーパラメータを組み込み、テストを続行します。
正解です。ハイパーパラメータのいずれかが妥当な選択肢と思われる場合は、試してみてください。ただし、すべてのハイパーパラメータの選択が、すべてのテストのコンテキストで意味があるとは限りません。
現在のテストのすべてのハイパーパラメータを、同僚のハイパーパラメータに合わせて変更します。
1 つのモデルを改善したハイパーパラメータが、別のモデルも改善するとは限りません。他のチームメイトはテストを継続する必要があります。これにより、後でベースラインがさらに改善される可能性があります。
モデルの実装に使用するエンドツーエンドのパイプラインの構築を開始します。
ベースラインを改善するモデルが、最終的に本番環境で使用されるモデルであるとは限りません。テストを継続すると、後でベースラインがさらに改善される可能性があります。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-27 UTC。
[null,null,["最終更新日 2025-07-27 UTC。"],[[["\u003cp\u003eExperiments involve making single, small, iterative changes to model features, architecture, or hyperparameters to improve performance compared to a baseline.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to track all experimental results, including unsuccessful ones, to understand which approaches work and which don't.\u003c/p\u003e\n"],["\u003cp\u003eTeams should establish clear experimentation practices, including defining artifacts, coding standards, reproducibility measures, and tracking methods.\u003c/p\u003e\n"],["\u003cp\u003ePlan for handling wrong predictions early on, potentially by incorporating user feedback for model improvement.\u003c/p\u003e\n"],["\u003cp\u003eConsider building parts of the final pipeline alongside experimentation to facilitate a smoother transition to production.\u003c/p\u003e\n"]]],[],null,["# Experiments drive a project toward viability. They are testable and\nreproducible hypotheses. When running experiments, the\ngoal is to make continual, incremental improvements by evaluating a variety of\nmodel architectures and features. When experimenting, you'll want to do\nthe following:\n\n- **Determine baseline performance.** Start by establishing a\n [baseline](/machine-learning/glossary#baseline) metric. The baseline\n acts as a measuring stick to compare experiments against.\n\n In some cases, the current non-ML solution can provide the first baseline\n metric. If no solution currently exists, create a ML model with a simple\n architecture, a few features, and use its metrics as the baseline.\n- **Make single, small changes.** Make only a single, small change at a time,\n for example, to the hyperparameters, architecture, or features. If the\n change improves the model, that model's metrics become the new baseline to\n compare future experiments against.\n\n The following are examples of experiments that make a single, small change:\n - include feature *X*.\n - use 0.5 dropout on the first hidden layer.\n - take the log transform of feature *Y*.\n - change the learning rate to 0.001.\n- **Record the progress of the experiments.** You'll most likely need to do\n lots of experiments. Experiments with poor (or neutral) prediction quality\n compared to the baseline are still useful to track. They signal which\n approaches won't work. Because progress is typically non-linear, it's\n important to show that you're working on the problem by highlighting all\n the ways you found that don't work---in addition to your progress at\n increasing the baseline quality.\n\nBecause each full training on a real-world dataset can take hours (or days),\nconsider running multiple independent experiments concurrently to explore the\nspace quickly. As you continue to iterate, you'll hopefully get closer and\ncloser to the level of quality you'll need for production.\n\n### Noise in experimental results\n\nNote that you might encounter noise in experimental results that aren't from\nchanges to the model or the data, making it difficult to determine if a change\nyou made actually improved the model. The following are examples of things that\ncan produce noise in experimental results:\n\n- Data shuffling: The order in which the data is presented to the model can\n affect the model's performance.\n\n- Variable initialization: The way in which the model's\n variables are initialized can also affect its performance.\n\n- Asynchronous parallelism: If the model is trained using asynchronous\n parallelism, the order in which the different parts of the model are updated\n can also affect its performance.\n\n- Small evaluation sets: If the evaluation set is too small, it may\n not be representative of the overall performance of the model, producing\n uneven variations in the model's quality.\n\nRunning an experiment multiple times helps confirm experimental results.\n\n### Align on experimentation practices\n\nYour team should have a clear understanding of what exactly an \"experiment\" is,\nwith a defined set of practices and artifacts. You'll want documentation that\noutlines the following:\n\n- **Artifacts.** What are the artifacts for an experiment? In most cases, an\n experiment is a tested hypothesis that can be reproduced, typically by\n logging the metadata (like the features and hyperparameters) that indicate\n the changes between experiments and how they affect model quality.\n\n- **Coding practices.** Will everyone use their own experimental environments?\n How possible (or easy) will it be to unify everyone's work into shared\n libraries?\n\n- **Reproducibility and tracking.** What are the standards for\n reproducibility? For instance, should the team use the same data pipeline\n and versioning practices, or is it OK to show only plots? How will\n experimental data be saved: as SQL queries or as model snapshots? Where will\n the logs from each experiment be documented: in a doc, a spreadsheet, or a\n CMS for managing experiments?\n\nWrong predictions\n-----------------\n\nNo real-world model is perfect. How will your system handle wrong predictions?\nBegin thinking early on about how to deal with them.\n\nA best-practices strategy encourages users to correctly label wrong predictions.\nFor example, mail apps capture misclassified email by logging the mail users\nmove into their spam folder, as well as the reverse. By capturing ground truth\nlabels from users, you can design automated feedback loops for data collection\nand model retraining.\n\nNote that although UI-embedded surveys capture user feedback, the data is\ntypically qualitative and can't be incorporated into the retraining data.\n\nImplement an end-to-end solution\n--------------------------------\n\nWhile your team is experimenting on the model, it's a good idea to start\nbuilding out parts of the final pipeline (if you have the resources to do so).\n\nEstablishing different pieces of the pipeline---like data intake and model\nretraining---makes it easier to move the final model to production. For\nexample, getting an end-to-end pipeline for ingesting data and serving\npredictions can help the team start integrating the model into the product and\nto begin conducting early-stage user testing.\n\nTroubleshooting stalled projects\n--------------------------------\n\nYou might be in scenarios where a project's progress stalls. Maybe your\nteam has been working on a promising experiment but hasn't had success\nimproving the model for weeks. What should you do? The following are some\npossible approaches:\n\n- **Strategic.** You might need to reframe the problem. After spending time in\n the experimentation phase, you probably understand the problem, the data,\n and the possible solutions better. With a deeper knowledge of the domain,\n you can probably frame the problem more precisely.\n\n For instance, maybe you initially wanted to use linear regression to predict\n a numeric value. Unfortunately, the data wasn't good enough to train a\n viable linear regression model. Maybe further analysis reveals the problem\n can be solved by predicting whether an example is above or below a specific\n value. This lets you reframe the problem as a binary classification one.\n\n If progress is slower than expected, don't give up. Incremental improvements\n over time might be the only way to solve the problem. As noted earlier,\n don't expect the same amount of progress week over week. Often, getting a\n production-ready version of a model requires substantial amounts of time.\n Model improvement can be irregular and unpredictable. Periods of slow\n progress can be followed by spikes in improvement, or the reverse.\n- **Technical.** Spend time diagnosing and analyzing wrong predictions. In\n some cases, you can find the issue by isolating a few wrong predictions and\n diagnosing the model's behavior in those instances. For example, you might\n uncover problems with the architecture or the data. In other cases,\n getting more data can help. You might get a clearer signal that suggests\n you're on the right path, or it might produce more noise, indicating other\n issues exist in the approach.\n\n If you're working on a problem that requires human-labeled datasets,\n getting a labeled dataset for model evaluation might be hard to obtain. Find\n resources to get the datasets you'll need for evaluation.\n\nMaybe no solution is possible. Time-box your approach, stopping if you haven't\nmade progress within the timeframe. However, if you have a strong problem\nstatement, then it probably warrants a solution.\n\n### Check Your Understanding\n\nA team member found a combination of hyperparameters that improves the baseline model metric. What should the other members of the team do? \nMaybe incorporate one hyperparameter, but continue with their experiments. \nCorrect. If one of their hyperparameters seems like a reasonable choice, try it. However, not all hyperparameter choices make sense in every experimental context. \nChange all their hyperparameters in their current experiment to match their co-worker's. \nHyperparameters that improved one model doesn't mean they'll also improve a different model. The other teammates should continue with their experiments, which might actually improve the baseline even more later on. \nStart building an end-to-end pipeline that will be used to implement the model. \nA model that improves the baseline doesn't mean it's the model that will ultimately be used in production. They should continue with their experiments, which might actually improve the baseline even more later on.\n| **Key Terms:**\n|\n| - [baseline](/machine-learning/glossary#baseline)"]]
