Mosaic AI Training auf Databricks: Wann Fine-Tuning sinnvoll ist und wann RAG ausreicht
Die Kernaussagen auf einen Blick.
- Mit Mosaic AI Training lassen sich Foundation Models direkt in Databricks anpassen. Die Trainingsdaten bleiben in Unity Catalog, das Training läuft auf verwalteten GPUs und das fertige Modell kann anschließend registriert und bereitgestellt werden.
- Fine-Tuning sollte nicht automatisch der nächste Schritt eines GenAI-Projekts sein. In der Regel sollten zunächst Prompting und RAG ausgeschöpft werden.
- Zur Verfügung stehen drei Verfahren mit unterschiedlichen Zielen und Anforderungen: Foundation Model Fine-Tuning zur Anpassung von Verhalten, Stil und Ausgabeformat, Continued Pre-Training zum Erlernen domänenspezifischer Begriffe aus großen Textbeständen sowie Instruction Tuning für die zuverlässige Umsetzung klar definierter Aufgaben und Ausgabeformate.
- In den meisten Fällen sollte zunächst RAG eingesetzt werden. Fine-Tuning ist sinnvoll, wenn sich eine konkrete fachliche oder verhaltensbezogene Lücke damit nicht schließen lässt. Eine Evaluationspipeline mit einem unabhängigen Goldset sollte bereits vor dem ersten Training eingerichtet sein. Das trainierte Modell sollte anschließend standardmäßig über Model Registry und Model Serving verwaltet werden.
Inhaltsverzeichnis
Die meisten brauchen kein Fine-Tuning
Die Ausgangslage ähnelt sich in vielen Projekten. Ein erster RAG-Prototyp findet die passenden Informationen, liefert aber noch zu allgemeine oder stilistisch unpassende Antworten. Daraufhin entsteht häufig der Wunsch nach einem eigenen oder speziell angepassten Modell. Zwar sind oft große Mengen an Tickets, Chatverläufen und Produktdokumenten vorhanden, sie wurden jedoch nicht für ein Training geprüft und aufbereitet. Ob Umfang, Qualität und Verteilung dieser Daten für ein Fine-Tuning ausreichen, ist meist noch ungeklärt.
In größeren GenAI-Umgebungen führt das häufig zu einem ähnlichen Ablauf: Ein erstes Fine-Tuning wird häufig über einen externen Anbieter umgesetzt, weil sich damit schneller ein Prototyp erstellen lässt. Spätestens beim nächsten Anwendungsfall stellt sich die Frage, ob und unter welchen Bedingungen Trainingsdaten die eigene Plattform verlassen dürfen. Danach muss geklärt werden, wie auf neue Versionen des Basismodells reagiert wird und welche Kosten ein erneutes Training verursacht. Oft fehlen zu diesem Zeitpunkt noch eine belastbare Evaluation, ein Verfahren zur Drift-Erkennung und ein nachvollziehbarer wirtschaftlicher Vergleich mit RAG.
Trainingsdaten prüfen
Wie viele geeignete Trainingsbeispiele tatsächlich vorliegen und wie zuverlässig sie annotiert sind.
RAG-Lücke benennen
Welches konkrete Problem sich mit RAG nicht ausreichend lösen lässt.
Lizenz klären
Ob die Lizenz den geplanten Einsatz im eigenen Produkt vor der Modellauswahl erlaubt.
Evaluation vorbereiten
Evaluationskriterien und Testdaten sollten vor dem ersten Trainingslauf feststehen.
Verantwortung festlegen
Für spätere Entscheidungen über Drift und erneutes Training sollte eine klare Verantwortung definiert sein.
Mosaic AI Training stellt die technische Umgebung für das Training bereit. Ob Fine-Tuning fachlich und wirtschaftlich sinnvoll ist, muss jedoch unabhängig davon entschieden werden. Diese Entscheidung sollte vor dem ersten Trainingslauf getroffen werden.
Was ist Databricks Mosaic AI Training?
Databricks Mosaic AI Training ist die in Databricks integrierte Funktionsgruppe zum Anpassen von Foundation Models. Trainingsdaten, GPU-Compute, Tracking und Registry sitzen an einem Ort, sodass ein Modell trainiert, bewertet und bereitgestellt werden kann, ohne dass die Daten die Databricks-Umgebung verlassen. Die Trainingsdaten werden aus Delta-Tabellen oder Volumes in Unity Catalog gelesen und auf einer von Databricks verwalteten GPU-Infrastruktur verarbeitet. Trainingsläufe lassen sich über die Benutzeroberfläche, die REST-API oder MLflow starten. Das trainierte Modell wird anschließend in der an Unity Catalog angebundenen Model Registry registriert und über Model Serving bereitgestellt; Managed MLflow erfasst dabei Trainingsläufe, Hyperparameter, Metriken und die zugehörigen Modellartefakte (Databricks-Dokumentation zu Mosaic AI Model Training).
Die zugrunde liegende Technologie geht auf MosaicML zurück, dem 2023 von Databricks übernommenen Pre-Training-Spezialisten. Mit der Übernahme wurden unter anderem die Trainingsinfrastruktur und die Orchestrierung großer GPU-Workloads in Databricks integriert.
Innerhalb einer LLMOps-Architektur verbindet Mosaic AI Training das ausgewählte Basismodell mit den nachgelagerten Schritten für Registrierung und Bereitstellung. Als Ausgangspunkt dient ein unterstütztes Foundation Model. Managed MLflow dokumentiert den Trainingslauf. Die Model Registry verwaltet die Modellversionen. Model Serving stellt das Modell für produktive Anfragen bereit. Fine-Tuning ergänzt diese Komponenten, ersetzt sie jedoch nicht. Zusätzlich entstehen Aufwände für Evaluation, Überwachung und erneutes Training. Retrieval und Qualitätsprüfung bleiben weiterhin notwendig. Wie sich Foundation Models, Tuning, Registry und Serving zu einer durchgängigen Pipeline zusammenfügen, klären wir im Überblick zu Artificial Intelligence auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Fine-Tuning, Pre-Training oder Instruction Tuning?
Mosaic AI Training unterstützt mehrere Verfahren, die sich bei Ziel, Datengrundlage und Rechenaufwand deutlich unterscheiden. Wer diese Verfahren nicht klar voneinander trennt, riskiert falsche Erwartungen bei Fachbereich, Management und Umsetzungsteam.
Foundation Model Fine-Tuning
Basismodell wird anhand von Prompt-Antwort-Paaren aus dem eigenen Datenbestand weitertrainiert, für Antwortmuster, Formulierung und Ausgabeformat. Bei kleinen Datenmengen sind bessere Prompts oder RAG meist günstiger.
Continued Pre-Training (CPT)
Basismodell wird mit umfangreichen Fachdomänen-Texten statt Frage-Antwort-Paaren weitertrainiert, um Fachbegriffe und Zusammenhänge besser zu erfassen. Braucht sehr große, gut aufbereitete Textmengen.
Instruction Fine-Tuning
Supervised Fine-Tuning mit Anweisung-Antwort-Beispielen für zuverlässiges Befolgen klar abgegrenzter Aufgaben wie Klassifikation, Extraktion oder Tool-Use.
| Verfahren | Use Case | Datenbasis-Bedarf | Compute-Charakter | Lizenz-Folge |
|---|---|---|---|---|
| Foundation Model Fine-Tuning (SFT) | Verhalten, Stil, Antwort-Format | 10k–100k Paare, hochwertig annotiert | mittel; Stunden bis Tage auf Multi-GPU | Lizenz des Foundation-Modells gilt |
| Continued Pre-Training | Domänen-Vokabular, Konzept-Raum | Milliarden Tokens, freier Text | hoch; Tage bis Wochen auf Multi-Node | Lizenz des Foundation-Modells gilt |
| Instruction Tuning | Anweisungs-Folge, Format-Treue | 5k–50k Instruction-Pairs | mittel; Stunden auf Multi-GPU | Lizenz des Foundation-Modells gilt |
Verfahren wie LoRA (Low-Rank Adaptation) oder PEFT (Parameter-Efficient Fine-Tuning) reduzieren den Rechen- und Speicherbedarf, verändern aber nicht das grundsätzliche Trainingsziel. Dabei wird nur ein kleiner Teil zusätzlicher Parameter trainiert, während die Gewichte des Basismodells unverändert bleiben. Für viele Fine-Tuning-Projekte ist LoRA ein sinnvoller Ausgangspunkt, weil sich damit Aufwand und Ressourcenbedarf begrenzen lassen.
Wann reicht Retrieval und wann lohnt Training?
In der Praxis empfiehlt sich meist eine schrittweise Vorgehensweise: zunächst Prompting, anschließend RAG und erst danach Fine-Tuning. Mit jeder Stufe steigen Entwicklungs-, Evaluations- und Betriebsaufwand. Fine-Tuning sollte erst geprüft werden, wenn sich das konkrete Problem mit Prompting und RAG nicht ausreichend lösen lässt. Die Entscheidung sollte auf messbaren Qualitätsanforderungen und nicht auf dem Wunsch nach einem vermeintlich eigenen Modell beruhen.
| Stufe | Wirkt auf | Sinnvoll wenn | Grenze |
|---|---|---|---|
| Prompting | Prompting eignet sich vor allem zur Steuerung von Ton, Struktur und Ausgabeformat. | Use-Case ist klein, Korpus existiert nicht | Die Grenzen sind erreicht, wenn dem Modell notwendiges Wissen oder fachliches Verständnis fehlt. |
| RAG | RAG stellt dem Modell zur Laufzeit aktuelle und relevante Informationen bereit. | Wissensbasis ist groß, ändert sich, ist abrufbar | RAG allein löst jedoch nicht jedes Problem bei Fachsprache, Antwortverhalten oder Laufzeit. |
| Tuning | Fine-Tuning kann Verhalten, Stil und den Umgang mit domänenspezifischer Sprache gezielt verändern. | Fine-Tuning kommt infrage, wenn der richtige Kontext bereits vorliegt, die Antworten aber weiterhin systematisch unpassend formuliert oder strukturiert sind. | Ohne geeignete Trainingsdaten, belastbare Evaluation und einen Plan für spätere Aktualisierungen sollte kein Fine-Tuning gestartet werden. |
Fine-Tuning prüfen, wenn
- Eine größere Menge geprüfter Frage-Antwort-Beispiele vorliegt und RAG-Antworten weiterhin zuverlässig das benötigte Format verfehlen
- Fachbegriffe trotz passender Quellen regelmäßig falsch oder ungenau verwendet werden und die Aufgabe klar abgegrenzt ist
- Bei sehr hohem Anfragevolumen Laufzeit und Nutzungskosten eines externen Foundation Models wirtschaftlich unattraktiv werden
RAG bevorzugen, wenn
- Sich die zugrunde liegenden Informationen regelmäßig ändern (Preislisten, Produkt-Kataloge, Tarife)
- Nur wenige oder stark unausgewogene Trainingsbeispiele vorliegen
- Antworten auf konkrete und überprüfbare Quellen verweisen müssen
Fine-Tuning ist keine automatische Weiterentwicklung von RAG. Beide Verfahren lösen unterschiedliche Aufgaben und können sich ergänzen.
Welche Foundation Models lassen sich fine-tunen?
Mosaic AI Training ist für die Anpassung unterstützter Open-Weight-Modelle ausgelegt. Proprietäre Modelle wie GPT oder Claude können nur über die Angebote des jeweiligen Herstellers angepasst werden. Zum unterstützten Angebot gehören unter anderem Modelle aus den Familien Llama, Mistral und DBRX. Da sich die unterstützten Modelle ändern können, sollte vor Projektbeginn die aktuelle Databricks-Dokumentation geprüft werden (Dokumentation zu Foundation Model Training sowie im Bereich Foundation Model Fine-Tuning).
Für das angepasste Modell gelten weiterhin die Lizenzbedingungen des jeweiligen Basismodells. Je nach Modellfamilie unterscheiden sich die Bedingungen für kommerzielle Nutzung, Weitergabe und Kennzeichnung.
Meta Llama Community License (Llama 3.x). Kommerzielle Nutzung erlaubt, mit definierten Schwellen für sehr große Nutzer-Basen und Acceptable-Use-Restrictions. Vor dem Einsatz eines angepassten Llama-Modells in einem Produkt sollten die jeweils gültigen Lizenzbedingungen und möglichen Pflichten geprüft werden.
Apache 2.0 (z. B. Mistral 7B). Apache 2.0 erlaubt eine weitreichende kommerzielle Nutzung, verlangt jedoch die Einhaltung der vorgesehenen Copyright- und Lizenzhinweise.
Menge, Qualität und Governance
Vor jedem Fine-Tuning muss geklärt werden, ob geeignete und ausreichend hochwertige Trainingsdaten vorhanden sind. Entscheidend sind vor allem Umfang, Qualität und Governance.
Menge
Nicht nur die absolute Zahl zählt, sondern wie ausgewogen und repräsentativ die Beispiele verteilt sind. Ein großer, aber unausgewogener Ticketbestand führt dazu, dass das Modell häufige Fälle überlernt und seltene vernachlässigt.
Qualität und Annotation
Fehlerhafte oder uneinheitliche Beispiele führen zu systematischen Qualitätsproblemen. Aus Tickets abgeleitete Paare sollten stichprobenartig fachkundig geprüft werden, nach einem vorab festgelegten Annotations-Leitfaden.
Governance
Trainingsdaten gehören als kontrollierte, versionierbare Objekte in Unity Catalog. Personenbezogene Daten müssen vor dem Training erkannt und maskiert oder pseudonymisiert werden, Herkunft und Version müssen nachvollziehbar dokumentiert sein.
Die Berechtigungs-Mechanik klären wir im Überblick zu Unity-Catalog-Permissions. Für alle verwendeten Inhalte muss zudem geklärt sein, ob sie zu Trainingszwecken genutzt werden dürfen.
In vielen Fine-Tuning-Projekten entstehen die größten Probleme bereits bei Auswahl und Aufbereitung der Daten. Die Wahl des Modells ist erst sinnvoll, wenn diese Grundlage geklärt ist. Vor dem ersten Trainingslauf sollte eine validierte Delta-Tabelle vorliegen, ergänzt um Mengenverteilungen je Klasse und eine manuell geprüfte Stichprobe.
Wie plant man Compute und Kosten in Mosaic AI Training?
Trainings-Compute auf Mosaic AI Training läuft auf verwalteten GPUs in der Databricks-Umgebung. Gegenüber einem selbst betriebenen GPU-Cluster reduziert die verwaltete Umgebung den administrativen Aufwand. Databricks übernimmt einen Teil der Infrastrukturverwaltung, etwa Bereitstellung, Treiber und Skalierung der GPU-Ressourcen (Databricks-Produktseite Mosaic AI Training).
Die Nutzung wird über Databricks-Einheiten und die eingesetzten GPU-Ressourcen abgerechnet, getrennt von Inferenz-Kosten. Da Preise und verfügbare GPU-Klassen variieren können, sollten aktuelle Werte direkt in der Preisübersicht geprüft werden (Databricks-Preis-Seite zu Foundation Model Training). Für eine erste Kostenschätzung sind vor allem drei Faktoren relevant:
GPU-Klasse
Speicher und Leistung der GPU bestimmen, welche Modellgröße trainiert werden kann und wie lange der Lauf dauert.
Job-Dauer
Hängt vor allem von Modellgröße, Datenmenge, Trainingsschritten und Verfahren ab. LoRA ist günstiger als Full-Parameter-SFT.
Anzahl der Trainings-Runs
Meist sind mehrere Trainings- und Vergleichsläufe nötig. Hyperparameter-Vergleiche, Datenkorrekturen und spätere Wiederholungen erhöhen die Zahl deutlich.
Neben dem Training entstehen laufende Kosten für die Bereitstellung und Nutzung des Modells. Ein getuntes Modell auf Model Serving wird pro Endpoint abgerechnet. Fine-Tuning ist wirtschaftlich nur dann günstiger als externe Modellaufrufe, wenn Trainings-, Betriebs- und Inferenzkosten gemeinsam betrachtet werden. Die erwartete Auslastung und der Zeitpunkt einer möglichen Amortisation sollten vor Projektbeginn berechnet werden.
LLM Evaluation mit MLflow, Goldset und LLM-as-a-Judge
LLM Evaluation in Mosaic AI Training stützt sich auf drei zusammengehörige Bausteine: ein Goldset als unabhängige Testbasis, Managed MLflow für Tracking und Vergleich der Runs, und bei freien Textantworten LLM-as-a-Judge für die strukturierte Bewertung. Tracking, Evaluation und Goldset erfüllen dabei unterschiedliche Zwecke und sollten getrennt geplant werden; wer sie vermischt, kann später kaum nachvollziehbar belegen, warum eine Modellversion als besser bewertet wurde.
Tracking
Managed MLflow protokolliert Hyperparameter, Trainings-Metriken, Datenbasis-Version und Modell-Artefakt je Run. Das zeigt aber nicht, wie gut das Modell fachliche Aufgaben löst.
Evaluation
Misst die Modellqualität anhand zuvor definierter Aufgaben und Kriterien, unabhängig von den reinen Trainingsmetriken.
Goldset
Sorgfältig geprüfte Sammlung repräsentativer Testfälle, gegen die das Modell bei jedem Run und Re-Run gemessen wird, nie Teil der Trainingsdaten.
Die Tracking-Mechanik klären wir im Überblick zu Managed MLflow auf Databricks. Je nach Anwendungsfall lassen sich bei der Evaluation drei Bewertungsformen kombinieren:
- Klassische Metriken (Accuracy, F1, BLEU, ROUGE) für strukturierte Outputs.
- Bei freien Textantworten kann ein weiteres Modell zur strukturierten Bewertung eingesetzt werden. Dieses Verfahren wird häufig als LLM-as-a-Judge bezeichnet (siehe Databricks-Dokumentation zu Mosaic AI Agent Evaluation).
- Menschliche Stichproben bleiben notwendig, insbesondere bei fachlich sensiblen oder schwer objektivierbaren Antworten.
Die Beispiele des Goldsets dürfen nicht für das Training verwendet werden. Sonst verfälscht bereits Bekanntes die Evaluation. Der erforderliche Umfang hängt vom Anwendungsfall ab; wichtiger als die reine Zahl sind Abdeckung und Qualität der Testfälle.
Bewertungsmetriken, Goldset und Vergleichsverfahren sollten vor dem ersten Trainingslauf festgelegt werden. Wird das Goldset erst nach Sichtung der Modellergebnisse erstellt, besteht die Gefahr, dass die Testfälle unbewusst zugunsten des vorhandenen Modells ausgewählt werden.
Wie bringt man getunte Modelle in Produktion?
Nach dem Training wird das Modell als versioniertes Artefakt in der Model Registry gespeichert. Die Anbindung an Unity Catalog ermöglicht eine einheitliche Verwaltung von Berechtigungen, Versionen und Herkunftsinformationen. Modell und Trainingsdaten können dadurch innerhalb derselben Governance-Struktur verwaltet werden. Zugriffe auf Modelle und Serving-Endpunkte sollten getrennt und gezielt über die vorgesehenen Berechtigungen gesteuert werden.
Die Registry-Mechanik klären wir im Überblick zu Mosaic AI Model Registry auf Databricks. Wie das registrierte Modell auf einem produktiven Endpoint landet, samt Durchsatz (englisch Throughput) und Inference Tables, klären wir im Überblick zu Model Serving auf Databricks.
Beim produktiven Betrieb sind besonders Versionierung, Protokollierung und Zugriffsrechte wichtig:
Modell-Aliase
Aliase wie @production oder @staging verweisen einen Endpunkt auf eine logische Version. So lässt sich eine frühere Modellversion aktivieren, ohne den Endpunkt neu anzulegen.
Inference Tables
Protokollieren Anfragen, Antworten, Laufzeiten und Nutzungsmetriken für spätere Analysen, Basis für Qualitätskontrollen und die Erkennung veränderter Nutzungsmuster.
Endpoint-Berechtigungen
Werden unabhängig von den Zugriffsrechten auf die Trainingsdaten verwaltet. Nutzer erhalten ausschließlich die Modellantwort, keinen direkten Zugriff auf die Trainingsdaten.
Wie sichert Re-Training die Modellqualität im Betrieb?
Model Drift und Re-Training entscheiden, ob ein getuntes Modell auch nach Wochen oder Monaten noch die Qualität liefert, für die es ursprünglich trainiert wurde. Ein trainiertes Modell verändert sich nicht automatisch, während sich Daten, Sprache und Anforderungen weiterentwickeln. Im Betrieb sollten dafür drei Arten von Veränderungen unterschieden werden:
Daten-Drift
Die Verteilung eingehender Anfragen oder Inhalte verändert sich. Neue Produkte, Begriffe oder Kundengruppen entstehen, bisherige Fälle verlieren an Bedeutung. Protokollierte Inferenzdaten zeigen die Abweichung von den Trainings- und Testdaten.
Modell-Drift gegenüber Foundation-Updates
Neue Generationen des Basismodells lösen Handlungsbedarf aus. Ein Wechsel erfordert eine erneute technische, fachliche und wirtschaftliche Bewertung, keine einfache Konfigurationsänderung.
Aufgaben-Drift
Der eigentliche Anwendungsfall verändert sich, etwa von ticket- zu E-Mail-orientierten Antworten. Das Modell bleibt konsistent, passt aber nicht mehr zur neuen Zielsetzung.
Die Bedingungen für ein späteres erneutes Training sollten bereits vor dem ersten produktiven Einsatz festgelegt werden. Es sollte definiert sein, bei welcher Verschlechterung auf dem Goldset eine Überprüfung oder ein erneutes Training ausgelöst wird. Welche Datenbasis-Updates fließen ins nächste Trainings-Set? Außerdem muss feststehen, wer die Entscheidung über ein erneutes Training trifft. Fehlen solche Regeln, wird jedes erneute Training zu einem separaten und schwer planbaren Projekt. Dadurch steigt das Risiko, dass Modellversionen unter unterschiedlichen und nicht reproduzierbaren Bedingungen entstehen.
Wann rechnet sich ein eigenes Modell?
Für die Kostenbetrachtung müssen einmalige und laufende Aufwände getrennt werden. Zu den einmaligen beziehungsweise wiederkehrenden Projektkosten gehören Datenaufbereitung, GPU-Training, Hyperparameter-Vergleiche und Evaluation. Diese Kosten können bei jeder neuen Modellgeneration erneut entstehen. Im laufenden Betrieb kommen die Kosten für Bereitstellung und Anfragen hinzu: Foundation-Call gegen Inference-Token auf dem eigenen Serving-Endpoint.
Fine-Tuning ist wirtschaftlich vorteilhaft, wenn die Einsparungen bei der Inferenz langfristig höher sind als die zusätzlichen Aufwände für Training, Evaluation, Betrieb und erneute Trainingsläufe. In Kostenrechnungen werden häufig nur GPU-Stunden berücksichtigt, während Evaluation, Monitoring und spätere Aktualisierungen fehlen. Im Betrieb sollten mindestens drei Kostenblöcke berücksichtigt werden:
Eval-Compute
Rechenkosten für regelmäßige Qualitätsprüfungen gegen das Goldset.
Drift-Monitoring
Kosten für die Auswertung der Inferenzdaten und die laufende Überwachung der Modellqualität.
Re-Training
Budget für notwendige Wiederholungen oder den Wechsel auf ein neues Basismodell, klar definierte Qualitäts- oder Datenänderungen als Auslöser, kein pauschaler Zeitplan.
Eine rein kostengetriebene Amortisation setzt häufig ein sehr hohes und dauerhaftes Anfragevolumen voraus. Bei geringerem Volumen liegt der Nutzen eher in besserer Steuerbarkeit, konsistenterem Verhalten oder klareren Betriebs- und Lizenzbedingungen. Kostenersparnis und Qualitätsverbesserung sollten deshalb als getrennte Business Cases bewertet werden.
Extern tunen oder eigener GPU-Cluster?
Je nach Modell, Datenlage und Betriebsanforderung können auch andere Ansätze sinnvoll sein. Drei typische Fälle sprechen für eine Alternative:
Externes Fine-Tuning (OpenAI, Anthropic, Vertex AI)
Sinnvoll, wenn ein proprietäres Modell angepasst werden soll, das Mosaic AI Training nicht unterstützt (GPT-4o-Mini, Claude Haiku). Vertraglich und technisch klären, wie Trainingsdaten verarbeitet und geschützt werden.
Eigener GPU-Cluster (EKS/AKS)
Lohnt bei dauerhaft hoher Auslastung oder sehr speziellen Infrastrukturvorgaben. Das eigene Team übernimmt dafür Bereitstellung, Treiber, Skalierung und Kosten ungenutzter Ressourcen.
Auslagerung an Spezialdienstleister
Sinnvoll für ein einmaliges oder eng abgegrenztes Vorhaben (z. B. domänenspezifische Klassifikation). Betrieb und spätere Trainingsläufe bleiben vom externen Anbieter abhängig.
In einer bestehenden Databricks-Umgebung ist Mosaic AI Training häufig der naheliegende Ausgangspunkt, weil Trainingsdaten, Experimentverfolgung, Modellverwaltung und Bereitstellung innerhalb einer Plattform verbunden werden können. Die Alternativen sollten gezielt anhand konkreter Anforderungen ausgewählt werden.
Grenzen von Databricks Mosaic AI Training
Mosaic AI Training deckt den technischen Prozess der Modellanpassung ab. Es ersetzt weder eine klare Anwendungsstrategie noch die Aufbereitung der Trainingsdaten oder eine unabhängige Evaluation und hat klare Grenzen.
Keine proprietären Modelle
GPT-4o, Claude und andere proprietäre Modelle lassen sich nicht direkt in Mosaic AI Training tunen. Wer auf diese Modelle setzt, bleibt bei Prompting, RAG oder externem Vendor-Tuning.
Kleine Datenmengen tragen kein Fine-Tuning
Bei wenigen Beispielen steigt das Risiko, dass das Modell Muster nur auswendig lernt und außerhalb der Trainingsdaten schlechter generalisiert, ohne messbare Verbesserung.
Schwerpunkt auf Text, nicht Multimodal
Bild-, Audio- und Videomodelle finden hier weniger Unterstützung als bei spezialisierten Multi-Modal-Plattformen. Für reine Text-Modelle ist die Abdeckung breit.
Evaluationspipeline kommt nicht mit
Goldset, LLM-as-a-Judge und Drift-Monitoring sind separate Schritte, die eigenständig aufgebaut werden müssen. Ohne sie lässt sich nicht belastbar beurteilen, ob eine neue Modellversion besser ist.
Re-Training braucht eigene Regeln
Auslöser, Verantwortlichkeiten und Budget für erneutes Training müssen vorab festgelegt werden. Ohne klaren Drift-Trigger wird jedes Re-Training zur Ad-hoc-Frage.
Diese Einschränkungen sprechen nicht grundsätzlich gegen Mosaic AI Training. Sie sollten jedoch vor jedem Fine-Tuning-Projekt in die Architekturentscheidung einfließen. Entscheidend ist, ob Plattform, Modellangebot und Betriebsmodell zu den Anforderungen des konkreten Anwendungsfalls passen. Ist das nicht der Fall, sollte eine alternative Trainings- oder Betriebsform gewählt werden.
Fazit
Mosaic AI Training verbindet die Anpassung eines Foundation Models mit dessen späterer Registrierung und Bereitstellung.
Fine-Tuning und RAG erfüllen unterschiedliche Aufgaben und sollten nicht als aufeinanderfolgende Reifestufen verstanden werden. Wenn RAG die richtigen Inhalte liefert, die Antworten aber weiterhin systematisch zu allgemein oder formal unpassend sind, kann Fine-Tuning sinnvoll sein, sofern geeignete Trainingsdaten, eine unabhängige Evaluation und ein Plan für den späteren Betrieb vorhanden sind.
Die größten Risiken liegen meist nicht im Trainingslauf selbst, sondern in der Vorbereitung. Dazu gehören nachträglich zusammengestellte Testdaten, nicht ausreichend dokumentierte oder versionierte Trainingsdaten und ein produktiver Endpunkt ohne regelmäßige Qualitätskontrolle. Diese Punkte lassen sich vor dem ersten Trainingslauf mit vergleichsweise wenig Aufwand klären. Eine spätere Korrektur ist meist deutlich aufwendiger.
Als Grundregel empfiehlt sich: zunächst RAG einsetzen und Fine-Tuning erst bei einer klar belegten Lücke in Verhalten, Fachsprache oder Ausgabeformat prüfen. Vor dem ersten Trainingslauf sollten drei Grundlagen vorhanden sein: eine validierte und versionierte Trainingsbasis mit dokumentierter Verteilung der Beispiele, ein unabhängiges, fachlich geprüftes Goldset, das nicht für das Training verwendet wird, und festgelegte Kriterien, anhand derer eine Verschlechterung im laufenden Betrieb erkannt wird. Model Registry und Model Serving sollten von Beginn an in den Betriebsprozess integriert werden. Wer Versionierung, Berechtigungen und Monitoring erst nach dem Prototyp ergänzt, verursacht meist erheblichen Zusatzaufwand.
FAQ
Fine-Tuning lohnt sich, wenn RAG den richtigen Kontext holt, die Antworten aber im Stil, Vokabular oder Antwort-Format konsistent danebenliegen. Faustregel: ab rund 10.000 hochwertig annotierten Q&A-Paaren mit klarem Format-Problem prüfen; darunter ist RAG meist die wirtschaftlichere Antwort. RAG bleibt erste Wahl, wenn Faktenwissen sich häufig ändert oder Compliance Quellen-Belege verlangt.
