RAG vs. Fine-Tuning: warum dein Firmenwissen kein Modelltraining braucht

Vorab die Antwort, damit du diesen Artikel richtig einordnen kannst: Wenn eine KI Fragen zu deinen Verträgen, Handbüchern oder Prozessdokumenten beantworten soll, brauchst du fast nie ein Modelltraining. Du brauchst eine Architektur, die dein Wissen zur Laufzeit nachschlägt. Genau das leistet RAG. In unseren Projekten bei happycoding hat sich eine Reihenfolge bewährt: erst RAG sauber bauen und ausreizen, dann über Fine-Tuning reden — und in den meisten Fällen erledigt sich das Danach von selbst.

Die beiden Begriffe in je zwei Sätzen. RAG (Retrieval Augmented Generation): Das Sprachmodell bleibt unverändert; bei jeder Anfrage sucht das System die passenden Textstellen aus deinen Dokumenten heraus und legt sie dem Modell als Kontext vor. Das Modell formuliert die Antwort aus dem, was es gerade gelesen hat. Fine-Tuning: Du veränderst die Gewichte des Modells selbst, mit hunderten bis tausenden eigener Trainingsbeispiele. Das Modell lernt dabei vor allem Verhalten: Tonfall, Ausgabeformat, Terminologie.

Dieser Artikel ist die Tiefenbohrung zu Stufe 2 unseres Entscheidungsbaums für eigene KI-Modelle. Den kompletten Vier-Stufen-Baum von der Prompt-Optimierung bis zum eigenen Training findest du im Hub-Artikel Eigenes KI-Modell trainieren: Den doppeln wir hier nicht. Wenn du eine Ebene grundsätzlicher einsteigen willst, sortiert KI im Unternehmen einführen die Vorfragen. Hier geht es um die eine Weiche, an der wir die meisten KI-Budgets falsch abbiegen sehen: RAG vs. Fine-Tuning.

Was du in den nächsten Minuten bekommst: den Unterschied, der wirklich zählt, eine Referenzarchitektur mit pgvector, einen Kostenvergleich mit Zahlen und Abrufdatum, den Grund, warum der bekannteste Fine-Tuning-Weg gerade verschwindet — und die drei Grenzen, an denen RAG ehrlicherweise scheitert, samt Gegenmaßnahmen.

Die Frage «RAG oder Fine-Tuning?» klingt nach einem Duell zwischen zwei gleichwertigen Werkzeugen. Das ist sie nicht: Die beiden lösen unterschiedliche Probleme. Vier Eigenschaften machen den Unterschied im Alltag aus, und drei davon fehlen in fast jedem deutschsprachigen Vergleichsartikel.

Aktualität: Bei RAG änderst du ein Dokument, die Pipeline indexiert es neu, und die nächste Antwort kennt den neuen Stand: eine Sache von Minuten. Ein fine-getuntes Modell kennt nur den Wissensstand seines Trainingslaufs. Ändert sich deine Preisliste, trainierst du neu — oder das Modell antwortet falsch, mit voller Überzeugung. Bei einem Produktkatalog, der sich wöchentlich ändert, heißt das: Bei RAG ist die Aktualisierung ein automatischer Job, bei Fine-Tuning ein wöchentliches Trainingsprojekt samt Abnahme.

Quellenangabe: Ein RAG-System kann zu jeder Antwort sagen, aus welchem Dokument und welchem Abschnitt sie stammt. Für dich als Entscheider ist das der unterschätzte Punkt: Deine Leute können jede Antwort in Sekunden gegen das Original prüfen, und genau daran entscheidet sich, ob sie dem System vertrauen. Ein fine-getuntes Modell kann das prinzipbedingt nicht: Sein Wissen steckt in Milliarden Gewichten, nicht in adressierbaren Textstellen.

Löschbarkeit: Verlangt jemand die Löschung seiner Daten, entfernst du bei RAG das Dokument samt Index-Einträgen: nachweisbar und vollständig. Aus trainierten Modellgewichten lässt sich eine einzelne Information nach heutigem Stand nicht gezielt entfernen. Was das für personenbezogene Daten und Drittlandtransfers bedeutet, haben wir im Praxisleitfaden zu DSGVO-konformer KI aufgeschrieben.

Catastrophic Forgetting: Fine-Tuning trägt ein Risiko, das kaum ein Vergleichsartikel nennt: Ein Modell, das du auf deine Daten trainierst, kann dabei Fähigkeiten verlernen, die es vorher hatte. In der Praxis heißt das: Dein Modell kennt jetzt deine Produktnamen, formuliert aber plötzlich schlechtere E-Mails oder verliert an Sprachqualität. Dagegen hilft nur systematische Evaluation, und die kostet Aufwand, den viele Projektpläne schlicht vergessen.

