Ist RAG dasselbe wie Fine-Tuning?

Nein. Fine-Tuning trainiert ein Modell zusätzlich auf eigenen Daten und verändert damit sein internes Verhalten dauerhaft – aufwendig, teuer und bei jeder Datenänderung erneut nötig. RAG lässt ein unverändertes Modell bei jeder Anfrage live in den eigenen Daten nachschlagen. Für „AI soll unser Wissen kennen“ ist RAG in den allermeisten Fällen die passendere, günstigere und aktuellere Lösung.

Brauche ich für RAG ein eigenes AI-Modell?

Nein – RAG funktioniert mit bestehenden Sprachmodellen, egal ob über eine API (z. B. GPT, Claude, Gemini) oder mit einem selbst gehosteten Open-Source-Modell. Die eigentliche Arbeit steckt in der Aufbereitung der Datenquellen und der Such-Komponente davor, nicht im Training eines neuen Modells.

Was kostet ein RAG-System für ein mittelständisches Unternehmen?

Das hängt stark vom Umfang und der Komplexität der Datenquellen ab – ein sauber abgegrenzter erster Anwendungsfall (z. B. ein interner Support-Assistent über eine Wissensdatenbank) lässt sich deutlich schlanker umsetzen als ein unternehmensweites System über alle Datenquellen hinweg. Ein AI Opportunity Scan oder ein erstes Gespräch schafft hier schnell Klarheit, bevor Budget in die Umsetzung fließt.

Bleiben unsere Daten bei RAG wirklich im eigenen Haus?

Das hängt von der gewählten Architektur ab, nicht von RAG selbst: Wird ein extern gehostetes Sprachmodell per API angebunden, gehen zumindest die jeweils gefundenen Textausschnitte dorthin. Mit einer On-Premise- oder EU-gehosteten Lösung – auch mit Open-Source-Modellen möglich – lässt sich der gesamte Prozess im eigenen Haus oder zumindest in der EU halten. Diese Entscheidung sollte am Anfang stehen, nicht am Ende.

RAG statt Fine-Tuning: AI auf eigenen Unternehmensdaten nutzen

„Wir wollen unser eigenes AI-Modell“ ist der Satz, der in Erstgesprächen mit mittelständischen Unternehmen am häufigsten fällt – gemeint ist damit fast immer etwas anderes: AI soll das vorhandene Firmenwissen kennen und nutzen können, nicht ein komplett neues Modell trainieren. Diese Verwechslung kostet Zeit und oft auch Budget, denn Fine-Tuning ist für die allermeisten dieser Fälle die falsche, weil zu teure und zu unflexible Antwort. Der richtige Ansatz heißt in den meisten Fällen Retrieval-Augmented Generation, kurz RAG: Statt einem Modell mühsam beizubringen, was in den eigenen Handbüchern, Verträgen oder Support-Tickets steht, durchsucht das System bei jeder Anfrage gezielt genau diese Quellen und reicht die relevanten Ausschnitte an das Sprachmodell weiter. Dieser Artikel erklärt, warum das der bessere Standardweg ist, wie eine solche Architektur grob aussieht – und wo die eigentlichen Herausforderungen liegen, die in den meisten Erklärungen fehlen.

Warum „Wir brauchen ein eigenes AI-Modell“ fast nie die richtige Anforderung ist

Ein Sprachmodell auf eigenen Daten zu trainieren oder nachzutrainieren (Fine-Tuning) bedeutet, seine internen Gewichte dauerhaft zu verändern – ein aufwendiger, rechenintensiver Prozess, der spezialisierte Infrastruktur und kuratierte Trainingsdaten braucht. Ändert sich danach eine einzige Preisliste oder ein Prozess, ist dieses Wissen bereits wieder veraltet und der Trainingsaufwand beginnt von vorn. Genau das wollen die wenigsten Unternehmen, wenn sie sagen, AI solle „unser Wissen kennen“ – sie wollen, dass AI bei einer Frage die richtige, aktuelle Antwort findet. Das ist ein Nachschlage-Problem, kein Trainings-Problem.

Der Denkfehler: „Trainieren“ vs. „Nachschlagen lassen“

Eine hilfreiche Analogie: Fine-Tuning ist wie ein Lehrbuch auswendig zu lernen – das Wissen sitzt danach im Kopf, ist aber ab dem Moment des Lernens eingefroren und veraltet mit jeder Änderung der Realität. RAG ist wie eine Open-Book-Prüfung: Die AI schlägt bei jeder Frage in den aktuellen Originalquellen nach, statt sich auf ihr (möglicherweise veraltetes) Gedächtnis zu verlassen. Wird ein Dokument aktualisiert, weiß das System sofort davon – ganz ohne erneutes Training.

Was RAG technisch macht – ohne unnötigen Jargon

Retrieval-Augmented Generation verbindet zwei Schritte: Erst wird das relevante Wissen gesucht (Retrieval), dann liefert das Sprachmodell die Antwort auf Basis dieses Fundes (Generation) – statt allein auf sein trainiertes Gedächtnis zurückzugreifen. Der Ablauf lässt sich in vier Schritte zusammenfassen.

