Kontextfenster vs RAG vs Fine-Tuning: Was wählen?

Drei Wege, ein LLM mit Ihren Daten und Aufgaben arbeiten zu lassen - alles ins Kontextfenster legen, RAG (Retrieval-Augmented Generation) anbinden oder das Modell fine-tunen. Jeder Ansatz hat eigene Kosten, Aktualisierungsgeschwindigkeit und Genauigkeitsgrenze. Im Folgenden: Aufbau, Unterschiede und Strategiewahl für Chatbot, Support-Assistent oder internen Copilot ohne unnötige Ausgaben.

Drei Ansätze für eine Aufgabe

Das Ziel ist gleich: Das Modell soll Fragen zu Ihrem Produkt, Ihrer Dokumentation, Richtlinien oder Domäne beantworten - nicht nur Pre-Training-Wissen. Optionen:

Ansatz	Idee	Wo Wissen liegt
Kontextfenster	Gesamter Text im Prompt	In jeder Anfrage
RAG	Relevante Fragmente suchen + generieren	Im Index / in der Wissensbasis
Fine-Tuning	Modellgewichte nachtrainieren	In den Modellgewichten

Oft wählt man nicht „entweder“, sondern eine Kombination: RAG für Fakten, Fine-Tuning für Stil und Format, langer Kontext für wenige Dokumente in einer Anfrage.

Kontextfenster: Alles im Prompt

Das Kontextfenster ist die Textmenge (in Tokens), die das Modell in einer Anfrage „sieht“: System-Prompt, Chat-Verlauf, angehängte Dateien und Anweisungen.

Funktionsweise

Sie legen in den Prompt:

• System-Anweisungen („antworte als Rechtsberater von Firma X“);
• relevante Dokumente ganz oder in großen Stücken;
• Few-Shot-Beispiele („hier ein gutes Antwortmuster“).

Moderne Modelle (GPT-5.6, Claude Fable 5, Gemini 3.5 Flash) unterstützen 1-2M Token Kontext - hunderte Seiten. Für viele Szenarien reicht das ohne eigene Infrastruktur.

Vorteile

• Minimale Infrastruktur - kein Vektorindex, keine Embedding-Pipeline.
• Sofortige Updates - Prompt-Text ändern, Wissen ist sofort aktuell.
• Transparenz - Sie wissen genau, was das Modell in dieser Anfrage „sieht“.
• Few-Shot ohne Training - Beispiele im Prompt setzen das Antwortformat.

Nachteile

• Kosten steigen mit Länge - Long-Context-Tarife oft x1,5-x2 zum Basispreis.
• Volumengrenze - selbst 2M Token fassen keine gesamte Enterprise-Wissensbasis.
• Qualität in der Mitte - Modelle verlieren Details in sehr langem Kontext (lost-in-the-middle).
• Latenz - mehr Input-Tokens bedeuten langsameren ersten Token.

Wann Kontext wählen

• Kleiner, stabiler Korpus: 5-50 Dokumente, ein Produkt, ein FAQ.
• Prototyp oder MVP - Hypothese in einem Tag ohne RAG-Stack testen.
• Aufgaben mit vollem Text in einer Anfrage: zwei Verträge vergleichen, Code-Review eines ganzen PR.
• Volle Kontrolle über den Prompt-Inhalt (Audit, Compliance).

RAG: Suche + Generierung

RAG (Retrieval-Augmented Generation) - vor der Antwort sucht das System relevante Fragmente in Ihrer Basis (Vektorsuche, BM25, Hybrid), fügt sie in den Prompt ein, und das Modell generiert eine Antwort auf Basis des Gefundenen.

Funktionsweise

Typische Pipeline:

1. Ingestion - Dokumente in Chunks (300-1000 Token), Embeddings erzeugen.
2. Index - Vektor-DB (Pinecone, Qdrant, pgvector, Chroma) + optional Keyword-Index.
3. Query - Nutzerfrage -> Embedding -> top-k Chunks.
4. Generation - Chunks + Frage -> LLM -> Antwort (idealerweise mit Quellenangaben).

Wissens-Updates: geänderte Dokumente reindizieren - ohne Modell-Nachtraining.

Vorteile

• Skalierung - Millionen Seiten bei richtigem Indexing und Chunking.
• Aktualität - neues Dokument in Minuten im Index, nicht in Wochen.
• Weniger Halluzinationen - Modell stützt sich auf gelieferte Fragmente; Zitate erhöhen Vertrauen.
• Input-Ersparnis - nur relevante Stücke im Prompt, nicht die ganze Basis.

Nachteile

