Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

TensorFlow Data Validation: Checking and analyzing your data

Sobald sich Ihre Daten in einer TFX-Pipeline befinden, können Sie sie mithilfe von TFX-Komponenten analysieren und transformieren. Sie können diese Tools bereits verwenden, bevor Sie ein Modell trainieren.

Es gibt viele Gründe, Ihre Daten zu analysieren und zu transformieren:

  • Probleme in Ihren Daten finden. Häufige Probleme sind:
    • Fehlende Daten, z. B. Features mit leeren Werten.
    • Beschriftungen, die als Features behandelt werden, damit Ihr Modell während des Trainings die richtige Antwort finden kann.
    • Funktionen mit Werten außerhalb des erwarteten Bereichs.
    • Datenanomalien.
  • Effektivere Funktionssätze entwickeln. Zum Beispiel können Sie identifizieren:
    • Besonders informative Funktionen.
    • Redundante Funktionen.
    • Funktionen, deren Größe so stark variiert, dass sie das Lernen verlangsamen können.
    • Funktionen mit wenigen oder keinen eindeutigen Vorhersageinformationen.

TFX-Tools können sowohl beim Auffinden von Datenfehlern als auch beim Feature-Engineering helfen.

TensorFlow-Datenvalidierung

Überblick

Die TensorFlow-Datenvalidierung identifiziert Anomalien beim Trainieren und Bereitstellen von Daten und kann durch Untersuchen der Daten automatisch ein Schema erstellen. Die Komponente kann so konfiguriert werden, dass verschiedene Klassen von Anomalien in den Daten erkannt werden. Es kann

  1. Führen Sie Gültigkeitsprüfungen durch, indem Sie Datenstatistiken mit einem Schema vergleichen, das die Erwartungen des Benutzers kodifiziert.
  2. Erkennen Sie einen Versatz zwischen Training und Serving, indem Sie Beispiele in Trainings- und Serving-Daten vergleichen.
  3. Erkennen Sie die Datendrift anhand einer Reihe von Daten.

Wir dokumentieren jede dieser Funktionen unabhängig:

Schemabasierte Beispielvalidierung

Die TensorFlow-Datenüberprüfung identifiziert alle Anomalien in den Eingabedaten, indem Datenstatistiken mit einem Schema verglichen werden. Das Schema kodiert Eigenschaften, die die Eingabedaten erfüllen sollen, z. B. Datentypen oder kategoriale Werte, und kann vom Benutzer geändert oder ersetzt werden.

Erweiterte Schemafunktionen

Dieser Abschnitt behandelt die erweiterte Schemakonfiguration, die bei speziellen Setups hilfreich sein kann.

Sparse Features

Durch das Codieren von Features mit geringer Dichte in Beispielen werden normalerweise mehrere Features eingeführt, von denen erwartet wird, dass sie für alle Beispiele dieselbe Wertigkeit haben. Zum Beispiel würde das Sparse-Feature:


WeightedCategories = [('CategoryA', 0.3), ('CategoryX', 0.7)]
mit separaten Features für Index und Wert:

WeightedCategoriesIndex = ['CategoryA', 'CategoryX']
WeightedCategoriesValue = [0.3, 0.7]
codiert, mit der Einschränkung, dass die Wertigkeit des Index- und Wert-Features für alle Beispiele übereinstimmen sollte. Diese Einschränkung kann im Schema durch Definieren einer sparse_feature explizit gemacht werden:

sparse_feature {
  name: 'WeightedCategories'
  index_feature { name: 'WeightedCategoriesIndex' }
  value_feature { name: 'WeightedCategoriesValue' }
}

Die Definition von Features mit geringer Dichte erfordert ein oder mehrere Index- und ein Wert-Feature, die sich auf Features beziehen, die im Schema vorhanden sind. Durch die explizite Definition von Features mit geringer Dichte kann TFDV überprüfen, ob die Valenzen aller referenzierten Features übereinstimmen.

