RAG, Fine-Tuning oder Prompt Engineering: Welche Methode passt wann?

Kaum eine Frage taucht in Beratungsgesprächen so oft auf: „Brauchen wir RAG oder Fine-Tuning?” Die Antwort ist selten eines von beidem allein. Wer einen LLM produktiv auf einen Use Case bringen will, hat 2026 fünf Hauptmethoden zur Wahl — mit sehr unterschiedlichen Kosten, Aufwänden und Effekten. Dieser Beitrag macht die Trade-offs sichtbar und liefert eine Entscheidungsmatrix für die Praxis.

1. Warum die Frage sich immer wieder stellt

Ein Generic-LLM kann viel, aber selten genau das, was ein Unternehmen braucht: die richtige Tonalität, das eigene Vokabular, die aktuellen Produkte, die internen Prozessregeln, die domänenspezifischen Klassifikationen. Aus dieser Lücke entsteht der Bedarf nach Anpassung — und damit die Frage nach der richtigen Methode.

Falsche Methodenwahl ist einer der häufigsten Gründe für gescheiterte KI-Projekte. Wer Fine-Tuning für ein Wissensproblem einsetzt, trainiert ein Modell auf einen Datenstand, der drei Wochen später überholt ist. Wer RAG für ein Verhaltensproblem einsetzt, wundert sich, warum das Modell weiter wie ein generischer Assistent klingt. Mehr dazu in Warum KI-Projekte scheitern.

2. Die fünf Methoden im Überblick

Prompt Engineering. Verhalten des Modells über sorgfältig formulierte Eingaben steuern — System-Prompts, Few-Shot-Beispiele, strukturierte Output-Schemas. Kein Training, keine zusätzliche Hardware. Wirksam, aber begrenzt: ein Prompt kann ein Modell nicht etwas Neues lehren, nur seine vorhandenen Fähigkeiten besser abrufen.

RAG (Retrieval-Augmented Generation). Externe Datenquellen werden zur Anfragezeit durchsucht; die relevanten Treffer fließen in den Prompt ein. Das Modell antwortet auf Basis dieses zusätzlichen Kontexts. Ideal für faktisches Wissen, das sich häufig ändert. Siehe Embeddings und Vector Databases.

LoRA / Parameter-effizientes Fine-Tuning. Statt alle Modellgewichte zu ändern, werden nur kleine Adapter-Matrizen trainiert. Günstig, schnell, auf Consumer-Hardware machbar, ohne das Basismodell zu beschädigen. Tiefer in LoRA erklärt.

Full Fine-Tuning. Alle Modellgewichte werden weitertrainiert. Maximaler Effekt, maximale Kosten, höchstes Risiko (Catastrophic Forgetting). Nur bei tiefgreifenden Verhaltensänderungen sinnvoll.

Model Distillation. Ein kleineres Modell wird so trainiert, dass es Antworten eines größeren imitiert. Reduziert Latenz und Kosten in Produktion, oft mit nur leichten Qualitätseinbußen. Vertiefung in Model Distillation.

3. Sechs Entscheidungskriterien

Die richtige Methode hängt von sechs Faktoren ab:

1. Daten-Volatilität. Ändert sich der Inhalt täglich, wöchentlich oder kaum? Volatile Daten ⇒ RAG. Stabile Daten ⇒ Fine-Tuning.
2. Art der Anpassung. Geht es um Wissen (Fakten, Dokumente) oder Verhalten (Stil, Format, Domänensprache)? Wissen ⇒ RAG. Verhalten ⇒ Fine-Tuning.
3. Datenmenge. Unter 100 Beispiele ⇒ Prompt Engineering oder RAG. 500–5.000 Beispiele ⇒ LoRA. 50.000+ Beispiele ⇒ Full Fine-Tuning erwägen.
4. Budget und Hardware. Keine GPUs ⇒ Prompt Engineering oder API-RAG. Eine GPU ⇒ LoRA. Multi-GPU-Cluster ⇒ Full Fine-Tuning oder Distillation.
5. Compliance und Datensouveränität. Sensible Daten dürfen häufig nicht in API-Aufrufe fließen. On-Premise mit LoRA oder Distillation in deutscher Infrastruktur ⇒ siehe Sichere KI-Integration.
6. Inference-Kosten und Latenz. Distillation und kleinere LoRA-angepasste Modelle sind in Produktion günstiger als ein großes Generic-Modell mit aufwändigen Prompts.

4. Entscheidungsmatrix

Eine vereinfachte Heuristik:

• „Antworte im Stil unseres Unternehmens, basierend auf unserem Handbuch”: Fine-Tuning (Stil) + RAG (Handbuch).
• „Antworte auf Fragen zu unserer Produktdokumentation, die wir wöchentlich aktualisieren”: Reines RAG.
• „Extrahiere strukturierte Daten aus standardisierten Verträgen”: Prompt Engineering mit JSON-Schema, ggf. LoRA, wenn die Verträge sehr domänenspezifisch sind.
• „Generiere Code in unserem internen Framework”: LoRA auf einem Code-Modell, weil das Framework dem Modell unbekannt ist.
• „Klassifiziere Support-Tickets in 30 Kategorien mit hoher Genauigkeit”: LoRA-Fine-Tuning auf historischen Tickets.
• „Wir wollen unser teures Cloud-Modell günstiger in Produktion bekommen”: Distillation.

5. Wann Methoden zu kombinieren sind

In der Realität gewinnt fast immer eine Kombination:

• RAG + Prompt Engineering: Standard für die meisten Wissensanwendungen. Strukturierte System-Prompts steuern das Verhalten, RAG liefert den Kontext.
• LoRA + RAG: Domänensprache plus aktuelles Wissen. Beispiel: ein medizinisch fine-getunter LLM mit RAG auf aktuelle Leitlinien.
• Distillation + LoRA: Großes Modell für Eval und Datengenerierung, kleines Modell für Produktion — mit LoRA-Adapter für domänenspezifische Feinheiten.
• Prompt Engineering + Strukturierte Outputs: Pydantic- oder JSON-Schemas zwingen das Modell in eine prüfbare Form. Siehe auch Tool Calling, Function Calling und MCP.

6. Häufige Fehlentscheidungen

• Fine-Tuning eines Wissensproblems. Ein Modell auf einen Datensatz zu trainieren, der sich permanent ändert, ist eine Sackgasse — der erste Datenwechsel macht das Training wertlos.
• RAG ohne saubere Daten. RAG bringt nichts, wenn die Quellen widersprüchlich, veraltet oder unstrukturiert sind. Datenarbeit ist die eigentliche Arbeit.
• Full Fine-Tuning für Stil. Mit LoRA erreicht man fast denselben Effekt zu einem Bruchteil der Kosten.
• Prompt Engineering als Dauerlösung. Prompts werden mit der Zeit lang, fragil und schwer zu warten. Sobald reproduzierbare Qualität erforderlich ist, ist LoRA oder RAG die robustere Wahl.
• Distillation ohne Eval-Suite. Ohne harte Evaluation lässt sich nicht messen, ob das kleinere Modell wirklich gleichwertig ist. Die Annahme „kleiner geht auch” ist gefährlich.

7. Empfohlenes Vorgehen

Aus unserer Beratungspraxis bewährt:

1. Use Case sauber definieren. Eine Aufgabe, eine messbare Metrik, ein Akzeptanzkriterium.
2. Mit der einfachsten Methode starten. Prompt Engineering plus ein generisches Modell. Wenn das reicht — Glück gehabt.
3. RAG ergänzen, wenn Wissensbedarf entsteht. Vector Database, Chunking, Hybrid Search aufsetzen.
4. LoRA, wenn Verhalten konsistent angepasst werden muss. Saubere Datensätze, reproduzierbares Training, Eval.
5. Distillation nur am Ende. Erst wenn die Methodenwahl klar ist, lohnt sich die Reduktion auf ein kleineres Produktionsmodell.
6. Eval von Anfang an. Ohne reproduzierbare Evaluation ist jede Methodenwahl Bauchgefühl. Mehr in Guardrails, Evals und Prompt Injection.

Die ehrliche Botschaft: Es gibt keine pauschal beste Methode. Es gibt nur die beste Methode für eine konkrete Aufgabe — und die ergibt sich erst aus einer sauberen Analyse von Daten, Anforderungen und Constraints. Wer diese Analyse überspringt und sofort mit Fine-Tuning oder RAG einsteigt, weil es im LinkedIn-Post stand, baut auf Sand. Wer sie macht, hat innerhalb weniger Wochen eine produktive AI-Lösung, die wirklich zum eigenen Geschäft passt.