• Komplexität - Chunking, Embeddings, Reranking, Evaluation, Drift-Monitoring.
• Retrieval-Qualität = Antwortqualität - schlechte Suche liefert schlechte Antworten trotz „perfektem“ Modell.
• Latenz - zwei Schritte (Suche + Generierung) plus Rerank.
• Duplikate und Widersprüche - verschiedene Dokumentversionen im Index verwirren das System.

Wann RAG wählen

• Große oder häufig wechselnde Basis: Docs, Wiki, Tickets, Confluence, PDF-Archiv.
• Quellenlinks in Antworten nötig (Support, Legal, Medical mit Vorbehalten).
• Viele Nutzer und Anfragen - günstiger, 5 Chunks zu holen als 500 Seiten in den Kontext.
• Daten dürfen nicht in Modellgewichte (Vertraulichkeit, Mandantenisolation).

Fine-Tuning: Wissen in den Gewichten

Fine-Tuning - Weitertraining eines Basismodells auf Ihren Daten: Instruction/Response-Paare, Dialoge, Domänentext. Gewichte verschieben sich, sodass das Modell Stil, Terminologie und typische Aufgaben besser kennt ohne langen Prompt.

Varianten:

• Full Fine-Tuning - alle Parameter (teuer, selten nötig).
• LoRA / QLoRA - Adapter auf frozen Base (Standard für Custom-Modelle).
• DPO / RLHF - Ausrichtung auf Präferenzen (Ton, Sicherheit, Format).

Funktionsweise

1. Dataset aufbauen: Q&A, Support-Dialoge, Code-Beispiele, JSON-Antworten.
2. Adapter oder volles Modell auf GPU trainieren (Stunden bis Tage).
3. Fine-tuned Endpoint oder merged Weights deployen.
4. Bei Inference - kurzer System-Prompt, Modell „kennt“ Muster bereits.

Fine-Tuning ersetzt keine aktuellen Fakten: Preise, API-Versionen, Produktnews werden ohne RAG oder frischen Kontext nicht zuverlässig „gemerkt“.

Vorteile

• Stil und Format - einheitlicher Ton, JSON-Schema, Antwortvorlagen.
• Weniger Prompt-Tokens - keine langen Anweisungen und Dutzende Few-Shot-Beispiele.
• Latenz und Kosten pro Anfrage - kürzerer Prompt für dieselbe Aufgabe.
• Fachterminologie - Medizin, Recht, internes Jargon.

Nachteile

• Teuer und langsam - Daten, GPU, Iterationen, Eval; ML-Kompetenz nötig.
• Veraltung - neues Produkt = neuer Trainingszyklus oder Hybrid mit RAG.
• Overfitting-Risiko - Modell „auswendig gelernt“, generalisiert schlecht.
• Schwächer bei seltenen Fakten - Fine-Tuning schlechter als RAG für „finde Absatz 4.2 in Policy v3“.

Wann Fine-Tuning wählen

• Stabile Aufgabe mit wiederholtem Format: Klassifikation, Extraktion, templated Summaries.
• Kurzer Prompt und niedrige Latenz bei Millionen Anfragen.
• Große Menge qualitativ gelabelter Dialoge (tausende+ Beispiele).
• On-prem oder air-gapped - ein lokales Modell ohne externe API pro Chunk.

Vergleich nach Kriterien

Kriterium	Kontext	RAG	Fine-Tuning
Wissensvolumen	Bis Fenstergrenze	Praktisch unbegrenzt	Begrenzt durch Training Set
Aktualität	Sofort (neuer Prompt)	Schnell (Reindex)	Langsam (Retrain)
Startkosten	Niedrig	Mittel	Hoch
Kosten pro Anfrage	Steigt mit Kontextlänge	Suche + kurzer Kontext	Niedriger Prompt
Halluzinationen	Mittleres Risiko	Niedriger bei gutem Retrieval	Mittel, „selbstsichere“ Fehler
Quellenangaben	Manuell im Prompt	Natürlich	Schwer
Infrastruktur	Modell-API	Vektor-DB, Pipeline	GPU, MLOps
Compliance / Audit	Volle Prompt-Kontrolle	Retrieval-Logs	Gewichte Black Box

Praktische Entscheidungsmatrix

Mit Kontext starten, wenn:

• wenige Dokumente in 100-200K Token passen;
• POC in einem Sprint nötig;
• jede Anfrage einzigartig ist und „die ganze Datei“ braucht (Diff, Vertrag).

RAG hinzufügen, wenn:

• Basis gewachsen ist oder wöchentlich aktualisiert wird;
• Nutzer nach konkreten Fakten aus tausenden Seiten fragen;
• Zitate und niedrigere Halluzinationsrate nötig sind.

