Fine-Tuning gehört zu den meistgenannten Begriffen in jedem KI-Roadmap-Dokument. „Wir trainieren ein eigenes Modell, das unsere Domäne versteht." In der Theorie elegant. In der Praxis haben wir erlebt, wie dasselbe Vorhaben an sieben verschiedenen Stellen gescheitert ist — jedes Mal aus einem anderen Grund. Dieser Artikel handelt nicht davon, wie man Fine-Tuning durchführt — er handelt davon, warum die Mehrheit der Versuche die Produktion nie erreicht, und wie man diesen Fallen ausweicht, bevor sie Zeit und Budget kosten.
Wenn Sie noch abwägen, ob Sie überhaupt zum Fine-Tuning greifen oder lieber zu RAG, lesen Sie zuerst RAG vs. Fine-Tuning — welcher Ansatz für Ihre Wissensbasis. Die Ursachen des Scheiterns, die wir unten beschreiben, beginnen nämlich genau dort.
---
1. Zu wenig Daten — oder Daten minderer Qualität
Dies ist die häufigste Ursache des Scheiterns. Das Team sammelt, was es hat — ein paar hundert interne Dokumente, einen CRM-Export, ein paar exportierte E-Mails — und startet das Training. Das Ergebnis ist ein Modell, das mit hoher Zuversicht falsch antwortet: schlechter als das Basismodell, das immerhin „ich weiß es nicht" sagen kann.
Die Forschung hat gezeigt (LIMA und weitere Arbeiten), dass eine verhältnismäßig kleine Anzahl hochwertiger Beispiele — in der Größenordnung von tausend — ein besseres Modell erzeugen kann als Zehntausende minderwertiger Beispiele. Quantität ohne Qualität ist in diesem Fall aktiv schädlich.
Praktische Richtwerte:
- SFT (Supervised Fine-Tuning): Minimum ca. 1.000 hochwertige Frage-Antwort- oder Task-Completion-Paare mit Abdeckung der wichtigsten Themen Ihrer Domäne. Produktionssysteme liegen typischerweise bei 10.000–100.000 Beispielen.
- DPO (Preference Tuning): ca. 2.000 Präferenzpaare mit menschlich verifizierten Winner/Loser-Urteilen.
- GRPO (RL-based Tuning): ca. 1.000 bewertete Trajektorien mit verifizierbaren Belohnungen.
Neben der Anzahl kommt es auf die Abdeckung an — wenn Ihre KB (Knowledge Base) nicht genug Beispiele aus einer bestimmten Teildomäne enthält, wird das Modell in diesem Bereich halluzinieren. Wir empfehlen daher vor dem Trainingsstart einen Topic-Coverage-Audit: Notieren Sie die wichtigsten Fragekategorien, die das Modell abdecken soll, und prüfen Sie, ob in jeder davon ausreichend Beispiele vorhanden sind.
---
2. Overfitting — das Modell kennt nur, was es gesehen hat
Wenn der Datensatz zu klein oder zu eng ist und das Modell zu lang darauf trainiert wird, tritt Overfitting auf. Das Modell liefert hervorragende Ergebnisse auf den Trainingsbeispielen, versagt aber bei jeder Abweichung — einer etwas anders formulierten Frage, einem anderen Kontext, einer ungewöhnlichen Eingabe — vollständig oder halluziniert.
Zeichen von Overfitting in der Praxis:
- Das Modell zitiert Trainingsbeispiele buchstäblich, anstatt zu generalisieren.
- Auf Trainingsdaten hohe Scores, auf neuen Beispielen deutlich niedrigere.
- Das Modell verweigert Antworten auf Fragen außerhalb der Trainingsverteilung, anstatt Unsicherheit einzugestehen.
Technische Gegenmaßnahmen: Überwachen Sie den Validation Loss während des Trainings und stoppen Sie, wenn er anfängt zu steigen (Early Stopping). Beobachten Sie Eval-Metriken auf einem Hold-out-Set, nicht nur auf Trainingsdaten. Bei kleinen Datensätzen sind Regularisierung und niedrigere rank-Werte bei LoRA-Adaptern (z. B. rank=8 statt rank=64) die bessere Einstellung.
---
3. Catastrophic Forgetting — das Modell vergisst, was es wusste
Fine-Tuning auf engen Domänendaten kann die allgemeinen Fähigkeiten des Modells degradieren — die Fähigkeit zu analysieren, zusammenzufassen, auf Englisch oder anderen Sprachen zu denken, grundlegende Logik anzuwenden. Dieser Effekt wird als Catastrophic Forgetting (katastrophales Vergessen) bezeichnet und ist gut dokumentiert.
In der Praxis sieht das so aus: Durch Fine-Tuning auf internen technischen Dokumenten erreichen Sie, dass das Modell Fragen aus Ihrem Fachbereich hervorragend beantwortet — aber es hört auf, bei allgemeinen Aufgaben zu funktionieren, die es zuvor problemlos erledigte. Kunden, die diesen Effekt nicht kennen, interpretieren ihn als „das Modell ist kaputt gegangen".
Was das Problem mildert, aber nicht beseitigt:
- LoRA / QLoRA — Adapter ändern nur eine geringe Anzahl von Parametern, die ursprünglichen Gewichte bleiben eingefroren. Dies ist der effektivste praktische Weg, Forgetting zu begrenzen.
- Merging — das fine-getunte Modell wird mit dem Basismodell über Tools wie
mergekitzusammengeführt (SLERP, TIES). Das Ergebnis balanciert Domänenwissen und allgemeine Fähigkeiten. - Diversifizierung des Datensatzes — Einbindung allgemeiner Beispiele in den Trainingsdatensatz zusammen mit domänenspezifischen.
Für regulierte Branchen (Medizin, Recht, Pharma) ist Forgetting besonders kritisch — ein Modell, das Logik und Sicherheitsmuster vergessen hat, kann inhaltlich überzeugend wirkende, aber faktisch falsche Ausgaben produzieren.
---
4. Falsche Methodenwahl — volles Fine-Tuning wo LoRA reicht, oder umgekehrt
Teams, die mit Fine-Tuning beginnen, neigen dazu, entweder ins Extrem zu gehen (volles Fine-Tuning, das enorme GPU-Ressourcen erfordert) oder umgekehrt die sparsamste Variante zu wählen, ohne über die Trade-offs nachzudenken.
Orientierung zu VRAM-Anforderungen für ein 7B-Modell:
- Volles Fine-Tuning (BF16): ca. 70–120 GB — erfordert einen Multi-GPU-Server
- LoRA (16-bit): ca. 15 GB — A100 oder eine RTX 4090 (24 GB VRAM)
- QLoRA (4-bit): ca. 5 GB — passt auf eine RTX 3090 mit 24 GB VRAM
LoRA erreicht typischerweise ca. 90–95 % der Qualität von vollem Fine-Tuning bei 10–20× niedrigerer Speicheranforderung. Für die meisten domänenspezifischen Use-Cases ist das ausreichend — volles Fine-Tuning ohne klare Begründung einzusetzen ist Ressourcenverschwendung.
Auf der anderen Seite gibt es Fälle, in denen LoRA nicht ausreicht: wenn der Tokenizer geändert wird, wenn es sich um Sprachen mit sehr unterschiedlicher Morphologie von den Trainingsdaten handelt, oder bei tiefem „Continued Pretraining" (Aufbau von Domänenwissen aus unmarkierten Texten). Die Methodenwahl sollte aus dem konkreten Ziel folgen, nicht daraus, was zufällig als erstes gestartet wurde. Eine detailliertere Übersicht finden Sie im Artikel LoRA vs. QLoRA vs. volles Fine-Tuning.
---
5. Fine-Tuning statt RAG — das falsche Werkzeug für die falsche Aufgabe
Dies ist möglicherweise der teuerste Irrtum, dem wir begegnen. Das Team möchte, dass das Modell über ihre Produkte, Dokumente und internen Prozesse „Bescheid weiß". Fine-Tuning erscheint als natürliche Antwort. Sie starten es, schütten die Daten ins Training, und stellen nach einigen Wochen fest, dass das Modell noch immer Fakten halluziniert — weil Fine-Tuning Fakten unzuverlässig ins Modell schreibt.
Fine-Tuning ist das richtige Werkzeug für:
- Die Änderung von Format und Antwortstil (z. B. immer JSON mit einem bestimmten Schema zurückgeben).
- Die Änderung von Verhalten (z. B. das Modell soll bestimmte Anfragen stets ablehnen oder einen konkreten Kommunikationston einhalten).
- Die Anpassung an eine spezialisierte Domäne, in der das Basismodell nicht ausreichend Trainingsdaten hat (z. B. enger Industriejargon, proprietäre Formate).
RAG (Retrieval-Augmented Generation — durch Retrieval angereicherte Generierung) ist das richtige Werkzeug für:
- Zugriff auf aktuelle oder sich ändernde Informationen.
- Beantwortung von Fragen auf Basis konkreter Dokumente.
- Rückverfolgbarkeit der Antwort zur Quelle (Zitat, Grounding).
In der Praxis: Wenn Ihr Ziel ist, dass „das Modell Fragen aus unserem Produktkatalog beantworten soll" — das ist ein RAG-Use-Case, kein Fine-Tuning. Fine-Tuning würden Sie einsetzen, wenn das Modell Ihr spezifisches Antwortformat oder die Terminologie Ihrer Branche verwenden soll.
---
6. Kein Eval — wir wissen nicht, ob wir etwas gewonnen oder verloren haben
Ein überraschend häufiges Szenario: Das Team startet Fine-Tuning, das Modell wird trainiert, wirkt auf einigen manuell getesteten Beispielen „besser", und geht in die Produktion. Einen Monat später kommen Beschwerden über Regressionen — das Modell funktioniert nicht mehr bei Fällen, die es zuvor problemlos gelöst hat.
Ohne systematische Evaluation (Qualitätsbewertung des Modells) wissen wir nicht:
- 1.Ob Fine-Tuning überhaupt geholfen hat — Vergleich mit dem Basismodell.
- 2.Ob wir eine Regression verursacht haben — Leistung bei zuvor funktionierenden Fällen.
- 3.Wo genau das Modell versagt — in welchen Fragekategorien.
Ein minimales Eval-Framework vor dem Produktionsdeployment enthält:
- Hold-out-Test-Set — ca. 10–20 % der Daten, die weder im Trainings- noch im Validierungs-Set waren. Darauf messen Sie nach dem Training.
- Baseline-Vergleich — dieselben Fragen an das Basismodell und die fine-getunte Version. Regression = wenn das fine-getunte Modell bei Fällen schlechter abschneidet, bei denen das Basismodell funktioniert hat.
- Task-spezifische Metriken — nicht nur Perplexität (eine technische Metrik des maschinellen Lernens), sondern für Ihren Use-Case relevante Metriken: Extraktionsgenauigkeit, Formatrichtigkeit, Qualitätsbewertung durch einen Domänenexperten.
Mehr zur Einrichtung der Evaluation: Wie man misst, ob Fine-Tuning geholfen hat.
---
7. Unrealistische Erwartungen — Fine-Tuning ist kein Wundermittel
Der letzte, aber in vielerlei Hinsicht wichtigste Grund. Fine-Tuning wird in internen Präsentationen häufig als Lösung verkauft, die aus einem generischen LLM einen Experten für Ihre Domäne macht. In der Praxis ist es differenzierter:
- Ein fine-getuntes 4B–8B-Modell kann ein generisches 70B+-Modell bei eng definierten Tasks übertreffen — aber nur wenn der Task wirklich eng definiert ist, die Daten qualitativ hochwertig sind und das Eval dies bestätigt.
- Fine-Tuning verbessert kein Reasoning — wenn das Basismodell einen bestimmten Typ logischer Aufgaben nicht lösen kann, ändert Fine-Tuning auf Domänendaten daran nichts. Für Reasoning sind Methoden wie GRPO mit verifizierbaren Belohnungen geeignet. Mehr dazu im Artikel SFT, DPO, GRPO — welche Methode wann.
- Fine-Tuning ist kein einmaliges Projekt — Daten ändern sich, das Modell altert, Regressionen häufen sich. Ohne Infrastruktur für wiederholbare Train-Eval-Deploy-Zyklen zerfällt das Projekt nach und nach.
- Halluzinationen bleiben — Fine-Tuning kann sie in einer spezifischen Domäne reduzieren, aber nicht beseitigen. Guardrails, RAG-Grounding und Human-in-the-Loop sind nach wie vor notwendig, wo Korrektheit zählt.
Teams, die diese Grenzen kennen, bevor sie ein Projekt starten, enden mit nutzbaren Modellen. Teams, die die Grenzen nach sechs Monaten Entwicklung kennenlernen, stellen das Projekt in der Regel ein.
---
Zusammenfassung: Checkliste vor dem Projektstart
Bevor Sie sich entscheiden, ein Fine-Tuning-Projekt zu starten, empfehlen wir, diese sieben Fragen durchzugehen:
- 1.Haben Sie einen ausreichenden Datensatz? — Anzahl der Beispiele, Themenabdeckung, verifizierte Qualität.
- 2.Ist Fine-Tuning das richtige Werkzeug? — oder würde RAG oder Prompt Engineering ausreichen?
- 3.Haben Sie Eval eingerichtet? — Hold-out-Set, Baseline, task-spezifische Metriken.
- 4.Haben Sie GPU-Infrastruktur? — oder einen realistischen Plan für Cloud-Training mit Kostenschätzung.
- 5.Sind Sie bereit zu iterieren? — ein einzelner Fine-Tuning-Run reicht nicht, die Pipeline muss wiederholbar sein.
- 6.Haben Sie einen Domänenexperten in der Schleife? — wer verifiziert, dass das Modell korrekt antwortet, nicht nur flüssig.
- 7.Haben Sie einen Plan für Forgetting und Regressionen? — Monitoring, Rollback, Eval nach jedem neuen Trainings-Run.
Wenn eine dieser Fragen keine klare Antwort hat, ist das Projekt nicht startklar — sondern vorbereitung-bereit.
---
Häufige Fragen
Warum antwortet mein fine-getuntes Modell schlechter als das Basismodell?
Die häufigste Ursache ist Overfitting auf einem kleinen oder minderwertigen Datensatz. Das Modell lernt „Muster" aus den Trainingsdaten, aber die Generalisierung auf neue Eingaben schlägt fehl. Lösung: Datenqualität erhöhen, Early Stopping verwenden, den Rank des LoRA-Adapters reduzieren oder das gesamte Projekt aus der RAG-vs.-Fine-Tuning-Perspektive neu bewerten.
Wie viele Beispiele brauche ich wirklich für Fine-Tuning?
Für SFT ist ein funktionsfähiges Ergebnis ab ca. 1.000 hochwertigen Beispielen möglich, aber Produktionssysteme liegen typischerweise bei 10.000–100.000. Wichtiger als die Quantität ist die Abdeckung — fehlt eine ausreichende Stichprobe in Schlüsselkategorien, wird das Modell in diesen Bereichen unzuverlässig sein, unabhängig von der Gesamtanzahl der Beispiele.
Eignet sich Fine-Tuning zur Aktualisierung des Modellwissens (neue Produkte, Preise, Einträge)?
Nein. Fine-Tuning speichert Fakten unzuverlässig — das Modell kann Informationen aus dem Training andeuten, mischt sie aber auch mit Halluzinationen. Für Wissen, das sich ändert oder verifizierbar sein muss, ist RAG mit einer aktuellen Dokumentendatenbank das richtige Werkzeug.
Kann ein kleines fine-getuntes Modell ein großes generisches Modell übertreffen?
Ja — unter konkreten Bedingungen. Ein fine-getuntes 4B–8B-Modell kann bei einem eng definierten Task ein generisches 70B+-Modell übertreffen, wenn der Task gut abgegrenzt ist, der Datensatz qualitativ hochwertig ist und das Eval dies bestätigt. Bei breiten, allgemeinen Aufgaben gewinnt das größere Modell in der Regel.
Was ist Catastrophic Forgetting und wie beugt man ihm vor?
Catastrophic Forgetting ist ein Effekt, bei dem Fine-Tuning auf engen Daten die allgemeinen Fähigkeiten des Modells degradiert — Sprachen, Logik, Reasoning. Die effektivste Gegenmaßnahme ist LoRA oder QLoRA, die nur eine geringe Anzahl von Parametern ändern und die ursprünglichen Gewichte erhalten. Ergänzend hilft das Merging des fine-getunten Modells mit dem Basismodell über das Tool mergekit.
---
*MP Industrial Solutions hilft Unternehmen zu unterscheiden, wann Fine-Tuning wirklich sinnvoll ist und wann es einen einfacheren und günstigeren Weg gibt. Wenn Sie eine Domänenadaption eines LLM in Betracht ziehen, bewerten wir Ihren Use-Case gerne — vom Datensatz bis zur Infrastruktur und Evaluation.*