RAG oder Fine-Tuning: welche Aufgabe löst welcher Ansatz?

Bei RAG wird zur Laufzeit Kontext ausgewählt. Ein Modell erhält beispielsweise Ausschnitte aus einer gültigen Wartungsanleitung. Ändert sich die Anleitung, kann die Anwendung den Suchbestand aktualisieren, ohne deswegen ein neues Modelltraining durchzuführen. Das setzt eine funktionierende Aktualisierung voraus.

Fine-Tuning verwendet Trainingsbeispiele, um Modellverhalten anzupassen. Google beschreibt überwachtes Fine-Tuning für klar definierte Aufgaben mit verfügbaren gekennzeichneten Daten. Unterstützte Modelle und Konfigurationen sind produktspezifisch und müssen für ein konkretes Vorhaben geprüft werden. Google: Supervised Fine-Tuning.

Die vereinfachte Merkhilfe „RAG für Wissen, Fine-Tuning für Verhalten“ ist nützlich, aber nicht vollständig. Training kann auch fachliche Muster beeinflussen, und RAG-Anwendungen benötigen geeignete Instruktionen. Entscheidend ist, welche Eigenschaft sich kontrolliert ändern und anschließend nachweisen lässt.

Die folgende Tabelle vergleicht RAG und Fine-Tuning in vier Punkten, die die Abschnitte unten ausführlich erläutern.

Aufgabenbeschreibung. Prüfen Sie vor einer Modellanpassung die Aufgabenbeschreibung. Ist das gewünschte Ergebnis eindeutig? Stimmen sich Fachpersonen über eine gute Antwort ab? Ein Modell kann widersprüchliche Erwartungen nicht zuverlässig auflösen, wenn sie nicht einmal in den Referenzbeispielen geklärt sind.

Prompt und Format. Prüfen Sie anschließend Prompt, Ausgabeformat und Beispiele. Wenn eine Anwendung ein bestimmtes Schema benötigt, gehören strukturelle Validierung und klare Felder zum Ausgangspunkt. Ein neues Training ist keine notwendige erste Reaktion auf einen gelegentlich fehlenden Feldnamen.

Suche. Danach prüfen Sie die Suche. Liegt die erforderliche Information im erlaubten Bestand und erreicht sie den Modellkontext vollständig? Ein fein abgestimmtes Antwortmodell repariert keine fehlende Dokumentseite oder eine falsch gefilterte Quelle.

Die folgende Tabelle ordnet beobachteten Fehlerbildern zu, was zuerst zu untersuchen ist und welche weitere Maßnahme möglich ist.

Die Tabelle ist eine Diagnosehilfe, keine allgemeine Leistungsrangliste. Mehrere Ursachen können gleichzeitig auftreten. Beheben Sie sie möglichst getrennt, damit ein späterer Vergleich zeigt, welche Änderung geholfen hat.

Ein erfundenes Unternehmen aktualisiert regelmäßig Produktanleitungen und Zuständigkeiten. Die Mitarbeiter benötigen Antworten mit gültiger Version und verlässlichem Quellenlink. Hier ist ein gepflegter Suchzugriff der naheliegende erste Ansatz.

Würde man Änderungen ausschließlich in ein Modell trainieren, blieben Fragen offen: Wie wird eine einzelne falsche Angabe zurückgezogen? Wie wird eine historische Version ausgewählt? Wie werden unterschiedliche Leserechte pro Mitarbeiter berücksichtigt? Ein Such- und Berechtigungssystem kann diese Aufgaben ausdrücklich modellieren.

RAG ist dabei keine automatische Lösung. Quellenbesitzer, Gültigkeit, Löschung und Testfragen müssen ebenfalls festgelegt werden. Für einen heutigen Transaktionsstatus kann sogar eine direkte Abfrage des führenden Systems geeigneter sein als ein regelmäßig aktualisierter Dokumentindex.

Ein weiteres synthetisches Beispiel betrifft Serviceanfragen, die nach klar definierten Kategorien eingeordnet werden sollen. Die Kategorien ändern sich selten, die Eingaben variieren stark und Fachpersonen können gute Referenzentscheidungen liefern.

Beginnen Sie mit Regeln, einem klaren Prompt und einem geeigneten Basismodell. Sammeln Sie die verbleibenden systematischen Fehler. Wenn genügend konsistente Beispiele vorhanden sind und der Nutzen einer Verbesserung relevant ist, kann ein Fine-Tuning-Versuch sinnvoll sein.

Dabei müssen auch schwierige Grenzfälle enthalten sein. Wenn Trainingsdaten nur eindeutige Fälle zeigen, kann das Modell bei Mehrdeutigkeit weiterhin übermäßig sicher antworten. Eine Kategorie „nicht ausreichend bestimmbar“ oder eine menschliche Prüfschleife kann fachlich wichtiger sein als die letzte Nachkommastelle einer Durchschnittsquote.

Prüfen Sie außerdem die Verteilung der Kategorien. Ein Modell, das bei der häufigsten Kategorie gut abschneidet, kann trotzdem bei den seltenen Anfragen versagen, die dringend eine Fachperson benötigen. Weisen Sie diese Fälle gesondert aus, statt ihre Fehler in der Gesamtmenge verschwinden zu lassen.

