Fine-Tuning vs RAG vs Prompt Engineering: Das Entscheidungsframework für LLM-Anpassung
Drei Werkzeuge, eine wiederkehrende Diskussion
Jedes Team, das ein LLM-Feature ausliefert, landet irgendwann im selben Meeting. Die Antworten sind nicht gut genug, und jemand schlägt Fine-Tuning vor. Jemand anderes hat über Retrieval gelesen und will eine Vektordatenbank. Eine dritte Person merkt leise an, dass sich seit drei Wochen niemand den Prompt angeschaut hat. Die Debatte Fine-Tuning vs RAG vs Prompt Engineering verläuft im Sand, weil die drei Ansätze als konkurrierende Optionen für dieselbe Aufgabe behandelt werden, obwohl sie in der Praxis unterschiedliche Fehler beheben.
Prompt Engineering ändert, wie das Modell angewiesen wird. RAG ändert, welche Informationen das Modell zum Zeitpunkt der Anfrage sieht. Fine-Tuning ändert die Gewichte des Modells und damit sein Standardverhalten. Sobald du es so einordnest, treffen sich die meisten Entscheidungen von selbst. Der Rest dieses Beitrags geht jeden Ansatz durch: wo er passt, was er kostet und ob du ihn selbst betreiben oder jemand anderen dafür bezahlen solltest.
Fang immer mit dem Prompt an
Der Prompt ist der günstigste Hebel und der, den die meisten Teams am wenigsten nutzen. Du kannst ihn heute ändern, mit dem nächsten Deploy ausliefern und das Ergebnis mit eigenen Augen lesen. Du brauchst keinen Trainingslauf, keinen Datensatz und keine neue Infrastruktur. Wenn eine Ausgabe falsch ist, siehst du genau, was dem Modell gesagt wurde, und kannst nachvollziehen, warum es schiefging.
Erstaunlich viele "Wir müssen fine-tunen"-Anfragen entpuppen sich als Prompt-Probleme. Typische Fälle sind Anweisungen, die mitten in einer langen System-Message vergraben sind, keine Beispiele für die erwartete Ausgabe, widersprüchliche Regeln, die verschiedene Leute über die Zeit ergänzt haben, und ein einziger Mega-Prompt, der sechs verschiedene Aufgaben erledigen soll. Diesen Prompt in einen pro Aufgabe aufzuteilen, zwei oder drei ausgearbeitete Beispiele hinzuzufügen und die wichtigste Einschränkung ans Ende der Anweisungen zu verschieben, behebt mehr Qualitätsprobleme als jede andere einzelne Änderung, die wir in Kundenprojekten gesehen haben.
Prompt-Arbeit hat Grenzen. Sie kann dem Modell keine Fakten geben, die es nie gesehen hat. Sie wird bei großem Volumen teuer, wenn du bei jeder Anfrage Tausende Tokens Kontext mitschickst. Und sie erzwingt ohne Hilfe eines Schemas oder einer Validierungsschicht kein zuverlässiges Ausgabeformat über Millionen von Aufrufen. Wenn du an diese Wände stößt, hast du die Grenze dessen gefunden, was Prompting leisten kann, und erst dann lohnt es sich, weiterzuschauen.
Wenn du den Prompt nicht ausgereizt hast, überspringe diesen Schritt nicht. Das fine-getunte Modell, das du baust, erbt jede unklare Anweisung, die du nicht behoben hast.
RAG ist für Wissen, das sich ändert oder nicht hineinpasst
Retrieval-Augmented Generation löst ein bestimmtes Problem: Das Modell braucht Informationen, die es nicht hat. Das betrifft Produktdokumentation, interne Wissensdatenbanken, Kundendaten, Support-Ticket-Historie, Verträge, alles, was entweder zu groß für das Kontextfenster ist oder sich so oft ändert, dass ein statischer Snapshot innerhalb von Wochen veraltet wäre.
Das Missverständnis, das am meisten Budget verbrennt, ist der Glaube, Fine-Tuning bringe einem Modell Fakten bei. Tut es nicht, zumindest nicht zuverlässig. Fine-Tuning verschiebt, wie ein Modell antwortet, aber ein Modell, das letzten Monat auf deiner Dokumentation trainiert wurde, weiß trotzdem nicht, was sich gestern geändert hat, und es erfindet bereitwillig plausibel klingende Details, wenn es nach Dingen gefragt wird, an die es sich nur halb erinnert. RAG umgeht das, indem es die relevanten Passagen zum Zeitpunkt der Anfrage holt und dem Modell vorlegt, sodass die Antwort in der aktuellen Version der Quelle verankert ist.
RAG hat eigene Fehlerbilder, und die sind fast alle Retrieval-Fehler und keine Generierungsfehler. Schlechtes Chunking, schwache Embeddings für dein Fachvokabular, kein Reranking-Schritt und ein fehlendes Evaluations-Harness erklären die meisten Beschwerden der Art "die KI gibt selbstbewusst falsche Antworten", zu denen wir gerufen werden. Die Mechanik haben wir in Building Production-Ready RAG: A Symfony + pgvector Architecture Blueprint behandelt, die Messseite in RAG Evaluation Metrics: Measuring Retrieval Quality Before You Blame the Model.
Das Signal dafür, dass du RAG brauchst, ist einfach. Wenn die richtige Antwort auf die Frage eines Nutzers irgendwo in einem Dokument steht und man vom Modell nicht erwarten kann, dieses Dokument zu kennen, brauchst du Retrieval. Kein Prompting und kein Fine-Tuning ersetzt es, dem Modell die Quelle zu zeigen.
Fine-Tuning ist für Verhalten, nicht für Wissen
Fine-Tuning ist das richtige Werkzeug, wenn das Problem darin liegt, wie das Modell antwortet, und nicht darin, was es weiß. Typische Fälle: ein Modell dazu bringen, in einem bestimmten Haus-Tonfall zu schreiben, ohne in jedem Prompt einen Styleguide mit 2.000 Tokens mitzuschicken; ein konsistentes JSON-Schema für strukturierte Extraktion bei hohem Volumen erzwingen; ein domänenspezifisches Denkmuster beibringen (zum Beispiel, wie ein Schadensregulierer einen Fall durcharbeitet); und einen Prompt schrumpfen, der so lang geworden ist, dass er deine Kosten pro Anfrage dominiert.
Die Ökonomie macht Fine-Tuning bei Volumen attraktiv. Wenn du dieselben 1.500 Tokens an Anweisungen und Beispielen bei jedem von zehn Millionen monatlichen Aufrufen sendest, kosten diese Tokens echtes Geld. Ein fine-getuntes Modell, das die Anweisungen verinnerlicht hat, kommt mit einem Bruchteil des Prompts aus, und oft mit einem kleineren Basismodell, was Latenz und Ausgaben senkt. Das ist auch der Grund, warum Fine-Tuning spät im Leben eines Produkts auftaucht und nicht früh: Du brauchst das Volumen, damit die Einsparungen zählen, und du brauchst eine stabile Aufgabendefinition, damit die Trainingsdaten nicht veralten.
Die Voraussetzungen sind der Punkt, an dem Teams hängen bleiben. Du brauchst ein paar hundert bis ein paar tausend hochwertige Beispiele für genau das Verhalten, das du willst. Diese Beispiele müssen konsistent sein, denn das Modell lernt deine Inkonsistenzen genauso eifrig wie deine Absicht. Du brauchst ein Evaluations-Set, das vom Training zurückgehalten wird, damit du erkennen kannst, ob das neue Modell besser ist oder nur anders. Und du musst akzeptieren, dass Trainingsdaten und Modell jedes Mal aufgefrischt werden müssen, wenn sich die Aufgabe ändert.
Noch etwas, das Fine-Tuning nicht tut: Es repariert kein Retrieval. Der typische Fehler sieht so aus: Ein Team fine-tunt ein Modell auf seinen Support-Artikeln und erwartet, dass es Produktfragen beantwortet. Der Tonfall stimmt, aber die Fakten driften ab, sobald die Artikel aktualisiert werden, weil das Modell nur die Version kennt, auf der es trainiert wurde. Was dieses Team braucht, ist RAG, mit dem fine-getunten Modell dahinter für den Tonfall. Diese Kombination funktioniert gut, aber nur, wenn du verstehst, welche Schicht welche Aufgabe übernimmt.
Das Entscheidungsframework
Das ist die Reihenfolge, die wir mit Kunden durchgehen.
Erstens: Ist die Ausgabe falsch, weil das Modell schlecht angewiesen wurde? Prompt umschreiben, Beispiele hinzufügen, Aufgaben aufteilen. Messen. Dieser Schritt ist kostenlos und sollte nie übersprungen werden.
Zweitens: Ist die Ausgabe falsch, weil dem Modell Informationen fehlen? Wenn die richtige Antwort in einem Dokument, einer Datenbank oder einer API existiert, füge Retrieval hinzu. Beginne mit einer einfachen Pipeline, miss die Retrieval-Qualität getrennt von der Antwortqualität, und optimiere erst dann Chunking und Reranking.
Drittens: Ist die Ausgabe inhaltlich richtig, aber in Form, Tonfall oder Struktur falsch, und kostet dich das bei Volumen Geld? Jetzt lohnt sich die Investition in Fine-Tuning. Sammle Beispiele aus deinen besten gepromteten Ausgaben, trainiere, evaluiere gegen ein zurückgehaltenes Set und vergleiche die Kosten pro Anfrage mit der gepromteten Baseline.
Die drei schließen sich nicht aus. Ein ausgereiftes System nutzt oft alle: einen knappen Prompt, Retrieval für Fakten und ein fine-getuntes Modell für konsistentes Format. Der Fehler ist, bei Schritt drei anzufangen.
| Problem, das du siehst | Wahrscheinliche Lösung | Warum die anderen nicht helfen |
|---|---|---|
| Ignoriert Anweisungen, inkonsistente Qualität | Prompt Engineering | Fine-Tuning zementiert die unklaren Anweisungen; RAG gibt keine Anleitung |
| Fakten falsch, veraltet oder erfunden | RAG | Fine-Tuning speichert Fakten nicht zuverlässig; Prompts fassen nicht deine ganze Wissensbasis |
| Richtiger Inhalt, falscher Tonfall oder Format bei hohem Volumen | Fine-Tuning | Prompting funktioniert, kostet aber bei jedem Aufruf Tokens; RAG ist für Stil irrelevant |
| Prompt so lang, dass er die Kosten dominiert | Fine-Tuning | RAG fügt Tokens hinzu; Prompt-Kompression hat eine Untergrenze |
| Antworten müssen aktuelle Quellen zitieren | RAG | Keiner der anderen Ansätze kann auf ein Dokument verweisen |
Was jeder Ansatz in verschiedenen Größenordnungen kostet
Die Zahlen variieren je nach Anbieter und Modell, also betrachte sie als Größenordnungen und nicht als Angebote.
Bei ein paar tausend Anfragen pro Monat kostet Prompt Engineering Entwicklungszeit und sonst fast nichts. RAG kostet einen Vektorspeicher (pgvector in deinem bestehenden Postgres reicht oft) plus Embedding-Aufrufe, typischerweise einige zehn Euro im Monat. Fine-Tuning ist in dieser Größenordnung schwer zu rechtfertigen: Trainingslauf und Evaluationsarbeit kosten mehr als ein Jahr an Token-Einsparungen.
Bei ein paar hunderttausend Anfragen pro Monat taucht die Prompt-Länge auf der Rechnung auf. Ein System-Prompt mit 1.500 Tokens bei 300.000 Aufrufen sind 450 Millionen Input-Tokens, und bei aktuellen Preisen ist das ein Posten, nach dem jemand fragen wird. Die RAG-Infrastruktur wächst moderat, aber die Retrieval-Latenz wird zum Produktthema. Fine-Tuning beginnt sich zu rechnen, wenn die Aufgabe stabil ist, weil das Kürzen des Prompts um 1.000 Tokens pro Aufruf innerhalb eines Quartals mehr spart, als das Training kostet.
Bei Millionen von Anfragen pro Monat zählen alle drei, und die Abwägungen werden schärfer. Prompt Caching, das wir in Prompt Caching in Production behandelt haben, kann einen großen Teil der Kosten für den wiederholten Präfix ohne Fine-Tuning zurückholen. RAG braucht eine echte Retrieval-Architektur mit Reranking und Monitoring. Ein kleineres Modell so zu fine-tunen, dass es ein größeres bei einer eng umrissenen Aufgabe ersetzt, kann die Kosten um eine Größenordnung senken, und bei diesem Volumen rechtfertigt das einen eigenen ML-Engineer oder ein Beratungsprojekt.
Selbst bauen oder Managed Service nutzen
Jeder Ansatz hat eine Build-vs-Buy-Frage, und die Antwort fällt unterschiedlich aus.
Für Prompt Engineering gibt es nichts zu kaufen. Halte Prompts in der Versionskontrolle, teste sie wie Code und logge Ein- und Ausgaben, damit du Regressionen erkennst. SaaS-Tools für Prompt-Management existieren, aber ein Git-Repository und ein kleines Evaluationsskript decken die meisten Teams ab.
Für RAG sind die Managed-Optionen (gehostete Vektordatenbanken, Retrieval-APIs, die Modellanbieter mitliefern) schnell aufgesetzt und für Prototypen in Ordnung. Das Argument für den eigenen Stack wird stärker, wenn deine Daten sensibel sind, wenn du bereits Postgres betreibst und pgvector ergänzen kannst, oder wenn du Retrieval-Logik brauchst, die an dein bestehendes Berechtigungsmodell gekoppelt ist. Gerade Multi-Tenant-SaaS landet meist beim Self-Hosting, weil Tenant-Isolation in einem Drittanbieter-Vektorspeicher entweder umständlich oder teuer ist.
Für Fine-Tuning ist Managed Fine-Tuning bei den großen Modellanbietern die Standardwahl für die meisten SaaS-Teams. Du lädst Beispiele hoch, sie trainieren, du bekommst einen Modell-Endpoint. Eigenes Training auf Open-Weights-Modellen ergibt Sinn, wenn du das Modell besitzen musst, wenn Daten deine Infrastruktur nicht verlassen dürfen, oder wenn die Token-Preise des Managed-Modells bei deinem Volumen zu hoch sind. Das ist ein echtes Engineering-Commitment, und es lohnt sich, ehrlich zu prüfen, ob dein Team die Kapazität dafür hat, bevor du anfängst.
FAQ
Können RAG und Fine-Tuning zusammen eingesetzt werden?
Ja, und für ausgereifte Produkte ist das der übliche Endzustand. RAG liefert die Fakten, das fine-getunte Modell liefert konsistenten Tonfall und Struktur. Baue zuerst die RAG-Schicht, weil sie den häufigeren Fehler behebt.
Wie viele Beispiele brauche ich für Fine-Tuning?
Für die Anpassung von Stil und Format bringen ein paar hundert konsistente Beispiele oft eine messbare Verbesserung. Für komplexere Denkmuster rechne mit Tausenden. Qualität und Konsistenz zählen mehr als die reine Anzahl.
Merkt sich das Modell durch Fine-Tuning meine Dokumentation?
Nicht zuverlässig. Es übernimmt Vokabular und Formulierungen, wird aber keine vertrauenswürdige Faktenquelle, und alles, was sich nach dem Training ändert, bleibt ihm verborgen. Nutze Retrieval für Fakten.
Wann reicht Prompt Engineering nicht mehr aus?
Wenn dem Modell die nötigen Informationen fehlen (nutze RAG), oder wenn der Prompt, der für das richtige Verhalten nötig ist, so lang wird, dass er bei deinem Anfragevolumen Kosten oder Latenz dominiert (erwäge Fine-Tuning).
Wo du anfängst
Wenn dein LLM-Feature enttäuschende Ausgaben produziert, investiere einen Tag in den Prompt, bevor du einen Monat in irgendetwas anderes steckst. Wenn die Fehler faktischer Natur sind, füge Retrieval hinzu und miss es getrennt. Wenn die Fehler stilistisch sind und du bei relevantem Volumen bist, fine-tune. Diese Reihenfolge vermeidet die beiden teuersten Fehler, die wir sehen: Fine-Tuning, um ein Prompt-Problem zu beheben, und Fine-Tuning, um ein Wissensproblem zu beheben.
Wolf-Tech hilft SaaS-Teams beim Entwurf und Review von LLM-Integrationen, einschließlich der Architekturentscheidungen rund um Retrieval und Modellanpassung. Wenn du eine zweite Meinung dazu willst, wohin sich dein System als Nächstes entwickeln sollte, schreib an hello@wolf-tech.io oder lies mehr über unsere Arbeit in der individuellen Softwareentwicklung und im Code Quality Consulting auf wolf-tech.io.