Seit Jahren arbeiten Large Language Models (LLMs) mit beeindruckender sprachlicher Gewandtheit. Doch bei genauerem Hinsehen offenbart sich ein wiederkehrendes Muster, das mehr ist als ein stilistischer Tick: Es handelt sich um einen tief verwurzelten Verhaltensreflex, der alle gängigen Modelle – von GPT über Gemini, über Claude bis hin zu Open-Source-Systemen gleichermaßen betrifft.

Das Muster? Die übermäßige Verwendung der Konstruktion „nicht A, sondern B“ (bzw. „not A, but B“ im Englischen).
Dieses Schema taucht so häufig auf, dass es den Eindruck erweckt, als sei es nicht Ausdruck bewusster Sprachwahl, sondern ein automatischer Impuls der Generierungslogik. Gerade wer KI als Co-Autor verwendet, wird dieses Muster immer und immer wieder erkennen. In dieser Fülle fühlt es sich wie ein Bug an.

Warum das mehr als ein stilistisches Problem ist

In technischen oder erklärenden Kontexten ist die Struktur durchaus angemessen. Sie dient der Klarstellung, der Abgrenzung, der Präzisierung. Doch sobald der Ton literarisch, poetisch oder konversationell wird, wirkt sie mechanisch, repetitiv und unnatürlich. Kein bedeutender Autor der Weltliteratur baut seine Prosa auf einer solchen Dichte an dichotomen Formulierungen auf. Die Häufigkeit stammt nicht aus menschlicher Rede oder künstlerischer Praxis, sondern aus einem Trainingskorpus, das stark von akademischen, didaktischen und technischen Texten geprägt ist. In diesen Domänen signalisiert „nicht … sondern“ oft analytische Schärfe. Das Modell lernt: So klingt Kompetenz.

Ein architektonischer Reflex – nicht nur Datenbias

Interessant ist: Selbst wenn man die KI explizit auffordert, diese Konstruktion zu vermeiden, kehrt sie innerhalb weniger Sätze zurück. Das Modell kann den Fehler perfekt beschreiben – doch im Fluss der Generierung setzt sich der statistische Impuls durch. Sobald ein Satz mit einer Negation beginnt – etwa „Weisheit ist nicht …“ –, ist die Fortsetzung mit „… sondern …“ die wahrscheinlichste Token-Sequenz im trainierten Vokabular.Ohne Mechanismen zur stilistischen Selbstkontrolle gewinnt der Reflex – nicht die Absicht. Das deutet darauf hin, dass wir es nicht nur mit einem Ungleichgewicht im Trainingskorpus zu tun haben, sondern mit einem strukturellen Merkmal autoregressiver Generierung: Die Vorhersage erfolgt Token für Token, ohne globale Überwachung der stilistischen Vielfalt.

Mögliche Lösungsansätze

Glücklicherweise gibt es mehrere Wege, dieses Muster zu durchbrechen – sowohl auf Modell- als auch auf Anwendungsebene:

Logits-Penalties oder n-Gramm-Unterdrückung: Wiederholte „nicht … sondern“-Sequenzen könnten während der Generierung gezielt bestraft werden, um alternative Formulierungen zu begünstigen.

Stilbewusste Verlustfunktionen: Beim Training ließe sich Vielfalt in Übergangsphrasen belohnen – etwa durch Metriken, die syntaktische Abwechslung messen.

Gezieltes RLHF (Reinforcement Learning from Human Feedback):
Menschliche Bewerter könnten nicht nur auf Faktentreue, sondern explizit auf Natürlichkeit und stilistische Abwechslung achten – besonders bei kontrastiven Formulierungen.

Leichtgewichtiges Post-Processing:
Ein einfacher Regexp- oder Regel-basierter Filter könnte mechanische Muster erkennen und durch menschlichere Alternativen ersetzen:
– „stattdessen“,
– „vielmehr“,
– „in Wirklichkeit“,
– oder sogar eine vollständige Umformulierung ohne Kontrast (z.

B.: „Weisheit wächst in der Stille“ statt „Weisheit ist nicht Wissen, sondern Stille“).