Einige Anwendungsfälle führen ähnliche Valenzbeschränkungen zwischen Features ein, codieren jedoch nicht unbedingt ein Sparse-Feature. Die Verwendung der Sparse-Funktion sollte Sie entsperren, ist jedoch nicht ideal.

Schemaumgebungen

Standardmäßig wird bei Überprüfungen davon ausgegangen, dass alle Beispiele in einer Pipeline einem einzelnen Schema entsprechen. In einigen Fällen ist die Einführung geringfügiger Schemaabweichungen erforderlich. Beispielsweise sind Funktionen, die als Beschriftungen verwendet werden, während des Trainings erforderlich (und sollten validiert werden), fehlen jedoch während des Servierens. Umgebungen können verwendet werden, um solche Anforderungen auszudrücken, insbesondere default_environment() , in_environment() , not_in_environment() .

Angenommen, für das Training ist eine Funktion mit dem Namen "LABEL" erforderlich, die jedoch beim Servieren voraussichtlich fehlt. Dies kann ausgedrückt werden durch:

  • Definieren Sie zwei unterschiedliche Umgebungen im Schema: ["SERVING", "TRAINING"] und ordnen Sie 'LABEL' nur der Umgebung "TRAINING" zu.
  • Verknüpfen Sie die Trainingsdaten mit der Umgebung "TRAINING" und die Serving-Daten mit der Umgebung "SERVING".
Schemaerstellung

Das Eingangsdatenschema wird als eine Instanz des TensorFlow angegebenen Schema .

Anstatt ein Schema manuell von Grund auf neu zu erstellen, kann sich ein Entwickler auf die automatische Schemakonstruktion von TensorFlow Data Validation verlassen. Insbesondere erstellt TensorFlow Data Validation automatisch ein anfängliches Schema basierend auf Statistiken, die über die in der Pipeline verfügbaren Trainingsdaten berechnet werden. Benutzer können dieses automatisch generierte Schema einfach überprüfen, nach Bedarf ändern, in ein Versionskontrollsystem einchecken und es zur weiteren Validierung explizit in die Pipeline verschieben.

TFDV enthält infer_schema() , um automatisch ein Schema zu generieren. Beispielsweise:

schema = tfdv.infer_schema(statistics=train_stats)
tfdv.display_schema(schema=schema)

Dies löst eine automatische Schemagenerierung basierend auf den folgenden Regeln aus:

  • Wenn ein Schema bereits automatisch generiert wurde, wird es unverändert verwendet.

  • Andernfalls überprüft TensorFlow Data Validation die verfügbaren Datenstatistiken und berechnet ein geeignetes Schema für die Daten.

Hinweis: Das automatisch generierte Schema ist bestmöglich und versucht nur, grundlegende Eigenschaften der Daten abzuleiten. Es wird erwartet, dass Benutzer es nach Bedarf überprüfen und ändern.

Training-Serving-Skew-Erkennung

Überblick

Der Trainingsversorgungs-Skew-Detektor wird als Unterkomponente der TensorFlow-Datenvalidierung ausgeführt und erkennt den Versatz zwischen Trainings- und Serving-Daten.

Arten von Schrägstellung

