Kapitel 4. Merkmale und Trainingsdaten

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Von Robbie Sedgewick und Todd Underwood

An dieser Stelle sollte klar sein, dass Modelle aus Daten entstehen. In diesem Kapitel geht es um die Daten: wie sie erstellt, verarbeitet, mit Anmerkungen versehen, gespeichert und schließlich zur Erstellung des Modells verwendet werden. Du wirst sehen, dass die Verwaltung und der Umgang mit den Daten besondere Herausforderungen in Bezug auf Wiederholbarkeit, Handhabbarkeit und Zuverlässigkeit mit sich bringen, und wir werden einige konkrete Empfehlungen geben, wie du diese Herausforderungen angehen kannst. Als Hintergrundinformation solltest du dir (falls noch nicht geschehen) die Kapitel 2 und 3 ansehen.

In diesem Kapitel geht es um die Infrastruktur, die Daten aus einer Quelle entgegennimmt und sie für die Nutzung durch das Trainingssystem vorbereitet. Wir werden drei grundlegende funktionale Subsysteme besprechen, die an dieser Aufgabe beteiligt sind: ein Merkmalssystem, ein System für menschliche Anmerkungen und ein Metadatensystem. Im vorigen Kapitel haben wir bereits ein wenig über Merkmale gesprochen. Man kann sie auch so verstehen, dass es sich um Eigenschaften der Eingabedaten handelt, insbesondere um Eigenschaften, die wir als vorhersagend für etwas bestimmt haben, das uns interessiert. Labels sind spezifische Fälle der Ausgabe, die wir von dem Modell, das wir letztendlich trainieren, erwarten. Sie werden als Beispiele verwendet, um das Modell zu trainieren. Eine andere Art, über Labels nachzudenken, ist, dass sie die Ziel- oder "richtigen" Werte für eine bestimmte Dateninstanz sind, die das Modell lernen wird. Labels können aus Protokollen extrahiert werden, indem die Daten mit einem anderen unabhängigen Ereignis korreliert werden, oder sie können von Menschen erstellt werden. Wir werden die Systeme besprechen, die für die Erstellung von menschlichen Kennzeichnungen in großem Umfang benötigt werden, die oft als Annotationen bezeichnet werden. Zum Schluss gehen wir kurz auf Metadatensysteme ein, die die Details über die Funktionsweise der anderen Systeme aufzeichnen und entscheidend dafür sind, dass sie wiederholbar und zuverlässig sind.

Mehrere Aspekte dieser Systeme werden in der Regel vom Merkmalssystem und vom Datensystem gemeinsam genutzt - vor allem das Metadatensystem. Da wir Metadaten (Daten über die Daten, die wir sammeln und annotieren) am besten verstehen, wenn wir wissen, was wir mit den Daten machen, werden wir diese Systeme besprechen, nachdem wir die Anforderungen und Merkmale der Feature- und Labeling-Systeme untersucht haben.

Eigenschaften

Die Daten sind nur die Daten. Merkmale sind das, was sie für ML nützlich macht.1 Ein Merkmal ist jeder Aspekt der Daten, den wir als nützlich erachten, um die Ziele des Modells zu erreichen. Mit "wir" sind hier die Menschen gemeint, die das Modell erstellen, oder in vielen Fällen auch automatische Feature-Engineering-Systeme. Mit anderen Worten: Ein Merkmal ist ein bestimmter, messbarer Aspekt der Daten oder eine Funktion davon.

Merkmale werden verwendet, um Modelle zu erstellen. Sie sind die Struktur, die das Modell mit den Daten verbindet, die zum Aufbau des Modells verwendet. Wir haben bereits gesagt, dass ein Modell eine Reihe von Regeln ist, die aus den Daten Vorhersagen über die Welt machen. Das gilt für eine Modellarchitektur und ein konfiguriertes Modell. Ein trainiertes Modell ist jedoch vielmehr eine Formel zur Kombination einer Sammlung von Merkmalen (im Wesentlichen Merkmalsdefinitionen, die dazu dienen, Merkmalswerte aus realen Daten zu extrahieren - auf diese Definition gehen wir später in diesem Kapitel genauer ein). Merkmale sind häufig mehr als nur Teile der Rohdaten, sondern müssen in irgendeiner Form vorverarbeitet werden.

Diese konkreten Beispiele von Merkmalen sollten ein Gefühl dafür vermitteln, was sie sind:

  • Aus einem Web-Log, Informationen über den Kunden (z.B. den Browsertyp).

  • Einzelne Wörter oder Kombinationen von Wörtern aus einem Text, den ein Mensch in eine Anwendung eingibt.

  • Die Menge aller Pixel in einem Bild oder eine strukturierte Teilmenge davon.

  • Aktuelles Wetter am Standort des Kunden, als er die Seite geladen hat.

  • Jede Kombination oder Umwandlung von Merkmalen kann selbst ein Merkmal sein.

Normalerweise enthalten Features kleinere Teile von strukturierten Daten, die aus den zugrunde liegenden Trainingsdaten extrahiert wurden. Da sich die Modellierungstechniken weiterentwickeln, ist es wahrscheinlich, dass immer mehr Merkmale den Rohdaten ähneln werden und nicht mehr diesen extrahierten Elementen. Ein Modell, das auf Text trainiert wird, könnte zum Beispiel auf Wörter oder Wortkombinationen trainieren, aber wir erwarten, dass in Zukunft mehr auf Absätze oder sogar ganze Dokumente trainiert wird. Das hat natürlich erhebliche Auswirkungen auf die Modellierung, aber wer ML-Systeme für die Produktion entwickelt, sollte sich auch darüber im Klaren sein, welche Auswirkungen es auf die Systeme hat, wenn die Trainingsdaten größer und weniger strukturiert werden.

Bei YarnIt haben wir mehrere Modelle, und eines davon ist es, Empfehlungen für andere oder zusätzliche Produkte zu geben, während ein Kunde auf der Website einkauft. Dieses Empfehlungsmodell wird von der Webanwendung während einer Einkaufssitzung aufgerufen, und zwar sowohl von der Hauptproduktseite, auf der ein Kunde ein einzelnes Produkt ansieht, als auch von der Bestätigungsseite des Warenkorbs, wenn ein Kunde gerade ein Produkt in seinen Warenkorb gelegt hat. Der Webserver ruft das Modell auf, um zu fragen, welche zusätzlichen Produkte er dem Kunden unter diesen Umständen zeigen soll, in der Hoffnung, dem Kunden etwas anderes zu zeigen, das er vielleicht braucht oder möchte, und so unsere Verkäufe an diesen Kunden zu steigern.

In diesem Zusammenhang könnten wir einige der folgenden nützlichen Funktionen in Betracht ziehen, die wir dem Modell zur Verfügung stellen möchten, wenn es nach zusätzlichen Produkten abgefragt wird:

  • Produktseite oder Seite zur Bestätigung des Warenkorbs. Stöbert der Nutzer oder kauft er?

  • Das aktuelle Produkt, das sich der/die Nutzer/in ansieht, einschließlich Informationen aus dem Namen des aktuellen Produkts, möglicherweise Informationen aus dem Bild des aktuellen Produkts, der Produktkategorie, dem Hersteller und dem Preis.

  • Die durchschnittliche Kaufsumme des Kunden oder die Gesamteinkäufe pro Jahr, wenn wir sie kennen. Das kann ein Hinweis darauf sein, wie ausgabefreudig ein Kunde ist.

  • Stricker oder Häkler? Es gibt Kunden, die nie häkeln, und andere, die nur häkeln. Dies zu wissen, könnte uns helfen, die richtigen Garne, Nadeln und Muster zu empfehlen. Wir könnten diese Eigenschaft von den Kunden selbst angeben lassen oder sie aus früheren Einkäufen oder dem Surfverhalten ableiten.

  • Kundenland. Manche Produkte sind vielleicht nur an bestimmten Orten beliebt. Außerdem sind manche Länder kälter als andere, und das könnte ein Signal sein.

Dies sind nur ein paar Ideen, um einen Eindruck davon zu vermitteln, was ein Merkmal sein könnte. Es ist wichtig anzumerken, dass wir ohne konkrete Daten keine Ahnung haben, ob eine dieser Funktionen nützlich ist. Sie sehen zwar so aus, als könnten sie hilfreich sein, aber viele Merkmale, die so aussehen, als könnten sie funktionieren, sind es einfach nicht. Meistens haben solche Merkmale nur eine geringe Vorhersagekraft und die Dinge, die sie vorhersagen, werden vielleicht von einem anderen Merkmal, das wir bereits haben, besser vorhergesagt. In diesen Fällen bringt die neue Funktion zwar zusätzliche Kosten und Komplexität, aber überhaupt keinen Nutzen. Erinnere dich daran, dass Funktionen in vielen Bereichen des Systems zusätzliche Wartungskosten verursachen, die so lange anfallen, bis die Funktion entfernt wird. Wir sollten vorsichtig sein, wenn wir neue Funktionen hinzufügen, vor allem wenn sie von neuen Datenquellen oder Feeds abhängen, die nun selbst überwacht und gewartet werden müssen.

Bevor wir zu weit gehen, müssen wir zwei völlig unterschiedliche Verwendungen des Begriffs " Merkmal" klären und wie wir sie voneinander unterscheiden:

Feature Definition

