RAG oder Fine-Tuning: Welche Methode passt zu welchem Ziel?

Die Frage kommt fast in jedem Erstgespräch, in dem es um ein internes KI-Wissenssystem geht: „Sollen wir das Modell nicht einfach mit unseren Daten trainieren?” Dahinter steckt fast immer eine Verwechslung von drei unterschiedlichen Dingen: dem Wissen, das ein System braucht, dem Stil, in dem es antworten soll, und dem Verhalten, das es bei bestimmten Aufgaben zeigen soll. RAG (Retrieval-Augmented Generation) und Fine-Tuning beantworten unterschiedliche Fragen – wer sie verwechselt, wählt oft die aufwändigere Methode für ein Problem, das die einfachere gelöst hätte.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die vor der Entscheidung stehen, wie ein Sprachmodell an unternehmenseigenes Wissen angebunden werden soll. Er ordnet RAG und Fine-Tuning entlang von fünf Fragen ein: Wann passt welche Methode, wie unterscheiden sich Aktualisierung und Löschung, welche Kosten entstehen, und wann lohnt sich eine Kombination.

Begriffe: Wissen, Stil und Verhalten sind nicht dasselbe

Bevor die Methoden verglichen werden, lohnt sich eine saubere Abgrenzung – die Datenschutzkonferenz verwendet in ihrer Orientierungshilfe zu RAG-Systemen genau diese Trennung als Ausgangspunkt.

• RAG (Retrieval-Augmented Generation) kombiniert ein Sprachmodell mit einer durchsuchbaren Wissensbasis. Bei jeder Anfrage sucht ein Retriever passende Textabschnitte (Chunks) aus zuvor aufbereiteten Referenzdokumenten und reicht sie dem Modell als zusätzlichen Kontext mit. Das Modell selbst wird dabei nicht verändert – es liefert im Idealfall nur noch die Sprachfähigkeit, während das Faktenwissen aus der Wissensbasis stammt.
• Fine-Tuning (Nachtraining) verändert die Parameter eines bereits trainierten Sprachmodells anhand zusätzlicher, aufgabenspezifischer Dokumente. Damit ändert sich, wie das Modell das jeweils wahrscheinlichste nächste Wort vorhersagt – und damit auch Sprachstil, Tonalität oder die Neigung, bestimmte Ausgaben zu unterdrücken oder zu bevorzugen.
• Wissen ist das, was ein System über die Welt oder dein Unternehmen „weiß” – Fakten, Zahlen, Regelungen, Produktdetails.
• Stil und Verhalten betreffen, wie ein System antwortet: Tonalität, Format, welche Art von Aufgaben es zuverlässig löst.

Die Kurzformel, die sich aus dieser Abgrenzung ergibt: RAG verändert, was ein Modell bei einer konkreten Anfrage weiß – Fine-Tuning verändert, wie das Modell grundsätzlich antwortet. Diese Unterscheidung ist keine akademische Feinheit, sondern entscheidet in der Praxis darüber, ob ein Projekt sein Ziel erreicht.

Wann nutzt man RAG?

RAG ist die richtige Wahl, wenn drei Bedingungen zusammenkommen: Es geht um Faktenwissen, dieses Wissen ändert sich mit einer gewissen Regelmäßigkeit, und es soll nachvollziehbar sein, worauf sich eine Antwort stützt.

Typische Fälle aus der KMU-Praxis: ein interner Assistent, der Fragen zu Produktkatalogen, Preislisten oder technischen Datenblättern beantwortet; ein Support-Tool, das auf Basis der aktuellen Dokumentation antwortet statt auf veraltetem, im Modell „einprogrammiertem” Wissen; ein System, das Vertragsklauseln oder interne Richtlinien zitierfähig zusammenfasst. In all diesen Fällen ändert sich die zugrunde liegende Datenbasis regelmäßig – neue Produkte, aktualisierte Preise, geänderte Richtlinien –, und genau das ist die Stärke von RAG: Referenzdokumente lassen sich austauschen, ohne dass irgendetwas am Modell selbst passiert.

