---
title: "RAG vs Fine Tuning für Startups"
slug: "rag-vs-fine-tuning"
url: "https://mvp-development.io/de/blog/rag-vs-fine-tuning"
type: post
lang: de
date: "2026-05-07"
last_modified: "2026-05-07"
version: "1.0"
summary: "RAG vs Fine Tuning für Startups: was beide verändern, welche Daten nötig sind, wie Kosten und Tempo sich unterscheiden und wann sich ein Hybrid-Ansatz lohnt."
author: "MVP Development"
tags: ["rag vs fine tuning", "fine tuning vs rag", "retrieval augmented generation", "wann sich fine tuning lohnt", "vektordatenbank", "hybrid rag fine tuning"]
use:
  training: allow
  rag: allow
  embedding: allow
attribution: required
---

# RAG vs Fine Tuning für Startups

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.

## Was RAG und Fine Tuning jeweils machen

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.

Keiner der beiden Ansätze ist ein Mittel gegen Halluzinationen. Das lohnt sich zu wiederholen, denn genau das nehmen die meisten Teams zuerst an. RAG senkt die Wahrscheinlichkeit einer falschen Antwort, weil es das Modell in echten Inhalten verankert. Fine Tuning macht das Verhalten konsistenter. Rechne bei beiden mit gelegentlich falschen Antworten und baue den Prüfschritt ein, der sie abfängt.

## RAG vs Fine Tuning im Überblick

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.

### Sechs Dimensionen, die die beiden Ansätze unterscheiden

| Dimension | RAG | Fine Tuning |
| --- | --- | --- |
| Was sich verändert | Was das Modell zur Anfragezeit sieht | Wie sich das Modell standardmäßig verhält |
| Benötigte Daten | Eine durchsuchbare Wissensbasis: Dokumente, Datensätze, Tickets | Gelabelte Beispiele für Ein- und Ausgaben |
| Iterationstempo | Neu indexieren, und die Änderung ist noch am selben Tag live | Neu trainieren, neu bewerten, dann neu ausrollen |
| Kostenstruktur | Infrastruktur plus laufende Optimierung des Retrievals | Daten labeln plus Trainingsläufe, wiederholt bei Drift |
| Aktualität des Wissens | So aktuell wie dein letzter Index | Eingefroren auf dem Stand des Trainings |
| Fehlerquellen | Schwaches oder falsches Retrieval, dünne Verankerung | Veraltete Fakten, übernommene Verzerrungen, Format-Drift |

## Wann RAG zu einem Produkt passt

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.

## Wann sich Fine Tuning lohnt

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.

Einen universellen Gewinner gibt es hier nicht, und diese Seite als Suche danach zu lesen, geht am Punkt vorbei. Ein Dokumentations-Assistent, ein Ticket-Klassifizierer und ein Tool für markenkonforme Texte können in ein und demselben Unternehmen zu drei unterschiedlichen Antworten kommen.

## Datenbereitschaft für jeden Weg

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.

## Kosten und Iterationstempo im Vergleich

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.

## Hybrid-Setups

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.