Dies ist ein Code (oder ein Algorithmus oder eine andere schriftliche Beschreibung) , der die Informationen beschreibt, die wir aus den zugrunde liegenden Daten extrahieren. Es handelt sich jedoch nicht um eine bestimmte Instanz der extrahierten Daten. So ist z. B. das "Herkunftsland des aktuellen Kunden, das durch die IP-Adresse des Kunden und die Suche im Geolokalisierungsdienst ermittelt wird" eine Feature-Definition. Ein bestimmtes Land - zum Beispiel die "Dominikanische Republik" oder "Russland" - ist keine Merkmalsdefinition.

Merkmal Wert

Dies ist eine spezifische Ausgabe einer Merkmalsdefinition , die auf eingehende Daten angewendet wird. Im vorangegangenen Beispiel ist die "Dominikanische Republik" ein Merkmalswert, den man erhalten kann, wenn man feststellt, dass die IP-Adresse des aktuellen Kunden vermutlich am häufigsten in diesem Land verwendet wird.

Das ist (noch) keine Standardterminologie, aber wir verwenden sie in diesem Abschnitt, um zu unterscheiden, wie wir versuchen, Informationen aus den Daten zu extrahieren, und was wir bisher extrahiert haben.

Auswahl und Entwicklung von Merkmalen

Die Merkmalsauswahl ist der Prozess, mit dem wir die Merkmale in den Daten identifizieren, die wir in unserem Modell verwenden wollen. Feature-Engineering ist der Prozess, bei dem wir diese Merkmale extrahieren und sie in einen brauchbaren Zustand überführen. Mit anderen Worten: Durch diese Aktivitäten finden wir heraus, was wichtig ist (für die ML-Aufgabe, die wir zu erfüllen versuchen) und was nicht. Das Erstellen und Verwalten von Merkmalen hat sich im Laufe der Jahre verändert und wird sich auch weiterhin weiterentwickeln, da es sich von einem rein manuellen Prozess zu einem weitgehend automatisierten und in einigen Fällen sogar zu einem vollständig automatisierten Prozess entwickelt. In diesem Kapitel bezeichnen wir die Prozesse der Auswahl und Umwandlung von Features gemeinsam als Feature Engineering.

Beim Human-Driven Feature Engineering beginnt der Prozess in der Regel mit menschlicher Intuition, die auf einem Verständnis der Problemstellung oder zumindest auf einer ausführlichen Beratung mit Experten beruht. Stell dir vor, du versuchst, ein Vorhersagemodell dafür zu erstellen, was Kunden bei yarnit.ai kaufen würden, ohne zu wissen, was Garn, Nadeln oder Strickwaren sind, oder noch schlimmer, ohne zu wissen, wie der Online-Handel überhaupt funktioniert. Es ist wichtig, den zugrunde liegenden Problembereich zu verstehen, und je spezifischer, desto besser. Danach beschäftigt sich ein ML-Ingenieur mit einem Datensatz und einem Problem und verwendet eine Reihe von statistischen Werkzeugen, um die Wahrscheinlichkeit zu bewerten, dass ein bestimmtes Merkmal oder mehrere Merkmale in Kombination miteinander für die Aufgabe nützlich sein werden. Als Nächstes machen ML-Ingenieure in der Regel ein Brainstorming, um eine Liste mit möglichen Merkmalen zu erstellen. Die Auswahl ist ziemlich groß. Die Tageszeit könnte ein Merkmal sein, das vorhersagt, welche Garne die Kunden kaufen werden. Die lokale Luftfeuchtigkeit könnte ein Merkmal sein. Der Preis könnte ein Merkmal sein. Von diesen drei Merkmalen ist eines viel wahrscheinlicher nützlich als die anderen. Es liegt an den Menschen, diese Ideen mit Hilfe der ML-Plattform und der Modellmetriken zu entwickeln und zu bewerten.

Beim algorithmischen Feature-Engineering, das manchmal Teil von AutoML ist, ist der Prozess wesentlich automatischer und datengebundener. AutoML, das in Kapitel 3 beschrieben wird, kann nicht nur aus identifizierten Merkmalen auswählen, sondern auch gängige Transformationen (z. B. logarithmische Skalierung oder Schwellenwerte) programmgesteuert auf vorhandene Merkmale anwenden. Es gibt noch andere Möglichkeiten, wie wir algorithmisch etwas (eine Einbettung) über die Daten lernen können, ohne sie explizit zu spezifizieren. Algorithmen sind jedoch in der Regel nur in der Lage, Merkmale zu erkennen, die in den Daten vorhanden sind, während Menschen sich vorstellen können, dass neue Daten gesammelt werden könnten, die relevant sein könnten. Unterschwellig, aber vielleicht noch wichtiger ist, dass Menschen den Prozess der Datenerhebung verstehen, einschließlich möglicher systematischer Verzerrungen. Das kann sich erheblich auf den Wert der Daten auswirken. Dennoch kann die algorithmische Merkmalserfassung und -auswertung, vor allem wenn sie auf bestimmte Problemtypen beschränkt ist, genauso effektiv oder effektiver sein als die menschliche Merkmalserfassung. Diese Technologien befinden sich in der Entwicklung und wir sollten davon ausgehen, dass sich das Gleichgewicht zwischen Menschen und Computern weiterentwickeln wird.

Lebenszyklus eines Features

Die Unterscheidung zwischen Merkmalsdefinitionen und Merkmalswerten wird besonders wichtig, wenn man den Lebenszyklus eines Merkmals betrachtet. Merkmalsdefinitionen werden erstellt, um ein Bedürfnis zu befriedigen, anhand dieses Bedürfnisses bewertet und schließlich verworfen, wenn entweder das Modell verworfen wird oder bessere Merkmale gefunden werden, die dasselbe Ziel erreichen. Hier ist eine vereinfachte Version des Lebenszyklus eines Merkmals (sowohl die Definition als auch die repräsentativen Werte):

1. Daten sammeln/erstellen

Ohne Daten haben wir keine Funktionen. Wir müssen Daten sammeln oder erstellen, um Merkmale zu schaffen.

2. Datenbereinigung/Normalisierung/Vorverarbeitung

Obwohl selbst der Prozess der Feature-Erstellung als eine Art Datennormalisierung angesehen werden könnte, beziehen wir uns hier auf eine gröbere Vorverarbeitung: das Entfernen von offensichtlich fehlerhaften Beispielen, das Skalieren von Eingabeproben auf einen gemeinsamen Wertesatz und möglicherweise sogar das Löschen bestimmter Daten, die wir aus politischen Gründen nicht trainieren sollten. Dies mag vielleicht nicht zum Prozess der Merkmalstechnik gehören, aber Merkmale können erst dann entstehen, wenn die Daten vorhanden und in einer brauchbaren Form sind. Das Thema Datennormalisierung und -vorverarbeitung ist sehr umfangreich und würde den Rahmen dieses Buches sprengen, aber der Aufbau der Infrastruktur, um diese Vorverarbeitung konsequent durchzuführen und zu überwachen, ist ein wichtiger Aufgabenbereich.

3. Erstellung von Kandidaten-Features Definition

Entwickle mit Hilfe von Fachwissen und menschlicher Vorstellungskraft oder automatisierten Werkzeugen eine Hypothese darüber, welche Elemente oder Kombinationen von Daten die Ziele unseres Modells wahrscheinlich erreichen werden.

4. Merkmalswert Extraktion

Wir müssen einen Code schreiben, der die Eingabedaten liest und die benötigten Merkmale aus den Daten extrahiert. In einigen einfachen Situationen können wir dies inline als Teil des Trainingsprozesses tun. Wenn wir jedoch davon ausgehen, dass wir mehr als nur ein paar Mal mit denselben Daten trainieren werden, ist es wahrscheinlich sinnvoll, die Merkmale aus den Rohdaten zu extrahieren und sie zu speichern, um sie später effizient und konsistent lesen zu können. Es ist wichtig, sich daran zu erinnern, dass wir eine Version dieses Codes brauchen, um die gleichen Merkmale aus den Werten zu extrahieren, die uns beim Serving zur Verfügung stehen, um sie für die Inferenz in unserem Modell zu verwenden, wenn unsere Anwendung Online-Serving beinhaltet. Im Idealfall kann derselbe Code Merkmale für das Training und für das Serving extrahieren, aber es kann sein, dass wir beim Serving zusätzliche Einschränkungen haben, die beim Training nicht vorhanden sind.

5. Speicherung der Merkmalswerte in einem Merkmalspeicher

Und genau hier speichern wir die Merkmale. Ein Merkmalsspeicher ist nur ein Ort, an dem die extrahierten Merkmalswerte gespeichert werden, damit sie beim Training eines Modells schnell und konsistent gelesen werden können. Das wird im Detail unter "Feature Store" behandelt .

6. Definition der Merkmale Bewertung

