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.