Wann Fine-Tuning sinnvoll ist (und wann RAG ausreicht)

Wenn ein Unternehmen die Implementierung eines eigenen Modells beschließt, stellt sich früher oder später diese Frage: Reicht es, dem Modell Wissen per RAG zuzuführen, oder muss es nachtrainiert werden? Beide Ansätze existieren seit Jahren, aber 2026 ist die Grenze zwischen ihnen schärfer denn je – und ihre Verwechslung kostet Wochen Arbeit und Zehntausende Złoty.

RAG verändert das Modell nicht. Es sucht relevante Fragmente aus Ihrer Wissensdatenbank und injiziert sie vor jeder Antwort in den Kontext. Das Modell liest diese Fragmente und antwortet auf deren Basis – mit Zitat. Das Wissen existiert außerhalb des Modells, sodass Sie die Datenbank morgen aktualisieren können, ohne ein Retraining durchzuführen.

Fine-Tuning verändert die Gewichte des Modells. Sie trainieren es mit eigenen Eingabe-Ausgabe-Beispielen und speichern die daraus resultierenden Änderungen im Modell selbst. Nach dem Fine-Tuning generiert das Modell Text anders, selbst ohne zusätzlichen Kontext. Das ist dauerhaft und lässt sich nicht ohne erneutes Training rückgängig machen.

Der entscheidende Satz: RAG verändert, was das Modell weiß, Fine-Tuning verändert, wie sich das Modell verhält.

Nachfolgend drei konkrete Fälle, in denen Fine-Tuning einen Wert liefert, den RAG nicht reproduzieren kann:

1. Dauerhafter Stil und Ausgabeformat. Wenn Ihr System Berichte in einem streng definierten Template generieren muss (z. B. spezifisches XML, juristisches Format, branchenspezifische Notation) und kein Prompt dies über Tausende Aufrufe hinweg konsistent hält – verankert Fine-Tuning das Format in den Gewichten. Beispiel: Ein System, das technische Beschreibungen nach ISO-Norm generiert, wo Abweichungen vom Template regulatorische Probleme verursachen.

2. Spezialisierter Jargon und domänenspezifische Terminologie. Ein allgemeines Modell kennt das Wort „Dekretation“ nur aus dem buchhalterischen Kontext. Wenn Ihr Prozess Abkürzungen, Akronyme und Terminologien verwendet, die das Modell im Pretraining nicht gesehen hat, bringen ihm einige hundert Fine-Tuning-Beispiele bei, diese korrekt zu interpretieren und zu generieren. RAG kann eine Definition liefern, aber es verändert nicht das tiefe Verständnis des Verwendungskontexts.

3. Kosten- und Latenzreduktion durch Spezialisierung. Ein kleines Modell (7B-14B), das auf eine konkrete Aufgabe trainiert wurde (z. B. nur Intent-Klassifikation im Kundenservice), ist in der Inferenz um ein Vielfaches günstiger als ein großes, allgemeines Modell. Wenn Ihr System Millionen Aufrufe pro Monat für eine einzige, enge Aufgabe durchführt, kann sich das Fine-Tuning eines kleineren Modells innerhalb weniger Monate amortisieren. Rechnen Sie es mit dem Inferenz-Rechner durch.

Es lohnt sich zu wissen, wann man KEIN Fine-Tuning wählen sollte, denn das ist der häufigere Fehler:

1. „Wir wollen, dass das Modell unsere Dokumente kennt.“ Das ist genau die Aufgabe von RAG. Fine-Tuning auf Dokumenten ist keine faktografische Erinnerung – das Modell kann weiterhin Fakten halluzinieren, nur jetzt in Ihrem spezifischen Stil. RAG mit einer vektorbasierten Datenbank und Quellenangabe ist die richtige Lösung.

2. Wissen ändert sich häufig. Wenn sich Ihre Daten wöchentlich aktualisieren (Preislisten, AGBs, Angebote), ist Fine-Tuning ungeeignet – jede Änderung erfordert ein Retraining. RAG aktualisiert sich durch das Hinzufügen neuer Dokumente zur Datenbank.