Sobald wir einige Merkmale extrahiert haben, werden wir höchstwahrscheinlich ein Modell mit diesen Merkmalen erstellen oder neue Merkmale zu einem bestehenden Modell hinzufügen, um zu prüfen, wie gut sie funktionieren. Insbesondere werden wir nach Beweisen dafür suchen, dass die Merkmale den erhofften Nutzen bringen. Die Bewertung von Merkmalsdefinitionen erfolgt in zwei verschiedenen Phasen, die miteinander verbunden sind. Zunächst müssen wir feststellen, ob das Merkmal überhaupt nützlich ist. Dabei handelt es sich um eine grobkörnige Bewertung; wir versuchen einfach zu entscheiden, ob wir weiter daran arbeiten sollen, das Merkmal in unser Modell zu integrieren. Die nächste Phase tritt ein, wenn wir uns entscheiden, das Merkmal zu behalten. Dann brauchen wir ein Verfahren, um die Qualität und den Wert (im Vergleich zu den Kosten) des Merkmals kontinuierlich zu bewerten. Das ist notwendig, damit wir feststellen können, ob die Funktion noch so funktioniert, wie wir es erwarten, und ob sie auch in einigen Jahren noch den erwarteten Nutzen bringt.

7. Modelltraining und Bedienung anhand von Merkmalswerten

Vielleicht ist das offensichtlich, aber der Sinn von Merkmalen ist es, mit ihnen Modelle zu trainieren und die daraus resultierenden Modelle für einen bestimmten Zweck zu nutzen.

8. (Normalerweise) Aktualisierung der Definitionen des Merkmals

Häufig müssen wir die Definition eines Features aktualisieren, entweder um einen Fehler zu beheben oder um es auf irgendeine Weise zu verbessern. Wenn wir Versionen für Merkmalsdefinitionen hinzufügen und nachverfolgen, wird dies viel einfacher sein. Wir können die Version aktualisieren und dann optional ältere Daten neu verarbeiten, um einen neuen Satz von Merkmalswerten für die neue Version zu erstellen.

9. (Manchmal) Löschung von Merkmalswerten

Manchmal müssen wir in der Lage sein, Merkmalswerte aus unserem Merkmalspeicher zu löschen. Das kann aus Gründen der Politik/Governance geschehen, z. B. wenn wir diese Merkmalswerte nicht mehr speichern dürfen, weil eine Person oder eine Regierung diese Erlaubnis widerrufen hat. Es kann auch aus Gründen der Qualität/Effizienz sein: Wir können beschließen, dass diese Werte in irgendeiner Weise schlecht sind (z. B. beschädigt, in einer verzerrten Art und Weise erfasst) oder einfach zu alt, um nützlich zu sein.

10. (Eventuell) Abschaffung einer Merkmalsdefinition

Alles hat einmal ein Ende, auch nützliche Funktionen. Irgendwann im Lebenszyklus des Modells werden wir entweder einen besseren Weg finden, um den Wert, den diese Funktionsdefinition bietet, bereitzustellen, oder feststellen, dass sich die Welt so sehr verändert hat, dass diese Funktion keinen Wert mehr hat. Letztendlich werden wir uns entscheiden, die Feature-Definition (und die Werte) komplett zu löschen. Wir müssen alle Serving Codes, die sich auf das Feature beziehen, entfernen, die Feature-Werte im Feature Store löschen, den Code, der das Feature aus den Daten von extrahiert, abbrechen und mit dem Löschen des Feature-Codes fortfahren.

Feature Systeme

Um den Datenfluss durch unsere Systeme erfolgreich zu steuern und Daten in Merkmale umzuwandeln, die von unserem Schulungssystem genutzt und von unseren Modellierern verwaltet werden können, müssen wir die Arbeit in mehrere Teilsysteme aufteilen.

Wie in der Einleitung zu diesem Kapitel erwähnt, wird eines dieser Systeme ein Metadatensystem sein, das Informationen über die Daten, die Datensätze, die Merkmalserstellung und die Beschriftungen erfasst. Da dieses System in den meisten Fällen mit allen Kennzeichnungssystemen gemeinsam genutzt wird, werden wir es am Ende dieses Kapitels besprechen. Gehen wir nun die Feature-Systeme durch, beginnend mit den Rohdaten und endend mit den Features, die in einem Format gespeichert sind, das von einem Trainingssystem gelesen werden kann.

Dateneingabesystem

Wir müssen eine Software schreiben, die Rohdaten liest, unseren Code zur Merkmalsextraktion auf diese Daten anwendet und die resultierenden Merkmalswerte im Merkmalsspeicher speichert. Bei einer einmaligen Extraktion, selbst bei sehr großen Datenmengen, kann dies ein relativ spontaner Prozess mit einem Code sein, der nur einmal ausgeführt werden muss. Aber in vielen Fällen ist der Prozess der Datenextraktion ein eigenes Produktionssystem.

Wenn wir viele Nutzer oder eine wiederholte Nutzung des Dateneingabesystems haben, sollte es als eine bedarfsgesteuerte, wiederholbare und überwachte Datenverarbeitungspipeline strukturiert sein. Wie bei den meisten Pipelines ist die größte Variable der Nutzercode. Wir brauchen ein System, in dem die Autoren von Merkmalen einen Code schreiben, der die Merkmale identifiziert und extrahiert, um sie im Merkmalsspeicher zu speichern. Wir können die Feature-Autoren ihren Code entweder selbst schreiben lassen, was für sie eine große Belastung bedeutet, oder wir können die Herausforderung annehmen und ihnen eine Entwicklungsumgebung zur Verfügung stellen. Das hilft ihnen, zuverlässigen Code für die Feature-Extraktion zu schreiben, damit wir diesen Code zuverlässig in unserem Dateneingabesystem ausführen können.

Wir müssen ein paar Systeme aufbauen, die es den Autoren von Merkmalen erleichtern, zuverlässige und korrekte Merkmale zu schreiben. Zunächst einmal sollten wir beachten, dass Features versioniert werden sollten. Es ist wahrscheinlich, dass wir ein Feature im Laufe der Zeit stark verändern wollen, z. B. aufgrund von Änderungen in den Daten, mit denen es zusammengeführt wird, oder aufgrund anderer Faktoren, die mit den von uns gesammelten Daten zusammenhängen. In diesen Fällen hilft eine Funktionsversion, den Übergang klar zu gestalten und unbeabsichtigte Folgen der Änderung zu vermeiden.

Als Nächstes brauchen wir ein Testsystem, das den Code für die Merkmalsextraktion auf seine grundsätzliche Korrektheit überprüft. Dann brauchen wir eine Testumgebung, in der wir die vorgeschlagene Merkmalsextraktion an einer bestimmten Anzahl von Beispielen ausprobieren und diese den Autoren des Merkmals zusammen mit grundlegenden Analysewerkzeugen zur Verfügung stellen, um sicherzustellen, dass das Merkmal das extrahiert, was es extrahieren soll. An diesem Punkt können wir das Feature zur Ausführung freigeben oder eine zusätzliche Überprüfung durch einen Menschen verlangen, um die Zuverlässigkeit zu gewährleisten (z. B. die Abhängigkeit von externen Daten). Je mehr Arbeit wir hier leisten, desto produktiver werden die Feature-Autoren sein.

Schließlich ist es wichtig zu wissen, dass einige Kennzeichnungen aus den Daten, die uns zum Zeitpunkt der Dateneingabe vorliegen, berechnet oder generiert werden können. Ein gutes Beispiel dafür sind die Produkt- und Verkaufsvorschläge bei YarnIt. Wir schlagen Produkte vor, um mehr davon zu verkaufen. Die Merkmale sind die Eigenschaften des Produkts oder Merkmale über den Kunden, und das Label ist, ob der Kunde es gekauft hat oder nicht. Solange wir die Vorschlagsprotokolle mit den Bestellungen verknüpfen können, haben wir dieses Label, wenn wir die Merkmale konstruieren. In solchen Fällen generiert das Dateneingabesystem neben den Merkmalen selbst auch Labels für diese Merkmale, die zusammen in einem gemeinsamen Datenspeicher gespeichert werden können. Mehr über die Beschriftung von Systemen erfährst du unter "Labels".

Feature Store

Ein Feature Store ist eine Speicherung , die dazu dient, extrahierte Feature- (und Label-) Werte zu speichern, damit sie beim Training eines Modells und sogar bei der Inferenz schnell und konsistent gelesen werden können. Die meisten ML-Trainings- und Serversysteme haben eine Art Feature Store, auch wenn er nicht so genannt wird.2 Am nützlichsten sind sie jedoch in größeren, zentral verwalteten Diensten, vor allem wenn die Merkmale (sowohl Definitionen als auch Werte) von mehreren Modellen gemeinsam genutzt werden. Die Erkenntnis, wie wichtig es ist, unsere Merkmals- und Bezeichnungsdaten an einem einzigen, gut verwalteten Ort zu speichern, hat die Produktionsfähigkeit von ML in der Branche erheblich verbessert. Aber Feature Stores lösen nicht jedes Problem, und viele erwarten mehr von ihnen, als sie leisten können. Schauen wir uns die Probleme an, die ein Feature Store löst, und die Vorteile, die er für dein Trainingssystem bietet.

Das wichtigste Merkmal eines Feature stores ist seine API. Verschiedene kommerzielle und Open-Source-Feature-Stores haben unterschiedliche APIs, aber alle sollten ein paar grundlegende Funktionen bieten:

Merkmalsdefinitionen speichern
Normalerweise werden diese als Code gespeichert, der das Merkmal in einem Rohdatenformat extrahiert und die Merkmalsdaten im gewünschten Format ausgibt.
Merkmalswerte selbst speichern
Letztendlich müssen wir die Funktionen in einem Format schreiben, das einfach zu schreiben, zu lesen und zu benutzen ist. Dies wird größtenteils durch die von uns vorgeschlagenen Anwendungsfälle bestimmt und wird in der Regel in geordnete und ungeordnete Daten unterteilt, aber wir behandeln die Feinheiten in "Lifecycle Access Patterns".
Merkmalsdaten servieren
Biete einen schnellen und effizienten Zugriff auf die Merkmalsdaten mit einer für die Aufgabe geeigneten Leistung. Wir wollen auf keinen Fall, dass teure CPUs oder Beschleuniger abgewürgt werden, weil sie auf das Einlesen von Daten aus unserem Feature Store warten. Das ist eine sinnlose Verschwendung einer teuren Ressource.
Koordiniere das Schreiben von Metadaten mit dem Metadatensystem
Um das Beste aus unserem Feature Store herauszuholen, sollten wir Informationen über die Daten, die wir darin speichern, im Metadatensystem aufbewahren. Das hilft den Modellbauern. Beachte, dass sich Metadaten über Features von Metadaten über Pipeline-Durchläufe unterscheiden, obwohl beide bei der Fehlersuche und Reproduktion von Problemen nützlich sind. Feature-Metadaten sind am nützlichsten für Modellentwickler, während Pipeline-Metadaten am nützlichsten für ML-Zuverlässigkeits- oder Produktionsingenieure sind.

Viele Feature Stores ( ) bieten auch eine grundlegende Normalisierung der Daten beim Ingestion sowie komplexere Transformationen der Daten im Store. Die gebräuchlichsten Transformationen sind das standardisierte In-Store-Bucketing und integrierte Transformationsfunktionen.3

Die Feature Store API muss sorgfältig auf den Anwendungsfall abgestimmt werden. Wir sollten uns die folgenden Fragen stellen, wenn wir darüber nachdenken, was wir in einem Feature Store brauchen:

  • Lesen wir die Daten in einer bestimmten Reihenfolge (Protokollzeilen mit Zeitstempel) oder in einer Reihenfolge, die keine Rolle spielt (eine große Sammlung von Bildern in einer Cloud Speicherung)?

  • Werden wir die Merkmale häufig lesen oder nur, wenn wir ein neues Modell trainieren? Wie ist insbesondere das Verhältnis von gelesenen zu geschriebenen Bytes/Datensätzen?

  • Werden die Merkmalsdaten einmal aufgenommen, nie ergänzt und selten aktualisiert? Oder werden die Daten häufig ergänzt, während ältere Daten kontinuierlich gelöscht werden?

  • Können die Werte von Merkmalen aktualisiert werden, oder ist der Store nur für Anhänge geeignet?

  • Gibt es besondere Datenschutz- oder Sicherheitsanforderungen für die Daten, die wir speichern? In den meisten Fällen werden die extrahierten Merkmale eines Datensatzes mit Datenschutz- und Nutzungsbeschränkungen auch Datenschutz- und Nutzungsbeschränkungen haben.

Nachdem wir über diese Fragen nachgedacht haben, sollten wir in der Lage sein, unseren Bedarf an einer Speicherung von Merkmalen zu bestimmen. Wenn wir Glück haben, können wir einen der bestehenden kommerziellen oder Open-Source-Feature-Stores auf dem Markt nutzen. Wenn nicht, müssen wir diese Funktionen selbst implementieren, entweder auf unkoordinierte Weise oder als Teil eines kohärenteren Systems.

Wenn wir uns über die Anforderungen für eine API im Klaren sind und unsere Anforderungen an den Datenzugriff genauer kennen, werden wir im Allgemeinen feststellen, dass unser Feature Store in eine von zwei Kategorien fällt:4

Rubriken
Die Daten sind strukturiert und in Spalten zerlegbar, von denen nicht alle in allen Modellen verwendet werden. In der Regel sind die Daten auch in irgendeiner Weise geordnet, oft nach Zeit. In diesem Fall ist die spaltenorientierte Speicherung am flexibelsten und effizientesten.
Blobs
Das ist ein Akronym für Binary Large Objects, aber auch das gebräuchliche englische Wort ist aussagekräftig. In diesem Fall sind die Daten grundsätzlich ungeordnet, meist unstrukturiert und werden am besten auf eine Art und Weise gespeichert, die effizienter ist als die Speicherung eines Haufens von Bytes.

Viele Feature-Stores müssen teilweise oder vollständig repliziert werden, um Daten in der Nähe der Trainings- und Serving-Stacks zu speichern. Da der ML-Rechenaufwand für das Training in der Regel beträchtlich ist, ziehen wir es oft vor, die Daten an den Ort oder die Orte zu verlagern, an denen wir den besten Gegenwert für unseren Trainingsdollar erhalten können. Die Implementierung des Feature Stores als Service erleichtert die Verwaltung dieser Replikation.

System zur Bewertung der Qualität von Merkmalen

Wenn wir neue Funktionen entwickeln, müssen wir bewerten, ob und wie diese Funktionen die Qualität des Gesamtmodells in Kombination mit den bestehenden Funktionen verbessern. Dieses Thema wird in Kapitel 5 ausführlich behandelt. An dieser Stelle sollten wir wissen, dass wir die Ansätze der Verwendung leicht unterschiedlicher Modelle, des A/B-Tests und eines Systems zur Bewertung der Modellqualität kombinieren können, um den Nutzen jeder neuen Funktion, die wir entwickeln, effektiv zu bewerten. Das geht schnell und zu relativ geringen Kosten.

Ein gängiger Ansatz ist es, ein bestehendes Modell zu nehmen und es mit einem einzigen zusätzlichen Merkmal neu zu trainieren. Bei einer Webanwendung wie bei YarnIt können wir dann einen Teil der Nutzeranfragen an das neue Modell weiterleiten und seine Leistung bei einer Aufgabe bewerten. Wenn wir zum Beispiel eine Funktion für Country the User Is In zu einem Modell hinzufügen, das dem Nutzer neue Produkte zum Ausprobieren vorschlägt, können wir 1 % der Nutzeranfragen (entweder nach Anfrage oder nach Nutzer) an das neue Modell weiterleiten. Wir können bewerten, ob das neue Modell eine höhere Wahrscheinlichkeit hat, Produkte zu empfehlen, die die Nutzer/innen auch tatsächlich kaufen, und können so entscheiden, ob wir die neue Funktion beibehalten oder sie streichen und andere Ideen ausprobieren.

Denke daran, dass selbst eine Funktion, die einen Mehrwert bietet, möglicherweise nicht die Kosten für die Erfassung, Verarbeitung, Speicherung und Pflege der Daten wert ist. Es ist eine gute Angewohnheit, für jede neue Funktion, die dem System hinzugefügt wird, eine ungefähre Investitionsrendite (ROI) zu berechnen, mit Ausnahme der trivialsten Funktionen. Das hilft uns, nützliche Funktionen zu vermeiden, die teurer sind als der Mehrwert, den sie bringen.

Etiketten

Obwohl die Merkmale die wichtigsten Aspekte der Daten zu sein scheinen, ist eine Sache noch wichtiger: die Beschriftungen. Bis zu diesem Punkt solltest du ein solides Verständnis davon haben, wozu die Merkmale dienen und welche Systemüberlegungen bei der Verwaltung einer großen Anzahl von Merkmalen berücksichtigt werden sollten. Aber vor allem überwachte Lernmodelle brauchen Labels.

Labels sind die andere Hauptkategorie von Daten, die beim Training eines ML-Modells verwendet werden. Während die Merkmale als Eingabe für das Modell dienen, sind die Bezeichnungen Beispiele für die richtige Modellausgabe. Sie werden im Trainingsprozess verwendet, um die (vielen!) internen Parameter des Modells einzustellen und das Modell so zu tunen, dass es die gewünschten Ergebnisse für die Merkmale liefert, die es zur Inferenzzeit erhält. Ausgelassene Beispiele und Labels (Labels, die nicht im Training verwendet wurden) werden auch bei der Modellbewertung verwendet, um die Qualität des Modells zu verstehen.

Wie wir bereits besprochen haben, können für einige Problemklassen, wie z. B. unser Empfehlungssystem, die Labels algorithmisch aus den Logdaten des Systems generiert werden. Diese Merkmale sind fast immer konsistenter und genauer als von Menschen erstellte Merkmale. Da diese Daten oft zusammen mit den Merkmalsdaten aus den Logdaten des Systems generiert werden, werden diese Kennzeichnungen meist im Merkmalsystem für die Modellschulung und -bewertung gespeichert. Tatsächlich können alle Kennzeichnungen im Merkmalsspeicher gespeichert werden, obwohl von Menschen erstellte Kennzeichnungen zusätzliche Systeme benötigen, um diese Kennzeichnungen zu erstellen, zu validieren und zu korrigieren, bevor sie für die Modellschulung und -bewertung gespeichert werden. Wir besprechen diese Systeme im nächsten Abschnitt.

Von Menschen erstellte Etiketten

