LLMOps in der Praxis: Evaluierung, Observability, Kosten und Governance für KI

Ein Wochenende reicht, um eine RAG-App über Unternehmensdaten zu bauen, Tool Calling hinzuzufügen, einen Agenten in eine ordentliche Oberfläche zu packen und eine Demo zu zeigen. Alle sind beeindruckt. Schwierig ist, dass sie sechs Monate später noch zuverlässig läuft. Dann beginnen die Fragen. Woran merken wir, dass die Antworten schlechter werden? Was ist passiert, als letzten Dienstag das Modell gewechselt hat? Warum ist die KI-Rechnung um 40 % gestiegen? Die Security will wissen, welche Informationen das Modell erhält. Und das Engineering stellt die Frage, die niemand mag: Können wir die Antwort reproduzieren, die der Kunde tatsächlich bekommen hat?

Das ist das Terrain von LLMOps. DevOps hat Teams eine Disziplin für Bau, Deployment und Betrieb gewöhnlicher Software gegeben. LLMOps überträgt dieselbe Denkweise auf Systeme, deren Verhalten von Modellen, Prompts, Kontext, Retrieval und probabilistischer Ausgabe abhängt, und dieser Unterschied ändert fast alles.

Mehr als das Beobachten eines LLM-Endpunkts

Viele halten LLMOps für Dashboards rund um einen OpenAI- oder Azure-OpenAI-Endpunkt. Das ist nur ein kleiner Ausschnitt. Eine KI-Anwendung in Produktion ist ein Haufen beweglicher Teile: das Foundation Model mit seinen Prompts und Systemanweisungen, RAG-Pipelines mit Embedding-Modellen und Vektorindizes, Tools und Agenten, Evaluierungsdatensätze, Sicherheitsrichtlinien, gewöhnlicher Anwendungscode und Nutzerfeedback.

Man kann es sich als Summe aus Lifecycle-Management, Evaluierung, Observability, Governance und Kostenkontrolle merken. Das wichtigste Wort darin ist Lifecycle. Ein KI-System ist nicht fertig, wenn das Modell in Produktion geht. Genau dort beginnt der eigentliche Lebenszyklus.

Ein Lebenszyklus ohne Ende

Klassische Software läuft in einer Schleife aus Programmieren, Testen, Deployen, Beobachten und Verbessern. LLM-Anwendungen durchlaufen eine ähnliche Schleife, mit einem großen Unterschied. In gewöhnlicher Software ändert eine geänderte Codezeile das Verhalten meist vorhersehbar. In einer LLM-App kann die Ausgabe durch eine Änderung der Modellversion, der Temperatur, des Prompts, der abgerufenen Dokumente, des Embedding-Modells, der Chunking-Strategie, der Tool-Definitionen oder der Reihenfolge im Kontext beeinflusst werden. Lifecycle-Management ist daher auf mehreren Ebenen nötig. Sie deployen kein KI-Modell. Sie deployen ein KI-System.

Der Prompt ist Produktionskonfiguration

Früh im Projekt schreibt jemand einen Prompt wie diesen:

You are a helpful assistant...

Dann wächst er immer weiter. Ein paar Monate später enthält er Geschäftslogik, Ausgabeformatierung, Sicherheitsgrenzen, Beispielantworten und Ausnahmen, und jemand bearbeitet ihn live in Produktion. Das ist ein Problem. Ein Produktions-Prompt verdient eine Behandlung nahe an Quellcode, einschließlich Versionen:

customer-support-v1
customer-support-v2
customer-support-v3

Jede Version braucht einen Verantwortlichen, eine Änderungshistorie, Evaluierungsergebnisse, einen Deployment-Status und eine Rollback-Möglichkeit. Eine Prompt-Änderung ist eine Produktionsänderung. Wenn Version 17 die Antwortrelevanz um 12 % verbessert, aber die Halluzinationen verdoppelt, wollen Sie das wissen, bevor sie alle Nutzer erreicht. Hier leiht sich LLMOps viel aus dem Software-Engineering: Versionieren Sie alles, was das Modellverhalten verändern kann.

