Was ist RAG (Retrieval-Augmented Generation)

Hinweis: Dieses Dokument ist eine automatische Übersetzung des englischen Originals.

Was ist RAG (Retrieval-Augmented Generation)

Stell dir einen Studenten vor, der eine Open-Book-Prüfung ablegt. Anstatt jede Frage allein aus dem Gedächtnis zu beantworten, blättert der Student durch ein Lehrbuch, findet die relevantesten Seiten, liest sie und schreibt dann eine Antwort, die erinnertes Wissen mit frisch nachgeschlagenen Fakten kombiniert. Retrieval-Augmented Generation (RAG) funktioniert für ein großes Sprachmodell genauso. Das Modell verlässt sich nicht ausschließlich auf das, was es während des Trainings memoriert hat — es durchsucht zunächst eine externe Wissensbasis, ruft die relevantesten Dokumente ab und nutzt sie als zusätzlichen Kontext bei der Generierung seiner Antwort.

Diese Technik ist wichtig, weil selbst die leistungsstärksten LLMs ein Wissens-Stichtagsdatum haben, „halluzinieren“ können (plausible, aber falsche Aussagen erzeugen) und spezialisiertes Domänenwissen vermissen lassen können. RAG adressiert alle drei Schwächen auf einmal, indem es dem Modell jedes Mal, wenn es eine Frage beantwortet, Zugriff auf aktuelle, domänenspezifische, überprüfbare Quellen gibt.

Kurz gesagt: RAG ist ein Architekturmuster, das ein Retrieval-System mit einem LLM kombiniert. Es ist kein separater Modelltyp — es ist eine Art, mit externem Wissen und Kontext zu arbeiten.

Wie es funktioniert

Eine RAG-Pipeline folgt einer klaren fünfstufigen Sequenz. Jeden Schritt zu verstehen hilft dir zu beurteilen, ob ein Projekt, das RAG behauptet, eine wirklich funktionale Retrieval-Ebene hat oder nur einen Standard-LLM-Aufruf umhüllt.

Schritt 1 — Nutzeranfrage

Der Prozess beginnt, wenn ein Nutzer eine Frage, einen Befehl oder einen Prompt einreicht. Diese Anfrage ist der Ausgangspunkt für alles Weitere. Ein Nutzer könnte zum Beispiel fragen: „Welche wichtigen Governance-Vorschläge gab es im letzten Monat auf Ethereum?“ Das System versucht nicht, allein aus dem Gedächtnis des LLM zu antworten — stattdessen behandelt es die Anfrage als Suchanweisung.

Schritt 2 — Query-Embedding

Die rohe Textanfrage wird in eine numerische Repräsentation umgewandelt, die Embedding genannt wird — ein Vektor aus Zahlen, der die semantische Bedeutung der Anfrage erfasst. Dieser Schritt verwendet ein spezialisiertes Embedding-Modell (wie OpenAIs text-embedding-ada-002 oder eine Open-Source-Alternative wie E5 oder BGE). Der resultierende Vektor ermöglicht es dem System, eine semantische Suche durchzuführen — Dokumente nach Bedeutung statt nach exakter Schlüsselwortübereinstimmung zu finden.

Schritt 3 — Abruf aus der Wissensbasis

Das Query-Embedding wird mit einer Vektordatenbank (auch Vector Store genannt) verglichen, die vorab berechnete Embeddings von Dokumenten, Passagen oder Datenblöcken enthält. Die Datenbank gibt die top-k semantisch ähnlichsten Elemente zurück. Gängige Vektordatenbanken sind Pinecone, Weaviate, Qdrant, Milvus und Chroma.

Die Qualität des Abrufs hängt von mehreren Faktoren ab:

Chunking-Strategie — wie die Originaldokumente in kleinere Stücke aufgeteilt wurden. Chunks, die zu groß sind, verwässern die Relevanz; Chunks, die zu klein sind, verlieren Kontext. Die richtige Chunk-Größe zu finden ist eine der wirkungsvollsten Engineering-Entscheidungen in einer RAG-Pipeline.
Embedding-Modell — wie genau Bedeutung in Vektoren erfasst wird. Ein schwaches Embedding-Modell führt unabhängig von der Datenbank zu schwachem Abruf.
Relevanz-Ranking — ob die Suche wirklich relevante Ergebnisse zurückgibt oder nur oberflächlich ähnliche. Manche Systeme fügen einen Re-Ranking-Schritt hinzu, der einen Cross-Encoder nutzt, um die initialen Ergebnisse neu zu bewerten.