Eine kombinierte Anwendung könnte freigegebene technische Informationen abrufen und anschließend in einem festgelegten Bearbeitungsformat zusammenfassen. RAG liefert die aktuelle Grundlage; ein angepasstes Modell könnte helfen, ein wiederkehrendes fachliches Ausgabeverhalten konsistenter umzusetzen.

Ein solcher Aufbau sollte erst aus einem nachgewiesenen Bedarf entstehen. Vergleichen Sie zunächst das unveränderte Modell mit denselben Quellen und denselben Aufgaben. Erst wenn die Fehler überwiegend bei der Verarbeitung des richtigen Kontexts liegen, ist ein Trainingsversuch gezielt begründbar.

Die ursprüngliche RAG-Forschung kombinierte bereits trainierte Komponenten und externe Informationsspeicher. RAG und Training sind daher keine logisch unvereinbaren Gegensätze. Die damaligen Forschungsergebnisse begründen allerdings keine pauschale Überlegenheit einer heutigen Kombination. Lewis et al.: RAG.

Repräsentative Beispiele. Für Fine-Tuning reichen viele Dokumente allein nicht aus. Die Beispiele müssen die gewünschte Aufgabe und richtige Ausgabe abbilden. Schlechte, widersprüchliche oder veraltete Referenzen können unerwünschtes Verhalten verstärken.

Getrennte Bestände. Trennen Sie Trainings-, Entwicklungs- und Prüfbestand. Nahezu identische Beispiele in Training und Test können ein irreführend gutes Ergebnis erzeugen. Bei zeitabhängigen Aufgaben ist zusätzlich ein späterer Zeitraum als Prüfung sinnvoll, damit der Versuch mehr als Wiedererkennen bekannter Formulierungen misst.

Herkunft und zulässige Verwendung. Prüfen Sie die Herkunft und zulässige Verwendung der Daten. Vertrauliche Informationen gehören nicht allein deshalb in Trainingsbeispiele, weil sie im Unternehmen vorhanden sind. Für personenbezogene oder geschützte Inhalte müssen die konkreten Verarbeitungsbedingungen und der Zweck geprüft werden. Diese Entscheidung lässt sich nicht durch die Bezeichnung „eigenes Modell“ ersetzen.

Referenzlabels. Dokumentieren Sie, wie die Referenzlabels entstanden sind. Beispiele, auf die sich qualifizierte Prüfende geeinigt haben, unterscheiden sich von Labels, die automatisch und ohne Prüfung erzeugt wurden. Wenn Sie automatische Labels verwenden, schätzen Sie deren Fehler anhand einer geeigneten Stichprobe, bevor Sie sie als verlässliche Trainingsziele behandeln.

Gleiche Bedingungen. Halten Sie Fragen, Quellen, Berechtigungen und Bewertungsmaßstab konstant. Vergleichen Sie beispielsweise Basismodell mit gutem Prompt gegen angepasstes Modell mit denselben verfügbaren Informationen. Wenn eine Variante zusätzlich bessere Dokumente erhält, misst der Versuch nicht allein Fine-Tuning.

Getrennte Kriterien. Bewerten Sie fachliche Richtigkeit, Format, Ausnahmen, unbelegte Behauptungen und Nacharbeit getrennt. Eine kürzere Antwort kann billiger und zugleich weniger brauchbar sein. Eine streng formatierte Antwort kann weiterhin die falsche Entscheidung enthalten.

Unangetasteter Prüfbestand. Behalten Sie einen unangetasteten Prüfbestand für die abschließende Bewertung. Wer nach jeder Runde genau dieselben Fälle zur Optimierung verwendet, passt die Lösung zunehmend an diesen Bestand an. Das Ergebnis sagt dann weniger über neue Arbeitsfragen aus.

Festgehaltene Konfiguration. Halten Sie neben dem Modellnamen auch die eingesetzte Konfiguration fest. Sucheinstellungen, Prompt-Versionen und Generierungsparameter können Ergebnisse verändern. Ohne diese Angaben kann ein späteres Team nicht erkennen, ob ein Unterschied auf das Modell oder auf einen anderen Teil der Anwendung zurückgeht.

Ein Modell, das auf vertraulichen Beispielen angepasst wurde, erhält dadurch keine automatisch nutzerspezifische Ausgabekontrolle. Die Anwendung muss weiterhin entscheiden, welche Informationen und Werkzeuge eine Person verwenden darf. Bei RAG sollte diese Grenze bereits vor dem Aufbau des Antwortkontexts wirken.

Auch die Rücknahme einzelner Inhalte unterscheidet sich. Ein Suchdatensatz kann gezielt gesperrt oder ersetzt werden, sofern sämtliche Ableitungen berücksichtigt werden. Bei Wissen, das in eine Modellanpassung eingeflossen ist, ist eine vergleichbar gezielte Entfernung nicht einfach als gegeben anzunehmen.

