Vorhersagen – Grundlagen

Sie können Ihre trainierten Modelle für maschinelles Lernen in der Cloud hosten und den Cloud ML-Vorhersagedienst zur Ableitung von Zielwerten für neue Daten verwenden. Auf dieser Seite werden das Modellhosting und Vorhersagen erläutert sowie Überlegungen angesprochen, die Sie bei Ihren Projekten berücksichtigen sollten.

Funktionsweise

Der Cloud ML Engine-Vorhersagedienst verwaltet die Rechenressourcen für die Ausführung Ihrer Modelle in der Cloud. Sie können Vorhersagen aus Ihren Modellen anfordern, um dafür vorhergesagte Zielwerte zu erhalten. Zum Einrichten von Vorhersagen in der Cloud gehen Sie wie folgt vor:

  1. Exportieren Sie Ihr Modell mithilfe von SavedModel als Teil Ihrer Trainingsanwendung.

  2. Erstellen Sie eine Modellressource in Cloud ML Engine und dann eine Modellversion aus Ihrem gespeicherten Modell.

  3. Formatieren Sie die Eingabedaten für die Vorhersage und fordern Sie entweder eine Onlinevorhersage oder eine Batchvorhersage an.

  4. Bei einer Onlinevorhersage führt der Dienst das gespeicherte Modell aus und gibt die angeforderten Vorhersagen als Antwort auf den Aufruf zurück.

    • Die Modellversion wird in der Region bereitgestellt, die Sie beim Erstellen des Modells angegeben haben.
    • Eine Modellversion, die Sie regelmäßig verwenden, ist normalerweise immer einsatzbereit, obwohl es dafür keine Garantie gibt.

    Bei Verwendung einer Batchvorhersage ist der Vorgang etwas komplizierter:

    1. Der Vorhersagedienst ordnet Ressourcen für die Ausführung des Jobs zu. Dazu werden ein oder mehrere Vorhersageknoten benötigt.

    2. Der Dienst stellt Ihre TensorFlow-Grafik auf jedem zugeordneten Knoten wieder her.

    3. Der Vorhersagedienst verteilt die Eingabedaten auf die zugeordneten Knoten.

    4. Jeder Knoten führt Ihre Grafik aus und speichert die Vorhersagen an einem von Ihnen angegebenen Google Cloud Storage-Speicherort.

    5. Wenn alle Eingabedaten verarbeitet wurden, beendet der Dienst den Job und gibt die dafür zugeordneten Ressourcen frei.

Modellbereitstellung

Cloud ML Engine kann Ihre Modelle hosten, sodass Sie die Vorhersagen dafür in der Cloud erhalten. Der Vorgang, mit dem ein gespeichertes Modell gehostet wird, heißt Bereitstellung. Der Vorhersagedienst verwaltet die für die skalierte Ausführung Ihres Modells erforderliche Infrastruktur. Ferner stellt er das Modell für Online- oder Batchvorhersageanfragen zur Verfügung. In diesem Abschnitt wird die Modellbereitstellung beschrieben.

Modelle und Versionen

Cloud ML Engine verwaltet trainierte Modelle mit Ressourcen, die als Modelle und Versionen bezeichnet werden. Ein Modell ist eine Lösung für maschinelles Lernen. Sie könnten beispielsweise ein Modell namens census erstellen, das Ihre gesamte Arbeit an einem US-Zensusmodell für maschinelles Lernen enthält. Die erstellte Entität namens census ist ein Container für die tatsächlichen Implementierungen des Modells für maschinelles Lernen. Diese werden als Versionen bezeichnet.

Die Entwicklung eines Modells für maschinelles Lernen ist ein iterativer Prozess. Aus diesem Grund sind die Ressourcen der Cloud ML Engine so eingerichtet, dass für die einzelnen Modelle für maschinelles Lernen verschiedene Versionen erstellt werden können. Die Begriffe können etwas verwirrend sein, da eine Cloud ML Engine-Modellressource kein Modell für maschinelles Lernen für sich allein ist. In Cloud ML Engine ist ein Modell ein Container für die Versionen eines Modells für maschinelles Lernen.

