Freigeben über


LLMOps-Workflows auf Azure Databricks

Dieser Artikel ergänzt MLOps-Workflows auf Databricks durch Informationen speziell zu LLMOps-Workflows. Weitere Details finden Sie im The Big Book of MLOps.

Wie ändert sich der MLOps-Workflow für LLMs?

LLMs sind eine Klasse von Modellen zur Verarbeitung natürlicher Sprache (NLP), die ihre Vorgänger in Bezug auf Größe und Leistung bei einer Vielzahl von Aufgaben wie z. B. der Beantwortung offener Fragen, der Zusammenfassung und der Ausführung von Anweisungen deutlich übertroffen haben.

Die Entwicklung und Evaluierung von LLMs unterscheidet sich in einigen wichtigen Punkten von herkömmlichen ML-Modellen. Dieser Abschnitt fasst kurz einige der wichtigsten Eigenschaften von LLMs und die Auswirkungen auf MLOps zusammen.

Schlüsseleigenschaften von LLMs Auswirkungen auf MLOps
LLMs gibt es in vielen Formen.
  • Allgemeine proprietäre und OSS-Modelle, auf die mit kostenpflichtigen APIs zugegriffen wird.
  • Vorgefertigte Open-Source-Modelle, die von allgemeinen bis zu speziellen Anwendungen reichen.
  • Benutzerdefinierte Modelle, die für bestimmte Anwendungen optimiert wurden.
  • Benutzerdefinierte vortrainierte Anwendungen.
Entwicklungsprozess: Projekte entwickeln sich oft schrittweise, ausgehend von bestehenden Modellen von Drittanbietern oder Open-Source und enden mit angepassten, fein abgestimmten Modellen.
Viele LLMs nehmen allgemeine Abfragen und Anweisungen in natürlicher Sprache entgegen. Diese Abfragen können sorgfältig ausgearbeitete Prompts enthalten, um die gewünschten Antworten hervorzurufen. Entwicklungsprozess: Das Entwerfen von Textvorlagen für Abfragen von LLMs ist oft ein wichtiges Element bei der Entwicklung neuer LLM-Pipelines.
Packaging von ML-Artefakten: Viele LLM-Pipelines verwenden bestehende LLMs oder LLM-Serving-Endpunkte. Die ML-Logik, die für diese Pipelines entwickelt wird, konzentriert sich möglicherweise auf Prompt-Vorlagen, Agenten oder Serien statt auf das Modell selbst. Die gepackten und in die Produktion heraufgestuften ML-Artefakte können diese Pipelines anstelle von Modellen sein.
Viele LLMs können Prompts mit Beispielen, Kontext oder anderen Informationen nutzen, um eine Frage zu beantworten. Bereitstellungsinfrastruktur: Wenn Sie LLM-Abfragen mit Kontext erweitern, können Sie zusätzliche Tools wie Vektorindizes verwenden, um nach relevanten Kontexten zu suchen.
APIs von Drittanbietern bieten proprietäre und Open-Source-Modelle. API Governance: Die Verwendung einer zentralisierten API-Governance bietet die Möglichkeit, problemlos zwischen API-Anbietern zu wechseln.
LLMs sind sehr große Deep-Learning-Modelle, die oft viele Gigabyte und hunderte von Gigabyte groß sind. Serving-Infrastruktur: LLMs benötigen möglicherweise GPUs für die Bereitstellung von Modellen in Echtzeit und schnellem Speicherplatz für Modelle, die dynamisch geladen werden müssen.
Kosten/Leistungs-Kompromisse: Da größere Modelle mehr Berechnungen erfordern und die Bereitstellung teurer ist, könnten Techniken zur Reduzierung der Modellgröße und der Berechnungen erforderlich sein.
LLMs sind mit traditionellen ML-Metriken nur schwer zu evaluieren, da es oft keine einzige „richtige“ Antwort gibt. Menschliches Feedback: Menschliches Feedback ist für die Evaluierung und das Testen von LLMs unerlässlich. Sie sollten das Feedback der Benutzer direkt in den MLOps-Prozess einbeziehen, auch zum Testen, Überwachen und für künftige Feinabstimmungen.

Gemeinsamkeiten zwischen MLOps und LLMOps

Viele Aspekte der MLOps-Prozesse ändern sich für LLMs nicht. Zum Beispiel gelten die folgenden Richtlinien auch für LLMs:

  • Verwenden Sie getrennte Umgebungen für Entwicklung, Staging und Produktion.
  • Verwenden Sie Git für die Versionskontrolle.
  • Verwalten Sie die Modellentwicklung mit MLflow, und verwenden Sie Modelle im Unity Catalog, um den Lebenszyklus des Modells zu verwalten.
  • Speichern Sie Daten in einer Lakehouse-Architektur mithilfe von Deltatabellen.
  • Ihre bestehende CI/CD-Infrastruktur sollte keine Änderungen erfordern.
  • Die modulare Struktur von MLOps bleibt gleich, mit Pipelines für Featurisierung, Modelltraining, Modellableitung usw.

Referenzarchitekturdiagramme