Basierend auf verschiedenen Post-Portems für die Produktion haben wir die verschiedenen Arten von Versatz auf vier Schlüsselkategorien reduziert. Als nächstes diskutieren wir jede dieser Kategorien und stellen Beispielszenarien bereit, unter denen sie auftreten.

  1. Schema-Versatz tritt auf, wenn die Trainings- und Serving-Daten nicht mit demselben Schema übereinstimmen. Da das Schema die logischen Eigenschaften der Daten beschreibt, wird erwartet, dass die Trainings- und Serving-Daten demselben Schema entsprechen. Alle erwarteten Abweichungen zwischen den beiden (z. B. die Beschriftungsfunktion, die nur in den Trainingsdaten, aber nicht im Serving vorhanden ist) sollten über das Feld "Umgebungen" im Schema angegeben werden.

    Da die Generierung von Trainingsdaten ein Bulk-Datenverarbeitungsschritt ist, während die (Online-) Serving-Datengenerierung normalerweise ein latenzempfindlicher Schritt ist, ist es üblich, unterschiedliche Codepfade zu haben, die Trainings- und Serving-Daten generieren. Das ist ein Fehler. Jede Diskrepanz zwischen diesen beiden Codepfaden (entweder aufgrund eines Entwicklerfehlers oder inkonsistenter Binärversionen) kann zu einem Schema-Versatz führen.

    Beispielszenario

    Bob möchte dem Modell eine neue Funktion hinzufügen und diese zu den Trainingsdaten hinzufügen. Die Offline-Trainingsmetriken sehen gut aus, aber die Online-Metriken sind viel schlechter. Nach stundenlangem Debuggen stellt Bob fest, dass er vergessen hat, dieselbe Funktion in den Serving-Code-Pfad aufzunehmen. Das Modell hat dieser neuen Funktion eine hohe Bedeutung beigemessen. Da sie zum Zeitpunkt der Bereitstellung nicht verfügbar war, wurden schlechte Vorhersagen generiert, die zu schlechteren Online-Metriken führten.

  2. Feature-Skew tritt auf, wenn sich die Feature-Werte, auf denen ein Modell trainiert, von den Feature-Werten unterscheiden, die es zur Bereitstellungszeit sieht. Dies kann mehrere Gründe haben, darunter:

    • Wenn eine externe Datenquelle, die einige Funktionswerte bereitstellt, zwischen Training und Bereitstellungszeit geändert wird.

    • Inkonsistente Logik zum Generieren von Features zwischen Training und Serving. Wenn Sie beispielsweise eine Transformation nur in einem der beiden Codepfade anwenden.

    Beispielszenario

    Alice verfügt über eine kontinuierliche Pipeline für maschinelles Lernen, in der die Serving-Daten für heute protokolliert und zur Generierung der Trainingsdaten für den nächsten Tag verwendet werden. Um Platz zu sparen, beschließt sie, die Video-ID nur zur Bereitstellungszeit zu protokollieren und die Videoeigenschaften während der Generierung der Trainingsdaten aus einem Datenspeicher abzurufen.

    Dabei führt sie versehentlich einen Versatz ein, der speziell für neu hochgeladene und virale Videos gefährlich ist, deren Anzeigezeit sich zwischen Serving- und Trainingszeit erheblich ändern kann (siehe unten).

    
     Serving Example           Training Example
     -------------------------  -------------------------
     features {                 features {
       feature {                  feature {
         key "vid"                  key "vid"
         value { int64_list {       value { int64_list {
           value 92392               value 92392
         } }                         } }
       }                          }
       feature {                  feature {
         key "views"               key "views"
         value { int_list {       value { bytes_list {
           value "10"                value "10000"  # skew
         } }                         } }
       }                          }
     }                          }
    

    Dies ist ein Beispiel für einen Merkmalsversatz, da die Trainingsdaten eine überhöhte Anzahl von Ansichten sehen.

  3. Verteilungsversatz tritt auf, wenn sich die Verteilung der Merkmalswerte für Trainingsdaten erheblich von der Verteilung der Daten unterscheidet. Eine der Hauptursachen für den Verteilungsversatz ist die Verwendung eines völlig anderen Korpus zum Trainieren der Datengenerierung, um den Mangel an Anfangsdaten im gewünschten Korpus zu überwinden. Ein weiterer Grund ist ein fehlerhafter Stichprobenmechanismus, bei dem nur eine Teilstichprobe der zu trainierenden Serving-Daten ausgewählt wird.

    Beispielszenario

    Um beispielsweise einen unterrepräsentierten Datenabschnitt zu kompensieren, wird die Verteilung der Merkmalswerte zwischen Trainings- und Serving-Daten aritisch verzerrt, wenn eine voreingenommene Stichprobe verwendet wird, ohne die heruntergetasteten Beispiele angemessen zu gewichten.

  4. Scoring / Serving Skew ist schwerer zu erkennen und tritt auf, wenn nur eine Teilmenge der bewerteten Beispiele tatsächlich bedient wird. Da Etiketten nur für die bereitgestellten Beispiele und nicht für die bewerteten Beispiele verfügbar sind, werden nur diese Beispiele für das Training verwendet. Dies führt implizit dazu, dass das Modell die bewerteten Beispiele falsch vorhersagt, da sie in den Trainingsdaten allmählich unterrepräsentiert sind.

    Beispielszenario

    Stellen Sie sich ein Anzeigensystem vor, das die Top-10-Anzeigen liefert. Von diesen 10 Anzeigen darf nur eine vom Nutzer angeklickt werden. Alle 10 dieser diente Beispiele werden für die nächsten Tage Training verwendet - 1 positive und 9 negativ. Zum Zeitpunkt der Zustellung wurde das trainierte Modell jedoch verwendet, um Hunderte von Anzeigen zu bewerten. Die anderen 90 Anzeigen, die nie geliefert wurden, werden implizit aus den Trainingsdaten entfernt. Dies führt zu einer impliziten Rückkopplungsschleife, die die Dinge mit niedrigerem Rang weiter falsch vorhersagt, da sie nicht in den Trainingsdaten enthalten sind.

