Was ist RAG?

Stell dir einen brillanten Praktikanten vor, der jedes Buch der Weltliteratur gelesen hat — aber noch nie was von deiner Firma gehört. Du setzt ihn in eine Sitzung über euren Onboarding-Prozess. Wenn du nichts tust, redet er allgemeines Zeug. Wenn du ihm vorher den passenden Stapel Notizen auf den Tisch legst, redet er plötzlich wie ein Insider. Das ist RAG. Mehr nicht.

Also die Kurzfassung, falls du es eilig hast. RAG — Retrieval-Augmented Generation — ist eine Mechanik aus zwei Schritten. Erst sucht ein kleines System die für die Frage passenden Stücke aus deinen Dokumenten raus (das R, Retrieval). Dann legt es diese Stücke dem KI-Modell zusammen mit der Frage in den Prompt, und das Modell antwortet auf dieser Grundlage (das G, Generation). Augmented heißt: die normale Antwort wird um deinen Kontext angereichert.

Der einzige technische Trick dabei: Wie findet man die richtigen Stücke aus tausenden Seiten? Über Embeddings, eine Methode, Texte so abzulegen, dass man inhaltlich Ähnliches schnell finden kann. Das war’s. RAG ist clever, aber nicht magisch.

Warum weiß ChatGPT nichts über deine Firma?

Ein KI-Modell wie ChatGPT oder Claude wurde mit einem riesigen Textberg trainiert, der bis zu einem Stichtag reicht — dem Cutoff-Date. In diesem Datensatz stehen Wikipedia, GitHub, Foren, Bücher, Zeitungen. Was nicht drinsteht: dein Onboarding-Wiki in Notion, eure Confluence-Seiten zum Liefer-Prozess, die hundert Tickets im Helpdesk, die das echte Wissen halten.

Hab ich im MCP-Server-Artikel schon kurz angerissen — hier ist die Stelle, wo es richtig konkret wird. Wenn ChatGPT auf die Frage „Wie läuft bei uns das Onboarding eines neuen Kunden?” irgendwas Allgemeines erzählt, ist das nicht doof, das ist halt das Resultat: kein Kontext, also kommt eine Standardantwort.

Die Frage ist also: Wie bringen wir dem Modell unsere Dokumente bei, ohne es jedes Mal neu zu trainieren? Letzteres wäre absurd teuer und absurd langsam. Es muss einfacher gehen.

Der naive Versuch: alles reinkopieren

Das Erste, was jeder probiert: die Dokumente einfach in den Prompt kleben. Geht prinzipiell. Frag: „Hier ist unser Onboarding-Doc. Wie läuft das Onboarding?” — und kopier das ganze Doc als Text mit rein. Funktioniert für ein einzelnes Dokument tatsächlich überraschend gut.

Das Problem fängt mit der Größe an. Jedes Modell hat ein Context-Window — die maximale Textmenge, die du ihm pro Frage geben kannst. Claude zum Beispiel kann etwa 200.000 Token verarbeiten, das sind grob 150.000 Wörter, also ein dickes Sachbuch. Klingt nach viel. Bei deinen 5.000 Notion-Seiten ist es ein Witz.

Dazu kommt ein Effekt, den viele unterschätzen: Je mehr du reinkippst, desto unschärfer wird die Antwort. Wenn das Modell durch 80.000 Wörter wühlen muss, um die drei Sätze zu finden, die wirklich zur Frage passen, leidet die Qualität spürbar. Mehr Kontext heißt nicht automatisch besserer Kontext.

Also brauchen wir nicht alles. Wir brauchen die richtigen Stücke.

Wie findet man „die richtigen Stücke”?

Das ist die einzig interessante technische Frage bei RAG — und Embeddings sind die Antwort.

Die Idee dahinter ist erstaunlich simpel: Wenn man einen Text in eine bestimmte Sorte Zahlenreihe übersetzt, kann man inhaltlich ähnliche Texte daran erkennen, dass ihre Zahlenreihen nahe beieinander liegen. Dafür gibt’s spezialisierte Modelle — OpenAI text-embedding-3, Cohere Embed, Voyage AI und Open-Source-Modelle wie BGE. Du jagst einen Textabschnitt durch so ein Modell, raus kommt eine lange Zahlenreihe (typischerweise 1.500 bis 3.000 Zahlen). Diese Reihen legst du in einer Vektordatenbank ab — etwa Pinecone, Weaviate, pgvector (das Postgres-Plugin) oder ChromaDB.

