Vier Fehlermuster, die automatisierte Metriken nicht erkennen

Im Folgenden geht es um vier wiederkehrende Muster. Keine exotischen, sondern die Formen, die Woche für Woche bei Code-, Logik- und Sprachaufgaben auftauchen. Die ersten beiden sind die Beispiele auf meiner Startseite. Die letzten beiden sind neue Illustrationen in derselben Form, eigens für diesen Beitrag gebaut. Nichts davon ist Kundenarbeit: Echte Aufgaben stehen unter NDA, deshalb ist jedes Beispiel hier frei konstruiert.

Die gemeinsame Struktur lohnt sich vorab zu benennen: Jeder Fehler ist richtig auf der Achse, die die Metrik misst, und falsch auf einer Achse, die niemand misst. Das ist kein Mangel der Metrik. Der Fehler liegt darin, eine einzelne Achse als Urteil zu behandeln.

01Lehnübersetzungen, die jede Bedeutungsprüfung bestehen

Eine förmliche deutsche Absage im Bewerbungsprozess, aus dem Englischen übersetzt. Eine Antwort gibt „move forward with other candidates“ als mit anderen Kandidaten voranzugehen wieder. Jedes Wort stimmt. Die Grammatik stimmt. Die Bedeutung bleibt vollständig erhalten, und genau deshalb lassen semantische Ähnlichkeit und Rückübersetzung den Satz durch. Gleichzeitig schreibt kein Muttersprachler so etwas, und ein deutscher Leser erkennt darin in etwa einer Sekunde Maschinentext.

Die bessere Antwort, dass wir uns für andere Bewerber entschieden haben, ist das, was eine Personalabteilung tatsächlich verschickt. Der Unterschied liegt nicht in der Bedeutung, sondern in Natürlichkeit und Stilebene. Das ist eine eigene Achse, die mit der Bedeutungstreue gerade so eng zusammenhängt, dass sie unsichtbar bleibt, bis ein Modell gut wird. Danach sammeln sich die verbleibenden Fehler fast nur noch hier.

MusterEnglische Phrasal Verbs und Redewendungen werden wörtlich übertragen, statt durch die natürliche Entsprechung ersetzt zu werden. Besteht Prüfungen auf Bedeutungstreue, fällt bei Muttersprachlern durch, am stärksten im förmlichen Register. Eine Natürlichkeitsprüfung durch Muttersprachler gehört neben die semantische Bewertung, nicht dahinter.

02Aussagen über Code, die der Code nicht hergibt

Zwei Funktionen, die das erste nicht wiederholte Zeichen eines Strings zurückgeben. Beide bestehen jeden Testfall aus dem Prompt, also bewertet ein Grader, der nur Ausgaben vergleicht, beide gleich. Eine davon ruft s.count(ch) innerhalb der Schleife auf. Das durchsucht bei jedem Durchlauf den ganzen String und macht die Funktion quadratisch. Trotzdem steht im Begleittext: „O(n) Laufzeit.“

Spannend ist dabei nicht die Ineffizienz. Spannend ist, dass die Aussage Teil der Antwort ist und nichts in der Pipeline sie prüft, weil eine Bewertung nach bestandenen Tests den Text um den Code herum als Dekoration behandelt. Dieselbe Form taucht bei behaupteter Thread-Sicherheit auf, bei behaupteter Idempotenz und bei „deckt alle Grenzfälle ab“ für eine Funktion mit einem ungeschützten Zweig. Wann immer ein Modell seine eigene Arbeit erklärt, ist die Erklärung ein zweiter Output, der eine eigene Prüfung braucht, und die bekommt er selten.

MusterAussagen zu Komplexität und Eigenschaften, ohne die Kosten eingebauter Aufrufe innerhalb einer Schleife zu berücksichtigen. Besteht funktionale Tests, obwohl die angegebene Komplexität falsch ist. Lohnt ein eigenes Probe-Set, weil eine normale Bestanden/Nicht-bestanden-Bewertung das nicht sehen kann.

03Verbote, die stillschweigend verschwinden Illustration

Eine Längenprüfung lässt beide durch. Ein Ähnlichkeitsscore gegen eine Referenzfassung bewertet beide hoch und bewertet A womöglich sogar höher, weil A mehr vom Ausgangsmaterial enthält. Das ist die Falle: Referenzbasierte Metriken messen, was vorhanden ist, gegen das, was vorhanden sein sollte. Ein eingehaltenes Verbot hinterlässt keine Spur im Text. Es gibt nichts zu belohnen, also kann eine Metrik, die auf Überschneidung beruht, es strukturell gar nicht bewerten.

