RAG vs. Fine-Tuning für den Mittelstand: was sich wirklich rechnet

In jedem zweiten Erstgespräch fällt irgendeine Variante des Satzes „wir wollen das Modell auf unseren Daten trainieren". Der Instinkt ist nachvollziehbar — und fast immer der falsche Plan. Die Verwirrung hat einen Grund: RAG vs. Fine-Tuning wird als Duell zweier Wege inszeniert, einem LLM „unser Geschäft beizubringen". Tatsächlich sind es zwei Werkzeuge für zwei verschiedene Fehlerbilder — und sie unterscheiden sich um Größenordnungen darin, was sie im Aufbau, im Betrieb und im Aktuell-Halten kosten.

Das hier ist der Entscheidungsleitfaden, den wir uns vor solchen Gesprächen wünschen — mit echten Zahlen von aktuellen Preisseiten statt Bauchgefühl.

Zwei Techniken, zwei verschiedene Fehlerbilder

Retrieval-Augmented Generation (RAG) hält euer Wissen außerhalb des Modells. Dokumente werden in Chunks zerlegt, als Embeddings in einen durchsuchbaren Index geschrieben; bei jeder Frage holt das System die relevanten Passagen und reicht sie dem Modell als Kontext. Die Idee stammt aus Lewis et al. 2020: Ein Generator mit angeschlossenem Retriever liefert spezifischere, faktentreuere Antworten als das, was in den Gewichten steckt — und liefert vor allem für jede Antwort eine Quelle mit.

