Ein falsch beschriftetes Trainingsbeispiel lehrt das Modell eine falsche Zuordnung. Cleanlab Datalab hilft Ihnen, solche Risiken in real-world data zu finden, bevor sie die Modellqualität beeinträchtigen.
Das Datalab-Objekt prüft bereits trainierte Klassifikationsmodelle und deren Vorhersagen oder gelernte Repräsentationen. Eine Out-of-sample-Vorhersage ist eine Modellvorhersage für ein Beispiel, das beim Training des Modells nicht verwendet wurde.
Die Prüfung liefert Hinweise, keine bestätigten Fehler. Ein verdächtiges Beispiel kann falsch beschriftet sein, aber auch eine seltene, gültige Beobachtung darstellen.
Gerade bei machine learning können uneinheitliche Labels dazu führen, dass ein Modell falsche Muster lernt. Eine gezielte Datenprüfung zeigt, welche Beispiele genaueres Hinsehen verdienen.
Wichtigste Erkenntnisse
- Fehlerhafte Trainingsdaten können die Vorhersagen eines Klassifikationsmodells schwächen.
- Das Audit nutzt passende Modellinformationen und vorhandene Daten.
- Die Ergebnisse sind Prüfhinweise, keine automatisch bestätigten Fehler.
- Seltene, gültige Beispiele können ebenfalls auffällig erscheinen.
- Vor einer Änderung müssen Sie jedes verdächtige Beispiel im Originalkontext prüfen.
Welche Problemarten lassen sich mit einer solchen Prüfung erkennen, und welche Modellinformationen braucht sie dafür?
Wie Cleanlab Datalab Probleme im Dataset erkennt
Datalab kann mehrere Arten von Datenproblemen gleichzeitig markieren, wenn die nötigen Modellinformationen vorliegen. So erkennen Sie verschiedene issues in einem Dataset, statt nur nach fehlerhaften Labels zu suchen.
Ein markiertes Beispiel ist ein Prüfhinweis, kein bestätigter Fehler. Ein einzelnes Beispiel kann bei mehreren Issue-Typen auffällig sein, etwa wegen eines ungewöhnlichen Inhalts und eines fraglichen Labels.
Behandeln Sie jeden Treffer als Hinweis zur Prüfung. Auch ein seltener, gültiger Datenpunkt kann auffällig wirken.
Welche Issue-Typen kann Datalab markieren?
Zu den erkennbaren Problemen zählen label issues, Ausreißer, Near-Duplicates, fehlende Werte und Klassenungleichgewicht. Datalab kann auch non-IID-Muster markieren, bei denen die Daten nicht unabhängig und gleich verteilt wirken.
Auch Gruppen mit schwacher Modellleistung können auffallen. Die Prüfung betrachtet dabei nicht nur eine einzelne Vorhersage, sondern sucht nach Mustern in den Beispielen und ihren Modellinformationen.
| Issue-Typ | Signal | Erster Prüfschritt |
|---|---|---|
| label issue | Vorhergesagte Klasse widerspricht dem gegebenen Label | Annotation gegen Originalbeispiel prüfen |
| outlier | Beispiel weicht von den übrigen ab | Gültigkeit und Repräsentativität prüfen |
| Near-Duplicate | Beispiele liegen in der Feature-Repräsentation ungewöhnlich nah | Duplikate und Split-Zugehörigkeit prüfen |
| non-IID | Reihenfolge hängt auffällig mit Ähnlichkeiten zusammen | Sortierung und mögliche Verteilungsverschiebung untersuchen |
Was bedeuten Report und Quality Scores?
Der Report fasst die gefundenen Issue-Typen zusammen und zeigt Scores pro Beispiel. Ein quality score beschreibt, wie zuverlässig ein Beispiel für einen bestimmten Problemtyp wirkt.
Confident learning ist ein Ansatz, der Modellwahrscheinlichkeiten und vorhandene Labels nutzt, um mögliche Labelprobleme zu schätzen. Die Schätzung ist keine sichere Wahrheit, denn auch Modellunsicherheit kann zu auffälligen Werten führen.
Die predicted probabilities helfen, mögliche Abweichungen zwischen einer vorhergesagten Klasse und dem vorhandenen Label einzuschätzen. Welche Daten und Modellinformationen dafür bereitstehen müssen, ist der nächste praktische Punkt.
Welche Daten und Modellinformationen brauchen Sie?
Datalab braucht verlässliche Labels und passende Modellausgaben, damit die Prüfung sinnvoll ist. Vorher sollten Sie prüfen, ob Beispiele, Labels und Features in derselben Reihenfolge stehen.
Für ein überwachtes Klassifikations-Dataset benötigen Sie Labels und Modellwahrscheinlichkeiten für jedes Beispiel. Numerische Features oder Embeddings helfen bei weiteren Prüfungen, etwa bei Ausreißern oder ähnlichen Beispielen.
Sie können Daten als Python-Dictionary, Hugging Face Dataset oder pandas DataFrame übergeben. Die Label-Spalte muss benannt sein, damit Datalab die Zielwerte eindeutig zuordnen kann.
Prüfen Sie vor dem Start diese vier Punkte:
- Labels und Beispiele haben dieselbe Reihenfolge.
- Die Label-Spalte ist benannt.
- Vorhergesagte Wahrscheinlichkeiten enthalten für jedes Beispiel eine Zeile.
- Feature-Vektoren stimmen in Anzahl und Reihenfolge mit den Beispielen überein.
Ein DataFrame mit kategorialen Spalten kann bei der Initialisierung Probleme verursachen. Nutzen Sie dann ein anderes Format oder wandeln Sie die Spalten passend um.
Die Wahrscheinlichkeiten erfordern besondere Sorgfalt bei ihrer Berechnung. Sie müssen für jedes Trainingsbeispiel aus einem Modell stammen, das dieses Beispiel nicht gesehen hat.
Wie erzeugen Sie verlässliche predicted probabilities?
Verwenden Sie für jedes Trainingsbeispiel eine Vorhersage aus einem Modell, das dieses Beispiel nicht gesehen hat. Solche out-of-sample predicted class probabilities eignen sich besser für die Prüfung möglicher Labelprobleme.
Vorhersagen aus den eigenen Trainingsbeispielen können zu sicher ausfallen und die Fehlererkennung schwächen. Das Modell hat diese Beispiele bereits genutzt und kann ihre Labels daher scheinbar gut wiedergeben.
Warum Out-of-sample-Vorhersagen wichtig sind
Mit Cross-Validation teilen Sie die Trainingsdaten in mehrere Teile. Das Modell lernt jeweils aus einigen Teilen und sagt für den ausgelassenen Teil die Klassenwahrscheinlichkeiten voraus.
In scikit-learn kann cross_val_predict diese Vorhersagen berechnen. Eine mögliche Konfiguration nutzt LogisticRegression und cv=5. Das ist ein Beispiel aus dem Tutorial, keine zwingende Vorgabe für jedes Dataset.
Wahrscheinlichkeiten aus einem Modell, das genau dieselben Beispiele schon zum Training genutzt hat, sind für diesen Zweck nicht gleichwertig. Die Überanpassung kann echte Unsicherheit verdecken und verdächtige Labels weniger klar erscheinen lassen.
Klassenreihenfolge und Wahrscheinlichkeitsmatrix prüfen
Die Wahrscheinlichkeitsmatrix braucht für jedes Beispiel eine Zeile und für jede Klasse eine Spalte. Jede Zelle gibt die Wahrscheinlichkeit für die jeweilige Klasse an.
Ordnen Sie die Spalten lexikografisch nach Klassennamen. Stimmen Klassenreihenfolge und Labels nicht überein, kann Datalab Wahrscheinlichkeiten der falschen Klasse zuordnen.
Prüfen Sie auch, ob die Matrix zu den tatsächlichen Klassen und Beispielen passt. Mit korrekt vorbereiteten Wahrscheinlichkeiten können Sie den Audit-Aufruf starten.
Wie starten Sie ein Audit mit Cleanlab Python?
Sind Paket, Dataset und Vorhersagen bereit, reichen wenige Python-Aufrufe für ein erstes Audit. Ein Datalab-Objekt kann mehrere Prüfungen für dasselbe Dataset ausführen.
Installieren Sie die zusätzlichen Datalab-Abhängigkeiten mit pip install „cleanlab[datalab]“. Bereiten Sie danach eine benannte Label-Spalte sowie passende Wahrscheinlichkeiten und bei Bedarf Features vor.
Gehen Sie in dieser Reihenfolge vor:
- Paket samt Datalab-Abhängigkeiten installieren.
- Dataset und Label-Spalte vorbereiten.
- Wahrscheinlichkeiten und bei Bedarf Features übergeben.
- Audit starten und Report aufrufen.
Ein knappes Beispiel sieht so aus: from cleanlab import Datalab; lab = Datalab(data=data, label_name=“labels“); lab.find_issues(pred_probs=pred_probs, features=features); lab.report().
Die Eingabe data enthält das Dataset. pred_probs bezeichnet die Wahrscheinlichkeiten, während features die numerischen Repräsentationen enthalten, sofern Sie diese nutzen.
Instanziieren Sie für ein Dataset nur ein Datalab-Objekt, statt für jeden Issue-Typ ein neues anzulegen. Der zusammengefasste Report führt Sie zu den möglicherweise falschen Labels, die Sie genauer prüfen sollten.
Wie finden und prüfen Sie label issues?
get_issues(„label“) gibt markierte Label-Kandidaten samt Scores und Label-Vergleich zurück. So finden Sie gezielt jene Beispiele, bei denen das vorhandene Label und die Modellausgabe nicht gut zusammenpassen.
Niedrigere label_score-Werte markieren innerhalb dieses Issue-Typs problematischere Beispiele. Sie können die Ergebnisse nach label_score sortieren und Fälle mit niedrigen Werten zuerst prüfen.
Verdächtige Labels nach Score sortieren
Die Tabelle aus get_issues(„label“) enthält die boolesche Markierung is_label_issue. Sie zeigt, ob Datalab ein Beispiel als möglichen Label-Kandidaten eingestuft hat.
Sortieren Sie die markierten Zeilen nach label_score. Nutzen Sie die Reihenfolge, um Ihre Prüfung zu priorisieren, aber nicht, um Labels automatisch zu ändern.
Gegebenes und vorhergesagtes Label gemeinsam kontrollieren
Die Felder given_label und predicted_label zeigen das gegebene und das vorhergesagte Label. Ein großer Unterschied ist ein Grund, den Inhalt und die Annotierungsregeln zu kontrollieren.
Im Banking-Textbeispiel markierte Datalab 10 potenzielle Label-Fehler unter 1.000 geprüften Anfragen. Bei Beispiel 485 lautete das gegebene Label 17, während das vorhergesagte Label 34 war.
Die Werte 17 und 34 sind Klassen-IDs, keine Beschreibungen des Anfrageinhalts. Sie müssen den Anfrage-Text lesen, um zu prüfen, welche Klasse passt.
Ein stark abweichendes predicted label ist ein Anlass zur Prüfung, aber kein Beleg für eine falsche Annotation. Nach der menschlichen Kontrolle lohnt sich auch ein Blick auf weitere auffällige Beispiele.
Wie bewerten Sie Ausreißer, Duplikate und Klassenungleichgewicht?
Der Report weist im numerischen Demo-Dataset mehrere Problemarten getrennt aus. Bei 132 Beispielen markiert er unterschiedliche Auffälligkeiten mit eigenen Scores.
Die Zahlen beschreiben Treffer im jeweiligen Issue-Typ, nicht bestätigte Fehler. Der Report markiert 17 label issues, 6 Ausreißer, 4 Near-Duplicates und 3 Beispiele der unterrepräsentierten Klasse.
| Issue-Typ | Markierte Beispiele im Demo-Dataset | Issue-Score |
|---|---|---|
| label | 17 | 0,8561 |
| Ausreißer | 6 | 0,3558 |
| Near-Duplicate | 4 | 0,6160 |
| Klassenungleichgewicht | 3 | 0,0227 |
Niedrigere Scores weisen auf schwerwiegendere Probleme innerhalb desselben Issue-Typs hin. Vergleichen Sie Scores nicht zwischen verschiedenen Typen, denn sie bewerten unterschiedliche Sachverhalte.
Mit get_issues(„outlier“) erhalten Sie markierte Beispiele und ihre Scores. get_issues(„near_duplicate“) kann zudem die Indizes der zugehörigen ähnlichen Beispiele anzeigen.
Ein Near-Duplicate-Paar kann über Trainings- und Testdaten verteilt sein, selbst wenn Text oder Features gleich sind. Diese Verteilung kann die Bewertung verzerren.
Das Markieren allein bereinigt keine Daten. Sie müssen die auffälligen Fälle im Kontext prüfen und passende Schritte wählen.
Wie nutzen Sie Cleanlab für Textklassifikation und LLM-Daten?
Textklassifikation kann numerische Embeddings als Features nutzen, obwohl die Originalbeispiele natürliche Sprache enthalten. So lassen sich Kundenanfragen mit denselben Prüfschritten untersuchen.
Datalab erhält Labels, Wahrscheinlichkeiten und numerische Features, nicht eine unmittelbare Deutung des rohen Texts. Der Klassifikator arbeitet auf den Text-Embeddings.
Cleanlab text classification mit Text-Embeddings
Das Textbeispiel nutzt 1.000 Kundenservice-Anfragen aus Banking77. Sentence Transformers erstellt Embeddings mit google/electra-small-discriminator.
Eine Logistic Regression verarbeitet diese Embeddings und liefert out-of-sample-Wahrscheinlichkeiten. Datalab nutzt anschließend die numerischen Features, Labels und Wahrscheinlichkeiten für das Audit.
Die Einbettungen bilden den Text als Zahlenvektoren ab. Sie ersetzen nicht die menschliche Prüfung des Anfrageinhalts, wenn ein Label verdächtig wirkt.
Cleanlab LLM: Klassifikationsdaten statt generativer Ausgaben
Cleanlab LLM-Trainingsdaten passen zu diesem Ablauf, wenn sie ein geeignetes überwachtes Klassifikationsproblem bilden. Dazu gehören passende Labels und Modelloutputs für die Beispiele.
Generative Modellausgaben lassen sich nicht einfach direkt mit diesem Klassifikationsaudit prüfen. Eine Klassifikationsaufgabe über Textdaten unterscheidet sich von der freien Textproduktion eines LLM.
Dass verschiedene Eingabemodalitäten unterstützt werden, bedeutet nicht, dass jede Aufgabenart unterstützt wird. Von diesem Beispiel führen die wichtigen Entscheidungen vor jeder Datenänderung weiter.
Wie gehen Sie mit den gefundenen Problemen um?
Datalab hilft Ihnen, Kandidaten zu priorisieren; die endgültige Entscheidung hängt vom Beispiel und Einsatzzweck ab. Prüfen Sie den Originalkontext, bevor Sie Daten ändern.
Ändern Sie nur bestätigte Label-Fehler. Ein ungewöhnliches Beispiel oder eine Modellunsicherheit allein rechtfertigt keine automatische Löschung.
Nutzen Sie diesen Ablauf für eine nachvollziehbare Prüfung:
- Priorisieren Sie die niedrigsten Scores innerhalb eines Issue-Typs.
- Prüfen Sie das Originalbeispiel und die Annotierungsrichtlinien.
- Korrigieren Sie bestätigte Label-Fehler; bewerten Sie Duplikate und Ausreißer fachlich.
- Führen Sie Audit und Modellbewertung nach Änderungen erneut aus.
| Befund | Sinnvolle Aktion | Zu prüfendes Risiko |
|---|---|---|
| Label-Verdacht | Annotation prüfen und gegebenenfalls berichtigen | Modellunsicherheit nicht mit sicherem Fehler verwechseln |
| Ausreißer | Gültigkeit und Zielpopulation kontrollieren | Seltene, relevante Daten nicht pauschal löschen |
| Near-Duplicate | Paar prüfen und bei Bedarf gruppiert aufteilen | Datenleckage zwischen Trainings- und Testset |
| non-IID | Reihenfolge und Erhebungsprozess untersuchen | Drift nicht durch blindes Shuffling verdecken |
Beim non-IID-Test sollten Sie die Reihenfolge nicht vorab mischen. Sonst kann das Mischen den Hinweis auf geordnete Muster oder Verteilungsverschiebungen entwerten.
Nach einer gezielten Bereinigung sollten Sie prüfen, ob die Modellbewertung besser oder schlechter ausfällt. Das führt zur Frage, welche Aufgaben dieser Ablauf tatsächlich abdeckt.
Wo liegen die Grenzen von Cleanlab Datalab?
Der gezeigte Datalab-Workflow ist für überwachte Klassifikations-Datasets gedacht und deckt nicht pauschal jede ML-Aufgabe ab. Er braucht passende Labels und Modellvorhersagen.
Die Eingabemodalität allein sagt nicht, ob eine Aufgabe unterstützt wird. Auch ein Bild-Dataset kann außerhalb dieses Ablaufs liegen, wenn seine Labels und Modelloutputs keine passende Klassifikationsaufgabe bilden.
Ein Bild als Eingabe macht eine Object-Detection-Aufgabe nicht automatisch zu einem unterstützten Klassifikationsaudit. Entscheidend sind Aufgabe, Labels und Modelloutputs.
Kann Cleanlab object detection prüfen?
Der beschriebene Ablauf gibt keine Zusage für Object Detection. Bilddaten sind eine Eingabemodalität; Object Detection ist eine eigene Aufgabenart mit passenden Zielen und Ausgaben.
Prüfen Sie daher, ob Ihre konkrete Version und Aufgabenart unterstützt werden. Ein Dataset aus Bildern reicht nicht aus, wenn die geforderten Modelloutputs nicht als unterstützte Klassifikationsvorhersagen vorliegen.
Welche Aufgaben passen zum beschriebenen Audit?
Passend ist ein überwachtes Klassifikations-Dataset mit bekannten Labels und Vorhersagen pro Beispiel. Das kann auch Text als Eingabe enthalten, wenn ein Klassifikator daraus passende Klassenwahrscheinlichkeiten erzeugt.
LLM-Ausgaben sind etwas anderes. Eine Klassifikation von Texten ist nicht dasselbe wie die Prüfung generierter Antworten oder freier Textproduktion.
Die Dokumentation einer installierten Version zeigt, welche Aufgaben sie tatsächlich unterstützt. Setzen Sie ältere Angaben nicht automatisch mit den Funktionen Ihrer aktuellen Installation gleich.
Für den nächsten Schritt zählt deshalb die konkrete Aufgabe, nicht nur der Datentyp. Damit lässt sich entscheiden, ob ein kleines Klassifikationsaudit sinnvoll ist.
Fazit
Datalab ist sinnvoll, wenn ein Klassifikationsmodell und passende, nicht überangepasste Vorhersagen vorliegen. Es hilft Ihnen, verdächtige Datenbeispiele gezielt zu finden.
Die Bereinigung bleibt eine fachliche Entscheidung. Beginnen Sie mit einem kleinen gelabelten Dataset und korrekt geordneten out-of-sample-Wahrscheinlichkeiten.
Prüfen Sie die auffälligsten Fälle manuell, bevor Sie Labels oder Beispiele ändern. Führen Sie ein kleines Audit aus und kontrollieren Sie jeden Verdacht im Originalkontext.
