Schemas für Model Monitoring in der Gemini Enterprise Agent Platform bereitstellen

Um einen Monitoringjob zu starten, muss das Modellmonitoring das Schema Ihres tabellarischen Datasets kennen, damit es die Eingabenutzlast korrekt parsen kann.

Schemaparsen für Onlinevorhersage-Endpunkte

Bei Endpunkten für Onlinevorhersagen kann Model Monitoring das Schema automatisch parsen oder ein Schema hochladen, wenn Sie einen Monitoringjob erstellen.

Automatisches Schema-Parsing

Nachdem Sie die Abweichungen- oder Drifterkennung für einen Online-Endpunkt aktiviert haben, kann Model Monitoring das Eingabeschema normalerweise automatisch parsen. Zum automatischen Parsen des Schemas analysiert Model Monitoring die ersten 1.000 Eingabeanfragen, um das Schema zu bestimmen.

Das automatische Parsen des Schemas funktioniert am besten, wenn die Eingabeanfragen als Schlüssel/Wert-Paare formatiert sind, wobei "key" der Name des Features und "value" der Wert des Features ist. Beispiel:

"key":"value"

{"TenYearCHD":"0", "glucose":"5.4", "heartRate":"1", "age":"30",
"prevalentStroke":"0", "gender":"f", "ethnicity":"latin american"}

Wenn die Eingaben nicht das Format "key":"value" haben, versucht Model Monitoring, den Datentyp jedes Features zu ermitteln, und weist jeder Eingabe automatisch einen Standardnamen zu.

Benutzerdefinierte Instanzschemas

Sie können ein eigenes Eingabeschema angeben, wenn Sie einen Modell-Monitoring-Job erstellen, um sicherzustellen, dass das Modell-Monitoring die Eingaben Ihres Modells korrekt parst.

Dieses Schema wird als Analyseinstanzschema bezeichnet. Die Schemadatei gibt das Format der Eingabenutzlast, die Namen der einzelnen Funktionen und den Typ der einzelnen Merkmale an.

Das Schema muss als YAML-Datei im Open API-Format geschrieben werden. Das folgende Beispiel bezieht sich auf eine Vorhersageanfrage mit dem Format object:

type: object
properties:
  age:
    type: string
  BMI:
    type: number
  TenYearCHD:
    type: string
  cigsPerDay:
    type: array
    items:
      type: string
  BPMeds:
    type: string
required:
- age
- BMI
- TenYearCHD
- cigsPerDay
- BPMeds

  • type gibt an, ob Ihre Vorhersageanfrage in einem der folgenden Formate vorliegt:

    • object: Schlüssel/Wert-Paare
    • array: array-ähnlich
    • string: CSV-String

  • properties gibt den Typ der einzelnen Features an.

  • Wenn die Anfrage im Array- oder CSV-Stringformat vorliegt, geben Sie die Reihenfolge an, in der die Features in jeder Anfrage unter dem Feld required aufgeführt sind.

Wenn Ihre Vorhersageanfrage im Array- oder CSV-Stringformat vorliegt, stellen Sie alle fehlenden Features als Nullwerte dar. Betrachten Sie beispielsweise eine Vorhersageanfrage mit fünf Features:

[feature_a, feature_b, feature_c, feature_d, feature_e]

Wenn feature_c fehlende Werte zulässt, würde eine Beispielanfrage ohne feature_c so lauten: {[1, 2, , 4, 6]}. Die Listenlänge beträgt weiterhin 5, mit einem Nullwert in der Mitte.

Schemaparsen für Batchvorhersagen

Bei Batchvorhersagen können Sie bestimmen, dass Model Monitoring das Schema automatisch parst oder ein Schema hochlädt, wenn Sie einen Monitoringjob erstellen.

Automatisches Schema-Parsing

Wenn Sie beim Erstellen des Monitoringjobs kein Schema angeben, leitet Model Monitoring die Datentypen Ihrer Features ab und generiert das Schema anhand Ihrer Trainingsdaten.

Model Monitoring muss auch wissen, welches Feature die Zielspalte ist, also welches Feature vorhergesagt wird. Die Zielspalte wird aus dem Schema und dem Messwert für die Featureabweichung ausgeschlossen. Sie können die Zielspalte beim Erstellen eines Monitoringjobs angeben.

Spezifikation der Zielspalte

Wenn Sie die Zielspalte beim Erstellen eines Monitoringjobs nicht angeben, kennzeichnet Model Monitoring den letzten Featurenamen in Ihren Trainingsdaten als Zielspalte.

Beispiel: Das Modellmonitoring kennzeichnet column_c in diesen CSV-Trainingsdaten als Zielspalte, da sich column_c am Ende der ersten Zeile befindet:

column_a, column_b, column_d, column_c
1,"a", 2, "c"
2,"b", 342, "d"

Ebenso kennzeichnet das Modellmonitoring in dieser JSONL-Datei column_c als Zielspalte, da sich column_c am Ende der ersten Zeile befindet:

{"column_a": 1, "column_b": "a", "column_d": 2, "column_c": "c" }
{"column_a": 2, "column_b": "b", "column_c": "d",  "column_d": 342}

In beiden Beispielen enthält das endgültige Schema nur column_a, column_b und column_d.

Benutzerdefinierte Schemas

Ihr benutzerdefiniertes Schema gibt das Format der Eingabenutzlast, die Namen der einzelnen Funktionen und den Typ der einzelnen Merkmale an.

Das Schema muss als YAML-Datei mit Open API Syntax geschrieben werden. Das folgende Beispiel bezieht sich auf eine Vorhersageanfrage mit dem Format object:

type: object
properties:
  age:
    type: string
  BMI:
    type: number
  TenYearCHD:
    type: string
  cigsPerDay:
    type: array
    items:
      type: string
  BPMeds:
    type: string
required:
- age
- BMI
- TenYearCHD
- cigsPerDay
- BPMeds

Model Monitoring berechnet die Featureabweichung anhand der JSON Lines Ausgabe für Batchvorhersagen. Wenn Ihr Datentyp ein Array enthält, muss die Länge des Arrays in den Eingabedaten der Zahl der in der YAML-Datei angegebenen Features entsprechen. Andernfalls schließt Model Monitoring die Vorhersageinstanz mit der falschen Arraylänge aus der Berechnung der Featureabweichung aus.

Beispielsweise enthalten die Arrays in folgenden Datentypen zwei Funktionen:

  • Array: {[[1, 2]]}

  • "Schlüssel"/"Wert": {"key": 0, "values": [[1, 2]]}

Im entsprechenden Schema müssen auch zwei Features angegeben sein:

type: object
properties:
  name:
    type: string
  age:
    type: number
required:
- name
- age

Nächste Schritte