Skip to main content
AI Tool Radar
Deep Dives

RAG vs Fine-Tuning vs Prompting: Welches brauchen Sie wirklich?

Drei Ansaetze, damit sich ein KI-Modell so verhaelt, wie Sie wollen. Sie loesen verschiedene Probleme, aber die meisten Guides erklaeren sie, als waeren sie Alternativen. Hier, wann jedes die richtige Wahl ist, und wann die falsche.

7 min read2026-03-22Von Roland Hentschel
ragfine-tuningprompt engineeringllm anpassung

Die Frage, die immer wieder kommt#

Alle paar Wochen fragt mich jemand, der ein KI-gestuetztes Produkt baut, dieselbe Frage in anderen Worten: "Soll ich RAG nutzen, ein Modell fine-tunen oder einfach bessere Prompts schreiben?"

Die Frage ist formuliert, als waeren das drei Optionen auf derselben Speisekarte. Sind sie nicht. Sie loesen verschiedene Probleme, haben verschiedene Kosten-Profile, und gehoeren meist zusammen statt als Alternativen.

Die Verwirrung kommt meist aus Blog-Posts, die sie direkt vergleichen, als waeren sie Konkurrenten. Sind sie nicht. Nach einem Jahr Produktions-KI-Features fuer eine Handvoll Kunden bauen, hier das tatsaechliche Entscheidungs-Framework, das ich nutze.

Was jedes tatsaechlich tut#

Bevor Sie waehlen koennen, brauchen Sie ein klares Bild, was jede Technik hinzufuegt.

Prompting ist, wie Sie mit dem Modell sprechen. Die Gewichte des Modells aendern sich nicht. Was sich aendert, ist das Context Window: die Anweisungen, Beispiele und Referenzmaterialien, die Sie bei jeder Frage mitgeben. Ein besserer Prompt bekommt eine bessere Antwort vom selben Modell.

RAG (Retrieval-Augmented Generation) ist eine Methode, dynamisch relevante Informationen zur Query-Zeit in den Prompt zu injizieren. Sie speichern Ihr Wissen in durchsuchbarer Form (eine Vektor-Datenbank, ein Keyword-Index oder beides), und zur Laufzeit holen Sie die fuer die Nutzerfrage relevanten Teile und fuegen sie dem Prompt hinzu. Das Modell ist unveraendert. Der Prompt wird on-the-fly aus Ihrer Wissensbasis gebaut.

Fine-Tuning aendert das Modell selbst. Sie nehmen ein Basismodell und trainieren es weiter auf Beispielen, die dem Verhalten entsprechen, das Sie wollen. Das resultierende Modell hat andere Gewichte. Es wird im Stil Ihrer Trainingsdaten antworten, auch ohne dass Sie die Anweisungen in jedem Prompt wiederholen.

Die entscheidende Unterscheidung, die die meisten uebersehen#

Prompting und RAG fuegen Informationen hinzu oder modifizieren sie, auf die das Modell Zugriff hat. Fine-Tuning aendert, wie sich das Modell standardmaessig verhaelt.

Diese Unterscheidung treibt fast jede Entscheidung. Wenn Ihr Problem ist "das Modell kennt meine spezifischen Fakten nicht", brauchen Sie RAG oder gutes Prompting, kein Fine-Tuning. Wenn Ihr Problem ist "das Modell antwortet nicht zuverlaessig in meinem benoetigten Format oder Stil", hilft Fine-Tuning, aber ein guter Prompt mit Beispielen auch.

Wenn Menschen sagen "fine-tune das Modell auf unsere Dokumentation", meinen sie meist "Ich will, dass das Modell unsere Dokumentation kennt". Fine-Tuning ist die falsche Antwort dafuer. Das Modell wird spezifische Fakten aus den Trainingsdaten nicht zuverlaessig abrufen; es wird sie auf Weisen generalisieren, die Sie nicht vorhersagen koennen. RAG ist die richtige Antwort.

Wann welches waehlen#

Starten Sie mit Prompting#

Wenn Sie fragen, ob Sie RAG oder Fine-Tuning nutzen sollen, ist die ehrliche erste Antwort meist: "Haben Sie tatsaechlich zuerst einen gut gebauten Prompt probiert?"

Die meisten haben nicht. Sie schrieben einen Prompt, bekamen okayne Ergebnisse und sprangen zum Schluss, dass sie Infrastruktur brauchen. Ein sorgfaeltiger Prompt mit:

  • Klarer Rolle
  • 2-3 Beispielen fuer idealen Output
  • Expliziten Constraints
  • Einem spezifischen Output-Format

...schlaegt viele Fruehstadium-RAG-Systeme und die meisten Amateur-Fine-Tuning-Versuche. Es kostet auch nichts zu iterieren, was ein enormer Vorteil ist.

Fuer eine tiefere Begleitung dessen, wie ein gut gebauter Prompt aussieht, geht unser Claude-Guide in Details. Aber die Regel lautet: Beherrschen Sie Prompting, bevor Sie etwas darauf bauen.

RAG hinzufuegen, wenn das Modell spezifisches Wissen braucht, das es nicht halten kann#

Nutzen Sie RAG, wenn:

  • Sie einen Wissensstamm haben, der sich ueber die Zeit aendert (Kundensupport-Docs, Produktkataloge, Richtlinien-Dokumente)
  • Das Modell spezifische Quellen zitieren muss
  • Sie nicht alle relevanten Informationen ins Context Window bekommen
  • Antworten in verifizierbaren Fakten grundend sein muessen statt generiert

RAG ist das richtige Tool fuer jedes "Chat mit deinen Dokumenten"-Produkt. Es ist auch das richtige Tool fuer Kundensupport-Bots, Produkt-Suche, interne Wissens-Tools und alles, wo die Antwort von Informationen abhaengt, die der Nutzer oder das Unternehmen besitzt.

Die Setup-Kosten sind real. Sie brauchen eine Dokument-Ingestion-Pipeline, ein Embedding-Modell, einen Vektor-Store (oder eine hybride Keyword+Vektor-Suche) und Logik zum Bauen von Prompts aus abgerufenen Chunks. Die Wartungskosten sind auch real: Ihre Retrieval-Qualitaet driftet, wenn sich die Quelldaten aendern, und Sie muessen ueberwachen, was tatsaechlich abgerufen wird vs was sollte.

Aber RAG vermeidet die groesste Falle von Fine-Tuning: Das Modell kann Ihnen nicht sagen, dass sein Wissen veraltet ist. Ein RAG-System mit frischen Dokumenten hat immer aktuelle Informationen. Ein fine-getuntes Modell ist ein Snapshot Ihrer Daten zum Trainingszeitpunkt.

Fine-Tuning hinzufuegen, wenn das Verhalten sich aendern muss, nicht das Wissen#

Nutzen Sie Fine-Tuning, wenn:

  • Sie das Modell in einem sehr spezifischen Format, Ton oder Stil antworten lassen muessen, der schwer im Prompt zu beschreiben ist
  • Die Aufgabe wiederholt genug ist, dass Verhalten ins Modell einzubacken billiger ist, als jedes Mal Beispiele zu senden
  • Sie niedrigere Latenz und Kosten pro Query brauchen (fine-getunte Modelle erlauben oft kuerzere Prompts)
  • Sie dasselbe Modell in hohem Volumen fuer eine schmale Aufgabe nutzen

Klassische Fine-Tuning-Anwendungsfaelle: Klassifikations-Modelle, strukturierte Output-Extraktoren, Code-Transformations-Tools und Domain-spezifische Assistenten, wo der Ton zaehlt (Recht, Medizin, Kundenservice).

Wo Fine-Tuning schlecht ist: dem Modell neue Fakten beibringen. Wenn Sie ein Modell auf 1.000 Kundensupport-Tickets fine-tunen, in der Hoffnung, dass es Ihr Produkt kennt, bekommen Sie ein Modell, das klingt, als kennte es Ihr Produkt, aber Details halluziniert. RAG loest das. Fine-Tuning macht es schlechter.

Wann stapeln#

Die besten Produktions-KI-Systeme nutzen meist alle drei. Ein typisches Muster:

  1. Ein fine-getuntes Modell, das weiss, wie im richtigen Format und Stil zu antworten ist
  2. RAG, um die fuer diese Query relevanten spezifischen Fakten zu injizieren
  3. Ein Prompt, der beide kombiniert, zusammen mit der tatsaechlichen Nutzerfrage

Das Fine-Tuning handhabt Stil. RAG handhabt Wissen. Der Prompt handhabt Aufgaben-Rahmen. Jedes tut, was es gut macht, nichts muss alles tun.

Die Kosten-Realitaet#

Ein paar Zahlen zur Orientierung der Entscheidung.

Prompting kostet null zu iterieren. Jedes Token, das Sie in Ihrem Prompt sparen, sind Einsparungen fuer immer, und Sie koennen Prompts an einem Nachmittag A/B-testen.

RAG kostet vielleicht 500-5.000 $ an Engineering-Zeit, um eine erste Version aufzusetzen, plus laufende Infrastruktur (Vektor-DB, Embedding-Kosten, Retrieval-Tuning). Die marginalen Kosten pro Query sind niedrig.

Fine-Tuning kostet einen Daten-Kurations-Schritt (oft der teuerste Teil, weil Sie gute Beispiele brauchen), plus den Trainings-Run selbst. Fuer ein OpenAI-Fine-Tune auf einem mittleren Modell erwarten Sie 500-2.000 $ fuer einen anstaendig grossen Datensatz. Selbst-gehostetes Fine-Tuning auf Open-Modellen ist pro Run guenstiger, hat aber viel hoehere Setup-Kosten.

Das Verhaeltnis ist grob: Prompting ist kostenlos, RAG ist eine vierstellige Investition, Fine-Tuning ist eine fuenfstellige Investition mit laufender Wartung. Budgetieren Sie entsprechend, und springen Sie nicht zur teuren Option ohne Beweis, dass die guenstige versagt hat.

Der Fehler, den ich am haeufigsten sehe#

Der haeufigste Fehler ist Fine-Tuning als erster Zug. Ein Startup hat eine Produktidee, entscheidet, dass KI dabei ist, hoert, dass Fine-Tuning "der richtige Weg" ist, um ein Modell anzupassen, und verbringt Wochen und Tausende Dollar damit, ein fine-getuntes Modell zu produzieren, bevor irgendjemand ernsthaft einen gut gebauten Prompt probiert hat.

Das fine-getunte Modell ist meist schlechter als ein sorgfaeltiger Prompt. Es ist definitiv schlechter als ein sorgfaeltiger Prompt plus RAG. Und es sperrt Verhalten ein, das schwer zu iterieren ist, weil jede Aenderung jetzt einen neuen Trainings-Run erfordert.

Die Disziplin, die Teams, die gute KI-Produkte shippen, von denen trennt, die kaempfen, ist die Bereitschaft, Prompting auszuschoepfen, bevor man Infrastruktur hinzufuegt, und RAG auszuschoepfen, bevor man fine-tunt. Das schickere Tool ist nicht immer das bessere Tool.

Der Entscheidungs-Baum#

Meine vereinfachte Version:

  1. Koennen Sie akzeptable Ergebnisse mit einem gut gebauten Prompt inklusive Beispielen bekommen? Shippen Sie es.
  2. Ist der Failure-Mode "das Modell kennt meine spezifischen Fakten nicht"? RAG hinzufuegen.
  3. Ist der Failure-Mode "das Modell kann das richtige Format oder den Stil nicht konsistent produzieren"? Versuchen Sie zuerst Prompt-Verbesserungen mit Few-Shot-Beispielen. Wenn es immer noch im Skale scheitert, fine-tunen.
  4. Beide Failure-Modes zusammen? Beides tun.

Starten Sie nie bei Schritt 3.

Fuer praktische Tool-Vergleiche bei den zugrundeliegenden Modellen, die Sie nutzen koennten, deckt unser ChatGPT vs Claude-Vergleich ab, welche Modelle fuer welche Arten von Anpassung besser geeignet sind. Aber Modell-Wahl ist eine viel kleinere Entscheidung als die Architektur richtig zu bekommen.

Prompting, RAG und Fine-Tuning sind nicht drei Geschmacksrichtungen desselben Dings. Es sind drei verschiedene Arten von Operation. Die meisten Projekte brauchen eines davon. Einige brauchen zwei. Sehr wenige brauchen alle drei. Starten Sie mit dem guenstigsten, fuegen Sie mehr hinzu, nur wenn noetig bewiesen.


Roland Hentschel

Roland Hentschel

AI & Web Technology Expert

Web developer and AI enthusiast helping businesses navigate the rapidly evolving landscape of AI tools. Testing and comparing tools so you don't have to.

Weitere Beiträge aus dem Blog