Pipeline-Stufe 7 — Performance-Loop und Modell-Verbesserung
Eine Pipeline, die ihre eigene Performance nicht misst, ist ein einmaliger Prozess — kein lernendes System. Stufe 7 schließt den Loop: was haben die publizierten Cuts erreicht? Welche Cuts waren erfolgreich, welche nicht? Welche Signale aus der Performance fließen zurück in die Stufen 2 (LLM-Scoring) und 5 (Human-Review)? Eine professionalisierte Pipeline 2026 hat diesen Loop strukturell.
Eine Pipeline, die ihre eigene Performance nicht misst, ist ein einmaliger Prozess — kein lernendes System. Stufe 7 schließt den Loop: was haben die publizierten Cuts erreicht? Welche Cuts waren erfolgreich, welche nicht? Welche Signale aus der Performance fließen zurück in die Stufen 2 (LLM-Scoring) und 5 (Human-Review)? Eine professionalisierte Pipeline 2026 hat diesen Loop strukturell — nicht als ad-hoc-Audit, sondern als systematisches Iteration.
Was hier untersucht wird
Dieser Tiefe-2-Artikel schließt den T2-C09-Cluster mit der Performance-Loop-Stufe. Die Vor-Stufen 1 bis 6 haben den Produktions-Workflow beschrieben. Hier wird die Frage gestellt: wie wird die Pipeline strukturell verbessert über Zeit?
Die vier Performance-Metriken
Pro publiziertem Cut werden 2026 vier Kern-Metriken erfasst.
— Views in den ersten 60 Minuten (First-Hour-Velocity, siehe T2-A03-04). — Completion-Rate (Anteil Sicht über die volle Cut-Lauflänge). — Engagement-Rate (Shares plus Saves plus substantielle Comments plus Likes geteilt durch Views). — Final-Reach (Views nach 7 Tagen).
Diese vier Metriken werden in einer Datenbank gepflegt — typisch Notion, Airtable oder dedizierte Datenbank-Lösung.
Die wöchentliche Performance-Review
Jeden Freitag (oder einen anderen festen Wochentag) wird in einer 60- bis 90-minütigen Routine:
— Die Top-3 Cuts der Woche identifiziert. Was hatten sie gemeinsam? Welcher Hook? Welche Caption-Struktur? Welche Posting-Zeit? — Die Bottom-3 Cuts der Woche identifiziert. Warum performten sie schwach? Welche Pipeline-Stufe könnte besser sein? — Die Pipeline-Outputs der vergangenen Woche gegen die LLM-Scoring-Vorhersagen verglichen. Hat das Scoring gut prognostiziert? — Konkrete Anpassungen für die folgende Woche definiert: Prompt-Update, Cut-Längen-Test, neuer Sound-Cluster.
Der Feedback-Loop in die LLM-Stufe
Ein Schlüssel-Mechanismus 2026: die Performance-Daten fließen in den LLM-Scoring-Prompt zurück.
Konkret: alle 4 bis 8 Wochen wird der System-Prompt der Stufe 2 (LLM-Scoring) mit Beispielen aus der bisherigen Performance ergänzt — sowohl positive als auch negative Beispiele. Beispiel-Eintrag im Prompt:
Beispiele für gut-performende Hooks (gemessen an
First-Hour-Views über 5000):
- "Was Sie zu Mietpreisen wissen müssen — in 30 Sekunden."
- "Hier ist, was die Bundesregierung nicht sagt."
- [...]
Beispiele für schwach-performende Hooks (unter 500 Views):
- "Heute im Bundestag: eine wichtige Debatte."
- [...]Diese gelabelten Beispiele helfen dem LLM, die Scoring-Kriterien an die realen Audience-Reaktionen anzupassen.
Der Feedback-Loop in die Human-Review-Stufe
Editor-spezifische Anpassungen 2026:
— Cut-Längen-Korrektur. Wenn die meisten Top-Cuts der Woche 25 bis 30 Sekunden lang waren, aber die Pipeline-Default-Empfehlung 15 bis 20 Sekunden ist: Anpassung der Editor-Routine.
— Sound-Cluster-Identifikation. Welche CML-Tracks haben überproportional gut performt? Diese werden in die Favoriten-Bibliothek aufgenommen (siehe T2-C01-03).
— Caption-Style-Anpassung. Welche Caption-Varianten performten besser? Diese Beobachtungen prägen die Stufe-4-Verdichtungs-Strategie.
Die Quartalsweise Pipeline-Review
Zusätzlich zur Wochen-Routine wird quartalsweise ein größerer Pipeline-Review durchgeführt.
— Die letzten 100 Cuts werden gegen die Pipeline-Outputs analysiert. — Patterns über mehrere Wochen werden identifiziert. — Strukturelle Pipeline-Anpassungen (z.B. neuer LLM-Modell-Wechsel, neue Scheduler-Tool, neue FFmpeg-Operation) werden beschlossen.
Aufwand pro Quartal: rund 6 bis 8 Stunden.
Die typischen Performance-Loop-Fehler
Drei Fehler-Muster.
— Fehler eins: kein Loop. Performance wird gemessen, aber nicht in Pipeline-Anpassungen umgesetzt. Pipeline lernt nicht.
— Fehler zwei: zu enger Loop. Anpassungen pro Tag oder pro Cut führen zu Über-Optimierung an einzelne Datenpunkte. Empfehlung: Wochen-Iteration plus Quartals-Review.
— Fehler drei: nur Top-Performer-Analyse. Wenn nur die erfolgreichen Cuts analysiert werden, fehlt die Diagnostik der schwachen. Beide Enden zählen.
Operative Konsequenzen
Drei priorisierte Empfehlungen.
— Priorität A: Performance-Datenbank. Notion- oder Airtable-Datenbank mit den vier Kern-Metriken pro Cut. Aufwand: 4 Stunden Setup, dann automatisiertes Tracking.
— Priorität B: Wöchentliche Review-Routine. 60 bis 90 Minuten pro Woche. Aufwand: rund eine Stunde pro Woche.
— Priorität C: Quartalsweise Pipeline-Review. Größere Strukturanpassungen. Aufwand: 6 bis 8 Stunden pro Quartal.
Empfehlungen mit Priorität
— Priorität A: Performance-Datenbank. — Priorität B: Wöchentliche Review-Routine. — Priorität C: Quartals-Pipeline-Review.
Wo das hingehört
Tiefe-1 Sieben-Stufen-Pipeline: T1-C09. Vor-Stufen: T2-C09-01 bis T2-C09-06. Distributions-Timing: T2-A03-04. LLM-Scoring: T2-C09-02.
Codex AI-Automation Sektion 4.
Was du als nächstes tust
Diese Woche: Performance-Datenbank aufbauen. Vier Metriken pro Cut werden ab sofort erfasst.