Der oft übersehene Punkt dahinter: Fine-Tuning ist schlicht ein schlechter Wissensspeicher. Ein Modell, das deine 500 Richtlinien-Seiten im Training gesehen hat, hat sie nicht abgelegt, sondern statistisch verdaut: Es kann Inhalte daraus reproduzieren, aber sicher abrufbar sind sie nicht. Für die Frage «Welche Kündigungsfrist gilt bei unseren Lieferantenverträgen?» willst du keine statistische Erinnerung, sondern die Textstelle aus dem gültigen Vertragsmuster, mit Fundstelle.

Die meisten Vergleichsartikel bleiben beim Konzept stehen. Wir zeigen dir stattdessen den Stack, den wir bei happycoding tatsächlich bauen: PostgreSQL mit der Erweiterung pgvector, betrieben auf Supabase oder direkt auf EU-Servern von Hetzner. Der Weg deiner Dokumente durch dieses System hat fünf Stationen.

Ingestion: Eine Pipeline in TypeScript sammelt deine Quellen ein: PDFs, Word-Dateien, Wiki-Seiten, Ticketsystem, ERP-Exporte. Sie extrahiert den Text und behält die Metadaten: Quelle, Datum, Version, Berechtigungen. Schon hier entscheidet sich viel: Was die Pipeline nicht sauber extrahiert, kann später keine Suche finden. Eingescannte PDFs ohne Textebene brauchen zum Beispiel eine OCR-Stufe, sonst bleiben sie für das System unsichtbar.

Chunking: Die Texte werden in Abschnitte von einigen hundert Wörtern zerlegt, entlang der Dokumentstruktur: Kapitel, Absätze, Listen. Unser Erfahrungswert aus Projekten: Schlechtes Chunking ist die häufigste Ursache für schwache RAG-Antworten, noch vor der Wahl des Sprachmodells.

Embedding: Jeder Abschnitt wird von einem Embedding-Modell in einen Zahlenvektor übersetzt, der seine Bedeutung abbildet. Ähnliche Inhalte bekommen ähnliche Vektoren: So findet die Suche später auch Treffer, die andere Wörter benutzen als deine Frage.

Speicherung in pgvector: Die Vektoren landen in derselben PostgreSQL, in der auch deine Anwendungsdaten liegen können. Das ist das zentrale Architektur-Argument: keine zweite Spezialdatenbank wie Pinecone, Weaviate oder Qdrant, kein zweites Backup-Konzept, kein zusätzlicher Betriebsaufwand und kein weiterer Auftragsverarbeiter. Für typische Datenmengen im Mittelstand, von zehntausenden bis zu einigen Millionen Abschnitten, reicht pgvector nach unserer Erfahrung problemlos.

Retrieval und Antwort: Deine Frage wird ebenfalls in einen Vektor übersetzt. Die Datenbank liefert die ähnlichsten Abschnitte, das Sprachmodell formuliert daraus die Antwort und nennt die Quellen.

Zwei Eigenschaften dieses Aufbaus sind für dich wichtiger als jedes Benchmark-Ergebnis. Erstens Zugriffsrechte: Mit Row Level Security filtert die Datenbank selbst, welche Abschnitte ein Nutzer sehen darf, bevor das Modell sie zu Gesicht bekommt. Der Vertrieb bekommt keine Antworten aus HR-Dokumenten: nicht als höfliche Prompt-Anweisung, sondern als Datenbankregel. Zweitens Datenhoheit: Der komplette Index läuft auf EU-Infrastruktur, und das Sprachmodell dahinter kannst du austauschen, ohne dein Wissen neu aufzubauen.

Zwei Praxisfragen gehen bei der Stack-Wahl oft unter. Erstens die Sprache: Nicht jedes Embedding-Modell trennt deutsche Komposita und Fachbegriffe sauber. Wir testen die Kandidaten deshalb gegen echte Fragen aus deinem Unternehmen, bevor die Entscheidung fällt.

Zweitens die Messbarkeit: Ein RAG-System ohne Referenzfragen ist ein Blindflug. Wir legen zu Projektbeginn zwanzig bis fünfzig Fragen mit bekannten, vom Fachbereich abgenommenen Antworten fest und messen jede Änderung an Chunking, Embedding oder Prompt gegen diese Liste. So wird aus «fühlt sich besser an» ein Prozentwert, über den du entscheiden kannst.

Von den deutschsprachigen Artikeln, die zu dieser Frage ranken, nennt keiner einen einzigen Preis. Wir tun es, mit Abrufdatum, denn diese Preise ändern sich.

Was RAG kostet: Der größte Block ist einmalig: der Aufbau von Pipeline, Chunking und Evaluation, bei uns je nach Quellenlage ein Projekt von wenigen Wochen (Erfahrungswert happycoding). Im Betrieb bleiben drei Posten: Hosting der Datenbank, Embedding-Kosten beim Indexieren und der Retrieval-Overhead: Jede Anfrage trägt die gefundenen Abschnitte als zusätzliche Tokens in den Prompt, typischerweise einige tausend pro Frage. Dieser Overhead ist der ehrliche laufende Preis von RAG.

Wichtig für die Bewertung: Du kaufst damit genau die Eigenschaften ein, an denen Fine-Tuning scheitert, nämlich Aktualität und Quellenangabe. Wer nur Token-Preise vergleicht, vergleicht am Wert vorbei.

Was Fine-Tuning kostet: Als Referenz taugt 2026 nicht mehr OpenAI (dazu gleich mehr), sondern ein Anbieter wie Together AI, der offene Modelle trainiert.

Dessen Preisliste (Abruf 18.08.2026) rechnet pro Million Trainings-Tokens und nach Modellgröße: LoRA-Training kostet 0,48 $ bei Modellen bis 16 Milliarden Parameter, 1,50 $ in der Klasse von 17 bis 69 Milliarden und 2,90 $ in der Klasse von 70 bis 100 Milliarden, bei einer Mindestgebühr von 4 $ pro Trainingsjob. Ein Trainingslauf mit 10 Millionen Tokens auf einem 70-Milliarden-Modell kostet also rund 29 $.

Da liegt die Überraschung: Der reine Rechenpreis ist nicht das Problem. Die echten Kosten eines Fine-Tuning-Projekts stecken daneben.

Datenaufbereitung: hunderte bis tausende geprüfte Frage-Antwort-Paare, die jemand aus deinem Fachbereich erstellen und abnehmen muss. Evaluation: ein Satz Referenzfragen plus Regressionstests gegen Catastrophic Forgetting. Re-Training: fällig bei jeder relevanten Wissensänderung, inklusive erneuter Evaluation. Betrieb: Ein fine-getuntes Open-Weight-Modell musst du hosten. Was GPU-Miete und Selbstbetrieb kosten, rechnen wir im Schwesterartikel Was kostet es, ein LLM selbst zu hosten? durch.

Und die Frage «Was kostet ein Pilot?», die KMU-Ratgeber gern aufwerfen und nie beantworten? Unsere ehrliche Antwort: Der Preis hängt an deinen Quellen, nicht an der KI. Saubere PDFs und ein gepflegtes Wiki sind schnell angebunden; ein gewachsener Dateiserver mit zwanzig Jahren Altbeständen ist ein eigenes Projekt. Deshalb starten wir Piloten mit einem bewusst kleinen, aber echten Dokumentbestand: Der beweist die Machbarkeit an deinen Daten, ohne dass du vorher dein gesamtes Archiv aufräumen musst.

Den Break-even kannst du als Formel prüfen: Fine-Tuning rechnet sich gegenüber RAG erst, wenn die eingesparten Kontext-Tokens pro Anfrage, multipliziert mit den Anfragen pro Monat und dem Token-Preis, die monatliche Umlage aus Training, Datenpflege und Hosting übersteigen. Setz deine Zahlen ein: Bei einigen tausend Anfragen pro Monat, wie wir sie im Mittelstand typischerweise sehen, gewinnt diese Rechnung praktisch nie das Training (Erfahrungswert happycoding).

Falls du den Fine-Tuning-Weg trotzdem prüfst, kommt hier ein Fakt, der die Landkarte verändert hat: OpenAI wickelt sein Self-Serve-Fine-Tuning ab, in drei Stufen (developers.openai.com, Abruf 18.08.2026).

Seit dem 07.05.2026 können Organisationen ohne bisherige Fine-Tuning-Historie keine Trainingsjobs mehr starten. Seit dem 02.07.2026 gilt die Sperre auch für Organisationen, die in den letzten 60 Tagen keine Inferenz auf einem fine-getunten Modell hatten. Ab dem 06.01.2027 nimmt die API keine neuen Trainingsjobs mehr an, von niemandem. Ein Nachfolgeprodukt ist nicht angekündigt.

