blackdark
Angewandte KIRAGretrieval augmented generationembeddingsvector databaseLLMHalluzinationen

Was ist RAG (Retrieval-Augmented Generation): der klare Guide für 2026

RAG ohne Fachchinesisch erklärt: warum es Halluzinationen reduziert, wie der Ablauf funktioniert (Chunking, Embeddings, Vektor-DB, Retrieval, Generierung), RAG vs. Fine-Tuning, Tools und typische Fehler.

Von BlackdarkAktualisiert am 8 Min. Lesezeit

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

  1. Ingestion

    Du lädst deine Dokumente und zerlegst sie in handhabbare Fragmente (Chunking). Das ist die Vorbereitung des Buchs.

  2. Embeddings

    Jedes Fragment wird in einen Zahlenvektor umgewandelt, der seine Bedeutung erfasst, und in einer Vektordatenbank gespeichert.

  3. Retrieval

    Kommt eine Frage, wird sie genauso vektorisiert, und man sucht die nach Bedeutung ähnlichsten Fragmente, nicht nach Wörtern.

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

Prompt-Vorlage für die Generierung
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.

FAQ

RAG (Retrieval-Augmented Generation, abrufgestützte Generierung) ist eine Technik, die ein Sprachmodell mit einer externen Wissensbasis verbindet. Bevor es antwortet, sucht das System die für die Frage relevantesten Fragmente aus deinen Dokumenten und übergibt sie dem Modell als Kontext. So antwortet das LLM mit deinen echten Daten statt mit dem, woran es sich aus seinem Training 'erinnert'.

Nicht vollständig, aber es reduziert sie enorm. Indem man das Modell zwingt, sich auf Fragmente aus verlässlichen Quellen zu stützen, sinkt die Wahrscheinlichkeit drastisch, dass es Daten erfindet. Außerdem lässt sich die Quelle jeder Antwort zitieren. Wenn der Abruf scheitert oder das Dokument die Antwort nicht enthält, kann das Modell trotzdem danebenliegen – deshalb ist das Design des Retrievals das Wichtigste.

RAG spielt externes Wissen im Moment der Antwort ein, ohne die Gewichte des Modells anzutasten: ideal für Informationen, die sich ändern oder privat sind. Fine-Tuning trainiert das Modell mit deinen Beispielen nach, um sein Verhalten, Format oder seinen Ton zu ändern. Faustregel: Wissen, das sich ändert, gehört ins RAG; stabiles Verhalten gehört ins Fine-Tuning. In der Produktion kombiniert man beides meist.

Drei Bausteine: ein Orchestrierungs-Framework (LlamaIndex oder LangChain), ein Embedding-Modell (von OpenAI, Cohere oder ein lokales) und eine Vektordatenbank (Pinecone, Qdrant, Weaviate, Chroma oder pgvector). Zum Lernen ist LlamaIndex mit Chroma lokal die einfachste Kombination; für die Produktion skaliert man in der Regel die Vektordatenbank.

Chunking bedeutet, deine Dokumente vor dem Vektorisieren in handhabbare Fragmente zu zerlegen. Es ist wichtig, weil es festlegt, was beim Modell ankommt: zu große Stücke verwässern den Kontext und bringen Rauschen; zu kleine Stücke verlieren den Sinn und zerreißen Ideen in der Mitte. Gutes Chunking, das die Struktur des Dokuments respektiert, verbessert die Ergebnisse oft mehr, als das Modell zu wechseln.

Teilen
Newsletter

Erhalte die nächsten Guides per E-Mail

Ideen und Ressourcen zu KI und Marketing, ohne Füllmaterial. Was funktioniert und wie du es anwendest.

Ideen und Ressourcen, kein Spam. Jederzeit abbestellbar.

Hilft dir dieser Guide?

Abonnieren