Fine-Tuning, RAG oder Prompting? Wann welcher Anpassungsweg für LLMs passt

Worum es bei der Frage eigentlich geht

Prompting, Retrieval Augmented Generation und Fine-Tuning sind keine konkurrierenden Produkte, sondern drei sehr unterschiedliche Eingriffe in dasselbe System. Ein Prompt ändert, was das Modell in einer Anfrage zu tun hat. RAG ändert, welches Wissen das Modell für eine Antwort zur Verfügung hat. Fine-Tuning ändert das Modell selbst.

Die drei Wege unterscheiden sich nicht nur technisch, sondern in dem, wo sie eingreifen. Prompting passiert pro Anfrage, RAG pro Antwort, Fine-Tuning einmal pro Trainingslauf. Daraus ergeben sich völlig unterschiedliche Anforderungen an Daten, Tooling, Tests und Betrieb. Wer diese Trennung nicht sauber zieht, vergleicht Lösungen, die unterschiedliche Probleme lösen.

Wann ein guter Prompt schon ausreicht

Prompting ist der schnellste, billigste und reversibelste Eingriff. Wenn ein moderner Allzweck-Modell die Aufgabe inhaltlich versteht, das benötigte Wissen ohnehin trägt und das Verhalten lediglich verlässlich gemacht werden muss, ist ein bewusst entworfener Prompt fast immer die richtige erste Wahl.

Typische Fälle sind Klassifikationen, einfache Extraktionen, das Umformulieren oder Strukturieren von Texten, Zusammenfassungen klar abgegrenzter Inhalte oder das Anwenden stabiler interner Regeln auf bekannte Eingaben. In diesen Szenarien lohnt sich der Aufwand für RAG oder Fine-Tuning meist nicht — er macht das System nur teurer und komplizierter, ohne die Qualität messbar zu verbessern.

Was Prompting im Unternehmen wirklich bedeutet, ist allerdings selten ein einzelner Satz. Es bedeutet versionierte System-Prompts, getrennte System- und User-Rollen, Testfälle, Fehlerbilder und ein bewusster Umgang mit Ausgabeformaten. Wer hier disziplinarisch arbeitet, holt aus Standardmodellen oft mehr heraus als gedacht. Wir haben das im Detail in unserem Artikel zu Prompt Engineering im Unternehmen beschrieben.

Die Grenze von Prompting wird sichtbar, sobald drei Dinge zusammenkommen: das nötige Wissen liegt nicht im Modell, sondern in eigenen Quellen, die Antworten müssen auf diese Quellen zurückführbar sein, oder die Aufgabe verlangt einen Stil, der sich nur aus vielen Beispielen lernen lässt. Dann reicht ein Prompt nicht mehr.

Wann RAG der richtige Hebel ist

RAG ist der richtige Hebel, sobald die eigentliche Schwierigkeit im Wissen liegt, nicht im Verhalten des Modells. Handbücher, Verträge, Tickets, Produktdaten oder interne Richtlinien sind in keinem öffentlichen Trainingsdatensatz enthalten — und sie ändern sich. Genau dafür ist Retrieval Augmented Generation gebaut: das Modell beantwortet eine Frage nicht aus dem Gedächtnis, sondern bekommt vor der Antwort passende Textstellen aus einer eigenen Wissensbasis eingeblendet.

Der entscheidende Vorteil ist nicht die Sprachfähigkeit, sondern die Aktualisierbarkeit. Eine Änderung in einer Richtlinie wird durch eine neue Version im Index sofort wirksam, ohne ein Modell neu zu trainieren. Damit ist RAG im Betrieb deutlich näher an klassischen Datenpipelines als an einem Trainingsprozess.

RAG entfaltet seine Stärken, wenn drei Bedingungen zusammenkommen: Es gibt eine klar umrissene Menge an Inhalten, die Antworten müssen belegbar auf diese Inhalte zurückgehen, und das System muss „ich weiß es nicht" ehrlich beantworten können. In dieser Kombination schlägt ein gut gebautes RAG jeden Versuch, dasselbe Wissen über Fine-Tuning ins Modell zu pressen. Die Tiefe dieses Themas — Datenaufbereitung, Chunking, hybride Suche, Evaluation — haben wir separat im Artikel zu RAG-Systemen im Unternehmen ausgeführt.

RAG ändert dabei explizit nicht, wie das Modell formuliert oder wie es entscheidet, wenn es entscheidet. Es ändert nur, was es weiß. Wer Stil, Tonalität, ein bestimmtes Antwortverhalten oder eine sehr enge Domänen-Sprache braucht, ist mit RAG allein selten am Ziel. Hier kommt der dritte Weg ins Spiel.

Wann Fine-Tuning sich tatsächlich lohnt

Fine-Tuning ist die teuerste und unflexibelste der drei Optionen — und genau deshalb eine sinnvolle Antwort auf eine sehr spezifische Klasse von Problemen. Sinnvoll ist Fine-Tuning, wenn die Aufgabe stabil ist, die Anforderungen sich aus Beispielen besser ableiten lassen als aus Beschreibungen, und Prompt-Länge, Latenz oder Kosten in einem relevanten Maßstab eine Rolle spielen.

Typische Fälle, in denen Fine-Tuning trägt, sind enge Klassifikationsaufgaben mit vielen feinen Klassen, hochfrequente Extraktionen mit sehr eigener Domänen-Sprache, stilistische Konsistenz auf Markenebene oder strukturierte Ausgaben in einem festen Schema, das per Prompt schwer zuverlässig zu erzwingen ist. In diesen Fällen ersetzt ein gut trainiertes, kleineres Modell oft ein größeres mit langem Prompt — schneller, günstiger und stabiler.

Wenig sinnvoll ist Fine-Tuning, wenn Wissen das eigentliche Problem ist. Modelle lernen aus Trainingsdaten kein verlässliches Faktenwissen, jedenfalls nicht so, dass sich einzelne Aussagen später noch korrigieren oder belegen lassen. Wer versucht, sein internes Handbuch durch Fine-Tuning „in das Modell zu schreiben", landet in der Regel bei einem System, das überzeugend klingt, aber im Detail nicht zitierfähig ist und sich mit jeder neuen Version der Inhalte nur durch ein neues Training pflegen lässt. Für diesen Fall gibt es RAG.

Fine-Tuning bringt zudem einen eigenen Lebenszyklus mit: Trainingsdaten, Versionierung, Reproduzierbarkeit, Drift-Beobachtung und Rückrollszenarien gehören dazu. Modelle altern, Daten verändern sich, Anforderungen verschieben sich. Was nach einer einmaligen Investition aussieht, ist in Wahrheit ein neuer Pfad in der Betriebsverantwortung.

Eine ehrliche Aufwand- und Kostendimension

Wer die drei Wege gegeneinander stellt, sollte sie nicht nur an Modell- oder Lizenzkosten messen. Entscheidender ist der Lebenszyklus drumherum.

Prompting verursacht im Wesentlichen Aufwand für Entwurf, Versionierung und Tests. Es gibt keine eigene Infrastruktur jenseits eines Aufruf-Pfades zum Modell, und Änderungen sind in Minuten produktiv. Das ist der Grund, warum sich für viele klar geschnittene Aufgaben jede andere Option zunächst kaum rechtfertigen lässt.

RAG verschiebt den Aufwand spürbar in Richtung Datenarbeit. Eine Ingestion-Pipeline, ein Index, ein Retrieval-Verfahren, eine bewusste Antwortschicht und eine Evaluation kommen hinzu. Das ist beherrschbar, aber kein Nebenprojekt. Im Betrieb entstehen laufende Kosten für Embeddings, Index-Speicher und Monitoring der Antwortqualität.

Fine-Tuning verschiebt den Aufwand in Richtung Trainingsdaten und Modell-Lebenszyklus. Datensätze müssen aufgebaut, kuratiert, versioniert und evaluiert werden. Trainingsläufe müssen reproduzierbar sein. Das trainierte Modell muss versioniert, deployt und beobachtet werden. Im laufenden Betrieb sind die einzelnen Anfragen oft günstiger als beim Allzweck-Modell — die Investition davor und drumherum ist deutlich höher.

Eine ehrliche Bewertung dieser drei Wege gehört genau in den Bereich, den wir als KI-ROI im Unternehmen beschrieben haben: nicht nur die Initialkosten zählen, sondern Pflege, Betrieb und Anpassbarkeit über mehrere Jahre.

Mischformen sind in der Praxis der Regelfall

In produktiven Systemen ist die saubere Wahl „nur RAG" oder „nur Fine-Tuning" eher die Ausnahme. Üblich ist eine bewusste Kombination, die jeder Methode das gibt, wofür sie gebaut ist.

Eine typische Architektur in Unternehmensprojekten kombiniert ein Allzweck-Modell mit einem sorgfältig gebauten System-Prompt, einer RAG-Schicht für das eigene Wissen und — falls überhaupt — einem fokussiert fine-getunten kleineren Modell für eng definierte Teilaufgaben wie Klassifikation oder strukturierte Extraktion. Der große Nutzen entsteht in dieser Mischung, nicht in der Reinform.

Diese Mischarchitekturen sind auch der Grund, warum die Frage nach Fine-Tuning vs. RAG vs. Prompting in den meisten Fällen schlecht gestellt ist. Die bessere Frage lautet: Welche Teilaufgabe in unserem System gehört zu welchem Anpassungsweg, und wo lohnt es sich, später nachzuziehen, wenn wir aus dem Betrieb gelernt haben?

Typische Fehler in dieser Entscheidung

Der erste Fehler ist, mit Fine-Tuning zu starten. Es entsteht durch eine Mischung aus Mode und der Annahme, ein „eigenes Modell" sei automatisch besser als ein generisches. In den meisten Fällen ist es das nicht, jedenfalls nicht so lange Prompting und RAG nicht ausgereizt sind. Wer mit Fine-Tuning beginnt, investiert früh viel in eine Architektur, die sich später nicht mehr leicht zurückbauen lässt.

Der zweite Fehler ist, RAG als Wundermittel zu sehen. RAG schließt die Lücke zwischen Modell und eigenem Wissen, aber es ändert nicht das Verhalten und nicht das Urteil des Modells. Schlechte Inhalte werden nicht durch Retrieval besser. Wenig strukturierte Quellen werden nicht durch eine Vektordatenbank klar.

Der dritte Fehler ist, die Wahl an der Modellseite festzumachen, statt am Use Case. „Welches Modell nehmen wir?" ist eine berechtigte Frage, aber nicht die erste. Erst die Aufgabe, dann die Anpassungsmethode, dann das Modell. Wir haben die Modellfrage und ihre Auswahlkriterien separat in unserem Artikel zur LLM-Auswahl für Unternehmen ausgeführt.

Der vierte Fehler ist, ohne Evaluation zu entscheiden. Ohne saubere Testfälle und messbare Qualitätskriterien lässt sich nicht sagen, ob Prompting bereits ausreicht, ob RAG einen spürbaren Unterschied macht oder ob Fine-Tuning seine Investition wert ist. Hier überschneidet sich die Anpassungsfrage mit dem Bereich LLM-Qualitätssicherung: Tests, Metriken und Regressionen sind kein Add-on, sondern die Voraussetzung für eine tragfähige Entscheidung.

Eine pragmatische Reihenfolge für Unternehmensprojekte

Wer aus diesen drei Wegen eine belastbare Entscheidung ableiten möchte, fährt in den meisten Unternehmensprojekten gut mit einer einfachen Reihenfolge.

Erstens: Prompt-basiert beginnen. Die Aufgabe wird mit einem ernsthaft entworfenen System-Prompt, festen Testfällen und klaren Ausgabeformaten umgesetzt und ehrlich evaluiert. Sehr oft ist das schon das produktive System.

Zweitens: RAG ergänzen, wenn das Wissen das Problem ist. Sobald die Lücke zwischen Modellwissen und Unternehmenswissen die Qualität bestimmt, kommt eine RAG-Schicht hinzu. Sie übernimmt das Wissen, der Prompt bleibt für das Verhalten zuständig.

Drittens: Fine-Tuning erst dort, wo Verhalten oder Effizienz nicht anders einzufangen sind. Wenn ein stabiler, eng definierter Teil der Aufgabe sich aus Beispielen besser beschreiben lässt als aus Regeln, oder wenn Latenz und Kosten im großen Maßstab einen relevanten Unterschied machen, lohnt der Schritt — gezielt für diesen Teil, nicht für das ganze System.

Diese Reihenfolge ist keine Doktrin, sondern eine Default-Empfehlung, die in den meisten Projekten Aufwand und Risiko sinnvoll verteilt. Sie ist außerdem die Reihenfolge, in der sich Lernen aus dem Betrieb am ehesten in spätere Architektur übersetzen lässt — ein Punkt, der eng mit den Erfahrungen aus dem Schritt vom KI-Pilot zur Produktion zusammenhängt.

Wann externe Unterstützung sinnvoll ist

Bei klar geschnittenen Aufgaben mit einem reifen Team ist diese Entscheidung intern beherrschbar. Sobald aber mehrere Teilaufgaben aufeinander treffen, eine bestehende Systemlandschaft eingebunden werden muss oder die Investitionsentscheidung über mehrere Jahre trägt, lohnt sich ein zweiter Blick von außen — bevor die Architektur zementiert ist und nicht mehr leicht umgebaut werden kann.

Wir arbeiten mit Unternehmen, die diese Wahl nicht aus Mode oder aus Reflex treffen wollen, sondern entlang ihres tatsächlichen Use Cases. Wenn Sie gerade vor dieser Entscheidung stehen, sprechen Sie uns an, am besten zu Beginn — wenn Zielbild, Datenlage und Erfolgskriterien noch gestaltbar sind. Den passenden Rahmen dafür bieten wir über AI Engineering und unser AI Consulting.