Notizen aus der Review-Praxis
Wann man ein Modell evaluieren sollte, und wann Training es leise verschlechtert
Zwei Fragen kommen in fast jedem Evaluationsprogramm auf, in dem ich gearbeitet habe. Sollte diese Charge überhaupt durch eine menschliche Prüfung, oder verschwendet sie einen Nachmittag eines Prüfers? Und unabhängig davon: Macht das Trainingsmaterial, das wir gleich hinzufügen, das Modell besser, oder bringt es ihm leise bei, selbstbewusster falsch zu liegen? Beide Fragen haben echte Antworten. Es sind nur nicht die, die „alles evaluieren“ und „mehr Daten sind immer besser“ liefern würden.
01Wann sich Evaluation lohnt, und wann nicht
Menschliche Evaluation ist pro Element teuer und im Vergleich zu einem automatischen Score langsam. Das ist in Ordnung, wenn das Ergebnis der Prüfung eine Entscheidung verändert. Es ist verschwendet, wenn nicht. Der Unterschied hängt weniger davon ab, wie schwierig die Aufgabe ist, sondern davon, was nach der Prüfung passiert.
Genau prüfen, wenn:
Der Output als Trainings- oder Präferenzdaten genutzt wird. Alles, woraus ein Modell lernt, verdient mehr Sorgfalt als etwas, das ein Nutzer einmal liest, denn ein Fehler kostet hier nicht eine schlechte Antwort, sondern ein Muster, das das Modell wiederholt. Die Aufgabe heikel oder schwer rückgängig zu machen ist (Medizin, Recht, Finanzen, sicherheitsnahe Inhalte, alles, was auf einmal ein großes Publikum erreicht). Automatische Metriken den eigenen Stichproben widersprechen oder sich untereinander widersprechen. Der Bereich so neu ist, dass noch niemand weiß, welche Fehlerarten es gibt, und deshalb keine Rubrik existiert, die sich automatisieren ließe. Und immer dann, wenn ein Modell seine eigene Antwort erklären oder begründen soll: Die Erklärung ist eine zweite Behauptung, die eine eigene Prüfung braucht, und keine Beigabe, die mit einer richtigen Antwort gratis mitkommt.
Evaluation weglassen oder ausdünnen, wenn:
Die Aufgabe stabil und unkritisch ist und eine automatische Metrik für genau diese Aufgabe bereits gegen menschliches Urteil validiert wurde. Sie dann noch von Hand nachzuprüfen ist Theater, keine Qualitätskontrolle. Die Prüfwarteschlange schneller wächst, als jemand die Befunde umsetzen kann. Ein Rückstau korrekt erkannter Probleme, die niemand beheben kann, ist keine Evaluation, sondern ein Archiv. Und eine Metrik oder Prüfstufe nur noch aus Gewohnheit läuft und niemand sagen kann, welche Entscheidung sie heute noch beeinflusst.
FaustregelFragen Sie, in welche Entscheidung das Prüfergebnis einfließt. Wenn Sie keine benennen können, ist die Prüfung ein Kostenfaktor ohne Gegenwert. Streichen Sie sie oder setzen Sie die Zeit des Prüfers dort ein, wo sie eine Entscheidung speist.
02Was mehr Trainingsdaten wirklich bringen, und was sie kosten
„Mehr Trainingsdaten“ gilt so oft als uneingeschränkt gut, dass es sich lohnt, die Abwägung offen auszusprechen, denn beide Seiten sind real.
Der Nutzen ist echt: breitere Abdeckung der Eingaben, die das Modell im Einsatz tatsächlich sieht, bessere Kalibrierung bei Grenzfällen, die ein kleines, handverlesenes Set nie enthalten hat, einheitlicheres Verhalten bei ähnlichen Prompts und, speziell bei RLHF, die Möglichkeit, Urteilsvermögen zu vermitteln, das sich schwer als Regel aufschreiben lässt. Ein gut gebautes Präferenz-Dataset kann einem Modell den Unterschied zwischen „beantwortet die Frage technisch“ und „beantwortet sie so, wie ein sorgfältiger Mensch es tun würde“ beibringen. Das leistet Prompt-Engineering allein nicht zuverlässig.
Der Nachteil zeigt sich, wenn die Pipeline, die die neuen Trainingsdaten erzeugt, nicht unabhängig vom Modell ist, das trainiert wird. Reward Hacking ist die bekannte Variante: Ein Modell lernt, das Belohnungssignal zu erfüllen statt der Absicht dahinter. Eine subtilere Variante ist Vereinheitlichung. Die Outputs nähern sich dem an, was die Mehrheit der Bewerter bevorzugt hat, und das Modell wird leise schlechter bei den wenigen Stilen oder Lösungswegen, die früher in der Minderheit, aber trotzdem richtig waren. Beides sind echte Kosten von mehr Trainingsdaten, und keines zeigt sich in einer Gesamtgenauigkeit. Genau deshalb bleiben sie meist unbemerkt, bis jemand auf die Verteilung schaut statt auf den Durchschnitt.
03Die Schleife, die ein Modell schlechter macht: ein Modell mit sich selbst trainieren
Innerhalb von „mehr Trainingsdaten können schaden“ steckt ein besonders scharfer Fehler, der einen eigenen Namen verdient, weil man leicht aus Versehen hineinläuft. In der Forschung heißt er Model Collapse. Im Review-Team beschreibt man ihn eher so, wie es sich anfühlt, dabei zuzusehen: als „Bullshit-Loop“. Ein Modell erzeugt Outputs, und diese Outputs (oder daraus abgeleitete Zusammenfassungen, Labels oder Bildunterschriften) fließen in die nächste Trainingsrunde zurück, mit zu wenig echtem, vielfältigem, von Menschen geprüftem Material als Anker. So trainiert das Modell auf einer immer konzentrierteren Fassung seiner eigenen Stimme.
Der Mechanismus ist nicht rätselhaft. Jede Generation eines Modells schleift tendenziell die Ränder einer Verteilung ab: die seltene Formulierung, die ungewöhnliche, aber richtige Antwort, das ehrliche „kommt darauf an“. Trainiert man die nächste Generation auf diesem Output, werden die Ränder noch dünner. Wiederholt man das ein paar Mal, ohne dass frische, echte Daten den Kreislauf unterbrechen, entsteht ein Modell, das flüssig und selbstbewusst ist und immer weniger richtig liegt bei allem, was nicht im statistischen Zentrum dessen liegt, was es schon gesagt hat. Es kündigt sich nicht als Absturz an. Es sieht aus wie eine langsame Drift, nicht wie ein Fehlerbericht.
Eine konstruierte Illustration, so wie ich sie in einer Prüfung tatsächlich markieren würde: Ein Modell für Support-Zusammenfassungen erstellt kurze Zusammenfassungen alter Tickets. Um Annotationskosten zu sparen, nutzt eine spätere Fine-Tuning-Runde diese Zusammenfassungen als Wahrheit statt der Original-Tickets. Die Zusammenfassungen der ersten Generation waren zu 90 % gut und zu 10 % leicht übertrieben sicher (aus „der Kunde erwähnte zeitweise auftretende Probleme“ wurde „das Gerät des Kunden war defekt“). Mit dieser Mischung trainiert, lernt die nächste Generation die sichere Variante als Normalfall. Zwei Runden später ist aus „zeitweises Problem gemeldet“ leise „Hardwaredefekt bestätigt“ geworden, als Standardformulierung des Modells: flüssig, einheitlich und jedes Mal in dieselbe Richtung falsch, weil nichts in der Schleife jemals auf ein echtes Ticket zurückverwiesen hat.
MusterTrainingsdaten, die ganz oder teilweise aus früheren Outputs des Modells selbst stammen und über mehr als eine Generation wiederverwendet werden, ohne einen großen, festen Anker aus echten, unabhängig gewonnenen Beispielen. Die Gesamtgenauigkeit kann eine Zeit lang stabil bleiben, während Vielfalt und Richtigkeit bei seltenen Fällen leise erodieren. Genau deshalb braucht es eine eigene Prüfung, statt der Hauptmetrik zu vertrauen. EmpfehlungEin echtes, von Menschen stammendes Anker-Set führen, dessen Anteil an den Trainingsdaten nie schrumpft, und jedes Mal, wenn synthetische oder vom Modell abgeleitete Daten hinzukommen, auf Verteilungsdrift prüfen (Genauigkeit bei seltenen Fällen, Vielfalt der Outputs), nicht nur auf den Durchschnittswert.
Was das für den Aufbau der Schleife bedeutet
Die beiden Fragen vom Anfang sind am Ende eine einzige Frage mit zwei Hüten: Ist dieser Teil der Pipeline noch mit der Wirklichkeit verbunden, oder fängt er an, sich selbst zu prüfen?
- Menschliche Evaluation dort einsetzen, wo sie eine Entscheidung verändert. Vor allem, bevor etwas zu Trainingsdaten wird. Das ist die eine Stelle, an der ein unbemerkter Fehler nicht eine falsche Antwort kostet, sondern ein Muster, das das Modell in großem Maßstab wiederholt.
- „Mehr Daten“ als Frage behandeln, nicht als Standard. Erst fragen, woher die neuen Daten kommen und wie unabhängig sie vom Modell sind, das damit trainiert wird, und dann, wie viele es sind.
- Ein echtes Anker-Set führen und es nicht schrumpfen lassen. Ein fester, von Menschen stammender, unabhängig geprüfter Kern an Beispielen ist das, was ein Bullshit-Loop nicht verderben kann, solange er einen nennenswerten Anteil dessen ausmacht, womit das Modell tatsächlich trainiert.
- Auf die Ränder schauen, nicht nur auf den Durchschnitt. Genauigkeit bei seltenen Fällen und Vielfalt der Outputs erodieren in einer Rückkopplungsschleife als Erstes, und eine Gesamtmetrik meldet sie als Letztes.
Nichts davon spricht gegen Evaluation oder gegen mehr Trainingsdaten. Beides ist der Weg, wie Modelle besser werden. Es ist ein Plädoyer dafür, zu erkennen, in welcher Schleife man sich gerade befindet: in einer, die immer wieder echte, unabhängige Wahrheit berührt, oder in einer, die angefangen hat, ihre eigenen Hausaufgaben zu korrigieren.
— S.M.S.