Verbote sind außerdem die Art von Anweisung, die Modelle unter Druck als Erstes fallen lassen: bei langen Kontexten, bei verwandten Themen, bei einer späteren Nachricht, die das Thema wieder aufbringt. „Nicht erwähnen“, „keine Codebeispiele“, „nicht duzen“: leicht zu erfüllen und für Überschneidungsmetriken unsichtbar.

MusterAusschluss-Anweisungen gehen verloren, wenn der ausgeschlossene Inhalt thematisch nah am gewünschten liegt. Empfehlung: ein Probe-Set, in dem jeder Prompt genau ein Verbot enthält, dazu Ausgangsmaterial, das stark zum Verstoß verleitet, bewertet nach Regel statt nach Ähnlichkeit.

04Erfundene Genauigkeit in quellengebundenen Zusammenfassungen Illustration

Eine Treue-Bewertung auf Basis von Überschneidung bewertet A hoch, weil etwa neun Zehntel des Satzes sauber aus der Quelle stammen. Auch Entailment-Prüfungen auf Satzebene lassen A oft durch: Die Aussage „die meisten Unternehmen berichteten von Verzögerungen“ ist durch die Quelle gedeckt, und die eingeschobene Zahl fährt in einem ansonsten gut belegten Satz einfach mit. Die menschliche Prüfung erkennt den Fehler durch etwas Unspektakuläres: Bei jeder Zahl, jedem Namen und jedem Datum fragt sie, aus welcher Stelle der Quelle das stammt.

Dieser Fall verdient mehr Aufmerksamkeit, als seine Größe vermuten lässt, denn der Fehler ist gegenläufig dazu, wie gut sich der Output liest. A hat eine Zahl erfunden und wirkt auf fast jeden Leser und die meisten Reward-Modelle wie die bessere Zusammenfassung. Präferenzdaten, die ohne Quellenprüfung gesammelt werden, bringen einem Modell zuverlässig bei, genau das öfter zu tun.

MusterVorsichtige Mengenangaben in der Quelle („eine Mehrheit“, „mehrere“, „die meisten“) werden durch erfundene genaue Zahlen ersetzt. Besteht Treue-Bewertungen auf Basis von Überschneidung und oft auch Entailment auf Satzebene. Empfehlung: bei der Evaluation quellengebundener Texte jede Zahl einer konkreten Quellstelle zuordnen.

Was das für den Aufbau einer Pipeline bedeutet

Nichts davon spricht gegen automatisierte Evaluation. 3.000 Outputs ohne Vorfilter einem Menschen vorzulegen ist ein teurer Weg, um festzustellen, dass die meisten in Ordnung sind. Es geht darum, an welcher Stelle der Kette die automatischen Prüfungen sitzen.

1. Metriken sortieren vor, Menschen entscheiden. Ein automatischer Score ist ein guter Grund, sich etwas zuerst anzusehen, und ein schlechter Grund, nicht mehr hinzusehen.
2. Für jede Metrik die Achse benennen, die sie abdeckt, und den Rest mit Menschen besetzen. Bedeutungstreue und Natürlichkeit sind zwei Achsen. Funktionale Korrektheit und Selbstbeschreibung sind zwei Achsen. Inhaltliche Überschneidung und Befolgen von Anweisungen sind zwei Achsen. Jede Lücke ist eine Stelle, an der ein Modell selbstbewusst falsch liegen kann.
3. Wiederkehrende Fehler in Probe-Sets verwandeln. Das nützlichste Ergebnis meiner Arbeit ist kein Score, sondern ein Satz von Prompts, die so gebaut sind, dass sie die automatische Prüfung bestehen und beim genauen Lesen durchfallen. So wird aus einem Muster, das ein Prüfer bemerkt hat, etwas, das die Pipeline dauerhaft verfolgen kann.
4. Uneinigkeit unter Prüfern als Fehler in der Guideline behandeln. Wenn zwei sorgfältige Prüfer beim selben Paar unterschiedlich entscheiden, liegt es meist an einer Rubrik, die nie gesagt hat, welche Achse Vorrang hat. Die Guideline zu korrigieren ist billiger, als jede Charge neu zu entscheiden, und es ist die Änderung, die sich aufsummiert.

Der rote Faden in allen vier Mustern: Modelle scheitern in Richtung „sieht richtig aus“. Das ist kein Zufall, sondern das, was entsteht, wenn man auf eine messbare Ersatzgröße optimiert. Und genau deshalb lohnt es sich, wenn jemand das Ergebnis Zeile für Zeile liest.

— S.M.S.