Vertex AI AutoML prognostiziert Trends aus Daten

Vor der nächsten Bestellrunde möchte eine Einzelhändlerin wissen, welche Produkte stärker nachgefragt werden. Sie muss entscheiden, was sie bestellt, bevor der Vorrat knapp wird.

Mit Vertex AI AutoML kann sie aus tabellarischen Daten ein Prognosemodell für diese Geschäftsfrage vorbereiten. Der Ablauf führt von der Fragestellung über das Dataset und das Training bis zu Vorhersagen.

Der Nutzen hängt nicht allein von der Technik ab. Passende und saubere Daten sind entscheidend, damit die Ergebnisse im Alltag helfen. Ein Modell kann fehlende Erfahrung aus den Daten nicht einfach ausgleichen.

Wichtige Punkte

• Eine Prognose braucht eine messbare Zielgröße.
• Der Modelltyp richtet sich nach der Zielspalte.
• Historische Daten müssen die spätere Anwendung abbilden.
• Training und Testauswertung beantworten verschiedene Fragen.
• Vorhersagen lassen sich einzeln oder gebündelt abrufen.
• Bereitstellung kann Kosten für Cloud-Ressourcen verursachen.

Bevor die Händlerin ein Projekt in Google Cloud startet, muss sie ihr Anliegen genau fassen. Zuerst klärt sie, was sich mit einer Prognose aus Tabellendaten beantworten lässt.

Welche Trendfragen lassen sich mit tabellarischen Daten beantworten?

„Wie viele Einheiten dieses Produkts werden nächste Woche täglich benötigt?“ ist eine messbare Frage. Für eine brauchbare Antwort braucht die Händlerin eine konkrete Zielgröße, nicht nur eine allgemeine Beschreibung eines Trends.

Eine Zeitreihenprognose ist die Vorhersage künftiger Werte in einer zeitlichen Reihenfolge anhand früherer Beobachtungen. Das Modell braucht eine vorherzusagende Zahl und Daten, die zu dieser Frage passen. Ein vages Anliegen wie „Was wird beliebter?“ liefert noch kein eindeutiges Lernziel.

Formulieren Sie eine messbare Frage, bevor Sie Daten für ein Prognosemodell auswählen. Ohne klare Zielgröße bleibt auch das Ergebnis unklar.

Bei der Nachfrageprognose bilden frühere Tagesverkäufe, Produktart, Preis und Werbeaktionen mögliche Eingaben. Die vorherzusagende Spalte ist die täglich verkaufte Stückzahl für den künftigen Zeitraum.

Diese Eingabespalten heißen Features. Sie zeigen, was vor der Vorhersage bekannt ist, etwa Wochentag oder Lagerbestand. Eine spätere Entscheidung darf nicht als Eingabe dienen, wenn sie zum Prognosezeitpunkt noch unbekannt ist.

Eine Trendbeschreibung fasst oft zusammen, dass Verkäufe in einer Saison steigen. Eine Vorhersage nennt dagegen erwartete Werte, etwa 18 Einheiten am Montag und 22 am Dienstag.

Ein machine learning-Modell sucht Muster in Beispielen, aber es kann keine fehlende Fragestellung erraten. Der case sollte deshalb festlegen, für welches Produkt und welchen Zeitraum die Vorhersage gilt.

Auch ein gutes example muss einen klaren objective haben. Die Händlerin könnte eine Prognose für jedes Produkt und jeden Tag wünschen. Oder sie könnte nur wissen wollen, ob der Bedarf über einer Bestellgrenze liegt.

Diese Entscheidung bestimmt, welche Werte das Modell lernen soll. Übergeben Sie die geklärte Zielgröße an die Entscheidung, welcher Modelltyp zu ihr passt.

Wie hilft Vertex AI AutoML bei der Trendprognose?

Manuell müssten Fachleute ein Modellverfahren auswählen, programmieren und anpassen. Ein verwalteter Ablauf kann viele Schritte automatisieren, wenn Sie passende Beispieldaten bereitstellen.

