Du fragst ChatGPT nach der Urlaubsregelung deines Unternehmens und es haut dir eine perfekt formulierte Antwort raus... und die ist komplett erfunden. Das Modell hat keine Ahnung von deinem Unternehmen, sagt es aber nicht: Es füllt die Lücke mit etwas Plausiblem. Das nennen wir Halluzination, und es ist das größte Problem von Sprachmodellen, sobald man sie aus ihrer Komfortzone holt.
RAG ist die Lösung, die sich zum Standard entwickelt hat, um das zu beheben. Es ändert nicht das Modell: Es ändert seine Hausaufgaben. Statt es aus dem Gedächtnis antworten zu lassen, legst du ihm die offenen Notizen vor die Nase. Schauen wir es uns ohne Fachjargon an.
Hinweis
RAG steht für Retrieval-Augmented Generation (abrufgestützte Generierung). Die Grundidee ist alt und einfach: Bevor du antwortest, such nach. Neu ist, das mit Sprachmodellen und einer Suche nach Bedeutung zu tun, nicht nach exakten Wörtern.
Welches Problem RAG löst
Ein Sprachmodell lernt während des Trainings und wird dann „eingefroren". Ab da schleppt es drei Grenzen mit sich, die kein noch so eleganter Prompt behebt:
- Es kennt deine Daten nicht. Es hat nie dein internes Wiki gesehen, nicht deinen Produktkatalog und nicht die Verträge deiner Kunden. Es ist ein Genie, das nie einen Fuß in dein Büro gesetzt hat.
- Es hat ein Verfallsdatum. Sein Wissen endet an dem Tag, an dem sein Training abgeschlossen wurde. Was danach passiert ist, existiert für es nicht.
- Wenn es etwas nicht weiß, erfindet es. Statt „ich weiß es nicht" zu sagen, produziert es etwas, das gut klingt. Bei einem kreativen Text egal; bei einer juristischen oder medizinischen Antwort gefährlich.
RAG greift alle drei auf einen Schlag an. Du verbindest es mit einer externen Wissensbasis —deinen Dokumenten, deiner Datenbank, deinen PDFs— und das System ruft im Moment der Antwort das Relevante ab. Das Modell schöpft nicht mehr aus dem Gedächtnis, sondern aus Belegen. Die direkte Folge: weniger Halluzinationen, jederzeit aktualisierbare Daten (du änderst das Dokument, nicht das Modell) und die Möglichkeit, die Quelle jeder Antwort zu zitieren.
Die beste Analogie ist die Prüfung. Ein normales LLM schreibt die Prüfung aus dem Gedächtnis. Ein LLM mit RAG schreibt dieselbe Prüfung, aber mit offenem Buch und einer Suchmaschine, die ihm vor jeder Antwort die genaue Seite findet.
Wie der RAG-Ablauf funktioniert
Hier ist der Kern des Ganzen. Ein RAG-System ist keine Zauberei: Es sind vier verkettete Schritte, und sie zu verstehen gibt dir 80 % des Konzepts.
Wie ein RAG-System funktioniert
Ingestion
Du lädst deine Dokumente und zerlegst sie in handhabbare Fragmente (Chunking). Das ist die Vorbereitung des Buchs.
Embeddings
Jedes Fragment wird in einen Zahlenvektor umgewandelt, der seine Bedeutung erfasst, und in einer Vektordatenbank gespeichert.
Retrieval
Kommt eine Frage, wird sie genauso vektorisiert, und man sucht die nach Bedeutung ähnlichsten Fragmente, nicht nach Wörtern.
Generierung
Diese Fragmente werden zusammen mit der Frage in den Prompt eingespielt, und das Modell verfasst die Antwort, indem es sich darauf stützt.
Die ersten beiden Schritte (Ingestion und Embeddings) passieren einmal, wenn du deine Wissensbasis vorbereitest. Die letzten beiden (Retrieval und Generierung) passieren jedes Mal, wenn jemand fragt. Merk dir: Du indexierst einmal, du fragst oft ab. Sehen wir uns jeden Baustein in Ruhe an.
Die Komponenten, eine nach der anderen
Chunking: richtig zerlegen
Du kannst dem Modell kein 300-seitiges Handbuch auf einmal reinschieben: Es passt nicht in sein Kontextfenster, und selbst wenn es passte, würde es das Signal in einem Meer aus Rauschen verwässern. Deshalb ist der erste Schritt, die Dokumente in Fragmente (Chunks) zu zerlegen.
Die Größe des Stücks ist eine kritische und wenig glamouröse Entscheidung. Zu große Stücke schleusen irrelevante Information in jede Antwort; zu kleine Stücke zerreißen eine Idee in der Mitte und verlieren den Sinn. Die gute Praxis von 2026 ist, unter Wahrung der Struktur des Dokuments zu zerlegen —nach Abschnitten, Absätzen oder Überschriften— statt blind alle X Zeichen zu schneiden. Gutes Chunking verbessert die Ergebnisse oft mehr, als für das teuerste Modell zu zahlen.
Embeddings: Bedeutung in Zahlen umwandeln
Ein Embedding ist die Übersetzung eines Textes in eine Liste von Zahlen (einen Vektor), die seine Bedeutung erfasst. Das Schöne daran: Texte mit ähnlichem Sinn landen bei ähnlichen Vektoren, auch wenn sie kein einziges Wort teilen. „Wie kündige ich mein Abo" und „das Konto abmelden" landen in diesem mathematischen Raum nah beieinander.
Das ist es, was die Suche nach Konzept ermöglicht und nicht nach wörtlicher Übereinstimmung von Begriffen – der große Sprung gegenüber der klassischen Suchmaschine. Jedes Fragment deiner Wissensbasis wird mit einem spezialisierten Modell (von OpenAI, Cohere oder einem Open-Source-Modell, das du selbst betreibst) in ein Embedding umgewandelt.
Vektordatenbank: das Lager mit semantischer Suche
All diese Vektoren muss man irgendwo speichern, das sie schnell durchsuchen kann. Dafür gibt es die Vektordatenbank: ein Lager, das darauf optimiert ist, unter Millionen von Vektoren die einem gegebenen Vektor nächstgelegenen zu finden, mithilfe von Distanzmetriken wie der Kosinus-Ähnlichkeit.
Die üblichen Optionen 2026: Pinecone (gemanagt, keine Kopfschmerzen), Qdrant und Weaviate (leistungsstarke Open Source), Chroma (die einfachste zum Starten und Prototyping) und pgvector (falls du schon PostgreSQL nutzt und nicht noch einen Baustein willst). Zum Lernen reicht Chroma lokal locker; für die Produktion im großen Maßstab springt man meist zu einer gemanagten Lösung oder zu Qdrant.
Retrieval: das Relevante finden
Die Frage des Nutzers kommt an. Das System wandelt sie mit demselben Modell in ein Embedding um und bittet die Vektordatenbank um die Top-k nach Bedeutung nächstgelegenen Fragmente (typischerweise zwischen 3 und 8). Das ist das Retrieval.
Tipp
2026 ist der Flaschenhals von RAG nicht das Modell, sondern der Abruf. Wenn das System dir nicht das richtige Fragment bringt, kann dir das brillanteste LLM der Welt nicht die richtige Antwort geben: Es hat sie nicht vor sich. Deshalb mischen ernsthafte Architekturen semantische Suche mit Stichwortsuche (hybride Suche) und ordnen die Ergebnisse neu.
Generierung: mit dem Kontext vor Augen schreiben
Zuletzt werden die abgerufenen Fragmente zusammen mit der ursprünglichen Frage in den Prompt eingespielt, mit einer Anweisung wie „antworte nur mit diesem Kontext und, falls es nicht darin steht, sag es". Das Modell liest dieses Paket und verfasst eine Antwort, die auf deinen Daten fußt, nicht auf seinem Gedächtnis. Hier kannst du es zusätzlich bitten, zu zitieren, aus welchem Fragment jede Aussage stammt – das ist es, was RAG überprüfbar macht.
Beantworte die Frage des Nutzers AUSSCHLIESSLICH mit dem Kontext unten.
Wenn die Antwort nicht im Kontext steht, sag "Diese Information habe ich nicht" und erfinde sie nicht.
Zitiere in eckigen Klammern die Nummer des Fragments, das jede Aussage stützt.
Kontext:
{abgerufene_fragmente}
Frage:
{frage_des_nutzers}RAG vs. Fine-Tuning: wann was
Das ist die häufigste Verwechslung. Die Leute denken, dass man ein Modell neu trainieren muss (Fine-Tuning), damit es über ihr Unternehmen „Bescheid weiß". Fast nie ist das so. Es sind zwei Werkzeuge für unterschiedliche Probleme.
Vorteile
- Das Problem ist Wissen: es fehlen Daten oder sie sind veraltet.
- Die Information ändert sich häufig (Preise, Bestand, lebende Dokumentation).
- Du brauchst, dass das Modell private oder geschäftsspezifische Daten kennt.
- Du willst die Quelle zitieren und nachvollziehen können, woher jede Antwort kommt.
- Du willst schnell und günstig iterieren: du änderst ein Dokument, trainierst nichts nach.
Nachteile
- Das Problem ist Verhalten: inkonsistentes Format, instabiler Ton.
- Du brauchst, dass es einen ganz bestimmten Stil, eine Stimme oder Persönlichkeit annimmt.
- Du willst Antworten mit einem strukturierten, verlässlichen Ausgabeformat.
- Du willst eine Klassifizierungs- oder Regelbefolgungsaufgabe verbessern.
- Das Wissen ist stabil und ändert sich nicht jede Woche.
Die Regel, die alles zusammenfasst: Wissen, das sich ändert, gehört in den Abruf; stabiles Verhalten gehört in die Gewichte. RAG spielt dir frische Fakten ein, ohne das Modell anzutasten; Fine-Tuning formt, wie es antwortet, nicht was es weiß.
Und wenn du beides brauchst? Dann kombinierst du sie, und genau das ist 2026 der Produktionsstandard: ein leichtes Fine-Tuning (ein feiner LoRA-Adapter auf einem guten Basismodell), um Stimme und Format festzulegen, begleitet von RAG für das Wissen, das sich ändert. Die sinnvolle Reihenfolge dorthin: zuerst den Prompt ausquetschen, dann RAG hinzufügen und nur, wenn nötig, Fine-Tuning. Fang nicht mit dem Teuren an.
Tools, um dein RAG aufzubauen
Du musst die vier Bausteine nicht von Hand bauen. Das Ökosystem ist reif:
- Orchestrierungs-Frameworks. LlamaIndex ist von Grund auf für RAG gedacht: Ingestion, Indexierung und Abruf mit wenig Code und sehr guter Präzision. LangChain ist generalistischer —behandelt RAG als einen Baustein unter vielen in einem größeren System— und glänzt, wenn du komplexe Flows oder Agenten aufbaust. Ein übliches Muster 2026 ist, LlamaIndex für den Abruf und LangGraph zum Orchestrieren des Agenten zu nutzen, der ihn verwendet.
- Embedding-Modelle. Von OpenAI und Cohere, wenn du etwas Gemanagtes und Hochwertiges willst; Open-Source-Modelle, wenn du sie aus Datenschutz- oder Kostengründen lokal betreiben musst.
- Vektordatenbanken. Pinecone, Qdrant, Weaviate, Chroma oder pgvector, wie oben gesehen.
- Observability. Tools wie Langfuse oder LangSmith, um zu sehen, welche Fragmente abgerufen wurden und warum eine Antwort scheiterte. Sobald dein RAG ernst wird, ist das nicht mehr optional.
Wenn du es nur durch Ausprobieren verstehen willst, bau das Minimum: LlamaIndex + ein Embedding-Modell + Chroma lokal, mit einer Handvoll deiner PDFs. An einem Nachmittag hast du ein RAG, das gegen deine eigenen Dokumente läuft.
Typische Fehler (und wie du sie vermeidest)
- Das Modell beschuldigen, wenn der Abruf versagt. Ist die Antwort schlecht, ist der erste Schritt nicht, das LLM zu wechseln: Es ist, zu schauen, welche Fragmente abgerufen wurden. Fast immer liegt das Problem dort.
- Chunking mit dem Beil. Alle 500 Zeichen zu schneiden, ohne auf die Struktur zu achten, zerreißt Ideen in der Mitte. Zerlege nach Abschnitten und teste mehrere Größen.
- Nur auf die semantische Suche vertrauen. Bei Eigennamen, Codes oder exakten Begriffen versagt die Suche nach Bedeutung. Die hybride Suche (semantisch + Stichwörter) behebt das.
- Dem Modell nicht sagen, dass es etwas nicht wissen darf. Wenn du ihm nicht ausdrücklich die Erlaubnis gibst, „steht nicht im Kontext" zu antworten, wird es wieder erfinden. Die Anti-Halluzinations-Anweisung ist Pflicht.
- Zu viel oder zu wenig abrufen. 30 Fragmente reinzupacken verwässert das Signal und treibt die Kosten hoch; 1 reinzupacken ist zu wenig. Stell das Top-k ein und miss es.
Für wen ist RAG?
RAG ist keine akademische Spielerei: Es ist der direkteste und günstigste Weg, damit eine KI mit echten Daten über deine Sachen spricht.
Es ist etwas für dich, wenn du einen Chatbot willst, der über deine Dokumentation, deine Produkte oder deine Wissensbasis antwortet; du Informationen handhabst, die sich ändern, und nicht jedes Mal etwas nachtrainieren willst; du zitierbare und überprüfbare Antworten brauchst; oder du einen Agenten baust, der vor dem Handeln Quellen konsultieren muss.
Du brauchst es vielleicht nicht, wenn dein Problem Stil oder Format betrifft und nicht Wissen (das ist Fine-Tuning), oder wenn das, was du verlangst, locker ins Allgemeinwissen des Modells passt und weder private noch frische Daten braucht.
Die ehrliche Frage lautet nicht „RAG oder Fine-Tuning?", denn fast nie ist es das eine gegen das andere. Die Frage lautet „Ist mein Problem, dass dem Modell Daten fehlen, oder dass es sich verhält, wie ich es nicht will?". Ist es das Erste, ist RAG dein Werkzeug – und eines der wenigen, das du noch heute Nachmittag gegen deine Dokumente in Betrieb haben kannst.
