Erklärung zu RAG: Wie KI-Systeme nach Bedarf aktuelles Wissen abrufen
Erfahren Sie, wie Retrieval-Augmented Generation funktioniert – von der Aufteilung in Blöcke und Embeddings bis hin zur Vektorsuche – damit KI-Modelle Fragen beantworten können, ohne neu trainiert zu werden.
Stellen Sie sich einen KI-Assistenten vor, der seine Ausbildung bereits vor langer Zeit abgeschlossen hat.
Sie fragen ihn:
"Was steht in diesem Dokument, das ich gerade hochgeladen habe?"
Das Modell ist während seiner Ausbildung nie auf diese Datei gestoßen.
Wie könnte es also antworten?
Eine Antwort ist eine Technik namens Retrieval-Augmented Generation, meist abgekürzt als RAG.
RAG ermöglicht es einem KI-System, relevante Materialien aus externen Quellen abzurufen und diese in die von ihm generierte Antwort einzubinden.
Das Interessante daran ist:
Das Modell muss nicht jedes Mal neu trainiert werden, wenn neue Informationen auftauchen.
Betrachten wir nun, wie das funktioniert.
Das Problem: KI kann nicht alles wissen
Große Sprachmodelle lernen aus allen Daten, mit denen sie trainiert wurden.
Eine vereinfachte Darstellung dieses Prozesses sieht so aus:
Training Data
↓
Model Training
↓
Model Parameters
↓
AI Model
↓
Generate Answers
Sobald das Training abgeschlossen ist, verfügt das Modell nicht über eine automatische Möglichkeit, neue Dokumente, Webseiten, Unternehmensberichte oder private Dateien aufzunehmen, die danach entstehen.
Nehmen wir an, Sie beenden heute das Training eines Modells.
Morgen erstellt dann jemand:
new_report.pdf
Dieses PDF existierte einfach nicht, als das Modell trainiert wurde.
Wie würde das Modell also antworten:
"Welche sind die drei wichtigsten Erkenntnisse in diesem Bericht?"
Genau diese Lücke soll RAG schließen.
Was ist RAG?
RAG = Retrieval-Augmented Generation
Bereits der Name erklärt den Mechanismus:
- Retrieval → Suche nach relevanten Informationen
Anstelle des einfachen Ablaufs:
Question
↓
LLM
↓
Answer
kann man ein Pipeline wie folgt aufbauen:
Question
↓
Retrieve relevant information
↓
Add information to context
↓
LLM
↓
Answer
Diese architektonische Veränderung kann erhebliche Auswirkungen haben.
RAG gegenüber herkömmlicher KI
Ohne RAG ist der Ablauf direkt:
┌──────────────┐
Question ───→│ LLM │
└──────┬───────┘
↓
Answer
Mit eingefügtem RAG:
┌─────────────────┐
│ External Data │
│ PDFs / Docs │
│ Database / Web │
└────────┬────────┘
↓
Question → Retrieval → Relevant Context
↓
LLM
↓
Answer
Das Modell muss nicht mehr alles im Voraus auswendig lernen.
Stattdessen kann es relevanten Fakten nach Bedarf abrufen.
Wie funktioniert RAG eigentlich?
Eine Standard-RAG-Einrichtung durchläuft mehrere unterschiedliche Phasen:
Documents
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Database
↓
← User Question
↓
Query Embedding
↓
Similarity Search
↓
Relevant Chunks
↓
LLM
↓
Final Answer
Lassen Sie uns jede davon durchgehen.
Sammeln Sie Ihre Daten
Der Ausgangspunkt ist die Sammlung von Quellmaterialien. Dies kann Folgendes umfassen:
- Dateien im PDF-Format
- Dokumente, die in Word erstellt wurden
- Seiten, die von Webseiten abgerufen werden
- Akademische oder Forschungsarbeiten
- Interne Unternehmensunterlagen
- Handbücher, die ein Produkt beschreiben
- Einfache Textdateien
- Daten, die in einer Datenbank gespeichert sind
- Einträge aus einer Wissensdatenbank
Zum Beispiel stellen Sie sich einen Ordner vor, der Folgendes enthält:
company_policy.pdf
research_paper.pdf
employee_handbook.pdf
product_manual.pdf
Ein RAG-Pipeline ist in der Lage, all diese Daten zu verarbeiten.
Dokumente in Blöcke aufteilen
Es ist aufgrund von Größenbeschränkungen in der Regel nicht praktikabel, einem Modell ein ganzes Dokument auf einmal zur Verarbeitung zuzuführen.
Deshalb werden Dokumente in kleinere Einheiten aufgeteilt, die als Blöcke bezeichnet werden.
Hier ist eine einfache Darstellung:
Document
│
├── Chunk 1
├── Chunk 2
├── Chunk 3
├── Chunk 4
├── Chunk 5
└── ...
Stellen Sie sich ein 100-seitiges Dokument vor, das mehrere tausend Sätze enthält.
Anstatt bei jeder Anfrage den gesamten Text zu scannen, können Sie ihn in überschaubarere Abschnitte aufteilen:
Chunk 1 → Introduction
Chunk 2 → Architecture
Chunk 3 → Security
Chunk 4 → Performance
Chunk 5 → Limitations
Die Art und Weise, wie man Inhalte in Teile aufteilt, hängt von der Natur des Contents sowie vom zu entwickelnden Produkt ab.
Text in Embeddings umwandeln
Hier wird es wirklich interessant.
Computer können den textuellen Sinn nicht so wie Menschen erfassen, zumindest nicht von Natur aus.
Um dies zu umgehen, wird Text in numerische Vektoren umgewandelt, die Embeddings genannt werden.
Betrachten Sie folgendes Beispiel:
"Machine learning is a branch of AI"
↓
Embedding Model
↓
[0.21, -0.14, 0.73, ...]
Und ein zweiter Satz:
"Artificial intelligence includes machine learning"
↓
[0.19, -0.11, 0.70, ...]
Da diese beiden Sätze einen ähnlichen Sinn haben, liegen ihre resultierenden Vektoren im Embedding-Raum in der Regel nah beieinander.
Ungefähre Visualisierung:
AI
●
/ \
/ \
ML ● ● Robotics
\
\
Cooking ●
Ziel ist es nicht, eine wörtliche Überschneidung der Wörter zu finden.
Die Zielsetzung besteht vielmehr darin, eine semantische Ähnlichkeit – also eine Nähe in der Bedeutung – festzustellen.
Was ist semantische Suche?
Ein herkömmlicher Suchmaschinenantrieb auf Basis von Schlüsselwörtern würde eine Abfrage wie folgt behandeln:
"Auto"
und nach Dokumenten suchen, die buchstäblich das Wort Auto enthalten.
Semantische Suche hingegen versucht, zu verstehen, was die Abfrage tatsächlich bedeutet.
Zum Beispiel könnte eine Abfrage wie:
"Wie speichern Elektrofahrzeuge Energie?"
einen Abschnitt liefern, der erklärt, dass Elektrofahrzeuge auf Lithium-Ionen-Zellen angewiesen sind, um ihre elektrische Ladung zu speichern.
Die Formulierungen überschneiden sich kaum, doch die Übereinstimmung ist dennoch sinnvoll.
Das funktioniert, weil Embeddings Beziehungen in der Bedeutung kodieren und nicht nur die Rechtschreibung.
Embeddings in einer Vektordatenbank speichern
Sobald die Embeddings vorhanden sind, benötigen sie einen Speicherort.
Dafür dient eine Vektordatenbank, die folgendes enthält:
Chunk
+
Embedding
+
Metadata
Im Großen und Ganzen ist die Struktur wie folgt:
Vector Database
ID Vector Text
-------------------------------------
1 [0.21,...] Chunk A
2 [0.78,...] Chunk B
3 [0.34,...] Chunk C
4 [0.91,...] Chunk D
Wenn jemand eine Frage einreicht, durchsucht das System diese gespeicherten Vektoren, um einen passenden Kontext zu finden.
Zu den weit verbreiteten Werkzeugen für diese Art der Vektorsuche gehören:
- FAISS
- pgvector
- Pinecone
- Weaviate
- Milvus
- Chroma
Welche spezifische Datenbank man wählt, ist nicht das Wichtigste.
Wesentlich ist Folgendes:
Behalten Sie die Informationen in einer Form bei, die eine schnelle, bedeutungsbasierte Abfrage ermöglicht.
Der Benutzer stellt eine Frage
Nehmen wir an, ein Benutzer tippt Folgendes ein:
"Welche Sicherheitsmechanismen verwendet das System?"
Diese Frage wird anschließend in ihre eigene Embedding-Struktur umgewandelt.
User Question
↓
Embedding Model
↓
Query Vector
Zu diesem Zeitpunkt besitzt das System einen numerischen Fingerabdruck der Frage.
Aufsuche relevante Informationen
Der abgeleitete Abfragevektor wird dann mit jedem bereits im Datenbank gespeicherten Vektor verglichen.
Kurz gesagt:
Query
●
/ \
/ \
● ●
Relevant Relevant
Chunk Chunk
●
Unrelated
Die am besten passenden Abschnitte werden extrahiert.
Zum Beispiel, gegeben:
Question:
"What security mechanisms does the system use?"
Das System könnte Folgendes zurückgeben:
Retrieved:Chunk 17 → Authentication
Chunk 42 → Encryption
Chunk 51 → Access control
Dadurch verfügt das Modell nun über einen sinnvollen, relevanten Kontext zur Verarbeitung.
Füge die abgerufenen Informationen zum Prompt hinzu
Sobald die relevanten Abschnitte gefunden wurden, werden sie zusammen mit der ursprünglichen Frage als Kontext an das LLM übergeben.
Konzeptionell sieht die Prompt-Struktur wie folgt aus:
System Instructions
+
User Question
+
Retrieved Context
↓
LLM
↓
Answer
Zum Beispiel:
Context:
"The system uses AES-GCM encryption
for protecting stored data..."Question:"What encryption method does the
system use?"
Unter diesen Voraussetzungen könnte das Modell mit etwas wie folgendem antworten:
"Das System verwendet die AES-GCM-Verschlüsselung, um gespeicherte Daten zu schützen."
Diese Antwort basiert auf dem abgerufenen Material und hängt nicht ausschließlich davon ab, was das Modell während seiner ursprünglichen Trainierung aufgenommen hat.
Und das ist die Kernidee
Das Modell selbst hat aus diesem Austausch nicht unbedingt etwas Dauerhaftes gelernt.
S seine internen Parameter bleiben unverändert.
Stattdessen verläuft der Ablauf wie folgt:
New Information
↓
External Knowledge Store
↓
Retrieve When Needed
↓
LLM Uses Context
↓
Answer
Diese Trennung zwischen dem festen Wissen des Modells und einer austauschbaren, externen Wissensquelle ist genau das, was RAG seine Stärke verleiht.
RAG bedeutet nicht, dass die KI die Informationen gelernt hat
Dieser Unterschied ist äußerst wichtig und leicht falsch zu verstehen.
Nehmen wir an, Sie laden eine Datei wie diese hoch:
Project_Report.pdf
und der Assistent beginnt, auf dieser Grundlage Fragen zu beantworten.
Das bedeutet jedoch nicht, dass das Modell den Inhalt dieses Berichts dauerhaft in seine Gewichte aufgenommen hat.
Stattdessen ist das Dokument:
Stored externally
↓
Retrieved when relevant
↓
Provided as context
↓
Used to generate response
Eine nützliche Analogie ist ein Student, der während einer Prüfung in ein Lehrbuch schaut.
Der Student hat nicht jede einzelne Seite im Voraus auswendig gelernt.
Stattdessen verläuft der Prozess wie folgt:
Frage stellen, dann die entsprechende Seite finden, sie lesen und anschließend antworten
RAG verhält sich im Großen und Ganzen genauso.
RAG gegen Feintuning
Dieser Vergleich taucht ständig auf, daher lohnt es sich, ihn klar darzulegen.
Feintuning
Beim Feintuning werden tatsächlich die Parameter des Modells angepasst, indem das Training mit einer gezielten Menge an Beispielen fortgesetzt wird.
Konzeptionell:
Base Model
↓
Training Data
↓
Fine-Tuning
↓
Modified Model
RAG
RAG lässt das Modell im Grunde unverändert und liefert stattdessen externe Informationen, wenn eine Frage gestellt wird.
Base Model
+
External Knowledge
↓
Retrieval
↓
Context
↓
Answer
Hier ist ein vereinfachtes Vergleichsbild:
| Funktion | RAG | Detailanpassung |
|---|---|---|
| Änderung der Modellparameter | In der Regel nein | Ja |
| Externe Kenntnisse | Hervorragende Passung | Nicht so direkt |
| Aktualisierung von Kenntnissen | Dokumente oder Index aktualisieren | Kann ein Neutraining erfordern |
| Private Dokumente | Nützlich | Möglich, aber mit anderen Abwägungen |
| Stil oder Verhalten | Stärkere Anwendungsmöglichkeiten | |
| Quellenbezug | Hohes Potenzial | Nicht von vornherein garantiert |
Diese beiden Techniken sind nicht gegenseitig ausschließend; Teams können sie kombinieren.
Kann RAG das Internet nutzen?
Ja, das kann es.
Der Pool an externen Kenntnissen muss nicht in einem privaten Dokumentenspeicher gespeichert sein.
Stattdessen kann ein System Informationen aus Quellen wie folgenden abrufen:
Internet
↓
Search Engine
↓
Relevant Pages
↓
LLM
↓
Answer
Das wird wertvoll, wenn eine Frage auf aktuellem Wissen beruht.
Zum Beispiel:
"Was hat sich in der neuesten Version dieser Software geändert?"
In diesem Fall könnte das System zunächst die aktuelle Dokumentation abrufen und sie zur Formulierung der Antwort nutzen.
Trotzdem garantiert allein die Abfrage noch keine Genauigkeit.
Die abgerufte Quelle muss weiterhin zuverlässig und tatsächlich relevant für die Frage sein.
RAG für eigene Dokumente
Eine der praktischsten Anwendungen dieses Musters ist es, Ihnen zu ermöglichen, direkt mit Ihren eigenen Dateien zu kommunizieren.
Stellen Sie sich einen Ordner vor, der beispielsweise Folgendes enthält:
Research/
│
├── paper1.pdf
├── paper2.pdf
├── dataset_notes.pdf
├── experiment_results.pdf
└── thesis.pdf
Eine auf RAG basierende Lösung würde es Ihnen ermöglichen, Fragen wie diese zu stellen:
"Welche Hauptbeschränkungen wurden in den Experimenten festgestellt?"
Der Ablauf sieht dann so aus:
Your Documents
↓
Extract Text
↓
Chunk Documents
↓
Create Embeddings
↓
Vector Database
↓
Question
↓
Semantic Search
↓
Relevant Sections
↓
LLM
↓
Answer
Deshalb ist RAG gerade für Forschungsworkflows und unternehmensweite Wissenssysteme so wertvoll geworden.
RAG in praktischen Anwendungen
Dieses Muster kommt in einer Vielzahl von Systemen vor.
Kundenservice
Customer Question
↓
Product Documentation
↓
Retrieve Relevant Section
↓
AI
↓
Response
Bildung
Student Question
↓
Course Materials
↓
Relevant Concepts
↓
AI Tutor
↓
Explanation
Forschung
Research Question
↓
Research Papers
↓
Relevant Sections
↓
AI
↓
Summary
Unternehmenswissen
Employee Question
↓
Internal Documents
↓
Retrieve Policy
↓
AI
↓
Answer
RAG beseitigt Halluzinationen nicht vollständig
Dieser Punkt verdient besondere Betonung.
Man könnte annehmen:
„Wenn ich RAG verwende, wird die KI niemals Halluzinationen haben.“
Das ist nicht ganz richtig.
RAG kann bestimmte Arten von unbegründeten Antworten verringern, aber es beseitigt das Problem nicht vollständig.
Zum Beispiel:
Bad Retrieval
↓
Wrong Context
↓
LLM
↓
Wrong Answer
Es gibt auch mehrere andere Möglichkeiten, warum etwas schiefgehen kann:
- Blöcke, die auf eine Weise geteilt wurden, dass ihre Bedeutung verloren geht
- Relevante Fakten, die einfach nicht im Quellmaterial enthalten sind
- Ausgegebene Abschnitte, die tatsächlich nichts mit der Frage zu tun haben
- Dokumente, die veraltet oder nicht mehr aktuell sind
- Quelldateien, die von Anfang an falsch oder unpassend waren
- Zu viel Kontext, der auf einmal in die Anfrage gepackt wird
- Das Modell selbst, das trotz guter Eingabedaten falsch reasoningt
Deshalb benötigt ein solides RAG-System mehr als nur eine Vektordatenbank dahinter.
Bewertung eines RAG-Systems
Man kann einen RAG-Pipeline auf mehreren verschiedenen Ebenen bewerten.
Qualität der Informationsabrufung
Hat das System die richtigen Informationen abgerufen?
Question
↓
Retrieved chunks
↓
Are they relevant?
Qualität der Generierung
Hat das Modell tatsächlich gut von den abgerufenen Informationen Gebrauch gemacht?
Retrieved Context
↓
Generated Answer
↓
Is the answer supported?
End-to-End-Qualität
Beantwortet die gesamte Pipeline zusammen richtig die Frage des Benutzers?
Question
↓
Retrieval
↓
Context
↓
Generation
↓
Final Answer
Es ist möglich, dass das System versagt, selbst wenn das zugrunde liegende LLM hervorragend ist.
Zum Beispiel:
Falls bei der Informationsabrufung das falsche Dokument angezeigt wird, kann selbst ein sehr leistungsstarkes Modell zu einer falschen Antwort kommen.
Die Mathematik hinter Embeddings
Embeddings ermöglichen es, Informationen mithilfe von Mathematik zu vergleichen.
Eine weit verbreitete Maßzahl für Ähnlichkeit ist die Kosinusähnlichkeit.
Für zwei Vektoren A und B wird die Kosinusähnlichkeit als das Skalarprodukt von A und B geteilt durch das Produkt ihrer Längen berechnet.
Der resultierende Wert zeigt an, wie stark die beiden Vektoren in ihrer Richtung übereinstimmen.
Einfach ausgedrückt:
High similarity
↓
Vectors point in similar directions
↓
Likely related meaning
Das gibt RAG eine konkrete mathematische Methode, um Informationen zu finden, die semantisch mit einer Anfrage verbunden sind.
RAG ist wie das Bereitstellen einer Bibliothek für KI
Vielleicht ist dies die klarste Art, sich das vorzustellen.
Bilden Sie sich eine KI als einen sehr fähigen Schüler vor.
Ohne RAG:
Student
↓
Uses what they already remember
↓
Answer
Mit RAG:
Student
↓
Goes to library
↓
Finds relevant book
↓
Reads relevant pages
↓
Answers question
Das grundlegende Wissen und die Denkfähigkeit des Schülers haben sich nicht geändert.
Was sich geändert hat, sind die Informationen, die dem Schüler zum jeweiligen Zeitpunkt zur Verfügung stehen.
Das ist im Grunde die ganze Idee hinter RAG.
Wohin RAG entwickelt sich
RAG-Systeme werden stetig anspruchsvoller.
Zukünftige Implementierungen könnten Folgendes kombinieren:
User Question
↓
Query Understanding
↓
Multiple Retrieval Sources
↓
Document Ranking
↓
Reasoning
↓
Tool Use
↓
Verification
↓
Answer + Evidence
Anstatt aus einem einzigen Dokument zu ziehen, könnte ein System in mehreren Quellen suchen:
PDFs
+
Database
+
Website
+
API
+
Company Knowledge Base
Die relevanten Teile werden anschließend miteinander kombiniert.
Dadurch entwickelt sich RAG zu einer umfassenderen Architektur für Wissen und logisches Denken bei KI-Agenten – nicht nur zu einem Retrieval-Trick.
Das größere Bild
RAG stellt einen bedeutenden Wandel in der Art und Weise dar, wie wir über das Wissen von KI denken.
Das alte Modell war:
Train AI
↓
Put knowledge into model
↓
Ask questions
Der neuere Ansatz sieht eher so aus:
Train AI
↓
Keep knowledge externally
↓
Retrieve relevant information
↓
Reason over it
↓
Generate answer
Die Trennung der Modellintelligenz von externem Wissen erweist sich als äußerst mächtig.
Das Modell muss nicht mehr alle Fakten intern speichern.
Stattdessen muss es lernen, wie man Informationen effektiv nutzt, sobald man darauf zugreifen kann.
Letzter Gedanke
Möglicherweise dreht sich die Zukunft der KI nicht darum, ein Modell zu entwickeln, das alles Wissenswerte auswendig gelernt hat.
Möglicherweise geht es stattdessen darum, ein Modell zu schaffen, das herausfinden kann, was es nachschlagen muss, die richtige Quelle finden, dieses Material sinnvoll nutzen und überprüfen kann, ob die Antwort zutrifft.
Deshalb lohnt es sich, RAG genauer zu betrachten.
AI Model
+
External Knowledge
+
Retrieval
+
Reasoning
+
Verification
↓
More Useful AI
Das weist auf eine größere Idee hin: Die klügste KI ist vielleicht nicht die, die alles weiß. Vielmehr könnte sie die sein, die weiß, wie man das findet, was man braucht.
Zusätzliche Lektüre
- Agentic AI Explained: Von Sprachmodellen zu autonomen Agenten — Eine strukturierte Erklärung, wie LLMs durch Werkzeuge, Speicherfunktionen, Planung, mehragentige Architekturen und MCP-Integration zu agierenden Systemen werden.