AutoML übernimmt wesentliche Schritte der Modellerstellung und Feinabstimmung, aber nicht die Verantwortung für die Aufgabe. Sie legen das Ziel fest, prüfen die Daten und entscheiden, ob die Ergebnisse für Ihren Betrieb taugen.

Was AutoML im Trainingsablauf übernimmt

Beim training untersucht das System Muster zwischen den Eingabespalten und der Zielspalte. Es vergleicht mögliche Einstellungen und erstellt ein model, ohne dass Sie jeden Rechenschritt selbst programmieren.

Der verwaltete Ansatz senkt die technische Einstiegshürde. Trotzdem müssen Sie beurteilen, ob Beispiele die spätere Nutzung abbilden. Ein Modell kann auch aus sauber verarbeiteten, aber ungeeigneten Daten falsche Schlüsse ziehen.

AutoML ist daher kein Ersatz für Fachwissen über den Geschäftsfall. Die Händlerin kennt etwa Lieferzeiten und Aktionen, die in historischen Tabellen fehlen könnten. Ohne solche Informationen kann ein model wichtige Nachfragesprünge verpassen.

Was Google AutoML und frühere Angebote damit zu tun haben

Was ist Google AutoML? Der Begriff bezeichnet Googles verwalteten Ansatz für maschinelles Lernen, zu dem frühere Angebote wie Cloud AutoML und AutoML Tables gehörten.

Diese früheren Produktnamen helfen, ältere Anleitungen einzuordnen. Sie sind keine eigene Anleitung für den aktuellen Ablauf in Vertex AI. Die verfügbaren Funktionen und Bezeichnungen in der Google Cloud Console können je nach Aufgabe variieren.

Machine learning bleibt der technische Bereich, in dem Modelle aus Beispielen lernen. AutoML macht bestimmte Arbeitsschritte zugänglicher, während Ziel, Datenqualität und Ergebnisprüfung bei Ihnen bleiben.

Bevor Sie Daten vorbereiten, müssen Sie wissen, ob das Ergebnis eine Zahl über Zeit, einen anderen Zahlenwert oder eine Klasse sein soll. Von der Arbeitsweise führt der Weg zur Auswahl des Prognoseziels und Modelltyps.

Welcher Modelltyp passt zu Ihrer Prognose?

Ein Verkaufsdatensatz kann drei verschiedene Fragen beantworten: Wie viele Einheiten werden gebraucht, wie hoch wird der Umsatz, und welche Produktkategorie verkauft sich? Die passende Wahl hängt von der Zielspalte ab.

Forecasting sagt Werte über die Zeit voraus, Regression schätzt Zahlen und Klassifikation wählt eine Klasse. Der Inhalt der Zielspalte bestimmt, welche Art von Ergebnis das Modell lernen soll.

Forecasting für Werte über die Zeit

Forecasting passt, wenn die Zielgröße in zeitlicher Reihenfolge vorhergesagt werden soll. Bei der Händlerin sind das etwa tägliche Produktverkäufe für die kommenden Tage.

Die Zeitangaben und die Zuordnung zu einer Produktreihe müssen stimmen. So kann das Modell frühere Werte derselben Produktgruppe mit künftigen Werten vergleichen.

Regression und Klassifikation für andere Zielgrößen

Regression eignet sich für einen fortlaufenden Zahlenwert, etwa einen erwarteten Geldbetrag. Klassifikation ordnet einen Fall dagegen einer Gruppe zu, etwa „hohe Nachfrage“ oder „niedrige Nachfrage“.

Eine Klassifikation kann mehrere Klassen enthalten. Wählen Sie Classification nicht allein deshalb, weil Eingabewerte Zahlen enthalten. Entscheidend ist, ob die Zielspalte einen Zahlenwert oder eine Klasse enthält.

Die Eingabespalten dürfen ebenfalls Zahlen enthalten, ohne daraus eine Klassifikation zu machen. Eine Spalte mit Preiswerten kann als Feature dienen, während das Modell einen Geldbetrag vorhersagt.

