Das Modell, das deine Inhalte schreibt, kann sie nicht benoten

Was es mich gekostet hat, das zu lernen, gemessen an 233 Items.

Vier Erklärungen, die meine App deutschen Lernenden fast beigebracht hätte:

Und jetzt der Teil, der jeden beunruhigen sollte, der KI-generierte Inhalte ausliefert. In jedem einzelnen dieser Items war die Antwort korrekt. Die Aufgabe funktionierte. Ein Lernender hätte die richtige Option gewählt, sich gut gefühlt, dann einen Satz selbstbewussten, flüssigen, grammatisch formulierten Unsinn gelesen und ihn geglaubt.

Keine Stichprobe fängt das ab. Man liest das Item, die Antwort stimmt, man macht weiter.

Keines davon hat je einen Lernenden erreicht. Genau darum geht es in diesem Artikel: sie zu fangen.

Was ich gebaut habe

Ich betreibe KorrektWort, eine deutsche Vokabel-App, die ich allein baue. Ich lege gerade selbst eine B1-Prüfung ab, und so bin ich hier gelandet: Deutschprüfungen haben einen Grammatik-Lückenteil, ein Satz, eine Lücke, drei Optionen, genau eine richtig. Ich wollte diese aus den Sätzen erzeugen, die ohnehin in meinem Content-Cache liegen, und ich wollte, dass sich jede in einer einzigen Zeile selbst erklärt, denn eine Aufgabe, die nur anzeigt, dass man falsch lag, ist eine Prüfung, kein Lehrer.

Die Sicherheitseigenschaft ist gnadenlos. Genau eine Option darf akzeptabel sein. Wenn zwei funktionieren, bekommt ein Lernender, der korrekt Deutsch kann, gesagt, er liege falsch, und das ist das Schlimmste, was eine Sprach-App tun kann. Und die Erklärung muss wahr sein, denn eine falsche Regel, selbstbewusst gelehrt, ist schlimmer als gar keine Erklärung.

Die erste Pipeline und was sie tatsächlich erreichte

Version eins war das Naheliegende: ein Aufruf an ein schnelles, günstiges Modell (Claude Haiku), strukturierte Ausgabe, gib mir die Lücke, die Antwort, zwei Distraktoren und die Erklärung.

Es sah gut aus. Beim Durchlesen hätte ich es ausgeliefert.

Also habe ich stattdessen einen Blindtest gefahren: 106 Items aus Sätzen, die der Generator nie gesehen hatte, bewertet von unabhängigen Prüf-Agenten anhand einer festen Rubrik mit sechs Noten, Uneinigkeiten von einem stärkeren Modell entschieden. Kein erneutes Bewerten von etwas, worauf der Prompt getrimmt worden war.

15,1 % der Items enthielten etwas Falsches. Mein eigenes Durchlesen hatte fast nichts davon gefangen, weil die Antworten stimmten.

Die Diagnose

Zwei Fehler, und nur einer davon hatte mit der Modellgröße zu tun.

Die Erklärung war eine Rationalisierung. Derselbe Aufruf erfand die Lücke und schrieb dann den Grund. Als er überhaupt etwas erklärte, war die Entscheidung schon gefallen, also war die Aufgabe der Erklärung still und leise geworden, eine Wahl zu rechtfertigen statt eine Regel zu beschreiben. Genau unter dieser Bedingung produziert ein Sprachmodell flüssigen, falschen Text.

Das Modell war genau bei dem am schwächsten, was es erklärte. Grammatik-Terminologie ist der Punkt, an dem das Selbstvertrauen eines kleinen Modells und seine Kompetenz am weitesten auseinandergehen. Es kennt die Wörter Dativ, Genitiv, transitiv und benutzt sie in einem wohlgeformten Satz, der zufällig falsch ist.

Also habe ich die Arbeit aufgeteilt.

Die neu gebaute Pipeline

Jede Stufe unten ist ein eigener Aufruf, mit einer Regel hinter dem ganzen Aufbau: keine Stufe darf ihre eigene Ausgabe bewerten.

