Ich habe letzte Woche etwas Peinliches entdeckt.
Meine KI-Podcast-Pipeline hat einen ausgefeilten System-Prompt – einen „Dialog-Leitfaden" – an dem ich tagelang gearbeitet habe. Er sagt den Moderatoren (zwei KI-generierten Fußballkommentatoren) genau, wie sie miteinander reden sollen. Wiederhole nicht dieselbe Eröffnung. Variiere die Struktur zwischen den Segmenten. Verwende Catchphrases sparsam. Erfinde niemals Statistiken.
Das LLM hat jedes Wort gelesen. Und dann fast alles ignoriert.
Der vietnamesische Moderator sagte „Trời ơi" (Oh mein Gott) 13 Mal in einer einzigen Folge. Der japanische Moderator eröffnete jedes einzelne Segment mit „いやー、健一さん！" (Also, Kenichi-san!). Der englische Moderator zitierte mit absoluter Überzeugung xG 0,35 und 65 % Ballbesitz – Zahlen, die nirgendwo in meiner Datenbank existieren.
Der Prompt wurde höflich zur Kenntnis genommen. Und dann missachtet.
Das ist die mit Abstand nützlichste Erkenntnis, die ich über Prompt Engineering gewonnen habe: LLMs haben zwei Lesemodi, und sie behandeln sie völlig unterschiedlich.
Das Problem der zwei Lesemodi
So sah mein ursprünglicher Dialog-Leitfaden aus. Ich habe die vietnamesische Version ins Deutsche übersetzt, da die Struktur identisch ist:
STILVORGABEN:
INTERAKTIONSMUSTER DER MODERATOREN: Emotionaler Moderator + Analytischer Moderator.
STRENGE REGELN FÜR JEDES SEGMENT:
0. NIEMALS DIE GLEICHE ERÖFFNUNG WIEDERHOLEN. Variiere, welcher Moderator
beginnt und auf welchen Spielmoment sie zuerst reagieren.
1. EMOTIONALER START (verpflichtend): Jedes Segment beginnt mit
der puren Reaktion des emotionalen Moderators.
2. DATEN-VERANKERUNGSREGEL (verpflichtend): Jede Behauptung muss
konkrete Zahlen nennen. Nicht „sie haben dominiert", sondern
„61 % Ballbesitz, 3,17 xG zu 0,65."
3. CATCHPHRASES:
Emotionaler Moderator: „Hast du das gesehen?!" „Warte warte warte..."
Analytischer Moderator: „Es gibt einen tieferen Grund..." „Lass es mich dir erklären."
Sieht gründlich aus, oder? Ich dachte wirklich, ich hätte die Arbeit gemacht.
Aber als ich die tatsächlich generierten Skripte las, passierte Folgendes:
| Regel | Was der Leitfaden sagte | Was das LLM tat |
|---|---|---|
| Regel 0 (niemals wiederholen) | Variiere die Eröffnung | Jedes Segment begann mit der Catchphrase des emotionalen Moderators |
| Regel 2 (Daten) | Nenne konkrete Zahlen | Nannte erfundene Zahlen mit absoluter Autorität |
| Regel 3 (Catchphrases) | Liste charakteristischer Phrasen | Verwendete jede Phrase 5–13 Mal pro Folge |
Die Regeln waren da. Das LLM hat sie gelesen. Aber sie hatten die Durchschlagskraft einer Empfehlung, nicht einer Anforderung.
Da begriff ich: Das LLM verarbeitete meine Regeln als „Stil-Kontext" – nicht als „durchsetzbare Einschränkungen".
Das Muster: Kontext vs. Befehl
Überleg mal, wie du verschiedene Textsorten liest. Wenn ich dir eine Restaurantkarte gebe, liest du sie als Handlungsinformation. Wenn ich dir einen Wikipedia-Artikel über die Geschichte der Pasta gebe, liest du ihn als Hintergrundwissen.
LLMs machen etwas Ähnliches mit Prompts. Wenn Regeln in einem Abschnitt mit der Überschrift „STILVORGABEN" oder „INTERAKTIONSMUSTER DER MODERATOREN" oder „REGELN FÜR SEGMENTE" erscheinen, behandelt das Modell sie als Umgebungsinformation – Kontext, der die Antwort einfärbt, aber nicht einschränkt.
Wenn Regeln in einem Abschnitt mit der Überschrift „KRITISCHE ERFORDERLICHE VERBESSERUNGEN" oder „SPEZIFISCHE PHRASEN-LIMITS" erscheinen, behandelt das Modell sie als durchsetzbare Befehle – Dinge, die es prüfen und korrigieren muss.
Die Erkenntnis liegt nicht in den Wörtern „kritisch" oder „erforderlich". Sie liegt darin, wo in der Pipeline die Regel lebt.
Die Lösung: Lass den Review-Schritt durchsetzen, was der Generierungsschritt ignoriert
Meine Pipeline hat zwei LLM-Aufrufe:
- Generierungsschritt – schreibt das Skript Segment für Segment, mit dem Dialog-Leitfaden als Kontext
- Review-Schritt – liest das gesamte zusammengesetzte Skript und verbessert es
Im Generierungsschritt lebten all meine Regeln. Der Review-Schritt hatte generische Anti-Wiederholungs-Regeln („sag nicht zweimal 'Das ist faszinierend'"), die komplett englisch-zentriert waren und nichts über die Catchphrases meiner Moderatoren oder die strukturellen Anforderungen wussten.
Die Lösung war strukturell, nicht sprachlich. Ich verschob die Durchsetzung in den Review-Schritt, wo das gesamte Skript auf einmal sichtbar ist.
Das hat sich geändert:
Vorher: Regeln im Generierungs-Prompt (ignoriert)
STILVORGABEN:
0. NIEMALS DIE GLEICHE ERÖFFNUNG WIEDERHOLEN...
1. EMOTIONALER START...
2. DATEN-VERANKERUNG...
3. CATCHPHRASES: „Hast du das gesehen?!" ...
Nachher: Regeln extrahiert und in den Review-Prompt eingefügt (durchgesetzt)
KRITISCHE ERFORDERLICHE VERBESSERUNGEN IM GESAMTEN SKRIPT:
2a. SETZE DIE STRUKTURELLEN REGELN DER STILVORGABEN DURCH:
Die obigen STILVORGABEN enthalten spezifische Anforderungen
zur Segmentstruktur. Dies sind ANFORDERUNGEN, keine Vorschläge.
- Wenn die Vorgaben sagen „X von Y Segmenten müssen variieren",
ÄNDERE Segmente, die dagegen verstoßen.
- Prüfe, wie JEDES Segment beginnt. Wenn 4+ von 5 identisch beginnen,
VARIIERE mindestens 2.
3b. LOCALE-SPEZIFISCHE PHRASEN-LIMITS (aus den Moderator-Profilen extrahiert –
MAXIMAL 2 MAL pro Phrase im gesamten Skript):
- „Trời ơi" / „Trời má" – max. 4x kombiniert
- „Có một lý do sâu hơn" – max. 2x
- „Mày thấy chưa?!" – max. 2x
...
Zwei Dinge sind hier passiert:
-
Die strukturellen Regeln wurden von Kontext zu Befehl hochgestuft – umformuliert als „SETZE dies DURCH" und „ÄNDERE Segmente, die dagegen verstoßen" statt „hier ist das bevorzugte Muster"
-
Die Catchphrases wurden aus den Moderator-Profilen extrahiert und als explizite Limits dargestellt, nicht als Liste von Vorschlägen. Aus „Catchphrases: hier sind ein paar" wurde „Diese Phrasen: MAXIMAL 2 MAL."
Beide Änderungen leben im Review-Prompt, nicht im Generierungs-Prompt. Das ist die entscheidende architektonische Entscheidung. Der Generierungsschritt bekommt den Stilleitfaden als Kontext – er braucht den Persönlichkeits-Geschmack. Der Review-Schritt bekommt die Regeln als Durchsetzungsmandat – er braucht den Compliance-Auftrag.
Das Extraktions-Detail (warum das in 7 Sprachen funktioniert)
Ich wollte keine sprachspezifischen Phrasenlisten per Hand pflegen. Jedes Mal, wenn ich ein Moderator-Profil anpasste, müsste ich auch den Review-Prompt aktualisieren. Das ist genau die Art von Drift, die das Produkt eines Solo-Entwicklers killt.
Stattdessen schrieb ich eine kleine Extraktionsfunktion, die die Moderator-Profile zur Review-Zeit parst. Jedes Locale-Profil hat einen Catchphrase-Abschnitt mit einem Standard-Label:
- Vietnamesisch:
Câu cửa miệng: - Japanisch:
口癖: - Spanisch:
Latiguillos: - Französisch:
Phrases fétiches: - Koreanisch:
입버릇: - Chinesisch:
口头禅:
Die Funktion findet dieses Label, extrahiert alle darauf folgenden Strings in Anführungszeichen und formatiert sie als durchsetzbare Limits:
@staticmethod
def _extract_catchphrase_limits(host_profiles: str) -> str:
patterns = [
(r'Câu cửa miệng:?', r'"([^"]+)"'), # Vietnamese
(r'口癖:?', r'「([^」]+)」'), # Japanese
(r'Latiguillos:?', r'"([^"]+)"'), # Spanish
# ... etc for all 7 languages
]
limits = []
for marker_pattern, quote_pattern in patterns:
match = re.search(marker_pattern, host_profiles)
if match:
phrases = re.findall(quote_pattern, host_profiles[match.end():])
for phrase in phrases:
limits.append(f' - "{phrase}" — max 2x')
return "\n".join(limits)
Wenn ich jetzt ein Moderator-Profil bearbeite und dessen Catchphrases ändere, aktualisiert sich der Review-Prompt automatisch. Keine Drift. Keine vergessene Sprache.
Was das tatsächlich behoben hat (mit Zahlen)
Hier ist, was sich zwischen der vor diesen Fixes generierten Folge und einer danach generierten geändert hat:
| Metrik | Vorher | Nachher |
|---|---|---|
| „Trời ơi"-Anzahl (Limit: max. 4) | 13 | Noch nicht in vi getestet, aber in ja: alle 4 Catchphrases innerhalb der Limits |
| „Có một lý do sâu hơn" (Limit: max. 2) | 5 | Innerhalb des Limits im entsprechenden ja-Test |
| Erfundene Statistiken (xG, Ballbesitz %, Formationsbreite) | 4 erfundene Zahlen | Null erfundene Zahlen |
| Segment-Eröffnungen mit identischem Muster | 6/6 identisch | Immer noch 5/5 in ja – siehe unten |
| Erhaltene Vietnam/Japan-Verbindungen | 1/4 überlebte (Review strich 3) | 11/11 überlebten |
| Verwischung der Moderatoren-Stimmen | Beide nutzten die Phrasen des anderen | Klare Trennung |
Die Catchphrase-Limits, die Anti-Erfindungs-Regeln und der Lokalisierungserhalt funktionierten alle. Die Moderator-Profile diktieren die Persönlichkeiten jetzt klar genug, dass das LLM nicht mehr verwechselt, wer was sagt.
Was immer noch nicht funktioniert
Eine Regel scheitert weiterhin: die strukturelle Vielfalt. Der Dialog-Leitfaden sagt: „mindestens 2 von 5 Segmenten müssen unterschiedliche strukturelle Einstiege verwenden." Nach den Fixes eröffnete die japanische Folge immer noch jedes Segment identisch: „いやー、健一さん！" – fünf Mal in einer Folge.
Das ist kein Prompt-Durchsetzungsproblem. Es ist ein Architekturproblem.
Der Generierungsschritt produziert jedes Segment unabhängig. Segment 3 hat keine Ahnung, dass Segment 1 und 2 mit der Catchphrase des emotionalen Moderators begannen. Jedes Segment wird isoliert mit demselben Dialog-Leitfaden generiert, also kommt jedes zur selben „lass uns mit dem emotionalen Moderator beginnen"-Entscheidung.
Der Review-Schritt sollte das erkennen – er sieht das gesamte Skript auf einmal. Und ich habe explizite Durchsetzungssprache hinzugefügt, die ihm sagt, die Eröffnungen zu variieren. Aber Gemini 3.5 Flash, das Modell für den Review, findet es anscheinend schwieriger, Segment-Eröffnungen umzustrukturieren, als Catchphrases zu kürzen oder erfundene Behauptungen abzuschwächen. Eröffnungsvielfalt erfordert das Neugenerieren von Inhaltsteilen, nicht nur Straffen oder Entfernen. Das ist ein größerer Aufwand für das Modell.
Ich arbeite noch daran – wahrscheinlich ein leistungsfähigeres Review-Modell oder eine Pipeline-Umstrukturierung, bei der Segmente den Eröffnungszustand teilen. Der übergeordnete Punkt: Prompt-Durchsetzung kann Architekturprobleme nicht beheben. Wenn die Struktur deiner Pipeline eine Regel unmöglich befolgbar macht, rettet dich keine Menge an „KRITISCH" oder „VERPFLICHTEND" in deinen Prompts.
Das Framework: Drei Fragen für jede Regel
Nach dieser Erfahrung auditiere ich jetzt jeden System-Prompt, den ich schreibe, mit drei Fragen:
1. Wo lebt diese Regel – Generierung oder Review? Regeln zu Persönlichkeit und Ton gehören in die Generierung. Regeln zu Compliance, Konsistenz und Struktur gehören in den Review. Wenn eine Regel beides betrifft (wie Catchphrases – sie sind Persönlichkeit, brauchen aber Limits), pack sie in beide.
2. Ist diese Regel als Kontext oder als Befehl formuliert? „Hier sind die Catchphrases" ist Kontext. „Maximal 2 Mal" ist Befehl. Beides wird für dieselbe Regel gebraucht – der Generierungsschritt muss wissen, WAS die Catchphrases SIND, und der Review-Schritt muss durchsetzen, WIE OFT sie erscheinen.
3. Kann die Pipeline diese Regel überhaupt befolgen? Segmentweise Generierung kann keine segmentübergreifende Vielfalt durchsetzen. Kein Prompt wird das beheben. Du musst entweder die Regel in den Review-Schritt verschieben (der das gesamte Skript sieht) oder die Pipeline so umstrukturieren, dass Segmente ihren Zustand teilen.
Dieses Framework ist nicht spezifisch für Podcast-Generierung. Es gilt für jede mehrschrittige LLM-Pipeline – Content-Generierung, Code-Review, Dokumentenzusammenfassung, überall, wo du getrennte Generierungs- und Qualitätskontroll-Durchläufe hast.
Ich iteriere noch daran, aber wenn du deine erste mehrschrittige LLM-Pipeline baust: Teile sie in mindestens zwei Schritte auf. Der erste Schritt generiert mit Persönlichkeit und Freiheit – gib ihm Kontext, Beispiele, Ton-Vorgaben. Der zweite Schritt reviewed mit Präzision und Durchsetzung – gib ihm explizite Limits, Compliance-Prüfungen und die Autorität, Dinge zu ändern.
Der Generierungsschritt sollte sich anfühlen wie ein Briefing mit einem kreativen Partner. Der Review-Schritt sollte sich anfühlen wie eine Checkliste, die du einem Lektor in die Hand drückst.
Und wenn deine Regeln immer noch ignoriert werden, nachdem du beides gemacht hast, stell zuerst die Architektur-Frage. Ist es der Prompt, oder ist es die Pipeline?
Häufig gestellte Fragen
Gilt das auch für ein Single-Prompt-Setup (ohne Pipeline)?
Ja, aber nur begrenzt. In einem einzigen Prompt bittest du dasselbe Modell, gleichzeitig kreativ und compliant zu sein – es wird immer Kreativität über Compliance stellen, wenn die beiden in Konflikt geraten. Selbst in einem einzelnen Prompt hilft es, deine Anweisungen in einen „Kontext"-Abschnitt und einen expliziten „Einschränkungen"-Abschnitt zu trennen. Aber du wirst an eine Decke stoßen. Zwei getrennte Aufrufe mit unterschiedlichen Anweisungen übertreffen fast immer einen einzigen.
Warum hast du die Regeln nicht einfach stärker in den Generierungs-Prompt gepackt?
Habe ich versucht. Ich habe „VERPFLICHTEND", „KRITISCH", „NIEMALS" und alles in Großbuchstaben hinzugefügt. Der Generierungsschritt hat zu viele konkurrierende Anforderungen – er versucht gleichzeitig, fesselnd, natürlich klingend, abwechslungsreich, lokal authentisch und compliant zu sein. Wenn das Modell wählen muss zwischen „klinge wie ein aufgeregter vietnamesischer Fußballfan" und „sage 'Trời ơi' nur zweimal", gewinnt immer die Persönlichkeit. Der Review-Schritt hat diesen Konflikt nicht – sein einziger Job ist die Durchsetzung.
Welches Modell verwendest du für den Review-Schritt?
Gemini 3.5 Flash (aus Kostengründen – der Review läuft bei jeder Folge in 7 Sprachen). Es kommt gut mit einfacher Durchsetzung zurecht (Catchphrases kürzen, erfundene Stats abschwächen). Es hat Schwierigkeiten mit Aufgaben, die Content-Neugenerierung erfordern, wie das Umstrukturieren von Segment-Eröffnungen. Ein stärkeres Modell würde da helfen, aber ich habe die Kosten dafür noch nicht gerechtfertigt.
Ich baue DIALOGUE, eine KI-Podcast-Plattform, allein an meinen Abenden und Wochenenden. Der Code für die Catchphrase-Extraktion und die Review-Prompt-Änderungen ist offen – du kannst den vollständigen System-Prompt und die Durchsetzungslogik in meinem podcast-engine-Repository lesen. Ich schreibe über das, was ich dabei lerne.
Falls du auf ein ähnliches Problem gestoßen bist – Regeln, die gelesen, aber nicht durchgesetzt werden – würde mich interessieren: Welche Regel war es, und wo lebte sie in deiner Pipeline?
Das war's von mir für heute.
Viele Grüße, Chandler