RAG – Was du jetzt wissen musst

RAG holt relevante Dokumente zur Laufzeit ins Modell, statt das Modell neu zu trainieren. Das ist 2026 der pragmatischste Weg zu nützlicher, belegbarer KI im Unternehmen, und mit Agentic RAG und MCP gerade dabei, sich neu zu erfinden.

Grosse Sprachmodelle haben ein grundsätzliches Problem: Ihr Wissen endet am Trainings-Cutoff, sie kennen deine internen Dokumente nicht, und wenn sie keine Antwort wissen, erfinden sie eine. Für produktive Anwendungen in Unternehmen ist das inakzeptabel. Retrieval-Augmented Generation (kurz RAG) löst das architektonisch, ohne dass du ein Modell neu trainieren oder fine-tunen musst. Deshalb ist RAG auch 2026 der de-facto-Standard für wissensbasierte KI-Anwendungen im Enterprise-Umfeld.

Stand: Juni 2026. RAG-Techniken und der regulatorische Rahmen (EU AI Act) entwickeln sich laufend; prüfe zeitkritische Angaben an der Originalquelle.

Was bedeutet RAG technisch, ohne Vereinfachung?

RAG kombiniert zwei Komponenten: einen Retrieval-Schritt und einen Generation-Schritt. Bevor das Sprachmodell eine Antwort generiert, sucht das System in einem Dokumentenindex nach relevantem Kontext und gibt diesen zusammen mit der Nutzerfrage an das Modell weiter. Das Modell antwortet auf Basis dieses Kontexts, nicht nur auf Basis seines Trainings. Das Konzept geht auf eine Arbeit von Lewis et al. aus dem Jahr 2020 zurück, die den Begriff geprägt hat.

Der technische Ablauf läuft in drei Phasen:

1. Indexierung: Dokumente werden in Chunks aufgeteilt (typisch 256 bis 1’024 Tokens), in Vektoren umgewandelt (Embedding-Modelle wie text-embedding-3-large oder ein mehrsprachiges Modell wie multilingual-e5-large für DACH-relevante Sprachen) und in einer Vektordatenbank gespeichert. Gängige Optionen: Qdrant, Weaviate, Pinecone oder pgvector als PostgreSQL-Extension.
2. Retrieval: Bei einer Nutzeranfrage wird diese ebenfalls in einen Vektor umgewandelt. Das System berechnet die Kosinus-Ähnlichkeit zur Anfrage und gibt die ähnlichsten Chunks zurück, typisch die Top-3 bis Top-10.
3. Augmentation und Generation: Die gefundenen Chunks werden als Kontext in den Prompt eingefügt. Das Sprachmodell generiert die Antwort auf Basis dieses Kontexts plus seinem allgemeinen Sprachverständnis.

Das Entscheidende: Das Modell wird nicht verändert. Die Wissensbasis liegt ausserhalb, ist versionierbar, aktualisierbar und auditierbar. Genau diese Trennung macht RAG für regulierte Branchen attraktiv.

Warum gewinnt RAG gegenüber Fine-Tuning, meistens?

Fine-Tuning ist sinnvoll, wenn du Ton, Stil oder domänenspezifische Syntax trainieren willst. Für reine Wissensvermittlung ist es oft die falsche Wahl. Ein Modell, das auf internen Dokumenten fine-getuned wurde, ist Monate später veraltet, sobald sich deine Dokumentenbasis ändert, und ein erneuter Trainingslauf kostet jedes Mal Geld und Zeit.

RAG dagegen skaliert inkrementell: Ein neues Dokument ins System laden dauert Sekunden. Die Wissensbasis lässt sich pro Nutzergruppe segmentieren, ein Sales-Team sieht andere Dokumente als die Rechtsabteilung. Und du kannst mit Quellangaben belegen, woher eine Antwort stammt. Genau diese Nachvollziehbarkeit wird unter dem EU AI Act zunehmend relevant.

Welche drei RAG-Fehler kosten in der Praxis am meisten?

1. Schlechtes Chunking zerstört die Qualität

Viele Teams nehmen ihre PDFs, teilen sie mechanisch in 500-Token-Blöcke und wundern sich über schlechte Ergebnisse. Das Problem: Kontext geht verloren, wenn ein Absatz mitten im Satz abgeschnitten wird oder wenn eine Tabelle über drei Chunks verteilt ist.

Besser ist semantisches Chunking, das Absatz- und Sektionsgrenzen respektiert. Frameworks wie LangChain oder LlamaIndex bieten dafür fertige Splitter. Für strukturierte Dokumente wie Verträge oder technische Spezifikationen ist ein dokumentenspezifisches Parsing sinnvoll, das Tabellen, Header und Listen separat behandelt.

2. Nur Vektor-Suche reicht nicht

Reine semantische Suche findet konzeptionell ähnliche Inhalte, versagt aber bei exakten Begriffen, Produktnummern oder Abkürzungen. Die Lösung heisst Hybrid Search: die Kombination aus Vektorsuche und klassischer Keyword-Suche (BM25). Qdrant und Weaviate unterstützen das nativ. In der Praxis verbessert Hybrid Search die Trefferqualität bei Enterprise-Dokumentenbeständen spürbar gegenüber reiner Vektorsuche.