Inhalt einer Version

Das "Modell", das Sie in Cloud ML Engine als Modellversion bereitstellen, ist ein TensorFlow-SavedModel. Sie exportieren ein SavedModel in Ihren Trainer. Dabei spielt es keine Rolle, ob Sie das Modell in der Cloud ML Engine oder anderswo trainiert haben, solange Sie ein SavedModel verwenden, dessen Dienstsignatur auf serving_default gesetzt ist.

Abweichungen zwischen Versionen

Die Versionen, die Sie für eine bestimmte Modellressource erstellen, sind beliebig. Das bedeutet, dass Sie die gleiche Modellressource verwenden können, auch wenn Sie das Modell für maschinelles Lernen zwischen den Versionen vollständig ändern. Ein Modell ist ein Verwaltungstool, das Sie so einsetzen können, wie es für Ihre Situation am sinnvollsten ist.

Es ist üblich, dass Eingaben und Ausgaben der Modellversionen identisch sind, insbesondere wenn sich eine Version in der Produktion befindet. Dies ermöglicht ein schnelles Umschalten zwischen den Versionen, ohne dass Sie die umgebende Anwendungsstruktur, die Sie um das Modell eingerichtet haben, ändern müssen. Auch das Testen neuer Versionen mit vorhandenen Daten ist dadurch einfacher.

Standardversion

Jedes Modell mit mindestens einer Version hat eine Standardversion. Diese Voreinstellung wird bei der Erstellung der ersten Version festgelegt. Wenn Sie Vorhersagen anfordern und dabei nur einen Modellnamen angeben, verwendet Cloud ML Engine die Standardversion für dieses Modell.

Beachten Sie, dass der Dienst die Standardversion nur ein einziges Mal automatisch festlegt, wenn Sie die allererste Version erstellen. Sie können jede nachfolgende Version manuell als Standard festlegen, indem Sie projects.models.versions.setDefault aufrufen. Dieser Vorgang steht auch über gcloud ml-engine versions set-default und als Option in der Versionsliste der Seite "Modelldetails" in der Google Cloud Platform Console zur Verfügung (gehen Sie zur Seite mit den Modelldetails, indem Sie auf der Seite "Modelle" in der Modellliste auf Ihr Modell klicken). So können Sie beispielsweise in der Produktion eine stabile Standardversion für Vorhersagen verwenden und gleichzeitig neuere Versionen testen, ohne eine eigene Modellressource zum Testen zu erstellen.

Modelle und Versionen benennen

Für die Namen von Modellen und Versionen gilt Folgendes:

  • Sie dürfen sich nur aus Buchstaben (Groß-/Kleinschreibung beachten), Zahlen und Unterstrichen zusammensetzen.
  • Sie müssen mit einem Buchstaben beginnen.
  • Sie dürfen maximal 128 Zeichen enthalten.
  • Sie dürfen innerhalb eines Projekts (für Modelle) oder innerhalb eines Modells (für Versionen) nicht mehrfach vergeben sein.

Neben diesen technischen Anforderungen gibt es keine weiteren Namensregeln. Hier finden Sie jedoch einige Best Practices:

  • Modellnamen sollten aussagekräftig und unverwechselbar sein, sodass sie in Listen mit vielen Namen in Logs oder Berichten leicht zu finden sind.
  • Es empfiehlt sich, Versionsnamen möglichst kurz und einfach zu halten. So lässt sich "v1" in einer Liste von Ressourcen einfacher erkennen als beispielsweise "2017_01_29T13_54_58".

Modell- und Versionslimits

Die Kontingentrichtlinie von Cloud ML Engine beschränkt die Anzahl der Modelle pro Projekt auf 100 Modelle. Die Gesamtzahl der Versionen (für alle Modelle zusammen) ist auf 200 Versionen beschränkt.

Parameter für die Modellbereitstellung

Cloud ML Engine benötigt einige Informationen zum Erstellen Ihrer Modellversion. Außerdem gibt es einige Optionen, die Sie konfigurieren können. In diesem Abschnitt werden beide Parameterarten beschrieben. Diese Parameter werden im Objekt Version definiert oder dem Befehl gcloud ml-engine versions create hinzugefügt.

