Kapitel 4. Datentechnik
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Einführung
In früheren Kapiteln hast du abstrakte Konzepte kennengelernt. Jetzt gehen wir von dieser technischen Einführung zu den Implementierungsdetails und subjektiven Entscheidungen über. Ich zeige dir, wie wir in der Praxis mit der Kunst der Trainingsdaten arbeiten, während wir die Skalierung auf größere Projekte und die Optimierung der Leistung durchgehen.
Die Datenübernahme ist der erste und einer der wichtigsten Schritte. Der erste Schritt zur Datenaufnahme ist die Einrichtung und Nutzung eines Schulungsdatensystems (System of Record, SoR). Ein Beispiel für ein SoR ist eine Schulungsdatenbank.
Warum ist die Datenerfassung schwierig? Es gibt viele Gründe. Zum Beispiel sind Trainingsdaten ein relativ neues Konzept, und es gibt eine Reihe von Herausforderungen bei der Formatierung und Kommunikation. Das Volumen, die Vielfalt und die Geschwindigkeit der Daten variieren und es gibt keine etablierten Normen, so dass es viele Wege gibt, sie zu verarbeiten.
Außerdem gibt es viele Konzepte, wie z.B. die Verwendung einer Trainingsdatenbank, und wer wann auf was zugreifen möchte, die selbst für erfahrene Ingenieure nicht offensichtlich sind. Die Entscheidung über die Aufnahme von Daten bestimmt letztendlich die Abfrage, den Zugriff und den Export.
Dieses Kapitel ist gegliedert in:
Wer die Daten nutzen will und wann er sie nutzen will
Warum die Datenformate und Kommunikationsmethoden wichtig sind; denk an das "Telefonspiel"
Eine Einführung in eine Trainingsdatenbank als dein System der Aufzeichnung
Die technischen Grundlagen des Einstiegs
Speicherung, medienspezifische Anforderungen und Versionierung
Kommerzielle Belange der Formatierung und Kartierung von Daten
Datenzugang, Sicherheit und voretikettierte Daten
Um einen datengesteuerten oder datenzentrierten Ansatz zu erreichen, werden Werkzeuge, Iterationen und Daten benötigt. Je mehr Iterationen und je mehr Daten, desto mehr muss eine großartige Organisation damit umgehen.
Du kannst Daten einlesen, sie erforschen und mit Anmerkungen versehen - in dieser Reihenfolge. Oder du gehst direkt von der Datenerfassung zum Debuggen eines Modells über. Nach dem Streaming zum Training kannst du neue Vorhersagen einlesen, diese debuggen und dann den Annotationsworkflow nutzen. Je mehr du dich auf deine Datenbank stützen kannst, um die schwere Arbeit zu erledigen, desto weniger musst du selbst tun.
Wer will die Daten?
Bevor wir uns mit den Herausforderungen und technischen Besonderheiten befassen, wollen wir zunächst die Ziele und die beteiligten Menschen erläutern und erörtern, wie Data Engineering diese Endnutzer und Systeme bedient. Danach gehe ich auf die konzeptionellen Gründe ein, warum wir eine Ausbildungsdatenbank brauchen. Ich werde die Notwendigkeit einer solchen Datenbank erläutern, indem ich zeige, wie der Standardfall ohne und dann wie er mit einer solchen Datenbank aussieht.
Um die Diskussion zu vereinfachen, können wir sie in Gruppen unterteilen:
Kommentatoren
Datenwissenschaftler/innen
ML-Programme (von Maschine zu Maschine)
Anwendungsingenieure
Andere Interessengruppen
Kommentatoren
Kommentatoren müssen die richtigen Daten zur richtigen Zeit und mit den richtigen Rechten erhalten. Oft geschieht dies auf der Ebene einer einzelnen Datei und wird durch sehr spezifisch ausgerichtete Anfragen gesteuert. Der Schwerpunkt liegt hier auf Berechtigungen und Autorisierung. Außerdem müssen die Daten zum richtigen Zeitpunkt bereitgestellt werden - aber was ist der "richtige Zeitpunkt"? Nun, im Allgemeinen bedeutet es On-Demand- oder Online-Zugriff. Dabei wird die Datei durch einen Softwareprozess, wie z. B. ein Aufgabensystem, identifiziert und mit schnellen Antwortzeiten bereitgestellt.
Datenwissenschaftler/innen
Die Datenwissenschaft befasst sich meist mit Daten auf der Mengenebene. Es wird mehr Wert auf Abfragefunktionen, die Fähigkeit, große Datenmengen zu verarbeiten, und die Formatierung gelegt. Idealerweise gibt es auch die Möglichkeit, bestimmte Stichproben aufzuschlüsseln und die Ergebnisse verschiedener Ansätze sowohl quantitativ als auch qualitativ zu vergleichen.
ML-Programme
ML-Programme folgen einem ähnlichen Weg wie dem der Datenwissenschaft. Zu den Unterschieden gehören die Berechtigungsregelungen (in der Regel haben Programme mehr Zugriff als einzelne Data Scientists) und die Klarheit darüber, was wann aufgedeckt wird (in der Regel eher integrations- und prozessorientiert im Gegensatz zur On-Demand-Analyse). ML-Programme können oft eine softwaredefinierte Integration oder Automatisierung haben.
Anwendungsingenieure
Anwendungsingenieure befassen sich damit, wie die Daten von der Anwendung in die Trainingsdatenbank gelangen und wie die Kommentierung und Überwachung für die Endnutzer eingebettet werden kann. Abfragen pro Sekunde (Durchsatz) und das Datenvolumen sind oft die Hauptanliegen. Manchmal wird fälschlicherweise angenommen, dass es einen linearen Datenfluss von einem "Ingestion"-Team oder der Anwendung zu den Datenwissenschaftlern gibt.
Andere Interessengruppen
Andere Interessengruppen, die ein Interesse an den Schulungsdaten von haben, sind z. B. Sicherheitspersonal, DevMLOps-Experten und Systemtechniker. Diese Gruppen haben oft bereichsübergreifende Anliegen und überschneiden sich mit den Bedürfnissen anderer Nutzer und Systeme. Die Sicherheit kümmert sich zum Beispiel um die bereits erwähnten Endbenutzerrechte. Die Sicherheit sorgt sich auch darum, dass ein einzelner Datenwissenschaftler keine kritische Schwachstelle darstellt, z. B. wenn er den gesamten Datensatz auf seinem Rechner hat oder zu weitreichenden Zugriff auf entfernte Datensätze.
Jetzt, wo du einen Überblick über die beteiligten Gruppen hast, wie reden sie miteinander? Wie arbeiten sie zusammen?
Ein Spiel mit dem Telefon
Telefon ist "ein Spiel, bei dem du dir einen Satz ausdenkst und ihn dann der Person, die neben dir sitzt, ins Ohr flüsterst. Als nächstes muss diese Person das Gehörte in das Ohr der nächsten Person flüstern. So geht es im Kreis weiter, bis die letzte Person den Satz gehört hat. Bei den Nacherzählungen häufen sich in der Regel Fehler, so dass die Aussage, die der letzte Spieler verkündet, deutlich von der des ersten Spielers abweicht, meist mit amüsantem oder humorvollem Effekt."1
Als Analogie kannst du dir suboptimales Data Engineering wie ein Telefonspiel vorstellen, wie in Abbildung 4-1 dargestellt. In jeder Phase häufen sich die Datenfehler an. Und es ist sogar noch schlimmer, als die Grafik zeigt. Das liegt daran, dass Sensoren, Menschen, Modelle, Daten und ML-Systeme alle auf nichtlineare Weise miteinander interagieren.
Abbildung 4-1. Ohne ein Aufzeichnungssystem häufen sich Datenfehler wie bei einem Telefonspiel
Anders als im Spiel sind diese Fehler bei den Trainingsdaten nicht lustig. Datenfehler führen zu Leistungseinbußen, Systemverschlechterungen und Ausfällen, die in der realen Welt zu physischen und finanziellen Schäden führen. In jeder Phase führen unterschiedliche Formate, schlechte oder fehlende Datendefinitionen und Annahmen dazu, dass die Daten missgebildet und verstümmelt werden. Während das eine Tool vielleicht "xyz"-Eigenschaften kennt, weiß das nächste Tool das vielleicht nicht. Und das wiederholt sich. Das nächste Programm exportiert nicht alle Eigenschaften oder ändert sie willkürlich, usw. Egal, wie trivial diese Probleme auf dem Whiteboard erscheinen, in der Praxis werden sie immer ein Problem sein.
Probleme treten vor allem in größeren Kontexten mit mehreren Teams auf und wenn die ganzheitlichen Bedürfnisse aller wichtigen Gruppen nicht berücksichtigt werden. Da es sich um einen neuen Bereich mit neuen Standards handelt, sind selbst scheinbar einfache Dinge nur unzureichend definiert. Mit anderen Worten: Data Engineering ist besonders wichtig für Trainingsdaten. Wenn du ein (neues) Projekt auf der grünen Wiese hast, dann ist jetzt der perfekte Zeitpunkt, um dein Data Engineering zu planen.
Woher weißt du, wann ein Aufzeichnungssystem erforderlich ist? Das wollen wir als Nächstes untersuchen.
Wenn ein Aufzeichnungssystem benötigt wird
Von der Planung eines neuen Projekts bis hin zum Überdenken bestehender Projekte gibt es folgende Anzeichen dafür, dass es Zeit für ein System zur Erfassung von Ausbildungsdaten ist:
Es kommt zu Datenverlusten zwischen den Teams, z. B. weil jedes Team seine eigene Kopie der Daten besitzt.
Teams aggregieren die Daten anderer Teams, nutzen aber nur einen kleinen Teil davon, z.B. wenn eine Abfrage besser wäre.
Unstrukturierte oder halbstrukturierte Formate wie CSV, Strings, JSON usw. werden missbraucht oder übermäßig genutzt, z. B. indem die Ergebnisse in viele CSV-Dateien in einem Bucket gespeichert werden.
Es gibt Fälle, in denen das Format nur der jeweiligen Anwendung bekannt ist, die die Daten erzeugt hat. Es kann zum Beispiel vorkommen, dass unstrukturierte oder schlecht strukturierte Daten im Nachhinein geladen werden, in der Hoffnung, dass das Beste dabei herauskommt.
Es wird zu oft davon ausgegangen, dass jedes System in einer bestimmten, vordefinierten Reihenfolge läuft, anstatt ein kompatibleres Design zu wählen.
Die allgemeine Systemleistung entspricht nicht den Erwartungen oder die Modelle werden nur langsam ausgeliefert oder aktualisiert.
Es kann aber auch sein, dass du einfach nirgendwo ein richtiges Aufzeichnungssystem hast. Wenn du ein System hast, das aber den Zustand der Ausbildungsdaten nicht ganzheitlich abbildet (z. B. wenn du es nur als Beschriftung und nicht als Schwerpunkt des Prozesses betrachtest), dann ist sein Nutzen wahrscheinlich gering. Das liegt daran, dass für Änderungen wahrscheinlich ein unverhältnismäßig hoher Kommunikationsaufwand erforderlich ist (z. B. ist die Änderung des Schemas nicht mit einem schnellen API-Aufruf oder einer UI-Interaktion verbunden). Das bedeutet auch, dass Änderungen, die von den Endnutzern vorgenommen werden sollten, als Änderungen auf technischer Ebene diskutiert werden müssen.
Wenn jedes Team seine eigene Kopie der Daten besitzt, gibt es unnötigen Kommunikations- und Integrationsaufwand und wahrscheinlich auch Datenverlust. Dieses Kopieren ist oft die "Erbsünde", denn sobald mehrere Teams dies tun, ist eine Änderung auf technischer Ebene erforderlich, um das Gesamtsystem zu aktualisieren - was bedeutet, dass die Aktualisierungen nicht fließend sind, was dazu führt, dass die Gesamtleistung des Systems nicht den Erwartungen entspricht.
Die Erwartungen der Nutzer und die Datenformate ändern sich so häufig, dass die Lösung kein allzu starrer, automatischer Prozess sein kann. Denke also nicht an Automatisierung, sondern an die Frage: "Wo liegt der Schwerpunkt der Trainingsdaten?" Er sollte bei den Menschen und einem System zur Aufzeichnung liegen, z. B. einer Schulungsdatenbank, um die besten Ergebnisse zu erzielen .
Ein tolles System planen
Wie vermeidest du also das Spiel mit dem Telefon? Es beginnt mit der Planung. Hier sind ein paar Denkanstöße, und dann gehe ich auf bewährte Methoden für die eigentliche Planung ein.
Die erste besteht darin, eine sinnvolle Arbeitseinheit festzulegen, die für dein Unternehmen relevant ist. Für ein Unternehmen, das medizinische Videos analysiert, könnte das zum Beispiel ein einzelner medizinischer Vorgang sein. Dann überlegst du dir für jeden Vorgang, wie viele Modelle benötigt werden (geh nicht von einem aus!), wie oft sie aktualisiert werden, wie der Datenfluss aussieht usw. Wir werden das im Abschnitt "Gesamtsystemdesign" näher erläutern, aber jetzt möchte ich erst einmal klarstellen, dass die Datenerfassung oft keine einmalige Angelegenheit ist. Es ist etwas, das laufend gewartet und im Laufe der Zeit wahrscheinlich auch erweitert werden muss .
Zweitens musst du dir Gedanken über die Speicherung und den Zugriff auf die Daten machen und ein System für die Aufzeichnung einrichten, z. B. eine Datenbank für Ausbildungsdaten. Es ist zwar möglich, eine eigene Datenbank zu erstellen, aber es ist schwierig, die Bedürfnisse aller Gruppen ganzheitlich zu berücksichtigen. Je mehr eine Ausbildungsdatenbank genutzt wird, desto einfacher ist es, die Komplexität zu bewältigen. Je mehr unabhängige Speicherungen verwendet werden, desto mehr Druck wird auf dein Team ausgeübt, das "Rad" der Datenbank neu zu erfinden.
Es gibt einige Besonderheiten beim Aufbau eines guten Ingestion-Subsystems. In der Regel ist es ideal, wenn diese Sensoren direkt in ein Trainingsdatensystem einfließen. Überlege dir, wie weit die Sensoren, die Vorhersagen, die Rohdaten und deine Trainingsdaten-Tools voneinander entfernt sind.
Produktionsdaten müssen oft von Menschen überprüft, auf einer bestimmten Ebene analysiert und möglicherweise weiter für Verbesserungen "geschürft" werden. Je mehr Vorhersagen, desto mehr Möglichkeiten für weitere Systemkorrekturen. Du musst dir also Fragen stellen wie: Wie gelangen die Produktionsdaten auf sinnvolle Weise in das Trainingsdatensystem? Wie oft werden die Daten während der Werkzeugherstellung dupliziert?
Welche Annahmen treffen wir bezüglich der Unterscheidung zwischen den verschiedenen Verwendungszwecken der Daten? Zum Beispiel ist die Abfrage der Daten innerhalb eines Trainingsdatentools besser skalierbar, als von einem Datenwissenschaftler zu erwarten, dass er alle Daten exportiert und sie anschließend selbst abfragt.
Naive und Trainingsdaten-zentrierte Ansätze
Es gibt zwei Hauptansätze für die Arbeit mit Trainingsdaten. Die eine bezeichne ich als "naiv", die andere konzentriert sich mehr auf die Bedeutung der Daten selbst (datenzentriert).
Naive Ansätze neigen dazu, Trainingsdaten nur als einen Schritt zu sehen, der an eine Reihe von bestehenden Schritten angehängt wird. Bei datenzentrierten Ansätzen steht der Mensch, der die Daten überwacht, im Mittelpunkt des Systems. Viele der in diesem Buch vorgestellten Ansätze passen gut zu den datenzentrierten Ansätzen oder sind direkt mit ihnen gleichzusetzen, so dass sie in gewisser Weise gleichbedeutend mit datenzentriert sind.
Eine Trainingsdatenbank enthält zum Beispiel die Definitionen und/oder die buchstabengetreue Speicherung der Rohdaten, der Anmerkungen, des Schemas und des Mappings für den Zugriff von Maschine zu Maschine.
Natürlich gibt es einige Überschneidungen bei den Ansätzen. Im Allgemeinen gilt: Je kompetenter der naive Ansatz ist, desto mehr ähnelt er einem trainingsdatenzentrierten Ansatz. Es ist zwar auch möglich, mit anderen Ansätzen gute Ergebnisse zu erzielen, aber es ist viel einfacher, mit einem trainingsdatenzentrierten Ansatz durchgängig gute Ergebnisse zu erzielen.
Schauen wir uns zunächst einmal an, wie naive Ansätze normalerweise funktionieren.
Naive Ansätze
Bei einem naiven Ansatz erfassen, speichern und fragen die Sensoren die Daten unabhängig von den Trainingsdaten ab, wie in Abbildung 4-2 dargestellt. Das sieht normalerweise wie ein linearer Prozess aus, mit vorher festgelegten Start- und Endbedingungen.
Abbildung 4-2. Beispiel für einen naiven Data-Engineering-Prozess
Die häufigsten Gründe, warum naive Ansätze verwendet werden:
Das Projekt begann, bevor es für datenzentrierte Ansätze ausgereifte Werkzeuge gab.
Ingenieure wussten nichts von datenzentrierten Ansätzen für die Ausbildung.
Testen und Entwickeln von neuen Systemen.
Alte, historische Daten, ohne die Chance, dass neue Daten hinzukommen (selten).
Fälle, in denen es unpraktisch ist, einen trainingsdatenzentrierten Ansatz zu verwenden (selten).
Naive Ansätze sehen aus wie das bereits erwähnte Telefonspiel. Da jedes Team seine eigene Kopie der Daten hat, häufen sich die Fehler, wenn die Daten weitergegeben werden. Da es entweder kein "System of Record" gibt oder das "System of Record" nicht den kompletten Stand der Trainingsdaten enthält, ist es schwierig, Änderungen auf Benutzerebene vorzunehmen. Je schwieriger es ist, Änderungen auf sichere Weise vorzunehmen, desto langsamer ist die Auslieferung und Iteration und desto schlechter sind die Ergebnisse insgesamt.
Außerdem sind naive Ansätze oft an versteckte oder undefinierte menschliche Prozesse gekoppelt. Irgendein Ingenieur hat zum Beispiel ein Skript auf seinem lokalen Rechner, das einen wichtigen Teil des Gesamtablaufs ausführt, aber dieses Skript ist nicht dokumentiert oder für andere nicht in angemessener Weise zugänglich. Dies geschieht oft, weil man nicht weiß, wie man eine Trainingsdatendatenbank nutzt, und nicht, weil es eine gezielte Aktion ist.
Bei naiven Ansätzen besteht eine größere Chance, dass Daten unnötig dupliziert werden. Das erhöht die Hardwarekosten, z. B. für Speicherung und Netzwerkbandbreite, zusätzlich zu den bereits erwähnten konzeptionellen Engpässen zwischen den Teams. Es kann auch zu Sicherheitsproblemen führen, da die verschiedenen Kopien unterschiedliche Sicherheitseinstellungen haben können. Ein Team, das Daten aggregiert oder korreliert, könnte zum Beispiel die Sicherheit eines Systems umgehen, das in der Verarbeitungskette weiter vorne steht.
Bei naiven Ansätzen wird davon ausgegangen, dass ein menschlicher Administrator die Daten manuell überprüft (in der Regel nur auf Satzebene), so dass nur die Daten importiert werden, die für eine Kommentierung geeignet erscheinen. Mit anderen Worten: Es werden nur Daten importiert, die (in der Regel auf relativ inkonsistente Art und Weise) für die Kommentierung vorgesehen sind. Diese "zufällige Verwaltung vor dem Import" erschwert eine effektive Überwachung der Produktionsdaten und den Einsatz von Explorationsmethoden und führt im Allgemeinen zu Engpässen im Prozess, da der versteckte Kuratierungsprozess manuell und undefiniert ist. Im Grunde genommen verlässt man sich auf implizite, verwaltungsgesteuerte Annahmen, anstatt die Prozesse explizit mit mehreren Beteiligten, einschließlich KMU, zu definieren. Um es klar zu sagen: Es geht nicht um die Überprüfung der Daten, sondern darum, dass ein Prozess, der von einem größeren Team gesteuert wird, besser ist als ein einzelner Administrator, der willkürlich vorgeht.
Bitte betrachte dies konzeptionell und nicht im Sinne einer buchstäblichen Automatisierung. Ein softwaredefinierter Ingestion-Prozess ( ) allein sagt wenig über die allgemeine Gesundheit eines Systems aus, da er nichts über die tatsächlichen architektonischen Probleme bei der Nutzung einer Trainingsdatenbank aussagt.
Trainingsdaten-zentriert (System of Record)
Eine andere Möglichkeit ist die Verwendung eines trainingsdatenzentrierten Ansatzes. Eine Trainingsdatenbank, wie in Abbildung 4-3 dargestellt, ist das Herzstück eines trainingsdatenzentrierten Ansatzes. Sie ist das System, in dem deine Anwendungen gespeichert werden.
Abbildung 4-3. Schulungsdatenbank (System of Record)
Eine Trainingsdatendatenbank enthält die Definitionen und/oder die wörtliche Speicherung der Rohdaten, Anmerkungen, das Schema und die Zuordnung für den Zugriff von Maschine zu Maschine und vieles mehr. Im Idealfall ist sie die vollständige Definition des Systems, d. h. mit der Trainingsdatenbank kannst du den gesamten ML-Prozess ohne zusätzliche Arbeit reproduzieren.
Wenn du eine Trainingsdatenbank als Datensystem verwendest, hast du einen zentralen Ort, an dem alle Teams Trainingsdaten speichern und abrufen können. Je mehr die Datenbank genutzt wird, desto besser sind die Ergebnisse - ähnlich wie die richtige Nutzung einer Datenbank in einer herkömmlichen Anwendung bekanntlich entscheidend ist.
Die häufigsten Gründe für die Verwendung einer Trainingsdatenbank:
Es unterstützt den Wechsel zum datenzentrierten maschinellen Lernen . Das bedeutet, dass man sich auf die Verbesserung der Gesamtleistung konzentriert, indem man die Daten verbessert, anstatt nur den Modellalgorithmus zu verbessern.
Es erleichtert den Abgleich mehrerer ML-Programme, da die Definitionen der Trainingsdaten an einem Ort liegen.
Es unterstützt Endnutzer bei der Überwachung (Kommentierung) von Daten und bei der tieferen Einbettung der Endnutzerüberwachung in Arbeitsabläufe und Anwendungen.
Der Datenzugriff ist jetzt abfragebasiert und erfordert keine Massenvervielfältigung und zusätzliche Aggregationsschritte.
Um beim Thema der Unterscheidung zwischen Trainingsdaten und Data Science zu bleiben: An den Integrationspunkten ist die Linie natürlich am unschärfsten. In der Praxis ist es sinnvoll, ML-Programme aus einem Trainingsdatensystem aufzurufen.
Weitere Gründe für die Verwendung einer Trainingsdatenbank sind die folgenden:
Es entkoppelt die Anforderungen an die visuelle Benutzeroberfläche von der Datenmodellierung (z. B. Abfragemechanismen).
Sie ermöglicht einen schnelleren Zugang zu neuen Tools für die Datenermittlung, die Kennzeichnung und vieles mehr.
Sie ermöglicht benutzerdefinierte Dateitypen, z. B. die Darstellung einer "Interaktion" als eine Reihe von Bildern und Text, was fließende Iterationen und benutzergesteuerte Änderungen unterstützt.
Es vermeidet die Duplizierung von Daten und speichert externe Mapping-Definitionen und Beziehungen an einem Ort.
Das gibt den Teams die Möglichkeit, so schnell wie möglich zu arbeiten, anstatt auf die Fertigstellung einzelner Phasen zu warten.
Es gibt ein paar Probleme mit dem Ansatz einer Trainingsdatenbank:
Um sie zu nutzen, muss man wissen, dass es sie gibt, und sie konzeptionell verstehen.
Das Personal muss die Zeit, die Fähigkeit und die Ressourcen haben, eine Ausbildungsdatenbank zu nutzen.
Gut etablierte Datenzugriffsmuster müssen möglicherweise an den neuen Kontext angepasst werden.
Seine Zuverlässigkeit als Aufzeichnungssystem hat nicht die gleiche Geschichte wie ältere Systeme.
Anstatt zu entscheiden, welche Rohdaten gesendet werden sollen (z. B. von einer Anwendung an die Datenbank), werden idealerweise alle relevanten Daten zuerst an die Datenbank gesendet, bevor die Menschen die zu kennzeichnenden Proben auswählen. So wird sichergestellt, dass es sich wirklich um das System handelt, das die Daten erfasst. Es kann z. B. ein Programm geben, das alle Daten verwendet, auch wenn die Menschen nur einen Teil der Daten prüfen. Wenn dem "What to Label"-Programm alle Daten über die Trainingsdatenbank zur Verfügung stehen, ist das ganz einfach. Der einfachste Weg, sich daran zu erinnern, ist, sich die Trainingsdatenbank als das Zentrum des Prozesses vorzustellen.
Die Trainingsdatendatenbank übernimmt die Verwaltung der Verweise auf die Rohdaten oder enthält sogar deren Speicherung in Bytes. Das bedeutet, dass die Daten direkt an das Trainingsdaten-Tool gesendet werden. In der tatsächlichen Umsetzung kann es eine Reihe von Verarbeitungsschritten geben, aber die Idee ist, dass der endgültige Ruheort der Daten, die Quelle der Wahrheit, in der Trainingsdatenbank liegt.
Eine Trainingsdatendatenbank ist die vollständige Definition des Systems. Das bedeutet, dass du mit der Trainingsdatendatenbank alle ML-Anwendungen für Endbenutzer, einschließlich ML-Prozesse, ohne zusätzlichen Aufwand erstellen, verwalten und reproduzieren kannst. Das geht über den MLOps-Ansatz hinaus, der sich oft mehr auf Automatisierung, Modellierung und Reproduzierbarkeit konzentriert, und zwar ausschließlich auf der ML-Seite. Du kannst dir MLOps als einen Teilaspekt eines strategischeren, auf Trainingsdaten ausgerichteten Ansatzes vorstellen.
Eine Trainingsdatenbank berücksichtigt vom ersten Tag an mehrere Nutzer und plant entsprechend. Eine Anwendung zur Unterstützung der Datenexploration kann zum Beispiel festlegen, dass Indizes für die Datenerkennung automatisch beim Ingest erstellt werden. Wenn sie Anmerkungen speichert, kann sie gleichzeitig auch Indizes für die Entdeckung, das Streaming, die Sicherheit usw. erstellen.
Ein eng verwandtes Thema ist der Export der Daten in andere Tools. Vielleicht willst du einen Prozess zur Untersuchung der Daten durchführen und sie dann für einen Sicherheitsprozess an ein anderes Tool senden, z. B. um persönliche Daten zu verwischen. Dann musst du die Daten an ein anderes Unternehmen weiterleiten, um sie zu kommentieren, und die Ergebnisse von dort zurückbekommen, um sie in deine Modelle zu integrieren usw. Nehmen wir an, dass es bei jedem dieser Schritte ein Zuordnungsproblem (Definitionen) gibt. Werkzeug A hat ein anderes Format als Werkzeug B. Diese Art der Datenübertragung erfordert oft um Größenordnungen mehr Rechenressourcen als bei der Verwendung anderer gängiger Systeme. In gewisser Weise ist jede Übertragung wie eine Mini-Datenbankmigration, weil alle Datenkomponenten den Konvertierungsprozess durchlaufen müssen. Das wird auch im Abschnitt "Umfang" behandelt.
Generell gilt: Je enger die Verbindung zwischen den Sensoren und den Trainingsdaten-Tools ist, desto größer ist das Potenzial für alle Endnutzer und Tools, gemeinsam effektiv zu sein. Jeder weitere Schritt, der zwischen den Sensoren und den Tools eingefügt wird, ist praktisch garantiert ein Engpass. Die Daten können immer noch gleichzeitig in einem anderen Dienst gesichert werden, aber in der Regel bedeutet das, dass die Daten vom ersten Tag an in den Trainingsdaten-Tools organisiert werden.
Die ersten Schritte
Angenommen, du hast dich für einen datenbasierten Ansatz entschieden. Wie fängst du eigentlich an?
Die ersten Schritte sind:
Definitionen der Trainingsdatenbank einrichten
Dateneingabe einrichten
Betrachten wir zuerst die Definitionen. In einer Ausbildungsdatenbank befinden sich alle Daten an einem Ort, einschließlich der Zuordnungsdefinitionen zu anderen Systemen. Das bedeutet, dass es nur einen einzigen Ort gibt, an dem das Datensystem und die zugehörigen Zuordnungsdefinitionen zu Modulen innerhalb und außerhalb des Ausbildungsdatensystems zu finden sind. Dadurch werden Zuordnungsfehler, der Bedarf an Datenübertragungen und Datenduplikate reduziert.
Bevor wir mit dem eigentlichen Ingesting von Daten beginnen, gibt es unter noch ein paar weitere Begriffe, die wir zunächst kennenlernen müssen:
Speicherung von Rohdaten
Rohmedien BLOB-spezifische Bedenken
Formatierung und Kartierung
Datenzugang
Sicherheitsbedenken
Beginnen wir mit der Speicherung von Rohdaten.
Speicherung von Rohdaten
Das Ziel ist es, die Rohdaten, wie Bilder, Videos und Texte, in eine brauchbare Form für die Trainingsdatenarbeit zu bringen. Je nach Art des Mediums kann dies einfacher oder schwieriger sein. Bei kleinen Mengen von Textdaten ist die Aufgabe relativ einfach, bei großen Mengen von Videos oder sogar spezielleren Daten wie Genomikdaten wird sie zu einer zentralen Herausforderung.
Es ist üblich, Rohdaten in einer Bucket-Abstraktion zu speichern. Das kann in der Cloud sein oder mit Software wie MinIO. Manche Leute denken bei diesen Cloud-Buckets an "wegwerfen und vergessen", aber es gibt tatsächlich eine Menge Optionen zur Leistungsoptimierung. Bei den Trainingsdaten kommt es auf die Wahl der Speicherung an. Es gibt einige wichtige Überlegungen, die du bei der Auswahl deiner Speicherung beachten solltest:
- Klasse der Speicherung
- Es gibt größere Unterschiede zwischen den Speicherungen, als es zunächst den Anschein hat. Die Kompromisse betreffen Dinge wie Zugriffszeit, Redundanz, geografische Verfügbarkeit usw. Die Preisunterschiede zwischen den Tiers liegen in der Größenordnung von Größenordnungen. Das wichtigste Tool, das du kennen solltest, sind die Lebenszyklusregeln, z. B. bei Amazon S3, mit denen du mit ein paar Klicks Richtlinien festlegen kannst, um alte Dateien automatisch in billigere Speicheroptionen zu verschieben, wenn sie altern. Detaillierte Beispiele für bewährte Methoden findest du auf der Website von Diffgram.
- Geolocation (auch Zone, Region genannt)
- Speichern Sie die Daten auf der einen Seite des Atlantiks und lassen Sie die Kommentatoren auf der anderen Seite auf sie zugreifen? Es lohnt sich zu überlegen, wo die eigentliche Kommentierung stattfinden soll und ob es Möglichkeiten gibt, die Daten näher daran zu speichern.
- Unterstützung durch den Anbieter
- Nicht alle Annotationstools haben das gleiche Maß an Unterstützung für alle großen Anbieter. Bedenke, dass du jedes dieser Angebote in der Regel manuell integrieren kannst, was aber mehr Aufwand erfordert als bei Tools mit nativer Integration.
Die Unterstützung für den Zugriff auf Daten von diesen Speicheranbietern unterscheidet sich von dem Tool, das bei diesem Anbieter läuft. Einige Tools können den Zugriff von allen drei Anbietern unterstützen, aber als Service läuft das Tool selbst nur auf einer einzigen Cloud. Wenn du ein System hast, das du auf deiner eigenen Cloud installierst, unterstützt das Tool normalerweise alle drei.
Du kannst dich zum Beispiel dafür entscheiden, das System auf Azure zu installieren. Du kannst dann Daten von Azure in das Tool ziehen, was zu einer besseren Leistung führt. Das hindert dich aber nicht daran, bei Bedarf Daten von Amazon und Google zu beziehen.
Nach Referenz oder nach Wert
Speichern per Referenz bedeutet, dass du nur kleine Informationen wie Strings oder IDs speicherst, die es dir ermöglichen, die Rohbytes auf einem vorhandenen Quellsystem zu identifizieren und darauf zuzugreifen. Nach Wert bedeutet, dass du die Bytes in Buchstaben kopierst. Sobald sie auf das Zielsystem kopiert wurden, besteht keine Abhängigkeit mehr vom Quellsystem.
Wenn du deine Ordnerstruktur beibehalten willst, unterstützen einige Tools das Verweisen auf die Dateien, anstatt sie tatsächlich zu übertragen. Das hat den Vorteil, dass weniger Daten übertragen werden müssen. Der Nachteil ist, dass es nun zu fehlerhaften Verknüpfungen kommen kann. Außerdem kann die Trennung der Interessen ein Problem darstellen, z. B. wenn ein anderer Prozess eine Datei verändert, auf die das Anmerkungsprogramm zugreifen soll.
Auch wenn du einen Pass-by-Reference-Ansatz für die Rohdaten verwendest, ist es wichtig, dass das System der Wahrheit die Trainingsdatenbank ist. Zum Beispiel können die Daten in der Datenbank in Sets organisiert sein, die in der Bucket-Organisation nicht enthalten sind. Darüber hinaus stellt der Bucket nur die Rohdaten dar, während die Datenbank die Anmerkungen und andere zugehörige Definitionen enthält.
Der Einfachheit halber ist es am besten, sich die Trainingsdatenbank als eine Abstraktion vorzustellen, auch wenn die Rohdaten außerhalb der physischen Hardware der Datenbank gespeichert sind, wie in Abbildung 4-4 gezeigt.
Abbildung 4-4. Trainingsdatenbank mit Verweisen auf extern gespeicherte Rohdaten
Dedizierte Schulungsdaten-Tools von der Stange auf deiner eigenen Hardware
Gehen wir davon aus, dass dein Tool vertrauenswürdig ist (vielleicht konntest du den Quellcode einsehen). In diesem Zusammenhang vertrauen wir darauf, dass das Schulungsdaten-Tool den Prozess der signierten URL verwaltet und sich um das Identitäts- und Zugriffsmanagement (IAM) kümmert. Damit ist die einzige wirkliche Sorge die Frage, welchen Bucket es verwendet - und das ist in der Regel eine einmalige Angelegenheit, weil das Tool das IAM verwaltet. Für fortgeschrittene Fälle kann das Tool noch mit einem Single Sign-On (SSO) oder einem komplexeren IAM-System verbunden werden.
Hinweis: Das Tool muss nicht auf der Hardware laufen. Die nächsthöhere Stufe ist das Vertrauen in das Tool für die Trainingsdaten und in den Dienstleister, der die Daten hostet/verarbeitet. Dies ist zwar eine Option, aber du solltest bedenken, dass du damit die geringste Kontrolle hast.
Speicherung von Daten: Wo bleiben die Daten?
Im Allgemeinen werden bei jeder Art von Tooling eine Art Daten erzeugt, die zu den "ursprünglichen" Daten hinzugefügt werden. Die BLOB-Daten werden in der Regel per Verweis oder durch physisches Verschieben der Daten gespeichert.
Das heißt, wenn ich Daten in Bucket A habe und sie mit einem Tool verarbeite, müssen sich entweder zusätzliche Daten in Bucket A befinden, oder ich brauche einen neuen Bucket B, der von dem Tool verwendet werden kann. Das gilt für Diffgram, SageMaker und, soweit ich weiß, für die meisten wichtigen Tools.
Je nach deinen Kosten- und Leistungszielen kann dies ein entscheidender Faktor sein oder nur eine geringe Rolle spielen. In der Praxis musst du für die meisten Anwendungsfälle nur zwei einfache Konzepte im Auge behalten:
Erwarte, dass zusätzliche Daten generiert werden.
Wisse, wo die Daten gespeichert werden, aber denke nicht zu viel darüber nach.
Genauso wenig hinterfragen wir, wie viel Speicherung z.B. ein PostgreSQL Write-Ahead Log (WAL) erzeugt. Ich persönlich bin der Meinung, dass es am besten ist, dem Trainingsdaten-Tool in dieser Hinsicht zu vertrauen. Wenn es ein Problem gibt, solltest du es im Einflussbereich des Trainingsdatentools angehen.
Externe Referenzverbindung
Eine nützliche Abstraktion ist eine Verbindung vom Trainingsdaten-Tooling zu einer bestehenden externen Referenz, z. B. einem Cloud-Bucket. Es gibt verschiedene Meinungen darüber, wie dies zu bewerkstelligen ist, und die Einzelheiten variieren je nach Hardware und Cloud-Provider.
Für den technisch nicht versierten Benutzer bedeutet dies im Wesentlichen, dass er sich bei einem Bucket "anmeldet". Mit anderen Worten: Ich erstelle einen neuen Bucket A und erhalte eine Benutzer-ID und ein Passwort (Client-ID/Client-Secret) aus dem IAM-System. Ich übergebe diese Anmeldedaten an das Trainingsdaten-Tool, das sie sicher speichert. Bei Bedarf verwendet das Trainingsdaten-Tool dann diese Anmeldedaten, um mit dem Bucket zu interagieren.
Rohmedien (BLOB)-Typ spezifisch
Ein BLOB ist ein Binary Large Object. Es ist die Rohdatenform von Medien und wird auch als "Objekt" bezeichnet. Die Technologie, die Rohdaten-BLOBs speichert, wird "Bucket" oder "Objektspeicher" genannt. Je nach Medientyp gibt es bestimmte Probleme. Jeder Medientyp hat weitaus mehr Probleme, als hier aufgelistet werden können. Du musst jeden Typ für deine Bedürfnisse untersuchen. Eine Trainingsdatenbank hilft dir dabei, BLOBs so zu formatieren, dass sie für verschiedene Endnutzer, wie z. B. Kommentatoren und Datenwissenschaftler, nützlich sind. Hier sind einige der häufigsten Überlegungen aufgeführt, die du beachten solltest.
Video
Es ist üblich, Videodateien in kleinere Clips aufzuteilen, um sie leichter kommentieren und bearbeiten zu können. Ein 10-minütiges Video kann zum Beispiel in 60-Sekunden-Clips aufgeteilt werden.
Eine Möglichkeit, den Verarbeitungsaufwand zu reduzieren, ist das Sampling von Bildern. Das geht, indem du die Bildrate reduzierst und Bilder extrahierst. Zum Beispiel kannst du eine Datei von 30 Bildern pro Sekunde (FPS) auf 5 oder 10 pro Sekunde umwandeln. Ein Nachteil ist, dass der Verlust von zu vielen Einzelbildern das Kommentieren erschweren kann (z. B. kann ein Schlüsselmoment im Video abgeschnitten werden) oder du kannst andere wichtige Videofunktionen wie Interpolation oder Tracking (die auf der Annahme einer bestimmten Bildrate basieren) nicht mehr nutzen. In der Regel ist es am besten, das Video als abspielbares Video beizubehalten und alle benötigten Bilder zu extrahieren. Das verbessert die Erfahrung des Endnutzers bei der Kommentierung und maximiert die Kommentarfunktion.
Ereignisorientierte Analysen benötigen den genauen Frame, wenn etwas passiert, der verloren geht, wenn viele Frames entfernt werden. Wenn alle Frames intakt sind, können die Algorithmen zum Auffinden interessanter Highlights die gesamten Daten auswerten. Dies führt dazu, dass die Kommentatoren mehr "interessante" Dinge sehen und somit qualitativ hochwertigere Daten erhalten. Objektverfolgung und Interpolation machen diesen Punkt noch deutlicher, da ein Kommentator nur eine Handvoll Bilder beschriften muss und durch diese Algorithmen oft viele Bilder "umsonst" zurückbekommt. In der Praxis sind nahegelegene Bilder zwar in der Regel ähnlich, aber die zusätzlichen Daten sind trotzdem hilfreich.
Eine Ausnahme hiervon ist, dass ein Video mit sehr hohen FPS (z. B. 240-480+) manchmal auf 120 FPS oder ähnliche Werte heruntergerechnet werden muss. Nur weil viele Bilder für die Kommentierung zur Verfügung stehen, können wir trotzdem entscheiden, die Modelle nur auf abgeschlossenen Videos, abgeschlossenen Bildern usw. zu trainieren. Wenn du die Bilder herunterrechnen musst, verwende den globalen Referenzrahmen, um die Zuordnung zwischen dem heruntergerechneten Bild und dem Originalbild beizubehalten.
Text
Du musst deinen gewünschten Tokenizer auswählen oder bestätigen, dass der vom System verwendete Tokenizer deinen Anforderungen entspricht. Der Tokenizer unterteilt Wörter, z. B. anhand von Leerzeichen oder mit Hilfe komplexerer Algorithmen, in kleinere Bestandteile. Es gibt viele Open-Source-Tokenizer und eine genauere Beschreibung würde den Rahmen dieses Buches sprengen. Möglicherweise brauchst du auch ein Verfahren, um BLOB-Dateien (z. B. .txt) in Zeichenketten umzuwandeln oder umgekehrt.
Geospatial
GeoTiff und Cloud-Optimized GeoTIFF (COG) sind Standardformate in der Geodatenanalyse. Nicht alle Schulungsdaten-Tools unterstützen beide Formate; wenn sie jedoch Unterstützung bieten, scheint der Trend zu COG zu gehen. Sei dir darüber im Klaren, dass eine Änderung der Projektionsabbildung erforderlich sein kann, um die Ebenen zu standardisieren.
Formatierung und Kartierung
Rohmedien sind ein Teil des Puzzles. Anmerkungen und Vorhersagen sind ein weiterer großer Teil. Denke eher an die Einrichtung von Datendefinitionen als an einen einmaligen Import. Je besser deine Definitionen sind, desto einfacher können die Daten zwischen ML-Anwendungen fließen und desto mehr Endnutzer können die Daten ohne Technik aktualisieren.
Benutzerdefinierte Typen (zusammengesetzte Dateien)
In der realen Welt gibt es oft mehr als eine Datei. Ein Führerschein hat zum Beispiel eine Vorder- und eine Rückseite. Wir können uns vorstellen, einen neuen benutzerdefinierten Typ "Führerschein" zu erstellen, der dann zwei untergeordnete Dateien unterstützt, von denen jede ein Bild ist. Oder wir können uns eine "Rich Text"-Konversation vorstellen, die mehrere Textdateien, Bilder usw. enthält.
Definieren von DataMaps
Eine DataMap ermöglicht das Laden und Entladen von Definitionen zwischen Anwendungen. Sie kann z. B. Daten in ein Schulungssystem oder einen "What to Label"-Analysator laden. Wenn diese Definitionen gut definiert sind, können sie von den Endnutzern problemlos integriert werden und machen Änderungen auf technischer Ebene überflüssig. Mit anderen Worten: Der Aufruf einer Anwendung wird von der Datendefinition selbst entkoppelt. Beispiele dafür sind die Deklaration eines Mappings zwischen räumlichen Orten, die als x_min, y_min, x_max, y_max und top_left, bottom_right formatiert sind, oder das Mapping von Ganzzahlergebnissen aus einem Modell zurück in ein Schema.
Assistenten einnehmen
Eine der größten Lücken im Tooling ist oft die Frage: "Wie schwer ist es, meine Daten im System einzurichten und zu pflegen?" Welche Art von Medien kann es einlesen? Wie schnell kann es sie einlesen?
Das ist ein Problem, das noch nicht so gut definiert ist wie bei anderen Formen von Software. Kennst du das, wenn du einen Link zu einem Dokument bekommst und es zum ersten Mal lädst? Oder ein großes Dokument auf deinem Computer zu laden beginnt?
In letzter Zeit sind neue Technologien wie "Importassistenten" - schrittweise Formulare - aufgetaucht, die einen Teil des Datenimports erleichtern. Ich gehe zwar davon aus, dass diese Prozesse im Laufe der Zeit noch einfacher werden, aber je mehr du über die Aspekte hinter den Kulissen weißt, desto mehr verstehst du, wie diese neuen wunderbaren Assistenten tatsächlich funktionieren. Das fing ursprünglich mit Dateibrowsern für cloudbasierte Systeme an und hat sich zu ausgewachsenen Mapping-Engines weiterentwickelt, ähnlich wie die Smart-Switch-Apps für Telefone, mit denen du alle deine Daten von Android auf das iPhone oder umgekehrt übertragen kannst.
Im Großen und Ganzen funktioniert es so, dass eine Mapping-Engine (z.B. Teil des Ingest-Assistenten) dich schrittweise durch den Prozess des Mappings jedes Feldes von einer Datenquelle zur anderen führt. Mapping-Assistenten bieten einen enormen Nutzen. Sie ersparen dir eine technisch aufwendige Integration. Sie bieten in der Regel mehr Validierungen und Überprüfungen, um sicherzustellen, dass die Daten deinen Erwartungen entsprechen (stell dir vor, du siehst eine E-Mail-Vorschau in Google Mail, bevor du dich verpflichtest, die E-Mail zu öffnen). Und das Beste ist, dass die Mappings, sobald sie eingerichtet sind, ganz einfach aus einer Liste ausgetauscht werden können, ohne dass der Kontext gewechselt werden muss!
Die Auswirkungen dieser Entwicklung sind kaum zu überschätzen. Früher hast du vielleicht gezögert, eine neue Modellarchitektur, einen kommerziellen Vorhersagedienst usw. auszuprobieren, weil du nicht wusstest, wie du die Daten dorthin und wieder zurück bekommst. Das nimmt diesen Druck drastisch ab.
Was sind die Grenzen von Assistenten? Nun, erstens werden sie von einigen Tools noch nicht unterstützt und sind daher möglicherweise einfach nicht verfügbar. Ein weiteres Problem ist, dass sie technische Einschränkungen mit sich bringen können, die bei reinen API-Aufrufen oder SDK-Integrationen nicht vorhanden sind.
Organisieren von Daten und nützliche Speicherung
Eine der ersten Herausforderungen ist oft die Organisation der Daten, die du bereits erfasst hast (oder noch erfassen wirst). Ein Grund dafür, dass dies schwieriger ist, als es auf den ersten Blick scheint, ist, dass diese Rohdatensätze oft dezentral gespeichert werden.
Zum Zeitpunkt der Erstellung dieses Artikels sind die Browser für die Speicherung von Daten in der Cloud im Allgemeinen weniger ausgereift als die Browser für lokale Dateien. Selbst die einfachsten Vorgänge, z. B. wenn ich an einem Bildschirm sitze und Dateien ziehe, können eine neue Herausforderung darstellen.
Hier einige praktische Vorschläge:
Versuche, die Daten lieber früher als später in dein Annotationstool zu übertragen. Wenn ich zum Beispiel neue Daten erhalte, kann ich die Datenreferenz zum gleichen Zeitpunkt in das Annotationstool schreiben, zu dem ich auch in einen allgemeinen Objektspeicher schreibe. Auf diese Weise kann ich die Daten bis zu einem gewissen Grad "automatisch" organisieren und/oder die Teammitglieder leichter zur Mithilfe bei den Organisationsaufgaben heranziehen.
Erwäge den Einsatz von Tools, die dabei helfen, die "interessantesten" Daten zu finden. Dieser Bereich ist noch im Entstehen begriffen, aber es ist bereits klar, dass diese Methoden zwar nicht unproblematisch sind, aber ihre Vorteile haben und immer besser zu werden scheinen.
Verwende Tags. So einfach es auch klingt, es hilft, Datensätze mit organisatorischen Informationen auf Unternehmensebene zu versehen. Zum Beispiel kann der Datensatz "Zugsensor 12" mit dem Tag "Kunde ABC" versehen werden. Tags können die Belange der Datenwissenschaft überschneiden und sowohl die Ziele der Geschäftskontrolle/Organisation als auch die der Datenwissenschaft ermöglichen.
Fernspeicherung
Die Daten werden in der Regel relativ zum Endnutzer gespeichert. Der Grund dafür sind der Umfang der Daten, die Sicherheitsanforderungen und die Automatisierungsanforderungen (z. B. die Verbindung aus einem integrierten Programm, die praktische Durchführung der Modellinferenz, die Aggregation der Daten von Knotenpunkten/Systemen). Bei der Arbeit in Teams ist die Person, die die Trainingsdaten verwaltet, möglicherweise nicht die Person, die die Daten gesammelt hat (man denke an Anwendungsfälle in der Medizin, beim Militär, auf dem Bau usw.).
Dies gilt auch für Lösungen ohne externe Internetverbindung, die auch als "Air-Gapped"-Lösungen auf geheimer Ebene bezeichnet werden. In diesen Fällen ist es immer noch wahrscheinlich, dass sich das physische System, in dem die Daten gespeichert sind, an einem anderen Ort befindet als der Endnutzer, selbst wenn sie nur einen Meter voneinander entfernt sitzen.
Da die Daten an einem anderen Ort liegen, brauchen wir jetzt eine Möglichkeit, auf sie zuzugreifen. Zumindest muss derjenige, der die Daten mit Anmerkungen versieht, darauf zugreifen können, und höchstwahrscheinlich wird auch eine Art der Datenvorbereitung darauf angewiesen sein.
Versionierung
Die Versionskontrolle ist wichtig für die Reproduzierbarkeit. Unter wird der Versionierung manchmal etwas zu viel Aufmerksamkeit geschenkt. In der Praxis kommt man in den meisten Fällen sehr weit, wenn man sich an die übergeordneten Konzepte hält, Snapshots verwendet und ein gutes System von Datensätzen definiert.
Es gibt drei primäre Ebenen der Datenversionierung: pro Instanz (Anmerkung), pro Datei und Export. Ihr Verhältnis zueinander ist in Abbildung 4-5 dargestellt.
Abbildung 4-5. Versionierungsvergleich auf hoher Ebene
Als Nächstes stelle ich dir jedes dieser Elemente auf hohem Niveau vor.
Verlauf pro Instanz
In der Standardeinstellung werden Instanzen nicht hart gelöscht. Wenn du eine bestehende Instanz bearbeitest, markiert Diffgram sie als weiches Löschen und erstellt eine neue Instanz, die an ihre Stelle tritt, wie in Abbildung 4-6 gezeigt. Du könntest dies z. B. für Deep-Dive-Annotationen oder Modellprüfungen verwenden. Es wird davon ausgegangen, dass die soft_deleted Instanzen nicht zurückgegeben werden, wenn die Standardinstanzliste für eine Datei abgerufen wird.
Abbildung 4-6. Links, Verlauf pro Instanz in der Benutzeroberfläche; rechts, ein einzelner differenzieller Vergleich zwischen derselben Instanz zu verschiedenen Zeitpunkten
Pro Datei und pro Set
Jeder Aufgabensatz kann so eingestellt werden, dass automatisch Kopien pro Datei auf jeder Stufe der Verarbeitungspipeline erstellt werden. Dadurch werden automatisch mehrere Versionen auf Dateiebene beibehalten, die für das Aufgabenschema relevant sind.
Du kannst Daten auch programmatisch und manuell organisieren und bei Bedarf in Sets kopieren. Du kannst Daten nach Tags filtern, z. B. nach einem bestimmten Machine Learning-Lauf. Dann kannst du Dateien und Sets vergleichen, um zu sehen, was sich geändert hat.
Füge Dateien zu mehreren Sets hinzu, wenn du möchtest, dass die Dateien immer auf der neuesten Version sind. Das bedeutet, dass du mehrere Sets mit unterschiedlichen Kriterien erstellen kannst und sofort die neueste Version hast, wenn du Anmerkungen machst. Entscheidend ist, dass es sich um eine lebende Version handelt, so dass es einfach ist, immer auf der "neuesten" Version zu sein.
Du kannst diese Bausteine nutzen, um auf der Administratorebene flexibel Versionen von laufenden Arbeiten zu verwalten.
Schnappschüsse pro Export
Mit Snapshots pro Export wird jeder Export auf automatisch in einer statischen Datei zwischengespeichert. Das bedeutet, dass du zu jedem Zeitpunkt und für jede Abfrage einen Snapshot machen kannst und einen wiederholbaren Weg hast, um auf genau diesen Datensatz zuzugreifen. Dies kann mit Webhooks, SDKs oder Benutzerskripten kombiniert werden, um automatisch Exporte zu erzeugen. Diese können bei Bedarf und jederzeit erstellt werden. Du kannst zum Beispiel Snapshots pro Export verwenden, um sicherzustellen, dass ein Modell auf genau dieselben Daten zugreift. Die Kopfzeile eines Exports ist in Abbildung 4-7 als Beispiel dargestellt.
Abbildung 4-7. Beispiel für eine Export-UI-Listenansicht
Als Nächstes befassen wir uns in Data Access ausführlicher mit den Kompromissen beim Exportieren und Zugreifen auf Muster.
Datenzugang
Bisher haben wir uns mit den allgemeinen Architekturkonzepten von beschäftigt, z. B. mit der Verwendung einer Trainingsdatenbank, um ein Telefonspiel zu vermeiden. Wir haben uns mit den Grundlagen des Einstiegs, der Speicherung von Medien, Mapping-Konzepten, BLOBs und anderen Formaten beschäftigt. Jetzt gehen wir auf die Anmerkungen selbst ein. Der Vorteil eines trainingsdatenzentrierten Ansatzes ist, dass bewährte Methoden wie Snapshots und Streaming eingebaut sind.
Streaming ist ein anderes Konzept als die Abfrage, aber in praktischen Anwendungen geht es Hand in Hand. Du kannst zum Beispiel eine Abfrage ausführen, die 1/100 der Daten eines Exports auf Dateiebene ergibt, und dann diesen Teil der Daten direkt im Code streamen.
Es gibt einige wichtige Konzepte, die du beachten solltest:
Dateibasierte Exporte
Streaming
Daten abfragen
Speicherung, Ingestion, Export und Zugriff auseinanderhalten
Eine Möglichkeit, sich das vorzustellen, ist, dass die Art und Weise, wie die Daten in einer Datenbank genutzt werden, sich oft von der Art und Weise unterscheidet, wie sie gespeichert und abgefragt werden. Bei Trainingsdaten ist es ähnlich. Es gibt Prozesse, um Daten zu erfassen, verschiedene Prozesse, um sie zu speichern, und wieder andere, um sie abzufragen:
Die Rohdatenspeicherung bezieht sich auf die wörtliche Speicherung der BLOBs und nicht auf die Anmerkungen, von denen angenommen wird, dass sie in einer separaten Datenbank gespeichert werden.
Beim Ingestion geht es um den Durchsatz, die Architektur, die Formate und das Mapping der Daten. Oft geht es dabei um die Verbindung zwischen anderen Anwendungen und dem Ausbildungsdatensystem.
Der Export bezieht sich in diesem Zusammenhang in der Regel auf einen einmaligen dateibasierten Export aus dem Ausbildungsdatensystem.
Beim Datenzugriff geht es um das Abfragen, Anzeigen und Herunterladen von BLOBs und Anmerkungen.
Moderne Trainingsdatensysteme speichern Annotationen in einer Datenbank (nicht in einem JSON-Dump) und bieten abstrakte Abfragefunktionen für diese Annotationen.
Dateibasierte Exporte
Wie bei der Versionierung erwähnt, ist ein dateibasierter Export eine Momentaufnahme der Daten. Er wird in der Regel nur nach sehr groben Kriterien erstellt, z. B. nach dem Namen eines Datensatzes. Dateibasierte Exporte sind ziemlich einfach, deshalb werde ich mich nicht lange mit ihnen beschäftigen. Ein Vergleich der Kompromisse zwischen dateibasierten Exporten und Streaming wird im nächsten Abschnitt behandelt.
Streaming-Daten
Klassischerweise wurden Anmerkungen immer in eine statische Datei exportiert, z. B. eine JSON-Datei. Statt jeden Export einmalig zu erstellen, streamst du die Daten jetzt direkt in den Speicher. Das wirft die Frage auf: "Wie bekomme ich meine Daten aus dem System heraus?" Alle Systeme bieten irgendeine Form des Exports an, aber du musst dir überlegen, welche Art. Ist es ein statischer, einmaliger Export? Geht es direkt in den TensorFlow- oder PyTorch-Speicher?
Streaming-Vorteile
Du kannst nur das laden, was du brauchst, was ein kleiner Teil einer JSON-Datei sein kann. Im großen Maßstab kann es unpraktisch sein, alle Daten in eine JSON-Datei zu laden, daher kann dies ein großer Vorteil sein.
Es funktioniert besser für große Teams. Du musst nicht auf statische Dateien warten, sondern kannst programmieren und mit dem erwarteten Datensatz arbeiten, bevor die Kommentierung beginnt, oder sogar während die Kommentierung läuft.
Es ist speichereffizienter - da es sich um Streaming handelt, musst du nicht den gesamten Datensatz in den Speicher laden. Das ist vor allem für verteilte Trainings geeignet und wenn das Marschieren einer JSON-Datei auf einem lokalen Rechner unpraktisch wäre.
Es erspart ein "doppeltes Mapping", z. B. das Mapping auf ein anderes Format, das dann wiederum auf Tensoren abgebildet wird. In manchen Fällen kann das Parsen einer JSON-Datei sogar mehr Aufwand bedeuten, als nur ein paar Tensoren zu aktualisieren.
Es bietet mehr Flexibilität; das Format kann von den Endnutzern festgelegt und neu definiert werden.
Nachteile des Streaming
Die Spezifikationen sind unter im Code definiert. Wenn sich der Datensatz ändert, kann die Reproduzierbarkeit beeinträchtigt werden, wenn keine zusätzlichen Maßnahmen ergriffen werden.
Sie erfordert eine Netzwerkverbindung.
Einige ältere Ausbildungssysteme/AutoML-Anbieter unterstützen das direkte Laden aus dem Speicher möglicherweise nicht und benötigen statische Dateien.
Eine Sache, die du dabei im Hinterkopf behalten solltest, ist, dass wir nicht wirklich statisch Ordner und Dateien auswählen wollen. Wir wollen vielmehr einen Prozess einrichten, in dem wir neue Daten ereignisgesteuert streamen. Dazu müssen wir uns das Ganze eher wie eine Pipeline vorstellen, als dass wir uns auf die Mechanismen konzentrieren, mit denen wir einen einzelnen bekannten Satz abrufen.
Beispiel: Holen und streamen
In diesem Beispiel holen wir uns einen Datensatz und streamen ihn mit dem Diffgram SDK:
pipinstalldiffgram==0.15.0
fromdiffgramimportProjectproject=Project(project_string_id='your_project')default_dataset=project.directory.get(name='Default')# Let's see how many images we got('Number of items in dataset:{}'.format(len(default_dataset)))# Let's stream just the 8th element of the dataset('8th element:{}'.format(default_dataset[7]))pytorch_ready_dataset=default_dataset.to_pytorch()
Abfragen Einleitung
Jede Anwendung hat ihre eigene Abfragesprache . Diese Sprache hat oft eine spezielle Struktur, die auf den Kontext der Trainingsdaten zugeschnitten ist. Sie kann auch abstrakte Integrationen mit anderen Abfragekonstrukten unterstützen.
Um dies zu verdeutlichen, beginnen wir mit diesem einfachen Beispiel, um alle Dateien mit mehr als 3 Autos und mindestens einem Fußgänger zu erhalten (vorausgesetzt, diese Labels existieren in deinem Projekt):
dataset = project.dataset.get('my dataset')
sliced_dataset = dataset.slice('labels.cars > 3 and labels.pedestrian >= 1')
Integration in das Ökosystem
Es gibt viele Anwendungen, mit denen man Modelle trainieren und bedienen kann. Zum Zeitpunkt der Erstellung dieses Artikels gibt es viele Hunderte von Tools, die in diese Kategorie fallen. Wie bereits erwähnt, kannst du eine Zuordnung von Definitionen für Formate, Auslöser, Datensatznamen und mehr in deinen Trainingsdaten-Tools einrichten. Wir werden diese Konzepte in späteren Kapiteln noch genauer behandeln.
Sicherheit
Die Sicherheit von Trainingsdaten ist von entscheidender Bedeutung. Oft werden Rohdaten aus Sicherheitsgründen mit größerer Sorgfalt behandelt als Daten in anderer Form. Zum Beispiel werden die Rohdaten von kritischen Infrastrukturen, Führerscheinen, militärischen Zielen usw. sehr sorgfältig gespeichert und übertragen.
Sicherheit ist ein breites Thema, das gründlich recherchiert und separat von diesem Buch behandelt werden muss. Wir werden jedoch einige Punkte ansprechen, die bei der Arbeit mit Trainingsdaten unbedingt zu verstehen sind. Ich möchte speziell auf die häufigsten Sicherheitsprobleme im Zusammenhang mit Data Engineering für Trainingsdaten aufmerksam machen:
Zugriffskontrolle
Signierte URLs
Persönlich identifizierbare Informationen
Zugriffskontrolle
Es gibt ein paar wichtige Fragen zur Zugriffskontrolle, auf die wir uns zu Beginn konzentrieren können. Welches System verarbeitet die Daten? Wie sieht das Identitäts- und Zugriffsmanagement (IAM) für die Verarbeitung und Speicherung auf Systemebene aus? Welche Bedenken gibt es hinsichtlich des Benutzerzugriffs?
Identität und Berechtigung
Systeme auf Produktionsebene verwenden oft OpenID Connect (OIDC). Dies kann mit rollenbasierter Zugriffskontrolle (RBAC) und attributbasierter Zugriffskontrolle (ABAC) gekoppelt werden.
Speziell bei den Trainingsdaten gibt es oft die größten Spannungen beim Zugriff auf die Rohdaten. In diesem Zusammenhang kann das Problem normalerweise entweder auf Datei- oder auf Set-Ebene gelöst werden. Auf der Ebene der einzelnen Dateien muss der Zugriff durch eine Policy Engine kontrolliert werden, die die dreifache Anzahl der {user, file, policy} kennt. Dies kann auf der Ebene der einzelnen Dateien sehr komplex sein. Normalerweise ist es einfacher, dies auf der Ebene der einzelnen Datensätze zu erreichen. Auf der Set-Ebene (Datensatz) wird dies mit {user, set, policy} erreicht.
Beispiel für die Einstellung von Berechtigungen
In diesem Codebeispiel erstellen wir ein neues Dataset und eine neue Sicherheitsberaterrolle und fügen das abstrakte Objektpaar {view, dataset} für diese Rolle hinzu:
restricted_ds1=project.directory.new(name='Hidden Dataset 1',access_type='restricted')advisor_role=project.roles.new(name='security_advisor')advisor_role.add_permission(perm='dataset_view',object_type='WorkingDir')
Dann ordnen wir den Nutzer (das Mitglied) dem eingeschränkten Datensatz zu:
member_to_grant=project.get_member(='security_advisor_1@example.com')advisor_role.assign_to_member_in_object(member_id=member.get('member_id'),object_id=restricted_ds1.id,object_type='WorkingDir')
Alternativ kann dies auch mit einer externen Policy Engine geschehen.
Signierte URLs
Signierte URLs sind ein technischer Mechanismus, um einen sicheren Zugang zu Ressourcen, meist Raw Media BLOBs, zu ermöglichen. Eine signierte URL ist das Ergebnis eines Sicherheitsprozesses, der Identitäts- und Autorisierungsschritte umfasst. Eine signierte URL kann man sich am ehesten als ein Einmalpasswort für eine Ressource vorstellen, mit dem häufig hinzugefügten Vorbehalt, dass es nach einer bestimmten Zeit abläuft. Diese Zeitspanne beträgt manchmal nur ein paar Sekunden, in der Regel weniger als eine Woche und in seltenen Fällen ist die signierte URL "praktisch unbegrenzt" gültig, z. B. für mehrere Jahre. Signierte URLs gibt es nicht nur bei Schulungsdaten, und es lohnt sich, sich näher damit zu befassen, denn sie scheinen einfach zu sein, bergen aber viele Fallstricke. Wir erwähnen signierte URLs hier nur im Zusammenhang mit Schulungsdaten.
Da signierte URLs vergänglich sind, ist es keine gute Idee, signierte URLs nur einmalig zu übertragen. Das würde das System der Trainingsdaten praktisch lahmlegen, wenn die URL abläuft. Es ist auch weniger sicher, da die Zeit entweder zu kurz ist, um nützlich zu sein, oder zu lang, um sicher zu sein. Stattdessen ist es besser, sie in dein Identitäts- und Autorisierungssystem zu integrieren. Auf diese Weise können signierte URLs bei Bedarf von bestimmten {User, Object/Resource} Paaren erstellt werden. Dieser bestimmte Nutzer kann dann eine URL mit kurzer Gültigkeitsdauer erhalten.
Mit anderen Worten: Du kannst einen Dienst außerhalb des Ausbildungsdatensystems nutzen, um die signierten URLs zu generieren, solange der Dienst direkt in das Ausbildungsdatensystem integriert ist. Auch hier ist es wichtig, die eigentliche Organisationslogik und die Definitionen so weit wie möglich in das Ausbildungsdatensystem zu verlagern. Single Sign-On (SSO) und die Integration von Identitäts- und Zugriffsmanagement sind in der Regel datenbank- und anwendungsübergreifend, daher ist dies ein weiterer Aspekt.
Zusätzlich zu dem, was wir in diesem Abschnitt behandeln, bieten Trainingsdatensysteme derzeit neue Möglichkeiten, Daten zu sichern. Dazu gehört z. B. die direkte Übertragung von Ausbildungsdaten an ML-Programme, so dass eine einzelne Person keinen extrem offenen Zugang mehr haben muss. Ich empfehle dir, die aktuelle Dokumentation deines Anbieters von Ausbildungsdatensystemen zu lesen, um über die neuesten bewährten Methoden auf dem Laufenden zu bleiben.
Cloud-Verbindungen und signierte URLs
Derjenige, der die Daten überwachen soll, muss sie einsehen können. Das ist das Minimum an Zugriff und ist im Grunde unvermeidlich. Die vorbereitenden Systeme, wie z. B. das System, das personenbezogene Daten (PII) entfernt, Vorschaubilder, Voretikettierungen usw. erstellt, müssen sie ebenfalls sehen. Außerdem ist es für die praktische Kommunikation zwischen den Systemen oft einfacher, nur eine URL/einen Dateipfad zu übermitteln und das System die Daten dann direkt herunterladen zu lassen. Das gilt vor allem deshalb, weil viele Endnutzersysteme viel langsamere Upload- als Download-Raten haben. Stell dir zum Beispiel vor, du sagst: "Nutze das 48 GB große Video auf diesem Cloud-Pfad" (KBs an Daten), während du versuchst, 48 GB von deinem Rechner zu Hause zu übertragen.
Es gibt viele Möglichkeiten, dies zu erreichen, aber signierte URLs - ein Passwortsystem für jede Ressource - sind derzeit die am häufigsten akzeptierte Methode. Sie können "hinter den Kulissen" stattfinden, werden aber in der Regel immer in irgendeiner Form verwendet.
Aus guten und schlechten Gründen kann dies manchmal ein kontroverses Thema sein. Ich werde hier einige Kompromisse aufzeigen, damit du entscheiden kannst, was für dein System relevant ist.
Zusammenfassend lässt sich sagen, dass Ausbildungsdaten einige ungewöhnliche Sicherheitsprobleme bei der Datenverarbeitung mit sich bringen, die beachtet werden müssen:
Menschen sehen die "rohen" Daten auf eine Weise, die in anderen Systemen unüblich ist.
Admins brauchen in der Regel ziemlich weitreichende Rechte, um mit den Daten zu arbeiten, wie es in klassischen Systemen nicht üblich ist.
Aufgrund der zunehmenden Verbreitung neuer Medientypen, Formate und Methoden der Datenübertragung gibt es Probleme mit der Größe und Verarbeitung von Trainingsdaten. Obwohl die Bedenken denen ähneln, die wir von den klassischen Systemen kennen, gibt es weniger etablierte Normen dafür, was angemessen ist.
Persönlich identifizierbare Informationen
Personenbezogene Daten müssen mit Sorgfalt behandelt werden, wenn du mit Ausbildungsdaten arbeitest. Die drei gängigsten Möglichkeiten, mit personenbezogenen Daten umzugehen, bestehen darin, eine PII-konforme Verarbeitungskette zu schaffen, sie ganz zu vermeiden oder sie zu entfernen.
PII-konforme Datenkette
Obwohl PII Komplikationen in unsere Arbeitsabläufe bringen, ist ihre Anwesenheit manchmal notwendig. Vielleicht sind die PII erwünscht oder nützlich für die Ausbildung. Dies erfordert eine PII-konforme Datenkette, PII-Schulungen für das Personal und eine entsprechende Kennzeichnung der Elemente, die PII enthalten. Das gilt auch, wenn der Datensatz PII enthält und die PII nicht geändert werden sollen. Die wichtigsten Faktoren, auf die du achten musst, sind:
OAuth oder ähnliche Identifizierungsmethoden, wie OIDC
Vor-Ort- oder Cloud-orientierte Installationen
Übergabe per Referenz und kein Senden von Daten
PII-Vermeidung
Es ist vielleicht möglich, den Umgang mit personenbezogenen Daten zu vermeiden. Vielleicht können deine Kunden oder Nutzer ihre eigenen personenbezogenen Daten selbst einsehen. Das erfordert zwar immer noch ein gewisses Maß an PII-Compliance, aber weniger, als wenn du oder dein Team die Daten direkt ansieht.
PII-Entfernung
Möglicherweise kannst du Daten entfernen oder zusammenfassen, um PII zu vermeiden. Zum Beispiel kann die PII in Metadaten (wie DICOM) enthalten sein. Du möchtest diese Informationen entweder vollständig löschen oder nur eine einzelne ID behalten, die auf eine separate Datenbank mit den erforderlichen Metadaten verweist. Oder die PII sind in den Daten selbst enthalten; in diesem Fall gelten andere Maßnahmen. In diesem Fall kommen andere Maßnahmen zur Anwendung. Bei Bildern kann dies zum Beispiel bedeuten, dass Gesichter und Identifikationsmerkmale wie Hausnummern unkenntlich gemacht werden. Dies hängt stark von den örtlichen Gesetzen und dem Anwendungsfall ab.
Pre-Labeling
Die Überwachung von Modellvorhersagen ist weit verbreitet. Sie wird eingesetzt, um die Qualität des Systems zu messen, die Trainingsdaten (Annotation) zu verbessern und auf Fehler hinzuweisen. Auf die Vor- und Nachteile von Pre-Labeling gehe ich in späteren Kapiteln ein; jetzt gebe ich erst einmal eine kurze Einführung in die technischen Besonderheiten. Der Grundgedanke beim Pre-Labeling ist, dass wir die Ergebnisse eines bereits laufenden Modells für andere Prozesse nutzen, z. B. für die Überprüfung durch Menschen.
Daten aktualisieren
Es mag seltsam erscheinen, mit dem Aktualisierungsfall zu beginnen, aber da die Datensätze häufig von ML-Programmen aktualisiert werden, ist es gut, einen Plan zu haben, wie die Aktualisierungen funktionieren, bevor Modelle und ML-Programme laufen.
Wenn sich die Daten bereits im System befinden, musst du dich auf die Datei-ID oder eine andere Form der Identifizierung wie den Dateinamen beziehen, um sie mit der vorhandenen Datei abzugleichen. Bei großen Mengen an Bildern, häufigen Aktualisierungen, Videos usw. ist es viel schneller, einen bereits bekannten Datensatz zu aktualisieren, als die Rohdaten neu zu importieren und zu verarbeiten.
Es ist am besten, wenn die Definitionen zwischen ML-Programmen und Trainingsdaten im Trainingsdatenprogramm festgelegt werden.
Wenn das nicht möglich ist, solltest du zumindest die ID der Trainingsdatendatei zusammen mit den Daten angeben, auf denen das Modell trainiert wird. Auf diese Weise kannst du die Datei später leichter mit den neuen Ergebnissen aktualisieren. Diese ID ist zuverlässiger als ein Dateiname, denn Dateinamen sind oft nur innerhalb eines Verzeichnisses eindeutig.
Fehler bei der Voretikettierung
Manche Formate, wie z.B. Videosequenzen, sind etwas schwierig zu verstehen. Das gilt besonders, wenn du ein komplexes Schema hast. In diesen Fällen schlage ich vor, dass du sicherstellst, dass der Prozess mit einem Bild und/oder mit einer einzigen Standardsequenz funktioniert, bevor du es mit mehreren Sequenzen versuchst. SDK-Funktionen können bei der Vorbeschriftung helfen.
Einige Systeme verwenden relative, andere absolute Koordinaten. Es ist einfach, zwischen diesen Koordinaten zu wechseln, solange die Höhe und Breite des Bildes bekannt sind. Eine Transformation von absoluten zu relativen Koordinaten ist zum Beispiel definiert als "x / Bildbreite" und "y / Bildhöhe". Ein Beispiel: Ein Punkt x,y (120, 90) mit einer Bildbreite/-höhe (1280, 720) hätte einen relativen Wert von 120/1280 und 90/720 oder (0,09375, 0,125).
Wenn du die Rohdaten zum ersten Mal importierst, ist es möglich, die vorhandenen Instanzen (Anmerkungen) gleichzeitig mit den Rohdaten anzuhängen. Wenn es nicht möglich ist, die Instanzen anzuhängen, behandelst du sie als Aktualisierung.
Eine häufige Frage lautet: "Sollten alle maschinellen Vorhersagen an die Trainingsdatenbank gesendet werden?" Die Antwort ist ja, solange es machbar ist. Rauschen ist Rauschen. Es macht keinen Sinn, bekannte verrauschte Vorhersagen zu senden. Viele Vorhersagemethoden generieren mehrere Vorhersagen mit einem bestimmten Schwellenwert für die Einbeziehung. In der Regel musst du auch hier den Mechanismus anwenden, den du zum Filtern dieser Daten benutzt. Du könntest zum Beispiel nur die Vorhersage mit dem höchsten "Vertrauen" nehmen. Zu diesem Zweck kann es in manchen Fällen sehr nützlich sein, diesen "Konfidenz"-Wert oder andere "Entropie"-Werte mit einzubeziehen, um die Trainingsdaten besser zu filtern.
Datenvorbereitung für die Etikettierung
Nachdem wir nun einige der abstrakten Konzepte behandelt haben, wollen wir uns nun einigen konkreten Beispielen für ausgewählte Medienformate zuwenden. Wir können in diesem Buch nicht alle möglichen Formate und Typen abdecken, daher musst du die Unterlagen für dein spezielles Ausbildungsdatensystem, deine Medientypen und deine Bedürfnisse recherchieren.
Abbildung 4-8 zeigt ein Beispiel für einen Pre-Labeling-Prozess mit drei Schritten. Es ist wichtig, dass du deine Daten zunächst dem Format deines Datensystems zuordnest. Wenn du deine Daten verarbeitet hast, musst du sicherstellen, dass alles korrekt ist.
Abbildung 4-8. Beispiel für ein Blockdiagramm
In der Regel gibt es einige wichtige Formatierungsinformationen zu beachten, z. B. dass ein Bild viele Instanzen haben kann oder dass ein Video viele Frames haben kann und jedes Frame viele Instanzen haben kann, wie in Abbildung 4-9 gezeigt.
Abbildung 4-9. Visuelle Übersicht über die Beziehung zwischen Rohmedien und Instanzen
Fassen wir all dies in einem praktischen Codebeispiel zusammen, das die Daten für einen Bildbegrenzungsrahmen nachahmt.
Hier ist ein Beispiel für Python-Code:
defmock_box(sequence_number:int=None,name:str=None):return{"name":name,"number":sequence_number,"type":"box","x_max":random.randint(500,800),"x_min":random.randint(400,499),"y_max":random.randint(500,800),"y_min":random.randint(400,499)}
Dies ist eine "Instanz". Wenn du also zum Beispiel die Funktion mock_box() ausführst, erhältst du folgendes Ergebnis:
instance={"name":"Example","number":0,"type":"box","x_max":500,"x_min":400,"y_max":500,"y_min":400}
Wir können Instanzen in einer Liste kombinieren, um mehrere Anmerkungen zum selben Frame darzustellen:
instance={}instance_list=[instance,instance,instance]
Zusammenfassung
Ein gutes Data-Engineering für Trainingsdaten erfordert ein zentrales Aufzeichnungssystem, Überlegungen zu Rohdaten, Ingestion- und Abfrage-Setups, die Definition von Zugriffsmethoden, die angemessene Sicherung von Daten und die Einrichtung von Pre-Labeling-Integrationen (z. B. Modellvorhersagen). Es gibt einige wichtige Punkte aus diesem Kapitel, die es zu beachten gilt:
Ein Aufzeichnungssystem ist entscheidend, um eine hohe Leistung zu erzielen und zu vermeiden, dass sich Datenfehler wie bei einem Telefonspiel anhäufen.
Eine Ausbildungsdatenbank ist ein Beispiel für ein praktisches Aufzeichnungssystem.
Ideal ist es, wenn du im Voraus ein System zur Erfassung von Ausbildungsdaten planst, aber du kannst es auch zu einem bestehenden System hinzufügen.
Bei der Speicherung von Rohdaten sind u.a. die Speicherklasse, die Geolokalisierung, die Kosten, die Unterstützung durch den Anbieter und die Speicherung nach Verweis statt nach Wert zu berücksichtigen.
Verschiedene Arten von Rohdaten wie Bilder, Videos, 3D-, Text-, medizinische und Geodaten haben besondere Anforderungen an die Aufnahme.
Abfragen und Streaming bieten einen flexibleren Datenzugriff als Dateiexporte.
Sicherheitsaspekte wie Zugriffskontrolle, signierte URLs und personenbezogene Daten müssen berücksichtigt werden.
Das Pre-Labeling lädt idealerweise die Modellvorhersagen in das System der Aufzeichnungen.
Die Zuordnung von Formaten, die Bearbeitung von Aktualisierungen und die Überprüfung der Genauigkeit sind wichtige Bestandteile des Pre-Labeling-Workflows.
Die bewährten Methoden in diesem Kapitel helfen dir dabei, die Ergebnisse deiner Trainingsdaten und die Nutzung der Daten durch das maschinelle Lernmodell zu verbessern .
1 Von Google Answers
Get Trainingsdaten für 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.
