RAG

RAG Pipeline einfach erklärt

Was ist RAG?

RAG steht für „Retrieval Augmented Generation„, auf Deutsch etwa „Antwort erstellen mit Nachschlagen“. Es ist eine Methode, mit der eine KI genauere und aktuellere Antworten geben kann, indem sie vor der Antwort erst in echten Dokumenten nachschaut, statt sich nur auf ihr antrainiertes Wissen zu verlassen.

Welches Grundproblem löst RAG

Eine normale KI hat ihr Wissen wie ein Mensch im Kopf gespeichert, der viel gelernt hat. Das bringt zwei Schwächen mit sich: Sie kann Dinge verwechseln oder erfinden, und sie kennt nichts, was nach ihrem Training passiert ist oder was nirgends öffentlich zu lesen war, etwa interne Firmendokumente.

RAG behebt beides, indem die KI bei jeder Frage zuerst eine Bibliothek durchsucht und ihre Antwort auf Basis der gefundenen Texte formuliert.

Ein Alltagsbeispiel

Stell dir zwei Prüflinge vor. Der eine beantwortet Fragen nur aus dem Gedächtnis. Der andere darf ein Buch oder das Internet benutzen, schlägt kurz nach und schreibt dann die Antwort mit eigenen Worten auf. Der zweite Prüfling macht weniger Fehler und kann auch Fragen zu Dingen beantworten, die er vorher nie gelernt hat. Genau das macht eine KI mit RAG.

Wie eine RAG-Pipeline abläuft

Eine „Pipeline“ ist einfach die Kette der Arbeitsschritte, die nacheinander ablaufen, so wie an einem Fließband. Bei RAG sind das vier Schritte:

1. Frage stellen. Der Nutzer stellt eine Frage, zum Beispiel „Wie viele Urlaubstage habe ich laut Vertrag?“
2. Suchen (Retrieval). Die KI durchsucht eine Sammlung von Dokumenten, zum Beispiel den Arbeitsvertrag, und findet die Textstellen, die zur Frage passen.
3. Zusammenführen. Die gefundenen Textausschnitte werden zusammen mit der ursprünglichen Frage der KI übergeben, quasi als Spickzettel.
4. Antworten (Generation). Die KI liest den Spickzettel und formuliert daraus eine verständliche, vollständige Antwort in eigenen Worten.

Warum das nützlich ist

Mit RAG kann eine KI Fragen zu aktuellen Nachrichten, firmeninternen Unterlagen, persönlichen Dokumenten oder Fachliteratur beantworten, ohne dafür extra und aufwendig neu trainiert werden zu müssen. Es reicht, die passenden Dokumente in die durchsuchbare Bibliothek zu legen. Außerdem kann die KI angeben, aus welchem Dokument eine Antwort stammt, was die Antwort nachprüfbar macht.

Kurz zusammengefasst
RAG bedeutet: erst nachschauen, dann antworten. Die RAG-Pipeline ist der feste Ablauf aus Fragen, Suchen, Zusammenführen und Antworten, der dafür sorgt, dass die KI-Antwort auf echten, nachprüfbaren Informationen beruht statt nur auf Erinnerung.

Stufen einer RAG Pipline

Hier eine Übersicht typischer Ausbaustufen, von einer simplen Demo bis zu einem produktionsreifen System.

Stufe 1: Naives RAG

Ein Dokument wird grob in Chunks zerlegt, mit einem einzigen Embedding-Modell vektorisiert, in eine einfache Vektor-Datenbank gepackt. Bei einer Frage: Vektor-Suche, Top-Treffer direkt an das Sprachmodell. Kein Overlap, kein Re-Ranking, keine Fehlerbehandlung. Reicht für ein Wochenendprojekt oder eine erste Demo.

Stufe 2: Optimiertes Chunking

Chunk-Größe und Chunk-Overlap werden bewusst gewählt, idealerweise entlang natürlicher Grenzen wie Absätzen oder Kapiteln statt starrer Zeichenzahl. OCR-Vorverarbeitung für gescannte Dokumente kommt dazu. Die Antwortqualität steigt spürbar, ohne dass die Architektur komplizierter wird.

Stufe 3: Hybride Suche.

Semantic Search und Lexical Search (z. B. BM25) laufen parallel, ihre Ergebnisse werden kombiniert. Das fängt Schwächen der reinen Vektor-Suche ab, etwa bei exakten Fachbegriffen, Namen oder Zahlen, die semantisch leicht untergehen.

Stufe 4: Re-Ranking und Metadaten-Filter

Nach der hybriden Suche sortiert ein Re-Ranker die Treffer nach echter Relevanz neu. Zusätzlich lassen sich Metadaten nutzen, etwa nur in Dokumenten eines bestimmten Datums oder einer bestimmten Quelle zu suchen, bevor überhaupt gesucht wird.

Stufe 5: Query-Transformatio

Die ursprüngliche Frage wird vor der Suche selbst von einer KI verbessert, etwa umformuliert, in mehrere Teilfragen zerlegt, oder um Synonyme erweitert. Das hilft bei vagen oder mehrdeutigen Nutzerfragen.

Stufe 6: Agentic RAG