Wenn die Händlerin die Zielart bestimmt hat, kann sie passende Beispiele suchen. Führen Sie von der Zielart zu den Daten, die eine belastbare Antwort ermöglichen.

Welche Daten braucht ein belastbares Prognosemodell?

Forecasting braucht als Richtwert deutlich mehr Beispiele als einfache Klassifikation oder Regression. Als Orientierung gelten für Forecasting 5.000 Zeilen mal Feature-Anzahl und 10 eindeutige Werte in der Zeitreihen-ID-Spalte mal Feature-Anzahl.

Diese dokumentierten Richtwerte sind Empfehlungen, keine Garantie für ein gutes Ergebnis. Die Daten müssen zudem zur späteren Anwendung passen und genügend unterschiedliche Situationen abdecken.

Umfang und Vielfalt der Beispieldaten

Als grobe Richtwerte für tabellarische Aufgaben gelten:

• Klassifikation: 50 Zeilen multipliziert mit der Anzahl der Features.
• Regression: 200 Zeilen multipliziert mit der Anzahl der Features.
• Forecasting: 5.000 Zeilen multipliziert mit der Anzahl der Features.
• Forecasting: 10 eindeutige Werte in der Zeitreihen-ID-Spalte multipliziert mit der Anzahl der Features.

Bei 12 Features entspräche der erste Forecasting-Richtwert 60.000 Zeilen. Das ist keine feste Grenze und sagt nicht aus, ob die Werte gut genug sind.

Ein Dataset mit vielen ähnlichen Zeilen kann weniger hilfreich sein als ein kleineres Dataset mit passenden Beispielen. Eine Händlerin braucht etwa Fälle aus Wochen mit normalen Verkäufen und Wochen mit Aktionen.

Zeitbezug und passende Features

Bei einer Zeitreihe sollten die Beobachtungen in einer passenden Reihenfolge liegen. Auch der Abstand zwischen Messungen muss zur geplanten Vorhersage passen, etwa täglich statt monatlich.

Ein Datensatz mit nur einer Saison kann saisonale Unterschiede nicht gut abbilden. Ebenso kann eine enge Kundengruppe die Anwendung auf andere Kundinnen und Kunden verzerren.

Features sollten die spätere Entscheidung stützen. Produktart, Preis und geplante Aktion können relevant sein, wenn sie für den Prognosezeitpunkt bekannt sind.

Ein test mit Daten aus derselben engen Situation reicht nicht aus, um die Vielfalt für den Alltag zu belegen. Prüfen Sie, ob die Beispiele unterschiedliche Zeiten und Fälle abdecken.

Wenn diese Daten fehlen, sollten Sie passende Beobachtungen ergänzen, statt nur auf mehr Zeilen zu setzen. Danach stellt sich die Frage, aus welchen Quellen sich ein passendes Dataset zusammensetzen lässt.

Woher kommen die Daten und wie importieren Sie sie?

Eine bereitgestellte CSV-Datei muss erst eingelesen werden; eine Tabelle in BigQuery liegt bereits in Google Cloud. Die passende Quelle richtet sich danach, wo Ihre Daten schon liegen und wie Sie sie verwalten.

Lokale Dateien, Cloud Storage und BigQuery bieten verschiedene Wege in ein Dataset. Ein Bucket in Cloud Storage kann viele Dateien enthalten und ist nicht mit einer einzelnen Datei gleichzusetzen.

Lokale Dateien, Cloud Storage und BigQuery

Cloud Storage speichert Dateien in Buckets. Ein Bucket kann mehrere Datenbestände und Dateien enthalten, die verschiedene Aufgaben bedienen.

BigQuery eignet sich, wenn die Tabelle dort schon bereitsteht. Ein greifbares Beispiel ist bigquery-public-data.ml_datasets.ulb_fraud_detection. Die Tabelle enthält Transaktionen für eine Betrugsklassifikation.