Datenquellen erschließen: Handbücher, Wikis, CRM-Einträge, Vertragsdokumente, Ticket-Historien – alles, was als Wissensbasis dienen soll.
In durchsuchbare Bausteine zerlegen (Chunking): Dokumente werden in sinnvolle Abschnitte aufgeteilt und in eine durchsuchbare Form gebracht, die inhaltliche statt nur wörtliche Ähnlichkeit erkennt (technisch meist über eine sogenannte Vektor-Datenbank).
Semantische Suche bei jeder Anfrage: Stellt jemand eine Frage, sucht das System die inhaltlich passendsten Abschnitte aus der gesamten Wissensbasis – in Millisekunden, über tausende Dokumente hinweg.
Antwort mit Quellenbezug generieren: Die gefundenen Abschnitte werden zusammen mit der Frage an das Sprachmodell übergeben, das daraus eine Antwort formuliert – im Idealfall mit Verweis auf die genutzten Quellen.

Wann RAG die richtige Wahl ist – und wann nicht

In der Praxis stehen meist drei Wege zur Debatte, und sie passen zu unterschiedlichen Situationen.

RAG: passt, wenn die Wissensbasis groß ist, sich regelmäßig ändert, Antworten nachvollziehbar/quellenbelegt sein müssen und Datenhoheit eine Rolle spielt – der Regelfall für „AI soll unser Firmenwissen nutzen“.
Fine-Tuning: sinnvoll, wenn tatsächlich das Verhalten, der Stil oder das Antwortformat eines Modells verändert werden soll (z. B. eine bestimmte Fachsprache oder Tonalität) – nicht, um ihm Fakten beizubringen, die sich ändern können.
Alles direkt ins Prompt-Fenster kopieren: funktioniert für kleine, überschaubare und selten wechselnde Datenmengen – wird aber schnell zur Sackgasse, sobald die Wissensbasis über eine Handvoll Dokumente hinauswächst oder sich häufig ändert.

Die eigentliche Herausforderung: nicht das Modell, sondern die Datenbasis

In den meisten öffentlichen Erklärungen zu RAG wirkt die Sache trivial – Dokumente rein, Antworten raus. In der Praxis entscheidet fast ausschließlich die Qualität der Datenbasis darüber, ob ein RAG-System zuverlässig funktioniert oder frustrierend ungenau bleibt. Ein paar der Stolpersteine, die dabei regelmäßig unterschätzt werden:

Uneinheitliche oder veraltete Quellen: Wenn mehrere Versionsstände eines Dokuments im Umlauf sind, findet die Suche im Zweifel die falsche.
Zugriffsrechte müssen im System nachgebildet werden, nicht nur im Ordner: Sonst kann die AI einer Person Inhalte zeigen, die diese im Original-Ordner gar nicht einsehen dürfte.
Die richtige Chunking-Strategie hängt stark vom Dokumenttyp ab: Ein Vertrag, eine Tabelle und ein Chat-Verlauf brauchen unterschiedliche Zuschnitte – zu grob verschlechtert die Treffergenauigkeit, zu fein lässt wichtigen Kontext verloren gehen.
Ohne laufendes Monitoring merkt niemand, wenn die Trefferqualität über Zeit nachlässt – etwa weil neue Dokumenttypen dazukommen, für die die bestehende Struktur nicht ausgelegt ist.

Keiner dieser Punkte ist mit einer pauschalen Antwort zu lösen – die passende Strategie hängt an der konkreten Datenlage, den vorhandenen Systemen und dem gewählten Anwendungsfall. Genau das ist der Teil der Arbeit, der in Marketing-Erklärungen zu RAG fast immer fehlt.

Datenschutz: der eigentliche Vorteil gegenüber „einfach ChatGPT nutzen“

Ein oft übersehener Vorteil von RAG: Die Architektur lässt sich so gestalten, dass nur die für eine konkrete Anfrage tatsächlich relevanten Textausschnitte überhaupt an ein Sprachmodell gehen – nicht der gesamte Datenbestand. Mit einer On-Premise- oder EU-gehosteten Lösung (auch mit Open-Source-Modellen möglich, siehe unser Vergleich offener LLMs) lässt sich der gesamte Prozess sogar im eigenen Haus oder zumindest innerhalb der EU halten. Für Unternehmen mit sensiblen Daten – Verträge, Kundendaten, Personalunterlagen – ist das ein echter Unterschied zu „einfach ChatGPT im Team nutzen“, wo unklar bleibt, was wohin übermittelt wird.

Ein realistischer Fahrplan, wenn du das bei euch prüfen willst

Wissen kartieren: Wo liegt relevantes Wissen tatsächlich – nicht wo es laut Organigramm liegen sollte?
Einen einzigen, klar abgegrenzten Anwendungsfall zuerst wählen (z. B. ein interner Support-Assistent über eine Wissensdatenbank) statt „alles auf einmal“.
Datenqualität vor Technikwahl klären: Zugriffsrechte, Aktualität und Struktur der Quellen zuerst, die Wahl von Modell/Anbieter danach.
Pilotphase mit echten, aber wenigen Nutzenden – und aktivem Nachschärfen der Trefferqualität anhand ihres Feedbacks.
Erst nach einer funktionierenden Pilotphase auf weitere Anwendungsfälle oder Abteilungen ausweiten.

Ein gut gebautes RAG-System ist am Ende eine individuelle Anwendung, kein Standardprodukt von der Stange – die passende Aufbereitung der eigenen Datenquellen, eine durchdachte Rechte- und Chunking-Strategie sowie die bewusste Entscheidung, ob und wo ein externes Sprachmodell überhaupt etwas zu sehen bekommt, entscheiden über Erfolg oder Frust. Genau das ist der Kern dessen, was wir bei Custom Applications gemeinsam mit Unternehmen aufbauen – von der ersten Bestandsaufnahme des vorhandenen Wissens bis zum lauffähigen System.

RAG statt Fine-Tuning: Wie dein Unternehmen mit AI auf eigenen Daten arbeitet, ohne sie zu trainieren