3. Sie haben wenig Trainingsdaten. Fine-Tuning ohne ausreichende Menge guter Beispiele führt zu Overfitting oder Regression der allgemeinen Fähigkeiten des Modells. Das Minimum sind einige hundert qualitativ hochwertige Eingabe-Ausgabe-Paare; realistisch mehrere tausend für wiederholbare Ergebnisse. Wenn Sie nicht so viele Daten haben – RAG plus Prompt Engineering ist ein günstigerer Einstieg.

4. Budget und Zeit sind begrenzt. Fine-Tuning erfordert GPU-Infrastruktur, Trainingsdaten, Experimente, Evaluation und die Wartung verschiedener Modellversionen. Das ist kein einmaliger Kostenpunkt. Einen RAG-Pilot können Sie innerhalb von Wochen mit einem Bruchteil des Aufwands starten.

Praktische Regel: Beginnen Sie mit RAG, messen Sie die Ergebnisse. Wenn nach zwei bis drei Wochen das Problem nicht „was das Modell weiß“, sondern „wie sich das Modell verhält“ ist – kommen Sie auf das Thema Fine-Tuning zurück.

Wenn nach der obigen Analyse Fine-Tuning die richtige Entscheidung ist, sieht der Prozess wie folgt aus:

1. Sammeln Sie Trainingspaare. Jedes Beispiel besteht aus einer Eingabe (Prompt, Kontext) und einer Ausgabe (korrekte Antwort). Qualität ist wichtiger als Quantität – dreihundert präzise Beispiele schlagen dreitausend beliebige.
2. Wählen Sie ein Basismodell. Kleinere Modelle (7B, 13B) trainieren schneller und kosten weniger. Große Modelle mit 70B+ für Fine-Tuning sind selten außerhalb der größten Organisationen.
3. Technik LoRA / QLoRA. Ein vollständiges Fine-Tuning aller Gewichte ist Verschwendung. LoRA trainiert nur eine kleine Adaptermatrix, was die GPU-Kosten um eine Größenordnung reduziert und den Großteil der Wirkung beibehält.
4. Evaluation. Ein Testset (Hold-out) muss von Anfang an von den Trainingsdaten getrennt sein. Messen Sie aufgabenbezogene Metriken (F1 für Klassifikation, ROUGE für Generierung), nicht nur subjektive Eindrücke.
5. Versionsregistrierung. Jeder trainierte Checkpoint ist eine neue Modellversion mit Datum, Datensatz und Evaluationsergebnissen. Ohne dies wissen Sie nicht, welches Modell Sie deployen oder wie Sie zu einer früheren Version zurückkehren sollen.
6. Wartung. Modell-Drift tritt im Verhältnis zur wachsenden Faktenbasis auf. Legen Sie eine Retraining-Politik fest – z. B. vierteljährlich oder wenn die Evaluationsergebnisse unter einen Schwellenwert fallen.

Alles lässt sich leichter planen, nachdem Sie den Agenten-Blueprint ausgefüllt haben – er hilft zu sehen, wo in der Architektur Fine-Tuning und wo RAG landen.

Die besten Produktionsimplementierungen kombinieren oft beide Ansätze. Das Schema, das wir am häufigsten sehen:

• Fine-Tuning ist verantwortlich für Stil, Format und Stimme (das Modell spricht wie Ihre Marke, generiert in Ihrem Template).
• RAG bringt bei jedem Aufruf frische Fakten ein (das Modell halluziniert keinen aktuellen Preis, weil es ihn einfach im Kontext erhält).

Die Hybridlösung erfordert eine sorgfältige Architektur des Routers, der entscheidet, wann der Kontext angereichert wird und wann auf das Wissen aus dem Fine-Tuning vertraut wird. Dies ist eines der Muster, die wir im Rahmen des eigenen KI-Assistenten für Kunden umsetzen.

Fine-Tuning und die Inferenz eines trainierten Modells haben Konsequenzen für Sicherheit und Regulierung. Einige Fakten, die vor der Entscheidung beachtet werden sollten:

Wenn Sie ein Modell mit personenbezogenen Daten trainieren, unterliegen Sie der RODO und wahrscheinlich ist eine DPIA erforderlich. Die für das Training verwendeten Daten „fließen“ in die Modellgewichte ein, was eine Prüfung erschwert – Sie können das Recht auf Löschung nicht so einfach umsetzen wie bei RAG, wo es reicht, ein Dokument aus der Datenbank zu entfernen.

Gemäß AI Act müssen Hochrisikosysteme Trainingsdaten und Methodik dokumentieren. Fine-Tuning mit Kundendaten in Klassifikationssystemen (z. B. Kreditscoring, Rekrutierung) erfordert zusätzliche Kontrollen und Auditierbarkeit.

Für sensible Daten bevorzugen wir Self-Hosting – das Modell wird in Ihrer Infrastruktur trainiert und betrieben, PII verlässt die Organisation nicht.

Beschreiben Sie Ihren Anwendungsfall – das Modell hilft einzuschätzen, ob es sich um eine Aufgabe für RAG, Fine-Tuning oder eine Hybridlösung handelt (Playground: PII maskiert, keine Retention):

Fine-Tuning ist sinnvoll, wenn das Problem in einem konstanten Ausgabestil, spezialisiertem Domänenjargon oder dem Bedarf nach günstigerer Inferenz für eine enge Aufgabe liegt. RAG reicht aus, wenn das Problem im Zugriff auf frisches Faktenwissen besteht – und das ist der häufigste Fall in polnischen Unternehmen. Bevor Sie mit dem Training beginnen, prüfen Sie, ob ein guter Prompt mit RAG-Kontext das Problem nicht günstiger löst.

Die Kosten hängen von der Modellgröße, der Anzahl der Beispiele und der gewählten Technik ab. Das Training eines kleinen 7B-Modells mit LoRA auf einigen hundert Beispielen dauert wenige Stunden auf einer GPU und ist relativ kostengünstig. Große Modelle mit 70B+ und vollständiges Fine-Tuning erfordern einen Aufwand von mehreren Wochen Ingenieursarbeit plus Infrastrukturkosten. Rechnen Sie Ihren Fall mit dem Inferenz-Rechner durch oder besprechen Sie ihn im Rahmen eines Pilotprojekts.

Nein. Fine-Tuning verankert Stil und Verhalten, aber es verleiht dem Modell keine zuverlässige faktografische Erinnerung. Das Modell kann „Fakten“ aus den Trainingsdaten „erlernen“, halluziniert aber weiterhin, wenn es nach etwas außerhalb dieser Daten gefragt wird. RAG mit Zitaten und einem Vertrauensschwellenwert (Eskalation zu Human-Handoff, wenn kein relevantes Fragment gefunden wird) ist die Hauptverteidigung gegen Halluzinationen in Produktionssystemen.

Ja, aber es erfordert rechtliche Vorsicht. Personenbezogene Daten im Trainingsdatensatz unterliegen der RODO und erfordern eine Rechtsgrundlage sowie wahrscheinlich eine DPIA. Nach dem Training ist das Löschen spezifischer Daten aus den Modellgewichten technisch schwierig, was die Umsetzung des Rechts auf Vergessenwerden erschwert. Wir empfehlen vor dem Start einen Daten-Audit mit einem Juristen und die Wahl einer Architektur, bei der PII für das Training in Ihrer Infrastruktur verbleibt. Der Artikel AI Act und RODO 2026 beschreibt die Pflichten im Detail.

Beginnen Sie mit dem Sammeln guter Trainingspaare, nicht mit der Auswahl der Infrastruktur. Identifizieren Sie 200-500 konkrete Eingabe-Ausgabe-Beispiele, die das erwartete Modellverhalten illustrieren. Trennen Sie sofort 10-20% als Hold-out für die Evaluation. Erst mit diesen vorbereiteten Daten planen Sie Infrastruktur und Zeitplan. Hilfreich ist der Agenten-Blueprint, der es ermöglicht, die Architektur des gesamten Systems zu skizzieren, bevor Sie ins Detail des Trainings einsteigen.