Zur fairen Einordnung: Bestehende fine-getunte Modelle laufen weiter, bis ihr jeweiliges Basismodell abgekündigt wird. Es ist ein Auslauf, keine Abschaltung. Für neue Projekte ist die Tür trotzdem zu, und Fine-Tuning heißt 2026 deshalb praktisch: LoRA oder verwandte PEFT-Verfahren auf Open-Weight-Modellen wie Llama oder Qwen, auf gemieteter GPU oder über Anbieter wie Together AI.

Für deine Entscheidung ist die Richtung wichtiger als das Motiv: Der bekannteste KI-API-Anbieter der Welt hält Self-Serve-Fine-Tuning für verzichtbar. Jeder Dienstleister, der dir 2026 als ersten Schritt ein Modelltraining verkaufen will, sollte dir das erklären müssen.

Und die Episode zeigt das strukturelle Risiko: Ein Fine-Tune bindet dich an ein Basismodell und dessen Lebenszyklus. Wer 2024 Budget in GPT-3.5-Fine-Tunes gesteckt hat, schreibt diese Investition gerade ab: OpenAI schaltet fine-getunte GPT-3.5-Modelle zum 23.10.2026 zusammen mit dem Basismodell ab (developers.openai.com, Abruf 18.08.2026). Ein RAG-Index kennt dieses Risiko nicht: Dein Wissen liegt in deiner Datenbank, das Sprachmodell dahinter ist austauschbar.

Rechne die Zeitachse kurz mit: Zwischen der ersten Sperrstufe im Mai 2026 und der vollständigen Schließung im Januar 2027 liegen acht Monate. Wer Anfang 2026 ein Projekt auf OpenAI-Fine-Tuning geplant hatte, musste mitten im Projekt den Anbieter wechseln. Genau diese Abhängigkeit von den Produktentscheidungen eines einzelnen Anbieters vermeidest du mit einem Wissensspeicher, der dir gehört.

Wir verdienen Geld mit RAG-Systemen. Gerade deshalb sagen wir dir, wo der Ansatz strukturell schwach ist: Drei Grenzfälle begegnen uns in Projekten immer wieder, und keiner davon steht in den üblichen Vergleichsartikeln. Wenn du diese Fälle vor dem Projektstart kennst, kannst du sie in der Architektur abfangen; wenn sie dich im Betrieb überraschen, kosten sie Vertrauen bei genau den Leuten, die das System nutzen sollen.

Tabellenwissen: RAG sucht semantisch ähnliche Textstellen. Eine Frage wie «Welche Kunden hatten 2025 mehr als 100.000 € Umsatz?» beantwortet keine Textsuche: Die Antwort steht in keiner einzelnen Textstelle, sie entsteht erst durch Filtern und Aggregieren über viele Zeilen. Du erkennst das Muster an Wörtern wie «alle», «mehr als» oder «durchschnittlich» in den Fragen deiner Nutzer.

Die Gegenmaßnahme: strukturierte Daten strukturiert abfragen. Wir geben dem Modell per Function Calling Zugriff auf definierte SQL-Abfragen, sodass es deine Datenbank befragt statt Text-Schnipsel zu raten.

Rechenaufgaben: Sprachmodelle rechnen nicht, sie erzeugen plausiblen Text. Selbst mit perfektem Retrieval gilt: Sobald die Antwort eine Rechnung erfordert (Summen, Fristen, Margen, Staffelpreise), ist das Ergebnis unzuverlässig. Das typische Bild aus der Praxis: Das Modell zitiert die richtige Fristenregel und rechnet trotzdem das falsche Datum aus. Die Gegenmaßnahme: das Rechnen auslagern. Das Modell ruft ein Werkzeug auf, etwa eine Berechnungsfunktion oder ein SQL-Aggregat, und formuliert nur noch das geprüfte Ergebnis.

Widersprüchliche Quellen: RAG findet, was da ist. Liegen die Reisekostenrichtlinie von 2019 und die von 2024 beide im Index, bekommt das Modell unter Umständen beide als Kontext und mischt sie zu einer Antwort, die so in keinem Dokument steht. Das ist kein Modellfehler, sondern ein Datenproblem. Die Gegenmaßnahme: Quellen-Governance. Eine verbindliche Quelle pro Thema, Gültigkeitsdaten als Metadaten im Index, veraltete Versionen raus oder in der Suche abgewertet.

Wichtig für deine Entscheidung: Fine-Tuning löst keine dieser drei Grenzen. Ein trainiertes Modell rechnet genauso wenig und aggregiert deine Tabellen genauso schlecht. Wer wegen dieser Grenzen zum Training greift, tauscht ein lösbares Architekturproblem gegen ein unlösbares.

