LLM-Pipelines für die Produktion: Ein praxisorientiertes Engineering-Framework

Den Weg vom LLM-Prototyp in die Produktion zu gehen, ist kein Deployment-Problem – es ist ein Engineering-Problem. Die meisten Teams bringen einen funktionierenden Prototyp zum Einsatz und stoßen erst unter echtem Lastbetrieb auf die schwierigen Stellen: Prompt-Drift, inkonsistente Output-Schemata, undurchsichtige Fehlerbilder und Latenzen, die SLA-Vorgaben verletzen.

Die vier Schichten einer Produktions-LLM-Pipeline

Eine robuste Pipeline besteht aus vier klar abgegrenzten Schichten, jede mit eigenen Verträgen und Fehlerbildern.

1. Prompt-Management

Prompts sind versionierte Artefakte, keine inline-Strings. Sie gehören in ein dediziertes Registry mit semantischer Versionierung. Jeder Produktionsaufruf protokolliert, welche Prompt-Version verwendet wurde – das macht Regressionsanalysen handhabbar.

Grundprinzip: Trenne den System-Prompt (stabil, änderungsgesteuert) vom User-Kontext (dynamisch, pro Request). Diese Grenze macht A/B-Tests messbar.

2. Input- und Output-Validierung

LLM-Outputs sind probabilistisch. Definiere ein Output-Schema (JSON Schema oder Pydantic-Modell) und validiere jede Antwort, bevor sie nachgelagerte Systeme berührt. Bei Schema-Fehler: strukturiertes Retry mit korrigierendem Prompt, kein Fehler-Propagation.

Typische Validierungsziele:

• Pflichtfelder vorhanden und korrekt typisiert
• Numerische Werte innerhalb erwarteter Bereiche
• Keine personenbezogenen Daten in Outputs, die ins Logging fließen

3. Evaluierungs-Harness

Eine Produktionspipeline braucht kontinuierliche Evaluierung, nicht nur Unit-Tests. Baue einen Eval-Harness, der bei jeder Prompt-Versionsänderung läuft:

• Golden Set: 50–200 repräsentative Inputs mit manuell verifizierten erwarteten Outputs
• LLM-as-Judge: Ein zweites Modell bewertet Outputs anhand eines Rubrics (Genauigkeit, Ton, Vollständigkeit)
• Regression-Gate: Deployment wird geblockt, wenn der Score um mehr als zwei Prozentpunkte unter den Baseline-Wert fällt

4. Observability

Standard-APM deckt Latenz und Fehlerquoten ab. LLM-Pipelines brauchen zusätzlich:

• Token-Verbrauch pro Request und Modell
• Prompt-Versionsverteilung im Produktionstraffic
• Pass/Fail-Rate der Output-Schema-Validierung
• User-Feedback-Signale, sofern vorhanden

Latenz-Budgetierung

Lege ein Latenz-Budget fest, bevor du ein Modell wählst. Ein p95-Budget von 2 Sekunden schließt bestimmte Modellgrößen und Hosting-Konfigurationen aus. Dokumentiere das Budget, messe wöchentlich dagegen und behandle es als erstklassige Engineering-Anforderung – nicht als Nachgedanken.

Zusammenfassung

Der Unterschied zwischen einer Demo und einem produktiven LLM-System liegt in Observability, Versionierung und strukturierter Validierung auf jeder Ebene. Baue diese Strukturen von Woche eins an ein; nachträgliche Implementierung ist teuer.

Fehlerbehandlung ist Teil des Vertrags

Eine ungültige Antwort darf weder zu einem generischen 500-Fehler noch zu einer Endlosschleife werden. Klassifiziere Fehler: transienter Provider-Fehler, Schema-Mismatch, fehlende Quelle, Policy-Verstoß, Timeout oder Ablehnung durch das nachgelagerte System. Jede Klasse erhält eine begrenzte Reaktion. Transiente Fehler können mit Backoff wiederholt werden; ein Policy-Verstoß stoppt; eine Downstream-Ablehnung bewahrt den Payload und leitet ihn an den Owner.

Der Zustand liegt außerhalb des Modells. Die Pipeline – nicht das Gespräch – besitzt Versuchszahl, Idempotency-Key, Workflow-Status und den nächsten erlaubten Übergang. So wird ein Teilfehler wiederherstellbar und das Modell kann nicht behaupten, eine Aktion sei erfolgt, wenn der API-Aufruf nicht abgeschlossen wurde.

Integrations- und Security-Grenzen

Der Modellaufruf ist nur eine Komponente der Integration. Definiere Authentifizierung, Rate Limits, Provider-Egress, Secret-Redaction und den Vertrag zu jedem Zielsystem. Tool-Use braucht enge Schemata und Allowlists. Retrieval-Dokumente, User-Input und Tool-Ergebnisse sind untrusted Context; Prompt-Injection-Tests gehören ins Eval-Set, nicht in eine nachträgliche Checkliste.

Was gemessen und abgenommen wird

Vereinbare, welche Metrik für den Workflow Erfolg bedeutet. Das kann Faktenprüfung, Schema-Gültigkeit, Reviewer-Akzeptanz, Latenz, Kosten und sicheres Fehlerverhalten kombinieren. Dokumentiere Nenner und Testset-Version, damit eine Prozentzahl interpretierbar bleibt. Zur Abnahme gehören repräsentative Inputs, Grenzfälle, Provider-Ausfall, leeres Retrieval, langer Kontext und Rollback.

Übergabe und Change Management

Das Übergabepaket erklärt, wie Eval-Suite läuft, Prompt geändert, Modell gepinnt oder gewechselt, Trace geprüft, Secret rotiert, ein fehlgeschlagenes Item erneut abgespielt und zurückgerollt wird. Jede Änderung mit Einfluss auf Output-Qualität wird gegen die Baseline geprüft. Prompt-Registry, Schemata, Dependencies und Deployment-Konfiguration bilden eine gemeinsame Change-Fläche.

Das Framework bleibt bewusst konservativ: Produktionszuverlässigkeit entsteht durch explizite Verträge und Recovery-Pfade, nicht durch die Annahme, ein leistungsfähiges Modell werde konsistent handeln. Der Engineering-Service deckt die Umsetzung ab, der LLMOps-Service die Betriebsschicht.

Eine sinnvolle Reihenfolge

Beginne weder mit einem Dashboard noch mit einem großen Agent-Framework. Zuerst werden Input- und Output-Vertrag explizit, dann eine repräsentative Baseline erfasst, danach Validierung und Zustand ergänzt. Instrumentiere den Pfad, solange er klein ist. Erst wenn das Team Fehler erklären kann, kommen Parallelität, Fallback-Modelle oder komplexere Orchestrierung hinzu. Diese Reihenfolge reduziert die Zahl gleichzeitiger Unbekannter.