Die Datenschutzkonferenz beschreibt den zugrunde liegenden Mechanismus so: Die Eingabe der Nutzenden wird durch das RAG-Subsystem um passende Textabschnitte aus vorbereiteten Referenzdokumenten ergänzt, bevor sie an das Sprachmodell geht. Im Idealfall soll das faktische Wissen einer Antwort vollständig aus den Referenzdokumenten stammen; das Modell liefert nur noch die sprachliche Formulierung. Dieser Idealfall wird technisch nicht immer vollständig erreicht – auch antrainiertes Wissen des Modells kann ungewollt in die Ausgabe einfließen –, aber die Grundrichtung stimmt: RAG reduziert, wie stark eine Antwort von dem abhängt, was im Modell selbst „steckt”.

Ein zweiter, in der Praxis oft unterschätzter Vorteil: RAG kann laut der Orientierungshilfe Halluzinationen – also plausibel klingende, aber nicht durch Trainingsdaten gestützte Ausgaben – reduzieren, weil relevante, geprüfte Informationen direkt in die Anfrage eingebunden werden. Vollständig ausschließen lässt sich das Problem dadurch nicht; die Zuverlässigkeit hängt maßgeblich von der Qualität, Aktualität und Vollständigkeit der Referenzdokumente ab.

Wann ist Fine-Tuning sinnvoll?

Fine-Tuning setzt dort an, wo es nicht um Fakten, sondern um Verhalten geht. Beispiele: ein Modell soll durchgängig einen bestimmten Tonfall treffen (etwa die Markensprache eines Unternehmens), strukturierte Ausgaben in einem festen Format liefern, oder eine wiederkehrende Aufgabenklasse besonders zuverlässig lösen, für die es kaum gute Trainingsbeispiele im ursprünglichen Modell gab.

Wichtig ist die Einschränkung, die die Datenschutzkonferenz unter Berufung auf eine Einschätzung des Fraunhofer-Instituts IESE trifft: Fine-Tuning sollte nicht dafür eingesetzt werden, einem Sprachmodell Wissen anzutrainieren – es kann aber helfen, einen bestimmten Antwortstil zu berücksichtigen, auf bestimmte Details zu achten oder mit speziellen Ausgabeformaten besser umzugehen. Die Orientierungshilfe verweist zugleich auf eine Studie, in der beobachtet wurde, dass RAG und Fine-Tuning unabhängig voneinander zu Verbesserungen führen können – beide Methoden lösen also tendenziell unterschiedliche Probleme und schließen einander nicht aus.

In meiner Beratungspraxis sehe ich Fine-Tuning bei KMU deutlich seltener als sinnvollen ersten Schritt als RAG. Der Grund ist weniger technisch als praktisch: Fine-Tuning braucht eine ausreichend große, saubere Menge an Trainingsbeispielen für genau das gewünschte Verhalten, ein wiederholbares Trainingsverfahren und – sobald sich Anforderungen ändern – ein erneutes Training. Für die meisten Einstiegs-Use-Cases in KMU (Wissen zugänglich machen, Support-Anfragen beantworten, Dokumente durchsuchbar machen) ist das ein hoher Aufwand für ein Problem, das eine gut aufgebaute RAG-Lösung oft ausreichend gut löst. Fine-Tuning wird dann interessant, wenn eine RAG-Lösung bereits läuft, aber ein sehr spezifisches Antwortverhalten über Prompting allein nicht zuverlässig erreichbar ist.

Wie unterscheiden sich Aktualisierung und Löschung?

Das ist der Punkt, an dem sich die beiden Methoden am deutlichsten unterscheiden – und an dem die Wahl der Methode direkte rechtliche und betriebliche Konsequenzen hat.

