LLMOps: Vom Demo zur produktiven KI-Anwendung
Jeder kann ein LLM-Demo in einer Stunde bauen. In Produktion bringen dauert Monate — weil das Modell nur ein kleiner Teil des Systems ist.
Was LLMOps bedeutet, wie RAG und Fine-Tuning sich unterscheiden, und warum Evaluation der Schlüssel zur Produktionsreife ist.
Die Demo-Produktions-Lücke
Generative KI hat eine strukturelle Eigenschaft die sie von klassischer Software unterscheidet: Demos sind übermäßig einfach. Ein paar API-Calls, ein gutes Prompt — und das Ergebnis sieht besser aus als alles was Stakeholder erwartet haben. Das Problem folgt danach.
Was im Demo funktioniert
- Ein Prompt
- Eine Antwort
- Beeindruckt im Meeting
Was in Produktion nötig ist
- Retrieval-Pipeline
- Query-Enhancement
- Re-Ranking
- Output-Validation
- Tracing, Evaluation, Feedback-Loop, Monitoring
„Machine Learning ist die hochverzinsliche Kreditkarte technischer Schulden — und LLMs verdoppeln den Zinssatz."
— nach Google
LLMOps ist der operative Rahmen der sicherstellt, dass generative KI-Anwendungen nicht nur funktionieren, sondern zuverlässig, messbar und weiterentwickelbar sind. Es ist MLOps — angewendet auf LLM-Systeme, mit LLM-spezifischer Komplexität obendrauf.
Was das für euch bedeutet
Wer LLM-Projekte mit Demos plant und Produktions-Timelines ableitet, unterschätzt strukturell. Die Demo zeigt das Mögliche. Der Weg dorthin entscheidet über den Erfolg.
RAG oder Fine-Tuning: Eine Entscheidung mit Konsequenzen
Wenn Organisationen ein LLM an ihre Domain anpassen wollen, steht früh die Frage: Fine-Tuning oder RAG? Die Antwort hängt davon ab, was angepasst werden soll.
RAG (Retrieval-Augmented Generation)
Das Modell kann die Aufgabe — es kennt nur eure Daten nicht.
- Relevante Dokumente beim Inferenz-Zeitpunkt abrufen und als Kontext mitgeben
- Kein Modell-Training nötig
- Aktuell bleibend ohne Retraining
- Einstiegspunkt für die meisten Enterprise-Use-Cases
Fine-Tuning
Das Modell kann die spezifische Aufgabe grundsätzlich nicht gut genug — auch nicht mit detailliertem Prompting.
- Modell-Anpassung nötig
- Hosting-Kosten, Retraining-Zyklen, Versions-Management entstehen
- Sinnvoll für sehr spezifische Tasks die das Basis-Modell strukturell nicht beherrscht
Wann was?
Braucht das Modell Zugang zu euren spezifischen Dokumenten/Daten? RAG ist die richtige Wahl.
Schlägt das Modell bei einer bestimmten Aufgabe selbst mit ausführlichem Prompting fehl? Fine-Tuning evaluieren.
Wollt ihr vom neuesten externen Modell profitieren ohne Retraining? RAG.
Was das für euch bedeutet
Die meisten Enterprise-Use-Cases sind RAG-Probleme, keine Fine-Tuning-Probleme. Wer mit Fine-Tuning beginnt, übernimmt Infrastruktur-Schulden die RAG nicht hätte.
Production-Ready RAG: Die 5 Bausteine
Eine einfache RAG-Pipeline (Query → Vektorsuche → LLM-Antwort) ist kein Produktionssystem. Für einen zuverlässigen Betrieb braucht es fünf Bausteine:
Query Enhancement
Nutzer schreiben vage, abgekürzte oder mehrdeutige Anfragen. Bevor die Vektorsuche läuft, sollte die Query umformuliert werden — vollständiger, präziser, näher an der Sprache des Knowledge Bases. Ohne diesen Schritt findet die Suche die falschen Dokumente.
Re-Ranking
Vektorsuche gibt k Ergebnisse zurück — nicht unbedingt in der richtigen Reihenfolge nach Relevanz. Re-Ranking sortiert die abgerufenen Dokumente neu: die relevantesten kommen zuerst in den LLM-Kontext.
Hybrid Retrieval
Vektorsuche allein versagt bei exakten Treffern (Produktcodes, Eigennamen, spezifische Begriffe). Hybrid Retrieval kombiniert klassische Keyword-Suche (BM25) mit embedding-basierter Suche — das schlägt reine Vektor-Ansätze regelmäßig.
Output Validation
Ein letzter QA-Check bevor die Antwort an den User geht. Macht die Antwort Sinn? Enthält sie keine erfundenen Versprechen über Produkte oder Dienste, die nicht existieren? Einfache Regeln — große Wirkung.
End-to-End Tracing
Jede Anfrage vollständig loggen: Original-Query, abgerufene Dokumente, LLM-Output, Latenz pro Schritt. Ohne Tracing ist Debugging unmöglich.
Was das für euch bedeutet
Ein RAG-System ohne diese fünf Bausteine ist ein Experiment, kein Produkt. Die Bausteine sind nicht optional — sie sind die Differenz zwischen Demo und Deployment.
Evaluation: Der Schlüssel zur Produktionsreife
Was ist der häufigste Fehler bei LLM-Evaluationen? Teams bauen generische Dashboards mit Metriken wie „Helpfulness" oder „Toxicity Score" — und verpassen dabei die spezifischen Fehler ihrer Anwendung.
Traces lesen (vor allem anderen)
100 echte User-Interaktionen lesen und notieren was schiefgeht. Nicht root-causen — nur beobachten. Dieser Schritt dauert eine Stunde und liefert mehr Insight als jede generische Metrik.
Fehler kategorisieren
Die Notizen mit einem LLM zu 5–6 Kategorien verdichten (Axial Coding). Plötzlich ist sichtbar: 40% der Probleme sind eine Kategorie — das ist die erste Baustelle.
Gezielte Evaluatoren bauen
Für jede relevante Fehlerkategorie einen spezifischen Evaluator — entweder code-basiert (deterministische Prüfung) oder LLM-as-judge (mit manuell gelabelten Testfällen kalibriert).
„Wer direkt zum Eval-Dashboard springt ohne Traces gelesen zu haben, misst generische Metriken für ein spezifisches Problem. Das Dashboard sieht gut aus. Das Produkt nicht."
Was das für euch bedeutet
Evaluation ist eine Disziplin, kein Tool. Die wertvollste Investition ist Zeit zum Datenschauen — nicht Budget für ein Eval-Platform-Abo.