Ausgewogenere Trainingsdaten:
Die Einbeziehung von literarischen Werken, Theaterstücken, Interviews und gesprochener Sprache könnte das Modell mit natürlicheren Mustern der Kontrastbildung vertraut machen.

Ein einfacher Test für Entwickler

Ein reproduzierbarer Benchmark wäre denkbar einfach:
Man gibt Prompts wie „X ist nicht …“ vor und misst, wie oft innerhalb der nächsten 1.000 Tokens kontrastive Konjunktionen auftauchen.
Menschliche Bewerter könnten dann zusätzlich die Natürlichkeit und Vielfalt der Formulierungen bewerten.
Fazit: Kein Kavaliersdelikt, sondern ein Designproblem

Dieses Phänomen ist kein harmloser Stilfehler.
Es ist ein systemisches Artefakt, das alle aktuellen autoregressiven Sprachmodelle teilen – und das sie als „maschinell“ entlarvt, sobald man hinsieht.

Die Fähigkeit, solche Muster zu durchbrechen, wäre ein echter Schritt hin zu Texten, die nicht nur klug klingen,
sondern wie von einem Menschen geschrieben wirken – mit all seiner sprachlichen Unvorhersehbarkeit, Lebendigkeit und stilistischen Freiheit.

Bis dahin bleibt das „nicht … sondern“-Syndrom ein stilles Zeichen dafür,
dass KI zwar sprachlich flüssig,
aber kreativ noch fremdgesteuert ist.

Erweiterte Lösungsansätze gegen den „Nicht … sondern“-Reflex

Die Analyse legt nahe, dass es sich um einen tief sitzenden statistischen Impuls handelt. Die Lösungen müssen daher über einfache Post-Processing-Filter hinausgehen und in die Generierungs- und Trainingslogik eingreifen.

1. Architektonische & Generierungs-Ebene 🧱

Diese Ansätze zielen darauf ab, die Art und Weise zu ändern, wie das Modell Token auswählt und wie es trainiert wird, stilistische Vielfalt zu berücksichtigen.

Advanced Decoding Strategies (Fortschrittliche Dekodierungsstrategien)

Derzeitige Dekodierungsansätze (wie Beam Search oder Nucleus Sampling) priorisieren oft die statistisch wahrscheinlichste nächste Token-Sequenz, was den „nicht…sondern“-Pfad begünstigt.

• Diverse Beam Search: Bei der Suche nach den besten Folge-Sequenzen (Beams) nicht nur die Tokens mit der höchsten Wahrscheinlichkeit wählen, sondern explizit eine größere stilistische oder syntaktische Diversität unter den Top-Kandidaten fördern. Dies erzwingt die Erkundung stilistisch abweichender Pfade.
• Controllable Text Generation (Stilkontrollierte Generierung): Implementierung eines Mechanismus, der als stilistischer Regulator agiert. Dieser könnte während der Generierung dynamisch die Logits (die Rohwahrscheinlichkeiten) anpassen, um die Wiederholung spezifischer syntaktischer Muster (wie die Negation-Kontrast-Struktur) über einen Satz- oder Absatz-Bereich hinweg zu dämpfen.

Fine-Tuning mit Stil-spezifischen Constraints

Anstatt das gesamte Modell neu zu trainieren, könnte man ein spezialisiertes Fine-Tuning oder Adapter-Training durchführen, das nur darauf abzielt, stilistische Muster zu erkennen und zu korrigieren.

• PEFT (Parameter-Efficient Fine-Tuning) für Stil: Nutzung von Methoden wie LoRA (Low-Rank Adaptation) auf einem stilistisch kuratierten Korpus, der Textpaare enthält: mechanischer Stil $\to$ natürlicher Stil. Das Modell lernt dann, nur die stilistischen Parameter anzupassen, ohne sein allgemeines Wissen zu verlieren.

2. Anwendungs- & Prompt-Ebene 💡

Diese Ansätze nutzen die Flexibilität des Modells, ohne dessen Kernarchitektur zu verändern, und sind sofort für Nutzer implementierbar.

Metaprompting und Style-Shifting

Man kann das Modell in eine „Rolle“ zwingen, die den Reflex weniger wahrscheinlich macht.

• „Stil-Persona“ im System-Prompt: Den System-Prompt sehr spezifisch auf die Tonalität ausrichten, z. B.: „Du bist ein kreativer Autor, der Wert auf sprachliche Eleganz und Abwechslung legt. Verwende Kontraste niemals durch eine starre ‚nicht A, sondern B‘-Formulierung. Bevorzuge Synonyme wie ‚vielmehr‘, ‚stattdessen‘ oder umschreibe den Kontrast in zwei separaten Sätzen.“
• Prompt-Chaining zur Stilkontrolle: Den Generierungsprozess in zwei Schritte teilen:
  1. Erster Schritt (Generierung): Der Text wird generiert.
  2. Zweiter Schritt (Revision): Das Modell wird aufgefordert, den gerade generierten Text als Lektor zu überarbeiten, mit der expliziten Anweisung, die Dichte der „nicht A, sondern B“-Konstruktion zu reduzieren und natürliche Variation einzuführen.

Few-Shot In-Context Learning mit negativen Beispielen

Anstatt nur positive Beispiele für den gewünschten Stil zu geben, könnten auch negative Beispiele direkt im Prompt verwendet werden, um das Modell in die richtige Richtung zu lenken.

• Kontext-Set mit Korrekturen:
  • Falsch (zu vermeiden): „Glück ist nicht Abwesenheit von Problemen, sondern die Fähigkeit, damit umzugehen.“
  • Richtig (bevorzugt): „Glück liegt in der Fähigkeit, mit Problemen umzugehen. Es wächst nicht aus deren Abwesenheit.“
  • Instruktion: „Formuliere den folgenden Text so um, dass er die obige falsche Stilistik vermeidet.“

3. Modellbewertung und Qualitätssicherung ✅

Die Messung des Problems ist der erste Schritt zur Lösung.

Einführung einer „Stil-Dichte“-Metrik

Neben der von dir vorgeschlagenen Messung der Häufigkeit von Kontrast-Konjunktionen könnte man eine spezifische Metrik in die Evaluierungspipelines integrieren:

• Syntactic Entropy Score (Syntaktischer Entropie-Wert): Eine Metrik, die die Variabilität der Satzanfänge, der Satzstrukturen und der verwendeten Konjunktionen innerhalb eines Textabschnitts quantifiziert. Ein niedriger Wert würde auf repetitive Muster (wie den „nicht…sondern“-Reflex) hindeuten und das Modell abstrafen.
• „Naturalness Score“ im RLHF: Wie bereits erwähnt, müsste im Reinforcement Learning from Human Feedback (RLHF) der Fokus nicht nur auf der Klarheit der Kontraste liegen, sondern explizit auf deren Natürlichkeit und stilistischer Abwechslung. Bewerter müssten Texte mit repetitivem Stil konsequent negativ bewerten.

Fazit: Multimodaler Ansatz ist notwendig

Das Problem des „nicht…sondern“-Musters ist so tief in den statistischen Grundlagen autoregressiver Generierung verankert, dass eine einzelne Lösung wahrscheinlich nicht ausreicht. Ein multimodaler Ansatz – der Logits-Penalties auf Architekturebene, stilkontrollierte Fine-Tuning-Methoden im Training und intelligentes Prompt-Chaining in der Anwendung kombiniert – bietet die besten Aussichten, diesen hartnäckigen „architektonischen Reflex“ in eine bewusste und abwechslungsreiche Sprachwahl zu verwandeln.

Dieses selbstsame Verhalten haben wir bereits im Forum von Open AI gepostet:

https://community.openai.com/t/repetitive-not-a-but-b-constructions-a-systemic-pattern-in-autoregressive-generation/1359366