Warum sollte es dich interessieren?

Skew ist schwer zu erkennen und in vielen ML-Pipelines weit verbreitet. Es gab mehrere Vorfälle, bei denen dies zu Leistungseinbußen und Umsatzverlusten führte.

Was wird aktuell unterstützt?

Derzeit unterstützt TensorFlow Data Validation die Erkennung von Schema-Versatz, Feature-Versatz und Verteilungsversatz.

Drifterkennung

Die Drifterkennung wird für kategoriale Merkmale und zwischen aufeinanderfolgenden Datenbereichen (dh zwischen Bereich N und Bereich N + 1) unterstützt, z. B. zwischen verschiedenen Tagen mit Trainingsdaten. Wir drücken die Drift als L-Unendlichkeitsabstand aus , und Sie können den Schwellenabstand so einstellen, dass Sie Warnungen erhalten, wenn die Drift höher als akzeptabel ist. Das Einstellen der richtigen Entfernung ist normalerweise ein iterativer Prozess, der Domänenwissen und Experimente erfordert.

Verwenden von Visualisierungen zum Überprüfen Ihrer Daten

TensorFlow Data Validation bietet Tools zur Visualisierung der Verteilung von Feature-Werten. Wenn Sie diese Verteilungen in einem Jupyter-Notizbuch mithilfe von Facetten untersuchen , können Sie häufig auftretende Probleme mit Daten erkennen.

Funktionsstatistiken

Verdächtige Verteilungen identifizieren

Sie können häufige Fehler in Ihren Daten identifizieren, indem Sie eine Facettenübersicht verwenden, um nach verdächtigen Verteilungen von Feature-Werten zu suchen.

Unausgeglichene Daten

Ein unausgeglichenes Merkmal ist ein Merkmal, für das ein Wert vorherrscht. Unausgeglichene Features können natürlich auftreten. Wenn ein Feature jedoch immer den gleichen Wert hat, liegt möglicherweise ein Datenfehler vor. Um unausgeglichene Merkmale in einer Facettenübersicht zu erkennen, wählen Sie "Ungleichmäßigkeit" aus der Dropdown-Liste "Sortieren nach".

Die unausgeglichensten Features werden oben in jeder Feature-Typ-Liste aufgelistet. Der folgende Screenshot zeigt beispielsweise eine Funktion, bei der es sich ausschließlich um Nullen handelt, und eine zweite Funktion, die stark unausgeglichen ist, oben in der Liste "Numerische Funktionen":

Visualisierung unausgeglichener Daten

Gleichmäßig verteilte Daten

Ein gleichmäßig verteiltes Merkmal ist eines, bei dem alle möglichen Werte mit nahezu derselben Frequenz erscheinen. Wie bei unausgeglichenen Daten kann diese Verteilung natürlich auftreten, aber auch durch Datenfehler verursacht werden.

