Trainingsdaten prüfen, bevor Sie ein Sprachmodell feintunen

Warum die Datenprüfung vor das Training gehört

Keine Trainingseinstellung gleicht falsche Antworten in den Daten aus. Im SFTTrainer von Hugging Face TRL ist der Verlust eine Kreuzentropie auf Token-Ebene, und bei Prompt-Completion-Datensätzen wird er standardmäßig nur über die Antwort-Token berechnet. Das Modell wird dafür belohnt, Ihre erfassten Antworten Token für Token nachzubilden, nachlässige Labels und abgeschaffte Richtlinien eingeschlossen.

Die Fine-Tuning-Dokumentation von OpenAI, geschrieben für eine gehostete Plattform, die für neue Nutzer geschlossen ist, empfiehlt, mit etwa 50 sorgfältig erstellten Beispielen zu beginnen und Aufgabe oder Prompt zu überdenken, wenn diese nichts ändern. Der Rat gilt für Open-Weight-Modelle genauso.

Erfasste Antworten mit dem Urteil von Fachleuten abgleichen

Historische Datensätze sehen aus wie Labels, sind es aber oft nicht. Ticketkategorien werden in Eile gewählt, Felder werden später im Prozess korrigiert, ohne dass die Korrektur zurückfließt, und Betrugskennzeichen spiegeln Regeln wider, die sich inzwischen geändert haben. Lassen Sie vor dem Training eine Fachperson eine Zufallsstichprobe labeln, ohne die erfasste Antwort zu sehen, und ordnen Sie jede Abweichung einer dieser Gruppen zu.

• Falsches Label: Der Datensatz ist schlicht fehlerhaft. Korrigieren oder entfernen.
• Lücke in den Richtlinien: Zwei Fachleute sind uneins, weil die Regeln den Fall nicht entscheiden. Erst die Regel formulieren, dann neu labeln.
• Veraltete Antwort: nach einer alten Richtlinie richtig, nach der aktuellen falsch. Nach Datum filtern oder neu labeln.
• Label aus der Rückschau: Die Antwort hängt von Informationen ab, die erst später vorlagen, etwa einer Rückbuchung Wochen nach der Entscheidung. Die Eingabe darf nur enthalten, was zum Entscheidungszeitpunkt bekannt war.

Wenn zwei Fachleute seltener übereinstimmen, als das Modell mit ihnen übereinstimmen soll, überarbeiten Sie zuerst die Aufgabendefinition.

Beispiele mit dem Traffic vergleichen, den das Modell bekommen wird

Ein korrekter Datensatz kann trotzdem nicht repräsentativ sein. Vergleichen Sie die Produktionseingaben eines aktuellen Monats mit dem Trainingsset nach Kategorie, Sprache, Dokumentvorlage, Kundensegment und Länge der Eingabe.

Zählen Sie seltene Klassen getrennt. Die Hinweise zu Hugging Face Evaluate halten fest: Bei 99 normalen Fällen und einem Betrugsfall erreicht ein Modell, das immer normal antwortet, 99 Prozent Genauigkeit und erkennt keinen Betrug. Weisen Sie die teuren Fälle gesondert aus.

Die Länge ist die Prüfung, die Teams vergessen. In der zum Zeitpunkt des Schreibens dokumentierten TRL-Version kürzt der SFTTrainer Sequenzen, die länger als max_length sind, standardmäßig 1.024 Token, und behält den Anfang. Zählen Sie Token mit dem Tokenizer des Basismodells. Wenn lange Dokumente Ihr Limit überschreiten, erhöhen Sie es oder strukturieren Sie die Eingabe um, sonst trainiert das Modell auf Beispielen, deren Antwort abgeschnitten wurde.

Festhalten, woher jedes Beispiel stammt

Gebru und Kollegen haben vorgeschlagen, jeden Datensatz mit einem Datenblatt zu versehen, das Zweck, Zusammensetzung, Erhebung und empfohlene Verwendung beschreibt. Für ein Fine-Tuning-Set genügt eine Seite pro Datenquelle, wenn sie Folgendes festhält.