Evaluierung ist die fehlende CI/CD-Schicht

Für Engineers, die in die KI kommen, ist das vielleicht der größte Umdenkprozess. Angenommen, Sie ändern einen Prompt, probieren fünf Fragen von Hand aus, finden die Antworten besser und deployen. Das reicht nicht. Pflegen Sie stattdessen einen Evaluierungsdatensatz:

Question
Expected behavior
Reference answer
Relevant source
Safety expectation

Und lassen Sie jede relevante Änderung dagegen laufen. Welche Metriken zählen, hängt von der Anwendung ab. Bei einem RAG-System interessieren Sie vielleicht Retrieval-Qualität, Groundedness, Zitiergenauigkeit und Antwortrelevanz. Bei einem Agenten, ob er das richtige Tool wählt und korrekt aufruft, die Aufgabe abschließt, unnötige Schritte vermeidet und sich von Fehlern erholt. Bei einem Assistenten mit Kundenkontakt Korrektheit, Sicherheit, Latenz und Nutzerzufriedenheit. Das Prinzip: Jede Änderung an einem KI-System braucht einen Weg zu zeigen, ob sie das System verbessert oder verschlechtert hat. Das ist das KI-Gegenstück zu automatisierten Tests.

Warum Unit-Tests nicht genügen

Nehmen Sie die Anfrage „Erklär mir, warum meine Pipeline fehlgeschlagen ist.“ Es könnte fünf gleich gute Antworten geben, also ist ein Test wie dieser nutzlos:

assert response == expected_response

Testen Sie stattdessen Eigenschaften:

Did the answer contain the correct root cause?
Did it use the right evidence?
Did it avoid unsupported claims?
Did it cite the correct source?

Daraus ergeben sich mehrere Ebenen von KI-Tests:

• Unit-Tests prüfen, ob das Retrieval die erwarteten Dokumente liefert.
• Integrationstests prüfen, ob die gesamte RAG-Pipeline quellengestützte Antworten erzeugt.
• Evaluierungstests messen Ergebnisse an vorab festgelegten Qualitätsschwellen.
• Red-Team-Tests prüfen feindselige oder unsichere Eingaben.
• Regressionstests fangen Szenarien ab, die früher funktionierten und nach einer Modell- oder Prompt-Änderung kaputtgingen.

Klassisches Testen verschwindet nicht. Es wächst.

Halluzinationen messbar machen

Jedes KI-Team in Produktion stößt darauf: Eine Antwort klingt selbstsicher und ist falsch. Halluzinationen sind nicht immer offensichtlich, und ein Modell kann eine Unternehmensrichtlinie, eine Zahl, eine Quelle, die Ausgabe eines API-Aufrufs, eine Datenbankzeile oder eine ganze technische Erklärung erfinden. Verfolgen Sie dieses Verhalten deshalb systematisch. Fragen Sie bei RAG, ob die Antwort durch die abgerufenen Belege gestützt war. Bei einem Agenten, ob er etwas behauptet hat, das in den Tool-Ergebnissen fehlt. Bei einem Datenassistenten, ob die Erklärung zum zugrunde liegenden Abfrageergebnis passte. Darum werden Groundedness und Faithfulness zu Standarddimensionen der Evaluierung. Ziel ist nicht, so zu tun, als ließen sich Halluzinationen auf null bringen. Ziel ist, sie zu messen, zu verstehen, wo sie auftreten, und sie Schritt für Schritt zu reduzieren.

Observability jenseits von Logs

Klassisches Monitoring sagt Ihnen vielleicht Folgendes:

HTTP 500
Latency: 1.8 sec
Database error