Wenden wir uns also den großen Klassen von Problemen zu, die menschliche Anmerkungen benötigen, um die Trainingsdaten für das Modell zu liefern. Die Entwicklung eines Systems zur Analyse und Interpretation menschlicher Sprache erfordert zum Beispiel menschliche Anmerkungen, um sicherzustellen, dass die Transkription korrekt ist und um zu verstehen, was der Sprecher gemeint hat. Für die Analyse und das Verstehen von Bildern werden oft kommentierte Beispielbilder für die Klassifizierung oder Erkennung von Bildern benötigt. Diese menschlichen Anmerkungen in dem Umfang zu erhalten, der für das Training eines ML-Modells erforderlich ist, ist sowohl aus Implementierungs- als auch aus Kostensicht eine Herausforderung. Wir müssen uns bemühen, effiziente Systeme zu entwickeln, um diese Kommentare zu erstellen. Im Folgenden werden wir uns auf die wichtigsten Komponenten dieser Systeme für menschliche Annotationen konzentrieren.

Ein konkretes Beispiel für unseren fiktiven Garnladen YarnIt ist eine neue Funktion auf , die bei einem Bild eines gehäkelten Stoffes die Häkelmasche vorhersagen kann, mit der dieser Stoff hergestellt wurde. Für ein solches Modell muss jemand die Menge der Häkelstiche entwerfen, die das Modell vorhersagen soll, und die Menge der Klassen bereitstellen, die das Modell ausgeben kann. Dann müssen große Mengen an Bildern von gehäkelten Stoffen, die alle diese Stiche abdecken, von Häkelexperten beschriftet werden, um festzustellen, mit welcher Masche dieser Stoff hergestellt wurde. Anhand dieser Expertenkennzeichnungen kann ein Modell trainiert werden, das neue Bilder von gehäkeltem Stoff klassifiziert und die verwendete Masche bestimmt.

Das ist nicht billig. Menschen müssen für diese Aufgabe geschult werden, und jedes Bild muss unter Umständen mehrmals beschriftet werden, um vertrauenswürdige Ergebnisse zu erhalten. Aufgrund der hohen Kosten, die mit der Beschaffung der von Menschen erstellten Kennzeichnungen verbunden sind, sollten die Trainingssysteme so konzipiert sein, dass sie so viel wie möglich davon profitieren. Eine Technik, die häufig eingesetzt wird, ist die Datenerweiterung: Die Merkmalsdaten werden auf eine Art und Weise "gefuscht", die die Merkmale verändert, aber nicht die Korrektheit der Kennzeichnung beeinträchtigt.5 Nehmen wir zum Beispiel unser Problem der Stichklassifizierung. Gängige Bildoperationen wie Skalieren, Beschneiden, Hinzufügen von Bildrauschen und Ändern der Farbbalance ändern nichts an der Klassifizierung des Stichs im Bild, können aber die Anzahl der Bilder, die dem Modell zum Trainieren zur Verfügung stehen, erheblich erhöhen. Ähnliche Techniken können auch bei anderen Problemklassen eingesetzt werden. Es muss jedoch darauf geachtet werden, dass nicht mit zwei Bildern trainiert und getestet wird, die aus demselben Ausgangsbild gefuzzt wurden. Aus diesem Grund sollte jede Datenerweiterung dieser Art im Trainingssystem und nicht im Kennzeichnungssystem vorgenommen werden (oder auch nicht, und sei vorsichtig, wenn du einen guten Grund hast, etwas anderes zu tun, wie z. B. einen sehr teuren Fuzzing-Algorithmus).

Ein wichtiger Hinweis: Während einige Arten von enorm komplexen Daten am besten von Menschen beschriftet werden können, sind andere Arten von Daten definitiv nicht von Menschen zu beschriften. Dabei handelt es sich in der Regel um abstrakte Daten mit hoher Dimensionalität, die es einem Menschen schwer machen, schnell die richtige Antwort zu finden. Manchmal können Menschen mit Hilfe von Erweiterungssoftware bei diesen Aufgaben unterstützt werden, aber manchmal sind sie einfach die falsche Option, um die Kennzeichnung durchzuführen.

Anmerkung Arbeitskräfte

Die erste Frage, die sich bei Problemen mit der menschlichen Beschriftung stellt, ist, wer die Beschriftung vornehmen soll. Dies ist eine Frage des Umfangs und der Gerechtigkeit.6 Bei einfacheren Modellen, bei denen eine kleine Datenmenge ausreicht, um das Modell zu trainieren, nimmt der Ingenieur, der das Modell erstellt, die Beschriftung selbst vor, oft mit selbstgebauten Werkzeugen (und der Gefahr, dass die Beschriftung verfälscht wird). Für komplexere Modelle werden spezielle Beschriftungsteams eingesetzt, die menschliche Beschriftungen in einem Umfang vornehmen, der sonst nicht möglich wäre.

Diese speziellen Annotationsteams können beim Modellbauer angesiedelt sein oder von Drittanbietern bereitgestellt werden. Sie reichen von einer einzelnen Person bis zu Hunderten von Personen, die alle kommentierte Daten für ein einziges Modell erstellen. Der Amazon Mechanical Turk Service war die ursprüngliche Plattform, die dafür genutzt wurde, aber seither haben sich eine Vielzahl von Crowdsourcing-Plattformen und -Diensten entwickelt. Einige dieser Dienste nutzen bezahlte Freiwillige, andere setzen Teams von Angestellten ein, um die Daten zu beschriften.

Bei der Wahl der Kennzeichnung muss ein Kompromiss zwischen Kosten, Qualität und Konsistenz gefunden werden. Crowdsourced Labeling erfordert oft zusätzlichen Aufwand, um die Qualität und Konsistenz zu überprüfen, aber bezahltes Personal für die Beschriftung kann teuer sein. Die Kosten für diese Beschriftungsteams können leicht die Kosten für das Training der Modelle übersteigen. In Kapitel 13 gehen wir auf einige organisatorische Herausforderungen bei der Verwaltung eines großen Kommentatorenteams ein.

Messung der Qualität von menschlichen Kommentaren

Da die Qualität eines jeden Modells nur so gut ist wie die Daten, die zum Trainieren des Modells verwendet werden, muss die Qualität von Anfang an in das System integriert werden. Das gilt umso mehr, je größer das Annotationsteam ist. Qualität kann je nach Aufgabe auf verschiedene Weise erreicht werden, aber zu den am häufigsten verwendeten Techniken gehören die folgenden:

Mehrfachkennzeichnung (auch Konsenskennzeichnung genannt)
Dieselben Daten werden mehreren Etikettierern gegeben, um zu überprüfen, ob sie übereinstimmen.
Fragen zum Golden Set Test
Vertrauenswürdige Etikettierer/innen (oder der/die Modellbauer/in) erstellen eine Reihe von Testfragen, die nach dem Zufallsprinzip in die unetikettierten Daten aufgenommen werden, um die Qualität der erstellten Etiketten zu bewerten.
Ein separater QA-Schritt
Ein Teil der Daten des Etikettierers wird von einem vertrauenswürdigen QS-Team überprüft. (Wer prüft das QS-Team? Vielleicht der Ersteller des Modells, aber je nach Kontext kann es sich auch um ein separates QS-Team, einen Richtlinienexperten oder eine andere Person mit Fachwissen handeln).

Sobald sie gemessen wurden, können die Qualitätskennzahlen verbessert werden. Qualitätsproblemen begegnet man am besten, indem man das Kommentatorenteam mit Bescheidenheit führt und sich bewusst macht, dass es qualitativ hochwertigere Ergebnisse erzielen wird, wenn es die folgenden Voraussetzungen erfüllt:

  • Mehr Schulung und Dokumentation

  • Anerkennung für Qualität und nicht nur für Durchsatz

  • Vielfältige Aufgaben während des Arbeitstages

  • Leicht zu bedienende Werkzeuge

  • Aufgaben mit einer ausgewogenen Anzahl von Antworten (keine "Nadel im Heuhaufen"-Aufgaben)

  • Eine Möglichkeit, Feedback zu den Tools und Anweisungen zu geben

Auf diese Weise geführte Beschriftungsteams können qualitativ hochwertige Ergebnisse liefern. Aber auch der beste und gewissenhafteste Beschrifter wird gelegentlich etwas übersehen. Deshalb sollten die Prozesse so gestaltet sein, dass sie diese gelegentlichen Fehler erkennen oder akzeptieren.

Eine Annotationsplattform

Eine Beschriftungsplattform organisiert den Fluss der zu beschriftenden Daten und die Ergebnisse der Beschriftungen und liefert gleichzeitig Qualitäts- und Durchsatzmetriken für den Gesamtprozess. Im Kern handelt es sich bei diesen Systemen in erster Linie um Warteschlangensysteme, mit denen die Annotationsarbeit auf die Annotatoren aufgeteilt wird. Das eigentliche Beschriftungstool, mit dem die Beschrifter/innen die Daten ansehen und ihre Anmerkungen machen können, sollte flexibel sein, um jede beliebige Beschriftungsaufgabe zu unterstützen.

In einem Team oder einer Organisation, die an mehreren Modellen gleichzeitig arbeitet, kann ein und dasselbe Annotations-Team für mehrere Annotationsprojekte eingesetzt werden. Außerdem kann jeder Annotator über unterschiedliche Fähigkeiten verfügen (z. B. Sprachkenntnisse oder Wissen über Häkelstiche), und die Warteschlangensysteme können relativ komplex sein und erfordern ein sorgfältiges Design, um Probleme wie Skalierbarkeit oder Warteschlangenmangel zu vermeiden. Pipelines, die es ermöglichen, dass der Output einer Annotationsaufgabe als Input für eine andere dient, können für komplexe Arbeitsabläufe nützlich sein. Die Qualitätsmessung mit den zuvor besprochenen Techniken sollte von Anfang an in das System integriert werden, damit die Projektverantwortlichen den Durchsatz und die Qualität aller ihrer Annotationsaufgaben nachvollziehen können.