Schritt 4 — Kontext-Injektion

Die abgerufenen Dokumente werden mit der ursprünglichen Anfrage des Nutzers zu einem einzigen Prompt (manchmal „augmentierter Prompt“ genannt) kombiniert, der an das LLM gesendet wird. Der Prompt weist das Modell typischerweise an, die Frage anhand des bereitgestellten Kontexts zu beantworten und anzugeben, wenn der Kontext nicht genügend Informationen enthält.

Schritt 5 — LLM-Generierung und Output

Das LLM liest den augmentierten Prompt und generiert eine Antwort, die sowohl in seinem vortrainierten Wissen als auch in der abgerufenen Evidenz verankert ist. Ein gut konzipiertes RAG-System kann auch eine Zitationsebene enthalten, die Teile der Antwort mit bestimmten Quelldokumenten verknüpft und dem Nutzer eine Möglichkeit gibt, Behauptungen zu verifizieren.

Stufe	Input	Output	Schlüsselkomponente
Anfrage	Nutzertext	Rohe Anfrage	Benutzerschnittstelle
Embedding	Rohe Anfrage	Query-Vektor	Embedding-Modell
Abruf	Query-Vektor	Relevante Dokumente	Vektordatenbank
Kontext-Injektion	Anfrage + Dokumente	Augmentierter Prompt	Prompt-Vorlage
Generierung	Augmentierter Prompt	Endgültige Antwort	LLM

Warum RAG wichtig ist

RAG adressiert drei bekannte Einschränkungen eigenständiger LLMs:

Halluzinationen. LLMs können selbstbewusste, aber falsche Antworten erzeugen. RAG reduziert dies, indem es Antworten in tatsächlichen Dokumenten verankert. Wenn das Modell auf eine bestimmte Passage verweisen kann, sinkt das Risiko von Erfindungen erheblich.
Veraltetes Wissen. Ein vortrainiertes Modell hat ein Wissens-Stichtagsdatum. RAG ermöglicht den Zugriff auf frische, kontinuierlich aktualisierte Daten — eine externe Datenbank kann täglich oder sogar in Echtzeit aufgefrischt werden.
Domänenspezifität. Ein LLM für eine enge Domäne feinzujustieren ist teuer und zeitaufwendig. RAG lässt ein universelles Modell mit spezialisierten Wissensbasen arbeiten, ohne es nachzutrainieren, was das Deployment domänenspezifischer Anwendungen schneller und günstiger macht.

RAG vs. Fine-Tuning

Sowohl RAG als auch Fine-Tuning zielen darauf ab, die Leistung eines LLM bei spezifischen Aufgaben zu verbessern, aber sie funktionieren auf grundlegend verschiedene Weise.

Aspekt	RAG	Fine-Tuning
Wann Wissen hinzugefügt wird	Zur Inferenzzeit (jede Anfrage)	Zur Trainingszeit (einmal, dann statisch)
Aktualisierungskosten	Niedrig — die Wissensbasis aktualisieren	Hoch — das Modell neu trainieren oder neu feinjustieren
Wissensaktualität	Kann nahezu in Echtzeit sein	Eingefroren zum Trainings-Stichtag
Erfordert Trainingsinfrastruktur	Nein	Ja (GPUs, Datensätze, Trainings-Pipeline)
Am besten geeignet für	Faktenabruf, Dokumentations-Q&A	Stil, Ton, Format, Optimierung enger Aufgaben
Auditierbarkeit	Hoch — abgerufene Quellen können protokolliert werden	Niedrig — Wissen ist in Gewichten eingebettet

In der Praxis kombinieren viele Produktionssysteme beides: Ein feinjustiertes Modell liefert den richtigen Ton und das richtige Aufgabenverhalten, während RAG aktuelle faktische Verankerung liefert.

