Letzten Monat habe ich eine Pipeline-Änderung ausgeliefert, auf die ich wirklich stolz war. Ein umgeschriebener Prompt. Ein Review-Schritt mit vollem Kontext. Eine detaillierte Bewertungsmatrix, um Wiederholungen zu erkennen und strukturelle Abwechslung zwischen den Segmenten zu erzwingen.
Ich habe es deployed. Sechs Wochen lang beobachtet. Mir eingeredet, dass es funktioniert.
Dann habe ich ein Evaluierungs-Framework gebaut. Es auf 40 echte Produktionsepisoden in 7 Sprachen losgelassen. Und festgestellt, dass der Review-Schritt – derjenige, den ich so sorgfältig entworfen hatte – die Skripte messbar schlechter machte.
Nicht neutral. Schlechter.
Der Dialog pro Segment erreichte 3,34 von 5. Das Outline 3,01. Und das finale Skript, nach dem Review-Durchlauf? 2,91.
Der Schritt, der zur Verbesserung der Skripte gedacht war, reduzierte die Qualität um über 12 %.
Dieser Wechsel – von „ich glaube, es funktioniert" zu „ich weiß, dass es nicht funktioniert" – begann vor ein paar Wochen. Ich habe mir Andrew Ng's Agentic AI-Kurs auf DeepLearning.AI angesehen, in dem er etwas betont, das offensichtlich klingt, es aber nicht ist: Evaluierungen und Traces sind die Grundlage jedes agentischen Systems. Ohne sie debuggt man im Dunkeln. Mit ihnen weiß man genau, welches Glied in der Kette gebrochen ist.
Ich hatte monatelang Ad-hoc-Qualitätschecks für Skripte durchgeführt – strukturelle Metriken wie das Verhältnis der Gesprächsbeiträge und die Sprecher-Balance, plus einen LLM-Richter, der A/B-Prompt-Varianten verglich. Sie fingen offensichtliche Regressionen ab. Aber sie waren nicht umfassend. Sie deckten eine Stufe ab (Dialog), eine Sprache nach der anderen, und waren für Prompt-A/B-Tests konzipiert, nicht für pipeline-weite Qualitätsaudits.
Andrews Punkt über Traces traf mich hart. Meine Pipeline hat fünf große LLM-Aufrufe pro Episode – Recherche, Outline, Dialog pro Segment, Intro/Outro und Review – plus einen ElevenLabs-TTS-Durchlauf. Ich hatte Qualitätsmetriken für einen davon. Den anderen vieren vertraute ich allein nach Bauchgefühl.
Also habe ich ein echtes Evaluierungssystem gebaut. Vollständig. Mehrdimensional. Wiederholbar. Hier ist, was es gefunden hat, die sechs Fixes, die ich an einem Tag ausgeliefert habe, und was sich tatsächlich verbessert hat.
Die Baseline: Drei Zahlen, die alles verändert haben
Ich habe 40 abgeschlossene Episoden aus meiner Produktionsdatenbank evaluiert – über alle 7 Sprachen (en, vi, ja, ko, es, zh, fr) und 10 Podcast-Stile hinweg – anhand von drei Bewertungsmatrizen mit je fünf Dimensionen. Ein LLM-Richter (GPT-5.6-terra) bewertete jede Stufe.
| Stage | Score | Worst Dimension |
|---|---|---|
| Dialogue (per-segment) | 3,34 | Factual Grounding: 2,17 |
| Outline (research + structure) | 3,01 | Citation Credibility: 1,28 |
| Final Script (post-review) | 2,91 | Publishability: 1,95 |
Drei Dinge sprangen sofort ins Auge:
1. Der Review-Durchlauf verschlechterte Skripte um 0,43. Dialog erreichte 3,34. Nach dem Review? 2,91. Der Schritt, der die Qualität verbessern sollte, entfernte sie.
2. Quellen-URLs waren alle undurchsichtige Weiterleitungen. Jede „Quellen-URL" in jedem Outline zeigte auf vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ.... Diese funktionieren für Menschen, die darauf klicken, sehen aber für automatisierte Prüfer komplett erfunden aus. 344 Fakten hatten Quellen-URLs. Null hatten resolved_url – ein Feld, das es noch gar nicht gab.
3. Publishability war die niedrigste Dimension in der gesamten Pipeline (1,95). Echte Podcaster, so urteilte der Evaluierungs-Richter, würden diese Skripte nicht unter ihrem eigenen Namen veröffentlichen. Erkennbare KI-Muster: identische Segment-Eröffnungen, generische Übergänge, fehlende Host-Persönlichkeit.
Die Evaluierung gab mir eine priorisierte Liste, was genau zu beheben war. Den Rest des Tages habe ich mit dem Beheben verbracht.
Die sechs Fixes (und ihre gemessene Wirkung)
Fix 1: Quellen-URLs – 0 % bis 100 % Auflösung
Vorher: 0 von 344 Recherche-Fakten hatten eine resolved_url. Jede URL sah aus, als wäre sie erfunden.
Fix: Ein 60-Zeilen-URL-Resolver, der während der Outline-Generierung läuft, der Vertex-AI-Weiterleitung zur tatsächlichen Quelle folgt und beide URLs speichert (Original für Google-ToS-Compliance, aufgelöst für alles andere).
def resolve_grounding_url(url: str) -> str:
if "grounding-api-redirect" not in url:
return url
response = requests.head(url, allow_redirects=True, timeout=5)
return response.url if response.url != url else url
Nachher: 23 von 23 Recherche-Fakten in den heutigen neuen Episoden haben resolved_url ausgefüllt – echte URLs wie simonwillison.net, axios.com, thinkingmachines.ai. 100 % Auflösung.
Fix 2: Das Review-Modell ausgetauscht (Gemini → DeepSeek)
Vorher: Gemini 3.5 Flash führte den Review-Durchlauf aus. Es machte leichte, konservative Änderungen: änderte „Genau!" zu „Keine Frage!", behielt aber größtenteils den Originaltext bei. Es fügte Füllwörter hinzu, die den Dialog abflachten. Die Dichte der Audio-Tags sank. Die Type-Token-Ratio sank. Die Anzahl der Gesprächswechsel blähte sich auf.
Fix: Den Review-Durchlauf auf DeepSeek v4-pro umgestellt (384K max output, auf 96K gedeckelt). Den Provider konfigurierbar gemacht:
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
Verifikation: In Produktion deployed. Eine vietnamesische Tech-News-Episode durchlief die gesamte Pipeline mit DeepSeek-Review – 10,3K → 11,6K Tokens, in 121 Sekunden abgeschlossen, 0 Straffungs-Durchläufe nötig. Eine zweite Episode (Englisch) verarbeitete 7,9K → 17K Tokens in 203 Sekunden. Der DeepSeek-API-Key lebt in Google Cloud Secret Manager und wird automatisch zum Deployment-Zeitpunkt via service.yaml injiziert.
Fix 3: Outline-Selbstkritik (+0,50 Verbesserung)
Vorher: Outlines gingen direkt von Gemini an den Nutzer, ohne interne Qualitätsprüfung. Durchschnittlicher Score: 3,01.
Fix: Einen automatisierten Kritik-Schritt hinzugefügt. DeepSeek v4-pro bewertet das Outline anhand einer 6-dimensionalen Bewertungsmatrix (die 5 Outline-Dimensionen plus Segmentanzahl), liefert Scores + spezifisches Feedback und speichert die Kritik in den Podcast-Metadaten.
Dann führte ich ein kontrolliertes Experiment durch: Nimm 6 Episoden, deren Outlines unter 3,0 lagen, führe die DeepSeek-Kritik aus, spiele das Feedback als Regenerierungsanweisungen an Gemini zurück und bewerte neu.
Nachher: +0,50 Gesamtverbesserung über die 6 Episoden hinweg.
| Dimension | Before | After | Delta |
|---|---|---|---|
| Content Boundaries | 3,33 | 4,17 | +0,83 |
| Research Depth | 2,67 | 3,17 | +0,50 |
| Citation Credibility | 1,00 | 1,50 | +0,50 |
| Structural Logic | 3,67 | 4,17 | +0,50 |
| Audience Fit | 2,17 | 2,33 | +0,17 |
Die schlechteste Episode stieg von 1,80 auf 3,20 (+1,40). Nur 1 von 6 wurde schlechter. Die Kritik ist jetzt standardmäßig in der Produktion aktiviert – jedes neue Outline durchläuft diese Qualitätsprüfung, bevor der Nutzer es sieht.
Fix 4: Ein-Segment-Outlines scheitern jetzt hart
Vorher: Die Evaluierung zeigte Episoden mit einem einzigen Segment und null Recherche-Fakten, die so niedrig wie 2,07 bewertet wurden. Das waren Fehlerfälle, die die Pipeline nicht als Fehler behandelte.
Fix: Wenn der Outline-Generator nach einem Wiederherstellungsversuch weniger als 3 gültige Segmente produziert, wird der Podcast als FAILED markiert. Keine Ein-Segment-Outlines mehr, die Nutzer erreichen. Beim nächsten Erstellungsversuch wird das Guthaben des Nutzers für einen neuen Versuch freigegeben.
Fix 5: Chinesische Lokalisierungsregeln
Vorher: Chinesische Episoden erreichten 2,88 – der niedrigste Wert aller 7 Sprachen. Übersetzungsartefakte (wörtlich übersetzte englische Redewendungen), identische Segment-Eröffnungen, englische Standard-Host-Namen (Alex/Maya) statt chinesischer Namen (明辉/晓雯).
Fix: Chinesisch-spezifische Dialogregeln geschrieben: natürliche Konversationsmuster (不是...而是...-Konstruktionen), korrekte satzfinale Partikel (吧/啊/呢), Anti-Übersetzungs-Richtlinien („medical miracle" niemals wörtlich übersetzen), chinesische Fußball-Metaphern für WM-Folgen und sprachspezifische Host-Profile mit eigenständigen Persönlichkeiten.
Die chinesische Dialogvorlage ging von der Wiederverwendung englischer Standards zu einem eigenen 80-Zeilen-Leitfaden über, der Konversationsmuster, Formulierungen für Meinungsverschiedenheiten und zielgruppenspezifisches Framing für jeden Podcast-Stil abdeckt.
Fix 6: Host-Namen-Standardwerte für Nicht-Englisch
Vorher: Mehrere nicht-englische Episoden hatten Hosts namens Alex und Maya. Die sprachspezifischen Host-Profile existierten, aber der Fallback-Pfad im Outline-Generator war auf englische Standards hartcodiert.
Fix: Den Fix durch die sprachbewusste Profilauflösungs-Pipeline verfolgt. Aktuelle Produktionsepisoden verwenden jetzt 翔太/健一 (ja), Mạnh/Nga (vi), Hugo/Camille (fr), 明辉/晓雯 (zh). Die Juli-Commits hatten bereits die Edge-Funktion und den Erstellungsablauf behoben – der verbleibende Fallback war im Outline-Generator selbst.
Das Evaluierungs-Framework (wiederverwendbar)
Das Framework, das all das gefunden hat, besteht aus ~500 Zeilen Python, drei Bewertungsmatrizen-Dateien (je 5 Dimensionen), einem gemeinsamen GPT-5.6-terra-Richter und einem Orchestrator:
docs/pipeline/evals/
├── run.py # Orchestrator: extract → judge → report
├── judge.py # Shared LLM judge (rate with rubric)
├── rubric_outline.py # Stage 1: 5 dimensions, 1-5 scale
├── rubric_dialogue.py # Stage 2: 5 dimensions, 1-5 scale
├── rubric_final_script.py # Stage 3: 5 dimensions, 1-5 scale
├── dataset_40.json # Extracted production data
├── scores.json # Machine-readable scores
└── report.md # Auto-generated report
Ich habe auch eine Experimentier-Ebene für A/B-Vergleiche gebaut:
docs/pipeline/evals/experiments/
├── review_ab.py # Compare two review models
├── outline_critique_ab.py # Critique → regenerate → compare
├── shared.py # Score comparator, report generator
└── results/ # Archived by date
Führe python docs/pipeline/evals/run.py --full nach jeder Pipeline-Änderung aus und erhalte einen Bericht in ~8 Minuten. Führe experiments/review_ab.py --episodes 10 aus, um Modelle zu vergleichen. Ergebnisse werden nach Datum archiviert für Trend-Tracking – willst du wissen, ob sich die Qualität diesen Monat im Vergleich zum letzten verbessert hat? Vergleiche die Scores.
Die vollständige 40-Episoden-Evaluierung kostet etwa $1-2 an API-Aufrufen. Die Experimente kosten weniger. Für das Signal, das du zurückbekommst – eine priorisierte Liste, welche Pipeline-Stufen und Dimensionen genau Aufmerksamkeit brauchen – ist es das günstigste Debugging-Tool, das ich je gebaut habe.
Was immer noch kaputt ist
Das DeepSeek-Review-A/B-Experiment braucht den vollständigen Produktions-Prompt. Das Experimentierskript verwendete einen vereinfachten 15-Zeilen-Prompt. Das Produktions-Review verwendet einen 80-Zeilen-Prompt mit Anti-Wiederholungs-Regeln, Catchphrase-Kontingenten, redaktionellen Leitplanken und Duration Policy. Mit dem vereinfachten Prompt zeigte DeepSeek im Wesentlichen neutrale Ergebnisse (-0,04). Mit dem vollständigen Prompt in Produktion schließt die Pipeline auf Englisch und Vietnamesisch erfolgreich ab. Ich muss das Experiment auf Produktionsniveau aktualisieren und erneut ausführen.
Die chinesische Lokalisierung braucht Validierung. Die Regeln sehen auf dem Papier richtig aus, die Host-Profile sind geschrieben, die Dialog-Leitfäden sind vorhanden. Aber ich habe die Evaluierung noch nicht auf neuen chinesischen Episoden laufen lassen, um zu bestätigen, dass der Score von 2,88 gestiegen ist. Das hat diese Woche Priorität.
Ich muss die vollständige 40-Episoden-Evaluierung auf neuen Episoden erneut ausführen. Alle sechs Fixes sind deployed. Der nächste Schritt ist, 40 Episoden zu extrahieren, die nach diesen Änderungen generiert wurden, sie durch dieselben Evaluierungen zu schicken und mit der historischen Baseline zu vergleichen. Wenn der finale Skript-Score von 2,91 auf über 3,0 steigt und die Quellen-Glaubwürdigkeit von 1,28 auf etwas Vernünftiges, weiß ich, dass die Änderungen durchgängig funktioniert haben.
Das Drei-Fragen-Pipeline-Audit
Nach dieser Erfahrung prüfe ich jetzt jede Pipeline-Änderung anhand von drei Fragen:
1. Gibt es ein Quality Gate zwischen jedem Schritt? Mein Outline ging direkt von Gemini an den Nutzer. Das Hinzufügen des Kritik-Schritts fing die schlechtesten Outlines ab, bevor sie jemand sah. Jeder Pipeline-Schritt braucht eine Qualitätsprüfung – automatisierte LLM-Evaluierung anhand expliziter Kriterien.
2. Verbessert jeder Schritt tatsächlich die Qualität, wenn man sie misst? Ihn auszuführen und anzunehmen, dass er hilft, reicht nicht. Du brauchst wortwörtliche Vorher-Nachher-Scores für denselben Inhalt. Mein Review-Schritt verschlechterte Skripte sechs Wochen lang, bevor ich es gemessen habe. Zuerst messen, nichts annehmen.
3. Kann ich erkennen, welche Dimension gebrochen ist? „Die Qualität ist schlecht" ist nicht handlungsrelevant. „Die Quellen-Glaubwürdigkeit liegt bei 1,28, weil 100 % der URLs undurchsichtige Weiterleitungen sind" ist es. Eine mehrdimensionale Bewertungsmatrix pro Stufe zeigt dir genau, wohin du schauen musst. Ich habe Stunden damit verbracht, meinen Review-Schritt vor der Evaluierung zu untersuchen. Mit der Evaluierung brauchte ich Sekunden – die Zahlen zeigten direkt auf Publishability und das Review-Modell.
Häufig gestellte Fragen
Werden LLM-Evaluierungen nicht teuer?
Die vollständige 40-Episoden-Evaluierung kostet etwa $1-2 an API-Aufrufen (GPT-5.6-terra, ~420K Tokens insgesamt). Die A/B-Experimente kosten noch weniger. Für das Signal, das du zurückbekommst – eine priorisierte Liste, welche Pipeline-Stufen genau Aufmerksamkeit brauchen – ist es das günstigste Debugging-Tool, das ich je gebaut habe, und günstiger als die Credits, die Nutzer für kaputte Episoden verschwenden würden.
Warum 5 Dimensionen pro Stufe? Warum nicht einfach „Gesamtqualität"?
„Gesamtqualität" sagt dir, dass etwas nicht stimmt. Sie sagt dir nicht, was. Als ich Quellen-Glaubwürdigkeit bei 1,28 sah, wusste ich sofort, dass die URLs kaputt waren. Als ich Publishability bei 1,95 sah, wusste ich, dass KI-Merkmale erkennbar waren. Fünf Dimensionen geben dir eine Differentialdiagnose. Eine Dimension gibt dir ein Fieberthermometer.
Wie hältst du den LLM-Richter konsistent?
Dasselbe Modell (GPT-5.6-terra), dieselbe Temperatur (0,0), derselbe Reasoning-Effort (medium), jedes Mal dieselben Bewertungsmatrix-Prompts. Die Scores werden mit Zeitstempeln archiviert, damit du über verschiedene Daten hinweg vergleichen kannst. Den Richter zu wechseln, ändert die Baseline – wähle einen und bleib dabei.
Was passiert, wenn der Richter selbst falsch liegt?
Die Bewertungsmatrix verlangt Begründungen für jeden Score – der Richter muss konkrete Belege aus dem Inhalt anführen. Ich habe außerdem eine manuelle qualitative Überprüfung von 10 Episoden in allen 7 Sprachen durchgeführt, um den Richter zu kalibrieren. Die LLM-Scores stimmten eng mit meinem menschlichen Urteil überein. Für kritische Dimensionen, bei denen das LLM unzuverlässig sein könnte (wie „Publishability", das kulturelles Urteilsvermögen erfordert), sind menschliche Stichproben unerlässlich.
Ich baue DIALOGUE, eine KI-Podcast-Plattform, solo an meinen Abenden und Wochenenden. Ich schreibe über das, was ich dabei lerne.
Falls du ein Evaluierungssystem für deine eigene LLM-Pipeline gebaut hast, würde mich interessieren: Wie misst du Qualität und was hast du entdeckt, das dich überrascht hat?
Das war's von mir für heute.
Viele Grüße, Chandler