1. Deterministische Hygiene, in Code. Sätze, die mit ae/oe/ue statt Umlauten geschrieben sind, und anderer billig zu erkennender Müll. Kein Modell nötig.
2. Natürlichkeits-Gate. Ist dieser Ausgangssatz überhaupt korrektes, standardsprachliches Deutsch? Nur Fehler, kein Geschmack.
3. Die Lücke vorschlagen, jetzt auf einem starken Modell (Claude Opus). Ein Token ausblenden, das eine Grammatikregel prüft, mit zwei Distraktoren, die verlockend, aber falsch sind.
4. Struktureller Validator, in Code. Der Satz mit Lücke plus die Antwort müssen das Original exakt rekonstruieren; zwei verschiedene Distraktoren; keine Inhalts-Nomen ausgeblendet; keine Lücke innerhalb eines Wortes; kein Genitiv-Artikel vor einem Nomen ausgeblendet, das bereits seine eigene Genitiv-Endung trägt, denn dann sind die falschen Optionen unmöglich statt verlockend. Jede Regel, die ich als Code ausdrücken konnte, habe ich aus einem Modell herausgezogen. Diese Prüfungen sind kostenlos, sofort und halluzinieren nie.
5. Die Erklärung getrennt schreiben, anhand einer Checkliste, in einem eigenen Aufruf. Sie sieht nie die Argumentation, die das Item erzeugt hat, also kann sie es nicht rationalisieren. Die Checkliste verbietet genau die obigen Fehler: ein steuerndes Wort nur nennen, wenn es wirklich steuert, einen Kasus oder ein Genus nur angeben, wenn sicher, nie ein Wort erfinden, das nicht im Satz steht.
6. Die Erklärung validieren, in Code. Länge, Fachjargon und eine Zitat-Prüfung: Jedes deutsche Wort, das in der Erklärung zitiert wird, muss im Satz vorkommen oder eine legitime Wörterbuchform davon sein. Diese eine Prüfung fängt springt, wenn der Satz sprang sagt, und uberweisen, ohne Umlaut geschrieben. Ihre Falsch-Positiv-Rate, gemessen über 206 zuvor erzeugte Erklärungen, liegt bei 1 zu 206.
7. Adversarialer Mehrdeutigkeits-Richter. Ein eigener Aufruf, dessen einzige Aufgabe es ist, jeden Distraktor in die Lücke zu setzen und zu argumentieren, dass er auch passt. Sein Anreiz ist das Gegenteil des Generators.
8. Zwei Abnahme-Panels. Je drei Perspektiven (Mehrdeutigkeit, Wahrheit der Erklärung, Natürlichkeit und Sog der Distraktoren), einstimmiges PASS von allen dreien nötig, dann dasselbe noch einmal auf einem stärkeren Modell.

Bei Multi-Agenten geht es um Unabhängigkeit, nicht um Parallelität

Das ist der Teil, den ich einem anderen Ingenieur am meisten mitgeben möchte, weil ich es am Anfang falsch hatte.

Ich habe ursprünglich zu mehreren Agenten gegriffen, weil sie gleichzeitig laufen konnten. Das ist der uninteressanteste Grund. Der Grund, der zählt, ist, dass Agenten strukturell verschieden voneinander gemacht werden können, und ein Richter, der die Rahmung des Generators teilt, teilt dessen blinde Flecken.

Der Beweis ist unbequem und einen Bericht wert. Mein erstes Abnahme-Panel, drei Perspektiven auf einem starken Modell, einstimmige Zustimmung nötig, ließ eine Reihe von Items glatt durch. Dann fügte ich ein zweites Panel auf einem stärkeren Modell hinzu, dieselbe Rubrik, und es lehnte dreizehn Items ab, die das erste Panel einstimmig gebilligt hatte. Darunter: zwei Ausgangssätze mit einem Rechtschreibfehler, den niemand bemerkt hatte, und drei Items, bei denen ein Distraktor tatsächlich korrektes Deutsch ergab.

Einstimmigkeit innerhalb einer Rahmung ist keine Unabhängigkeit. Es ist eine Meinung, dreimal wiederholt.

Als ich also den Bewerter baute, der die echte Qualität der Pipeline messen würde, habe ich ihn bewusst in drei Punkten gleichzeitig verschieden gemacht:

• Andere Prompt-Struktur. Er sieht nie die Rubrik, die die Gates der Pipeline selbst verwenden.
• Umgekehrter Anreiz. Er ist als Widerspruchsstelle einer Prüfung gerahmt. Prüflinge, die jede falsche Option gewählt haben, haben Widerspruch eingelegt und argumentieren, ihre Antwort passe auch, und das Gremium muss begründen, warum es einen Widerspruch ablehnt. Das Gate der Pipeline muss begründen, ein Item anzunehmen; der Bewerter muss begründen, einen Prüfling abzuweisen. Diese Kräfte zeigen in entgegengesetzte Richtungen.
• Das Urteil wird berechnet, nicht gewählt. Der Agent gibt atomare Einzelurteile zurück (ist diese Option akzeptabel, ist diese Aussage wahr, ist der Satz natürlich), und gewöhnlicher Code macht daraus eine Note. Ein Modell, das die Note nie benennt, kann bei der Note nicht nachsichtig sein.

Die Zahl, die entscheidet, ob du ausliefern kannst