In einer RAG-Wissensbasis sind Referenzdokumente und ihre Einträge in der Vektordatenbank direkt adressierbar. Laut der Datenschutzkonferenz erfolgt die Löschung technisch schlicht durch das Entfernen von Einträgen aus der Datenbank und aus den Referenzdokumenten; diese Einträge lassen sich gezielt löschen, und klassische Mechanismen zur Löschung nach Ablauf von Aufbewahrungsfristen sind sowohl für die Vektordatenbank als auch für die Referenzdokumente nutzbar. Auch Aktualisierungen sind unkompliziert: ein Dokument ersetzen, neu aufbereiten (chunken und einbetten), fertig. Der Effekt zeigt sich bei der nächsten Anfrage.

Bei Fine-Tuning gilt das nicht. Wissen, das in die Modellparameter eingeflossen ist, lässt sich nicht gezielt einzeln herausrechnen oder korrigieren. Die Datenschutzkonferenz stellt in ihrer Orientierungshilfe zu RAG-Systemen ausdrücklich fest, dass die Probleme bei der Datenlöschung im Sprachmodell bestehen bleiben, unabhängig davon, ob zusätzlich eine RAG-Methode eingesetzt wird – und dass die Umsetzung von Betroffenenrechten (etwa Berichtigung oder Löschung nach Art. 16 und 17 DSGVO) in Sprachmodellen weitgehend ungelöst ist. Praktisch heißt das: Ein fehlerhafter oder veralteter Fakt, der über Fine-Tuning ins Modell gelangt ist, verlangt in der Regel ein erneutes, angepasstes Training – nicht punktuelle Korrektur.

Für Unternehmen mit personenbezogenen oder sich häufig ändernden Daten ist das ein starkes Argument für RAG: Was in der Wissensbasis liegt, bleibt kontrollierbar. Was im Modell „einprogrammiert” ist, ist es nicht.

Welche Kosten entstehen?

Belastbare, allgemeingültige Zahlen gibt es hier nicht – zu unterschiedlich sind Datenmenge, Integrationstiefe und gewählte Anbieter. Realistisch lassen sich aber die Kostenblöcke benennen, die bei beiden Methoden anfallen, mit den Annahmen, unter denen sie gelten.

Bei RAG entstehen typischerweise vier Blöcke: die einmalige Aufbereitung der Wissensbasis (Dokumente sammeln, bereinigen, in Chunks aufteilen), der Betrieb von Embedding-Modell, Vektordatenbank und Retriever (laufend, abhängig von Datenmenge und Abfragehäufigkeit), die laufende Nutzung des Sprachmodells selbst (nach Token oder als Lizenz) sowie interne Zeit für Pflege der Wissensbasis, wenn sich Dokumente ändern. Für ein KMU mit einer überschaubaren, klar abgegrenzten Dokumentenbasis (einige Hundert bis wenige Tausend Dokumente, ein Anwendungsfall) ist der Aufbau meist mit vorhandenen Cloud- oder Standard-Werkzeugen umsetzbar; der laufende Aufwand konzentriert sich dann auf Pflege statt auf Infrastruktur.

Bei Fine-Tuning kommt zusätzlich der Trainingslauf selbst hinzu – rechenintensiv und je nach Modellgröße und Trainingsdatenmenge mit spürbaren Kosten verbunden – sowie der wiederkehrende Aufwand, ein neues Training anzustoßen, sobald sich Anforderungen oder Datenbasis ändern. Dieser wiederkehrende Aufwand ist der Grund, warum Fine-Tuning bei Themen mit hoher Änderungsfrequenz strukturell teurer wird als RAG: Jede relevante Änderung löst im Zweifel einen neuen Trainingszyklus aus, während RAG nur den Austausch eines Dokuments verlangt.

Als Faustregel aus meiner Projekterfahrung – ausdrücklich keine Zusage, sondern Orientierung unter der Annahme eines überschaubaren, klar abgegrenzten ersten Anwendungsfalls: Eine schlanke RAG-Lösung auf Basis bestehender Cloud-Dienste lässt sich mit deutlich geringerem einmaligem Aufwand aufsetzen als ein Fine-Tuning-Vorhaben, das zusätzlich saubere, ausreichend große Trainingsdatensätze und wiederholte Trainingsläufe braucht. Wer vor einer Kostenentscheidung steht, sollte daher zuerst prüfen, ob das eigentliche Problem überhaupt eines des Faktenwissens ist – dann ist RAG fast immer der günstigere Einstieg.

