[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
MLOps versus LLMOps: Infrastruktur für Foundation Models- und LLM-Systeme
Foundation Models hat mehrere Annahmen hinter den klassischen MLOps-Verfahren verändert. Teams passen häufig vorgefertigte Model an oder verwenden diese, anstatt jeden Model von Grund auf zu trainieren; zudem erfordern generierte Antworten sowie Tool-Aktionen eine Bewertung, die über einfache Vorhersagemetriken hinausgeht.
Die Disziplin des MLOps gilt weiterhin. Was sich geändert hat, ist die operative Einheit: Das Verhalten einer Sprach-Model-Anwendung kann von Prompts, der Dekodierung, Retrieval, den Tool-Verträgen, Berechtigungen, Routing sowie Richtlinien ebenso wie von Model Weights abhängen. In diesem Artikel wird erläutert, was weiterhin nützlich ist und welche Funktionen LLM-Systeme hinzugefügt haben.
Zusammenfassung. Bewahren Sie die MLOps-Linienführung, Automatisierung, schrittweise Bereitstellung, Überwachung sowie Rollback-Mechanismen bei. Erweitern Sie das Release-Manifest um Angaben zum Anbieter oder Weights, Prompts, Schemata, den Retrieval-Zustand, verwendete Tools, Routing sowie Richtlinien. Überprüfen Sie dieses Manifest in mehreren Stufen, um seine Qualität zu sichern, und nutzen Sie anschließend datenschutzkonforme Traces-Verfahren, um Produktionsfehler in neue Tests umzuwandeln.
Was MLOps bereits gelöst hat
MLOps bietet etablierte Kontrollmechanismen, die auch dann nicht veraltet werden, wenn der Model Text erzeugt:
- Abstammungslinie von Daten, Code, Konfigurationen sowie Model bis hin zu einer Veröffentlichung
- wiederholbare Trainingsschleifen oder Pipelines-Prozesse
- Offline-Validierung vor der Bereitstellung
- Registrierungsmechanismen sowie eindeutige Identifikation unveränderlicher Artefakte
- schrittweiser Rollout, servicebezogene Ziele, Rollback-Mechanismen und Vorgehensweisen bei Incidents
- Infrastruktur-Telemetrie sowie Kapazitätsmanagement Planning
- Zugriffskontrolle, Aufbewahrungsfristen und Prüfkonzepte für Daten
Die Foundation Models sollte diese Anforderungen nicht entfernen. Sie sorgen dafür, dass der alte Begriff „Model Version“ zu unpräzise wird.
Die Release-Einheit wurde zu einem Systemmanifest
In einem herkömmlichen Vorhersageservice erklären in der Regel der Code, die Feature-Logik sowie die Identität von Model den größten Teil der Verhaltensänderungen. Bei einem foundation-Model-System sollten zumindest folgende Aspekte aufgezeichnet werden:
application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisionsDie genaue Liste hängt vom System ab. Konstant bleibt, dass ein Manifest jedes eigenständig veränderliche Komponente identifizieren muss, das das dem Benutzer sichtbare Verhalten beeinflussen kann.
Der Alias eines Anbieters für Model ist nicht unbedingt ein unveränderliches Artefakt. Ein selbst gehosteter Hash für Checkpoint ist präziser, doch Runtime-, Quantization-, Vorlagen- sowie Parallelisierungs-Einstellungen müssen weiterhin im Release-Record enthalten sein.
Fünf erweiterte Fehlerquellen
Der Unterschied zwischen MLOps und LLMOps wird bei der Fehleranalyse deutlicher als in Listen von Tools.
1. Model und Serving
Beim gehosteten Models sind Verfügbarkeit des Anbieters, Quoten, regionale Verarbeitung, Änderungen von Aliassen sowie eine Pay-per-Token-Wirtschaftsmodell relevant. Beim selbst gehosteten Models spielen hingegen Weight-Lieferketten, GPU-Kapazitäten, Batching, Cache-Strategien, Quantization und verteilte Serving-Konzepte eine entscheidende Rolle.
Sowohl Ansätze als auch Agenten benötigen Latency, also Fehlerbehandlung, Throughput, also Sättigungskontrolle, sowie Kostenschutzmechanismen. Kein Deployment-Modus ersetzt die Qualitätsevaluierung.
2. Prompt, Schema und Orchestration
Ein Prompt ist eine kodenähnliche Konfiguration, doch allein Prompt-Text definiert kein Verhalten. Die Reihenfolge der Nachrichten, Beschreibungen der Tools, das Antwortschema, die Dekodierung, Wiederholungsversuche, das Trunkieren sowie der umgebende Code sind alle von Bedeutung.
Versionieren Sie die zusammengestellte Anfrage sowie die Orchestration-Richtlinie. Prüfen Sie Structured Outputs mithilfe von Parsern und Geschäfts-Invarianten, anstatt „gültige JSON“ einfach als Erfolg des Vorgangs zu betrachten.
3. Retrieval und Kontext
Retrieval fügt ein eigenständiges Datenprodukt zwischen der Quelle der Wahrheit und dem Model ein:
Der Pipeline muss die ursprüngliche Revision sowie die Versionen des Parsers und Chunkers beibehalten, die Embedding-Identität gewährleisten, den Index-Build-Prozess, Metadaten zur Zugriffskontrolle und den Löschzustand speichern. Vor der Erstellung muss eine Retrieval-Überprüfung durchgeführt werden: Dabei wird geprüft, ob das System die richtigen Belege gefunden hat, ob die Autorisierungsfilter funktioniert haben und ob die Antwort die bereitgestellten Belege korrekt verwendet hat.
Ein Vektorindex ersetzt weder einen Feature-Store noch ein Data-Warehouse. Er dient der Berechnung von Ähnlichkeiten Retrieval; strukturierte Merkmale zu einem bestimmten Zeitpunkt sowie analytische Fakten weisen weiterhin unterschiedliche Anforderungen hinsichtlich Konsistenz und Abfragemöglichkeiten auf.
4. Werkzeuge und Aktionen
Wenn ein Model in der Lage ist, auf einen APIs zuzugreifen, können Qualitätsmängel zu Nebeneffekten werden. Die betriebliche Grenze umfasst nun die Authentifizierung von Tools, das Prinzip des geringsten Privilegs, die Validierung von Argumenten, Zeitlimits, Idempotenz, Genehmigungsrichtlinien sowie Prüfungen der Postbedingung.
Trace Welches Tool angeboten, ausgewählt, aufgerufen, abgelehnt, erneut versucht und schließlich umgesetzt wurde. Eine präzise Endantwort kann nicht beweisen, dass der Handlungsablauf korrekt war.
5. Sicherheit, Schutz vor Angriffen und Richtlinien
Inhaltsfilter stellen lediglich eine Art Kontrolle dar und bilden keine vollständige Guardrail-Schicht. Zu den Bedrohungen gehören außerdem Prompt Injection, cross-tenant Retrieval-Probleme, die Offenlegung von Geheimnissen, übermäßiges Handeln durch KI-Agenten, unzuverlässiger Model- oder Knotencode sowie unsichere Argumente von Tools.
Drücken Sie deterministische Geschäftsregeln soweit wie möglich außerhalb von Model aus. Definieren Sie verbleibende Risiken, prüfen Sie feindliche Angriffsfälle und weisen Sie für Änderungen an den Richtlinien einen Verantwortlichen zu. Das von NIST vorgestellte Generative AI Profil stellt ein nützliches Risikoinventar dar, ist jedoch kein fertigstehender Akzeptanztest.
Die Bewertung wird zu einer Freigabestufe
Freiform-Ausgaben machen eine einzige Gesamtreichweitenangabe unzureichend – doch sie machen die Qualität keineswegs unmessbar.
Erstellen Sie einen Bewertungsstack mit mehreren Arten von Belegen:
- Deterministische Überprüfungen: Gültigkeit des Schemas, Vorhandensein von Zitaten, zulässige Tools, Einschränkungen der Argumente, Richtlinienregeln, Latency sowie Budget.
- Komponentenmetriken: Retrieval-Recall und -Ranking, Genauigkeit bei der Tool-Wahl, Richtigkeit der Tool-Argumente sowie Auswahl der Route.
- End-to-End-Aufgaben: repräsentative Eingaben mit expliziten Erfolgskriterien und Slice-Labels.
- Bewertung auf Basis von Model: durch Rubriken gesteuerte Beurteilungen, die anhand von Expertenlabels kalibriert werden und hinsichtlich einer Judge-Abweichung überwacht werden.
- Menschliche Überprüfung: unklare, hochwirksame, neuartige oder ausgewählte Fälle, bei denen die Automatisierung keine autoritative Entscheidung herbeiführen kann.
- Adversarische Tests: Fälle von Injektionen, Grenzüberschreitungen, Missbrauch, Ablehnungen sowie Nebeneffekten im Zusammenhang mit der Bedrohung Model.
Speichern Sie die Ergebnisse pro Beispiel – und nicht nur die Durchschnittswerte. Eine neue Version kann den Durchschnitt verbessern, während sie bei einer bestimmten Sprache, einem Tenant, einem Dokumenttyp oder einer Aktionsklasse zu Leistungsrückgängen führt.
Die Deployment-Schleuse vergleicht ein potenzielles Manifest mit der aktuellen Version derselben versionierten Suite. Die Schwellenwerte müssen Qualität, Sicherheit, Latency sowie Kosten gemeinsam abdecken; ein günstigerer Weg, der die Anforderungen nicht erfüllt, stellt keine Optimierung dar.
Traces Die Produktivumgebung wieder mit der Evaluierungsumgebung verbinden
Infrastrukturmetriken können auf eine langsame Aufrufzeit von Model hinweisen. Sie machen jedoch nicht sichtbar, ob Retrieval ein nicht autorisiertes Dokument zurückgegeben hat oder ob ein Tool mit dem falschen Konto aufgerufen wurde.
Erfassen Sie einen Trace entlang des Entscheidungswegs:
- Identitätsbestimmung sowie Korrelation von Release-Manifesten und Anfragen
- Model sowie Aufrufe an Anbieter, Latency, Nutzungsmuster und Abschlusszustände
- Retrieval-Abfragen, Dokumentidentifikatoren, Bewertungswerte sowie Entscheidungen zur Filterung
- Prompt/Template-Revision ohne unbefugte Speicherung sensibler Inhalte
- Angebote von Tools, übergebene Argumente, Genehmigungen, Ergebnisse sowie Identifikatoren für Nebeneffekte
- Richtlinienentscheidungen, Wiederholungsversuche, Fallback-Mechanismen sowie das endgültige Ergebnis
Tracing erzeugt eine neue Ebene zur Datenverwaltung. Bevor vollständige Prompts oder Dokumente gesammelt werden, sollten Verfahren wie Minimierung, Redaktion, Isolierung der Nutzergruppen, Verschlüsselung, Stichprobenentnahme, Aufbewahrungsfristenmanagement sowie Zugriffsprüfung angewandt werden. Die generativen-AI Konventionen von OpenTelemetry können die Interoperabilität verbessern, doch ihre Schemata entwickeln sich weiterhin weiter; daher ist es wichtig, festgelegte Instrumentierungs- und Sammlerversionen zu verwenden.
Der Verbesserungslauf ist:
production trace → triaged failure → labeled regression case
→ candidate change → offline comparison
→ staged release → monitored outcomeKundenfeedback kann die Priorisierung von Untersuchungen unterstützen, stellt jedoch keine zuverlässige Grundlage dar. Behalten Sie den umliegenden Trace bei und holen Sie in bedeutenden Fällen Expertenbewertungen ein.
Das Serving-Gateway stellt eine Grenze für Richtlinien dar
Ein Gateway kann Anwendungsclienten von Anbietern oder selbst gehosteten Engines entkoppeln. Zu seinen nützlichen Aufgaben gehören unter anderem:
- Authentifizierung, Budgets für einzelne Nutzer:innen, Quoten sowie Rate Limits
- stabile Verträge für Anfragen und Antworten
- Routenwahl nach Funktionalitäten, Region, Latency oder bewerteter Qualität
- begrenzte Wiederholungsversuche, Circuit Breaker-Mechanismen sowie explizite Fallback-Strategien
- Partitionierung von Caches sowie Richtlinien für sensible Daten
- Zuordnung der Nutzung sowie Verbreitung von Release-Manifesten
Ein Fallback stellt lediglich eine Änderung des Verhaltens dar und ist keineswegs ausschließlich ein Mechanismus zur Gewährleistung der Zuverlässigkeit. Sollten kleinere Model, alternative Anbieter oder eingeschränkte Kontexte die Qualität der Aufgabe beeinträchtigen, muss dieser Pfad als eigenständige Route bewertet und Trace werden.
Übertragen Sie nicht jede Entscheidung, die durch Orchestration getroffen wird, in das Gateway. Halten Sie die Domänenregeln in der Nähe der Anwendung und stellen Sie sicher, dass die Verantwortlichkeiten klar erkennbar sind.
Fine-Tuning stellt eine einzelne Intervention dar und nicht eine Hierarchie der Reifegradstufen.
Wählen Sie die geeignete Intervention aus dem beobachteten Ausfall aus:
| Fehler | Erster Komponente zur Überprüfung |
|---|---|
| Fehlende aktuelle oder private Fakten | Retrieval sowie Synchronisierung der Quelldaten |
| Falsches Format oder ungültige Argumente | Schema, begrenzte Ausgabe, Validierung |
| inkonsistentes Verhalten der Aufgabe | Prompt, Beispiele, die Wahl von Model sowie anschließend die Anpassungsdaten |
| Übermäßiger Verbrauch von Latency oder Kosten | Route, Kontext, Cache, Batching, Quantization |
| Nicht autorisierte oder unsichere Aktion | Tools-permissions und deterministische Richtlinie |
| Das Verhalten der Domäne lässt sich aus dem Kontext nicht rekonstruieren. | Fine-Tuning oder ein weiteres spezialisiertes Model |
LoRA sowie andere parametereffiziente Methoden verringern die Anzahl der zu trainierenden Parameter; sie beseitigen jedoch nicht die Governance-Vorgaben von Dataset, die basierenden Model-Lizenzbedingungen, die Bewertung, die Serving-Kompatibilität oder die Anforderungen an ein Rollback-Verfahren.
Eine praktische Implementierungssequenz
- Definieren Sie die Benutzeraufgabe, die Grenzen möglicher Schäden, die Serviceziele sowie den Kostenrahmen.
- Erstellen Sie zunächst das Release-Manifest, bevor ein Prompt-Register, Vector Database oder ein Gateway-Produkt eingeführt wird.
- Konstruieren Sie einen kleinen, in Teile unterteilten Evaluationsdatensatz sowie deterministische Komponententests.
- Instrumentalisieren Sie eine End-to-End-Trace-Umgebung mit Datenschutzmechanismen sowie stabilen Release-Identitäten.
- Führen Sie den Rollout über Shadow-Deployments, Canary-Tests oder eingeschränkten Traffic durch und definieren Sie dabei explizite Auslöser für einen Rollback.
- Wandeln Sie geprüfte Produktionsfehler in Regressionstests um und wiederholen Sie den Prozess.
Fügen Sie Infrastruktur nur dann hinzu, wenn sie eine benannte Steuerung besitzt oder einen gemessenen Bottleneck entfernt. Eine „LLMOps-Plattform“ stellt keine Anforderung hinsichtlich der Architektur dar.
Fazit
LLMOps stellt eine auf größere Verhaltenseinheiten angewandte Variante von MLOps dar. Der Model bleibt weiterhin von großer Bedeutung, doch Prompts, die abgerufenen Belege, die Berechtigungen der Tools, Routing sowie die geltenden Richtlinien können das Ergebnis verändern, ohne die Weights zu beeinflussen.
Die Version, die die gesamte Einheit umfasst, wird vor der Veröffentlichung evaluiert, Trace wobei dabei Datenschutzgrenzen berücksichtigt werden, und anschließend als integriertes System wieder zurückgerollt. Genau dieser operative Unterschied ist von entscheidender Bedeutung.