Fortgeschrittene RAG-Muster

Die oben beschriebene grundlegende fünfstufige Pipeline wird manchmal naives RAG genannt. Mit der Reifung der Technik haben Ingenieure ausgefeiltere Varianten entwickelt:

Mehrstufiges (iteratives) RAG. Anstatt einmal abzurufen, ruft das System ab, generiert eine Zwischenantwort, identifiziert Wissenslücken, ruft erneut mit einer verfeinerten Anfrage ab und wiederholt dies, bis die Antwort hinreichend vollständig ist. Dieser Ansatz bewältigt komplexe Fragen, die nicht aus einem einzigen Abrufdurchlauf beantwortet werden können.
Agentisches RAG. Der Abrufschritt wird in ein KI-Agenten-Framework eingebettet. Der Agent entscheidet, wann abgerufen wird, welche Wissensbasis abgefragt wird, ob die Anfrage neu formuliert wird und wann er genug Kontext hat, um eine endgültige Antwort zu generieren. Dieses Muster verwischt die Grenze zwischen RAG und autonomen Agenten.
Hybride Suche. Das Kombinieren vektorbasierter semantischer Suche mit traditioneller Schlüsselwortsuche (BM25) im selben Abrufschritt. Hybride Suche erfasst sowohl bedeutungsbasierte als auch begriffsbasierte Treffer und verbessert den Recall für Anfragen, die spezifische Fachbegriffe oder Eigennamen enthalten.
Graph-RAG. Anstelle flacher Dokument-Chunks ist die Wissensbasis als Wissensgraph strukturiert — Entitäten und Beziehungen. Der Abruf folgt Graphkanten statt (oder zusätzlich zu) Vektorähnlichkeit und ermöglicht Multi-Hop-Reasoning über strukturierte Daten. Diese Muster sind für die Bewertung wichtig: Ein Projekt, das eine Graph-RAG-Pipeline mit iterativem Abruf beschreibt, macht eine spezifischere (und schwerer zu fälschende) Behauptung als eines, das einfach sagt „wir nutzen RAG“.

Reale Beispiele für RAG

RAG ist kein theoretisches Konzept — es treibt einige der heute am weitesten verbreiteten KI-Produkte an.

Bing Chat (Microsoft Copilot). Wenn du Bing Chat eine Frage stellst, durchsucht es das Web, ruft relevante Seiten ab und nutzt diese Seiten als Kontext für die Antwort des LLM. Die Inline-Zitate, die du in der Antwort siehst, sind ein direktes Ergebnis des Abrufschritts.
Perplexity. Perplexity ist um eine RAG-Architektur herum gebaut: Jede Nutzeranfrage löst eine Websuche aus, die Ergebnisse werden einem LLM zugeführt, und die Antwort enthält nummerierte Quellenverweise. Der Nutzer kann durchklicken, um jede Behauptung zu verifizieren.
Unternehmens-Wissensassistenten. Unternehmen nutzen interne RAG-Systeme, damit Mitarbeiter HR-Richtlinien, Engineering-Dokumentation oder Rechtsverträge in natürlicher Sprache abfragen können. Die Abrufebene durchsucht den internen Dokumentenspeicher des Unternehmens statt des offenen Webs. Diese Beispiele zeigen, dass RAG eine etablierte Mainstream-Technologie ist. Wenn ein Krypto-KI-Projekt sagt „wir nutzen RAG“, ist die Frage nicht, ob RAG echte Technologie ist, sondern ob die spezifische Implementierung des Projekts solide ist: welche Daten abgerufen werden, wie sie indiziert sind und ob die Abrufqualität gemessen wurde.

Warum RAG in Krypto-KI-Projekten auftaucht

Viele Krypto-KI-Projekte nutzen RAG oder behaupten, es in ihren Architekturen zu nutzen. Gängige Anwendungsfälle umfassen:

Dokumentationsassistenten — Abrufen von Protokoll-Dokumentationen, Whitepapers oder Governance-Vorschlägen, um Nutzerfragen zu den Regeln oder Parametern eines Protokolls zu beantworten.
Krypto-Intelligence-Tools — Abrufen von Echtzeit-Marktdaten, On-Chain-Ereignissen oder Nachrichtenartikeln, um Analysezusammenfassungen oder Warnungen zu generieren.
Wissensbasen für Agenten — Aufbau strukturierter Repositories, die KI-Agenten abfragen können, bevor sie handeln, um sicherzustellen, dass Entscheidungen durch die neuesten Daten informiert sind.
On-Chain-Datenverankerung — Verbinden der Abrufebene mit Blockchain-Indexern, damit das LLM Fragen zu Wallet-Beständen, Transaktionshistorien oder Smart-Contract-Zuständen mit aktuellen Informationen statt mit Trainingszeit-Snapshots beantworten kann.

Typische AI-component-Werte in DecAIHub-Projektkarten, die RAG-Muster betreffen, umfassen: „3D AI agents (RAG/memory/LLM catalog)“, „AI summaries + crypto intelligence terminal“ und „AgentData (real-time data streams for AI agents)“.

RAG ist kein Modell

Ein verbreitetes Missverständnis ist, RAG als einen Typ von KI-Modell zu behandeln. Das ist es nicht. RAG ist ein Architekturmuster — eine Art, ein Retrieval-System mit einem LLM zu kombinieren. Das Modell innerhalb einer RAG-Pipeline kann GPT, DeepSeek, Mistral oder ein beliebiges anderes LLM sein. Die Abrufkomponente kann eine Vektordatenbank, eine Such-API oder ein strukturierter Wissensgraph sein.

„Wir nutzen RAG“ zu sagen verrät dir, wie das System organisiert ist. Es verrät dir nicht, welches Modell verwendet wird, ob es proprietär ist oder wie gut die Abrufqualität ist. Zwei Projekte können beide RAG behaupten und dabei enorm unterschiedliche Niveaus an Raffinesse aufweisen — eines mit einer sorgfältig kuratierten Wissensbasis und eigenen Embeddings, ein anderes mit einem hastig zusammengebauten Prototyp, der selten relevante Dokumente zurückgibt.

Was RAG nicht beweist

RAG zu nutzen beweist nicht, dass das zugrunde liegende LLM proprietär oder feinjustiert ist. Das Projekt ruft möglicherweise eine Drittanbieter-API auf.
Eine RAG-Pipeline zu bauen beweist nicht, dass die Abrufqualität hoch ist. Qualität hängt von der Wissensbasis, der Chunking-Strategie, dem Embedding-Modell und der Suchrelevanz ab.
Eine RAG-Architektur zu haben beweist nicht, dass die Antworten korrekt sind. Schlechter Abruf kann irrelevanten Kontext einspeisen, und das LLM kann immer noch halluzinieren.
RAG auf einer Landingpage zu erwähnen beweist nicht, dass das System tatsächlich Abruf durchführt. Ohne Tier-1-Evidenz — Code, Architekturdiagramme, Demo-Logs — bleibt die Behauptung unverifiziert. Wenn du ein Krypto-KI-Projekt bewertest, das RAG behauptet, achte auf Details: welche Wissensbasis durchsucht wird, welches Embedding-Modell verwendet wird, wie Relevanz gemessen wird und ob Qualitätsmetriken veröffentlicht werden.

Wo es in DecAIHub-Projektkarten erscheint

RAG wird typischerweise im Feld AI component referenziert — entweder direkt oder über Beschreibungen, die eine Retrieval-plus-Generierungs-Pipeline implizieren. Das AI_1-Flag prüft, ob die AI component mit genügend Spezifität beschrieben ist. Einfach „RAG“ zu schreiben reicht nicht; die Karte sollte erklären, was abgerufen wird, von wo und zu welchem Zweck.

Nicht verwechseln mit

LLM — die Generierungs-Engine innerhalb einer RAG-Pipeline. RAG fügt Abruf obendrauf hinzu.
Training — RAG ist ein Muster zur Inferenzzeit. Es trainiert das Modell nicht neu; es augmentiert den Prompt mit abgerufenem Kontext.
KI-Agent — ein Agent kann RAG als eines seiner Werkzeuge nutzen, aber RAG allein macht ein System nicht zu einem Agenten.
Fine-Tuning — Fine-Tuning passt Modellgewichte während einer Trainingsphase an. RAG injiziert externes Wissen zur Inferenzzeit, ohne das Modell zu verändern.
Retrieval / Wissensebene — die Abrufkomponente ist die eine Hälfte von RAG. RAG fügt den Generierungsschritt obendrauf auf reinen Abruf hinzu.