Kann man kombinieren?

Ja, und in ausgereiften Systemen ist das keine Seltenheit. Weil RAG und Fine-Tuning laut der von der Datenschutzkonferenz zitierten Studie unabhängig voneinander zu Verbesserungen führen können, schließen sie sich nicht gegenseitig aus – sie adressieren unterschiedliche Schwachstellen. Eine typische Kombination: Ein Modell wird per Fine-Tuning auf ein festes Antwortformat und einen bestimmten Tonfall getrimmt, während es sein Faktenwissen weiterhin per RAG aus einer laufend gepflegten Wissensbasis bezieht.

In der Praxis empfehle ich, mit reinem RAG zu starten und Fine-Tuning erst zu prüfen, wenn zwei Bedingungen erfüllt sind: Erstens läuft die RAG-Lösung bereits produktiv und die Wissensanbindung funktioniert zuverlässig. Zweitens zeigt sich ein wiederkehrendes Verhaltensproblem, das über Prompting (Systemanweisungen, Formatvorgaben) allein nicht zuverlässig lösbar ist. Wer beide Methoden von Anfang an parallel aufsetzt, verdoppelt Komplexität und Fehlerquellen, ohne zu wissen, welches der beiden Probleme überhaupt vorliegt.

Umsetzung: die Entscheidung strukturiert treffen

Die folgende Matrix fasst die Kriterien zusammen, die in meiner Beratungspraxis die Methodenwahl tatsächlich entscheiden. Sie ersetzt keine Einzelfallprüfung, gibt aber eine erste, nachvollziehbare Einordnung.

Kriterium	Spricht für RAG	Spricht für Fine-Tuning
Art des Problems	Faktenwissen fehlt oder ist veraltet	Stil, Format oder Aufgabenverhalten passt nicht
Änderungsfrequenz der Daten	Häufig (Preise, Produkte, Richtlinien)	Selten bis nie
Nachvollziehbarkeit gefordert	Ja – Quellenverweis auf Referenzdokumente möglich	Nein – Ausgabe ist nicht auf konkrete Dokumente rückführbar
Löschung/Berichtigung nötig	Ja, gezielt und einzeln möglich	Schwierig – nur über erneutes Training
Personenbezogene Daten im Wissen	Gut kontrollierbar (Zugriffsrechte, Mandantentrennung auf Datenbankebene)	Schwer kontrollierbar, da im Modell „verteilt”
Vorhandene Trainingsdatenmenge	Nicht erforderlich	Ausreichend große, saubere Beispielmenge nötig
Typischer Einstiegsaufwand	Meist geringer, mit Standardwerkzeugen umsetzbar	Meist höher, inklusive Trainingsinfrastruktur
Wiederkehrender Pflegeaufwand	Dokument austauschen	Neuen Trainingslauf anstoßen

Eigene Entscheidungsmatrix Philogic Labs, abgeleitet aus den in diesem Artikel referenzierten Quellen und eigener Projekterfahrung.

Als praktisches Vorgehen empfehle ich drei Schritte: Erstens das Problem präzise benennen – geht es wirklich um fehlendes Wissen, oder eigentlich um Stil und Format? Zweitens die Änderungsfrequenz der relevanten Daten einschätzen – täglich, monatlich, quartalsweise, praktisch nie? Drittens die Matrix als Checkliste durchgehen und die Mehrheit der Kriterien zählen lassen. In den allermeisten KMU-Fällen, die ich begleite, zeigt dieser Dreischritt schon nach kurzer Zeit deutlich in Richtung RAG.

Risiken & Grenzen

Beide Methoden haben Schwächen, die eine Methodenwahl nicht automatisch löst.

