Nach dem Fine-tuning haben Sie ein neues Modell. Der Benchmark auf der Trainingsaufgabe ist gestiegen. Das Team freut sich. Doch sobald Sie das Modell in Produktion bringen, melden Kunden seltsame Antworten bei Fällen, die vor dem Training einwandfrei funktionierten. Was ist passiert? Es ist etwas eingetreten, das wir immer wieder sehen: Das Modell wurde nur an dem evaluiert, was wir ihm beigebracht haben — nicht an dem, was wir ihm unbeabsichtigt wieder abgewöhnt haben.
Die Evaluation eines fine-getunten Modells ist eine andere Disziplin als die Evaluation eines produktiven LLM-Systems. Sie vergleichen nicht, ob Ihre RAG-Pipeline die richtigen Chunks zurückliefert — Sie vergleichen, was eine konkrete Gewichtsänderung mit dem Modell als Ganzem gemacht hat. Dieser Artikel zeigt, wie Sie dabei systematisch vorgehen: vom task-spezifischen Eval-Set über den Vergleich Base vs. Fine-tuned bis zur Regressionserkennung bei allgemeinen Fähigkeiten.
Warum „Loss ist gesunken" nicht reicht
Der Trainingsverlust (Training Loss) sagt Ihnen, wie gut sich das Modell an die Trainingsdaten angepasst hat. Er sagt Ihnen nichts darüber, ob sich das Verhalten des Modells in der Praxis verbessert hat. Und er sagt Ihnen erst recht nicht, was mit dem Modell außerhalb der trainierten Domäne passiert ist.
In der Praxis sehen wir drei häufige Fehler:
- Nur auf Trainingsdaten evaluieren — das Modell hat Muster auswendig gelernt, nicht gelernt zu generalisieren
- Nur die Zielaufgabe testen — allgemeine Fähigkeiten ignorieren, die Fine-tuning beschädigt haben könnte
- Keinen Vergleich mit dem Base-Modell ziehen — Sie wissen nicht, was der Mehrwert des Fine-tunings ist und was von vornherein die Fähigkeit des Base-Modells war
Katastrophisches Vergessen (catastrophic forgetting) ist ein reales Phänomen, empirisch dokumentiert auf mehreren Modell-Familien. Fine-tuning auf engen Daten kann Fähigkeiten degradieren, die das Modell während des Pretrainings erworben hat — logisches Schlussfolgern, Formatierung, Instruktionsfolgen, Wissen außerhalb der Domäne. PEFT-Methoden wie LoRA verringern dieses Risiko, eliminieren es aber nicht.
Die drei Schichten des Eval-Frameworks
Ein solides Eval eines fine-getunten Modells stützt sich auf drei Schichten. Jede erfasst ein anderes Risiko.
1. Task-spezifisches Eval-Set
Das ist Ihr primäres Signal. Es misst, ob das Modell das beherrscht, wofür Sie es trainiert haben.
Kernprinzip: Held-out Test-Set. Ein Teil der annotierten Daten, den das Modell während des Trainings nie gesehen hat, muss ausschließlich für die abschließende Evaluation reserviert bleiben. Wenn Sie dieselben Daten für Training und Eval verwenden, ist die Messung wertlos — das Modell könnte auswendig gelernt haben, anstatt zu lernen.
Praktisches Vorgehen: 1. Teilen Sie den Datensatz vor dem Training in Training / Validierung / Test auf (z. B. 80 / 10 / 10) 2. Das Validierungsset dient zur Beobachtung während des Trainings (Early Stopping, Hyperparameter-Tuning) 3. Das Test-Set wird einmal verwendet — erst wenn das Training abgeschlossen ist, nicht wiederholt zum Justieren
Für die eigentliche Messung benötigen Sie eine Evaluation mit definierter richtiger Antwort für Ihre Aufgabe. Die Formate variieren je nach Task-Typ:
- Klassifikation / Routing — Accuracy, F1-Score, Confusion Matrix
- Entity Extraction / strukturierter Output — Token-Level F1, Exact Match oder Custom Parser
- Generative Tasks — hier wird es komplizierter: BLEU/ROUGE korrelieren schlecht mit menschlicher Qualität bei LLMs; besser sind LLM-as-Judge (ein Frontier-Modell bewertet die Antwort) oder eigene Rubrics
Für die meisten B2B-Domain-Use-Cases empfehlen wir, 100–500 Fragen mit Referenzantworten manuell zu erstellen, geprüft von einem Domain-Experten. Das ist Ihr Goldstandard. Die Menge ist nicht entscheidend — entscheidend ist die Abdeckung der Falltypen und Edge Cases, die in der Praxis am wichtigsten sind.
2. Vergleich Base vs. Fine-tuned
Evaluieren Sie das fine-getunte Modell immer im Vergleich mit dem Base-Modell, nicht nur absolut. Der Grund: Sie müssen wissen, was Fine-tuning gegenüber dem, was Sie bereits kostenlos erhalten haben, wirklich hinzugefügt hat.
Eine typische Ergebnistabelle sollte enthalten:
- Base-Modell (ohne Fine-tuning) auf Ihrem task-spezifischen Test
- Fine-getuntes Modell auf demselben Test
- Delta (Verbesserung oder Verschlechterung)
Wenn das fine-getunte Modell das Base-Modell nur um marginale 2–3 % übertrifft, prüfen Sie kritisch, ob es die Wartungskosten rechtfertigt. Wenn das Delta negativ ist, haben Sie ein Problem — entweder mit der Datenqualität oder mit den Trainingseinstellungen.
Der Vergleich zeigt auch, wann Fine-tuning keine Lösung ist. Wir haben Fälle gesehen, in denen das Base-Modell mit einem gut konfigurierten Prompt (System-Prompt, Few-Shot-Beispiele) 90 % dessen erreichte, was das fine-getunte Modell lieferte — bei null Trainingskosten und ohne Regressionsrisiko. Für diese Fälle haben wir Kunden empfohlen, RAG vs. Fine-tuning — Entscheidungshilfe als ersten Schritt vor dem Training durchzugehen.
3. Regression bei allgemeinen Fähigkeiten
Das ist die Schicht, die die meisten Teams überspringen — und genau hier verbergen sich die Probleme, die erst in Produktion sichtbar werden.
Fine-tuning auf einer engen Domäne kann Schaden anrichten bei:
- Instruktionsfolgen — das Modell beginnt, Teile des Prompts zu ignorieren, das Antwortformat zu ändern
- Ablehnung bei Out-of-Domain-Fragen — das Modell versucht, domänenbezogen auf Fragen zu antworten, bei denen es „das weiß ich nicht" sagen sollte
- Logischem Schlussfolgern — Ergebnisse bei Reasoning-Tasks können sinken
- Sprachlichen Fähigkeiten — wenn Sie auf einer Sprache trainiert haben, können andere Sprachen degradieren
Zur Regressionserkennung kombinieren wir mehrere Ansätze:
a) Standard-Benchmarks als Sanity Check
lm-evaluation-harness von EleutherAI ermöglicht es, das Modell auf Standard-Benchmarks laufen zu lassen (MMLU und ähnliche). Erwarten Sie nicht, dass das fine-getunte Modell beim MMLU besser abschneidet als das Base — das ist nicht das Ziel. Sie beobachten, ob es deutlich gesunken ist (mehr als einige Punkte ist ein Grund zur Untersuchung).
b) Behavioral Regression Set
Erstellen Sie einen eigenen Beispielsatz, der Fähigkeiten abdeckt, die für Ihre Anwendung wichtig sind, aber nicht direkt mit der Trainingsdomäne zusammenhängen. Zum Beispiel: - Ausgabeformatierung (JSON, Markdown, Tabellen) - Ablehnung unsinniger Fragen - Instruktionsfolgen (Befolgen mehrerer Bedingungen in einem Prompt) - Faktische Genauigkeit in Bereichen außerhalb der Domäne
Diesen Set können Sie einmal zusammenstellen und bei jeder weiteren Fine-tuning-Runde wiederverwenden. Die Investition zahlt sich bei der dritten und vierten Runde aus, wenn Sie ohne ihn den Überblick verlieren.
c) Vergleich der Antwortverteilung
Ein pragmatischer Ansatz: Nehmen Sie 200–500 reale Eingaben aus der Produktion (oder Staging), lassen Sie sowohl das Base- als auch das fine-getunte Modell darüber laufen, und vergleichen Sie die Verteilung der Antwortlängen, die Häufigkeit von Ablehnungen und — wenn Sie LLM-as-Judge konfiguriert haben — die Bewertungsverteilung. Statistische Abweichungen signalisieren ein Problem, bevor es Nutzer melden.
Held-out Test-Set aufsetzen: Was schiefläuft
Ein Held-out Test-Set klingt einfach, scheitert in der Praxis aber an mehreren Stellen.
Verteilungskontamination: Wenn Sie Trainingsdaten synthetisch generiert haben (Teacher-Modell) und das Test-Set mit demselben Prozess erstellt wurde, messen Sie nur, wie gut das Modell den Teacher imitiert — nicht, wie gut es die reale Aufgabe löst. Das Test-Set muss aus echten Fällen stammen oder von einem Domain-Experten geprüft worden sein.
Zeitliche Trennung: Bei Produktionssystemen mit regelmäßigem Fine-tuning ist es kritisch, dass das Test-Set zeitlich von der Trainingsmenge getrennt ist. Wenn Sie auf Q1-Daten trainieren und auf Q1-Daten testen (selbst einer separaten Teilmenge), erkennen Sie möglicherweise den Verteilungsshift nicht, der in Q2 auftritt. Idealerweise stammt das Test-Set aus einem anderen Zeitfenster als das Training.
Größe und Repräsentativität: Ein Test-Set mit 50 Beispielen ist für die meisten Aufgaben zu klein für statistisch zuverlässige Schlüsse. Für binäre Klassifikation benötigen Sie in der Größenordnung 300–500 Beispiele, damit das 95%-Konfidenzintervall schmal genug für Entscheidungen ist. Für generative Tasks mit LLM-as-Judge sind kleinere Sets verwendbar, aber interpretieren Sie mit Vorsicht.
Leakage durch Augmentierung: Wenn Sie für die Augmentierung von Trainingsdaten Paraphrasen oder Variationen realer Beispiele verwendet haben, überprüfen Sie, dass keine Variante ins Test-Set gelangt ist.
Praktische Eval-Pipeline Schritt für Schritt
Für Teams, die Fine-tuning zum ersten Mal oder nur gelegentlich durchführen, empfehlen wir dieses minimalistische Vorgehen:
- 1.Vor dem Training: Reservieren Sie das Test-Set (mindestens 10 % der Daten, verwenden Sie es nie beim Training), protokollieren Sie die Baseline-Scores des Base-Modells auf dem task-spezifischen Eval und dem Behavioral Regression Set.
- 1.Während des Trainings: Beobachten Sie den Validierungsverlust (Val Loss) — er sollte gemeinsam mit dem Trainingsverlust sinken. Wenn Val Loss stagniert oder steigt, während Train Loss sinkt, übertrainieren Sie das Modell. Stoppen Sie das Training und versuchen Sie es mit weniger Epochen oder einem größeren
rankdes Adapters.
- 1.Nach dem Training: Lassen Sie das Modell auf dem task-spezifischen Test-Set laufen. Vergleichen Sie mit dem Base-Modell. Lassen Sie das Behavioral Regression Set laufen. Vergleichen Sie mit dem Base-Modell.
- 1.Vor dem Deployment: LLM-as-Judge auf einer Stichprobe realer Eingaben (falls vorhanden). Manuelle Prüfung von mindestens 20–30 konkreten Fällen — Zahlen täuschen, das Lesen von Antworten zeigt Muster, die Metriken übersehen.
Die gesamte Pipeline können Sie mit Tools wie lm-evaluation-harness, einem eigenen Python-Skript über vLLM oder Ollama oder Cloud-Eval-Plattformen umrahmen. Für die meisten maßgeschneiderten B2B-Projekte reicht ein eigenes Skript aus — überschätzen Sie die Infrastruktur nicht, wenn Sie nur eine zuverlässige Antwort auf die Frage „ist das Modell besser" benötigen.
Wann ist eine Regression zu groß zum Akzeptieren
Es gibt keine universelle Grenze. Es hängt vom Use-Case ab. Einige Orientierungsregeln:
Die task-spezifische Verbesserung muss die Regression bei allgemeinen Fähigkeiten überwiegen. Wenn Fine-tuning die Domänen-Accuracy um 15 Punkte verbessert hat, das Instruktionsfolgen aber um 20 % gesunken ist, ist das Ergebnis negativ — ein schlechtes Antwortformat macht das Modell selbst in der Domäne, in der Sie es verbessert haben, weniger brauchbar.
Null Verbesserung beim task-spezifischen Test ist ein Grund aufzuhören. Wenn das Base-Modell mit Few-Shot-Prompts dieselben Ergebnisse erzielt wie das fine-getunte Modell, war Fine-tuning nicht notwendig. Das sehen wir bei Kunden häufiger, als man erwarten würde — sie unterschätzen, was ein guter Prompt leistet.
Deutliche Regression beim Ablehnen von Out-of-Domain-Fragen ist ein ernstes Problem. Ein Modell, das darauf trainiert wurde, technische Anfragen zu einem bestimmten Produkt zu beantworten, darf nicht beginnen, auch auf Fragen mit Halluzinationen zu antworten, bei denen die richtige Antwort „das weiß ich nicht" wäre. Diese Regression ist ein direktes Sicherheitsrisiko in regulierten Branchen. Das hängt mit dem Thema Guardrails für KI-Agenten zusammen, wo der Ablehnungsmechanismus die erste Verteidigungslinie ist.
Kontinuierliche Evaluation: wenn Sie Fine-tuning wiederholen
Domain-Modelle werden nicht einmal getunet — wenn Sie es richtig machen, bringt jede neue Runde Daten eine neue Fine-tuning-Runde. In diesem Fall ist systematische Evaluation noch wichtiger, weil Sie den Trend über Iterationen hinweg verfolgen müssen, nicht nur absolute Zahlen.
Wir empfehlen, für jede Runde eine einfache Aufzeichnung zu führen: - Datum des Trainings und Modellversion (Base + Fine-tuned) - Größe des Trainingssets und Datenquelle - Task-spezifische Scores (Base / Fine-tuned / Delta) - Behavioral Regression Score - Notizen zu Anomalien oder manueller Prüfung
Diese Aufzeichnung ist eine Investition, die sich beim Debuggen einer Regression im Produktionssystem auszahlt. Ohne sie passiert es, dass das Team weiß „etwas hat sich nach dem letzten Training geändert" — aber nicht was, wann und warum.
Für Teams, die regelmäßiges Fine-tuning mit einem Zyklus von weniger als einem Monat planen, lohnt es sich, über eine automatisierte Eval-Pipeline nachzudenken — jeder Commit eines neuen Modells startet automatisch den task-spezifischen Eval und den Regression Set und protokolliert die Ergebnisse. Diese Investitionsstufe macht bei Produktionssystemen Sinn, bei denen das Modell direkt in der Flotte von Kundeninteraktionen steckt.
Häufige Fragen
Wie viele Beispiele brauche ich im Test-Set?
Für die meisten B2B-Domain-Aufgaben empfehlen wir mindestens 100–300 manuell geprüfte Beispiele. Unter 100 ist die statistische Zuverlässigkeit niedrig — ein kleiner Datensatz erschwert die Unterscheidung zwischen echter Verbesserung und zufälliger Streuung. Für binäre Klassifikation ist 300–500 eine vernünftige Untergrenze für das 95%-Konfidenzintervall. Für generative Tasks mit LLM-as-Judge können Sie mit einem kleineren Set arbeiten, aber interpretieren Sie mit größerer Vorsicht.
Was ist LLM-as-Judge und wann sollte ich ihn verwenden?
LLM-as-Judge ist eine Technik, bei der ein Frontier-Modell (z. B. aus der Claude Sonnet- oder GPT-Familie) die Antworten des fine-getunten Modells anhand definierter Kriterien bewertet — Genauigkeit, Relevanz, Format, Ton. Es ist nützlich für generative Tasks, bei denen es keine eindeutige „richtige Antwort" gibt. Nachteile: Es verursacht Kosten (API-Aufrufe), und der Judge kann eigene Biases haben (bevorzugt längere Antworten, formellen Stil). Für B2B-Domain-Anwendungen empfehlen wir eine Kombination: LLM-as-Judge für Gesamtqualität + deterministische Metriken (Exact Match, Parser) für kritische Felder.
Wie erkenne ich katastrophisches Vergessen ohne aufwendigen Benchmark-Set?
Pragmatisches Vorgehen: Nehmen Sie 50–100 reale Prompts, die das Modell vor dem Fine-tuning korrekt beantwortet hat, und prüfen Sie, ob es sie auch nach dem Training noch beherrscht. Wenn Sie Zugang zu den Logs des Produktionssystems haben, schauen Sie sich Beispiele mit hohen Nutzerbewertungen an — diese sind eine gute Quelle für das Behavioral Regression Set. Kombiniert mit einer schnellen manuellen Durchsicht von 20–30 Antworten zeigt das die meisten Probleme, bevor sie zum Kunden gelangen.
Warum sinkt Val Loss, aber die Antwortqualität verbessert sich nicht?
Klassischer Fall von Overfitting oder einem Verteilungsmismatch zwischen Training und realem Einsatz. Der Validierungsverlust sinkt, wenn das Modell das Validierungsset besser fittet — aber wenn das Validierungsset die realen Eingaben nicht widerspiegelt, ist dieser Verlust ein schlechter Proxy für die tatsächliche Qualität. Weiterer Grund: zu niedrige learning rate oder zu niedriger rank des Adapters, sodass das Modell nur oberflächliche Muster erlernt hat. Versuchen Sie, den rank zu erhöhen (z. B. von 8 auf 16 oder 32) und zu überprüfen, ob das Validierungsset repräsentativ ist. Verwandtes Thema: warum Fine-tuning scheitert.
Wann macht es Sinn, Fine-tuning zu wiederholen statt RAG zu nutzen?
Wiederholen Sie Fine-tuning, wenn sich die Domäne stabilisiert hat und Sie einen konsistenten Zufluss neuer annotierter Beispiele aus der Produktion haben. Wenn sich das Domänenwissen schnell ändert (neue Produkte, geänderte Regulierungen), ist RAG flexibler — eine Änderung schreiben Sie in die Knowledge Base, nicht in die Modellgewichte. Für die Entscheidung über die Kombination beider Ansätze lesen Sie Fine-tuning-Datensatz — wie viel und welche Qualität.
*Wenn Sie über Fine-tuning eines eigenen Modells nachdenken und unsicher sind, wie Sie den Eval-Prozess aufsetzen, schauen wir uns Ihren konkreten Use-Case gerne an. Bei MP Industrial Solutions helfen wir Unternehmen, die gesamte Pipeline von den Daten über das Training bis zur Evaluation zu konzipieren — so dass Sie vor dem Deployment in die Produktion wissen, was das Modell wirklich kann.*