Ein KI-System wird für ein Unternehmen erst dann brauchbar, wenn es die eigenen Vorgehensweisen kennt und mit echten Geschäftsdaten arbeitet. Modelle von der Stange leisten das nicht: Sie sind auf allgemein verfügbaren Texten trainiert und wissen nichts über Ihre Produktlogik, Ihre Angebotsvorlagen oder Ihre internen Freigabewege. Sie müssen also mit Kontext versorgt werden. Für diesen Schritt stehen zwei Ansätze zur Diskussion – Retrieval-Augmented Generation, kurz RAG, und Finetuning. Welcher der passende ist, hängt vom Anwendungsfall ab.

Was RAG macht

Bei RAG bleibt das Sprachmodell unverändert. Vorgeschaltet wird eine Suchschicht: Zu jeder Anfrage werden passende Ausschnitte aus den eigenen Beständen gesucht – Handbücher, Wiki-Seiten, Ticketverläufe, Produktdaten – und dem Modell zusammen mit der Frage übergeben. Die Antwort entsteht also auf Basis von Material, das erst im Moment der Anfrage bereitgestellt wird.

Der praktische Vorteil liegt in der Aktualität. Ändert sich eine Richtlinie, muss nur das Dokument im Bestand ausgetauscht werden; das Modell selbst bleibt unangetastet. Ebenso lässt sich nachvollziehen, aus welchen Quellen eine Aussage stammt – ein Punkt, der in regulierten Umfeldern und bei Auskünften gegenüber Kundinnen und Kunden schwer wiegt. Auch Zugriffsrechte lassen sich an dieser Stelle abbilden: Wer ein Dokument nicht sehen darf, bekommt es auch nicht als Kontext geliefert.

Der Aufwand verschiebt sich dafür in die Datenaufbereitung. Dokumente müssen erschlossen, sinnvoll zerlegt und durchsuchbar gemacht werden. Ist der Bestand unstrukturiert, veraltet oder in Dubletten vorhanden, liefert auch die beste Suchschicht schwache Treffer – und das Modell formuliert daraus eine flüssige, aber falsche Antwort.

Was Finetuning macht

Beim Finetuning wird das Modell selbst nachtrainiert, mit Beispielmaterial aus dem Unternehmen. Das Wissen wandert damit in die Gewichte des Modells, nicht in eine vorgelagerte Datenbank. Der Ansatz spielt seine Stärken dort aus, wo es weniger um Fakten als um Verhalten geht: um einen bestimmten Tonfall, um ein festes Antwortformat, um fachsprachliche Eigenheiten oder um wiederkehrende Klassifikationsaufgaben, bei denen dieselbe Art von Eingabe immer wieder dieselbe Art von Ausgabe erzeugen soll.

Der Preis dafür ist Trägheit. Neues oder korrigiertes Wissen landet nicht durch einen Dateiupload im System, sondern erfordert einen erneuten Trainingslauf mit entsprechend aufbereiteten Beispielen. Für Inhalte, die sich häufig ändern, ist das der falsche Hebel. Hinzu kommt, dass sich bei nachtrainierten Modellen deutlich schlechter belegen lässt, woher eine konkrete Aussage stammt.

Die Entscheidung entlang des Anwendungsfalls

Statt einer grundsätzlichen Präferenz hilft ein Blick auf die Eigenschaften des Falls:

  • Wie schnell veraltet das Wissen? Tagesaktuelle Preise, Bestände oder Richtlinien sprechen für RAG.
  • Geht es um Fakten oder um Form? Faktenauskunft spricht für RAG, konsistentes Format und Stil für Finetuning.
  • Muss die Herkunft einer Antwort belegbar sein? Dann ist eine Quellenangabe aus dem Suchschritt kaum zu ersetzen.
  • Wie homogen sind die Aufgaben? Ein eng umrissener, oft wiederholter Vorgang lohnt Trainingsaufwand eher als ein offenes Frage-Antwort-Szenario.
  • Welche Datenbasis existiert überhaupt? Finetuning braucht saubere Beispielpaare, RAG braucht gepflegte Dokumente. Beides ist Arbeit, aber unterschiedliche.

In der Praxis schließen sich die Ansätze nicht aus. Ein Modell kann auf Format und Fachsprache angepasst sein und die inhaltliche Substanz trotzdem aus einer Suchschicht beziehen. Wer klein anfangen will, beginnt in der Regel mit RAG: Der Weg ist reversibler, die Ergebnisse sind früher überprüfbar, und die Datenaufbereitung zahlt auch dann ein, wenn später nachtrainiert wird.

Was das für den Betrieb bedeutet

Beide Varianten erzeugen laufenden Aufwand, nur an unterschiedlichen Stellen. RAG-Systeme brauchen eine funktionierende Pflege der Wissensbasis: Wer verantwortet, dass ein überholtes Dokument wirklich aus dem Index verschwindet? Finetuning-Ansätze brauchen einen definierten Ablauf für neue Trainingsläufe und eine Möglichkeit, Qualitätsverschlechterungen zu erkennen, bevor sie in Produktion sichtbar werden.

In beiden Fällen gehört eine Auswertung dazu, die über Stichproben hinausgeht – ein fester Satz typischer Fragen mit bekannten korrekten Antworten, gegen den jede Änderung geprüft wird. Ohne diese Messlatte ist nicht feststellbar, ob eine Anpassung das System verbessert oder verschlechtert hat.

Der CMS-Bezug

Für Content-Management-Systeme ist der Punkt naheliegender, als er zunächst klingt. Ein CMS ist bereits ein strukturierter, rechteverwalteter, versionierter Wissensbestand – also genau das, was eine Suchschicht braucht. Redaktionsassistenz, interne Suche oder Chat-Auskunft auf Basis der eigenen Inhalte lassen sich damit anbinden, ohne dass Inhalte in ein Modell übertragen und dort dauerhaft eingefroren werden. Die redaktionelle Hoheit bleibt dort, wo sie hingehört: im Redaktionssystem.

Für Web- und Softwareprojekte heißt das: Die Frage nach RAG oder Finetuning ist keine reine Modellfrage, sondern eine Frage der Datenhaltung und der Zuständigkeiten. Wer seine Inhalte ohnehin sauber strukturiert, versioniert und mit Rechten versieht, hat den größeren Teil der Vorarbeit schon geleistet. Und wer die Architekturentscheidung früh trifft, vermeidet, dass sich ein Prototyp später nur mit hohem Aufwand in einen betreibbaren Dienst überführen lässt.

Quellen