Inkrementelles Lernen mit partial_fit: stabile Features, Klassenlisten und ehrliche Evaluation

Was die Methode leistet

Inkrementelles Lernen aktualisiert einen bestehenden Estimator schrittweise anhand aufeinanderfolgender Batches. Es eignet sich für ein Archiv, das grösser ist als der Arbeitsspeicher, oder für einen Datenstrom, dessen Labels erst im Lauf der Zeit eintreffen. Ein Out-of-Core-System benötigt dennoch einen Datenleser, eine konsistente Feature-Repräsentation und einen Estimator, der inkrementelle Updates unterstützt; ein kleiner Batch allein macht einen beliebigen Algorithmus nicht inkrementell. [1]

Der Update-Vertrag

Bei SGDClassifier führt partial_fit eine Trainingsepoche über den übergebenen Batch aus. Konvergenz nach diesem Aufruf wird nicht zugesichert. Der erste Aufruf benötigt die vollständige vorgesehene Klassenliste über classes, auch wenn dieser Batch nur einen Teil der Klassen enthält. Spätere Aufrufe müssen die Feature-Dimension und die Bedeutung der Labels beibehalten. Wiederholte fit-Aufrufe sind eine andere Operation: Selbst mit warm_start verhält sich ihr Zähler für die Lernrate anders. [2]

Ein praxistauglicher Entwurf fixiert das Feature-Vokabular oder verwendet eine zustandslose Hashing-Repräsentation. Ändert sich die numerische Vorverarbeitung im Betrieb, müssen die Koeffizienten des Modells und die transformierten Feature-Koordinaten konsistent bleiben; einen Scaler unabhängig davon nachzuführen, ist nicht automatisch eine gültige Anpassungsstrategie. Dies ist eine Folgerung für den Workflow, damit die Eingaben des Modells aussagekräftig bleiben.

Anschauliches Beispiel

Angenommen, ein Archiv mit 100000 Supportnachrichten wird in Batches zu 2000 verarbeitet, mit drei vordefinierten Labels: Abrechnung, Technik und Allgemeines. Ein Hashing-Vectorizer mit fester Dimension bildet jeden Batch im selben Feature-Raum ab. Der erste Batch enthält möglicherweise nur Nachrichten zu Abrechnung und Technik, doch bei der Initialisierung werden alle drei Klassen übergeben. Fünfzig Batches decken einen Durchlauf durch das Archiv ab; damit ist weder belegt, dass das resultierende Modell genau ist, noch dass es vollständig optimiert wurde.

Evaluation und Betrieb

Bei einem Live-Datenstrom ist jede Vorhersage zusammen mit ihrer Modellversion aufzubewahren, bevor das zugehörige Label für ein Update verwendet wird. Sobald das Label eintrifft, wird die gespeicherte Vorhersage bewertet, und erst danach wird mit dem Beispiel trainiert. Dieses vorgeschlagene Evaluationsprotokoll vermeidet, dass eine Vorhersage erst gemessen wird, nachdem das Modell die Antwort bereits gelernt hat.

Für Release-Entscheidungen ist ein unabhängiger Evaluationsdatensatz bereitzuhalten, alternativ ein dokumentiertes zeitbasiertes Protokoll. Reihenfolge der Batches, Feature-Konfiguration, Optimierer-Einstellungen, Klassendefinitionen und Modell-Checkpoints sind festzuhalten, damit ein verdächtiges Update untersucht werden kann.

Grenzen und Fehlerfälle

Inkrementelle Updates erkennen weder automatisch Concept Drift, noch verarbeiten sie eine tatsächlich neue Zielklasse, noch erhalten sie die Leistung bei älteren Fällen. Eine sinkende Lernrate kann die Anpassung an spätere Beispiele verringern. [1, 2] Aktuelle und historische Evaluationsausschnitte sind getrennt zu überwachen. Falsche Labels, wiederholte Batches und veränderte Bedeutungen von Features können das Modell beschädigen, obwohl der Update-Aufruf erfolgreich durchläuft. Hier wird weder ein Trainingsexperiment noch eine Durchsatzmessung berichtet.

Quellen

[1] Strategies to scale computationally: bigger data

[2] SGDClassifier