Der Kunde sagt: „Wir wollen unsere Firmendokumentation in GPT-5 / Claude / Llama laden, damit es Fragen unserer Mitarbeiter / Kunden / Partner beantwortet." Die Hälfte denkt an Fine-Tuning, die andere Hälfte an RAG und die dritte Hälfte an eine unklare Mischung beider. Dieser Artikel ist ein Entscheidungsrahmen für den ersten Workshop: wann RAG, wann Fine-Tuning, wann eine Kombination und wann Sie ein halbes Jahr warten und nichts einsetzen sollten.
Zwei Welten, zwei Ziele
**RAG (Retrieval-Augmented Generation):** - Daten liegen extern, das Modell sieht sie beim Training nicht - Bei Inference bekommt das Modell die Frage + relevante Datenausschnitte als Kontext - „Gib mir 5 relevanteste Absätze aus der Dokumentation, die Frage X beantworten" → senden wir dem Modell - Das Modell antwortet unter Berücksichtigung der präzisen Dokumentation, kann die Quelle zitieren
**Fine-Tuning:** - Daten werden in die Modellgewichte während des Trainings eingebrannt - Bei Inference „erinnert" sich das Modell an die Daten (oder zumindest ihren statistischen Abdruck) - Das Modell antwortet im Stil / Format / mit der Domainwissens-Ausprägung, die wir ihm beigebracht haben - Die ursprüngliche Datenquelle ist bei Inference NICHT zugänglich, nur ihre parametrische Repräsentation
Diese zwei Welten **lösen nicht dasselbe Problem.** Häufigster Fehler von Kunden: Sie entscheiden sich für Fine-Tuning, wenn ihr reales Problem RAG erfordert.
Test: Welche ist Ihre Aufgabe?
Beantworten Sie diese vier Fragen:
1. Suchen Sie in den Daten nach FAKTEN oder lehren Sie einen STIL?
- **Fakten** („Was ist unser Stundensatz für Kunde X?", „Was sind die Parameter von Maschine Y?") → **RAG**. Der Fakt muss präzise aus der autoritativen Quelle geladen werden. Ein fine-getuntes Modell halluziniert den Fakt (Halluzination ist eine unvorhersehbare Funktion der Trainingsdaten).
- **Stil** („Schreibe in formaler juristischer Sprache", „Antworte im strukturierten Format unserer technischen Berichte") → **Fine-Tuning** kann helfen. RAG mit den richtigen System-Prompts erreicht oft 80–90 % desselben Ergebnisses.
2. Wie oft ändern sich die Daten?
- **Täglich / wöchentlich** → **RAG**. Das Modell bei jeder Datenänderung neu zu trainieren kostet $50–500 und 2–8 Stunden. RAG-Knowledge-Base re-indexieren = 5 Minuten, 0,5 EUR.
- **Monatlich / vierteljährlich** → beides. RAG ist genauso bequem.
- **Einmal alle 2+ Jahre** → Fine-Tuning kann erwogen werden, wenn es ein stabiles Domänenwissen ist (medizinische Protokolle, Rechtskodexe, technische Normen).
3. Muss die Antwort auditierbar sein?
- **Ja (regulierte Branchen)** → **RAG ist nahezu Pflicht**. Dem Kunden muss nachgewiesen werden können: „Das Modell sagte X, weil es Y in Dokument Z gesehen hat." Ein fine-getuntes Modell „sagte X" ohne die Möglichkeit zu beweisen, woher es das weiß.
- **Nein** → Fine-Tuning kommt ins Spiel.
4. Welches Datenvolumen haben Sie?
- **< 100 k Tokens** → weder RAG noch Fine-Tuning. Geben Sie sie direkt in den System-Prompt eines Modells mit 200k Context Window (Claude Sonnet 4.6, Gemini 2.5 Pro). Am einfachsten, am schnellsten.
- **100 k – 10 M Tokens** → **RAG** ist optimal. Ein Vektor-Index über 1–10 M Tokens ist 200 MB Speicher, Sub-100-ms-Latenz.
- **10 M – 1 B Tokens** → RAG funktioniert, benötigt aber sophistiziertere Architektur (Multi-Stage Retrieval, Hybrid Search, Reranking). Fine-Tuning als Ergänzung, nicht als Ersatz.
- **> 1 B Tokens** → Fine-Tuning als Pre-Training-Step + RAG obendrauf.
Wann Fine-Tuning eindeutig gewinnt
1. Domänenspezifische Sprache / Terminologie
Slowakische Rechtsprechung, medizinisches Latein, technische Abkürzungen in Ihrer Firma („PVRZ" = Name eines Produktionsprotokolls, den auch Google nicht errät). Das Basismodell kennt es nicht. Fine-Tuning bringt es ihm bei.
Beispiel: Mistral 7B fine-getunt auf 5.000 Beispielen slowakischer juristischer Dokumentation → antwortet in der richtigen Rechtssprache, kennt Terminologie wie „odporca" (Beklagter), „navrhovateľ" (Antragsteller), „dohodárenstvo", „zmiernenie sankcie" im richtigen Kontext. Das Basismodell schreibt im Stil von Wikipedia.
Kosten: SFT auf 5.000 Beispielen, RTX 4090, ~6 Stunden, ~10 EUR Strom. Real in der Praxis.
2. Strukturierte Ausgaben mit striktem Format
„Antworte immer in JSON mit diesem Schema." System-Prompt erreicht 95 % Genauigkeit. Fine-Tuning erreicht 99,5+ % Genauigkeit. In Produktionssystemen ist der Unterschied 95 % vs. 99,5 % lebenswichtig — bei 95 % haben Sie 5 % Parse-Errors, die durch die ganze Downstream-Pipeline lecken.
3. Geschwindigkeit (Latenz + Cost) im High-Throughput
RAG = Embedding (50 ms) + Retrieval (100 ms) + LLM mit erweitertem Prompt (8.000 Tokens × 100 RPS = teuer). Fine-getuntes Modell = LLM mit kurzem Prompt (500 Tokens × 100 RPS).
Bei >100 RPS Workloads ist Fine-Tuning 5–10× günstiger. Bei <10 RPS spielt es keine Rolle.
4. Offline / On-Device Deployment
Ein mobiler Client kann keine RAG-Knowledge-Base aufrufen. Ein fine-getuntes 1B–4B-Modell, das auf dem Gerät läuft (CoreML, ExecuTorch, llama.cpp) — hat das gesamte Domänenwissen eingebrannt, benötigt kein Internet.
Wann RAG eindeutig gewinnt
1. Daten ändern sich schnell
Customer-Support-Knowledge-Base, FAQ, Produktdokumentation, interne Wikis. Hinzufügen eines neuen Dokuments = Re-Index (Sekunden). Fine-Tuning würde tägliches Neutraining bedeuten.
2. Zitate sind Pflicht
Compliance, Recht, Medizin, Finanzberatung. Der Kunde muss sehen: „Das Modell denkt X, weil Artikel 12 Absatz 3 von Gesetz Y das so sagt." Fine-Tuning produziert keine Zitate — es produziert eine paraphrasierte Antwort ohne Audit-Trail.
3. Personalisierung pro User
User A sieht seine Daten, User B sieht seine. Das Modell ist gleich, aber die Knowledge-Base wird pro User gefiltert. Fine-getuntes Modell kann nicht ändern, was es weiß, je nach User.
4. Multi-Language / Multi-Domain
Der Kunde hat Dokumentation in SK, EN, DE und will in der Sprache der Frage antworten. RAG: ein Modell, 3 Knowledge-Bases (oder 1 Base mit Sprach-Metadaten). Fine-Tuning: 3 Modelle oder komplexeres Multi-Task-Training.
Hybrider Ansatz — häufigste Produktions-Realität
In realen Deployments 2026 wird typischerweise kombiniert:
1. **Basismodell:** Claude Sonnet 4.6 oder Llama 3.3 70B (Open-Weight) 2. **Light Fine-Tuning (LoRA):** auf 1–5 k Beispielen domänenspezifischer Q&A, lehrt das Modell „wie zu antworten" im Stil und Format Ihrer Firma 3. **RAG:** über Live-Daten (Dokumente, Datenbank, Ticket-System) 4. **System-Prompt:** fasst Kontext, Identity, Guardrails zusammen 5. **Reranker:** BGE-Reranker, Cohere Rerank — sortiert nach Retrieval die Ausschnitte neu, damit die relevantesten oben stehen
Dieser Stack löst: das Modell kennt „wie zu antworten" (Fine-Tune), kennt „aktuelle Daten" (RAG), kennt „wer wir sind und welche Regeln gelten" (System-Prompt). Plus Quellenangaben, plus Auditierbarkeit.
Konkretes Tooling 2026
RAG-Stack — unsere Standardwahl
- **Vektor-DB:** Qdrant (self-hosted) oder Weaviate. PostgreSQL + pgvector für kleine Use-Cases (< 1 M Vektoren).
- **Embedding-Modell:** BGE-M3 (open, SK/EN/DE multilingual) oder OpenAI text-embedding-3-large für Cloud-Only-Setups.
- **Reranker:** BGE-Reranker-Large oder Cohere Rerank 3.
- **Orchestration:** LangChain oder LlamaIndex für Quick PoC, eigener Python-Code für Produktion (LangChain Layer of Abstraction wird bei größeren Systemen zur Tax).
- **Document Parsing:** Docling (IBM, open) oder Unstructured.io für PDF/DOCX/HTML.
- **Chunking-Strategie:** semantic chunking (250–500 Tokens pro Chunk), 10–20 % Overlap, metadata-rich.
Fine-Tuning-Stack — wann wir ihn verwenden
- **Framework:** Unsloth (2–5× schneller als vanilla TRL), HuggingFace TRL für Standard-Workflows.
- **Method:** LoRA (Rank 16–32) oder QLoRA für VRAM-constrained Setups. Full Fine-Tuning nur bei >100 k Beispielen.
- **Base Model:** Llama 3.3 70B, Mistral Small 3 (22B), Qwen 2.5 32B je nach Lizenz + Sprache.
- **Eval:** Custom Eval Set mit 200+ Fragen + Standard-Benchmarks (MMLU, HellaSwag) zur Regression-Detection.
- **Serving:** vLLM oder SGLang für Throughput, llama.cpp für lokal / On-Device.
Kosten — reale Zahlen 2026
RAG-Deployment (typische B2B-Knowledge-Base)
- 50 k Dokumente, 10 M Tokens, 500 RPS Peak
- Vektor-DB: Qdrant auf 32-GB-VPS, $80/Monat
- Embedding (BGE-M3 self-hosted): RTX-4090-Server, $200/Monat Amortisation
- LLM (Claude Sonnet 4.6): ~$3/M Input-Tokens, ~$15/M Output-Tokens. Bei 500 RPS mit durchschnittlich 8 k Input + 500 Output → **$4.500–6.000 monatlich**
- Total: **~$5.500–6.500/Monat** plus einmalige Initialisierung $5–15 k
Oder voll lokaler Stack mit Llama 3.3 70B auf 2× H100: Hardware $80–120 k einmalig, Betrieb $300/Monat Strom + Wartung. Amortisation gegenüber Cloud-Only: 12–18 Monate.
Fine-Tuning-Deployment
- Einmaliges Training (LoRA, 5.000 Beispiele, Llama 3.3 70B): $30–80 Cloud-GPU oder $5 Strom auf RTX 4090, wenn Sie eigene haben
- Eval + Iteration Cycle: 3–6 Iterations × $50 = $150–300
- Hosting des fine-getunten Modells: gleich wie Basismodell (LoRA-Aufschlag ist null bei merged Weights)
- Wartung: alle 3–6 Monate retrainieren, wenn sich die Domain ändert
Reale Kosten Fine-Tuning bei produktivem System: **< $1.000 jährlich**, wenn Sie ein Team haben, das es warten kann. Hidden Cost ist „die Person, die Eval machen und Ergebnisse interpretieren kann" — nicht die GPU.
Wann nichts davon einsetzen
- Daten sind klein (< 50 Dokumente) → verwenden Sie Cloud-LLM (Claude Project, GPT Custom GPT, Gemini Workspace) direkt, keine Custom-Infra.
- Team hat keine MLOps-Kapazität und Sie sind nicht bereit, 6+ Monate in einen Data-Engineer zu investieren.
- Domain ändert sich rapide (Start-up-MVP, Produktexperimentierung) → warten Sie, bis sich die Daten stabilisieren.
- Kundendaten sind hochreguliert und Sie haben keine fertige DPIA (DSGVO-Impact-Assessment) — lösen Sie zuerst die Compliance, dann deployen Sie.
---
*Wir machen RAG und Fine-Tuning als Teil von KI-Integrationen. Wenn Sie über den Einsatz eines LLM über einer Firmenbasis nachdenken, geht die erste Beratung (90 Minuten) diese vier Entscheidungsfragen an Ihrem realen Use-Case durch und gibt Ihnen eine orientierende Architektur und ein Budget, bevor Sie sich auf den einen oder anderen Weg festlegen.*