RAG vs. Fine-Tuning vs. Prompting: Die richtige Wahl treffen

1. Drei Ansätze, ein häufiges Missverständnis

Prompting, RAG und Fine-Tuning lösen unterschiedliche Probleme, und genau das wird in Architekturdiskussionen oft übersehen. Prompting verändert, wie Claude eine Aufgabe im aktuellen Kontextfenster angeht, ohne dass zusätzliches Wissen oder dauerhaftes Verhalten eingebaut wird. RAG erweitert das Kontextfenster zur Laufzeit um extern abgerufene Informationen. Fine-Tuning verändert die Gewichte des Modells selbst und damit sein grundsätzliches Antwortverhalten, unabhängig vom jeweiligen Prompt.

Die Verwechslung entsteht meist, weil alle drei Ansätze am Ende dasselbe sichtbare Symptom adressieren: Das Modell soll etwas wissen oder können, das es standardmäßig nicht zeigt. Die richtige Frage ist aber nicht Wie bringe ich Claude etwas bei, sondern Ändert sich das zugrunde liegende Wissen, oder ändert sich das gewünschte Verhalten. Diese Unterscheidung entscheidet über Kosten, Wartungsaufwand und Aktualität über Monate hinweg, nicht nur über die erste Implementierung.

2. Reines Prompting: Wann es ausreicht

Reines Prompting ist die richtige Wahl, wenn die benötigten Informationen bereits im Kontextfenster Platz finden und die Aufgabe einmalig oder selten ist. Ein Beispiel: ein Entwickler lässt Claude eine 800-Zeilen-Datei refaktorieren, gibt Coding-Konventionen als System-Prompt mit und erhält eine Antwort, die genau auf diesen einen Anwendungsfall zugeschnitten ist. Es gibt keinen wiederkehrenden Bedarf, kein wachsendes Wissenskorpus und keine Notwendigkeit, das Verhalten über viele Sitzungen hinweg konsistent zu halten.

Der Denkfehler an dieser Stelle ist häufig die Annahme, ein größeres Kontextfenster mache RAG grundsätzlich überflüssig. Das stimmt nur für begrenzte, klar abgesteckte Datenmengen. Sobald ein Wissenskorpus wächst, sich mehrfach täglich ändert oder aus verschiedenen Quellen stammt, wird das Kontextfenster zum Nadelöhr: Jeder Request lädt unnötig viele irrelevante Tokens, die Latenz steigt, und die Kosten pro Anfrage wachsen linear mit der Größe des eingebetteten Wissens.

Prompt-Beispiel für reines Prompting (einmalige, klar abgegrenzte Aufgabe):

System: Du bist ein Senior-PHP-Entwickler. Halte dich an PSR-12 und
Constructor Property Promotion.

User: Refaktoriere die folgende Klasse, extrahiere die
Validierungslogik in eine eigene Methode und ergänze PHPDoc-Blöcke.
<800 Zeilen Code folgen>

-> Keine externe Wissensquelle nötig, kein wiederkehrender Bedarf.
   Prompting reicht vollständig aus.

3. RAG: Wenn sich das zugrunde liegende Wissen häufig ändert

RAG ist die richtige Wahl, wenn die Wissensbasis größer ist als ein einzelnes Kontextfenster oder sich regelmäßig ändert, etwa Produktdaten, interne Dokumentation, Support-Tickets oder Rechtstexte. Statt Wissen fest im Modell zu verankern, ruft die Pipeline zur Laufzeit die jeweils relevanten Dokumente ab und reicht sie als Kontext an Claude weiter. Ändert sich ein Dokument, ist die Änderung sofort wirksam, ohne dass ein Trainingslauf nötig wird.

Claude eignet sich gut dafür, die Retrieval-Strategie selbst mitzugestalten: Welche Metadatenfelder sollten für die Filterung genutzt werden, wie sollte die Ergebnisliste nach Relevanz und Aktualität gewichtet werden, und welche Formulierung im System-Prompt verhindert, dass das Modell bei fehlenden Treffern Informationen erfindet. Diese Fragen lassen sich vor der Implementierung gezielt mit Claude durchspielen, bevor die erste Zeile Infrastruktur-Code entsteht.

Prompt an Claude, um die Retrieval-Strategie vorab zu klären:

Wir bauen ein Support-Wissenssystem mit 40.000 Tickets, täglich
kommen ca. 200 neue hinzu. Entwirf eine Retrieval-Strategie:
- Welche Metadaten (Produkt, Datum, Lösungsstatus) sollten gefiltert
  werden, bevor die Vektorsuche läuft?
- Wie verhindern wir, dass veraltete, geschlossene Tickets mit
  falschen Lösungen bevorzugt zurückgegeben werden?
- Welche System-Prompt-Formulierung reduziert Halluzinationen bei
  fehlenden Treffern am zuverlässigsten?

4. Fine-Tuning: Wenn sich Verhalten oder Stil ändern soll, nicht das Wissen

Fine-Tuning verändert, wie ein Modell antwortet, nicht primär, was es weiß. Sinnvoll ist Fine-Tuning, wenn ein konsistenter Ausgabestil über tausende Anfragen hinweg gebraucht wird, etwa ein festes JSON-Format ohne wiederholte Few-Shot-Beispiele, ein markentypischer Tonfall in Kundenkommunikation, oder die zuverlässige Anwendung einer domänenspezifischen Klassifikationslogik, die sich über einfache Instruktionen nicht robust genug erzwingen lässt.

Der entscheidende Unterschied zu RAG: Fine-Tuning-Daten sind eine Momentaufnahme. Das Modell lernt Muster aus Beispielen, nicht einen aktuellen Faktenstand. Wird ein neues Feature ausgeliefert oder ändert sich eine Preisliste, hilft kein Fine-Tuning, denn die gelernten Muster spiegeln weiterhin den Stand zum Zeitpunkt des Trainings wider. Genau diese Verwechslung führt zu einem der teuersten Architekturfehler in produktiven KI-Systemen.

5. Der klassische Fehler: Fine-Tuning für aktuelles Wissen

In der Praxis begegnet mir immer wieder derselbe Fehlschluss: ein Team stellt fest, dass Claude eine interne Produktfrage nicht korrekt beantwortet, und der erste Reflex lautet dann trainieren wir das Modell auf unsere Daten. Das Ergebnis ist ein Fine-Tuning-Lauf, der teuer ist, Wochen dauert und am Ende ein Modell liefert, das schon am Tag nach dem Release wieder veraltet ist, sobald sich ein einziges Produktdetail ändert.

Das eigentliche Problem war in fast allen diesen Fällen kein Verhaltensproblem, sondern ein fehlender Wissenszugriff. Ein RAG-System mit einer sauber gepflegten Dokumenten-Pipeline hätte dasselbe Ergebnis in einem Bruchteil der Zeit erreicht, wäre bei jeder Produktänderung automatisch aktuell geblieben und hätte keinen erneuten Trainingslauf erfordert. Die Faustregel lautet: Ändert sich der Fakteninhalt öfter als das gewünschte Antwortverhalten, ist RAG fast immer die günstigere und robustere Lösung.

6. Kostenvergleich über die Systemlaufzeit

Prompting verursacht keine Vorabkosten, dafür aber laufende Tokenkosten, die mit der Menge des eingebetteten Kontexts pro Anfrage wachsen. RAG erfordert einmalige Infrastrukturinvestition in Embedding-Pipeline und Vektordatenbank, danach bleiben die Betriebskosten weitgehend proportional zur Anzahl der Anfragen und zur Größe der abgerufenen Kontextfenster, unabhängig davon, wie stark die zugrunde liegende Datenmenge wächst.

Fine-Tuning verursacht die höchsten Vorabkosten durch Trainingsläufe und Datenaufbereitung, dazu kommen wiederkehrende Kosten für jede erneute Anpassung, sobald sich Anforderungen ändern. Über eine Systemlaufzeit von zwölf bis vierundzwanzig Monaten gerechnet, ist RAG in den allermeisten wissensintensiven Anwendungsfällen günstiger, weil die Trainingskosten komplett entfallen und Aktualisierungen ohne neuen Trainingslauf möglich sind.

7. Hybride Ansätze: RAG und Fine-Tuning kombinieren

In komplexeren Systemen schließen sich die Ansätze nicht gegenseitig aus. Ein verbreitetes Muster: Fine-Tuning für einen konsistenten Ausgabestil und eine domänenspezifische Klassifikationslogik, kombiniert mit RAG für die faktische Grundlage. Das Modell lernt per Fine-Tuning, wie es strukturierte Support-Antworten formuliert, während die konkreten Fakten pro Anfrage frisch aus der Wissensdatenbank abgerufen werden.

Auch die Kombination aus RAG und gezieltem Prompting ist üblich: RAG liefert den Kontext, ein sorgfältig formulierter System-Prompt steuert, wie mit widersprüchlichen oder unvollständigen Retrieval-Ergebnissen umgegangen wird. Diese Kombination deckt die meisten produktiven Anwendungsfälle ab, ohne dass ein einziges Fine-Tuning nötig wird, und bleibt dabei deutlich einfacher zu warten als ein trainiertes Modell.

8. Den Entscheidungsprozess mit Claude durchspielen

Bevor die erste Architekturentscheidung fällt, lohnt es sich, Claude selbst als Sparringspartner für die Analyse zu nutzen. Ein präzise formulierter Prompt, der den Anwendungsfall, die Änderungshäufigkeit der Daten und das Budget beschreibt, liefert häufig eine belastbare erste Einschätzung, welcher Ansatz oder welche Kombination am besten passt, inklusive der Fragen, die intern noch geklärt werden müssen.

Wichtig ist dabei, Claude nicht nach einer pauschalen Empfehlung zu fragen, sondern nach den konkreten Entscheidungskriterien für den eigenen Fall. Fragen wie Wie oft ändert sich die Datenbasis, Wie kritisch ist absolute Aktualität und Wie hoch ist das Anfragevolumen pro Tag liefern zusammen ein deutlich verlässlicheres Bild als eine allgemeine Frage nach RAG versus Fine-Tuning.

Prompt-Vorlage für die Architektur-Entscheidung:

Anwendungsfall: [kurze Beschreibung]
Änderungshäufigkeit der Wissensbasis: [täglich / wöchentlich / selten]
Anfragevolumen: [Anfragen pro Tag]
Budget-Rahmen: [einmalig vs. laufend]
Kritikalität von Aktualität: [hoch / mittel / niedrig]

Frage: Welcher Ansatz (Prompting, RAG, Fine-Tuning, Kombination) passt
am besten, und welche zwei bis drei Risiken sollte ich vor der
Implementierung klären?

9. Migration zwischen Ansätzen erkennen und planen

Systeme entwickeln sich weiter, und ein Ansatz, der am Anfang richtig war, kann nach einem Jahr an seine Grenzen stoßen. Typisches Signal für eine Migration von Prompting zu RAG: die Kontextgröße pro Anfrage wächst kontinuierlich, weil immer mehr Referenzmaterial manuell eingefügt wird, und die Wartung der Prompt-Vorlagen wird zunehmend unübersichtlich.

Ein Signal für den Wechsel von RAG zu einer Fine-Tuning-Ergänzung ist, wenn trotz korrektem Retrieval das Antwortformat inkonsistent bleibt, etwa weil komplexe Formatierungsregeln über Few-Shot-Beispiele im Prompt nicht mehr zuverlässig eingehalten werden. Wer diese Signale früh erkennt, vermeidet eine teure Neuentwicklung und kann die bestehende Pipeline schrittweise erweitern statt komplett neu zu bauen.

10. Zusammenfassung

11. FAQ: RAG, Fine-Tuning und Prompting: Das Wichtigste auf einen Blick