Obwohl in der Vergangenheit viele Unternehmen ihre eigenen Beschriftungsplattformen mit ihren eigenen Funktionen implementiert haben, gibt es viele Optionen für vorgefertigte Beschriftungsplattformen. Die großen Cloud-Provider und viele kleinere Start-ups bieten Beschriftungsplattformen an, die mit beliebigen Annotation Workforces genutzt werden können, und viele Annotation Workforce Provider haben ihre eigenen Plattformoptionen, die genutzt werden können. Dieser Bereich verändert sich schnell und die bestehenden Plattformen werden laufend um neue Funktionen erweitert. Öffentlich verfügbare Tools gehen über einfache Warteschlangensysteme hinaus und bieten spezielle Tools für gängige Aufgaben an, darunter auch fortschrittliche Funktionen wie KI-gestützte Beschriftung (siehe folgender Abschnitt). Bei der Entscheidung für eine neue Technologieplattform müssen neben den Fähigkeiten der Plattform auch die Datensicherheit und die Integrationskosten berücksichtigt werden.

Wie im Abschnitt "Merkmalspeicher" erwähnt , ist es in vielen Fällen am sinnvollsten, fertige Beschriftungen im Merkmalspeicher zu speichern. Indem wir menschliche Anmerkungen als eigene Spalten behandeln, können wir alle anderen Funktionen des Merkmalspeichers in Anspruch nehmen.

Aktives Lernen und KI-unterstützte Beschriftung

Aktive Lerntechniken können den Beschriftungsaufwand auf die Fälle konzentrieren, in denen das Modell und die menschlichen Beschreiber nicht übereinstimmen oder das Modell am unsichersten ist, und so die Qualität der Beschriftung insgesamt verbessern. Nehmen wir zum Beispiel ein Bilderkennungsproblem, bei dem der Beschrifter alle Vorkommen eines bestimmten Objekts in einem Bild beschriften muss. Ein aktiv lernendes Beschriftungswerkzeug könnte ein bestehendes Modell verwenden, um das Bild mit vorgeschlagenen Erkennungen des fraglichen Objekts vorzubeschriften. Der Beschrifter würde dann die korrekten vorgeschlagenen Erkennungen bestätigen, die schlechten verwerfen und die fehlenden ergänzen. Dies kann den Durchsatz des Etikettierers zwar erheblich steigern, muss aber mit Bedacht geschehen, damit die Modelle nicht verzerrt werden. Solche aktiven Lerntechniken können die Qualität der Kennzeichnung insgesamt verbessern, da das Modell und der Mensch oft bei unterschiedlichen Eingabedaten die beste Leistung erbringen.

Ein halbüberwachtes System ermöglicht es dem Modellierer, das System mit schwachen heuristischen Funktionen zu booten, die die Beschriftungen einiger Daten unvollkommen vorhersagen, und dann Menschen zu benutzen, um ein Modell zu trainieren, das diese unvollkommenen Heuristiken auf hochwertige Trainingsdaten anwendet. Solche Systeme sind besonders wertvoll für Probleme mit komplexen, sich häufig ändernden Kategoriendefinitionen, bei denen die Modelle schnell und häufig neu trainiert werden müssen.

Effiziente Annotationstechniken für besonders komplexe Beschriftungsaufgaben sind ein fortlaufendes Forschungsgebiet. Vor allem, wenn du ein häufiges Annotationsproblem hast, lohnt sich ein kurzer Blick auf die verfügbaren Tools von Cloud- und Annotationsanbietern, da diese häufig neue Funktionen für die KI-gestützte Annotation hinzufügen.

Dokumentation und Schulung für Etikettierer

Dokumentation und Beschriftungssysteme Schulungssysteme gehören zu den am häufigsten übersehenen Teilen einer Beschriftungsplattform. Die Beschriftungsanweisungen fangen oft einfach an, werden aber unweigerlich komplexer, wenn die Daten beschriftet werden und verschiedene Eckfälle entdeckt werden. Um unser vorheriges YarnIt-Beispiel fortzusetzen: Vielleicht werden einige Häkelstiche in den Beschriftungsanweisungen nicht erwähnt, oder der Stoff besteht aus mehreren verschiedenen Stichen. Selbst konzeptionell einfache Beschriftungsaufgaben wie "alle Personen in einem Bild markieren" können mit umfangreichen Anweisungen zum richtigen Umgang mit verschiedenen Eckfällen enden (Spiegelungen, Bilder von Personen, Personen hinter Autofenstern usw.).

Die Beschriftungsdefinitionen und -anweisungen sollten aktualisiert werden, wenn neue Eckfälle entdeckt werden, und die Annotations- und Modellierungsteams sollten über die Änderungen informiert werden. Wenn die Änderungen signifikant sind, müssen die bereits beschrifteten Daten möglicherweise neu beschriftet werden, um die mit den alten Anweisungen beschrifteten Daten zu korrigieren. Da die Beschriftungsteams oft eine hohe Fluktuation aufweisen, sind Investitionen in Schulungen für die Verwendung von Beschriftungstools und das Verständnis der Beschriftungsanweisungen fast immer ein großer Gewinn für die Qualität der Beschriftung und den Durchsatz.

Metadaten

Sowohl Merkmalssysteme als auch Kennzeichnungssysteme profitieren von einer effizienten Nachverfolgung der Metadaten. Da du nun ein relativ vollständiges Verständnis der Daten hast, die von einem Feature- oder Kennzeichnungssystem geliefert werden, kannst du dir Gedanken darüber machen, welche Metadaten bei diesen Vorgängen erzeugt werden.

Überblick über Metadatensysteme

Ein Metadatensystem ist so konzipiert , dass es den Überblick darüber behält, was wir tun. Im Fall von Merkmalen und Bezeichnungen sollte es zumindest die Merkmalsdefinitionen und die Versionen, die in den Definitionen und trainierten Modellen verwendet werden, festhalten. Aber es lohnt sich, einen Moment innezuhalten und zu versuchen, in die Zukunft zu blicken: Was werden wir letztendlich von einem Metadatensystem erwarten, und gibt es eine Möglichkeit, das vorauszusehen?

Die meisten Unternehmen beginnen mit dem Aufbau ihrer Data-Sciences- und ML-Infrastruktur ohne ein solides Metadatensystem, um es später zu bereuen. Der nächste gängige Ansatz ist der Aufbau mehrerer Metadatensysteme, die jeweils auf die Lösung eines bestimmten Problems ausgerichtet sind. Genau das werden wir hier tun: ein System für die Nachverfolgung von Feature-Definitionen und Mappings zu Feature-Stores. Schon in diesem Kapitel wirst du sehen, dass wir Metadaten über Labels speichern müssen, einschließlich ihrer Spezifikation und wann bestimmte Labels auf bestimmte Feature-Werte angewendet wurden. Später werden wir ein System brauchen, mit dem wir Modelldefinitionen auf trainierte Modelle abbilden können, zusammen mit Daten über die Ingenieure oder Teams, die für diese Modelle verantwortlich sind. Unser Model Serving System muss auch den Überblick über die trainierten Modellversionen behalten, wann sie in Produktion gegangen sind. Alle Systeme zur Bewertung der Modellqualität oder der Fairness müssen aus all diesen Systemen ausgelesen werden, um die wahrscheinlichen Ursachen für Veränderungen der Modellqualität oder Verstöße gegen die von uns vorgeschlagenen Fairness-Metriken zu ermitteln und zu verfolgen.

Unsere Entscheidung für ein Metadatensystem ist relativ einfach:

Ein System
Baue ein System auf, um Metadaten aus all diesen Quellen zu erfassen. Das macht es einfach, Korrelationen über mehrere Subsysteme hinweg herzustellen, was die Analyse und Berichterstattung vereinfacht. Ein so großes System ist aus Sicht des Datenschemas schwierig zu gestalten. Wir werden ständig neue Spalten hinzufügen, wenn wir Daten entdecken, die wir im Auge behalten wollen (und diese Spalten mit bestehenden Daten auffüllen). Es wird auch schwierig sein, ein solches System zu stabilisieren und zuverlässig zu machen. Aus der Perspektive des Systemdesigns sollten wir sicherstellen, dass unsere Metadatensysteme nie in den Live-Pfad der Modellschulung oder des Modellservices geraten. Es ist jedoch schwer vorstellbar, wie das Feature Engineering oder die Beschriftung stattfinden kann, ohne dass das Metadatensystem funktioniert.
Mehrere Systeme (die zusammenarbeiten)
Wir können für jede Aufgabe, die wir identifizieren, ein eigenes Metadatensystem aufbauen. Vielleicht hätten wir eines für Merkmale und Kennzeichnungen, eines für die Ausbildung, eines für die Bedienung und eines für die Qualitätskontrolle. Die Entkopplung der Systeme bietet die üblichen Vorteile und Kosten, die eine Entkopplung immer mit sich bringt. So können wir jedes System separat entwickeln, ohne uns um die anderen zu kümmern, was die Systeme flinker und einfacher zu ändern und zu erweitern macht. Außerdem hat ein Ausfall eines Metadatensystems nur begrenzte Auswirkungen auf die anderen Systeme. Der Preis dafür ist jedoch die zusätzliche Schwierigkeit der Analyse und Berichterstattung über diese Systeme hinweg. Es wird Prozesse geben, die Daten aus den Systemen für Merkmale, Kennzeichnung, Schulung und Bereitstellung zusammenführen müssen. Mehrere Systeme sollten immer so konzipiert sein, dass ihre Daten zusammengeführt werden können. Das bedeutet entweder, dass eindeutige Bezeichner erstellt und gemeinsam genutzt werden oder dass ein Metadatensystem eingerichtet wird, das die Beziehungen zwischen den Datenfeldern in den Metadatensystemen verfolgt.