Versionsname
Ein Name für die neue Version, der unter den vorhandenen Versionsnamen des Modells noch nicht vergeben sein darf.
Beschreibung
Sie können eine Beschreibung zu Ihrer Version angeben. Derzeit wird die Beschreibung nur ausgegeben, wenn Sie die Versionsinformationen mit der API abrufen. Sie wird weder mit dem Befehlszeilentool gcloud noch in der Google Cloud Platform Console angezeigt.
Bereitstellungs-URI
Sie müssen den URI des Cloud Storage-Speicherorts angeben, an dem Ihr SavedModel gespeichert ist. Cloud ML Engine ruft das Modell aus diesem Speicherort ab und stellt es bereit. Dies geschieht mit dem Parameter --origin des Befehls gcloud ml-engine versions create.
Laufzeitversion
Cloud ML Engine verwendet die neueste stabile Laufzeitversion, um Ihre Modellversion bereitzustellen, sofern Sie keine andere unterstützte Version angegeben haben. Die Laufzeitversion legt in erster Linie die Version von TensorFlow fest, die der Vorhersagedienst für die Ausführung Ihres Modells verwendet. Wenn Sie einen Batchvorhersagejob ausführen, können Sie die zugeordnete Laufzeitversion überschreiben. Onlinevorhersagen verwenden immer die Laufzeitversion, die bei der Bereitstellung der Modellversion festgelegt wurde.
Manuelle Skalierung

Sie können die Anzahl der Trainingsknoten festlegen, die für Ihre Modellversion bereitstehen. Weitere Informationen hierzu finden Sie im Abschnitt "Skalierung".

Staging-Bucket

Wenn Sie Ihr Modell mit dem Befehlszeilentool gcloud bereitstellen, können Sie ein SavedModel auf Ihrem lokalen Computer verwenden. Das Tool implementiert es an dem Cloud Storage-Speicherort, den Sie angeben, bevor es in Cloud ML Engine bereitgestellt wird.

Grafikänderungen für Vorhersagen

Unter Umständen haben Sie TensorFlow-Vorgänge in Ihre Berechnungsgrafik eingebunden, die in erster Linie im Kontext des Trainings nützlich waren. Sie können diese Vorgänge aus der Grafik entfernen, wenn Ihr Modell trainiert und bereit für den Export der endgültigen Version ist.

Viele Tipps auf der Seite zur Entwicklung von Trainingsanwendungen handeln von Erfahrungswerten in Bezug auf Vorhersagen. In manchen Fällen geht es dabei um Änderungen, die Sie an Ihrem Modell vornehmen können, wenn der Großteil des Trainings durchgeführt ist und Sie mit der Bereitstellung von Versionen beginnen können.

Vorhersagen abrufen

Sie können neue Daten an Ihre bereitgestellten Modellversionen senden, um Vorhersagen zu erhalten. In den folgenden Abschnitten finden Sie wichtige Überlegungen zu Vorhersagen.

Onlinevorhersage im Vergleich zur Batchvorhersage

Cloud ML Engine bietet zwei Möglichkeiten, um Vorhersagen von trainierten Modellen zu erhalten: Onlinevorhersagen, auch HTTP-Vorhersagen genannt, und Batchvorhersagen. In beiden Fällen übergeben Sie Eingabedaten an ein in der Cloud gehostetes Modell für maschinelles Lernen und erhalten Inferenzen für jede Dateninstanz. Die Unterschiede sind in der folgenden Tabelle aufgeführt:

Onlinevorhersage Batchvorhersage
Optimiert, um die Latenz bei der Vorhersageverarbeitung zu minimieren. Optimiert, um eine große Anzahl von Instanzen in einem Job zu bewältigen und komplexere Modelle auszuführen.
Kann eine oder mehrere Instanzen pro Anfrage verarbeiten. Kann eine oder mehrere Instanzen pro Anfrage verarbeiten.
Vorhersagen werden in der Antwortnachricht zurückgegeben. Vorhersagen werden in Ausgabedateien an einem Cloud Storage-Speicherort Ihrer Wahl geschrieben.
Eingabedaten werden direkt als JSON-String übergeben. Eingabedaten werden indirekt an einen oder mehrere URIs von Dateien in Cloud Storage-Speicherorten übergeben.
Rückgabe erfolgt so bald wie möglich. Asynchrone Anfrage.
Jeder Nutzer mit Lesezugriff auf das Projekt kann Anfragen stellen. Anfragen müssen durch einen Projektbearbeiter erfolgen.
Wird mit der Laufzeitversion und in der Region ausgeführt, die beim Bereitstellen des Modells ausgewählt wurde. Kann in jeder verfügbaren Region mit jeder verfügbaren Laufzeitversion ausgeführt werden. Die Ausführung sollte jedoch mit den Standardeinstellungen für die bereitgestellten Modellversionen erfolgen.
Führt Modelle aus, die in Cloud ML Engine bereitgestellt sind. Führt Modelle aus, die in Cloud ML Engine oder an zugänglichen Google Cloud Storage-Speicherorten bereitgestellt sind.

Welche Art der Vorhersage Sie verwenden sollten, hängt von den Anforderungen Ihrer Anwendung ab. In der Regel sollten Sie Onlinevorhersagen verwenden, wenn Sie Anfragen als Reaktion auf die Anwendungseingaben stellen oder in anderen Situationen, in denen eine zeitnahe Schlussfolgerung erforderlich ist. Eine Batchvorhersage eignet sich hingegen besser für die Verarbeitung von akkumulierten Daten, wenn Sie keine sofortigen Ergebnisse benötigen. Dies könnte beispielsweise ein regelmäßiger Job sein, der Vorhersagen für alle Daten anfordert, die seit dem letzten Job hinzugekommen sind. Sie sollten auch die möglichen Unterschiede bei den Kosten für Vorhersagen in Ihre Entscheidung einfließen lassen.

Latenz bei Batchvorhersagen

Wenn Sie ein einfaches Modell und einen kleinen Satz von Eingabeinstanzen verwenden, werden Sie feststellen, dass es bei der Ausführungsdauer identischer Vorhersageanfragen einen erheblichen Unterschied zwischen der Onlinevorhersage und der Batchvorhersage gibt. Ein Job für eine Batchvorhersage kann mehrere Minuten dauern, während eine Onlineanfrage die Vorhersage fast sofort zurückgibt. Dies ist ein Nebeneffekt der verschiedenen Infrastrukturen, die beide Vorhersagemethoden verwenden. Cloud ML Engine verteilt und initialisiert Ressourcen für den Job einer Batchvorhersage, wenn Sie die Anfrage senden. Eine Onlinevorhersage kann in der Regel sofort zum Zeitpunkt der Anfrage verarbeitet werden.

Vorhersageknoten und Ressourcenzuordnung

Cloud ML Engine misst die Verarbeitungsmenge, die Sie für die Vorhersage benötigen, in Knotenstunden. In diesem Abschnitt werden die Knoten und deren Zuordnung zu den verschiedenen Arten von Vorhersagen beschrieben.

Am einfachsten stellen Sie sich einen Knoten als eine virtuelle Maschine (VM) vor, auch wenn er mit einem anderen Mechanismus als eine herkömmliche VM implementiert wird. Jeder Knoten wird mit einer festgelegten Menge an Rechenleistung und Speicher bereitgestellt. Ein Knoten hat auch ein Betriebssystemimage und Konfigurationseinstellungen für die Software, die für die Ausführung des Modells und den Erhalt von Vorhersagen erforderlich ist.

Sowohl Online- als auch Batchvorhersagen führen die Knoten mit verteilter Verarbeitung aus, sodass eine bestimmte Anfrage oder ein Job mehrere Knoten gleichzeitig verwenden kann. Die für Sie entstehenden Kosten errechnen sich aus der gesamten Knotennutzung pro Minute, basierend auf einer Rate pro Stunde. Zum Beispiel entstehen für die Ausführung von zwei Knoten über zehn Minuten dieselben Kosten wie für die Ausführung eines Knotens über zwanzig Minuten. Da die Online- und Batchvorhersagen jedoch unterschiedliche Knotenzuordnungen vornehmen, kann dies erhebliche Auswirkungen auf Ihre Kosten haben.