Für sensible Vorhaben gehört deshalb ein dokumentierter Lebenszyklus in die Auswahl: verwendete Trainingsdaten, Modellversionen, Aufbewahrung, Zugriffe und Vorgehen bei Rückzug oder Fehler. Diese Aufgaben können einen vermeintlich kleinen Trainingsversuch erheblich prägen.

Aufwand auf beiden Seiten. RAG verursacht Aufwand für Quellenbereinigung, Import, Suche, Kontextverarbeitung und Pflege. Fine-Tuning verursacht zusätzlich oder alternativ Aufwand für Beispielsammlung, Annotation, Training, Evaluation und Betrieb der angepassten Variante. Ein reiner Vergleich einzelner Modellaufrufe greift zu kurz.

Änderungshäufigkeit. Berücksichtigen Sie Änderungen. Bei häufig wechselnden Regeln kann die Pflege von Quellen planbarer sein als wiederholte Modellanpassung. Bei einer stabilen, häufig ausgeführten Aufgabe könnte eine geprüfte Anpassung wirtschaftlich interessant werden. Das muss mit dem eigenen Volumen und tatsächlichen Ergebnissen gerechnet werden.

Portabilität. Ein Anbieterwechsel oder die Ablösung eines Basismodells kann neue Tests nötig machen. Prüfen Sie vorab, ob Trainingsdaten exportierbar sind, welche Artefakte Ihnen gehören und wie die Anwendung auf eine andere Modellversion umgestellt werden kann. Technische Portabilität ist ein konkreter Prüfpunkt, keine automatische Eigenschaft einer Methode.

Kosten eines Fehlers. Vergleichen Sie außerdem die Kosten eines Fehlers. Eine günstige Antwort, die von einer Fachperson korrigiert werden muss, kann teurer sein als ein etwas langsamerer, verlässlicher Ablauf. Halten Sie menschliche Prüfung und Störungsbearbeitung neben den Infrastrukturkosten fest, wenn Sie die Wirtschaftlichkeit bewerten.

„Wir haben sehr viele Dokumente, deshalb brauchen wir Fine-Tuning“ verwechselt Datenmenge mit Aufgabenart. Viele häufig geänderte Dokumente können gerade für eine verwaltete Suche sprechen. Entscheidend ist, ob das Problem durch fehlenden Zugriff oder durch unzureichendes Verhalten bei vorhandenem Kontext entsteht.

„RAG braucht immer eine neue Vektordatenbank“ ist ebenfalls zu pauschal. Der Informationszugriff kann über vorhandene Suche, direkte Abfragen oder verschiedene kombinierte Verfahren erfolgen. Eine zusätzliche Datenbank ist dann zu rechtfertigen, wenn sie eine konkrete Anforderung besser erfüllt. Die Architektur sollte dem Quellenbestand und den Betriebsfähigkeiten folgen.

„Ein angepasstes Modell ist automatisch billiger“ lässt wesentliche Aufwände aus. Ein kürzerer Prompt kann Aufrufkosten reduzieren; dem stehen Datenpflege, Trainingsläufe und zusätzliche Evaluation gegenüber. Bei geringem Anfragevolumen können diese festen Aufwände den möglichen Vorteil übersteigen. Bei hohem Volumen bleibt zu prüfen, ob die Qualität bei den schwierigen Fällen erhalten bleibt.

Notieren Sie für jede dieser Annahmen einen prüfbaren Gegenbeleg. Welche reale Frage benötigt eine aktuelle Quelle? Welcher systematische Fehler bleibt trotz richtiger Information? Welcher Kostenposten verändert sich tatsächlich? So wird aus einer Methodendiskussion ein überschaubarer Versuch mit klarer Entscheidung. Die Dokumentation sollte auch festhalten, unter welchen geänderten Bedingungen die Entscheidung erneut geprüft wird, etwa bei stark steigendem Volumen, einer neuen Art von Quellen oder neuen Quellenrechten.

Wenn ein guter Prompt, saubere Quellen und eine einfache Suche die Aufgabe ausreichend lösen, braucht es keine zusätzliche Anpassung. Eine komplexere Lösung muss einen messbaren Vorteil rechtfertigen: weniger Fehler, geringere Nacharbeit, bessere Laufzeit oder nachvollziehbar niedrigere Gesamtkosten.

Wählen Sie den nächsten Schritt anhand der verbleibenden Fehler. Fehlende Informationen führen zur Quellenarbeit, schlechte Treffer zur Suchoptimierung und systematische Verarbeitungsfehler zu einem gezielten Modellvergleich. Der RAG-Testplan hilft, diese Entscheidung auf überprüfbare Fälle zu stützen.

Die Entscheidung bleibt an diese überprüften Aufgaben und Bedingungen gebunden.

Diese Leitfäden von modernagents behandeln angrenzende Entscheidungen rund um KI-Wissensassistenten:

• KI-Wissensassistent: internes Wissen auffindbar machen
• RAG einfach erklärt: wie KI mit Unternehmenswissen antwortet
• Microsoft 365 Copilot oder zusätzlicher RAG-Assistent?
• RAG-Kosten: Aufbau, Suche, Modelle und laufende Pflege

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.