In Teil 2 hatte ich die Slop-Liste. Ich wusste, was raus muss: die leeren Beteuerungen, der Doppelpunkt-Tic, „maßgeschneiderte Lösungen“, das Aufbauschen mit „wirklich“ und „echt“. Eine saubere Taxonomie auf Papier.

Nur trainiert eine Liste kein Modell. Die eigentliche Frage kam erst danach. Wie bringe ich einem 12-Milliarden-Parameter-Netz bei, genau diese Muster zu meiden, ohne dass es dabei verlernt, was es kann? Ein Modell, das slopfrei schreibt, aber nicht mehr rechnen oder strukturieren kann, ist wertlos.

Der Standardhebel dafür wäre DPO. Ich habe ihn bewusst nicht genommen, und das hat einen Grund.

Warum nicht DPO

Direct Preference Optimization optimiert auf ganze Antworten. Du zeigst dem Modell ein „besser“ und ein „schlechter“ und drückst die gesamte Wahrscheinlichkeitsverteilung in Richtung der besseren Antwort. Das funktioniert für Geschmack und Hilfsbereitschaft. Für mein Problem ist es ein Vorschlaghammer.

Ich wollte keine ganzen Antworten umbauen, ich wollte einzelne Tokens treffen. Das „inklusive“, das an der falschen Stelle steht. Das „nahtlos“, das in „nahtlose Integration“ zur Hülse wird. Optimiere ich auf Antwortebene, riskiere ich, dass das Modell beim Wegtrainieren eines Tics nebenbei seine Fähigkeiten mitverschiebt, Capability-Verlust als Kollateralschaden. Und genau den konnte ich mir nicht leisten.

Sam Paech hat dafür eine chirurgischere Methode gebaut. FTPO, Final Token Preference Optimization, Teil seines auto-antislop-Frameworks.1 Statt ganze Sequenzen zu vergleichen, operiert FTPO im Logit-Space auf einem einzelnen Token an einer einzelnen Position. An genau der Stelle, wo das Modell gleich Slop produzieren würde, lernt es, das Slop-Token abzuwerten und eine natürliche Alternative zu bevorzugen. Der Rest der Verteilung bleibt unangetastet.

Links zertrümmert ein Vorschlaghammer eine Mauer aus Sprechblasen-Ziegeln, rechts zieht eine Pinzette einen einzelnen Ziegel aus der intakten Mauer.
Links DPO, rechts FTPO. Ein Ziegel raus, die Mauer steht.

Ob das wirklich genug ist, hätte ich aus der Beschreibung allein nicht geglaubt. Überzeugt haben mich zwei Zahlen aus dem Paper (Paech et al., 2025). Die erste kennst du aus Teil 2. Manche Slop-Muster tauchen im LLM-Output über 1000-mal häufiger auf als in menschlichem Text.2 Slop ist also nicht subtil, er ist statistisch grotesk, und damit überhaupt erst messbar. Die zweite Zahl sagt, was FTPO dagegen ausrichtet. Rund 90 Prozent Slop-Reduktion, während die Performance auf GSM8K, MMLU und Creative-Writing-Benchmarks gehalten oder leicht verbessert wird.2 Das ist genau die Eigenschaft, die DPO mir nicht garantiert.

Ausgeliefert wird das als LoRA-Adapter, kein Full-Finetune, sondern eine dünne trainierbare Schicht über dem eingefrorenen Basismodell. Klein, billig, reversibel. Bleibt die Frage, was so ein Lauf eigentlich kostet.

Serverlos, eine H100, neun Dollar

Die Infrastruktur war der unspektakulärste Teil des Projekts, und das meine ich als Kompliment. Ich habe den ganzen Lauf serverlos auf Modal gefahren, eine H100, Modell einmal ins Volume cachen, dann zünden. Ein voller Lauf, also Generierung, Banlist, Training und Merge, dauerte rund zwei Stunden und kostete acht bis neun Dollar, weil der teure 24-GB-Modell-Pull beim zweiten Mal entfällt.

Kein Cluster, keine Reservierung, keine GPU, die nachts Geld verbrennt. Genau das ist der Punkt, an dem so ein Experiment für einen einzelnen Engineer überhaupt machbar wird. Wenn ein Trainingslauf so viel kostet wie zwei Kaffee, probierst du Dinge aus, die du dir bei Cluster-Preisen verkneifen würdest.

Der eigentliche Aufwand lag ganz woanders. Nicht im Trainieren, sondern im Definieren, wogegen trainiert wird.

Das Herzstück ist die Baseline

Paechs tiefste Einsicht im ganzen Projekt steckt in einem Satz. Die Baseline ist die Definition von „natürlich“.

Das klingt abstrakt, bis man versteht, warum Slop überhaupt relativ entsteht. Ein Wort ist nicht an sich Slop. Es wird zu Slop, wenn es in einem Register auftaucht, in das es nicht gehört, viel häufiger, als ein Mensch es dort verwenden würde. Der Detektor braucht also einen Referenzkorpus, deutsche Texte, von Menschen geschrieben, gegen die der Modell-Output verglichen wird. Was im Modell-Output systematisch über-frequent ist und in der Baseline fehlt, ist verdächtig.

Damit verschiebt sich die ganze Frage. Sie lautet nicht mehr „was ist richtiges Deutsch“, sondern „in welchem Register soll das Modell schreiben“. Lyrik hat anderen natürlichen Wortschatz als ein Gerichtsurteil, ein Chatverlauf anderen als eine Produktseite. Die Baseline muss zum Ziel-Register passen, sonst misst sie Unsinn.

Bei mir war die Antwort eindeutig, weil der Anwendungsfall es war. Website-Copy, Marketing-Deutsch, das nach Mensch klingt. Also baute ich die Baseline aus zwei Quellen, OpenSubtitles2018-DE als fertige, garantiert pre-LLM Frequenzliste, plus German Commons, register-selektiv gestreamt. Paechs Normalisierungslogik habe ich nachgebaut und nur die englischen Stoppwörter gegen deutsche getauscht.4

Die erste Baseline sah stark aus. Dann las ich genauer hin, und was ich fand, war ein Problem an der Wurzel.

Die Calque-Falle

Bevor ich die Baseline abnahm, schickte ich sie durch drei unabhängige Gutachter mit unterschiedlichen Prüffragen. Kein Echo aus demselben Prompt, sondern verschiedene Beweispfade. Alle drei kamen auf fail, mit Konfidenz um 86 bis 88. Und sie fanden, über getrennte Wege, denselben Defekt.

Die OpenSubtitles-Quelle hatte mir Synchron-Deutsch untergeschoben. Untertitel und Synchronfassungen aus englischen Filmen sind kein natürliches Deutsch, sie sind übersetztes Englisch mit deutschen Vokabeln. Im Korpus stand sir ganz oben, 71 Bigramme bei einer Frequenz von 460.755. Daneben Calques wie „fahr zur hölle“, eine Eins-zu-eins-Übertragung von go to hell, die so im echten deutschen Sprachgebrauch kaum vorkommt.

Eine Bauchrednerpuppe hat die Sprechblase über dem Kopf, deren Schwanz auf den Mann dahinter zeigt.
Die Stimme gehört nicht zum Körper. So sieht Synchron-Deutsch im Korpus aus.

Diese Wörter tarnten sich als Muttersprache. Sie standen in einem deutschen Korpus, also galten sie für den Detektor als natürliches Deutsch, und hätten dem Modell beigebracht, Synchron-Artefakte für guten Stil zu halten. Genau das, was ich verhindern wollte, hätte mein eigenes Lineal mir antrainiert.

Meine Reaktion war der ganze Befund in fünf Worten.

„sir und fahr hölle ist kein deutsch wtf.“5