Quer zu allen drei Grenzen liegt die Frage, wie du Qualität überhaupt feststellst. Unsere Antwort ist unspektakulär: die Referenzfragen aus dem Stack-Abschnitt, ergänzt um harte Regeln im Prompt («antworte nur aus dem gelieferten Kontext, sonst sage, dass du es nicht weißt») und regelmäßige Stichproben durch den Fachbereich. Wer Halluzinationen nicht misst, hat sie: Der Unterschied zwischen einem brauchbaren und einem peinlichen System liegt selten am Modell, sondern fast immer an Datenqualität und Evaluation.

Damit du uns nicht falsch verstehst: Es gibt legitime Fine-Tuning-Fälle, und wir bauen sie auch. Drei Muster tauchen dabei immer wieder auf.

Stil, Format, Terminologie: Wenn das Modell in einem festen Ton schreiben, ein exaktes Ausgabeformat einhalten oder die Fachsprache deiner Branche treffen soll, wirkt Training dort, wo Prompts an ihre Grenzen stoßen. Ein Beispiel: Ein Gutachten-Stil mit festen Formulierungen und Gliederungen lässt sich per Prompt nur mühsam erzwingen, per Training dagegen zuverlässig verankern. Das ist ein Verhaltensproblem, also genau das Terrain von Fine-Tuning.

Hohe Stückzahlen bei gleichem Aufgabentyp: Wenn ein System täglich zehntausende gleichartige Aufgaben erledigt, etwa E-Mails klassifizieren oder Felder aus Belegen extrahieren, kann ein kleines, spezialisiertes Modell ein großes generisches schlagen: schneller, günstiger pro Anfrage, ohne Retrieval-Overhead.

Edge und Offline: Wenn das Modell auf eigener Hardware ohne Internetzugang laufen muss, führt an einem kleinen, trainierten Open-Weight-Modell kaum ein Weg vorbei.

Auch die Kombination ist übrigens kein Entweder-oder: In Hybrid-Setups liefert RAG das aktuelle Wissen, während ein fine-getuntes Modell Ton und Format hält. Für die meisten Mittelständler ist das die zweite Ausbaustufe, nicht der Startpunkt: Erst wenn RAG steht und ein messbares Stilproblem übrig bleibt, lohnt der doppelte Aufwand.

Wie du diese Fälle erkennst, wie viele Daten du brauchst und wie ein Trainingsprojekt abläuft, vertiefen wir im Schwesterartikel Wann lohnt sich LLM-Fine-Tuning?.

Eine Prüffrage gehört zusätzlich auf den Tisch, und zwar als offene: Wirst du durch eigenes Training womöglich selbst zum Anbieter eines GPAI-Modells im Sinne des AI Act? Die unverbindlichen GPAI-Leitlinien der EU-Kommission vom 18.07.2025 nennen als indikative Größe ein Drittel des Trainings-Compute des Basismodells; rechtsverbindlich ist diese Schwelle nicht, und typisches LoRA-Training bleibt weit darunter.

Verbindlich klären kann das nur eine juristische Prüfung: Die Pflichtenlage haben wir im Artikel zum EU AI Act für Software-Auftraggeber sortiert.

Wenn du gerade vor dieser Entscheidung stehst, schlagen wir dir drei Schritte vor. Keiner davon verlangt eine große Budgetfreigabe: Alle drei sind Vorbereitung, die du intern erledigen kannst. Erstens: Kläre, ob dein Problem ein Wissens- oder ein Verhaltensproblem ist; der Merksatz aus Abschnitt zwei reicht dafür meistens aus.

Zweitens: Starte klein und messbar: ein abgegrenzter Dokumentbestand, zwanzig Referenzfragen mit bekannten Antworten, ein RAG-Pilot dagegen. So weißt du nach wenigen Wochen, was die Architektur in deinem Fall leistet, statt es glauben zu müssen. Drittens: Prüfe die drei Grenzen aus diesem Artikel gegen deine Anwendungsfälle: Wenn Tabellen und Berechnungen dominieren, plane Function Calling von Anfang an ein, nicht als Nachrüstung.

Wie wir solche Systeme bauen, von der ETL-Pipeline in TypeScript bis zum Betrieb auf deiner EU-Infrastruktur, steht auf unserer Seite zur Prozessautomatisierung. Und wenn du deinen konkreten Fall lieber direkt durchsprechen willst: Buch dir 30 Minuten mit mir — kein Pitch, sondern eine erste Architektur-Einschätzung mit einer klaren Empfehlung, auch wenn sie «kein Modelltraining» lautet.