RAG vs. Fine-Tuning: Ein Entscheidungsrahmen für Gründer

Setzen Sie auf RAG (Retrieval-Augmented Generation), wenn sich Ihre Datenbasis häufig ändert oder Sie Nutzern zeigen müssen, woher eine Antwort stammt. Wählen Sie Fine-Tuning, wenn das eigentliche Problem das Verhalten des Modells ist – Ton, Ausgabeformat oder eine eng umrissene Aufgabe, die es strukturell immer wieder falsch löst. Die meisten Teams, mit denen wir sprechen, greifen zuerst zu Fine-Tuning, weil es „individueller" klingt – und stellen dann fest, dass RAG 80 % des Problems für einen Bruchteil der Kosten und Komplexität gelöst hätte.

Was die beiden Ansätze wirklich leisten

Sie lösen unterschiedliche Probleme. Wer sie verwechselt, verliert Wochen.

• RAG ruft zur Abfragezeit relevante Dokumente ab und fügt sie als Kontext in den Prompt ein. Die Modellgewichte bleiben unverändert. Sie erweitern, was das Modell weiß – nicht, wie es sich verhält.
• Fine-Tuning passt die Modellgewichte anhand eines Trainingssets an. Sie verändern, wie das Modell antwortet – sein Format, seinen Ton oder domänenspezifische Denkmuster – und geben ihm keine neuen Fakten.

Das ursprüngliche RAG-Paper von Lewis et al. (2020) hat es genau so formuliert: ein parametrisches Modell mit einem nicht-parametrischen Speicher kombinieren, der sich unabhängig aktualisieren lässt. Das ist auch heute noch der zentrale Tradeoff – soll das Wissen in den Gewichten liegen oder in einem Speicher, den Sie ohne erneutes Training bearbeiten können?

Wann RAG die bessere Wahl ist

Entscheiden Sie sich für RAG, wenn eines der folgenden Kriterien zutrifft:

• Ihre Daten ändern sich wöchentlich oder täglich. Preistabellen, Lagerbestände, Richtliniendokumente, Support-Tickets. Fine-Tuning auf ein bewegliches Ziel bedeutet ständiges Nachtraining.
• Sie brauchen Quellenangaben. Anwendungsfälle in Healthcare, Recht und Finance erfordern in der Regel einen Nachweis der Quelle. RAG liefert eine nachvollziehbare Spur; Fine-Tuning bäckt Fakten in eine undurchsichtige Gewichtsmatrix ein, die sich nicht auditieren lässt.
• Sie haben noch keinen Product-Market-Fit. Mit RAG können Sie das zugrunde liegende Modell austauschen oder die Retrieval-Logik anpassen, ohne ein trainiertes Artefakt anzufassen. Die technischen Grundlagen erläutern wir in unserem RAG-Primer, die Speicherschicht in Vektordatenbanken erklärt.
• Das Budget ist knapp. Kein Trainingslauf, keine GPU-Miete, keine MLOps-Pipeline zu betreiben. Sie zahlen pro Abfrage, nicht pro Update-Zyklus.

Wann Fine-Tuning die bessere Wahl ist

Fine-Tuning rechtfertigt seine Kosten, wenn das Problem nicht fehlendes Wissen ist, sondern falsches Verhalten:

• Das Modell ignoriert Ihr Ausgabeformat. Sie brauchen striktes JSON, einen bestimmten Ton oder einen domänenspezifischen Reasoning-Stil (z. B. einen Triage-Workflow), den Prompting allein im großen Maßstab nicht konsistent hält.
• Sie haben tausende beschriftete Beispiele für korrektes Verhalten und das Muster ist stabil – nicht „neue Fakten", sondern „erledige diese Aufgabe genau auf diese Weise".
• Latenz und Prompt-Größe sind echte Einschränkungen. Jede RAG-Abfrage kostet Retrieval-Zeit und erzeugt einen längeren Prompt. Bei Millionen von Aufrufen pro Tag kann ein fine-getuntes Modell mit kurzem Prompt deutlich günstiger und schneller sein als ein langer RAG-Kontext – sobald die Trainingskosten amortisiert sind. In unserer Kostenanalyse vergleichen wir diese Zahlen über die Zeit.
• Vokabular oder Denkmuster Ihrer Domäne sind so speziell, dass selbst gutes Retrieval und Prompting ein Allzweckmodell nicht zuverlässig steuern können (z. B. hochspezialisiertes klinisches Coding).