Wenn jetzt jemand eine Frage stellt, wird die Frage genauso in eine Zahlenreihe verwandelt. Die Vektordatenbank gibt dir die paar Text-Abschnitte zurück, deren Reihen am nächsten dran liegen — und das sind genau die, die thematisch zur Frage passen. Bibliothekar mit Superspürsinn, nichts anderes.

🤓 Wie wird Text zu Zahlen — und warum funktioniert das?

Drei Schritte, alle nicht so wild wie sie klingen.

Erstens: Tokenisierung. Jeder Text wird in kleine Stücke zerlegt — sogenannte Tokens. Das sind oft ganze Wörter, manchmal Wortteile, besonders bei zusammengesetzten deutschen Wörtern. „Onboarding-Prozess” wird zu drei Tokens: On, boarding-, Prozess.

Zweitens: durch ein Embedding-Modell jagen. Diese Tokens laufen durch ein neuronales Netz, das mit Milliarden Textbeispielen trainiert wurde. Es nutzt dieselbe Transformer-Architektur, die auch GPT und Claude antreibt — der entscheidende Durchbruch dahinter ist ein Paper von Google aus 2017 mit dem schönen Titel „Attention Is All You Need”. Die Kernidee: jeder Token wird im Verhältnis zu allen anderen im Text betrachtet. Erst dadurch versteht das Modell Kontext. Am Ende kommt eine einzige Zahlenreihe raus — typisch 1.536 oder 3.072 Werte lang.

Drittens: jede Dimension steht für eine semantische Eigenschaft. Das beste Bild dafür ist das deutsche Wort Kater. Im Satz „Mein Kater ist 12 Jahre alt” landet das Embedding nah an Tier, Haustier, Familie. Im Satz „Ich habe einen Kater nach gestern” nah an Alkohol, Kopfschmerz, Wochenende. Das gleiche Wort, zwei komplett verschiedene Positionen — weil moderne Embeddings den Kontext drumherum mitberechnen. Klassische Embeddings vor 2018 (Word2Vec, GloVe) konnten das noch nicht; die hatten pro Wort einen festen Vektor. Heutige Modelle nicht mehr.

Auf 2D kannst du dir das wie eine Karte mit zwei Achsen vorstellen — „Tier” auf der einen, „Alkohol” auf der anderen. „Kater” rutscht je nach Kontext mal in die eine, mal in die andere Ecke. Echte Embeddings haben aber 1.536 oder 3.072 solche Achsen, jede für irgendeine semantische Eigenschaft, die das Modell im Training herausgearbeitet hat. Klassisches Beispiel für die Geometrie dahinter: König − Mann + Frau ≈ Königin. Die Beziehungen zwischen Begriffen werden zu Vektor-Arithmetik.

Wie misst man dann „nah dran”? Fast immer per Cosinus-Ähnlichkeit — vereinfacht: in welchem Winkel zeigen die zwei Vektoren? Selbe Richtung (Winkel ≈ 0) → Ähnlichkeit nahe 1. Senkrecht → 0. Gegenüber → −1.

Das macht den Trick komplett: „Hund frisst Knochen” und „Der Welpe nagt am Schinken” landen nah beieinander, obwohl kein einziges Wort übereinstimmt. Das Modell hat im Training gelernt, was inhaltlich zusammengehört — nicht, was textuell gleich aussieht. Genau deshalb funktioniert RAG auch dann, wenn deine Frage ganz anders formuliert ist als die Antwort im Dokument.

Niemand versteht endgültig, warum das so gut klappt — die Forschung daran heißt mechanistic interpretability und ist ein eigenes Feld. Aber für RAG reicht: ähnlicher Inhalt → ähnliche Zahlen. Mehr musst du nicht im Kopf haben.

So sieht der ganze Flow aus

Damit haben wir alle Teile beisammen — jetzt der Zusammenbau. RAG läuft immer in zwei Phasen: einmal beim Vorbereiten der Daten (Ingest) und jedes Mal beim Beantworten einer Frage (Retrieval + Generation).