Knotenzuordnung bei Batchvorhersagen

Der Batchvorhersagedienst skaliert die Anzahl der verwendeten Knoten, um die erforderliche Zeit für die Ausführung Ihres Jobs möglichst gering zu halten. Dazu geht der Dienst wie folgt vor:

  • Er ordnet einige Knoten zu, um den Job beim Start ausführen zu können.

  • Er skaliert die Anzahl der Knoten während des Jobs, um die Effizienz zu optimieren. Jeder Knoten braucht eine gewisse Startzeit, sodass der Dienst versucht, genügend Knoten zuzuordnen, ohne jedoch die gesamte Ausführungszeit durch eine zu hohe Startzeit der Knoten zu beeinträchtigen.

  • Er beendet die Knoten, sobald der Job abgeschlossen ist.

Sie können die Skalierung eines Batchvorhersagejobs beeinflussen, indem Sie eine maximale Anzahl der zu verwendenden Knoten angeben. Normalerweise möchten Sie so viele Knoten wie der Dienst letztendlich verwendet, allerdings unterliegt die Knotennutzung der Kontingentrichtlinie von Cloud ML Engine. Die Beschränkung der Anzahl von Knoten, die einem bestimmten Job zugeordnet werden, könnte besonders dann sinnvoll sein, wenn Sie Ihr Projekt mit anderen teilen und möglicherweise Jobs (sowohl Trainings- als auch Vorhersagejobs) gleichzeitig ausführen.

Knotenzuordnung bei Onlinevorhersagen

Der Onlinevorhersagedienst skaliert die Anzahl der verwendeten Knoten, um die Anzahl der Anfragen zu maximieren, die er ohne zu viel Latenz bewältigen kann. Dazu geht der Dienst wie folgt vor:

  • Er ordnet einige Knoten zu, wenn Sie Vorhersagen erstmalig nach einer langen Pause anfordern.

  • Er skaliert die Anzahl der Knoten als Antwort auf den Anfrage-Traffic und fügt Knoten hinzu, wenn der Traffic zunimmt bzw. entfernt Knoten bei nachlassenden Anfragen.

  • Er hält mindestens einen Knoten für Anfragen bereit, auch wenn gerade keine auszuführen ist. Er skaliert auf null herunter, wenn Ihre Modellversion einige Minuten ohne Vorhersageanfrage läuft.

Der Dienst hält Ihr Modell in einem Bereitschaftszustand, solange ein stetiger Strom von Anfragen erfolgt. Auf diese Weise kann jede Vorhersage sofort verarbeitet werden. Allerdings kann es eine lange Zeit – zehn Sekunden bis zu ein paar Minuten – dauern, um Knoten wieder zu initialisieren und eine Anfrage zu verarbeiten, wenn der Dienst auf null herunter skaliert worden ist.

Beschränkungen der automatischen Skalierung

Die automatische Skalierung von Cloud ML Engine für Onlinevorhersagen unterstützt Sie dabei, variierende Mengen von Vorhersageanfragen zu verarbeiten und gleichzeitig die Kosten zu minimieren. Sie ist jedoch nicht in allen Situationen ideal. Unter Umständen stellt der Dienst die Knoten nicht schnell genug online bereit, um extreme Spitzen von Anfrage-Traffic zu bewältigen. Wenn Ihr Traffic regelmäßig hohe Spitzen aufweist und eine zuverlässig niedrige Latenz für Ihre Anwendung wichtig ist, sollten Sie die manuelle Skalierung nutzen.

Manuelle Skalierung