Das System entscheidet selbst, ob und wie oft es sucht, kann bei unzureichenden Treffern nachfassen, mehrere Wissensquellen unterschiedlich behandeln (z. B. interne Datenbank vs. Web-Suche) und Zwischenschritte planen. Nähert sich einem KI-Agenten statt einer festen Pipeline.

Stufe 7: Maximum / Produktionssystem

Alles Vorherige plus: kontinuierliche Neu-Indexierung bei Dokumentänderungen, Caching für häufige Anfragen, Evaluation/Monitoring der Antwortqualität, Absicherung gegen Falschinformationen (Zitatprüfung, Quellenangabe), Skalierung der Vektor-Datenbank auf Millionen Dokumente, Zugriffsrechte pro Dokument.

Als Faustregel für ein Schulprojekt: Stufe 1 bis 3 sind gut machbar und zeigen schon die wichtigsten Konzepte, Stufe 4 als Erweiterung ist ein sinnvolles Ziel für eine sehr gute Note.

Software-Architektur-Konzept

Vollständige RAG-Pipeline

1. Architektur-Überblick

Eine vollständige RAG-Pipeline besteht aus zwei Strängen: einem Indexierungs-Strang, der einmalig oder regelmäßig die Wissensbasis aufbereitet, und einem Anfrage-Strang, der bei jeder Nutzerfrage durchlaufen wird.

INDEXIERUNG (offline)
Dokumente -> OCR -> Chunking -> Embedding -> Vektor-Datenbank
                                              + Lexical-Index

ANFRAGE (online, pro Frage)
Nutzerfrage -> Embedding -> Hybrid-Suche (Semantic + Lexical)
            -> Re-Ranking -> Prompt-Zusammenbau -> Sprachmodell -> Antwort

Darüber liegen als Querschnittsfunktionen: Orchestrierung/Framework, API-Schicht, Frontend, Monitoring, sowie Zugriffskontrolle und Sicherheit.

2. Komponenten und Software-Optionen

2.1 Dokumenten-Einlesen (Document Loading)

Aufgabe: Rohdaten aus verschiedenen Quellen und Formaten einlesen (PDF, Word, HTML, E-Mail, Datenbank).

2.2 OCR (Texterkennung)

Aufgabe: Gescannte oder bildbasierte Dokumente in durchsuchbaren Text umwandeln.

2.3 Chunking

Aufgabe: Texte in sinnvolle, überlappende Abschnitte zerlegen.

2.4 Embedding-Modelle

Aufgabe: Text in Vektoren (Zahlen) umwandeln, die die Bedeutung abbilden.

2.5 Vektor-Datenbank

Aufgabe: Vektoren speichern und schnell durchsuchbar machen.

2.6 Lexical Search / Hybrid-Suche

Aufgabe: Exakte Stichwortsuche parallel zur Bedeutungssuche.

2.7 Re-Ranking

Aufgabe: Gefundene Treffer nach tatsächlicher Relevanz neu sortieren.

2.8 Orchestrierung / Framework

Aufgabe: Alle Bausteine (Loader, Chunking, Embedding, Suche, Prompt, Modell) zu einer Pipeline verbinden.

2.9 Sprachmodell (Generation)

Aufgabe: Aus Frage und gefundenen Textstellen die finale Antwort formulieren.

2.10 API- und Backend-Schicht

Aufgabe: Die Pipeline als Dienst bereitstellen, der von einer Anwendung angesprochen werden kann.

2.11 Frontend / Nutzeroberfläche

Aufgabe: Nutzern eine Oberfläche zum Stellen von Fragen geben.

2.12 Monitoring und Evaluation

Aufgabe: Prüfen, wie gut die Pipeline tatsächlich antwortet, und Probleme erkennen.

2.13 Deployment und Infrastruktur

Aufgabe: Die gesamte Pipeline betreiben und skalieren.

3. Auswahlkriterien

Bei jeder Komponente lohnt sich die Frage: Open Source und selbst gehostet (volle Kontrolle, aber Betriebsaufwand) oder Managed-Service/API (schneller Start, laufende Kosten, Daten verlassen die eigene Infrastruktur). Für sensible Daten empfiehlt sich tendenziell mehr Open-Source-Anteil und Selbst-Hosting.

4. Beispielhafte Gesamtkonfigurationen

Kleines Projekt / Prototyp: LangChain + Chroma (lokal) + sentence-transformers + Claude oder Mistral API + Streamlit-Oberfläche. Schnell aufgesetzt, geringe Kosten.

Mittelständisches Unternehmen: LlamaIndex + Qdrant (selbst gehostet) + Mistral Embed + Elasticsearch für Lexical Search + Cohere Rerank + Claude API + FastAPI-Backend + eigenes Frontend. Guter Kompromiss zwischen Aufwand und Kontrolle.

Hochsicherheitsumgebung (Behörde, Klinik): Vollständig selbst gehostet: eigene Dokumenten-Pipeline, sentence-transformers Embeddings, Milvus oder Qdrant on-premise, BGE Reranker, Llama- oder Mistral-Open-Weights-Modell über vLLM, alles innerhalb des eigenen Netzwerks ohne externe API-Aufrufe.