Formate und Importentscheidung

CSV und JSON Lines sind mögliche Dateiformate im beschriebenen Importablauf. Wählen Sie ein Format, das die Werte und Spalten Ihrer Quelle klar abbildet.

Eine lokale Datei kann praktisch sein, wenn ein Team sie bereits exportiert hat. Cloud Storage hilft, wenn die Datei für weitere Cloud-Arbeit verfügbar sein soll. BigQuery spart einen Datei-Export, wenn die Daten dort liegen.

Auch bei AutoML Tables in älteren Anleitungen sollten Sie Quelle und aktuellen Ablauf auseinanderhalten. Die Importentscheidung hängt von Ihren vorhandenen Tabellen und Dateien ab, nicht vom alten Produktnamen.

Bevor Sie Daten einlesen, klären Sie, ob die Quelle zugänglich und vollständig ist. Nach der Quellenwahl folgt die Prüfung der Spalten und Werte.

Wie bereiten Sie Zielspalte, Zeitangaben und Features vor?

Eine künftig bekannte Zahlung kann die Zielinformation verraten, wenn Sie damit eine Anmeldung vorhersagen wollen. Prüfen Sie deshalb, ob jedes Feature zum tatsächlichen Vorhersagezeitpunkt verfügbar ist.

Entfernen Sie Eingaben, die erst nach dem vorherzusagenden Ereignis bekannt werden. Sonst kann das Modell im Test gut wirken und später im Einsatz scheitern.

Ziel und Eingabespalten sauber trennen

Gehen Sie diese Prüfungen der Reihe nach durch:

• Legen Sie die Zielspalte eindeutig fest.
• Kontrollieren Sie Bedeutung und Typ jeder Spalte.
• Sichten Sie fehlende, fehlerhafte oder uneinheitliche Werte.
• Prüfen Sie bei Forecasting die Abstände zwischen Zeitwerten.
• Behalten Sie nur Eingaben, die bei der Vorhersage verfügbar sind.

Ein Feature wie eine erst künftig gebuchte Zahlung wäre bei einer früheren Anmeldeprognose nicht bekannt. Es verrät indirekt, was später geschah. Dieses Problem heißt Data Leakage.

Ein eindeutiges ID-Feld wirkt auf den ersten Blick nützlich, kann aber nur einzelne Datensätze kennzeichnen. Das Modell lernt daraus womöglich keine wiederkehrende Eigenschaft, sondern eine zufällige Zuordnung.

Fehlende Werte und uneinheitliche Daten prüfen

Fehlende Werte können verarbeitet werden, doch vollständige und konsistente Daten begünstigen bessere Ergebnisse. Prüfen Sie etwa, ob dieselbe Produktkategorie mit mehreren Schreibweisen auftaucht.

Training-Serving-Skew entsteht, wenn Trainingsdaten und spätere Einsatzdaten unterschiedlich aussehen. Ein Beispiel sind wöchentliche Trainingswerte, während das Modell später stündliche Werte erhält.

Auch ein anderer Spaltentyp kann die Nutzung stören. Eine Zahl, die beim Training als Text eingeht, lässt sich nicht ohne Weiteres wie ein Zahlenwert behandeln.

Wenn die Spalten geprüft sind, können Sie das Dataset in der Google Cloud Console anlegen. Die Datenprüfung muss dabei zum späteren Einsatz passen.

Wie legen Sie das Dataset in der Google Cloud Console an?

Wählen Sie zuerst das richtige Google-Cloud-Projekt in der Google Cloud Console aus. Das Projekt bestimmt, in welchem Cloud-Arbeitsbereich Sie das Dataset anlegen.

Prüfen Sie nach dem Import Datentypen und die Zulässigkeit leerer Werte. Menünamen können sich ändern, der grundlegende Ablauf bleibt aber an Projekt, Aufgabe und Datenquelle gebunden.