Sie können die Skalierung der Onlinevorhersage für eine Modellversion beeinflussen, indem Sie eine Anzahl von Knoten angeben, die unabhängig vom Traffic ausgeführt werden soll. Wenn Sie die Anzahl der Knoten manuell festlegen, stoppt der Dienst die Skalierung. Dies bedeutet, dass die Anzahl der Knoten, die Sie angeben haben, immer bereit steht. Dadurch entstehen Ihnen aber auch laufende Kosten. Sie sollten diese Option nur dann wählen, wenn die Anzahl der Anfragen, die Ihr Modell erhält, regelmäßig und schneller schwankt, als es die automatische Skalierung ausgleichen kann. Sie legen die Anzahl der zu verwendenden Knoten in manualScaling des Objekts "Version" fest, das Sie an projects.models.versions.create übergeben.

Eingabedaten für Vorhersagen

Die Daten, die Sie für Vorhersagen verwenden, sind neue Daten, die in derselben Form wie die Daten vorliegen, die Sie für das Training verwendet haben. Online- und Batchvorhersagen verwenden die gleichen Daten (Merkmale Ihres Modells), jedoch unterschiedliche Formate, wobei diese von der Art der Vorhersage und der verwendeten Schnittstelle abhängen. Die möglichen Formate sind in der folgenden Tabelle zusammengefasst und in den nachfolgenden Abschnitten näher beschrieben:

Vorhersageart und Schnittstelle Unterstütztes Eingabeformat
Batch mit API-Aufruf Textdatei mit JSON-Instanzstrings oder TFRecords-Datei (kann komprimiert sein)
Batch mit gcloud-Tool Textdatei mit JSON-Instanzstrings oder TFRecords-Datei (kann komprimiert sein)
Online mit API-Aufruf JSON-Anfragenachricht
Online mit gcloud-Tool Textdatei mit JSON-Instanzstrings oder CSV-Datei

JSON-Instanzstrings

Das Grundformat für Online- und Batchvorhersagen ist eine Liste von Instanzdatentensoren. Es kann sich dabei um eine einfache Werteliste oder Member eines JSON-Objekts handeln, je nachdem, wie Sie die Eingaben in der Trainingsanwendung konfiguriert haben:

Dieses Beispiel zeigt einen Eingabetensor und einen Instanzschlüssel:

{"values": [1, 2, 3, 4], "key": 1}

Die Zusammensetzung des JSON-Strings kann komplex sein, solange diese Regeln eingehalten werden:

  • Die oberste Ebene der Instanzdaten muss ein JSON-Objekt sein – ein Wörterbuch aus Schlüssel/Wert-Paaren.

  • Einzelne Werte in einem Instanzobjekt können Strings, Zahlen oder Listen sein. JSON-Objekte können nicht eingebettet werden.

  • Listen dürfen nur Elemente des gleichen Typs (einschließlich anderer Listen) enthalten. Strings und numerische Werte dürfen nicht kombiniert werden.

Der folgende (zur Lesbarkeit formatierte) String zeigt ein Objekt, das ein Label und ein Bild enthält. Das Bild ist ein dreidimensionales Array aus 8-Bit-Ganzzahlen:

{
  "tag": "beach",
  "image": [
    [
      [138, 30, 66],
      [130, 20, 56],
      ...
    ],
    [
      [126, 38, 61],
      [122, 24, 57],
      ...
    ],
        ...
  ]
}

Wenn Ihr Modell nur eine einzige Eingabe annimmt, müssen Sie sie nicht in ein JSON-Objekt einschließen. Wenn Sie beispielsweise einen einzigen Tensor, in diesem Fall einen Vektor, mit vier Werten senden, müssen Sie dies nicht wie folgt formatieren:

{"values": [1, 2, 3, 4]}

Sie können die einzelnen Instanzen einfach in Form einer Liste angeben:

[1, 2, 3, 4]
Binärdaten in der Vorhersageeingabe