OpenAIs Fine-Tuning-Dokumentation ist eine solide Referenz dafür, wofür Fine-Tuning tatsächlich geeignet ist: Formatkonformität, Ton und konsistente Ausführung enger Aufgaben – nicht das Einpflegen neuer Fakten.

Der hybride Ansatz

In der Praxis kombinieren die stärksten Produktivsysteme beide Ansätze – aber nicht von Anfang an:

1. Starten Sie mit RAG und Prompting. Es lässt sich schnell iterieren und günstig anpassen.
2. Instrumentieren Sie alles – protokollieren Sie jede Abfrage, jeden Retrieval-Schritt und jede Ausgabe.
3. Sobald Sie echte Fehlermuster haben (keine hypothetischen), fine-tunen Sie gezielt auf das spezifische Verhalten, das nicht funktioniert.

Eine Fine-Tuning-Pipeline aufzubauen, bevor Sie Produktionslogs haben, ist Blindflug. Sie raten, wie „gut" aussieht, anstatt auf Ihren echten Fehlermodi zu trainieren.

Was wir in der Praxis erlebt haben

Wir betreiben eigenes Outreach-Tooling, das die Website eines potenziellen Kunden analysiert und eine maßgeschneiderte Kaltakquise-E-Mail entwirft. Unser erster Instinkt war die „saubere" Architektur: eine Agenten-Kette, die Fakten extrahiert, dann Relevanz bewertet, dann entwirft, dann den eigenen Entwurf kritisiert. Das war langsamer, teurer – und lieferte schlechtere E-Mails als ein einziger, gut strukturierter LLM-Aufruf mit der gescrapten Seite als Kontext. Im Wesentlichen ein RAG-Muster mit einem Dokument statt eines Korpus. Wir hätten nur dann zu Fine-Tuning gegriffen, wenn dieser Einzelaufruf-Ansatz bei Hunderten von E-Mails keine konsistente Stimme gehalten hätte – und das tat er. Die Erkenntnis lässt sich verallgemeinern: Greifen Sie nicht zum schwereren Werkzeug, bevor Sie bewiesen haben, dass das leichtere nicht ausreicht. Der Instinkt, der eine mehrstufige Agenten-Kette überentwirft, wenn ein einziger Aufruf genügen würde, ist derselbe, der eine Fine-Tuning-Pipeline überentwirft, wenn Retrieval ausreichen würde.

Eine Checkliste für Gründer

Beantworten Sie diese Fragen, bevor Sie Budget einplanen:

• Wie oft ändern sich die zugrunde liegenden Daten? Täglich/wöchentlich → RAG. Selten/nie → Fine-Tuning ist sinnvoll.
• Müssen Sie Quellen angeben? Ja → RAG, oder zumindest RAG plus Fine-Tuning, aber nie Fine-Tuning allein.
• Ist das Fehlerbild „falsche Fakten" oder „falsches Format/Verhalten"? Falsche Fakten → RAG. Falsches Verhalten → Fine-Tuning.
• Haben Sie bereits beschriftete Beispiele für korrektes Verhalten? Nein → Sie sind unabhängig vom Anwendungsfall noch nicht bereit für Fine-Tuning.
• Wie hoch ist Ihr Abfragevolumen? Niedrig bis mittel → der Overhead von RAG pro Abfrage ist unproblematisch. Hoch und latenzempfindlich → die amortisierten Kosten von Fine-Tuning beginnen sich auszuzahlen.

Wenn Sie einen der beiden Ansätze in ein bestehendes Produkt integrieren statt von Grund auf neu zu bauen, behandelt unser Leitfaden zur KI-Integration in Ihr Produkt die umgebenden Architekturentscheidungen – Authentifizierung, Rate Limiting und Fallback-Verhalten –, die mindestens genauso wichtig sind wie die Modellwahl.

Keiner der beiden Ansätze ist dem anderen überlegen – sie lösen unterschiedliche Probleme, und der schnellste Weg zu einem funktionierenden Produkt ist meistens die günstigere Option, die Sie zuerst validieren können. Wenn Sie eine zweite Meinung dazu wünschen, welcher Ansatz zu Ihrem Produkt passt, sprechen Sie mit uns.