1. Wählen Sie in der Google Cloud Console das passende Google-Cloud-Projekt aus.
2. Öffnen Sie Vertex AI und den Bereich für Daten oder Datasets.
3. Legen Sie ein neues Dataset an und vergeben Sie einen klaren Namen.
4. Wählen Sie Tabular sowie Regression oder Classification als Aufgabe.
5. Wählen Sie eine Importquelle, etwa lokale Datei, Cloud Storage oder BigQuery.
6. Starten Sie den Import und warten Sie, bis die Daten eingelesen sind.

Die Auswahl Tabular passt zu strukturierten Daten in Zeilen und Spalten. Die angebotenen Aufgaben hängen davon ab, welche Prognose Sie erstellen möchten.

Nach dem Import kann eine Statistikansicht Spalten und fehlende Werte zeigen. Nutzen Sie sie, um auffällige Typen oder große Lücken zu finden.

Eine Zahlenspalte sollte nicht versehentlich als Text erscheinen, wenn Sie mit ihr rechnen möchten. Kontrollieren Sie auch, ob leere Werte in den betroffenen Spalten erlaubt sind.

Die Konsolenoberfläche kann je nach Aufgabe andere Reiter oder Schritte anzeigen. Folgen Sie den aktuellen Feldnamen und prüfen Sie jede Auswahl vor dem Import.

Wenn das Dataset bereitsteht und die Spalten stimmen, können Sie den Trainingslauf vorbereiten. Vom Dataset führt der Weg zur Konfiguration des Trainings.

Wie konfigurieren und starten Sie das Training?

Vor dem Start müssen drei Entscheidungen feststehen: Zielspalte, Modellziel und Trainingsfeatures. Diese Reihenfolge hilft, Aufgabe und Eingaben sauber auseinanderzuhalten.

Prüfen Sie alle verwendeten Features, auch wenn standardmäßig alle Nicht-Zielspalten ausgewählt sind. Ungeeignete oder erst später verfügbare Spalten können die Testwerte irreführend machen.

Trainingsziel und Spalten festlegen

Wählen Sie zuerst die Zielspalte, die das Modell lernen soll. Danach legen Sie das Modellziel fest, etwa Regression oder Classification, passend zum Inhalt dieser Spalte.

Wählen Sie anschließend die Features für das Training. Der default kann alle Spalten außer der Zielspalte verwenden. Prüfen Sie IDs, spätere Ergebnisse und irrelevante Felder einzeln.

Sie können Daten automatisch oder manuell aufteilen. Bei der automatischen Option übernimmt der Ablauf die Aufteilung. Eine manuelle Aufteilung ist nützlich, wenn Sie bestimmte Zeilen für die Prüfung zurückhalten möchten.

Verwenden Sie für eine zeitliche Prognose keine zufällige Aufteilung, wenn sie die zeitliche Reihenfolge zerstört. Die Testauswertung soll die spätere Vorhersage möglichst realitätsnah prüfen.

Budget prüfen und den Trainingslauf starten

Vor dem Start sehen Sie Optionen für das Trainingsbudget. Ein Betrugsklassifikations-Lab nutzte als Beispiel ein Budget von einer Node-Stunde.

Die gesamte Laufzeit kann länger als eine Stunde sein, weil das Hoch- und Herunterfahren zusätzliche Zeit benötigt. Ein anderes Bankmarketing-Beispiel dauerte ungefähr zwei Stunden.

Diese Werte sind Beispiele, keine Zusage für Ihre Laufzeit. Datenumfang, Aufgabe und genutzte Ressourcen beeinflussen, wie lange ein Trainingslauf dauert.

Prüfen Sie Projekt, Zielspalte, Features und Budget, bevor Sie den Job starten. Wählen Sie dann Start training, um den Trainingsjob anzustoßen.

Ein Status zeigt, ob der Lauf noch arbeitet oder abgeschlossen ist. Vom laufenden beziehungsweise abgeschlossenen Training führt der nächste Schritt zur Prüfung der Modellqualität.

Woran erkennen Sie, ob das Modell brauchbare Prognosen liefert?

Bei einer Betrugserkennung kann hohe Gesamtgenauigkeit täuschen, wenn das Modell viele Betrugsfälle übersieht. Prüfen Sie deshalb die seltene Klasse gesondert und verlassen Sie sich nicht auf eine einzelne Kennzahl.

Eine Testauswertung muss zur Aufgabe und zu den Folgen falscher Vorhersagen passen. Accuracy zeigt den Anteil richtiger Gesamtentscheidungen, sagt bei ungleichen Klassen aber nicht alles aus.

Kennzahlen passend zur Zielaufgabe lesen

Bei Regression oder Forecasting sollten Sie prüfen, wie weit vorhergesagte Zahlen von den tatsächlichen Werten abweichen. Bei Klassifikation zählt zusätzlich, welche Arten von Fehlern auftreten.

Im konkreten Betrugsdatensatz machen Betrugsfälle weniger als 1 Prozent aus. Die erste Modellversion erkannte in der Testmenge 85 Prozent der Betrugsbeispiele korrekt.

Die genaue Prozentzahl kann variieren und ist kein allgemeiner Qualitätsmaßstab. Ein anderes Dataset, eine andere Aufteilung oder ein anderer Trainingslauf kann andere Werte ergeben.

Fehlerklassen und Feature Importance einordnen

Eine Confusion Matrix trennt etwa richtig erkannte Betrugsfälle von übersehenen Fällen und Fehlalarmen. So sehen Sie, ob die seltene Klasse ausreichend erkannt wird.

Feature Importance zeigt, welche Features für die Modellentscheidung wichtig waren. Sie beweist nicht, dass eine Spalte die Ursache eines Ergebnisses ist.

Vergleichen Sie Kennzahlen mit den Folgen im Betrieb. Ein Händler kann eine verfehlte Nachfragespitze anders bewerten als eine unnötige Warnung.

Wenn die Testauswertung für den Praxiseinsatz spricht, entscheiden Sie, wie Sie Vorhersagen bereitstellen. Von der Auswertung führt der Weg zur Wahl des passenden Bereitstellungswegs.

Wie stellen Sie das trainierte Modell für Vorhersagen bereit?

Eine einzelne neue Anfrage unterscheidet sich von einer Datei mit vielen Prognosefällen. Wählen Sie Online- oder Batch-Vorhersage passend zur Zahl und zum Zeitbedarf der Anfragen.

Ein bereitgestelltes Modell kann über einen Endpunkt angesprochen werden. Ein Modell kann mehrere Endpunkte haben, und Sie können Traffic zwischen diesen Endpunkten aufteilen.

Online-Vorhersagen über einen Endpunkt

Eine Online-Vorhersage passt, wenn eine Anwendung einen einzelnen neuen Fall zeitnah bewertet. Ein Endpunkt nimmt die Anfrage entgegen und gibt das Ergebnis zurück.

Auch wiederholte Anfragen können über einen Endpunkt laufen, etwa wenn eine Anwendung laufend neue Verkaufsdaten prüft. Achten Sie dabei auf die benötigte Antwortzeit und die tatsächliche Nutzung.

Batch-Vorhersagen für viele Datensätze

Batch-Vorhersage eignet sich, wenn viele Zeilen gemeinsam verarbeitet werden sollen. So kann die Händlerin etwa einen Bestand an Produkt- und Tagesdaten auf einmal bewerten lassen.

Bereitstellung kann Betriebskosten verursachen. Die Höhe hängt von den genutzten Ressourcen und dem Betrieb ab; konkrete aktuelle Europreise lassen sich hier nicht nennen.

Lassen Sie einen Testendpunkt nicht dauerhaft laufen, wenn Sie ihn nicht nutzen. Prüfen Sie den Bedarf, bevor Sie ein Modell für den Betrieb bereitstellen.

Wenn der Bereitstellungsweg feststeht, können Sie eine Vorhersage auslösen. Das führt zu den konkreten Wegen, einzelne oder viele Ergebnisse abzurufen.