Häufig gestellte Fragen

Was ist der Unterschied zwischen RAG und Fine-Tuning?

Fine-Tuning verändert die Gewichte des Modells dauerhaft, indem es auf einem spezialisierten Datensatz trainiert wird. Das neue Wissen wird Teil des Modells selbst. RAG lässt das Modell unangetastet und liefert stattdessen relevante Dokumente zur Anfragezeit. Fine-Tuning ist besser, um einem Modell einen neuen Stil oder ein neues Aufgabenformat beizubringen; RAG ist besser, um Antworten in frischen, überprüfbaren Fakten zu verankern. Viele Produktionssysteme nutzen beides — das feinjustierte Modell handhabt Ton und Format, während RAG aktuelle faktische Verankerung liefert.

Macht RAG LLMs genauer?

RAG kann Halluzinationen erheblich reduzieren, indem es den Output des Modells in abgerufener Evidenz verankert. Die Genauigkeit hängt jedoch von der Abrufqualität ab. Wenn das Retrieval-System irrelevante oder veraltete Dokumente zurückgibt, kann das LLM Antworten produzieren, die selbstbewusst falsch sind — nun gestützt durch die falsche Evidenz. RAG hebt die Obergrenze für Genauigkeit, garantiert sie aber nicht. Das Messen von Abruf-Precision und -Recall ist für jeden ernsthaften RAG-Einsatz unerlässlich.

Was ist eine Vektordatenbank?

Eine Vektordatenbank ist ein spezialisierter Datenspeicher, der dafür konzipiert ist, hochdimensionale numerische Vektoren (Embeddings) zu halten und zu durchsuchen. Wenn ein Query-Embedding eingereicht wird, führt die Datenbank eine Ähnlichkeitssuche durch — typischerweise mit Algorithmen wie HNSW oder IVF — um die am nächsten passenden Vektoren zu finden. Dies ermöglicht semantische Suche: Dokumente nach Bedeutung statt nach exakter Schlüsselwortübereinstimmung zu finden. Beliebte Vektordatenbanken sind Pinecone, Weaviate, Qdrant, Milvus und Chroma.

Wie wird RAG in Krypto-KI-Projekten genutzt?

Krypto-KI-Projekte nutzen RAG, um LLMs mit blockchainspezifischen Daten zu verbinden: Protokoll-Dokumentation, Governance-Vorschläge, On-Chain-Transaktionshistorien, Echtzeit-Preis-Feeds und Smart-Contract-Quellcode. Die Abrufebene durchsucht diese spezialisierten Quellen, damit das LLM domänenspezifische Fragen mit aktuellen Daten beantworten kann, statt sich auf veraltetes Trainingswissen zu verlassen. Die Qualität solcher Systeme variiert stark — von gut indizierten, kuratierten Wissensbasen bis hin zu minimalen Setups, die wenig nützlichen Kontext abrufen.

Kann RAG mit On-Chain-Daten arbeiten?

Ja. Die Abrufebene in einer RAG-Pipeline kann sich mit Blockchain-Indexern, Subgraphs oder On-Chain-Analytics-APIs verbinden. Wenn ein Nutzer nach einem Wallet-Bestand, einer Transaktionshistorie oder einem Smart-Contract-Zustand fragt, holt das Retrieval-System die relevanten On-Chain-Daten, und das LLM generiert eine für Menschen lesbare Erklärung. Die Hauptherausforderungen sind Latenz (Blockchain-Abfragen können langsam sein), Datenformatierung (rohe On-Chain-Daten müssen für das Embedding geparst und gechunkt werden) und Aktualität (der Index muss häufig genug aktualisiert werden, um den aktuellen Chain-Zustand widerzuspiegeln).

Siehe auch

Externe Referenzen

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview