RAG vs. Fine-Tuning vs. Long-Context — was wann?

Die ehrliche Kurzantwort

Drei Wege, einem LLM Unternehmenswissen beizubringen:

• RAG (Retrieval-Augmented Generation): Wissen in Vector-DB, pro Anfrage die relevanten Stücke heraussuchen und ins Prompt-Window legen
• Fine-Tuning: Modell-Gewichte mit eigenen Daten weiter trainieren
• Long-Context: gesamtes Wissen direkt ins Kontextfenster legen (Claude Sonnet 4.6 hat 1 Mio Tokens, Gemini 2.5 hat 2 Mio, Llama 4 Scout 10 Mio Kontext)

Wann was greift:

Anforderung	Empfehlung
Aktuelle Daten (Tickets, Verträge, Wikis)	RAG
Quellenverweise und Nachvollziehbarkeit	RAG
Spezielle Schreibstil/Ton/Format	Fine-Tuning
Domain-spezifisches Vokabular (Medizin, Recht)	Fine-Tuning + RAG
Kleine, statische Wissensbasis (<200 Seiten)	Long-Context
Hohes Frage-Volumen auf großem Korpus	RAG
Compliance-Anforderungen an Datentrennung	RAG

RAG — der Standardweg 2026

Wie es funktioniert. Dokumente werden in Chunks zerlegt (300–1.000 Tokens pro Chunk), mit einem Embedding-Modell (text-embedding-3-large, bge-m3, nomic-embed-text) in Vektoren übersetzt, in einer Vector-Datenbank (Qdrant, Weaviate, pgvector, Pinecone) abgelegt. Bei einer Anfrage werden die k=5 bis k=20 ähnlichsten Chunks geholt und ins LLM-Prompt gelegt. Das LLM antwortet auf Basis dieses Kontextes.

Stärken.

• Aktualisierbar ohne Modell-Retraining (neue Dokumente einfach indexieren)
• Quellen-Verweise möglich (welche Chunks haben zur Antwort beigetragen)
• Daten-Trennung pro Tenant/Abteilung über getrennte Vector-Indizes
• Kostengünstig (Embedding ist ein Bruchteil von Generation)

Schwächen.

• Retrieval-Qualität ist der zentrale Flaschenhals — schlechte Embeddings oder schlechte Chunking-Strategie → schlechte Antworten
• “Lost in the middle”-Problem bei vielen retrieveden Chunks
• Komplexer als ein reiner LLM-Call (mehrere Komponenten, Monitoring nötig)

Typische Mittelstands-Anwendungsfälle. Customer-Support mit Produktdatenbank, internes Wiki-Q&A, Vertragsklauseln-Suche, Wissens-Management für neue Mitarbeitende.

Tooling 2026.

• Vector-DB: Qdrant (open source, performant), pgvector (wenn Postgres schon im Stack), Weaviate (für gemischte Volltext+Vektor-Queries)
• Embedding: bge-m3 oder nomic-embed-text-v1.5 (open source, deutsch ausreichend gut), text-embedding-3-large von OpenAI (besser, kostet)
• Framework: LangChain LCEL, LlamaIndex, Haystack, oder gleich eigener schlanker Code (oft sinnvoller als Framework-Abstraktion)
• Re-Ranking: Cohere rerank-3, BGE-Reranker (deutlicher Qualitätssprung, kleiner Cost-Overhead)

Fine-Tuning — wann es Sinn macht

Wann es lohnt. Wenn du Ton, Format oder Stil dauerhaft willst — z. B. firmen-typische E-Mail-Antworten, juristische Formulierungen, medizinische Abkürzungen. Oder wenn du klassifizieren willst (Mail-Routing, Ticket-Priorisierung) und RAG-Approach ineffizient wäre.

Wann es nicht lohnt. Wenn du Fakten beibringen willst. Fine-Tuning ist ein schlechter Weg, neues Wissen reinzubekommen — das Modell halluziniert dann oft mit der “neuen Wahrheit”. RAG ist dafür der bessere Weg.

Tooling 2026.

• OpenAI Fine-Tuning (GPT-5.5, GPT-4o-mini): Web-UI oder API, kommt mit Server-side-Hosting. Kostet ca. 25 €/Million Trainingstoken.
• Anthropic bietet 2026 noch kein öffentliches Fine-Tuning. Nur über Bedrock-Custom-Models bei AWS, eingeschränkt.
• Open-Source-Fine-Tuning: LoRA/QLoRA mit Unsloth, Axolotl oder HF TRL. Reicht meist (LoRA hat ~1 % der Parameter, gleiche Qualität für Stil-Tasks). Trainingsdauer auf 1× A100 typisch 2–8 Stunden bei kleinen Datasets.

Daten-Anforderung. Mindestens 100, besser 500–2.000 hochwertige Trainings-Beispiele. Qualität schlägt Quantität: 200 perfekt kuratierte Paare sind besser als 5.000 inkonsistente. Test-Set zu mindestens 20 % reservieren.

Long-Context — der Kontextfenster-Weg

Wann es ausreicht. Wenn dein gesamtes relevantes Wissen in den Kontext passt: Claude Sonnet 4.6 fasst 1 Million Tokens (ca. 700.000 Wörter, ca. 2.000 Seiten DIN A4), Gemini 2.5 Pro fasst 2 Millionen, Llama 4 Scout sogar 10 Millionen. Für viele B2B-Szenarien — ein einzelnes Vertragsdokument, ein Produkthandbuch, ein technisches Spec — reicht das problemlos.

Wann es nicht funktioniert.

• Bei 10+ Millionen Tokens an Bestandsdaten — zu groß
• Bei dynamisch wachsendem Korpus (jeder Ticket-Eintrag soll abrufbar sein) — zu unflexibel
• Bei strengen Daten-Trennungs-Anforderungen — du sendest immer alles, was unter Compliance-Gesichtspunkten ein No-Go sein kann

Kosten-Realität. 1 Million Token Input bei Claude Sonnet 4.6: ca. 3 € pro Anfrage. Bei 100 Anfragen am Tag → 300 €/Tag → ~9.000 €/Monat. Anthropic bietet Prompt-Caching an, das die wiederholten Teile auf ~10 % der Kosten senkt — aber nur wenn die Cache-TTL passt (5 Minuten Standard, 1 Stunde gegen Aufpreis).

Sweet Spot für Long-Context.

• Statischer Dokumentenbestand (< 500.000 Tokens)
• Niedrige bis mittlere Anfrage-Frequenz
• Hoher Anspruch an Antwort-Qualität (Long-Context liefert oft besser als RAG bei kleinen Korpora)

Die typischen Mittelstands-Architekturen

Pattern A: RAG-Standard (etwa 60 % unserer Projekte 2026)

• Embedding mit text-embedding-3-large oder bge-m3
• Vector-DB Qdrant on-prem oder pgvector in Bestandspostgres
• Generation mit Claude Sonnet 4.6 (Cloud) oder Llama 4 Scout (on-prem)
• Re-Ranking mit Cohere rerank-3 oder BGE-Reranker
• Audit-Log mit Anfrage, Retrieved Chunks, Antwort

Pattern B: RAG + Fine-Tune (etwa 15 % unserer Projekte)

• RAG für Faktenwissen
• Fine-Tune (meist LoRA auf Open-Source-Modell) für firmen-typischen Antwortstil
• Use-Case: Kundenservice mit eigener Tonalität

Pattern C: Long-Context (etwa 15 % unserer Projekte)

• Pro Anfrage: Anhang/Dokument vorladen, dann Frage stellen
• Use-Case: Vertragsprüfung, Diagnose-Berichte, technische Spezifikations-Analyse

Pattern D: Hybrid Long-Context + RAG (etwa 10 % unserer Projekte)

• Long-Context für aktuellen Vorgang (z. B. konkreter Kundenfall)
• RAG für Hintergrund-Wissen (Produktkatalog, FAQ)
• Use-Case: Komplexe Kundensupport-Anfragen mit Kontext über mehrere Tickets

Was du heute nicht tun solltest

Keine Fine-Tuning-Sessions, um aktuelle Faktenwissen ins Modell zu bekommen — das wird halluzinieren. Keine RAG-Pipeline ohne Re-Ranking, wenn die Antwortqualität wirklich zählt. Keine Million-Token-Long-Context-Calls bei hohem Anfragenvolumen ohne Prompt-Caching — das wird teuer.

Pragmatischer Einstieg: erst Long-Context mit den 10 wichtigsten Dokumenten testen, ob das Antwortverhalten ausreicht. Wenn ja: einfach so betreiben. Wenn nein: RAG bauen, mit Re-Ranking, mit Eval-Set für Regressions-Tests.