Fine-Tuning vs. RAG vs. Prompt Engineering: Wann was?

Wenn ein Team anfängt, LLMs produktiv einzusetzen, kommt früher oder später die Frage: Reicht Prompt Engineering, oder brauchen wir RAG? Und wann lohnt sich Fine-Tuning eigentlich?

Die Frage ist legitim, aber sie wird oft zu früh gestellt — bevor klar ist, welches Problem genau gelöst werden soll. Das Ergebnis: Teams investieren Wochen in RAG-Infrastruktur für einen Use-Case, den ein gut geschriebener System-Prompt in zwei Stunden löst. Oder sie finetunen ein Modell für Daten, die sich monatlich ändern, und fragen sich dann, warum die Ausgaben veralten.

Dieser Guide soll das sortieren. Nicht abstrakt, sondern mit den Mustern, die sich in der Praxis zeigen.

Was die drei Ansätze grundlegend unterscheidet

Alle drei Ansätze verfolgen dasselbe Ziel: ein Sprachmodell so zu steuern, dass es für einen bestimmten Kontext nützlichere Ausgaben produziert. Aber sie tun das auf grundlegend verschiedenen Ebenen.

Prompt Engineering ändert nichts am Modell. Es steuert das Verhalten über den Eingabetext — System-Prompts, Few-Shot-Beispiele, Anweisungen zur Formatierung oder zum Reasoning-Stil. Schnell zu iterieren, keine Infrastruktur nötig, sofort anpassbar.

RAG (Retrieval-Augmented Generation) erweitert den Kontext zur Laufzeit. Das Modell selbst bleibt unverändert; stattdessen wird aus einer Wissensbasis relevante Information abgerufen und dem Prompt beigefügt. Das Modell antwortet auf Basis dieser Dokumente, nicht allein auf Basis seines Trainings.

Fine-Tuning ändert die Modellgewichte. Durch Training auf einem task-spezifischen Datensatz lernt das Modell ein neues Verhaltensmuster, eine neue Tonalität oder domänenspezifisches Wissen — dauerhaft, ohne dass diese Information bei jedem Request mitgesendet werden muss.

Die wichtigsten Unterschiede auf einen Blick:

Kriterium	Prompt Engineering	RAG	Fine-Tuning
Einrichtungsaufwand	Stunden	Tage–Wochen	Wochen–Monate
Laufende Kosten	Token-Kosten	Token + Infrastruktur	Training + Inferenz
Aktualisierbarkeit	Sofort	Sofort (Re-Index)	Neues Training nötig
Wissenstiefe	Begrenzt durch Context Window	Skaliert mit Datenbasis	Im Modell verankert
Datenmenge nötig	Keine	Ab ~50 Dokumenten sinnvoll	Hunderte–Tausende Beispiele
Verhaltensänderung	Schwach	Keine	Stark

Prompt Engineering reicht oft weiter als gedacht — bis es nicht mehr reicht

Die häufigste Fehlentscheidung ist, zu früh auf RAG oder Fine-Tuning zu wechseln. Prompt Engineering hat einen schlechten Ruf, weil schlecht geschriebene Prompts schlechte Ergebnisse liefern — und diese dann dem Ansatz angelastet werden, nicht der Ausführung.

Was Prompt Engineering zuverlässig löst:

Ausgabeformatierung (JSON, Markdown, strukturierte Felder)
Tonalität und Stil (formell, prägnant, auf Zielgruppe ausgerichtet)
Mehrstufiges Reasoning (Chain-of-Thought, Selbstkritik, Verifikation)
Rollenmodellierung (Experte für X, kritischer Reviewer)
Einschränkungen und Guardrails (Thema eingrenzen, Sicherheitsregeln)

Ein gut strukturierter System-Prompt mit drei bis fünf klaren Anweisungen und einem Few-Shot-Beispiel löst viele Probleme, für die Teams unnötig Infrastruktur aufbauen.

Wo Prompt Engineering an Grenzen stößt:

Das benötigte Wissen ist nicht im Modell vorhanden (proprietäre Daten, aktuelles Wissen, interne Dokumente)
Der Kontext überschreitet das Context Window des Modells
Das Verhalten soll konsistent und unabhängig von der Qualität der Prompt-Formulierung sein
Eine spezifische Ausgabestruktur soll zuverlässig reproduziert werden, ohne jedes Mal erklärt zu werden

RAG in der Praxis: Was funktioniert, was nicht

RAG ist der richtige Ansatz, wenn das Modell Zugriff auf Informationen braucht, die nicht in seinem Training stehen — oder die sich regelmäßig ändern. Interne Dokumentation, Produktdatenbanken, Wissensdatenbanken aus dem Support, aktuelle Preise.

Die Grundarchitektur

Ein RAG-System besteht aus zwei Phasen: Indexierung und Retrieval.

Beim Indexing werden Dokumente in Chunks aufgeteilt, als Embeddings kodiert und in einer Vektordatenbank gespeichert. Beim Retrieval wird die Anfrage des Nutzers ebenfalls als Embedding kodiert, die ähnlichsten Chunks werden abgerufen, und diese werden dem Prompt als Kontext beigefügt.

from openai import OpenAI
import chromadb

client = OpenAI()
chroma = chromadb.Client()
collection = chroma.create_collection("knowledge_base")

def index_documents(docs: list[dict]):
    """Dokumente in Vektordatenbank indexieren."""
    for doc in docs:
        response = client.embeddings.create(
            model="text-embedding-3-small",
            input=doc["text"]
        )
        collection.add(
            ids=[doc["id"]],
            embeddings=[response.data[0].embedding],
            documents=[doc["text"]],
            metadatas=[{"source": doc["source"]}]
        )

def retrieve(query: str, n_results: int = 5) -> list[str]:
    """Relevante Chunks für eine Anfrage abrufen."""
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=query
    )
    results = collection.query(
        query_embeddings=[response.data[0].embedding],
        n_results=n_results
    )
    return results["documents"][0]

def answer_with_rag(question: str) -> str:
    """Frage mit RAG-Kontext beantworten."""
    chunks = retrieve(question)
    context = "\n\n".join(chunks)

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {
                "role": "system",
                "content": (
                    "Du beantwortest Fragen ausschließlich auf Basis "
                    "der bereitgestellten Dokumente. Wenn die Antwort "
                    "nicht in den Dokumenten steht, sage das explizit."
                )
            },
            {
                "role": "user",
                "content": f"Kontext:\n{context}\n\nFrage: {question}"
            }
        ]
    )
    return response.choices[0].message.content

Typische Fallstricke

Zu kleine Datenbasis. RAG über 20 Dokumente zu betreiben ist selten sinnvoll. Bei so kleinen Mengen lässt sich die gesamte Wissensbasis in den Kontext packen — oder das Problem löst Prompt Engineering. Retrieval ergibt erst ab einer Datenmenge Sinn, die das Context Window sprengt.

Chunk-Größen falsch gewählt. Zu kleine Chunks (unter 200 Token) verlieren Kontext, zu große Chunks rauschen. Ein Chunk von 512–1024 Token mit 10–20 % Überlappung funktioniert in den meisten Fällen gut. Aber das hängt vom Dokumenttyp ab — bei juristischen Texten oder Handbüchern gelten andere Optima.

Kein Re-Ranking. Das initiale Embedding-Retrieval ist nicht perfekt. Semantische Ähnlichkeit ist nicht dasselbe wie Relevanz. Für kritische Anwendungen lohnt sich ein zweiter Schritt: Die Top-10 Chunks werden durch ein Cross-Encoder-Modell oder ein LLM nach tatsächlicher Relevanz sortiert, bevor nur die Top-3 in den Prompt kommen.

Halluzination trotz Retrieval. Wenn das Retrieval nicht die richtigen Chunks liefert, halluziniert das Modell trotzdem. Eine häufige Ursache: Die Frage des Nutzers und die Formulierung im Dokument sind semantisch unterschiedlich. Abhilfe: Query-Reformulierung (die Anfrage wird vor dem Retrieval vom Modell umformuliert) oder Hypothetical Document Embeddings (HyDE).

Fine-Tuning: Wann es sich lohnt, wann es überdimensioniert ist

Fine-Tuning ist das schwerste Werkzeug in diesem Set. Es verändert das Modell selbst, erfordert einen hochwertigen Trainingsdatensatz, kostet Zeit und Geld — und macht Sinn in einem überraschend kleinen Subset der Anwendungsfälle.

Fine-Tuning lohnt sich, wenn:

Verhalten konsistent sein muss, unabhängig davon, wie der Prompt formuliert ist. Beispiel: Ein Modell soll immer in einem spezifischen JSON-Schema antworten, auch wenn der Nutzer nicht danach fragt.
Domänenspezifische Formulierungen gelernt werden müssen, die nicht durch Prompt Engineering übermittelt werden können — Fachvokabular, Schreibstil eines Unternehmens, spezifische Reasoning-Patterns.
Inferenzkosten minimiert werden sollen: Ein kleines Fine-Tuned-Modell kann günstiger sein als ein großes Modell mit langem System-Prompt.
Das Verhalten stabil bleiben soll, auch wenn das Basismodell gewechselt oder aktualisiert wird (mit erneutem Fine-Tuning auf dem neuen Basis).

Fine-Tuning ist die falsche Wahl, wenn:

Die Daten sich regelmäßig ändern. Fine-Tuning “brennt” Wissen ins Modell — bei veränderten Daten braucht es ein neues Training.
Der Datensatz zu klein ist. Unter einigen Hundert hochwertigen Beispielen ist Fine-Tuning meist Rauschen.
Das eigentliche Problem schlechte Prompts sind. Fine-Tuning auf schlechten Beispielen verschlechtert das Modell.
Kein Evaluationsset vorhanden ist. Ohne systematisches Testing ist nicht messbar, ob Fine-Tuning geholfen hat.

Ein klassischer Fehler aus der Praxis: Teams sammeln 50 Konversationen aus dem internen Support, finetunen ein Modell darauf — und wundern sich, dass es schlechter antwortet als das Basismodell. Die Ursache ist fast immer Datensatzqualität, nicht das Verfahren.

Für OpenAI-Fine-Tuning sieht der Trainingsdatensatz so aus:

import json

# Trainingsdaten im JSONL-Format für OpenAI Fine-Tuning
training_examples = [
    {
        "messages": [
            {
                "role": "system",
                "content": "Du bist ein Support-Assistent für ein B2B-SaaS-Produkt. Antworte präzise, freundlich und immer auf Deutsch."
            },
            {
                "role": "user",
                "content": "Wie kann ich meinen API-Key rotieren?"
            },
            {
                "role": "assistant",
                "content": "API-Keys lassen sich im Bereich Einstellungen → API-Zugang rotieren. Klicken Sie dort auf 'Neuen Key generieren' — der alte Key wird sofort deaktiviert. Stellen Sie sicher, dass der neue Key in allen Integrationen hinterlegt ist, bevor Sie die Rotation bestätigen."
            }
        ]
    }
    # ... weitere Beispiele
]

# Als JSONL-Datei speichern
with open("training_data.jsonl", "w") as f:
    for example in training_examples:
        f.write(json.dumps(example, ensure_ascii=False) + "\n")

Entscheidungsmatrix: Konkrete Kriterien für die Wahl

Statt einer abstrakten Empfehlung hier ein direktes Entscheidungsschema, das in der Praxis funktioniert:

Schritt 1: Ist das Problem überhaupt ein Wissensproblem?

Wenn das Modell das nötige Wissen hat, aber schlechte Ausgaben produziert, ist das fast immer ein Prompt-Problem. Zuerst den Prompt systematisch verbessern.

Schritt 2: Wenn Wissen fehlt — ist es statisch oder dynamisch?

Dynamisch (ändern sich wöchentlich oder monatlich): RAG
Statisch (ändert sich selten): Fine-Tuning oder RAG, je nach Volumen

Schritt 3: Wie groß ist die Wissensbasis?

Unter 100 Dokumente: Alles in den Kontext, kein RAG nötig
100–10.000 Dokumente: RAG sinnvoll
Über 10.000 Dokumente: RAG, eventuell mit hierarchischer Indexierung

Schritt 4: Geht es um Verhalten oder Wissen?

Verhalten (Stil, Ausgabeformat, konsistentes Reasoning): Fine-Tuning
Wissen (Fakten, Dokumenteninhalte, aktuelle Daten): RAG

Schritt 5: Was ist das Budget?

Ansatz	Einrichtung	Laufend (pro Monat, mittleres Volumen)
Prompt Engineering	~0	Token-Kosten des Modells
RAG (selbst gehostet)	500–2.000 € Entwicklung	50–300 € Infrastruktur
RAG (managed, z.B. Pinecone)	200–800 € Entwicklung	70–500 € Dienst + Token
Fine-Tuning (GPT-4o mini)	200–2.000 € Training	Günstigere Inferenz
Fine-Tuning (eigenes Modell)	5.000–50.000 €	Eigene Inferenz-Infrastruktur

Diese Zahlen sind grobe Richtwerte — sie variieren stark nach Volumen, Qualitätsanforderungen und internen Kapazitäten.

Schritt 6: Wie oft ändern sich die Anforderungen?

Das ist eine unterschätzte Dimension. RAG-Pipelines können in Stunden aktualisiert werden — neue Dokumente indexieren, alte entfernen. Fine-Tuning braucht ein neues Training, das je nach Infrastruktur Stunden bis Tage dauert. Wer in einem frühen Produktstadium ist, in dem sich Anforderungen schnell ändern, sollte besonders vorsichtig mit Fine-Tuning sein: Es baut Trägheit ins System ein.

Der häufigste Fehler: Zu früh skalieren

Die meisten Teams, die mit LLM-Produkten anfangen, überspringen Prompt Engineering zu früh. Ein gut strukturierter System-Prompt mit Few-Shot-Beispielen und klaren Constraints löst mehr Probleme als vermutet — und ist in Stunden anpassbar, nicht in Wochen.

RAG und Fine-Tuning sind keine Qualitätsstufen, die man irgendwann “erreicht”. Sie sind spezifische Werkzeuge für spezifische Probleme. Die Entscheidung sollte vom konkreten Engpass getrieben werden, nicht vom Wunsch nach technischer Vollständigkeit.

Wer merkt, dass die Ausgabequalität mit RAG nicht besser wird, sollte drei Dinge prüfen: Erstens, liefert das Retrieval überhaupt die richtigen Chunks — oder sucht das System nach dem Falschen? Zweitens, ist die Wissensbasis selbst vollständig und aktuell? Drittens, wurde die Antwortqualität vorher systematisch gemessen, oder gilt „gefühlt besser” als Maßstab? Ohne Baseline-Messung ist jede Aussage über Verbesserung spekulativ.

Wer tiefer in den Bereich KI-Pipelines einsteigen will — also wie Retrieval, Generierung und Validierung zu robusten Workflows zusammenwachsen — findet in diesem Artikel über KI-Pipelines statt Einzelprompts einen guten Folgeschritt. Und wer konkret wissen will, welche Modelle für welchen Use-Case in Frage kommen, findet im Vergleich von Mistral, OpenAI und Claude praktische Orientierung.

Der einfachste Test: Wenn du die nächste Stunde damit verbringen könntest, den Prompt zu verbessern oder RAG aufzusetzen — verbessere zuerst den Prompt.