RAG löst kein Datenqualitätsproblem. Die Zuverlässigkeit eines RAG-Systems hängt laut der Datenschutzkonferenz stark von der Qualität, Aktualität und Vollständigkeit der Referenzdokumente ab; unvollständige oder veraltete Dokumente führen weiterhin zu unrichtigen Ausgaben. Wer unstrukturierte, widersprüchliche oder veraltete Dokumentenbestände in ein RAG-System kippt, bekommt strukturierte, aber nicht automatisch richtige Antworten.

RAG schützt nicht automatisch die Zweckbindung. Die Übergabe personenbezogener Daten aus der Wissensbasis an das Sprachmodell kann laut Orientierungshilfe zu einer Verkettung mit im Modell enthaltenen Informationen führen – ein Risiko, das bereits in der Konzeption mitgedacht werden muss, nicht erst im Betrieb.

Fine-Tuning bringt eigene Trainingsdatenrisiken mit. Die schwächste Stelle ist häufig die Qualität und Herkunft der Trainingsbeispiele: Enthalten sie personenbezogene Daten, die nicht erforderlich sind, müssen diese vor dem Training entfernt oder anonymisiert werden – ein Grundsatz, den die Orientierungshilfe zu technischen und organisatorischen Maßnahmen für die gesamte Entwicklungsphase von KI-Systemen festhält.

Beide Methoden lösen keine Rechtsgrundlage. Ob RAG oder Fine-Tuning – für die Verarbeitung personenbezogener Daten braucht es in jedem Fall eine datenschutzrechtliche Grundlage. Die Methode kann Risiken mindern, ersetzt aber keine Einzelfallprüfung. Bei sensiblen Daten oder größeren Vorhaben gehört diese Prüfung zu Datenschutzbeauftragten oder Rechtsberatung, nicht in ein Technikprojekt allein.

Beide Methoden lösen keine schlechte Prozessgrundlage. Wenn das eigentliche Problem ist, dass Wissen nirgends dokumentiert oder in verstreuten Postfächern verstreut ist, hilft weder RAG noch Fine-Tuning – dann ist der erste Schritt Wissensorganisation, nicht Modellwahl.

Checkliste: RAG oder Fine-Tuning entscheiden

1. Wir haben das eigentliche Problem präzise benannt: fehlendes Faktenwissen oder falsches Verhalten/Format?
2. Wir kennen die Änderungsfrequenz der relevanten Daten (täglich, monatlich, selten).
3. Wir haben geprüft, ob personenbezogene Daten betroffen sind – und wie Löschung/Berichtigung dafür aussehen müsste.
4. Wir haben die Entscheidungsmatrix durchgegangen und wissen, wohin die Mehrheit der Kriterien zeigt.
5. Bei RAG: Die Qualität und Aktualität der geplanten Referenzdokumente ist ausreichend – nicht nur ihre Menge.
6. Bei Fine-Tuning: Es liegt eine ausreichend große, saubere und rechtlich geprüfte Trainingsdatenmenge vor.
7. Zugriffsrechte und Mandantentrennung sind für die Wissensbasis beziehungsweise die Trainingsdaten geklärt.
8. Eine Rechtsgrundlage für die Verarbeitung personenbezogener Daten ist unabhängig von der Methode geprüft.
9. Wir haben realistische Kostenblöcke benannt statt eine pauschale Zahl zu erwarten.
10. Eine Kombination beider Methoden ist erst dann Thema, wenn RAG bereits produktiv läuft und ein konkretes Verhaltensproblem bleibt.

Wer diese Fragen für sich noch nicht sicher beantworten kann, sollte das nicht allein im Selbstversuch klären: Ein kostenloses Erstgespräch hilft, das eigentliche Problem einzugrenzen, und unser Beratungsangebot begleitet die Analyse- und Pilotphase, inklusive einer fundierten Einschätzung, ob RAG, Fine-Tuning oder beides zu deinem Vorhaben passt. Wer die Grundlagen zu RAG selbst vertiefen will, findet sie im Themen-Cluster RAG und Wissensdatenbanken; für Teams, die KI-Kompetenz strukturiert aufbauen wollen, sind unsere Schulungen ein guter nächster Schritt.