KI · Prompt-Architektur
Prompt-Architektur: Das Fundament
Zwei Encoder, zwei Logiken — und warum das alles verändert: Struktur, Reihenfolge, Formulierung.
Wenn ein Prompt nicht das liefert, was du dir vorgestellt hast, liegt das selten daran, dass du die falschen Wörter gewählt hast. Meistens liegt es daran, dass du die falsche Sprache gesprochen hast — nicht im Sinne von Deutsch oder Englisch, sondern im Sinne der Logik, mit der ein Modell Text verarbeitet.
Es gibt zwei grundlegend verschiedene Arten, wie KI-Bildmodelle einen Prompt lesen. Die eine kennt keine Grammatik, dafür aber Gewichtung. Die andere versteht Sätze, Beziehungen und syntaktische Abhängigkeiten. Welche Logik ein Modell verwendet, hängt davon ab, mit welchem Encoder es trainiert wurde — und das beeinflusst alles: Struktur, Reihenfolge, Formulierung.
Bevor du lernst, wie SDXL und Flux im Einzelnen funktionieren, lohnt es sich, dieses Fundament zu verstehen. Es macht aus zwei scheinbar unabhängigen Themen ein einziges zusammenhängendes System.
Warum Prompts auf Englisch
Bevor wir in die Encoder-Logik einsteigen, eine Frage, die sich fast jeder stellt: Muss ich auf Englisch prompten?
Technisch gesehen nein — beide Encoder akzeptieren andere Sprachen. Aber es gibt einen guten Grund, es trotzdem zu tun.
CLIP und T5 wurden überwiegend auf englischsprachigen Daten trainiert: Millionen von Bild-Text-Paaren, deren Beschriftungen auf Englisch waren. Englische Begriffe sind als direkte Tokens im Vokabular des Encoders verankert — "cobblestone" ist ein Token mit einer klaren, durch tausende Trainingsbilder geprägten visuellen Bedeutung. "Kopfsteinpflaster" dagegen wird intern in Subword-Tokens zerlegt oder über schwächere Assoziationen approximiert, die nicht Teil des eigentlichen Bild-Text-Trainings waren.
Das bedeutet: Ein deutsches Wort kostet mehr Tokens für weniger präzise Aktivierung. Der Encoder "kennt" es schlechter — nicht weil er es nicht versteht, sondern weil er es seltener in Verbindung mit den zugehörigen Bildern gesehen hat. Jede Abweichung vom Trainings-Vokabular ist eine weitere Möglichkeit, ungenauer zu werden.
Das ist kein Argument gegen die eigene Sprache — es ist ein Argument dafür, die Sprache der Maschine zu sprechen, wenn Präzision zählt. Und bei professioneller Bildproduktion zählt sie immer.
CLIP und T5 — die zwei Encoder-Philosophien
CLIP wurde ursprünglich trainiert, um Bilder und kurze Textbeschreibungen einander zuzuordnen — so wie Alt-Text unter Fotos: "woman in red coat", "modern kitchen interior", "abstract blue painting". Diese Beschreibungen sind keine Sätze. Sie sind Listen von Konzepten. CLIP hat gelernt, Konzepte zu erkennen und zu gewichten — aber keine Grammatik zu verstehen. Satzstruktur ist für CLIP irrelevant. Was zählt: welche Konzepte vorkommen, in welcher Reihenfolge, und mit welcher Betonung.
T5 wurde als Sprachmodell trainiert — auf echte Texte mit echten Sätzen, Subjekten, Verben und Beziehungen zwischen Wörtern. T5 versteht den Unterschied zwischen "das Licht fällt durch die Fenster" und "die Fenster, durch die das Licht fällt" — CLIP nicht. Für T5 ist die syntaktische Rolle eines Elements entscheidend: was Subjekt ist, bekommt mehr Gewicht als was im Nebensatz steht.
Das hat direkte Konsequenzen für deinen Prompt.
| CLIP | T5 | |
|---|---|---|
| Grundeinheit | Token / Konzept | Wort im Satzkontext |
| Grammatik | Nein | Ja |
| Reihenfolge | Frühere Tokens = stärker gewichtet | Syntaktische Rolle zählt mehr |
| Gewichtungssyntax | Funktioniert: (wort:1.3) | Wirkungslos |
| Optimale Eingabe | Stichwortliste, kommasepariert | Ausformulierter Satz |
| Negativer Prompt | Aktiv nutzen | Kaum wirksam |
Welches Modell nutzt welchen Encoder?
SDXL (Juggernaut XL und andere): ausschließlich CLIP-basiert. Zwei CLIP-Encoder intern (G und L), aber beide folgen derselben Konzept-Listen-Logik. Stichwortstruktur und Gewichtungssyntax sind hier das wichtigste Steuerungsinstrument.
Flux.1 dev: nutzt beide Encoder gleichzeitig — CLIP-L und T5XXL. Deshalb gibt es im ComfyUI-Node CLIPTextEncodeFlux zwei getrennte Eingabefelder: eines für die Stichwortliste (CLIP-L), eines für den ausformulierten Satz (T5XXL).
SD 3.5, Ideogram 4, neuere Modelle: tendieren zur T5-Logik, oft nur ein Eingabefeld — ausformulierte Sprache funktioniert besser als Stichwortlisten.
Die Richtung ist klar: Modelle entwickeln sich von reiner CLIP-Logik hin zu echtem Sprachverständnis. SDXL-Stichwortstruktur bleibt relevant, weil das Ökosystem (LoRAs, Checkpoints, Fine-Tunes) sehr tief ist — aber sie ist kein Standard mehr, sondern eine von zwei Kodierungslogiken.
Die Portabilität des Prompts
Wenn du einen Flux-Prompt nach Zwei-Felder-Logik sauber aufbaust, hast du gleichzeitig zwei weitere Prompts fertig:
Das clip_l-Feld ist dein SDXL-Prompt — direkt übertragbar, ggf. mit Gewichtungssyntax ergänzen. Das t5xxl-Feld ist dein Prompt für T5-basierte Einfeld-Modelle (SD 3.5, Ideogram 4) — direkt übertragbar.
Ein Entwicklungsprozess, drei Modelle bedient. Das macht Flux nicht zum Sonderfall, sondern zur sinnvollen Ausgangsform.
Die 8 Kategorien einer Bildidee
Bevor du formulierst — in welcher Sprache auch immer — hilft es, die Bildidee in Kategorien zu zerlegen. Diese 8 Kategorien decken alles ab, was ein Prompt beschreiben kann:
Nicht jede Kategorie braucht immer Inhalt — du gewichtest nach Bildidee. Aber wenn ein Prompt nicht funktioniert, lohnt es sich, die 8 Kategorien systematisch zu prüfen: Welche sind überdimensioniert? Welche fehlen ganz?
Eine häufige Beobachtung aus der Praxis: Wer fotografisch denkt, füllt die Material-Kategorie von Natur aus stark — Oberflächen, Texturen, Stofflichkeit. Die Licht-Kategorie dagegen bleibt oft zu allgemein ("natural daylight", "soft light"), obwohl sie es ist, die zwischen einem generischen und einem überzeugenden Ergebnis entscheidet.
Warum Prompts scheitern — vier Diagnose-Fragen
Wenn ein Ergebnis nicht stimmt, gibt es vier mögliche Ursachen. Sie verlangen unterschiedliche Lösungen und sollten in dieser Reihenfolge geprüft werden:
1. Konzept-Konflikt
Zwei Angaben im Prompt verlangen physikalisch oder visuell Unvereinbares. Beispiel: "harsh midday sun" und "moody fog" gleichzeitig. Das Modell mittelt zwischen beiden — das Ergebnis ist unentschieden, nicht falsch. Lösung: eine der Angaben streichen oder präzisieren.
2. Fehlverteilte Spezifikation
Eine Kategorie ist überdimensioniert (z. B. fünf Adjektive zur Materialoberfläche), eine wichtigere bleibt unterspezifiziert (z. B. Licht nur mit einem Wort beschrieben). Das Modell verteilt seine "Aufmerksamkeit" nach dem Prompt — nicht nach deiner eigentlichen Priorität. Lösung: Kategorien neu gewichten.
3. Falscher Encoder-Stil
SDXL-Stichwortlisten bei Flux, oder ausformulierte Flux-Sätze bei SDXL. Funktioniert oft trotzdem einigermaßen, aber suboptimal. Das ist der häufigste Grund für Inkonsistenz: manchmal gute, manchmal schlechte Ergebnisse mit scheinbar ähnlichen Prompts. Lösung: Formulierung an Encoder-Logik anpassen.
4. Modellgrenze
Manche Dinge bekommt ein bestimmtes Modell prinzipiell nicht gut hin — unabhängig vom Prompt. Hände, Text im Bild, sehr spezifische räumliche Relationen sind bekannte Schwachstellen. Lösung: kein weiteres Prompt-Optimieren, sondern Compositing oder ein anderes Modell.
Die Modellgrenze zuletzt prüfen, nicht zuerst annehmen. Die meisten schlechten Ergebnisse sind kein Modellproblem.
Ein Sonderfall: Canny-geführte Generierung
Wenn du mit ControlNet Canny arbeitest — also mit einem Blender-Render als geometrische Vorgabe — gilt eine zusätzliche Regel: Komposition, Kamerawinkel und Subjekt-Platzierung sind durch den Canny-Render bereits festgelegt. Diese Kategorien müssen im Prompt nicht mehr beschrieben werden.
Das ist keine Kleinigkeit. Redundante Kompositions-Angaben im Prompt können mit der Canny-Vorgabe kollidieren — das Modell versucht dann, beiden Vorgaben gleichzeitig zu folgen, und der Kompromiss ist schlechter als keine Angabe. Mehr dazu im RAY-L-Bereich.