• Quellsystem und Abfrage, mit dem abgedeckten Zeitraum
• Wer jedes Label erzeugt hat: eine Person, eine Regel, ein späteres Ergebnis oder ein anderes Modell
• Die Version der Richtlinie, der die Labels folgen
• Personenbezogene oder vertrauliche Felder und wie sie entfernt oder behalten wurden
• Die Grundlage, auf der die Daten für das Training genutzt werden dürfen, bestätigt durch Ihre Datenschutz- und Rechtsberatung

Kennzeichnen Sie von Modellen erzeugte oder synthetische Beispiele, prüfen Sie eine Stichprobe davon so sorgfältig wie menschliche Labels und halten Sie sie aus dem Testset heraus, damit Sie sie entfernen können, falls später ein Problem auftaucht.

Testfälle aus den Trainingsdaten heraushalten

Ein Testset sagt nur dann etwas aus, wenn das Modell es nicht gesehen hat. Lee und Kollegen stellten fest, dass Überschneidungen zwischen Training und Test in den untersuchten Standarddatensätzen über 4 Prozent der Validierungsbeispiele betrafen. Geschäftsdaten können schlimmer sein: Vorlagen-E-Mails, wiederkehrende Rechnungen und ein Fall, der als mehrere Tickets erfasst wurde, erzeugen lauter Beinahe-Kopien.

Deduplizieren Sie vor dem Aufteilen, mit normalisiertem Text oder einem Ähnlichkeitsschwellenwert statt exakter Übereinstimmung. Legen Sie dann fest, worauf das Modell verallgemeinern muss. Wird es neuen Lieferanten oder Vorlagen begegnen, halten Sie ganze Lieferanten zurück. Sieht es überwiegend künftige Rechnungen bekannter Lieferanten, teilen Sie nach Zeit, sodass der Testzeitraum auf den Trainingszeitraum folgt. Eine zufällige Aufteilung nach Zeilen beantwortet keine der beiden Fragen.

Frieren Sie das Testset ein und geben Sie ihm einen Verantwortlichen außerhalb der Trainingsarbeit.

Ein durchgerechnetes Audit für einen hypothetischen Rechnungsdatensatz

Angenommen, ein Finanzteam möchte ein kleines Modell zwölf Felder aus Lieferantenrechnungen extrahieren lassen und hat 8.000 von Sachbearbeitern korrigierte Rechnungen. Alle Zahlen sind hypothetisch, und die Schwellenwerte werden festgelegt, bevor jemand Ergebnisse sieht.

1. 1

   Stichprobenprüfung

   Eine Fachperson labelt 300 zufällige Rechnungen blind neu. Ziel: 97 Prozent Übereinstimmung auf Feldebene. Ergebnis: 93 Prozent, weil Umsatzsteuerkorrekturen im ERP nie zurückgeschrieben wurden.

2. 2

   Die Quelle korrigieren

   Die Labels werden aus den endgültigen Werten im ERP neu aufgebaut, und eine neue Stichprobe erreicht jetzt das Ziel.

3. 3

   Abdeckungstabelle

   Gescannte Rechnungen machen 9 Prozent des Traffics im letzten Quartal aus, aber nur 80 der 8.000 Beispiele. Das Team ergänzt 700 gelabelte Scans und kommt damit auf 780 von 8.700, nahe am Ziel von 9 Prozent.

4. 4

   Längenprüfung

   6 Prozent der Rechnungen überschreiten 1.024 Token. Das Limit wird erhöht, und mehrseitige Rechnungen erhalten einen eigenen Testausschnitt.

5. 5

   Deduplizieren und aufteilen

   Nach dem Entfernen von Beinahe-Duplikaten bleiben 7.350 von 8.700 Datensätzen, und das Team prüft, dass Scans weiterhin nahe bei 9 Prozent liegen. Jeden Monat kommen neue Lieferanten hinzu, daher werden 20 Prozent der Lieferanten vollständig zurückgehalten, und ein zweites Testset deckt den jüngsten Monat bekannter Lieferanten ab.

6. 6

   Datenblatt

   Eine Seite hält Quellen, Herkunft der Labels, Richtlinienversion, entfernte personenbezogene Felder und die Freigabe der Beratung fest.

Das Training beginnt nach Schritt sechs. Wo Ergebnisse nie erfasst werden oder Fachleute bei vielen Fällen uneins sind, definieren Sie zuerst die Aufgabe, bevor irgendein Fine-Tuning beginnt.