Fine-Tuning vs. RAG vs. Prompting: wann was?

Drei Werkzeuge fuer dasselbe Grundproblem

Ein Basismodell wie Claude, GPT oder ein offenes Modell wie Llama kennt dein Unternehmen nicht, deinen internen Tonfall nicht und dein aktuelles Ticket-System nicht. Die Frage, die sich bei praktisch jedem produktiven KI-Projekt stellt: Wie bringst du dem Modell das bei, was es fuer deinen konkreten Anwendungsfall wissen oder koennen muss?

Dafuer gibt es genau drei grundsaetzlich verschiedene Hebel, und sie loesen unterschiedliche Probleme:

• Prompting - du formulierst Anweisung und Kontext im Moment der Anfrage. Das Modell selbst bleibt unveraendert.
• RAG (Retrieval Augmented Generation) - du lieferst zur Laufzeit passende Fakten aus einer eigenen Wissensbasis dazu. Das Modell selbst bleibt ebenfalls unveraendert, nur der Prompt wird automatisch angereichert.
• Fine-Tuning - du trainierst die Gewichte des Modells selbst mit zusaetzlichen Beispieldaten weiter. Das Modell veraendert sich dauerhaft.

Der haeufigste Fehler in der Praxis ist nicht die falsche Wahl zwischen diesen drei Optionen, sondern der Reflex, zu frueh zu Fine-Tuning zu greifen, obwohl ein besserer System-Prompt oder ein einfacher RAG-Aufbau dasselbe Ergebnis in einem Bruchteil der Zeit liefert. Dieser Artikel ordnet die drei Ansaetze ein und liefert eine konkrete Entscheidungshilfe.

Die drei Ansaetze im Ueberblick

Prompting: der Standardweg fuer die meisten Faelle

Prompting ist die guenstigste und schnellste Anpassung, weil sie an keiner Infrastruktur haengt - nur am Text, den du ins Modell schickst. Ein guter System-Prompt mit klarer Rolle, expliziten Regeln, Formatvorgaben und ein paar Few-Shot-Beispielen bringt viele Modelle erstaunlich nah an das gewuenschte Verhalten heran. Details zu Aufbau und Testing stehen in Prompting-Vertiefung und System-Prompts und Prompt-Engineering fuer Entwickler.

System-Prompt (Auszug):
Du bist der Kategorisierungs-Assistent fuer eingehende Support-Tickets.
Antworte ausschliesslich als JSON mit den Feldern "kategorie", "prioritaet",
"zusammenfassung". Beispiel:
{"kategorie": "Netzwerk", "prioritaet": "hoch", "zusammenfassung": "VPN faellt seit Update aus"}

Die Grenzen von Prompting liegen dort, wo Wissen oder Beispiele nicht mehr ins Kontextfenster passen (siehe Tokens und Kontextfenster), wo sich Fakten staendig aendern, oder wo dieselbe Anweisung bei Tausenden Anfragen pro Tag nicht zuverlaessig genug befolgt wird. Genau an diesen zwei Grenzen setzen RAG beziehungsweise Fine-Tuning an.

RAG: Wissen nachliefern statt einbrennen

RAG loest gezielt das Wissensproblem: Statt zu hoffen, dass das Modell aus seinem Trainingswissen die richtige Antwort kennt, holt eine Suche zur Laufzeit passende Ausschnitte aus deiner eigenen Wissensbasis (Handbuecher, Tickets, Confluence, Produktdaten) und mischt sie in den Prompt. Das Modell selbst wird dabei nicht veraendert - es bekommt lediglich bessere Zutaten fuer die jeweilige Antwort.

[System-Prompt] + [automatisch abgerufene Chunks aus der Wissensbasis] + [Nutzerfrage]
  → an das unveraenderte Modell
  → Antwort, die sich auf die gelieferten Fakten stuetzt

Der grosse Vorteil: Aenderst du die Wissensbasis (neue Preisliste, aktualisiertes Handbuch), wirkt sich das sofort auf die naechste Antwort aus - kein neuer Trainingslauf noetig. Der Nachteil: RAG bringt kein neues Verhalten mit, nur neue Fakten. Ein Modell, das partout nicht im gewuenschten Format antwortet, wird das auch mit perfektem RAG-Kontext nicht automatisch tun - dafuer braucht es einen guten System-Prompt oder eben Fine-Tuning. Wie man eine RAG-Pipeline konkret aufbaut, steht in RAG selbst bauen; die Konzepte dahinter (Embeddings, Vektor-Suche) in Embeddings und Vektoren erklaert und Vektordatenbanken.

Fine-Tuning: das Modell selbst veraendern

Fine-Tuning trainiert die Gewichte eines bereits vortrainierten Modells mit zusaetzlichen, meist deutlich kleineren Datensaetzen weiter, sodass sich Muster aus diesen Daten dauerhaft im Modellverhalten niederschlagen. Anders als bei Prompting und RAG ist das Ergebnis nicht “mehr Kontext fuer diese eine Anfrage”, sondern ein tatsaechlich veraendertes Modell, das sich fuer jede zukuenftige Anfrage anders verhaelt.

In der Praxis unterscheiden sich mehrere Verfahren deutlich in Aufwand und Wirkung (Stand: 2026-07, konkrete Angebote je Anbieter pruefen):

Wichtig fuer die Anbieterwahl: Nicht jeder Modellanbieter bietet Fine-Tuning fuer sein Flaggschiff-Modell an. Anthropics Claude-API bietet fuer die Standard-Modelle aktuell kein selbstbedienbares Fine-Tuning an (Stand: 2026-07) - Claude ist zwar selbst intern mit RLHF trainiert, Kundinnen und Kunden passen es aber ueber Prompting, RAG und Tool-Use an. Andere Anbieter (etwa OpenAI mit SFT-, DPO- und RFT-Optionen fuer ausgewaehlte Modelle, oder Cloud-Plattformen fuer offene Modelle wie Llama/Mistral per LoRA/QLoRA) stellen dagegen dedizierte Fine-Tuning-Angebote bereit - wobei OpenAI seine eigene Fine-Tuning-Plattform fuer neue Kundinnen und Kunden bereits nicht mehr zugaenglich macht (Stand: 2026-07, bestehende Nutzerinnen und Nutzer koennen vorerst weiter Trainingslaeufe starten) - solche Angebote koennen sich also aendern, vor einer Entscheidung immer die aktuelle Anbieter-Dokumentation pruefen. Wer auf ein geschlossenes Modell ohne Fine-Tuning-API setzt, ist fuer Anpassungen also ohnehin auf Prompting und RAG angewiesen - was in der Praxis fuer die grosse Mehrheit der Anwendungsfaelle auch ausreicht (siehe unten). Mehr zu offenen und geschlossenen Modellen generell in Open- vs. Closed-Source-Modelle, zum Selbstbetrieb offener Modelle in Lokale Modelle betreiben.

# Konzeptionelles Beispiel: SFT-Job bei einem Anbieter mit Fine-Tuning-API
# (Feldnamen/Endpunkte variieren je Anbieter, Stand: 2026-07 pruefen)
job = client.fine_tuning.jobs.create(
    training_file="file-abc123",      # JSONL mit Eingabe/Ausgabe-Paaren
    model="basis-modell-name",
    method={"type": "supervised"},    # oder "dpo", "reinforcement"
)

Kosten und Aufwand im Vergleich

Die drei Ansaetze unterscheiden sich nicht nur technisch, sondern auch darin, wo genau die Kosten anfallen:

• Prompting: praktisch keine Zusatzkosten ausser den normalen API-Token-Kosten - laengere Prompts kosten mehr Tokens pro Anfrage, aber es gibt keine separate Infrastruktur. Siehe Tokens und Kosten optimieren fuer Feintuning der laufenden Kosten.
• RAG: zusaetzliche Infrastruktur (Vektor-Datenbank, Embedding-Aufrufe bei Indexierung und jeder Anfrage), aber die Kosten skalieren moderat mit der Wissensbasis-Groesse und lassen sich schrittweise ausbauen.
• Fine-Tuning: einmalige, teils erhebliche Trainingskosten (abhaengig von Datenmenge und Modellgroesse), oft zusaetzlich teurere oder dedizierte Inferenz-Infrastruktur fuer das eigene, feinabgestimmte Modell, plus laufender Wartungsaufwand bei jedem neuen Trainingslauf.

Entscheidungsbaum

Braucht die KI aktuelles oder firmenspezifisches WISSEN
(Preise, Handbuecher, Tickets, interne Dokumente)?
  JA  → Reicht das Wissen in den Prompt (wenige Dokumente, selten geaendert)?
          JA  → Prompting reicht: Dokument(e) direkt in den System-Prompt
          NEIN → RAG: Wissensbasis mit Retrieval anbinden
  NEIN → Geht es eher um VERHALTEN/FORMAT/STIL
        (immer gleiches JSON-Schema, bestimmter Tonfall, Aufgaben-Reflex)?
          JA  → Reicht ein klarer System-Prompt mit Beispielen und
                erzwungenem Ausgabeschema (Structured Outputs/Tool-Use)?
                  JA  → Prompting reicht
                  NEIN → Fine-Tuning pruefen (SFT/DPO/LoRA je nach Modell/Anbieter),
                         aber erst nach Test mit optimiertem Prompt
          NEIN → Ist die Aufgabe hochspezialisiert, mit vielen Tausend
                 konsistenten Beispielen UND einem klar messbaren
                 Erfolgskriterium (z.B. Diagnose, Klassifizierung
                 in Nischendomaene)?
                  JA  → Fine-Tuning (ggf. RFT) ist ein starker Kandidat
                  NEIN → mit Prompting + RAG starten, Fine-Tuning
                         nur bei nachgewiesenem Bedarf nachruesten

Warum Prompting plus RAG fuer die meisten Faelle reicht

Die grosse Mehrheit produktiver KI-Anwendungen - Support-Chatbots, interne Assistenten, Dokumenten-Zusammenfassungen, Klassifizierung von Anfragen - loest ein Wissensproblem, kein tief verwurzeltes Verhaltensproblem. Moderne Modelle folgen gut formulierten Anweisungen bereits sehr zuverlaessig, und ein Kontextfenster von hunderttausenden Tokens erlaubt es, erstaunlich viel Kontext direkt mitzugeben, statt das Modell selbst zu veraendern (siehe Tokens und Kontextfenster). Kombiniert mit RAG fuer aktuelles, firmenspezifisches Wissen deckt Prompting damit einen grossen Teil der Anforderungen ab, die frueher als klassische Fine-Tuning-Faelle galten.

Dazu kommt ein praktischer Grund: Prompting und RAG sind reversibel und sofort testbar. Ein schlecht formulierter System-Prompt laesst sich in Sekunden korrigieren, ein Retrieval-Problem laesst sich isoliert debuggen (siehe RAG selbst bauen). Ein schlecht trainiertes Fine-Tuning-Modell dagegen erfordert einen neuen, teuren Trainingslauf, um korrigiert zu werden - und ob die Korrektur tatsaechlich wirkt, zeigt sich erst nach dem naechsten Lauf.

Wann Fine-Tuning tatsaechlich Sinn macht

Es gibt reale Faelle, in denen Fine-Tuning der richtige Hebel ist - typischerweise, wenn eines oder mehrere dieser Kriterien zutreffen:

• Sehr hohes Anfragevolumen mit engem Aufgabenprofil: Bei Millionen taeglicher Anfragen fuer eine eng umrissene Aufgabe (z.B. Klassifizierung in eine feste Kategorienliste) kann ein kleineres, feinabgestimmtes Modell die Inferenzkosten gegenueber einem grossen Modell mit langem Prompt deutlich senken.
• Konsistentes Verhalten, das Prompting nicht zuverlaessig genug erzwingt: Wenn selbst ein sorgfaeltig getesteter System-Prompt bei einem kleinen Prozentsatz der Anfragen abweicht und diese Abweichung geschaeftskritisch ist, kann Fine-Tuning die Zuverlaessigkeit erhoehen.
• Sehr spezialisiertes Fachvokabular oder eine ungewoehnliche Struktur, die sich schlecht in einen Prompt packen laesst - etwa ein sehr eigenwilliges internes Datenformat oder eine Nischensprache/-domaene mit wenig Trainingsdaten im Basismodell.
• Latenz- oder Kostenanforderungen, die einen deutlich kleineren, spezialisierten Modell-Footprint erfordern, der ohne Fine-Tuning die Qualitaet nicht erreichen wuerde.
• Datenhoheit und lokaler Betrieb: Wenn ein offenes Modell lokal betrieben und auf unternehmenseigene Daten zugeschnitten werden soll, ist LoRA/QLoRA-Fine-Tuning oft Teil des Betriebskonzepts - siehe Lokale LLMs und Datenhoheit.

Zusammenfassung

• Prompting veraendert nichts am Modell, nur den Text der jeweiligen Anfrage - schnellster, guenstigster und am einfachsten testbarer Hebel.
• RAG liefert aktuelles, firmenspezifisches Wissen automatisch in den Prompt, ohne das Modell selbst zu veraendern - der richtige Weg fuer Wissensprobleme.
• Fine-Tuning veraendert die Modellgewichte dauerhaft (Full Fine-Tuning, LoRA/QLoRA, SFT, DPO, RFT je nach Verfahren) und eignet sich fuer stabiles, wiederkehrendes Verhalten - nicht fuer bewegliches Wissen.
• Nicht jeder Modellanbieter bietet Fine-Tuning fuer sein Top-Modell an - pruefe vor der Entscheidung, ob dein bevorzugtes Modell ueberhaupt eine Fine-Tuning-Option hat.
• Fuer die grosse Mehrheit produktiver Anwendungsfaelle reicht Prompting kombiniert mit RAG - Fine-Tuning lohnt sich erst bei hohem Volumen, engem Aufgabenprofil oder nachgewiesenem, wiederholtem Prompting-Versagen.
• Alle drei Ansaetze lassen sich kombinieren; die Reihenfolge in der Praxis ist fast immer: Prompting optimieren, RAG ergaenzen, Fine-Tuning nur bei nachgewiesenem Bedarf nachruesten.

Weiterlernen

• Anthropic - Fine-tuning (Glossar-Eintrag) - offizielle Einordnung, dass die Claude-API aktuell kein Self-Service-Fine-Tuning anbietet
• OpenAI - Model Optimization / Fine-Tuning Guide - offizielle Uebersicht zu SFT, DPO, RFT und Vision Fine-Tuning
• Anthropic - Prompt Engineering Overview - Grundlagen fuer den ersten, meist ausreichenden Hebel
• Hugging Face - PEFT / LoRA Dokumentation - Referenz zu LoRA/QLoRA fuer offene Modelle
• Cloudflare - Vectorize Documentation - Vektor-Datenbank als Baustein fuer RAG
• Ragas Documentation - Evaluationsmetriken - Qualitaetsmessung, relevant bevor du ueberhaupt an Fine-Tuning denkst

Verwandte Themen: RAG selbst bauen · System-Prompts und Prompt-Engineering · Open- vs. Closed-Source-Modelle · Lokale Modelle betreiben · Tokens und Kosten optimieren