Um gleichmäßig verteilte Features in einer Facettenübersicht zu erkennen, wählen Sie "Ungleichmäßigkeit" aus der Dropdown-Liste "Sortieren nach" und aktivieren Sie das Kontrollkästchen "Reihenfolge umkehren":

Histogramm einheitlicher Daten

Zeichenfolgendaten werden mithilfe von Balkendiagrammen dargestellt, wenn 20 oder weniger eindeutige Werte vorhanden sind, und als kumulatives Verteilungsdiagramm, wenn mehr als 20 eindeutige Werte vorhanden sind. Für Zeichenfolgendaten können gleichmäßige Verteilungen entweder als flache Balkendiagramme wie oben oder als gerade Linien wie unten angezeigt werden:

Liniendiagramm: kumulative Verteilung einheitlicher Daten

Fehler, die gleichmäßig verteilte Daten erzeugen können

Hier sind einige häufige Fehler, die gleichmäßig verteilte Daten erzeugen können:

  • Verwenden von Zeichenfolgen zur Darstellung von Nicht-Zeichenfolgen-Datentypen wie Datumsangaben. Beispielsweise haben Sie viele eindeutige Werte für ein Datum / Uhrzeit-Feature mit Darstellungen wie "2017-03-01-11-45-03". Eindeutige Werte werden gleichmäßig verteilt.

  • Einschließlich Indizes wie "Zeilennummer" als Features. Auch hier haben Sie viele einzigartige Werte.

Fehlende Daten

So überprüfen Sie, ob einem Feature Werte vollständig fehlen:

  1. Wählen Sie "Fehlender Betrag / Null" aus der Dropdown-Liste "Sortieren nach".
  2. Aktivieren Sie das Kontrollkästchen "Reihenfolge umkehren".
  3. Sehen Sie sich die Spalte "fehlend" an, um den Prozentsatz der Instanzen mit fehlenden Werten für ein Feature anzuzeigen.

Ein Datenfehler kann auch zu unvollständigen Feature-Werten führen. Beispielsweise können Sie erwarten, dass die Werteliste eines Features immer drei Elemente enthält, und feststellen, dass sie manchmal nur eines enthält. So suchen Sie nach unvollständigen Werten oder anderen Fällen, in denen Feature-Wertelisten nicht die erwartete Anzahl von Elementen aufweisen:

  1. Wählen Sie rechts im Dropdown-Menü "Zu zeigende Tabelle" die Option "Wertelistenlänge".

  2. Sehen Sie sich das Diagramm rechts neben jeder Feature-Zeile an. Das Diagramm zeigt den Bereich der Wertelistenlängen für das Feature. Die hervorgehobene Zeile im folgenden Screenshot zeigt beispielsweise eine Funktion mit einigen Wertelisten mit der Länge Null:

Facettenübersicht mit Feature mit Feature-Wertelisten mit der Länge Null

Große Unterschiede in der Skalierung zwischen Features

Wenn sich Ihre Funktionen stark unterscheiden, kann das Modell Schwierigkeiten beim Lernen haben. Wenn beispielsweise einige Funktionen von 0 bis 1 und andere von 0 bis 1.000.000.000 variieren, besteht ein großer Skalierungsunterschied. Vergleichen Sie die Spalten "max" und "min" über Features hinweg, um sehr unterschiedliche Maßstäbe zu finden.

Erwägen Sie, die Merkmalswerte zu normalisieren, um diese großen Abweichungen zu verringern.

Etiketten mit ungültigen Etiketten

Die Schätzer von TensorFlow haben Einschränkungen hinsichtlich der Art der Daten, die sie als Beschriftungen akzeptieren. Beispielsweise funktionieren binäre Klassifizierer normalerweise nur mit {0, 1} -Labels.

Überprüfen Sie die Beschriftungswerte in der Facettenübersicht und stellen Sie sicher, dass sie den Anforderungen der Schätzer entsprechen .