RAG vs Fine Tuning: Was wirklich zu deinem Produkt passt

Irgendwann in der zweiten Woche beim Scoping eines LLM-Features taucht die Frage auf, die den Rest des Projekts bestimmt: RAG vs Fine Tuning? Klingt nach einem kleinen technischen Detail. Verändert in Wirklichkeit die ganze Roadmap. Triffst du die falsche Wahl, trainierst du einen Monat lang ein Modell neu, das eigentlich nur einen Suchindex gebraucht hätte, oder baust eine Retrieval-Pipeline für ein Problem, bei dem es eigentlich um Tonalität und Ausgabeformat ging. Beides wird gern als „der KI-Teil" eines Projekts in einen Topf geworfen, was verdeckt, wie unterschiedlich die beiden Ansätze funktionieren. Retrieval Augmented Generation zieht bei einer Frage passendes Material in den Prompt. Fine Tuning verändert das Modell selbst, im Voraus, anhand von Beispielen, die du lieferst. Dieser Leitfaden zeigt, was beide jeweils verändern, wann sich welcher Ansatz lohnt und wo ein Hybrid-Setup besser ist, als sich für eine Seite zu entscheiden.

RAG, kurz für Retrieval Augmented Generation, wird aktiv, sobald jemand eine Anfrage stellt. Das System durchsucht eine Wissensbasis, meist eine Vektordatenbank mit deinen Inhalten als Embeddings, holt die passendsten Abschnitte heraus und gibt sie dem Modell zusammen mit der Frage. Das Modell schreibt die Antwort immer noch selbst, liest dabei aber dein Material mit. Deshalb kann RAG seine Quelle nennen, und deshalb wirkt sich das erneute Indexieren eines Dokuments innerhalb von Minuten auf sein Wissen aus. Fine Tuning läuft ab, bevor überhaupt eine Anfrage gestellt wird. Du nimmst ein Basismodell und trainierst es weiter mit Beispielen, die du lieferst, und passt dabei seine internen Gewichte an, sodass es sich standardmäßig anders verhält: in einem bestimmten Format, Ton oder Stil, ohne dass das in jedem Prompt extra festgelegt werden muss. Hier liegt die Falle, in die viele Teams tappen: Fine Tuning bringt einem Modell nicht zuverlässig neue Fakten bei und stoppt keine Halluzinationen. RAG löst das auch nicht vollständig. Das Modell kann das Abgerufene trotzdem falsch interpretieren. Beide Ansätze reduzieren unterschiedliche Fehlerarten, und keiner ersetzt die Kontrolle der Ausgabe.

Die Tradeoffs nebeneinander zu sehen, klärt meistens schon die halbe Diskussion, bevor ein Meeting überhaupt beginnt. Die Tabelle unten stellt beide Ansätze anhand der Punkte gegenüber, die für Startups wirklich den Ausschlag geben: was sich jeweils verändert, welche Daten nötig sind, wie schnell du iterieren kannst und wohin das Geld fließt.

RAG passt meistens dann, wenn sich das Wissen hinter einem Feature nach einem Zeitplan ändert, den dein Engineering-Team nicht kontrolliert. Ein Helpcenter beantwortet Fragen zu Preisstufen, die sich vierteljährlich ändern. Ein internes Suchtool muss widerspiegeln, was heute Morgen im Wiki gelandet ist. Ein Modell jedes Mal neu zu trainieren, wenn sich ein Dokument ändert, führt zu einem langsamen Release-Zyklus. Neu indexieren hält dagegen mit dem Content Schritt. RAG passt auch dann, wenn du deine Arbeit belegen musst. Eine Antwort, die auf ihre Quelle verweist, ist leichter zu vertrauen und zu korrigieren als eine, die aus dem Gedächtnis entsteht. Diese Nachvollziehbarkeit bekommst du bei RAG fast geschenkt, weil die abgerufenen Passagen ohnehin schon im Kontextfenster liegen. Noch ein Signal: Wenn dein Content schon als unstrukturierter Text vorliegt, also Dokumentation, Tickets, Verträge, Wiki-Seiten, kann RAG fast sofort mit echtem Material arbeiten. Es organisiert, was bereits existiert, statt einen neuen gelabelten Datensatz zusammenzustellen.

Fine Tuning zahlt sich aus, wenn das Problem im Verhalten liegt, nicht bei den Fakten. Du brauchst konsistente Ausgaben in einem bestimmten Format (strukturierte Daten, die ein nachgelagertes System parst, ein Label aus einer festen Menge, ein Markenton, der immer hält), und ein System-Prompt hat diese Aufgabe im großen Maßstab bisher unzuverlässig erledigt. Fine Tuning lohnt sich auch dann, wenn die Prompt-Länge zu einer echten Kostenfrage wird: Ein langer System-Prompt voller Formatierungsregeln und Sonderfälle wird bei jedem Aufruf mitberechnet, und wenn du dieses Verhalten stattdessen ins Modell trainierst, schrumpft der Prompt deutlich. Der Haken ist die Datenlage. Fine Tuning braucht gepaarte Beispiele, also eine Eingabe und die exakt gewünschte Ausgabe, in echtem Umfang statt eines Ordners voller Referenzdokumente. Eine eng gefasste Klassifizierungsaufgabe kommt vielleicht mit ein paar Hundert gut gelabelten Beispielen aus. Ein Modell, das über unterschiedliche Anfragen hinweg eine konsistente Stimme halten soll, braucht mehr, plus ein echtes Evaluationsset, das bestätigt, dass das Training sitzt.