Fine-Tuning hinzufügen, wenn:

• Antwortformat strikt und auf 95% der Anfragen identisch;
• RAG läuft, aber Prompt durch Anweisungen und Beispiele anschwillt;
• Dataset und Budget für Eval-Iterationen vorhanden.

Typischer Production-Stack 2026:

Fine-tuned Modell (Stil + Routing)
    + RAG (Fakten aus Wissensbasis)
    + Moderater Kontext (System-Prompt, letzte N Nachrichten, 1-2 volle Docs bei Bedarf)

Häufige Fehler

• „Alles in 1M Kontext schütten“ - teuer, langsam; Retrieval-Qualität oft besser bei gleichem Budget.
• Fine-Tune statt RAG für FAQ - Modell „merkt“ veraltete Preise; RAG oder Kontext ist einfacher.
• RAG ohne Eval - ohne Metriken (recall@k, faithfulness, Human Review) degradiert das System unbemerkt.
• Chunks zu klein - Absatzsinn geht verloren; zu groß - Rauschen im Prompt.
• Reranking ignorieren - top-5 aus Vektorsuche ohne Cross-Encoder oft schlechter als BM25 + Rerank-Hybrid.

Fazit

Kontextfenster - schneller Start und volle Kontrolle für kleine Mengen. RAG - Standard für skalierbare Wissensbasen mit frischen Fakten und Zitaten. Fine-Tuning - Investition in stabiles Verhalten und Format, keine Enzyklopädie von Fakten.

Für die meisten Unternehmens-Assistenten ist RAG + kurzer System-Prompt optimal; Fine-Tuning kommt dazu, wenn messbare Qualitäts- oder Kostenvorteile das Training rechtfertigen. Langer Kontext punktuell - für Aufgaben mit ganzem Dokument in einem Shot, nicht als Ersatz für organisationweite Suche.

Häufig gestellte Fragen

Kann man RAG durch ein sehr langes Kontextfenster ersetzen?

Theoretisch - für kleine Korpora. Praktisch - selten lohnend: Kosten und Latenz wachsen linear mit Prompt-Länge, Modelle nutzen Information aus der Mitte langer Kontexte schlechter. RAG holt nur Relevantes und skaliert auf große Archive. Ausnahme - „lies die ganze Datei“: Code-Review, zwei Vertragsversionen vergleichen, ein 200-Seiten-PDF analysieren.

Braucht ein Unternehmens-Chatbot Fine-Tuning?

Nicht zwingend am Anfang. Die meisten internen Copilots und Support-Bots reichen mit RAG + gutem System-Prompt. Fine-Tuning lohnt bei tausenden Referenzdialogen, einheitlichem Format (JSON, Tickets, CRM-Felder) oder kritischen Token-Einsparungen pro Anfrage. Zuerst Baseline mit RAG messen - Fine-Tuning ohne Metriken lohnt sich oft nicht.

Was ist günstiger: RAG oder Fine-Tuning?

RAG günstiger upfront: Vektor-DB, Embeddings-API, kein GPU-Cluster. Fine-Tuning teurer am Start (Daten, Training, Deploy), kann aber Kosten pro Anfrage senken, wenn lange Anweisungen und Few-Shot aus jedem Prompt bei hohem Traffic entfallen. TCO über 6-12 Monate vergleichen: RAG-Infra + Embedding-Refresh vs Retrain-Kosten und Inference des fine-tuned Modells.

Wie oft muss Wissen bei jedem Ansatz aktualisiert werden?

Kontext - bei jeder Anfrage (aktueller Prompt) oder beim Deploy neuer Template-Version. RAG - bei Dokumentänderungen: inkrementelles Reindex von Minuten bis Stunden; Full Rebuild nach Plan oder bei Wechsel des Embedding-Modells. Fine-Tuning - bei Verhaltens- oder Domänenwechsel: Wochen bis Monate zwischen Releases; Fakten (Preise, Releases) weiterhin via RAG oder Tool Calls.

Kann man alle drei Ansätze kombinieren?

Ja, und die besten Production-Systeme tun das. Fine-tuned Modell setzt Stil und Routing („Wissensbasissuche nötig?“). RAG liefert aktuelle Fragmente. Kontext enthält Systemregeln, Chat-Verlauf und manchmal ein volles Dokument für „ganz lesen“-Aufgaben. Wichtig: klare Rollen - Fakten aus RAG, Verhalten aus Fine-Tuning, Constraints und Few-Shot aus Prompt - ohne denselben Text in allen Schichten zu duplizieren.