Wie rufen Sie einzelne oder gebündelte Vorhersagen ab?

Ein Test über die Oberfläche eignet sich für wenige Werte; eine Anwendung braucht meist eine dynamische Anfrage. Die Oberfläche kann Testwerte für Features annehmen und Klassen mit Konfidenzwerten zurückgeben.

Eine Ausgabe aus einem einzelnen Testfall ist kein Produktionsversprechen. Sie zeigt, wie das Modell auf genau diese Eingabe reagiert.

Vorhersage in der Oberfläche testen

Geben Sie passende Werte für die Features ein, die das Modell erwartet. Die Oberfläche zeigt dann die vorhergesagte Klasse und einen Konfidenzwert.

Im Betrugserkennungs-Lab lag ein Beispielwert für Klasse 0 bei ungefähr 0,67. In genau diesem Testfall bedeutet das eine Wahrscheinlichkeit von 67 Prozent für „nicht betrügerisch“.

Der Wert gilt nur für diese Eingabe und dieses Modell. Eine andere Transaktion kann zu einer anderen Klasse oder Konfidenz führen.

Vorhersage über SDK oder API anfragen

Eine Anwendung kann das Modell über ein SDK oder eine API ansprechen. Dafür braucht der Aufruf das Projekt, die Region, die Endpunktkennung und passende Instanzwerte.

AutoML Python ist ein möglicher SDK-Zugangsweg. Die genaue Nutzung hängt von der eingesetzten Version und dem Modelltyp ab. Ein vollständiger Codeblock wäre ohne diese Angaben leicht irreführend.

Für viele Eingaben wählen Sie eine Batch-Vorhersage statt einzelner API-Aufrufe. So können Sie umfangreiche Datenmengen als gemeinsamen Lauf verarbeiten.

Behandeln Sie Beispielwerte nie als verlässliche Produktionsvorhersage. Prüfen Sie reale Anfragen im vorgesehenen Ablauf, bevor Sie Entscheidungen automatisieren.

Wenn ein Einzeltest funktioniert, sollten Sie auch Kosten, Zugriff und verantwortlichen Einsatz klären. Der funktionierende Test führt so zu den Betriebsbedingungen.

Welche Kosten- und Datenschutzfragen sollten Sie vorab klären?

Eine Trainingszeit im Budget ist nicht dasselbe wie die tatsächlich abgerechnete Nutzung eines Cloud-Projekts. Die Nutzung kann Training und bereitgestellte Ressourcen umfassen.

Die Kosten hängen von den genutzten Ressourcen und der Bereitstellung ab. Die Schätzung von etwa 22 US-Dollar gilt nur für genau den beschriebenen Cloud-Lab-Lauf, nicht als aktueller Preis für ein deutsches Projekt.

Trainings- und Bereitstellungsaufwand einschätzen

Die Frage nach Google AutoML pricing betrifft mehr als den Trainingslauf. Prüfen Sie Training und bereitgestellte Ressourcen getrennt, weil beide unterschiedliche Cloud-Nutzung auslösen können.

Das beschriebene Lab verlangt ein Google-Cloud-Projekt mit aktivierter Abrechnung. Daraus folgt nicht, dass Google Cloud allgemein kostenlos genutzt werden kann.

Die Höhe hängt vom gewählten Dienst, den Ressourcen und der Nutzungsdauer ab. Ein bereitgestellter Endpunkt kann auch dann Aufwand verursachen, wenn nur wenige Vorhersagen eingehen.

Zugriff und verantwortliche Datennutzung prüfen

Beschränken Sie den Zugriff auf Personen, die Dataset und Modell für ihre Arbeit brauchen. Sensible oder unzulässige Daten sollten Sie nicht ungeprüft importieren.

Prüfen Sie, welche Bedeutung die Daten haben und wer Ergebnisse sehen darf. Auch ein Modell ohne direkte Kennzeichnung kann sensible Muster aus Eingabedaten übernehmen.

Fairness gehört zur verantwortlichen Nutzung. Prüfen Sie, ob Fehler bestimmte Gruppen stärker treffen, und lassen Sie wichtige Entscheidungen von Menschen kontrollieren.

Ein guter Testwert allein rechtfertigt keine automatische Entscheidung. Legen Sie fest, wer Ergebnisse überwacht und wie das Team auf auffällige Vorhersagen reagiert.

Wenn Projekt, Zugriff und Nutzung geklärt sind, bleibt die laufende Verbesserung. Von den Betriebsbedingungen führt der Weg zu häufigen Fehlerquellen und passenden Korrekturen.

Wie verbessern Sie das Modell und vermeiden typische Fehler?

Eine unerwartete Nachfrageprognose ist ein Anlass, zuerst Daten und Zielspalte zu prüfen, statt sofort das Trainingsbudget zu erhöhen. Relevante Eingaben helfen mehr als zusätzliche Rechenzeit allein.

Mehr Trainingszeit ersetzt keine passenden und vielfältigen Daten. Suchen Sie die Ursache für schwache Ergebnisse systematisch und vergleichen Sie Änderungen mit einer frischen Testauswertung.

Prüfen Sie zuerst Ziel, Daten und Verfügbarkeit der Features. Mehr Trainingszeit allein macht eine ungeeignete Datengrundlage nicht passend.

Ergebnisse mit geeigneten neuen Daten verbessern

Nutzen Sie diese Checkliste für den nächsten Prüfpunkt:

• Prüfen Sie die Zielspalte und die Typen der Spalten erneut.
• Suchen Sie nach Data Leakage durch spätere Informationen.
• Bereinigen Sie fehlende oder uneinheitliche Werte.
• Ergänzen Sie saisonale und zeitliche Vielfalt.
• Prüfen Sie, ob Features zum Vorhersagezeitpunkt verfügbar sind.
• Vergleichen Sie Änderungen mit einer frischen Testauswertung.

Bei einer Nachfrageprognose kann eine einzelne Saison wichtige Unterschiede verbergen. Ergänzen Sie Daten aus verschiedenen Zeiten, wenn diese den späteren Einsatz besser abbilden.

Fehler systematisch eingrenzen

Prüfen Sie zuerst, ob das Modell die richtige Zielspalte nutzt. Danach kontrollieren Sie Spaltentypen, fehlende Werte und die Bedeutung der Features.

Feature Importance kann zeigen, welche Eingaben bei Vorhersagen wichtig waren. Bei einem Dataset mit verschleierten Spaltennamen ist diese Auswertung jedoch nur eingeschränkt interpretierbar.

Entfernen Sie kein Feature nur wegen eines einzelnen Testfalls. Ein einzelner Fall kann ungewöhnlich sein und muss kein dauerhaftes Muster zeigen.

Vergleichen Sie neue Daten oder geänderte Features mit einer frischen Testauswertung. So sehen Sie, ob die Änderung hilft oder nur einen einzelnen Fehler verschiebt.

Für den nächsten Schritt gilt: Prüfen Sie zuerst die Zielspalte, wenn das Ergebnis unplausibel ist. Ergänzen Sie Daten, wenn eine wichtige Saison fehlt, und schließen Sie mit einem konkreten Plan für den nächsten Test.

Fazit

Eine belastbare Prognose beginnt mit einer klaren Frage, nicht mit dem Startknopf. Die Zielspalte muss genau festlegen, welcher Wert vorhergesagt werden soll.

Realitätsnahe und saubere Daten bilden die Grundlage für ein nützliches Modell. Die Testauswertung muss zur Aufgabe passen und zeigen, welche Fehler im Betrieb zählen.

Halten Sie für einen konkreten Anwendungsfall die Zielgröße und die verfügbaren historischen Daten in einer kleinen Projektprüfung fest. Schreiben Sie zuerst auf, was Sie vorhersagen möchten und welche Daten dafür bereits vorliegen.