Binärdaten können nicht als UTF-8-codierte Strings formatiert werden, die von JSON unterstützt werden. Wenn Sie Binärdaten in Ihren Eingaben verwenden, müssen Sie für deren Darstellung die base64-Codierung verwenden. Folgende besondere Formatierungen sind erforderlich:

  • Der codierte String muss als JSON-Objekt mit einem einzelnen Schlüssel namens b64 formatiert werden. Das folgende Python-Beispiel codiert zwischengespeicherte JPEG-Rohdaten mit der base64-Bibliothek (Sie müssen base64 importieren). Mit folgendem Code wird eine Instanz Ihrer Werte in Python erstellt:

    {"image_bytes":{"b64": base64.b64encode(jpeg_data)}}
    
  • In Ihrem TensorFlow-Modellcode in der Trainingsanwendung müssen Sie die Eingabe-/Ausgabealiase für diesen Wert so benennen, dass sie auf "_bytes" enden.

Eingabedaten für Onlinevorhersagen

Sie übergeben Eingabeinstanzen für Onlinevorhersagen als Nachrichtentext für den Aufruf "projects.predict". Nehmen Sie jede Instanz als Element in eine Liste auf und nennen Sie den Listen-Member instances.

Das oben dargestellte JSON-Beispiel einer einfachen Dateninstanz wird auf diese Weise zu:

{"instances": [{"values": [1, 2, 3, 4], "key": 1}]}

Eingabedaten für Batchvorhersagen

Die Eingabedaten für eine Batchvorhersage übergeben Sie in einer oder mehreren Textdateien. Diese enthalten Zeilen mit den JSON-Instanzdaten, wie oben beschrieben. Eine Eingabedatei enthält keine Spaltenüberschriften oder andere Formatierungen, sondern nur die einfache JSON-Syntax.

{"image": [0.0, 0.0, ... ], "key": 0}
{"image": [0.0, 0.0, ... ], "key": 1}
{"image": [0.0, 0.0, ... ], "key": 2}

Instanzschlüssel

Cloud ML Engine führt die Jobs für Batchvorhersagen in Form einer verteilten Verarbeitung aus. Dies bedeutet, dass die Daten auf einen beliebigen Cluster von virtuellen Maschinen verteilt sind und die Verarbeitung in einer nicht absehbaren Reihenfolge stattfindet. Damit Sie die zurückgegebenen Vorhersagen den Eingabeinstanzen zuordnen können, müssen Sie Instanzschlüssel definieren. Ein Instanzschlüssel ist ein Wert, den jede Instanz aufweist und der unter den Instanzen in einem Satz von Daten nur einmal vergeben ist. Der einfachste Schlüssel ist eine Indexnummer.

Sie sollten die Schlüssel über Ihre Grafik unverändert in Ihrer Trainingsanwendung übergeben. Wenn Ihre Daten noch keine Instanzschlüssel besitzen, können Sie diese als Teil der Datenvorverarbeitung zuweisen.

Laufzeitversionen

Bei Veröffentlichung neuer Versionen von Cloud ML Engine kann es sein, dass Modelle, die für ältere Versionen entwickelt wurden, damit veraltet sind. Dies ist besonders relevant, wenn Sie eine effektive Modellversion verwenden, die bereits über einen längeren Zeitraum unverändert ist. Konsultieren Sie in diesem Fall die Cloud ML Engine-Versionsverwaltungsrichtlinie und bestätigen Sie, dass Sie die Cloud ML Engine-Laufzeitversion kennen, die Sie für das Training Ihrer Modellversionen verwenden.

Laufzeitversionen und Vorhersagen

Sie können eine unterstützte Cloud ML Engine-Laufzeitversion festlegen, wenn Sie eine Modellversion erstellen. Diese wird dann als Standardeinstellung für die Modellversion übernommen. Wenn Sie keine Laufzeitversion explizit angeben, erstellt Cloud ML Engine Ihre Version mit der aktuellen Standardlaufzeitversion. Dies ist in der Regel die neueste stabile Version.

Sie können eine Laufzeitversion festlegen, die beim Start eines Batchvorhersagejobs verwendet wird. Dadurch erhalten Sie Vorhersagen für ein Modell, das nicht in Cloud ML Engine bereitgestellt ist. Sie sollten nie eine andere Laufzeitversion als die Standardlaufzeitversion für ein bereitgestelltes Modell verwenden. Dies würde sonst mit großer Wahrscheinlichkeit zu unerwarteten Fehlern führen.