## Die richtige Wahl für dein MVP

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](https://mvp-development.io/blog/llm-evaluation-metrics) 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](https://mvp-development.io/blog/ai-for-startups-mvp) behandelt diese frühere Entscheidung, und unser Team für [KI-Integration](https://mvp-development.io/ai-integration) hilft dir dabei, den passenden Weg einzugrenzen.

## FAQ

**Können RAG und Fine Tuning im selben Feature zusammenarbeiten?**

Ja, und das kommt in der Produktion häufiger vor, als die Entweder-oder-Frage vermuten lässt. Ein typisches Muster: ein kleines Modell für Intent-Klassifizierung und Routing fein tunen und die Antwortgenerierung dann einer RAG-Pipeline überlassen, die in deiner Dokumentation verankert ist. Oder umgekehrt: RAG für Fakten, ein leichtes Fine-Tuning nur für den Ton. Wichtig ist, jeden Teil einzeln zu scopen, statt darauf zu hoffen, dass eine Architektur beide Aufgaben still nebenbei übernimmt.

**Stoppt Fine Tuning Halluzinationen bei einem Modell?**

Nein, und das ist das mit Abstand häufigste Missverständnis dazu. Fine Tuning formt Ton, Format und Verhalten zuverlässig. Es bringt einem Modell keine neuen Fakten auf verlässliche Weise bei und lässt es auch nicht seltener halluzinieren.

**Wie viele gelabelte Daten braucht Fine Tuning wirklich?**

Das hängt stark davon ab, wie eng die Aufgabe gefasst ist. Ein Klassifizierer, der zwischen einer Handvoll fester Kategorien wählt, kommt mit ein paar Hundert soliden Beispielen aus. Eine konsistente Stimme über offene Anfragen hinweg zu halten, braucht meist mehr, oft im niedrigen vierstelligen Bereich, plus ein separates Evaluationsset, mit dem nicht trainiert wurde. Qualität schlägt Menge. Hundert sorgfältig geprüfte Beispiele schlagen meist tausend uneinheitliche.

**Ist RAG anfangs immer die günstigere Option?**

Nicht immer. „Günstiger" hängt vom Zeitraum ab, den du betrachtest. RAG hat oft niedrigere Einstiegskosten, weil kein Trainingslauf nötig ist, aber die Arbeit an der Retrieval-Qualität hört nach dem Launch selten auf. Fine Tuning wirkt am Anfang oft teurer, kostet dann aber im Live-Betrieb weniger pro Anfrage, weil ein kürzerer Prompt eine kleinere Rechnung bei jedem Aufruf bedeutet. Vergleiche die Betriebskosten über ein ganzes Jahr mit dem Angebot für den Build.

**Was ist eine Vektordatenbank, und braucht jedes RAG-Setup eine?**

Das ist eine Datenbank, die nach Bedeutung statt nach exakten Schlagwörtern sucht. Sie speichert deine Inhalte als numerische Embeddings, sodass eine Anfrage inhaltlich nahe Passagen findet, selbst wenn die Formulierung komplett anders ist. Die meisten echten RAG-Setups nutzen eine. Eine wirklich kleine, statische Wissensbasis mit ein paar Dutzend Dokumenten kommt manchmal auch mit einfacher Stichwortsuche aus, aber das funktioniert nur, solange die Bibliothek nicht größer wird, als ein einzelner Engineer im Kopf behalten kann.

**Wann ist Fine Tuning sinnvoller als der Wechsel zu einem größeren Modell?**

Ehrlich gesagt lohnt es sich, zuerst das größere Modell zu testen, denn das kostet einen Nachmittag statt einer Trainings-Pipeline. Fine Tuning verdient sich seinen Platz, sobald du bei einem bestimmten Verhalten an die Grenze dieses Modells stößt: Selbst ein größeres, leistungsfähigeres Modell hält ein starres Format oder eine bestimmte Stimme über Tausende unterschiedliche Anfragen hinweg nicht so zuverlässig wie eines, das genau auf deinen Beispielen trainiert wurde. Wenn besseres Prompting und ein stärkeres Basismodell beide am selben Fehler scheitern, ist das das eigentliche Signal.

**Wenn ich mit RAG starte, kann ich später zu Fine Tuning wechseln?**

Problemlos, das ist sogar ein gängiger Weg. Bring zuerst RAG live, weil es sich schneller aufsetzen lässt und keinen gelabelten Datensatz braucht, den du wahrscheinlich noch gar nicht hast. Sobald das Produkt läuft, werden echte Konversationen zu den Trainingsdaten, die ein fein getuntes Modell braucht. Viele Teams betreiben am Ende beides parallel.

**Kann ein fein getuntes Modell seine Quellen nennen, so wie eine RAG-Antwort das kann?**

Nicht von allein. Ein fein getuntes Modell hat keinen Retrieval-Schritt, es gibt also nichts, worauf es verweisen könnte, außer du fügst einen hinzu. Wenn Quellenangaben wichtig sind, etwa bei einem Rechts- oder Medizin-Assistenten oder überall dort, wo ein Nutzer berechtigterweise fragen könnte „wer sagt das", ist das ein Signal, dass du Retrieval in der Pipeline brauchst, egal ob du zusätzlich einen Teil davon fürs Fine Tuning nutzt.