Wenn die Bedürfnisse einfach sind und gut verstanden werden, solltest du ein einziges System bevorzugen.7 Wenn sich der Bereich schnell entwickelt und unsere Teams erwarten, dass sie das, was sie verfolgen und wie sie arbeiten, immer weiter ausbauen, werden mehrere Systeme die Entwicklung im Laufe der Zeit vereinfachen.

Metadaten zum Datensatz

Für die Metadaten zu Merkmalen und Bezeichnungen gibt es ein paar spezifische Elemente, die wir sicherstellen sollten, dass sie enthalten sind:

Herkunft der Datensätze
Woher stammen die Daten? Je nach der Quelle unserer Daten haben wir vielleicht eine Nachschlagetabelle mit Protokollen von verschiedenen Systemen, einen Schlüssel für einen externen Datenanbieter mit Daten darüber, wann wir die Daten heruntergeladen haben, oder sogar einen Verweis auf den Code, der die Daten erzeugt hat.
Standort des Datensatzes
Für einige Datensätze werden wir rohe, unbearbeitete Daten speichern. In diesem Fall sollten wir einen Verweis darauf speichern, wo wir den Datensatz aufbewahren, und vielleicht auch Informationen darüber, woher wir ihn haben. Einige Daten erstellen wir laufend für uns selbst, z. B. die Protokolle unserer Systeme. In diesen Fällen sollten wir den Verweis auf das Protokoll oder den Datenspeicher speichern, in dem diese Daten gespeichert sind oder aus dem wir sie lesen dürfen.
Verantwortliche Person oder Team für den Datensatz
Wir sollten nachverfolgen, welche Person oder welches Team für den Datensatz verantwortlich ist. In der Regel ist das das Team, das den Datensatz heruntergeladen oder erstellt hat, oder das Team, dem das System gehört, das die Daten produziert.
Erstellungsdatum oder Versionsdatum des Datensatzes
Oft ist es nützlich, das erste Datum zu kennen, an dem ein bestimmter Datensatz verwendet wurde.
Einschränkungen bei der Nutzung von Datensätzen
Bei vielen Datensätzen gibt es Beschränkungen für die Nutzung von , entweder aufgrund von Lizenzen oder aufgrund von Verwaltungsauflagen. Wir sollten dies im Metadatensystem dokumentieren, damit wir es später leicht analysieren und einhalten können.

Merkmal Metadaten

Die Erfassung von Metadaten über unsere Merkmalsdefinitionen ist ein Teil dessen, was es uns ermöglicht, diese Merkmale zuverlässig zu nutzen und zu pflegen. Zu diesen Metadaten gehören die folgenden:

Definition der Feature-Version
Die Feature-Definition ist ein Verweis auf Code oder eine andere dauerhafte Beschreibung, welche Daten das Feature liest und wie es die Daten verarbeitet, um das Feature zu erstellen. Sie sollte für jede aktualisierte Version der Feature-Definition aktualisiert werden. Wie bereits beschrieben, macht die Versionierung dieser Definitionen (und die Beschränkung der verwendeten Versionen) die resultierende Codebasis berechenbarer und wartbarer.
Merkmal Definition verantwortliche Person oder Team
Es gibt zwei gute Anwendungsfälle für die Speicherung dieser Informationen: Herausfinden, wozu ein Feature dient, und jemanden finden, der bei der Lösung eines Problems helfen kann, wenn das Feature einen Fehler verursacht hat. In beiden Fällen ist es sinnvoll, Informationen über die Urheberschaft oder den Betreuer der Funktion zu speichern.
Erstellungsdatum der Feature-Definition oder Datum der aktuellen Version
Das mag zwar ziemlich offensichtlich sein, aber es ist nützlich, einen Änderungsverlauf zu erhalten, der zeigt, wann ein Feature zuletzt aktualisiert wurde und wann es ursprünglich erstellt wurde.
Einschränkungen bei der Nutzung von Funktionen
Das ist wichtig, aber schwieriger zu speichern. Die Funktionen können in bestimmten Kontexten nicht verwendet werden. Zum Beispiel kann es in einigen Ländern illegal sein, ein bestimmtes Merkmal zu verwenden. Alter und Geschlecht können ein sinnvoller Prädiktor für Risikomodelle in der Kfz-Versicherung sein, aber das Versicherungswesen ist stark reguliert und es kann sein, dass es uns nicht erlaubt ist, diese Felder zu berücksichtigen. Bestimmte Felder nur für bestimmte Zwecke zu verbieten, ist schwer nachzuvollziehen und umzusetzen, aber die Einschränkungen können noch subtiler sein. So kann zum Beispiel das Alter berücksichtigt werden, aber nur bei bestimmten, spezifischen Gruppierungen (wie under 25, 25–64, 65–79 und over 80). In diesem speziellen Fall ist es einfacher, ein Transformationsmerkmal zu definieren, das auf der Spalte age aufbaut und die Anforderungen an das Bucketing erfüllt. Dann kann das allgemeine Merkmal age nicht für Versicherungszwecke verwendet werden, während das Merkmal insurance_bucketed_age verwendet werden kann. Aber der allgemeine Fall der Speicherung und Anwendung von Merkmalsbeschränkungen auf der Grundlage von Governance-Anforderungen ist extrem schwierig, und zum Zeitpunkt der Erstellung dieses Artikels gibt es keine großartigen Entwürfe oder Lösungen.

Label-Metadaten

Wir sollten auch Metadaten zu den Labels erfassen. Diese sollen bei der Wartung und Entwicklung des Kennzeichnungssystems selbst helfen, können aber auch vom Schulungssystem genutzt werden, wenn es die Kennzeichnungen verwendet:

Version der Etikettendefinition
Wenn wir zu den Metadaten für die Etiketten wechseln, müssen wir analog zu den Merkmalen die Version der Etikettendefinitionen speichern, um zu verstehen, mit welchen Etikettierungsanweisungen die Etiketten erstellt wurden.
Version des Etikettensatzes
Zusätzlich zu den Änderungen der Bezeichnungsdefinition können Änderungen an den Bezeichnungen auftreten, weil falsche Bezeichnungen korrigiert oder neue Bezeichnungen hinzugefügt werden. Wenn der Datensatz für einen Vergleich mit einem älteren Modell verwendet wird, kann es wünschenswert sein, eine ältere Version der Bezeichnungen zu verwenden, um den Vergleich zu vereinfachen.
Quelle des Labels
Obwohl es für das Training von normalerweise nicht erforderlich ist, ist es manchmal notwendig, die Quelle jeder Kennzeichnung in einem Datensatz zu kennen. Dabei kann es sich um die Quelle handeln, von der eine bestimmte Kennzeichnung lizenziert wurde, um den Menschen, der die Kennzeichnung erstellt hat (zusammen mit der Qualitätssicherung, die auf die Kennzeichnung angewandt wurde), oder um den Algorithmus, der die Kennzeichnung erstellt hat, wenn ein automatischer Ansatz zur Kennzeichnung verwendet wurde.
Label Vertrauen
Je nachdem, wie die Kennzeichnungen erstellt werden, können wir das Vertrauen in die Korrektheit der verschiedenen Kennzeichnungen unterschiedlich einschätzen. Zum Beispiel könnten wir ein geringeres Vertrauen in Kennzeichnungen haben, die durch einen automatischen Ansatz oder durch einen neueren Kennzeichner erstellt wurden. Die Nutzer dieser Kennzeichnungen können unterschiedliche Schwellenwerte wählen, um zu entscheiden, welche Kennzeichnungen sie für das Training ihrer Modelle verwenden.

Pipeline-Metadaten

In diesem Abschnitt geht es um eine letzte Art von Metadaten, auf die wir nicht so viel Zeit verwenden werden: Metadaten über die Pipeline-Prozesse selbst. Dabei handelt es sich um Daten über die Zwischenartefakte, die wir haben, aus welchen Pipeline-Läufen sie stammen und welche Binärdateien sie erzeugt haben. Diese Art von Metadaten wird von einigen ML-Trainingssystemen automatisch erzeugt. ML-Metadaten (MLMD) sind zum Beispiel automatisch in TensorFlow Extended (TFX) enthalten, das verwendet, um Artefakte über Trainingsläufe zu speichern. Diese Systeme sind entweder in diese Systeme integriert oder nachträglich nur schwer zu implementieren. Daher gehen wir hier nicht näher auf sie ein.

