In Teil 1 dieser Serie, warum Wissen wichtiger ist als das Modell, ging es um eine unbequeme Wahrheit: Nicht das größte KI-Modell entscheidet, ob KI in deinem Unternehmen funktioniert, sondern das Wissen, auf das sie zugreift. In Teil 2, warum deine Dokumente für KI unbrauchbar sind, hast du gesehen, warum ein Ordner voller PDFs auf SharePoint noch lange kein durchsuchbares Wissen ist. Jetzt kommt die Frage, die in der Praxis alles trägt: Wie kommt dieses Wissen konkret in die Antwort der KI, und zwar nur das richtige, nicht der ganze Wust?
Die Antwort heißt RAG. Der Begriff klingt technisch, das Prinzip ist es nicht. Danach kannst du sicher mitreden und die richtigen Fragen an deinen Dienstleister stellen.
RAG einfach erklärt: Was der Begriff wirklich bedeutet
RAG steht für Retrieval-Augmented Generation, sinngemäß „abrufgestützte Generierung“. Der Begriff wurde 2020 von Patrick Lewis und seinem Team geprägt und auf der Fachkonferenz NeurIPS 2020 veröffentlicht. Das Prinzip ist bis heute dasselbe geblieben.
Stell dir deinen Vertriebsinnendienst vor. Ein Kunde fragt nach einem Angebot, das einem früheren stark ähnelt. Die Antwort steckt irgendwo in 800 alten Angebots-PDFs, ein paar E-Mails und einer halb gepflegten Excel-Tabelle. Die naive Variante wäre, dem Sprachmodell einfach alles davorzukippen: langsam, teuer, ungenau. RAG macht es anders: Zu deiner konkreten Frage werden vorab die drei, vier Textstellen herausgesucht, die wirklich passen, und nur diese bekommt das Modell. Es antwortet auf dieser Basis und kann dir sagen, aus welchem Dokument und welcher Seite der Satz stammt.
Fachlich sauber beschrieben ist RAG die Kombination aus zwei Gedächtnissen: dem parametrischen Gedächtnis, also dem vortrainierten Sprachmodell selbst, und einem nicht-parametrischen Gedächtnis, einem durchsuchbaren Vektor-Index über deine Dokumente, auf den ein Retriever zugreift – das Suchmodul, das zu deiner Frage die passenden Stellen aus der Wissensbasis holt. Das Ergebnis laut Ursprungsarbeit: RAG-Systeme erzeugen „spezifischere, vielfältigere und faktentreuere“ Sprache als ein Modell, das nur aus seinem eigenen Training schöpft.
Zwei Phasen: erst einsortieren, dann abrufen
Jedes RAG-System zerfällt in zwei klar getrennte Phasen. Wer sie auseinanderhält, verliert bei den Fachbegriffen nicht den Faden.
Die Indexierungsphase läuft im Voraus, einmalig pro Dokument: Dokumente laden, in kleine sinnvolle Stücke zerlegen („Chunks“), jedes Stück per Embedding-Modell in Zahlen umwandeln und in einer Vektordatenbank ablegen. Das ist die Fleißarbeit, bevor überhaupt jemand fragt.
Die Retrieval- und Generierungsphase läuft live, bei jeder einzelnen Frage: Die Frage wird mit demselben Verfahren in Zahlen übersetzt, die ähnlichsten Chunks werden gesucht, bei Bedarf noch einmal sortiert und dann als Kontext an das Sprachmodell übergeben. Die Details dieser Pipeline nehme ich mir in Teil 4 zu OCR, Chunking und Vektordatenbank Schritt für Schritt vor. Hier geht es um das Herzstück, das beide Phasen erst möglich macht: Embeddings.
Alles ist nur Zahlen – Tokens und Embeddings
Ein neuronales Netz versteht keine Wörter, es rechnet nur mit Zahlen. Zwischen deinem Text und diesen Zahlen liegen zwei Schritte, die man sauber auseinanderhalten muss.
Schritt 1: Der Token – eine reine Nummer
Zuerst zerlegt ein Tokenizer den Text in Tokens, also Wörter oder Wortfragmente. Jeder Token bekommt eine ID aus dem Vokabular – eine reine Indexnummer, die für sich genommen nichts über die Bedeutung aussagt; zwei verwandte Wörter können völlig verschiedene IDs haben. Tokens ähneln grob Silben, folgen aber keiner Silbenregel, sondern entstehen statistisch aus den Trainingsdaten. „Arbeitssicherheitsunterweisung“ etwa zerlegt der GPT-4o-Tokenizer in sieben Tokens (Ar–beit–ss–icher–heits–unter–weisung) – erkennbar keine Silbengrenzen.
Für den Mittelstand heißt das: Deutsche Komposita kosten viele Tokens. „Qualitätsmanagementhandbuch“ sind fünf Tokens, „Krankenversicherungsunternehmen“ sechs. Die gern zitierte Faustregel „100 Tokens sind etwa 75 Wörter“ stammt von OpenAI und gilt ausdrücklich für englischen Text. Eine eigene Messung mit dem GPT-4o-Tokenizer zeigt: Deutsche Fachprosa braucht rund 1,2-mal so viele Tokens wie englische, also eher 66 statt 83 Wörter je 100 Tokens. Diese Werte gelten nur für OpenAI-Tokenizer, nicht für Claude oder Gemini.
Deshalb ist auch die verbreitete Rechnung „1 Million Token Kontextfenster gleich 750.000 Wörter“ für deutsche Texte falsch. Kontextfenster von 1 Mio. Tokens sind real (Claude Opus 4.8 etwa bietet genau das), aber auf Deutsch passen eher 650.000 bis 700.000 Wörter hinein. Und selbst das löst dein Problem nicht: Laut „Lost in the Middle“ nutzen Modelle Informationen am Anfang und Ende gut, in der Mitte aber deutlich schlechter, sogar solche, die extra für lange Kontexte gebaut sind. Ein großes Kontextfenster ersetzt Retrieval also nicht, es verschiebt nur die Grenze.
Schritt 2: Das Embedding – hier entsteht Bedeutung
Jetzt kommt der eigentliche Trick. Jeder Chunk wird durch ein spezielles Modell geschickt, das daraus einen Vektor berechnet: eine lange Liste von Zahlen. In diesem Zahlenraum liegen Inhalte mit ähnlicher Bedeutung nah beieinander, fremde Bedeutung weit auseinander. Aus der QM-Welt: „Erstmusterprüfbericht“ liegt näher an „Wareneingangsprüfung“ als an „Urlaubsantrag“. Genau diese Nähe ist die Bedeutung. Wichtig: Es zählt nur die Rangfolge, nicht der absolute Wert: Ein Ähnlichkeitswert von 0,65 heißt nicht „65 Prozent Übereinstimmung“, weil jedes Modell anders skaliert. Die Anzahl der Zahlen in dieser Liste nennt man die Dimension des Embeddings.
Das Embedding-Modell – und worauf du bei Deutsch achtest
Das Modell, das Text in Vektoren übersetzt, ist ein Embedding-Modell, nicht das Sprachmodell, das später die Antwort formuliert. Die Auswahl ist eine echte Stellschraube, gerade für deutsche Dokumente. In Wissens-KI-Projekten gehe ich immer dieselben nachprüfbaren Kriterien durch:
- Maximale Eingabelänge: Sie begrenzt hart, wie groß deine Chunks sein dürfen. multilingual-e5-large fasst nur 512 Tokens, BGE-M3 und jina-embeddings-v3 dagegen bis zu 8192.
- Dimensionen: Mehr Dimensionen bilden feinere Bedeutungsunterschiede ab, kosten aber mehr Speicher und Rechenzeit pro Suche, also Latenz im Chatbot. Manche lassen sich per „Matryoshka“ kürzen – benannt nach den ineinander geschachtelten Holzpuppen, weil der lange Vektor kürzere, weiter brauchbare Varianten in sich trägt (jina-v3 etwa von 1024 auf bis zu 32).
- Präfixe oder Adapter: multilingual-e5-large verlangt zwingend „query:“ und „passage:“ vor den Texten, sonst sinkt die Qualität. jina-v3 nutzt aufgabenspezifische Adapter.
- Dense plus Sparse: BGE-M3 liefert dichte und lexikalische Repräsentationen gleichzeitig, also hybride Suche ohne zweites System.
- Betriebsmodell: Selbst gehostet (e5, BGE-M3, Qwen3, jina) oder als API (OpenAI text-embedding-3, Cohere embed-v4.0, Google, Mistral). Für DSGVO-Kontexte im Mittelstand ist das oft die entscheidende Frage, die ich in der KI-Beratung zuerst kläre.
Alle genannten Modelle unterstützen Deutsch. Zur Bewertung gibt es den MTEB-Benchmark, für Deutsch den Zuschnitt MTEB(deu, v1) mit 19 Aufgaben über Retrieval, Clustering, Klassifikation, Reranking und Textähnlichkeit. Aber Vorsicht: Werte verschiedener MTEB-Versionen sind nicht vergleichbar, die Rangfolgen unterscheiden sich je nach Board, und „das beste Modell für Deutsch“ gibt es nicht seriös von der Stange. Für native deutsche Long-Context-Tests fehlen sogar die Datensätze; die Autoren von ModernGBERT mussten sich einen eigenen bauen. Mein Rat: Leaderboard als Orientierung, Entscheidung aber auf deinen eigenen Dokumenten nachmessen.
Warum RAG – und nicht ein eigenes Modell trainieren
Viele Entscheider fragen: Sollten wir nicht ein eigenes KI-Modell auf unsere Daten trainieren oder ein bestehendes „feintunen“? Meist lautet die Antwort: nein. RAG ist aus guten Gründen der Standardweg.
- Aktualität ohne Neutraining: Ein neues Angebot, ein geänderter Vertrag, ein frisches Prüfprotokoll: Du legst es in die Wissensbasis, und es ist sofort auffindbar. Ein trainiertes Modell müsstest du für jede Änderung neu trainieren.
- Quellenangabe: RAG kann bei jeder Antwort sagen, aus welchem Dokument sie stammt. Das macht Antworten überprüfbar, im QM oder in der Service-Dokumentation unverzichtbar. Ein feingetuntes Modell verrät seine Quelle nicht.
- Weniger Halluzinationen: Als Halluzination bezeichnet man frei erfundene, aber überzeugend formulierte Antworten. Weil das Modell sich bei RAG auf konkrete Belege stützen muss, sinkt die Neigung dazu. Wie stark schon der reine Abrufschritt besser wird, hat Anthropic gemessen: Die Wahrscheinlichkeit, dass das relevante Dokument gar nicht unter den Top-Treffern landet, fällt von 5,7 Prozent über 3,7 Prozent mit besseren Embeddings bis auf 1,9 Prozent mit zusätzlichem Reranking. Das ist eine Abruf-Fehlerrate, keine Halluzinationsrate, und ausdrücklich nicht null. Selbst bei richtiger Quelle kann das Modell noch falsch schlussfolgern; eine Garantie ist RAG nicht.
Und alles ins große Kontextfenster zu kippen? Keine Lösung: Du zahlst bei jeder Frage erneut alle Tokens, und der Lost-in-the-Middle-Effekt frisst die Trefferqualität. RAG überträgt pro Frage nur wenige Chunks – günstiger und präziser.
Unsicher, ob für dein Unternehmen RAG oder Fine-Tuning passt? Das klären wir in einem kurzen Gespräch: Schreib mir, und wir schauen gemeinsam auf deinen Fall.
Nicht „die sieben RAG-Arten“, sondern eine Reihe von Ansätzen
Im Netz kursieren Listen mit angeblich sieben festen RAG-Architekturen. Das ist keine saubere Fachtaxonomie. Die maßgebliche Übersichtsarbeit unterscheidet drei Paradigmen (Naive, Advanced und Modular RAG) und drei tragende Komponenten: Retrieval, Generation und Augmentation. Daneben gibt es benannte Ansätze, die sich teils überschneiden: Self-RAG, bei dem das Modell selbst entscheidet, ob überhaupt abgerufen wird; GraphRAG von Microsoft, das einen Wissensgraphen aus den Dokumenten baut und „globale“ Fragen beantwortet, an denen reine Vektorsuche scheitert; und Agentic RAG, bei dem ein Agent die Abrufstrategie dynamisch steuert. Diese Ansätze schaue ich mir in Teil 5 zu Hybrid-Suche und Reranking und Teil 6 zu Knowledge Graphs und GraphRAG genauer an. Für den Einstieg reicht: ein Werkzeugkasten, keine feste Siebener-Liste.
Häufige Fragen
Verhindert RAG Halluzinationen komplett?
Nein, aber es reduziert sie stark. Selbst die beste gemessene Abruf-Konfiguration liegt bei 1,9 Prozent Fehlerrate, nicht bei null, und das Modell kann trotz richtiger Quelle falsch kombinieren. Behandle jede KI-Antwort als überprüfbaren Vorschlag, nicht als Orakel.
Was ist der Unterschied zwischen RAG und Fine-Tuning?
Fine-Tuning bringt einem Modell einen Stil oder ein Verhalten bei, RAG bringt ihm dein aktuelles Faktenwissen. Ein neues Angebot landet bei RAG sofort in der Wissensbasis; beim Fine-Tuning müsstest du dafür neu trainieren, zahlst mehr und bekommst keine Quellenangabe. Für Faktenwissen ist RAG fast immer der richtige Weg.
Brauche ich RAG überhaupt noch, wenn Modelle 1 Million Token Kontext haben?
Ja. Ein großes Fenster verschiebt die Grenze, es ersetzt gezieltes Retrieval nicht: Du zahlst bei jeder Frage alle Tokens erneut, und laut „Lost in the Middle“ sinkt die Trefferqualität in der Mitte des Kontexts, auf Deutsch obendrein bei nur 650.000 bis 700.000 Wörtern statt der oft genannten 750.000.
Welches Embedding-Modell ist das beste für Deutsch?
Es gibt keine allgemeingültige Antwort. Entscheide nach nachprüfbaren Kriterien (Eingabelänge, Dimension, Präfix- oder Adapter-Anforderungen, Hosting) und miss die engere Auswahl auf deinen eigenen Dokumenten nach. Für DSGVO-sensible Bereiche spricht viel für ein selbst gehostetes Modell.
Fazit
RAG ist kein Zauberwort, sondern ein nüchternes Prinzip: Die KI bekommt zu jeder Frage nur die passenden Stellen aus deinen Dokumenten mitgeliefert und antwortet auf dieser Basis – mit Quellenangabe. Das Herzstück sind Embeddings, die Text in einen Zahlenraum übersetzen, in dem ähnliche Bedeutung nah beieinanderliegt. Das passende Embedding-Modell wählst du nicht nach Bauchgefühl oder Leaderboard-Platz, sondern nach harten Kriterien und einer Messung auf deinen eigenen Unterlagen. Genau deshalb ist RAG der Standard, nicht das teure Training eines eigenen Modells.
Im nächsten Teil, Von der PDF zur Antwort: OCR, Chunking und Vektordatenbank, bauen wir die Indexierungsphase konkret auf: Wie aus einer eingescannten PDF sauberer Text wird, wie du lange Dokumente in Chunks zerlegst und wo die Vektoren landen. Wenn du für dein Unternehmen im Raum Aalen und dem Ostalbkreis prüfen willst, ob sich ein Wissens-Chatbot lohnt, lass uns gemeinsam auf deine Dokumente und den sinnvollsten ersten Schritt schauen.