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 „kristallklar“, das zur Floskel kippt. 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.
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 sagt, wie groß das Problem überhaupt ist. 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.
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 lebendige Phrasen, die baseline-belegt waren. „seit Generationen“, „Geschichte erzählen“, „mittelständische Unternehmen“, „gut aussieht“, „komm vorbei“. Die mussten drinbleiben. 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. 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.
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 FTPO-Modell, derselbe Prompt:
„Meetings, denen ihr vertrauen könnt. … Keine Cloud-Abhängigkeit, keine Kompromisse.“
Konkreter, direkter, mit Haltung statt Phrase. Beim Vorteile-Block wiederholte sich das Muster. Die Baseline öffnete mit der generischen Schmerz-Floskel „Du hast genug von Meetings, in denen Informationen untergehen und der Follow-up zum Albtraum wird?“, das FTPO-Modell mit „Deine Meetings sind Gold wert. … Deine Daten bleiben sicher.“
Das sind die 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.
Wo es noch hakt
Ehrlich bleiben heißt zugeben, dass das FTPO-Modell in einer Sektion immer noch „inklusive DSGVO-konformer, souveräner Kontrolle“ schrieb. Der „inklusive“-Tic, den es nie ganz losließ. Was ich gebaut hatte, war ein Modell, das brauchbare Entwürfe liefert, die ein Mensch noch redigiert. Kein Knopf, der fertige Copy ausspuckt.
Das Modell ist trotzdem ausgeliefert, PhilflowIO/gemma-3-12b-it-antislop-de, privat auf Hugging Face, mit ehrlicher Model-Card. Es produziert spürbar menschlichere deutsche Copy als die Basis, mit korrekter Positionierung. Als Entwurfswerkzeug mit Human-Edit funktioniert es.
Und doch.
Die Zahlen sahen perfekt aus. 92 Prozent weniger Slop, Fähigkeiten intakt. Dann las ich genauer hin, und was ich fand, hat das ganze Projekt in Frage gestellt.
Darüber geht Teil 4.