Sie können keine Onlinevorhersagen von Modellen abfragen, die sich außerhalb von Cloud ML Engine befinden. Es gibt also keine Möglichkeit, die Standardlaufzeitversion in Ihrer Anfrage zu überschreiben.

Die für eine Modellversion festgelegte Standardlaufzeitversion kann nicht geändert werden. Um eine andere Laufzeitversion für eine Modellversion anzugeben, stellen Sie eine neue Version mit denselben Trainingsartefakten bereit, die Sie ursprünglich verwendet haben.

Regionen und Vorhersagen

Auf der Google Cloud Platform werden Zonen und Regionen verwendet, um die geografischen Standorte von physischen Rechenressourcen zu bestimmen. Cloud ML Engine verwendet Regionen, um die eigene Verarbeitung festzulegen. Wenn Sie ein Modell für die Vorhersage bereitstellen, geben Sie die Standardregion an, in der die Vorhersage ausgeführt werden soll.

Wenn Sie einen Batchvorhersagejob starten, können Sie eine Region angeben, in welcher der Job ausgeführt werden soll, und damit die Standardregion überschreiben. Onlinevorhersagen werden immer in der Region verarbeitet, die bei der Erstellung des Modells festgelegt wurde.

Vorhersage-Logging

Batchvorhersagen generieren Joblogs, die sich in Stackdriver Logging einsehen lassen. Sie können auch Logs für Onlinevorhersagen anfordern, wenn Sie das Modell bei der Erstellung so konfigurieren, dass Logs generiert werden. Sie müssen diese Option festlegen, wenn Sie die Modellressource in Cloud ML Engine erstellen. Entweder generieren alle Versionen eines Modells Logs für Onlinevorhersagen oder keine.

Sie können Onlinevorhersage-Logs für ein Modell festlegen, indem Sie onlinePredictionLogging auf "true" setzen (in Python True). Dies geschieht in der Modellressource, die Sie zur Erstellung Ihres Modells mit project.models.create verwenden. Wenn Sie das Modell mit dem Befehlszeilentool gcloud erstellen, schließen Sie das Flag --enable-logging bei der Ausführung von gcloud ml-engine models create ein.

Vorhersagen von nicht bereitgestellten Modellen abrufen

Sie können Batchvorhersagen von einem Modell anfordern, das Sie nicht im Cloud ML Engine-Dienst bereitgestellt haben. Anstatt einen Modell- oder Versionsnamen anzugeben, können Sie den URI des Google Cloud Storage-Speicherorts angeben, an dem das auszuführende Modell gespeichert ist.

Da ein nicht bereitgestelltes Modell keine Standardlaufzeitversion hat, sollten Sie diese explizit in der Jobanfrage festlegen. Andernfalls verwendet Cloud ML Engine die neueste stabile Laufzeitversion.

In allen anderen Punkten verhält sich ein Batchvorhersagejob für ein nicht bereitgestelltes Modell genauso wie jeder andere Batchjob.

Modell testen

Sie können mit dem Vorhersagedienst von Cloud ML Engine nicht nur Modelle für die Produktion hosten, sondern auch testen. Das Testen des Modells ist normalerweise der Schritt vor der Bereitstellung einer Lösung für maschinelles Lernen. Der Zweck einer Testphase ist es, das Modell in einer Umgebung zu prüfen, die der realen Einsatzsituation so ähnlich wie möglich ist.

Es können mehrere Versionen eines Modells gleichzeitig für den Dienst bereitgestellt sein. Sie haben also die Möglichkeit, bei Bedarf mehrere Versionen eines Modells gleichzeitig zu testen. So lässt sich auch einfach eine Produktionsversion des Modells bereitstellen, während die nächste Version bereits getestet wird. Wie so oft bei der Entwicklung von Anwendungen für maschinelles Lernen ist die Verfügbarkeit neuer Daten häufig ein einschränkender Faktor. Sie sollten deshalb eine Strategie für die Aufteilung vorhandener Daten und die Erfassung neuer Testdaten entwickeln.

Weitere Informationen

Feedback geben zu...

Cloud Machine Learning Engine (Cloud ML Engine)