RAG braucht eine Wissensbasis statt eines Trainingssets. Support-Dokumentation, Produktspezifikationen, Verträge, Ticket-Historien, praktisch alles, was schon schriftlich vorliegt, eignet sich, sobald es bereinigt und für das Retrieval in Abschnitte zerlegt ist. Niemand muss ein einziges Beispiel von Hand labeln. Das Labeling ist in gewisser Weise schon passiert, als ein Mensch das Dokument geschrieben hat. Fine Tuning dreht diese Anforderung um. Es braucht Paare: eine Eingabe und die gewünschte Ausgabe, wiederholt über genug Beispiele, bis ein Muster erkennbar wird. Ein Modell für die Ticket-Weiterleitung braucht Hunderte Tickets, jeweils mit der richtigen Warteschlange markiert. Das ist eine völlig andere Art von Daten als ein Ordner mit Unternehmensrichtlinien, und fünfzig Beispiele aus dem Gedächtnis reichen dafür auch nicht. Die meisten eng gefassten Aufgaben brauchen mindestens ein paar Hundert. Bei Multi-Tenant-Produkten wird RAG komplizierter, an einer Stelle, wo Fine Tuning keine Probleme hat: Die Dokumente eines Kunden dürfen niemals in die abgerufenen Ergebnisse eines anderen gelangen, also muss die Zugriffskontrolle direkt in der Retrieval-Schicht sitzen. Fine Tuning umgeht dieses Problem, weil die Gewichte des Modells keine privaten Dokumente enthalten, auch wenn das Zusammenstellen der Trainingsdaten trotzdem echte Arbeit ist, die vor dem Training erledigt werden muss.

Die Kostenstruktur von RAG tendiert zu Infrastruktur und Optimierungsarbeit, die eigentlich nie ganz fertig wird: eine Vektordatenbank, Embedding-Aufrufe für jedes Dokument, das du einspielst, und Engineering-Zeit, um zu verbessern, was abgerufen wird (Chunk-Größe, Ranking, welche Passagen die Frage beantworten). Die Kostenstruktur von Fine Tuning liegt dagegen vorne: Daten labeln und ein Trainingslauf machen den Großteil der ersten Rechnung aus, und das wiederholt sich, sobald sich die zugrunde liegenden Muster so weit verschoben haben, dass alte Beispiele nicht mehr zu aktuellen Antworten passen. Beim Iterationstempo trennen sich die beiden Wege wirklich. Aktualisierst du ein Dokument und indexierst es neu, spiegelt ein RAG-System die Änderung innerhalb von Minuten wider, oft ohne dass irgendetwas neu deployt werden muss. Änderst du das Verhalten eines fein getunten Modells, brauchst du einen neuen Trainingslauf, eine Evaluation und ein neues Deployment. Dieser Zyklus dauert Tage oder Wochen, ein erneutes Indexieren dauert Minuten. Unser Leitfaden zu den Kosten der KI-App-Entwicklung schlüsselt auf, wie beide Kostenstrukturen in echten Budgetspannen aussehen.

Das Ganze als Entweder-oder darzustellen, wird dem nicht gerecht, wie diese Systeme in der Praxis gebaut werden. Viele Teams setzen RAG für Fakten ein und ein leicht fein getuntes Modell für den Rest: Tool-Calling-Konventionen, Ausgabeschema, den Ton des Support-Teams. RAG kümmert sich darum, was das Modell wissen muss. Fine Tuning kümmert sich darum, wie es das sagt. Ein zweites Hybrid-Muster überrascht alle, die annehmen, Fine Tuning betreffe nur das Modell, das den Text schreibt: das Fine-Tuning des Embedding-Modells oder Rerankers innerhalb einer RAG-Pipeline. Ein generisches Embedding-Modell behandelt Fachjargon wie Rauschen. Dieses kleinere Modell auf das Vokabular deiner Domäne zu tunen, kann spürbar verbessern, welche Passagen abgerufen werden, ohne das Modell anzurühren, das die finale Antwort generiert. Keines der beiden Muster ist exotisch. Ein Support-Copilot kombiniert vielleicht beides: ein fein getunter Retriever findet die richtige Ticket-Historie, ein Basismodell generiert die Antwort, und ein leichtes Fine-Tuning formt den Ton. Behandle „RAG oder Fine Tuning" als die erste Frage beim Scoping eines Features, eine, die am Ende oft mit beidem beantwortet wird.

In der MVP-Phase ist der einfachere Weg die Standardwahl, außer du hast einen konkreten Grund dagegen. Die meisten frühen Features beantworten eigentlich nur die Frage „funktioniert das überhaupt", und RAG (oder, bei einer sehr kleinen statischen Wissensbasis, einfach ein gut geschriebener Prompt) bringt dich schneller dorthin und lässt sich leichter warten. Hebe dir Fine Tuning für den Moment auf, in dem du echte Nutzungsdaten hast und ein Verhaltensproblem, das besseres Prompting nicht löst. Ein paar kurze Fragen bringen die meisten Teams auf die richtige Spur:

• Ändert sich das Wissen wöchentlich, oder praktisch nie?
• Hast du gelabelte Beispiele, oder eher nur Dokumente?
• Muss ein Kunde sehen können, woher eine Antwort stammt?
• Ist die Kosten pro Anfrage im echten Maßstab schon ein Thema?

Beantworte das ehrlich, dann ergibt sich die Wahl fast von selbst. Für welchen Weg du dich auch entscheidest, evaluiere ihn, bevor echte Nutzer ihn zu Gesicht bekommen. Unser Leitfaden zu LLM Evaluation Metriken zeigt, wie du für beide Wege ein Testset aufbaust. Noch nicht sicher, ob dein Produkt überhaupt ein KI-Feature braucht? Unser Leitfaden KI in der MVP-Entwicklung behandelt diese frühere Entscheidung, und unser Team für KI-Integration hilft dir dabei, den passenden Weg einzugrenzen.