In diesem Abschnitt werden zwei LLM-basierte Anwendungen verwendet, um einige der Anpassungen an der Referenzarchitektur traditioneller MLOps zu veranschaulichen. Die Diagramme zeigen die Produktionsarchitektur für 1) eine Retrieval-Augmented Generation (RAG)-Anwendung, die eine API eines Drittanbieters verwendet, und 2) eine RAG-Anwendung, die ein selbstgehostetes, feinabgestimmtes Modell verwendet. Beide Diagramme zeigen eine optionale Vektordatenbank – dieses Element kann durch eine direkte Abfrage des LLM über den Model Serving Endpunkt ersetzt werden.

RAG mit einer LLM-API eines Drittanbieters

Das Diagramm zeigt eine Produktionsarchitektur für eine RAG-Anwendung, die über Databricks External Models eine Verbindung zu einer LLM-API eines Drittanbieters herstellt.

LLM eines Drittanbieters mit externem Modell

RAG mit einem feinabgestimmten Open-Source-Modell

Das Diagramm zeigt eine Produktionsarchitektur für eine RAG-Anwendung, die ein Open-Source-Modell feinabstimmt.

Feinabstimmung des LLM auf der Grundlage eines Open-Source-Modells

Änderungen von LLMOps an der MLOps Produktionsarchitektur

In diesem Abschnitt werden die wichtigsten Änderungen an der MLOps-Referenzarchitektur für LLMOps-Anwendungen erläutert.

Modellhub

LLM-Anwendungen verwenden häufig vorhandene, vorab trainierte Modelle, die von einem internen oder externen Model Hub ausgewählt wurden. Das Modell kann im Ist-Zustand oder feinabgestimmt verwendet werden.

Databricks bietet eine Auswahl an hochwertigen, vortrainierten Basismodellen im Unity Catalog und im Databricks Marketplace an. Mit diesen vortrainierten Modellen können Sie auf hochmoderne Funktionalitäten der KI zugreifen und sich die Zeit und die Kosten für die Erstellung eigener angepasster Modelle sparen. Ausführliche Informationen finden Sie unter Zugriff auf generative KI- und LLM-Modelle im Unity-Katalog.

Vektorindex

Einige LLM-Anwendungen verwenden Vektorindizes für schnelle Ähnlichkeitssuchen, z. B. um Kontext- oder Domänenwissen in LLM-Abfragen bereitzustellen. Databricks bietet eine integrierte Vektorsuchfunktion, mit der Sie eine beliebige Delta-Tabelle im Unity-Katalog als Vektorindex verwenden können. Der Index der Vektorsuche wird automatisch mit der Delta-Tabelle synchronisiert. Einzelheiten finden Sie unter Vektorsuche.

Sie können ein Modellartefakt erstellen, das die Logik zum Abrufen von Informationen aus einem Vektorindex kapselt und die zurückgegebenen Daten als Kontext für die LLM bereitstellt. Anschließend können Sie das Modell mit den Optionen MLflow-LangChain oder PyFunc protokollieren.

LLM feinabstimmen

Da es teuer und zeitaufwändig ist, LLM-Modelle von Grund auf zu erstellen, nehmen LLM-Anwendungen häufig eine Feinabstimmung eines bestehenden Modells vor, um dessen Leistung in einem bestimmten Szenario zu verbessern. In der Referenzarchitektur werden Feinabstimmungen und Modellbereitstellungen als unterschiedliche Lakeflow-Aufträge dargestellt. Die Validierung eines feinabgestimmten Modells vor der Bereitstellung ist oft ein manueller Prozess.

Databricks bietet eine Feinabstimmung des Basismodells, mit der Sie ein vorhandenes LLM anhand Ihrer eigenen Daten anpassen können, um seine Leistung für Ihre spezielle Anwendung zu optimieren. Einzelheiten finden Sie unter Feinabstimmung des Basismodells.

Modellbereitstellung

Im RAG-Szenario unter Verwendung einer API eines Drittanbieters besteht eine wichtige architektonische Änderung darin, dass die LLM Pipeline externe API-Aufrufe vom Model Serving Endpunkt zu internen LLM-APIs oder APIs von Drittanbietern vornimmt. Dies erhöht die Komplexität, die potenzielle Latenzzeit und die Verwaltung zusätzlicher Anmeldeinformationen.

Databricks bietet Mosaic KI Model Serving an, das eine einheitliche Schnittstelle zum Bereitstellen, Kontrollieren und Abfragen von KI-Modellen bietet. Einzelheiten finden Sie unter Mosaic KI Model Serving.

Menschliches Feedback bei der Überwachung und Evaluierung

Menschliche Feedback-Schleifen sind in den meisten LLM-Anwendungen unerlässlich. Menschliches Feedback sollte wie andere Daten verwaltet und idealerweise in die Überwachung auf der Grundlage von Streaming in nahezu Echtzeit einbezogen werden.

Die Mosaic KI Agent Framework Review-App hilft Ihnen, Feedback von menschlichen Prüfern zu sammeln. Weitere Informationen finden Sie in Benutzen Sie die Bewertungs-App für menschliche Bewertungen einer generativen KI-App (MLflow 2).