Generell werden Metadatensysteme oft übersehen oder vernachlässigt. Das sollte nicht sein. Sie sind einer der effektivsten und direktesten Beiträge zur produktiven Nutzung der Daten in einem ML-System. Metadaten sind wertvoll und sollten daher vorrangig behandelt werden.

Datenschutz und Fairness

Merkmale und Kennzeichnungssysteme werfen tiefgreifende Überlegungen zum Datenschutz und zu ethischen Aspekten auf. Auch wenn viele dieser Themen in Kapitel 6 ausführlicher behandelt werden, lohnt es sich, einige spezifische Themen hier ausdrücklich zu erwähnen.

Datenschutz

Sowohl die Daten, die wir unter erhalten, als auch die menschlichen Anmerkungen zu diesen Daten können personenbezogene Daten enthalten. Die einfachste Methode, mit privaten Informationen umzugehen, besteht darin, private oder sensible Informationen einfach aus unserer Speicherung auszuschließen, aber das ist oft nicht praktikabel.

PII-Daten und Merkmale

Wenn wir planen, PII-Daten in Features zu haben, wollen wir mindestens drei Dinge im Voraus planen:

  • Minimiere die PII-Daten, die wir verarbeiten und speichern

  • Beschränkung und Protokollierung des Zugriffs auf den Feature Store, der die privaten Features enthält

  • Plane, private Funktionen so bald wie möglich zu löschen

Es ist am besten, den richtigen Umgang mit personenbezogenen Daten im Voraus zu planen. Bevor die Erhebung von PII-Daten überhaupt in Erwägung gezogen wird, sollte ein klares Verfahren zur Einholung der Zustimmung der Nutzer/innen vorhanden sein: Sie sollten wissen, welche Daten sie bereitstellen und wie sie verwendet werden. Viele Unternehmen halten es für sinnvoll, einen Plan zu erstellen, in dem genau festgehalten wird, welche Daten gesammelt werden, wie sie verarbeitet werden, wo sie gespeichert werden und unter welchen Umständen auf sie zugegriffen werden kann und wie sie gelöscht werden. Dies ermöglicht eine interne (und möglicherweise auch externe) Überprüfung der Verfahren, um die Einhaltung der einschlägigen Gesetze und Vorschriften zu gewährleisten. Die meisten Unternehmen werden ihre Verfahren zur Planung von PII-Daten dokumentieren und ihre Mitarbeiter regelmäßig darin schulen wollen.

Erinnere dich daran, dass private Daten aus organisatorischer Sicht eher eine Belastung als ein Vorteil sind. Deshalb sollten wir vollkommen davon überzeugt sein, dass die Merkmale, die private Daten enthalten, erforderlich sind - dass sie einen ausreichenden Wert schaffen, der die Risiken der Verarbeitung und Speicherung privater Daten aufwiegt. Wie immer können verschiedene Teile nicht-privater Daten zu einem privaten Datenelement kombiniert werden.

Private Daten und Kennzeichnung

Die Kommentierung von personenbezogenen Daten durch den Menschen führt eine Vielzahl rechtlicher und rufschädigender Risiken ein, wenn sie nicht sorgfältig und korrekt gehandhabt wird. Die Details zum richtigen Umgang mit dieser Art von Daten, die in menschlichen Kommentarsystemen verwendet werden, sind sehr kontextspezifisch und würden den Rahmen dieses Buches sprengen. Oft ist es am besten, die PII-Daten so aufzuteilen, dass der Kommentator nur Zugang zu den Nicht-PII-Teilen der Daten hat. Dies hängt von dem jeweiligen Problem ab. Jede Kennzeichnung von PII-Daten sollte mit äußerster Sorgfalt erfolgen und die Projektleitung sollte sich der damit verbundenen Risiken bewusst sein.

Der Einsatz menschlicher Kommentatoren birgt auch das Risiko, dass das Modell unbeabsichtigt die kulturellen Vorurteile der Kommentierungsanweisungen oder des Teams selbst lernt. Diese potenzielle Voreingenommenheit lässt sich am besten durch eine sorgfältige Dokumentation und die Berücksichtigung potenzieller Missverständnisse, eine enge Kommunikation mit dem Kommentatorenteam und die Einstellung eines vielfältigen Kommentatorenteams bekämpfen. Positiv ist, dass ein gut geschultes Kommentierungsteam eine der effektivsten Methoden sein kann, um Daten mit potenziellen Verzerrungen zu filtern, um Verzerrungen zu verstehen und zu beseitigen.

Fairness

Fairness ist ein wichtiges Thema, das unter in Kapitel 6 viel breiter und gründlicher behandelt wird. Es genügt hier zu sagen, dass es wichtig ist, bei der Auswahl von Merkmalen und ihren Bezeichnungen auf Fairness zu achten. Es ist nicht einfach, Merkmale und Merkmalsgruppen auszuwählen, die sicherstellen, dass das resultierende ML-System nur auf faire Art und Weise genutzt werden kann. Es stimmt zwar, dass wir vermeiden müssen, Merkmale und Datensätze auszuwählen, die nicht repräsentativ und voreingenommen sind, aber das allein wird nicht ausreichen, um insgesamt Fairness zu gewährleisten. Für diejenigen, die sich besonders für Fairness interessieren, ist dies ein guter Zeitpunkt, Kapitel 6 zu lesen (oder zu wiederholen).

Fazit

ML-Systeme für die Produktion benötigen Mechanismen, um Trainingsdaten effizient und konsistent zu verwalten. Da Trainingsdaten fast immer aus Merkmalen bestehen, erleichtert ein strukturierter Merkmalsspeicher das Schreiben, Speichern, Lesen und schließlich das Löschen von Merkmalen erheblich. Viele ML-Systeme enthalten auch eine Komponente, bei der die Daten von Menschen kommentiert werden. Menschen, die Daten annotieren, benötigen ihre eigenen Systeme, um schnelle, genaue und verifizierte Annotationen zu ermöglichen, die schließlich in den Feature Store integriert werden müssen.

Wir hoffen, dass wir ein besseres Verständnis für diese Komponenten und die Überlegungen, die bei ihrer Auswahl oder im schlimmsten Fall bei ihrem Bau angestellt werden sollten, vermittelt haben.

1 Unter wissen wir, dass eines der Versprechen des Deep Learning darin besteht, dass es manchmal möglich ist, Rohdaten zum Trainieren eines Modells zu verwenden, ohne bestimmte Merkmale zu identifizieren. Dieses Versprechen gilt teilweise für einige Anwendungsfälle, aber im Moment vor allem für Wahrnehmungsdaten wie Bilder, Video und Audio. In diesen Fällen müssen wir vielleicht keine spezifischen Merkmale aus den zugrundeliegenden Daten extrahieren, auch wenn wir aus den Metadatenmerkmalen noch einen guten Nutzen ziehen können. In anderen Fällen ist die Featurisierung derzeit noch erforderlich. Auch Deep-Learning-Modellierer werden also von einem Verständnis der Merkmale profitieren.

2 Zum Beispiel muss ML-Training auf mobilen Geräten immer noch auf einigen Daten trainieren, hat aber keinen strukturierten, verwalteten Funktionsspeicher, da diese Daten nicht für andere Nutzer auf dem Gerät vermittelt werden müssen.

3 Bucketing ist der Prozess, bei dem kontinuierliche Daten in diskrete Kategorien eingeteilt werden. Transforming Features sind Features, die das Ergebnis einer berechneten Kombination aus einem oder mehreren anderen Features sind. Einfache Beispiele sind die Rückgabe des Wochentags, wenn ein Datums-Feature zur Verfügung gestellt wird, oder die Rückgabe des Ländernamens aus einem Feature, das den Breiten- und Längengrad eines Punktes auf der Erde speichert. Zu den komplexeren Beispielen gehören die Festlegung der Farbbalance eines Bildes oder die Auswahl einer bestimmten Projektion für 3D-Daten. Eines der häufigsten Beispiele ist vielleicht die Umwandlung von 32-Bit-Zahlen (entweder Ganzzahlen oder, schlimmer noch, Gleitkommazahlen) in 8-Bit-Zahlen, um den Platzbedarf und die Rechenressourcen, die für ihre Verarbeitung benötigt werden, deutlich zu reduzieren.

4 Einige Beispiele enthalten Merkmale aus beiden Bereichen. Zum Beispiel sind die Bilder in einem Bild Blobs, auf die man am besten als unstrukturierte Daten zugreift, aber die Metadaten über das Bild (Kamera, die es aufgenommen hat, Datum, Belichtungsinformationen, Standortinformationen) sind strukturiert und können sogar geordnet sein, wenn sie Felder wie date enthalten.

5 Dies ist auch eine Technik, um den Trainingsdatensatz algorithmisch zu erweitern.

6 Organisationen müssen sicherstellen, dass menschliche Etikettierer fair behandelt und angemessen für ihre Arbeit bezahlt werden.

7 In der Branche gibt es viele Unternehmen mit mehreren Metadatensystemen, von denen jedes glaubt, dass es das einzige System ist. Wenn die Bedürfnisse einfach sind und gut verstanden werden, solltest du ein System bevorzugen, aber Maßnahmen ergreifen, um sicherzustellen, dass es das einzige System ist, solange du nicht über die Bedürfnisse hinauswächst.

Get Zuverlässiges maschinelles Lernen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial