Fast jedes Erstgespräch zu Unternehmens-KI startet mit derselben Frage: “Sollen wir das Modell auf unsere Daten fine-tunen oder lieber RAG machen?” Die ehrliche Antwort ist meistens: weder, sondern erst Prompting. Aber wenn man darüber hinaus muss, lohnt sich ein klarer Blick auf die Trade-Offs.
Was die beiden eigentlich machen
RAG (Retrieval-Augmented Generation) stellt zur Frage des Nutzers passende Dokumente bereit, die das Modell beim Antworten berücksichtigt:
User-Frage ─────► Embedding ─► Vector-DB ─► Top-K Dokumente
│
▼
┌──────────────┐
Kontext + Frage ─────────────► │ LLM │ ─► Antwort
└──────────────┘Fine-Tuning verändert die Modell-Gewichte selbst, sodass die “Persönlichkeit”, der Stil oder das Domänenwissen direkt im Modell stecken — keine externe Datenbank nötig.
Wann RAG die richtige Wahl ist
RAG schlägt Fine-Tuning fast immer, wenn mindestens eine der folgenden Bedingungen zutrifft:
- Daten ändern sich häufig — Produktkatalog, Support-Wissensbasis, regulatorische Texte
- Quellenangabe ist Pflicht — der Nutzer muss sehen, woher die Information stammt
- Access Control — verschiedene Nutzer dürfen verschiedene Dokumente sehen
- Datenvolumen ist groß — Millionen Dokumente, deren Fine-Tuning niemand bezahlen will
- Budget für ersten Wurf ist klein — RAG-Prototyp läuft in einer Woche
In der Praxis macht RAG bei uns ~80% der produktiven KI-Anwendungen aus. Der typische Stack:
# Vereinfachter RAG-Pfad
def answer(question: str) -> str:
query_embedding = embed(question)
docs = vector_db.search(query_embedding, k=5, filter=user_acl)
context = format_context(docs)
return llm.generate(
system="Antworte basierend auf dem Kontext. Zitiere Quellen.",
user=f"{context}\n\nFrage: {question}",
)Wann Fine-Tuning sich lohnt
Fine-Tuning rechnet sich, wenn:
- Stil oder Format strikt sein müssen — ein juristischer Schriftverkehr, ein konsistenter Marken-Ton, eine zwingend einzuhaltende Output-Struktur
- Latenz kritisch ist — kein Retrieval-Overhead, kürzerer Kontext, schnellere Antwort
- Token-Kosten dominieren — wenn die gleichen 4.000 Token Kontext pro Anfrage zu groß werden, ist Fine-Tuning auf Dauer billiger
- Eine kleine, stabile Domäne vorliegt — z. B. ein internes API-Vokabular, das sich pro Jahr kaum ändert
Wichtig: “Wissen reinfine-tunen” ist meistens die falsche Erwartung. Fine-Tuning ist gut für Verhalten (Stil, Format, Domain-Sprache), nicht für die Antwort auf “Was steht in Document XYZ?”.
Eine Entscheidungstabelle
| Kriterium | RAG | Fine-Tuning |
|---|---|---|
| Daten ändern sich täglich | ✓ | ✗ |
| Zitate / Quellenangabe nötig | ✓ | ✗ |
| Latenz unter 500 ms | △ | ✓ |
| Konsistenter Output-Stil | △ | ✓ |
| Setup in < 2 Wochen | ✓ | △ |
| Laufende Pflege | hoch | niedrig |
| Initialer Aufwand | niedrig | hoch |
| Skaliert mit Datenvolumen | ✓ | ✗ |
Hybrid ist oft die Antwort
In den meisten unserer Kundenprojekte landen wir am Ende bei einer Hybrid-Architektur:
- Fine-Tuning für Output-Format, Sprach-Register, Markenkonventionen
- RAG für aktuelles, autorisiertes Domänen-Wissen
- Prompting als oberste Steuerungs-Schicht für Edge-Cases und Guardrails
Das klingt aufwendig, ist es aber in der Umsetzung kaum. Ein einmal fine-getuntes Modell ist ein paar hundert Euro und 48 Stunden Trainingszeit — die laufende RAG-Pipeline darüber ist der eigentliche Aufwand.
Was viele unterschätzen
Drei Dinge, die wir bei jedem KI-Projekt sehen:
- Datenqualität schlägt Methodenwahl. Ein RAG mit gut kuratierten 500 Dokumenten produziert besseren Output als ein Fine-Tuning auf 10.000 mittelmäßigen.
- Evals sind nicht optional. Ohne reproduzierbare Test-Suite weiß man nach 3 Monaten nicht mehr, ob das System besser oder schlechter geworden ist.
- Token-Budget ist ein Architektur-Constraint. Wer es nicht früh modelliert, baut sich Bottlenecks ein, die später teuer zu beheben sind.
Fazit
Die Frage “RAG oder Fine-Tuning?” ist meistens die falsche Frage. Die richtige ist: “Welche unserer Probleme lösen wir mit RAG, welche mit Fine-Tuning, und welche mit klugem Prompting?” Wer das sauber trennt, baut KI-Systeme, die nicht in der ersten Update-Welle nach 6 Monaten zusammenbrechen — sondern mitwachsen.