3. Kein Reranking

Die Reihenfolge der zurückgegebenen Chunks beeinflusst die Antwortqualität erheblich, weil Sprachmodelle Informationen am Anfang und Ende des Kontexts stärker gewichten, bekannt als Lost-in-the-Middle-Problem. Ein Cross-Encoder-Reranker oder ein Dienst wie Cohere Rerank sortiert die Top-Ergebnisse nach tatsächlicher Relevanz zur Frage neu. Für viele Pipelines ist das der Schritt mit dem besten Verhältnis aus Aufwand und Qualitätsgewinn.

Was kommt nach dem Grundsetup? Advanced RAG

Sobald ein Basis-RAG-System läuft, zeigen sich Grenzen: komplexe mehrteilige Fragen, Informationen, die über mehrere Dokumente verteilt sind, oder Fragen, die trotz fehlender Datenlage selbstbewusst falsch beantwortet werden. Dafür gibt es etablierte Techniken.

• HyDE (Hypothetical Document Embeddings): Statt die Nutzerfrage direkt zu embedden, lässt man das Modell zunächst eine hypothetische Antwort generieren und embedded diese. Eine hypothetische Antwort liegt im Vektorraum näher an echten Antwort-Dokumenten als eine kurze Frage, was das Retrieval bei schwach formulierten Fragen verbessert.
• Self-RAG und CRAG: Neuere Architekturen lassen das Modell selbst entscheiden, ob es überhaupt etwas abrufen muss und ob die gefundenen Dokumente relevant genug sind. Das reduziert Halluzinationen in Fällen, in denen der Retrieval-Schritt schlechte Dokumente zurückgibt.
• GraphRAG: Statt Dokumente als isolierte Chunks zu behandeln, wird ein Wissensgraph aufgebaut, in dem Entitäten und ihre Beziehungen explizit modelliert sind. Bei Fragen, die mehrere Konzepte über Dokumentgrenzen hinweg verbinden, schlägt dieser Ansatz klassisches RAG deutlich.

Wie verändert sich RAG 2026? Agentic RAG, lange Kontexte und MCP

Drei Entwicklungen prägen RAG im laufenden Jahr. Wer ein System neu baut, sollte sie kennen, statt ein Tutorial von 2023 abzuarbeiten.

Agentic RAG: Der Agent entscheidet, wann er abruft

Im klassischen RAG ist der Retrieval-Schritt fix verdrahtet: Jede Anfrage löst genau eine Suche aus. Agentic RAG dreht das um. Ein Modell mit Tool-Calling entscheidet selbst, ob es überhaupt etwas abrufen muss, formuliert die Suchanfrage gegebenenfalls um, ruft mehrere Quellen nacheinander ab und prüft, ob die Antwort ausreicht. Für einfache Fragen spart das einen unnötigen Suchlauf, für komplexe Fragen erlaubt es mehrstufige Recherche. Self-RAG und CRAG sind frühe Bausteine dieses Musters. 2026 wird es zum Standard-Pattern in den grossen Frameworks.

Lange Kontexte vs. RAG: Warum 1-Million-Token-Fenster RAG nicht ersetzen

Moderne Modelle verarbeiten Kontextfenster von bis zu einer Million Tokens. Eine naheliegende These lautet deshalb: Stopf einfach alle Dokumente in den Prompt, dann brauchst du kein Retrieval mehr. In der Praxis stimmt das selten. Drei Gründe sprechen weiterhin für RAG:

• Kosten und Latenz: Du bezahlst jeden eingegebenen Token. Eine Million Tokens pro Anfrage zu schicken ist um Grössenordnungen teurer und langsamer, als ein paar relevante Chunks abzurufen.
• Aktualität: Ein Modell hat einen Wissens-Cutoff, eine Retrieval-Quelle nicht. Du aktualisierst die Wissensbasis unabhängig vom Modell und bekommst neue Informationen sofort.
• Nachvollziehbarkeit: RAG liefert dir, welche Dokumente eine Antwort gestützt haben. Bei einem Voll-Kontext-Prompt verschwimmt diese Spur, und ein Audit-Trail ist in regulierten Branchen Pflicht.

Hinzu kommt das Lost-in-the-Middle-Problem: Modelle nutzen Informationen am Anfang und Ende eines langen Kontexts zuverlässiger als solche in der Mitte. Die produktivste Antwort 2026 ist deshalb selten ein Entweder-oder. Teams kombinieren beides: ein gut gebautes RAG-System, das die wirklich relevanten Dokumente in ein grosses Kontextfenster legt.

MCP: Ein Standard für den Anschluss von Wissensquellen

Das Model Context Protocol (MCP) ist ein offener Standard, den Anthropic Ende 2024 vorgestellt hat. Er definiert eine einheitliche Schnittstelle, über die ein Modell externe Werkzeuge und Datenquellen anspricht: Dateisysteme, Datenbanken, interne APIs. Für RAG ist das relevant, weil die Anbindung der Wissensquelle damit standardisiert wird, statt für jede Quelle einen eigenen Connector zu bauen. MCP ersetzt RAG nicht: RAG beschreibt das Abrufen relevanten Wissens, MCP beschreibt, wie ein Agent auf Quellen und Werkzeuge zugreift. In agentischen Systemen greifen beide ineinander.

Was musst du bei RAG in DACH beachten?

Für Unternehmen im deutschsprachigen Raum kommen drei Punkte hinzu, die in amerikanischen Tutorials oft fehlen.

• Datenschutz und Hosting: Sobald interne Dokumente in ein RAG-System fliessen, stellt sich die Frage nach der datenschutzrechtlichen Grundlage: in der Schweiz nach dem revidierten Datenschutzgesetz (revDSG), in Deutschland und der EU nach der DSGVO (ergänzend BDSG), in Österreich nach DSGVO und DSG. Viele Teams entscheiden sich deshalb für On-Premise-Deployments mit offen verfügbaren Modellen und selbst-gehosteten Vektordatenbanken. Die Alternative sind Cloud-Angebote mit EU-Datacenter-Option und entsprechenden Auftragsverarbeitungsverträgen.
• Mehrsprachigkeit: Embedding-Modelle, die vorrangig auf Englisch trainiert wurden, performen auf Deutsch oft schlechter. Für DACH-Anwendungen empfehlen sich mehrsprachige Modelle wie multilingual-e5-large. Wer hohen Qualitätsanspruch hat, trennt die Embedding-Indizes nach Sprache.
• Dokumentenformate: In deutschsprachigen Unternehmen dominieren PDFs mit eingebetteten Tabellen, gescannte Dokumente und komplexe Word-Vorlagen. Ein robustes Parsing-Layer ist keine Kür, sondern Pflicht, damit Tabellen und Layouts strukturiert in den Index kommen.

Der regulatorische Rahmen verschärft genau diese Punkte. Der EU AI Act ist seit 2024 in Kraft und wird gestaffelt anwendbar: Die Pflichten für Modelle mit allgemeinem Verwendungszweck (GPAI) gelten seit August 2025. Die Hochrisiko-Pflichten wurden mit dem Digital Omnibus verschoben: für Annex-III-Systeme auf den 2. Dezember 2027, für Hochrisiko-KI in regulierten Produkten (Annex I) auf den 2. August 2028. Ab dem 2. August 2026 bleiben unter anderem die Transparenzpflichten nach Artikel 50 anwendbar. Wer ein KI-System in einem sensiblen Bereich betreibt, muss damit rechnen, Herkunft und Nachvollziehbarkeit von Antworten belegen zu müssen. Den genauen Stand und die endgültige Ausgestaltung solltest du immer an der offiziellen Quelle prüfen, da Details laufend konkretisiert werden. Die saubere Quellen-Spur, die RAG ohnehin liefert, ist hier ein konkreter Vorteil gegenüber einem reinen Voll-Kontext-Prompt.

Was kann RAG nicht?

RAG löst das Halluzinationsproblem nicht vollständig. Wenn das Retrieval schlechte oder unvollständige Dokumente zurückgibt, generiert das Modell trotzdem eine plausibel klingende Antwort, nur eben auf falscher Grundlage. Die Qualität eines RAG-Systems steht und fällt mit der Qualität der Wissensbasis und des Retrievals, nicht mit dem Sprachmodell allein. Wer veraltete, widersprüchliche oder schlecht strukturierte Dokumente indexiert, bekommt veraltete, widersprüchliche Antworten zurück.

Zwei weitere Grenzen sind wichtig: RAG ersetzt kein echtes Schlussfolgern über viele Schritte: Komplexe Logik bleibt Aufgabe des Modells und seines Prompts. Und RAG macht aus einem schwachen Basismodell kein starkes; es liefert besseren Kontext, aber die Generation bleibt so gut oder schlecht wie das gewählte Modell. RAG ist ein Werkzeug für Faktentreue und Aktualität, kein Allheilmittel.

Fazit: Wann lohnt sich RAG für dich?

Bau ein RAG-System, wenn dein Anwendungsfall auf internem oder sich schnell änderndem Wissen beruht und du belegen können musst, woher eine Antwort stammt, also bei Wissens-Assistenten, Support-Systemen und allem im regulierten Umfeld. Starte schlank: ordentliches Chunking, Hybrid Search, ein Reranker. Erst wenn dieses Fundament steht, lohnen sich Advanced-Techniken wie HyDE oder GraphRAG und der Schritt zu Agentic RAG. Greif zu Fine-Tuning nur, wenn es um Ton und Format geht, nicht um Wissen. Und lass dich nicht von Millionen-Token-Fenstern verführen: Sie sind ein nützliches Werkzeug neben RAG, kein Ersatz dafür. In den meisten DACH-Setups ist die Kombination aus gutem Retrieval und einem soliden Modell die pragmatischste und am besten auditierbare Lösung.

Zurück zur Übersicht: KI-Grundlagen.