Mittendrin verschob sich die Rahmung, und das ist die übertragbarste Idee hier.

Ich hatte die Ausbeute berichtet: welcher Anteil der erzeugten Kandidaten überlebt. Es ist eine naheliegende Zahl, und es ist die falsche, um damit Entscheidungen zu treffen. Ausbeute ist eine Wirtschaftlichkeitskennzahl. Sie sagt dir, was Inhalte kosten.

Die Kennzahl, die entscheidet, ob du einem Menschen Inhalte vorlegen kannst, ist die Präzision unter den akzeptierten Items: Von allem, was dein Filter durchgelassen hat, wie viel ist tatsächlich korrekt?

Beide können sich in entgegengesetzte Richtungen bewegen, und genau das willst du. Ein strengerer Filter senkt die Ausbeute und hebt die Präzision. Wenn du die Ausbeute optimierst, lockerst du genau das Gate, das deine Nutzer geschützt hat.

Hier der Funnel für einen Lauf, alle Zahlen aus den Artefakten:

43,6 % sieht nach einem kaputten Generator aus. Es ist keine Zahl, die mich interessiert. Über 233 akzeptierte Items aus dieser Pipeline, unabhängig bewertet, liegt die schädliche Falsch-Annahme-Rate bei 2 Items, 0,9 %: eines mehrdeutig, eines, das Vokabular statt Grammatik prüfte. Keines enthielt eine sachlich falsche Erklärung.

Kosten: 0,168 USD pro akzeptiertem Item, einmal bezahlt. Der Inhalt wird über alle Nutzer der App geteilt, also gehen die Grenzkosten pro Lernendem gegen null.

Das ist der Handel. Verbrenne 56 % dessen, was du erzeugst, und liefere Inhalte, die du verteidigen kannst.

Das Experiment, von dem ich Wirkung erwartete und das keine hatte

Die verbleibende Schwäche war nicht die Wahrheit, sondern die Schärfe. Viele akzeptierte Items waren korrekt und langweilig: Die falschen Optionen waren so offensichtlich unmöglich, dass kein Grammatikwissen nötig war.

Die Hypothese war, dass dem Generator ein Modell davon fehlte, was echte Prüfungsitems testen und wie ihre Distraktoren gebaut sind. Die teure Variante, das zu beheben, ist, die Generierung in echtem, veröffentlichtem Prüfungsmaterial zu verankern, was Urheberrechts- und Nutzungsfragen aufwirft, die ich nicht wollte.

Also habe ich zuerst die billige, risikofreie Variante getestet. Ich ließ ein starkes Modell meine eigenen 281 unabhängig bewerteten Items lesen und sie zu einer Taxonomie abstrahieren: Grammatikkategorien, Verwechslungstypen bei Lernenden, Distraktor-Strategien, welchen Kontext ein Satz liefern muss, damit genau eine Antwort passt. Kein Fremdmaterial, kein Kopieren, nur meine eigenen Daten und allgemeines Wissen über das Format. Vierundzwanzig Muster, entworfen für 0,63 USD.

Dann ein kontrolliertes A/B, beide Arme durch dieselbe, unveränderte Trust-Pipeline. Ich habe die primäre Kennzahl vor dem Lauf vorregistriert: den Anteil akzeptierter Items, bei denen ein unabhängiger Bewerter beide falschen Optionen als wirklich verlockend beurteilte.

Muster-Verankerung tat überhaupt nichts für das, wofür ich sie gebaut hatte. Auf denselben Mix von Grammatikkategorien standardisiert, erreichen beide Arme 71,1 % und 72,0 %. Identisch.

Was sie stattdessen tat, war ein Problem zu lösen, das ich nicht als Priorität gerahmt hatte. Die satzbasierte Generierung konnte nur prüfen, welche Grammatik zufällig in meinen zwischengespeicherten Sätzen vorkam, und diese Sätze sind Anfängermaterial, also produzierte sie ein einziges B1-Item von 75. Für ein Feature, das auf B1 zielt, ist das kein Qualitätsproblem, es ist ein Existenzproblem. Musterbasiert produzierte 33.

Zwei Dinge, die ich davon behalten würde. Teste die billige, risikofreie Variante einer Idee vor der teuren, denn die billige kann die Frage vollständig beantworten, wie hier: Ich habe keinen Grund mehr, urheberrechtlich geschütztes Material anzufassen, da der Mechanismus, für den ich es wollte, sich als unwichtig herausstellte. Und registriere vor, was als Erfolg zählen würde, denn bei einem so mehrdeutigen Ergebnis hätte ich mir in beide Richtungen eine überzeugende Geschichte erzählen können.

Was ich nicht durch mehr Agenten beheben kann

