Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Tests tragen dazu bei, die Machbarkeit eines Projekts zu erhöhen. Es sind testbare und reproduzierbare Hypothesen. Bei der Durchführung von Tests besteht das Ziel darin, durch die Bewertung verschiedener Modellarchitekturen und ‑funktionen kontinuierliche, inkrementelle Verbesserungen vorzunehmen. Beachten Sie beim Testen Folgendes:
Bestimmen Sie die Referenzleistung. Legen Sie zuerst einen Referenzmesswert fest. Die Baseline dient als Maßstab für den Vergleich von Tests.
In einigen Fällen kann die aktuelle Lösung ohne maschinelles Lernen den ersten Messwert für den Vergleich liefern. Wenn derzeit keine Lösung vorhanden ist, erstellen Sie ein ML-Modell mit einer einfachen Architektur und wenigen Funktionen und verwenden Sie die Messwerte als Referenz.
Nehmen Sie einzelne, kleine Änderungen vor. Nehmen Sie immer nur eine kleine Änderung vor, z. B. an den Hyperparametern, der Architektur oder den Funktionen. Wenn sich das Modell durch die Änderung verbessert, werden die Messwerte dieses Modells zum neuen Referenzwert, an dem zukünftige Tests verglichen werden.
Die folgenden Beispiele zeigen Tests mit einer einzelnen, kleinen Änderung:
die Funktion X enthalten.
Verwenden Sie für die erste verborgene Schicht einen Dropout von 0,5.
die logarithmische Transformation des Attributs Y.
Ändern Sie die Lernrate in 0,001.
Notieren Sie den Fortschritt der Tests. Sie müssen höchstwahrscheinlich viele Tests durchführen. Auch Experimente mit einer schlechten (oder neutralen) Vorhersagequalität im Vergleich zur Kontrollgruppe sind nützlich. Sie zeigen an, welche Ansätze nicht funktionieren. Da der Fortschritt in der Regel nicht linear ist, ist es wichtig, zu zeigen, dass Sie an dem Problem arbeiten. Heben Sie dabei neben Ihren Fortschritten bei der Verbesserung der Grundqualität auch alle Methoden hervor, die nicht funktioniert haben.
Da jedes vollständige Training mit einem echten Datensatz Stunden oder Tage dauern kann, sollten Sie mehrere unabhängige Tests gleichzeitig ausführen, um den Bereich schnell zu erkunden. Mit jeder Iteration nähern Sie sich hoffentlich dem Qualitätsniveau, das Sie für die Produktion benötigen.
Abweichungen bei Testergebnissen
Beachten Sie, dass bei den Testergebnissen Abweichungen auftreten können, die nicht auf Änderungen am Modell oder an den Daten zurückzuführen sind. Daher ist es schwierig zu beurteilen, ob eine von Ihnen vorgenommene Änderung das Modell tatsächlich verbessert hat. Die folgenden Beispiele zeigen, was zu Abweichungen bei den Testergebnissen führen kann:
Datenmix: Die Reihenfolge, in der die Daten dem Modell präsentiert werden, kann sich auf die Leistung des Modells auswirken.
Variableninitialisierung: Die Art und Weise, wie die Variablen des Modells initialisiert werden, kann sich ebenfalls auf die Leistung auswirken.
Asynchroner Parallelismus: Wenn das Modell mit asynchronem Parallelismus trainiert wird, kann sich auch die Reihenfolge, in der die verschiedenen Teile des Modells aktualisiert werden, auf die Leistung auswirken.
Kleine Testsätze: Wenn der Testsatz zu klein ist, ist er möglicherweise nicht repräsentativ für die Gesamtleistung des Modells. Dies führt zu ungleichmäßigen Schwankungen bei der Qualität des Modells.
Wenn Sie einen Test mehrmals ausführen, können Sie die Testergebnisse bestätigen.
Testmethoden abstimmen
Ihr Team sollte genau wissen, was ein „Test“ ist, und eine Reihe von Praktiken und Artefakten haben. Die Dokumentation sollte Folgendes enthalten:
Artefakte Was sind die Artefakte für einen Test? In den meisten Fällen ist ein Test eine getestete Hypothese, die reproduziert werden kann. Dazu werden in der Regel die Metadaten (z. B. die Features und Hyperparameter) protokolliert, die die Änderungen zwischen den Tests angeben und wie sich diese auf die Modellqualität auswirken.
Programmierpraktiken Verwenden alle Teilnehmer ihre eigenen Testumgebungen? Wie einfach ist es, die Arbeit aller in gemeinsamen Bibliotheken zusammenzuführen?
Reproduzierbarkeit und Tracking: Was sind die Standards für die Reproduzierbarkeit? Sollte das Team beispielsweise dieselbe Datenpipeline und dieselben Versionierungspraktiken verwenden oder ist es in Ordnung, nur Diagramme zu zeigen? Wie werden experimentelle Daten gespeichert: als SQL-Abfragen oder als Modell-Snapshots? Wo werden die Protokolle der einzelnen Tests dokumentiert: in einem Dokument, einer Tabelle oder einem CMS zur Verwaltung von Tests?
Falsche Vorhersagen
Kein Modell aus der Praxis ist perfekt. Wie geht Ihr System mit falschen Vorhersagen um? Überlegen Sie sich frühzeitig, wie Sie damit umgehen möchten.
Eine Best Practices-Strategie ermutigt Nutzer, falsche Vorhersagen richtig zu labeln. Beispielsweise erfassen E-Mail-Apps fälschlicherweise klassifizierte E-Mails, indem sie die E-Mails protokollieren, die Nutzer in den Spamordner verschieben, und umgekehrt. Wenn Sie Ground-Truth-Labels von Nutzern erfassen, können Sie automatisierte Feedbackschleifen für die Datenerhebung und die Modellneuschulung entwerfen.
Beachten Sie, dass in der Benutzeroberfläche eingebettete Umfragen zwar Nutzerfeedback erfassen, die Daten aber in der Regel qualitativ sind und nicht in die Daten für die Neuschulung einfließen können.
End-to-End-Lösung implementieren
Während Ihr Team mit dem Modell experimentiert, sollten Sie mit dem Aufbau von Teilen der endgültigen Pipeline beginnen, sofern Sie die dafür erforderlichen Ressourcen haben.
Wenn Sie verschiedene Teile der Pipeline einrichten, z. B. die Datenaufnahme und das erneute Training des Modells, lässt sich das endgültige Modell leichter in die Produktion übernehmen. So kann beispielsweise eine End-to-End-Pipeline zum Aufnehmen von Daten und Bereitstellen von Vorhersagen dem Team helfen, das Modell in das Produkt einzubinden und frühzeitige Nutzertests durchzuführen.
Fehlerbehebung bei in der Schwebe befindlichen Projekten
Es kann vorkommen, dass der Fortschritt eines Projekts ins Stocken gerät. Vielleicht arbeitet Ihr Team an einem vielversprechenden Test, kann das Modell aber seit Wochen nicht verbessern. Was solltest du tun? Im Folgenden sind einige mögliche Ansätze aufgeführt:
Strategic (strategische Phase). Möglicherweise müssen Sie das Problem neu formulieren. Nachdem Sie einige Zeit in der Testphase verbracht haben, verstehen Sie das Problem, die Daten und die möglichen Lösungen wahrscheinlich besser. Mit einem besseren Verständnis der Branche können Sie das Problem wahrscheinlich genauer formulieren.
Angenommen, Sie wollten ursprünglich die lineare Regression verwenden, um einen numerischen Wert vorherzusagen. Leider waren die Daten nicht gut genug, um ein praktikables lineares Regressionsmodell zu trainieren. Vielleicht zeigt eine weitere Analyse, dass das Problem gelöst werden kann, indem vorhergesagt wird, ob ein Beispiel über oder unter einem bestimmten Wert liegt. So können Sie das Problem als binäre Klassifizierung neu formulieren.
Wenn der Fortschritt langsamer als erwartet ist, geben Sie nicht auf. Kleine Verbesserungen im Laufe der Zeit sind möglicherweise die einzige Möglichkeit, das Problem zu lösen. Wie bereits erwähnt, solltest du nicht erwarten, dass du jede Woche denselben Fortschritt erzielst. Oftmals ist viel Zeit erforderlich, um eine produktionsreife Version eines Modells zu erhalten. Die Modellverbesserung kann unregelmäßig und unvorhersehbar sein. Auf Phasen mit nur langsamen Fortschritten können Phasen mit deutlichen Verbesserungen folgen oder umgekehrt.
Technisch Nehmen Sie sich Zeit, um falsche Vorhersagen zu diagnostizieren und zu analysieren. In einigen Fällen können Sie das Problem finden, indem Sie einige falsche Vorhersagen herausfiltern und das Verhalten des Modells in diesen Fällen diagnostizieren. So können Sie beispielsweise Probleme mit der Architektur oder den Daten aufdecken. In anderen Fällen kann es hilfreich sein, mehr Daten zu erheben. Möglicherweise erhalten Sie ein klareres Signal, das darauf hindeutet, dass Sie auf dem richtigen Weg sind. Es kann aber auch mehr Rauschen verursachen, was auf andere Probleme im Ansatz hinweist.
Wenn Sie an einem Problem arbeiten, für das von Menschen beschriftete Datensätze erforderlich sind, ist es möglicherweise schwierig, einen beschrifteten Datensatz für die Modellbewertung zu erhalten. Hier finden Sie Ressourcen, mit denen Sie die Datensätze für die Bewertung abrufen können.
Möglicherweise ist keine Lösung möglich. Legen Sie einen Zeitrahmen für Ihren Ansatz fest und beenden Sie ihn, wenn Sie innerhalb des Zeitrahmens keinen Fortschritt erzielt haben. Wenn Sie jedoch eine gute Problembeschreibung haben, rechtfertigt das wahrscheinlich eine Lösung.
Wissen testen
Ein Teammitglied hat eine Kombination von Hyperparametern gefunden, mit der sich der Messwert des Ausgangsmodells verbessern lässt. Was sollten die anderen Teammitglieder tun?
Vielleicht einen Hyperparameter einbeziehen, aber mit den Tests fortfahren.
Korrekt. Wenn einer der Hyperparameter eine vernünftige Wahl zu sein scheint, können Sie ihn ausprobieren. Nicht alle Hyperparameter sind jedoch in jedem Testkontext sinnvoll.
Ändern Sie alle Hyperparameter in Ihrem aktuellen Test so, dass sie mit denen Ihres Kollegen übereinstimmen.
Hyperparameter, die ein Modell verbessert haben, führen nicht automatisch zu einer Verbesserung eines anderen Modells. Die anderen Teammitglieder sollten mit ihren Tests fortfahren, was die Baseline später sogar noch verbessern könnte.
Erstellen Sie eine End-to-End-Pipeline, die zum Implementieren des Modells verwendet wird.
Ein Modell, das die Baseline verbessert, ist nicht unbedingt das Modell, das letztendlich in der Produktion verwendet wird. Sie sollten mit ihren Tests fortfahren, da sich die Baseline später möglicherweise noch weiter verbessern lässt.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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\nNoise 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\nAlign 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\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\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\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\nCheck Your Understanding \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)"]]