Fine-Tuning verändert die Gewichte selbst, durch Training auf Beispielen. Es ist hervorragend darin, Verhalten zu verschieben — Ton, Ausgabeformat, eine eng umrissene Aufgabe — und überraschend schlecht darin, Fakten hinzuzufügen. Ovadia et al. 2023 haben genau diese Frage getestet („Fine-Tuning or Retrieval?"): RAG schlug unüberwachtes Fine-Tuning bei der Wissensinjektion durchgängig — sowohl bei Wissen, das das Basismodell im Training gesehen hatte, als auch bei komplett neuen Fakten. Modelle nehmen neue Fakten per Fine-Tuning kaum auf, außer man trainiert denselben Fakt in vielen umformulierten Varianten ein.

Die erste Sortierfrage lautet also nicht „welche Technik ist besser", sondern: Fehlt dem System Wissen, oder zeigt es falsches Verhalten? Fehlendes Wissen — aktuelle Preise, Richtlinien, Produktdaten, Verträge — ist ein Retrieval-Problem. Falsches Verhalten — zu lange Antworten, kaputtes JSON, falscher Ton — ist zuerst ein Prompting-Problem und erst dann ein Fine-Tuning-Problem, wenn Prompting messbar an seine Grenze kommt.

Warum Retrieval das Wissensproblem gewinnt

Vier Eigenschaften machen RAG zum Standard für eine geschäftliche Wissensdatenbank — und keine davon ist subtil.

Aktualität ist ein Index-Update, kein Trainingslauf. Ändert sich eine Richtlinie, indexiert ihr ein Dokument neu, und die nächste Antwort stimmt. Ein feingetuntes Modell kennt die Welt vom Stand seines letzten Trainingslaufs — und „dann trainieren wir halt nach" heißt: Trainingskosten erneut zahlen und das Modell erneut validieren, bei jeder Inhaltsänderung.

Antworten kommen mit Beleg. Weil das Modell aus abgerufenen Passagen generiert, kann das System den exakten Quellabsatz zitieren. Für alles Kundennahe oder Compliance-Relevante ist dieser Audit-Trail der Unterschied zwischen einem Werkzeug, dem man vertraut, und einem, das die Rechtsabteilung abschaltet. Ein feingetuntes Modell nennt euch eine Antwort — aber nie, woher sie kommt.

Geerdete Generierung scheitert seltener, und sichtbarer. Halluzinationen verschwinden mit RAG nicht, aber sie werden klein und messbar: Vectaras Hallucination Leaderboard misst, wie oft Modelle beim Zusammenfassen eines vorgelegten Dokuments — also im geerdeten, RAG-ähnlichen Setting — Fakten erfinden. Die besseren Modelle liegen im niedrigen einstelligen Prozentbereich, die besten um die 2 %. Und wenn Retrieval nichts findet, kann ein gut gebautes System „steht nicht in der Wissensbasis" sagen, statt zu konfabulieren. Für Fakten aus den Gewichten gibt es kein vergleichbares Vertrauenssignal.

Eure Daten bleiben löschbar. Das Recht auf Löschung (DSGVO Art. 17) ist in einer RAG-Architektur trivial umzusetzen: Dokument löschen, neu indexieren, fertig. Daten, die in Modellgewichte eintrainiert wurden, lassen sich nicht selektiv entfernen — es gibt kein DELETE FROM weights WHERE customer_id = …. Für europäische Mittelständler mit personenbezogenen Daten entscheidet diese Asymmetrie allein schon die meisten Diskussionen.

Die Kostenmechanik, ehrlich gerechnet

Die Kosten von RAG sitzen an drei Stellen: eine einmalige Indexierung, ein kleiner Speicherposten und eine laufende Rechnung für Kontext-Tokens, die mit der Nutzung skaliert.

Die Indexierung ist fast schon peinlich billig. OpenAIs aktuelle Preisliste führt text-embedding-3-small mit 0,02 $ pro Million Tokens und text-embedding-3-large mit 0,13 $ — ein komplettes Firmenarchiv zu embedden kostet weniger als ein Mittagessen. Selbst das aufwendigere Preprocessing hat einen veröffentlichten Preis: Anthropics Contextual Retrieval — jedem Chunk wird ein LLM-generierter Kontextsatz vorangestellt, was die Top-20-Retrieval-Fehlerrate um 49 % senkt (67 % mit Reranking) — kostet mit Prompt Caching rund 1,02 $ pro Million Dokument-Tokens. Der Speicher ist ein Rundungsfehler: Bei üblichen Chunk-Größen sind es ein paar zehntausend Vektoren, die bequem in die Postgres-Instanz mit pgvector passen, die ihr vermutlich ohnehin betreibt.

Der laufende Posten sind Kontext-Tokens: Jeder abgerufene Chunk ist Input, den das Modell bei jeder Anfrage liest. Laut Anthropics Preisliste kostet Claude Sonnet 4.6 3 $ pro Million Input-Tokens / 15 $ Output, Haiku 4.5 1 $ / 5 $. Zwei Hebel drücken das deutlich: Prompt Caching rechnet wiederholte Prompt-Präfixe mit 0,1× des Input-Preises ab (Schreiben kostet 1,25×), und Batch-Verarbeitung halbiert alles, was nicht latenzkritisch ist. Eine Schwelle solltet ihr kennen, bevor ihr irgendetwas baut: Anthropics eigene Empfehlung lautet, dass eine Wissensbasis unter ca. 200.000 Tokens (rund 500 Seiten) gar kein RAG braucht — komplett in den Prompt damit, das Caching fängt die Kosten ab.

Die Listenpreise fürs Fine-Tuning wirken vergleichbar, bis man die Struktur liest. Auf OpenAIs Preisseite kostet das Training 5 $ pro Million Tokens für gpt-4.1-mini und 25 $ für gpt-4.1; die feingetunten Modelle laufen dann für 0,80 $/3,20 $ bzw. 3 $/12 $. Hinter diesen Zahlen verstecken sich drei Kosten. Erstens: Training wird pro Lauf bezahlt, und jede substanzielle Inhaltsänderung ist ein neuer Lauf plus neue Validierung. Zweitens: Der dominante Posten ist gar nicht Compute, sondern der Aufbau und die Pflege des gelabelten Datensatzes und des Eval-Sets, das euch sagt, ob das Fine-Tuning überhaupt geholfen hat. Drittens: Generationen-Lock-in. Die feintunebaren Modelle auf der heutigen Preisliste sind die Generation gpt-4o / gpt-4.1 / o4-mini, während die aktuellen Flaggschiffe die gpt-5.6-Familie sind. Ein RAG-System erbt jedes neue Modell am Erscheinungstag; ein Fine-Tune ist an einen Snapshot geschweißt, der schon eine Generation zurückliegt.

Durchgerechnet: der Assistent für 10.000 Dokumente

Ein konkreter Mittelstandsfall: ein interner Assistent über 10.000 Dokumente — Handbücher, Verträge, Wiki-Seiten — mit im Schnitt ~2.500 Tokens pro Dokument, also ein Korpus von 25 Millionen Tokens, bei 5.000 Fragen pro Monat.

Aufbau (einmalig):

• Embeddings: 25M Tokens × 0,02 $/MTok = 0,50 $ (3,25 $ mit text-embedding-3-large)
• Contextual-Retrieval-Preprocessing: 25M × ~1,02 $/MTok ≈ 26 $
• Vektorspeicher: ~31.000 Chunks à 800 Tokens — pgvector auf bestehender Infrastruktur, faktisch 0 $

Betrieb (monatlich): Jede Antwort holt zehn 800-Token-Chunks plus Systemprompt und Frage, rund 10.000 Input-Tokens, bei ~500 Tokens Antwort. Auf Sonnet 4.6 sind das 0,030 $ + 0,0075 $ ≈ 4 Cent pro Antwort, also etwa 190 $/Monat bei 5.000 Fragen; auf Haiku 4.5 ~65 $/Monat. Caching von Systemprompt und Tool-Definitionen drückt das weiter.

Die Fine-Tuning-„Alternative" für denselben Korpus: 25M Trainings-Tokens auf gpt-4.1-mini zu 5 $/MTok sind 125 $ pro Epoche — 375 $ für einen typischen Lauf mit drei Epochen, fällig bei jeder nennenswerten Inhaltsänderung aufs Neue. Und laut den Ergebnissen von Ovadia et al. gibt das Modell die Fakten danach trotzdem nicht verlässlich wieder — und zitieren kann es sie nie. Die gesamte RAG-Indexierung kostet weniger als ein Viertel einer einzigen Trainingsepoche, und der monatliche Betrieb weniger als ein Personentag Engineering. Das ist die ehrliche Rechnung: Für das Wissensproblem ist Retrieval nicht nur besser — es ist an jeder einzelnen Position billiger.

Wo Fine-Tuning sein Geld wert ist

Nichts davon macht Fine-Tuning nutzlos. Es hat vier legitime Jobs, alle vom Typ „Verhalten":

• Format und Stil in Serie. Wer täglich tausende Outputs in einem exakten Schema oder einer bestimmten Stimme braucht, backt das Verhalten ins Modell und streicht die seitenlangen Few-Shot-Beispiele aus jedem Prompt.
• Distillation in kleine Modelle. Bringt einem günstigen Modell eine enge Aufgabe bei, mit den Outputs eines Frontier-Modells als Trainingsdaten: Fine-Tuning von gpt-4o-mini kostet 3 $ pro Million Trainings-Tokens und läuft danach für 0,30 $/1,20 $ — eine Größenordnung unter Flaggschiff-Preisen, was bei echtem Volumen zählt.
• Enge Klassifikation und Extraktion, wenn Prompting auf eurem Eval-Set messbar ausgereizt ist — nicht, wenn jemand es nur vermutet.
• Latenz. Kürzere Prompts auf kleineren Modellen antworten schneller; bei interaktiven Produkten ist das manchmal der ganze Business Case.

Die reife Architektur ist meist hybrid, und zwar nicht im Buzzword-Sinn: RAG trägt die Fakten, ein kleines feingetuntes Modell übernimmt eine einzelne, hochvolumige Teilaufgabe wie Query-Routing oder Feldextraktion. Die Techniken ergänzen sich; sie konkurrieren nicht.

Die Entscheidung, der Reihe nach

Geht diese Fragen in dieser Reihenfolge durch und stoppt bei der ersten Antwort:

1. Passt die gesamte Wissensbasis unter ~200.000 Tokens? Dann kein RAG. Kompletter Korpus in den Prompt, Prompt Caching an, diese Woche live.
2. Fehlt Wissen? RAG. Steckt das gesparte Geld in Dokumenten-Hygiene und ein Retrieval-Eval — Chunking und Suchqualität bestimmen eure Antwortqualität weit stärker als die Modellwahl.
3. Stimmt das Verhalten nicht? Erst Prompt Engineering mit einem echten Eval-Set. Erst wenn das Eval zeigt, dass Prompting ausgereizt ist und das Volumen die Pipeline rechtfertigt: das kleinstmögliche Modell für genau diese eine Aufgabe feintunen.
4. Braucht ihr beides? Baut RAG zuerst. Es steht in Wochen, produziert nebenbei die geloggten Frage-Antwort-Paare, die später euer Fine-Tuning-Datensatz werden, und nichts daran verbaut euch den feingetunten Baustein, wenn Schritt 3 wirklich zündet.

Das Muster hinter allen vier Schritten: Auf Mittelstandsskala sind API-Kosten Rauschen im Vergleich zur Engineering-Zeit. Knapp sind eine saubere Wissensbasis und ein Eval-Set aus echten Nutzerfragen — und beide Investitionen zahlen sich aus, egal welche Technik am Ende läuft.