Nützlich, ja. Aber stellen Sie sich eine falsche KI-Antwort auf gesunder Infrastruktur vor: Die API lieferte 200, das Modell lief normal durch, alles ist grün, und trotzdem hat der Kunde falsche Informationen bekommen. KI-Observability braucht ein tieferes Trace, das den Weg einer Anfrage festhält und nicht nur ihren Endpunkt. Das läuft auf Nachvollziehbarkeit der Intelligenz hinaus: Ausgehend von einer schlechten Antwort gehen Sie die Anfrage rückwärts durch, bis Sie den Schritt finden, der versagt hat. Hat das Retrieval danebengegriffen? War der Kontext unvollständig? War der Prompt fehlerhaft? Hat das Modell die Belege falsch gelesen, oder hat ein Tool schlechte Daten geliefert? Ohne diese Sicht ist KI-Debugging Raterei.

Das ganze System überwachen

Ein Produktions-Dashboard sollte nicht bei Token-Zahlen und Modelllatenz aufhören. Decken Sie diese Gruppen ab:

• Qualität: wie fundiert und relevant die Antworten sind, ob Aufgaben gelingen, wie oft das Modell halluziniert, was Nutzer sagen
• Performance: Latenz, Time to First Token, Durchsatz und Timeouts
• Zuverlässigkeit: fehlgeschlagene Anfragen, Tool- und Retrieval-Ausfälle sowie Retry-Raten
• Kosten: Ein- und Ausgabe-Tokens, welche Modelle genutzt werden, Ausgaben pro Anfrage, pro Nutzer und pro Workflow
• Sicherheit: Richtlinienverstöße, Offenlegung sensibler Daten, blockierte Anfragen und auffällige Tool-Aktivität

Damit können Sie mehr melden als eine gesunde API: Die Infrastruktur ist in Ordnung, doch die Antwortqualität sank, als der neueste Prompt ausgerollt wurde. Genau diese Sichtbarkeit braucht eine Enterprise-KI-Plattform.

Kosten werden zum Engineering-Problem

Gewöhnliche Anwendungen haben Infrastrukturkosten. LLM-Anwendungen fügen eine weitere Dimension hinzu: Jede Entscheidung verbraucht Tokens oder Modellressourcen. Stellen Sie sich einen Agenten vor, der normalerweise Folgendes macht:

1 model call

und nach einer Prompt-Änderung damit beginnt:

8 model calls

Er funktioniert vielleicht immer noch perfekt, aber die Kosten sind gesprungen. Deshalb lohnt es sich, dies zu verfolgen:

Cost per request
Cost per successful task
Cost per customer
Cost per workflow

Kostenarbeit wird dann zu Engineering. Setzen Sie kleinere Modelle ein, wo sie passen, cachen Sie wiederholte Operationen, kürzen Sie den Kontext, kontrollieren Sie Agentenschleifen, schicken Sie einfache Aufgaben an günstigere Modelle und heben Sie die teuren für Aufgaben auf, die sie brauchen. Das Ziel ist nicht „das billigste Modell nehmen“. Es geht darum, teure Intelligenz nur dort einzusetzen, wo sie Wert schafft.

Governance

Das ist der Teil von LLMOps, der Data Engineers am meisten interessieren sollte. Jede Organisation hat bereits Richtlinien für Datenzugriff, personenbezogene Daten, Aufbewahrung, Audit-Logging, Sicherheit, Compliance und Identität, und das KI-System muss sie befolgen. Wenn ein Mitarbeiter einen Kundendatensatz in der regulären Anwendung nicht sehen darf, sollte die KI diese Grenze nicht umgehen, nur weil sie die Datenbank abfragen kann. Die Autorisierung sollte aus dem Unternehmens-Setup in die KI-Schicht fließen, und die KI darf kein eigenes, separates Berechtigungssystem bekommen. Sie brauchen außerdem Aufzeichnungen darüber, welches Modell die Anfrage verarbeitet hat, welche Daten es bekam, welche Tools aufgerufen wurden, welche Antwort es erzeugte und wer die Aktion ausgelöst hat. Das ist mehr als Observability. Das ist Governance.

Produktion fließt ins System zurück

Starke KI-Systeme sind nie in einem Durchgang fertig. Sie lernen aus dem Produktionsverkehr. Angenommen, Nutzer stellen immer wieder Fragen, die das RAG-System falsch beantwortet. Sie gehen dem nach, und die Ursache liegt vielleicht gar nicht im Modell. Dokumente können schlecht gechunkt sein, Metadaten können fehlen, das Retrieval kann schwach sein, die falsche Quelle kann als maßgeblich gelten, oder der Prompt kommt mit Mehrdeutigkeit nicht zurecht. Sie beheben das eigentliche Problem und lassen die Evaluierungssuite erneut laufen. Das ist Engineering.

Wo Data Engineers im Vorteil sind

Data Engineering und LLMOps überschneiden sich auf interessante Weise. Viele vertraute Ideen lassen sich übertragen:

• Datenqualität ist KI-Qualität
• Data Lineage ist KI-Nachvollziehbarkeit
• Pipeline-Monitoring ist KI-Workflow-Monitoring
• Schemaänderungen entsprechen Prompt- und Modelländerungen
• ETL-Tests entsprechen Evaluierungspipelines
• Zugriffskontrolle ist KI-Autorisierung
• Kostenoptimierung ist Token- und Modelloptimierung

Die Werkzeuge unterscheiden sich, die Denkweise ist dieselbe. Verlässliche KI braucht weiterhin verlässliche Daten, kontrollierte Pipelines und messbare Ergebnisse. Das LLM beseitigt diese Anforderungen nicht, es macht sie wichtiger.

Ist LLMOps einfach DevOps für KI?

Als Ausgangspunkt ja, aber die Definition ist unvollständig. Software entscheidet normalerweise nicht, was sie sagt. LLMs tun das, und das bringt Unsicherheit. LLMOps muss daher zwei Fragen beantworten. Läuft das System korrekt? Das ist klassischer Betrieb. Verhält es sich korrekt? Das ist der neue Teil, und Sie brauchen beides. Ein völlig gesunder KI-Dienst kann furchtbare Antworten geben, und ein wackelig wirkender liefert manchmal exzellente, weshalb Uptime-Metriken allein nicht reichen.

Sechs Fragen an jedes Enterprise-KI-Design

Diese Fragen kommen auf, sobald eine KI-Anwendung so wichtig ist, dass Menschen sich auf sie verlassen:

1. Sind Prompts und Modelle versioniert? Ohne das wird das Reproduzieren eines Ergebnisses mühsam.
2. Wird jede Änderung vor dem Release evaluiert? Ohne das ist jedes Release eine Wette.
3. Lässt sich eine schlechte Antwort bis zu ihrem Ursprung zurückverfolgen? Ohne das kriecht das Debugging.
4. Werden Halluzinationen und Groundedness gemessen? Ohne das ist Qualität geraten.
5. Lassen sich die KI-Kosten erklären? Ohne das bringt Wachstum eine böse Überraschung.
6. Können Sie zeigen, auf welche Daten die KI zugegriffen hat und warum? Ohne das wird Governance schwierig.

Der Wandel, der bevorsteht

Die frühe generative KI fragte, ob sich ein Modell überhaupt zu einer Aufgabe bringen lässt. Heute lautet die Frage, ob es diese Aufgabe verlässlich erledigen kann, immer wieder, sicher und zu einem vernünftigen Preis. Das ist LLMOps. Das Modell ist ein Teil davon. Das schwierige Engineering steckt in allem drumherum: Versionierung, Evaluierung, Tests, Observability, Governance, Sicherheit und Kosten.

Erfahrenen Data- und Software-Engineers wird das vertraut vorkommen, denn sie haben längst gelernt, Systeme zu betreiben, die sie nicht vollständig kontrollieren. Jetzt erzeugen diese Systeme ihre eigenen Antworten. Das Ziel ist nicht, KI in jeder Situation vorhersagbar zu machen. Es geht darum, genug Engineering-Disziplin aufzubauen, damit Sie, wenn etwas schiefgeht, es erkennen, verstehen, beheben und belegen können, dass die Korrektur funktioniert hat. Das macht aus einer beeindruckenden Demo ein Enterprise-System.