Phase 1 baust du einmal auf und aktualisierst sie, wenn sich Dokumente ändern. Phase 2 läuft bei jeder einzelnen Frage — komplett unsichtbar, in Bruchteilen einer Sekunde. Für den Nutzer fühlt es sich an, als hätte das Modell dein Wiki im Kopf. Hat es nicht. Es kriegt die richtigen drei Seiten daraus jedes Mal frisch auf den Tisch gelegt.

“

RAG ersetzt kein Training. Es ist der Spickzettel, der vor der Antwort auf den Tisch wandert.

Daniel Schmilinski

Was RAG nicht kann

So weit, so clever. Jetzt das ehrliche Teil — denn RAG wird gerade gefühlt für alles in den Mund genommen, und das ist halt nicht ganz fair.

RAG ist passives Lesen. Das Modell kann auf Basis deiner Doku antworten, kommentieren, zusammenfassen. Es kann damit aber nichts tun. Es kann keinen Lead in Pipedrive anlegen, kein Ticket in Linear öffnen, keinen Pull Request in GitHub kommentieren. Für Aktionen in echten Systemen brauchst du ein anderes Werkzeug — und genau da kommen MCP-Server ins Spiel.

RAG ist nur so gut wie deine Datenbasis. Wenn dein Onboarding-Doc von 2022 ist und nie aktualisiert wurde, antwortet die KI auch 2026 noch mit dem alten Prozess. Garbage in, garbage out — und im RAG-Kontext heißt das ganz konkret: dein Update-Prozess für die Vektordatenbank muss sitzen. Sonst bekommst du selbstbewusst formulierte Antworten auf Basis veralteter Quellen, was schlimmer ist als gar keine Antwort.

Und Chunking ist die unterschätzte Disziplin. Wie du deine Dokumente in Stücke zerlegst, bevor du sie embeddest, entscheidet über die Qualität fast aller späteren Antworten. Schneidest du mitten durch einen Gedanken, geht der Kontext verloren. Machst du die Stücke zu groß, holst du zu viel Beifang. Macht du sie zu klein, fehlt das Drumherum. Das ist kein „einmal einstellen, läuft” — das ist eine eigene kleine Wissenschaft.

RAG oder MCP — wann was?

Das werd ich am häufigsten gefragt, also kurz und sortiert. Beide Werkzeuge lösen unterschiedliche Probleme, und in der Praxis kombiniert man sie sehr oft.

Wofür	RAG	MCP-Server
Doku oder Wiki durchsuchen	Ja — genau das Werkzeug	Geht prinzipiell, aber Overkill
In echten Systemen handeln	Nein, RAG kann nur lesen	Ja — Tools rufen, Aktionen auslösen
Echtzeit-Daten aus APIs	Nein, Daten müssen vorher in der Vektor-DB liegen	Ja — frische Abfrage bei jeder Anfrage
Stabilität & Versionierung	Du kontrollierst die Quelle	Hängt am angebundenen System
Aufwand erster Aufbau	Mittel: Ingest-Pipeline + DB	Niedrig: ein kleines Programm pro System

In den meisten ernsten Setups laufen beide nebeneinander. Die KI nutzt RAG, um zu wissen, was Sache ist (Doku, Wiki, alte Tickets), und MCP-Server, um etwas zu tun (in Pipedrive den Lead anlegen, in Slack die Nachricht schicken, in GitHub den PR kommentieren). Das eine ist das Gehirn, das andere die Hände.

Fazit

RAG klingt nach Magie, ist aber eine richtig gut durchdachte Such-vor-dem-Antworten-Mechanik. Du baust einmal eine Pipeline, die deine Dokumente in eine Vektordatenbank kippt. Du baust einen zweiten Mechanismus, der bei jeder Frage die passenden Stücke rausholt und ins Modell legt. Embeddings sind die Mathematik dahinter, die „inhaltlich ähnlich” maschinell auffindbar macht.

Was sich wirklich verschoben hat in den letzten zwei Jahren, ist nicht RAG selbst — die Idee ist älter. Es ist, dass die Bausteine drumherum (Embedding-Modelle, Vektordatenbanken, fertige Frameworks wie LangChain oder LlamaIndex) so gut geworden sind, dass ein erster brauchbarer RAG-Aufbau ein Tagesprojekt ist und kein Quartal mehr.

Und ich glaube, das ist der eigentliche Punkt: KI ans Firmenwissen anzuschließen war jahrelang ein riesiges Trainings-Projekt. Heute ist es einmal eine Pipeline aufsetzen und gut. Den Rest macht das Modell.