Eben. Und das war kein Bug, den man mit einem Filter wegpatcht. Das war ein Konstruktionsfehler an der Wurzel des Projekts. Wenn das Lineal falsch ist, ist alles, was du damit misst, falsch. Also komplettes Baseline-Redesign. Ein expository-Register kam dazu, Wikipedia-DE plus wissenschaftliche Texte, gegen das Sachtext überhaupt erst fair messbar wird. Dazu ein Calque-Filter, der die sir-Bigramme auf null zog, und die Plenar-Header der Parlamentsprotokolle per Regex gestrippt, wieder an der Ursache statt am Symptom. Die Frequenz-Spitze fiel von 787k auf 62k, der Korpus war nicht mehr von einem einzigen Artefakt monopolisiert.

Danach zogen alle drei Gutachter ihr fail zurück. Eine Lektion, die teurer gewesen wäre, hätte ich sie erst nach dem Training gelernt. Die nächste harte Frage stellte ich mir dann selbst.

Floskel oder Fachbegriff

Sie löste den eigentlichen Durchbruch aus.

Ich generierte Marketing-Copy über 15 Branchen, um daraus die Slop-Kandidaten zu ziehen. Das Problem dabei: Ich maß gegen eine dialogisch-literarische Baseline, die kein Produkt- oder Marketing-Register kennt. Die sieht einen korrekten Fachbegriff, sagen wir „Wärmepumpe“ oder „Sprecher-Diarisierung“, genauso fremd wie eine hohle Floskel. Beide fehlen im Lineal, also markiert der naive Detektor beide als Slop. Ein Filter, der Fachbegriffe wegwirft, ist aber nutzlos.

Der Knoten war der hier.

„das sind ja Fachbegriffe die richtig sind und rein müssen, ich weiß bloß nicht wogegen wir messen.“5

Daraus fiel der Groschen. Der echte Diskriminator ist nicht „fehlt in der Baseline“, sondern Branchen-Spread. Eine Floskel ist branchenunabhängig. „legen größten Wert“, „ganzheitlicher Ansatz“, „mit Rat und Tat“ tauchen beim Dachdecker so auf wie bei der Steuerkanzlei wie bei der Softwarefirma. Ein echter Fachbegriff dagegen lebt in genau einer Branche. Streut ein N-Gramm über viele der 15 Branchen, ist es Floskel-Treibstoff. Klebt es in einer, ist es ein Fachbegriff, der bleiben muss.

Spread-sortiert stand der branchenübergreifende Slop sauber oben in der Liste, die Fachbegriffe fielen nach unten weg. Aus 1472 Kandidaten-Prompts wurden 1380 saubere. Als Sicherheitsnetz lief ein Hand-Review darüber. Ich kuratierte die Grenzfälle selbst und verteidigte dabei dieselben lebendigen Phrasen, die schon in Teil 2 gegen das Über-Bannen standen. Slop ist die leere Hülle, nicht das lebendige Wort.

Die Pipeline in einem Absatz

So greift alles ineinander. gemma generiert deutsche Website-Copy über die 15 Branchen. Ein N-Gramm-Diff vergleicht diesen Output gegen das selbst destillierte deutsche Baseline-Profil und zieht die über-frequenten, branchenbreiten Muster heraus, daraus wird die Slop-Banlist. Ja, das ist genau die feste Liste, die ich in Teil 2 selbst verdächtig genannt habe. Für dieses Kapitel hält sie. Dann läuft der antislop-Sampler mit Backtracking.3 Beim Generieren weist er ein Slop-Token zurück, springt zurück und wählt eine natürliche Alternative, und aus genau diesen Paaren (rejected vs. chosen) entstehen die FTPO-Präferenzpaare. Auf denen trainiert das LoRA. Aus 1380 Prompts kamen nach Quota-Sampling 3778 FTPO-Rows. Das Backtracking ist auch der Grund, warum der Schritt zwingend auf eigener GPU laufen muss. Ein normaler Inferenz-Endpoint kann nicht mitten im Token-Stream zurückspringen.

Das Ergebnis, Seite an Seite

Als Test nahm ich Raven, meine Meeting-Plattform. Ein Glücksfall, denn Raven war im Prompt-Grid als profiling:false markiert und lag damit nie im Trainingsmaterial. Ein ungeleakter Holdout, der zugleich der echte Anwendungsfall ist. Baseline-gemma und das FTPO-Modell schrieben dieselben acht Sektionen, gleicher Seed pro Prompt, faire Bedingung.

Der klarste Gewinn steckt in einem Halbsatz. Die Baseline schrieb „plant Meetings im Gespräch (mit deinem Kalender, vier Providern)“, das FTPO-Modell schrieb:

„Dein Agent organisiert deinen Kalender (Google, Outlook, iCloud, Exchange), direkt im Gespräch.“

„Vier Providern“ ist eine Zahl, die nichts sagt. Vier Namen kann man nachschlagen und mir widersprechen. Genau das soll Copy tun.

Bei ganzen Sektionen wird es unschärfer. Die Hero-Section, Baseline-gemma:

„Meetings. Neu definiert. Raven ist die Meeting-Plattform, die Ihren gesamten Meeting-Lebenszyklus abdeckt, von der Planung bis zur Analyse.“

„Neu definiert.“ „Abdeckt.“ „Lebenszyklus.“ Lehrbuch-Slop: hohle Behauptung, kein Inhalt, austauschbar gegen jede beliebige SaaS-Startseite. Dasselbe Modell nach dem Training, derselbe Prompt:

„Meetings, denen ihr vertrauen könnt. … Keine Cloud-Abhängigkeit, keine Kompromisse.“

Direkter, mit Haltung statt Phrase. Ich habe dieses Paar wochenlang als Beleg herumgezeigt. Dann las ich den zweiten Satz noch einmal. „Keine Kompromisse“ ist nach meiner eigenen Definition aus Teil 2 eine leere Beteuerung, sie behauptet Qualität, ohne sie zu zeigen, und passt auf jedes Produkt der Welt. „Denen ihr vertrauen könnt“ behauptet Vertrauen, statt einen Grund dafür zu liefern. Mein Nachher-Beispiel besteht meinen eigenen Test nicht.

Das sind Einzelbeispiele, gut zum Anschauen, aber kein Beweis. Quantifiziert habe ich den Effekt auf dem vollen Holdout, und da fiel der Phrasen-Slop von 45,3 auf 3,75 Treffer pro 1.000 Tokens, minus 92 Prozent.5 Wichtiger noch, und das ist der eigentliche FTPO-Beweis, blieben die Fähigkeiten erhalten. GSM8K und MMLU lagen vor dem Training bei 87 und 68 Prozent, danach bei 86 und 68. Slop runter, ohne dass das Modell dümmer wird. Genau das, was DPO nicht garantiert.

Zweiundneunzig Prozent weniger Slop, die Fähigkeiten erhalten, auf Copy, die das Modell nie gesehen hatte, im echten Zielregister. Das war die Zahl, auf die ich seit Session eins hingearbeitet hatte. Sie leuchtete grün.

Was die Zahl nicht gemessen hat

Also zählte ich nach, was das Modell stattdessen schreibt. In den 36 Texten des Holdouts steht „maximal“ auf der FTPO-Seite 59-mal, auf der Baseline-Seite einmal. „absolut“ 55-mal gegen fünf. Und in den Taglines steht „Absolut kristallklar“, ausgerechnet das Wort, das ich in Teil 2 gegen das Über-Bannen verteidigt habe.5

Ein Pfeil steckt in einer Bretterwand, ein Maler auf einer Leiter malt die Zielscheibe erst nachträglich darum herum.
Der Pfeil steckt zuerst, die Scheibe kommt danach. So entstehen perfekte Zahlen.

Die Banlist war eingehalten. Die 92 Prozent stimmen. Sie messen nur, was auf der Liste steht, und der Slop war dorthin gewandert, wo die Liste nicht hinsieht. Die Zahl war nicht falsch, sie war blind.

Damit stand die Frage, die ich seit Session eins umgangen hatte. Wenn eine feste Liste den Slop nur verschiebt, statt ihn zu entfernen, was bringt sie dann? Darüber geht Teil 4.