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 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:

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 - 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

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.

Wann man mit RAG oder Fine-Tuning nicht überstürzen sollte

• Wenig Daten, wenig Fragen. Eine Handvoll Dokumente und seltene Nutzerfragen - ein langer Kontext im Prompt reicht aus; RAG-Infrastruktur und Fine-Tuning rechnen sich vorerst nicht.
• Kein Prozessverantwortlicher. RAG braucht jemanden, der die Aktualität des Index im Blick behält, Fine-Tuning jemanden für die Datenqualität; ohne verantwortliche Person sinkt die Antwortqualität unbemerkt.
• Produkt und Daten sind noch instabil. Solange sich Preise, Prozesse und Formulierungen häufig ändern, ist Fine-Tuning besonders riskant - jede Änderung erfordert einen neuen Trainingszyklus; in dieser Phase lohnen sich eher kurzer Kontext und Prompt-Anpassungen.
• Keine Zeit für Qualitätsbewertung. Recall, Antwortgenauigkeit und Tests mit echten Fragen brauchen Iterationen; wer Ergebnisse „in einer Woche, ohne Nacharbeit" braucht, beginnt am besten mit der einfachsten Variante - dem Kontextfenster - und ergänzt RAG und Fine-Tuning mit wachsender Last.

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.

Wenn Sie Hilfe bei Entwicklung, KI-Einführung oder Website-Betreuung für Ihr Projekt brauchen - schreiben Sie mir.

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.

Begriffe in diesem Artikel

LLM — Large Language Model

RAG — Retrieval-Augmented Generation

chatbot — conversational bot interface

fine-tuning — additional training of a model on domain data — zusätzliches Training des Modells auf Domänendaten

few-shot — prompting with a few examples — Prompting mit wenigen Beispielen

MVP — Minimum Viable Product

embeddings — numeric vectors that capture text meaning — numerische Vektoren, die Textbedeutung abbilden

pipeline — sequence of processing stages

chunks — small text pieces indexed for retrieval — kleine Textstücke für Retrieval/RAG

chunking — splitting documents into retrieval-friendly pieces — Aufteilen von Dokumenten in suchbare Fragmente

top-k — keep only the k most likely next tokens when sampling — bei Sampling nur die k wahrscheinlichsten Tokens behalten

reranking — reordering search results by relevance — Neusortierung von Suchergebnissen nach Relevanz

Confluence — Atlassian wiki for team documentation — Atlassian-Wiki für Teamdokumentation

inference — running a trained model to get predictions — Ausführung eines trainierten Modells für Vorhersagen

QLoRA — Quantized Low-Rank Adaptation

endpoint — specific API URL that accepts requests — spezifische API-URL, die Anfragen entgegennimmt

LoRA — Low-Rank Adaptation

RLHF — Reinforcement Learning from Human Feedback

GPU — Graphics Processing Unit

air-gapped — network fully isolated from the public internet — Netz vollständig vom öffentlichen Internet getrennt

on-prem — software hosted in your own infrastructure — Software in der eigenen Infrastruktur, nicht in der Cloud

retrieval — finding relevant context before generation — Finden relevanter Kontexte vor der Generierung

PoC — proof of concept / pilot

fine-tune — train a model further on domain data — Modell auf Domänendaten weiter trainieren

cross-encoder — rerank model that scores query and document together — Rerank-Modell, das Query und Dokument gemeinsam bewertet

baseline — reference measurement before changes

TCO — Total Cost of Ownership — Gesamtkosten des Eigentums