Ein Artikel über Validierung, der seine eigenen Grenzen nicht nennt, ist Marketing. Drei:

Jeder Bewerter ist ein Claude-Modell. Sie unterscheiden sich in Prompt, Anreiz und Entscheidungsverfahren, was genügt, um blinde Flecken auf Prompt-Ebene zu fangen, und das nachweislich tat. Es genügt nicht, um einen blinden Fleck zu fangen, den sie alle teilen. Wenn jedes Modell der Familie eine Konstruktion falsch beurteilt, kommt sie durch jede Stufe meiner Pipeline und ich erfahre es nie. Keine Zahl von Panels behebt das, denn die Panels stammen aus derselben Verteilung.

Ich habe einen Fail-open-Bug in meinem eigenen Mess-Harness gefunden. Mein Bewerter kombinierte zwei Teilurteile im Code zu einer Note, und wenn ein Teil-Agent fehlschlug, fiel das fehlende Urteil auf PASS durch. Er hätte perfekte Präzision für 36 Items gemeldet, die überhaupt keine Daten enthielten. Ich habe es beim Auszählen gefangen, nur weil die Bestehensrate zu sauber aussah. Bewertungscode braucht dieselbe Paranoia wie Produktionscode, und er sollte fail-closed sein. Wenn er das mir angetan hat, tut er es gerade jemand anderem.

Eine meiner Messungen war konfundiert, und ich hätte sie fast als sauberen Vergleich berichtet. Mein strengster Bewerter wurde mittendrin abgeschnitten und hatte nur das leichteste Drittel der Items gesehen, was seine Bestehensrate von 57,9 % nicht vergleichbar machte mit den 89,3 % eines anderen Bewerters auf dem vollen Satz. Andere Items, nicht andere Strenge.

Die ehrliche Schlussfolgerung ist, dass all das den Filter validiert, nicht das Deutschwissen der Modelle. Deshalb ist die letzte Stufe der Pipeline gar kein Modell: Jede Übung in der App trägt einen "Das sieht falsch aus"-Button, und diese Meldungen gehen an einen Menschen. Ein Lernender, der korrekt Deutsch kann, ist das einzige Instrument, das die Fehler erreicht, die meine Bewerter teilen.

Was übertragbar ist

Wenn du eine Pipeline baust, die Inhalte erzeugt, aus denen Menschen lernen sollen:

Trenne das, was entscheidet, von dem, was erklärt. Eine Erklärung, die von dem Aufruf geschrieben wird, der die Entscheidung getroffen hat, ist eine Rationalisierung, und in Rationalisierungen wohnen die Unwahrheiten.

Verlege jede Prüfung, die du kannst, in Code. Meine billigsten, zuverlässigsten Gates sind reguläre Ausdrücke. Sie halluzinieren nie, kosten nichts und laufen für immer auf jedem Item.

Mache deine Richter strukturell verschieden, nicht nur zahlreich. Andere Rahmung, umgekehrter Anreiz, und lass Code das Urteil aus atomaren Einzelurteilen berechnen, von denen das Modell nicht weiß, dass es sie aggregiert.

Berichte die Präzision unter den akzeptierten Items, nicht die Ausbeute. Sie bewegen sich in entgegengesetzte Richtungen, und nur eine davon betrifft deine Nutzer.

Halte Vertrauen und Feinschliff als getrennte Messlatten. Ich hätte fast ein Gate gebaut, das korrekte, gut erklärte Übungen ablehnt, weil sie etwas zu leicht sind, was das Feature ausgehungert und niemanden geschützt hätte. Vertrauen ist absolut: Ein Item, das falsch sein könnte, wird nie ausgeliefert. Feinschliff ist eine Vorliebe: Liefere das schärfere Item, wenn du eines hast, und sonst ein sicheres, leichtes.

Repariere nie ein zweifelhaftes Item. Wirf es weg und erzeuge ein neues. Reparieren heißt, einen übertünchten Zweifel für immer in die Produktion zu tragen. Sätze sind billig; Vertrauen nicht.

Die erste Version dieser Pipeline hätte Tausenden von Lernenden beigebracht, dass des eine Präposition ist. Die gemessene Version tut das nicht. Dieser Abstand, zwischen einer Ausgabe, die sich gut liest, und einer Ausgabe, die man mit Zahlen verteidigen kann, ist der größte Teil der Arbeit.

Ich baue KorrektWort allein, und bei KorrektCode arbeite ich an den Systemen anderer. Wenn du KI-generierte Inhalte auslieferst und noch nicht sagen kannst, wie hoch deine Präzision unter den akzeptierten Items ist, dann ist das die Zahl, mit der ich anfangen würde.