RAG-Pipeline aufbauen: Schritt-für-Schritt-Anleitung

RAG-Pipeline aufbauen: Schritt-für-Schritt-Anleitung

Sie wollen eine RAG-Pipeline aufbauen, die in der Produktion funktioniert -- nicht nur als Demo? Dann brauchen Sie mehr als ein LLM und eine Vektordatenbank. Sie brauchen eine durchdachte Architektur, die Ihre internen Dokumente, Produktdatenbanken und Wissensspeicher zuverlässig durchsucht und dem Sprachmodell genau den Kontext liefert, der für fundierte Antworten nötig ist.

Diese Schritt-für-Schritt-Anleitung führt Sie durch den gesamten Prozess: von der Architekturplanung über Chunking-Strategien und Embedding-Modelle bis zu Retrieval, Evaluation und Produktivbetrieb. Jeder Schritt enthält konkrete Empfehlungen, Vergleichstabellen und die häufigsten Fehler, die wir aus der Projektarbeit bei IJONIS kennen.

Kurzfassung: RAG-Systeme verbinden Ihre internen Datenquellen mit großen Sprachmodellen, damit KI-Antworten auf echtem Unternehmenswissen basieren statt auf Halluzinationen. Diese Anleitung zeigt in sieben Schritten, wie Sie eine produktionsreife Pipeline aufbauen -- von der Architektur bis zum laufenden Betrieb.

Was genau ist Retrieval-Augmented Generation und wie funktioniert es?

RAG kombiniert zwei Fähigkeiten: die gezielte Suche in einer Wissensbasis (Information Retrieval) und die Antwortgenerierung durch ein großes Sprachmodell (Text Generation). Das Konzept wurde erstmals im ursprünglichen RAG-Paper von Lewis et al. beschrieben. Statt das Modell mit allen Unternehmensdaten zu finetunen, wird relevanter Kontext zur Laufzeit abgerufen und in den Prompt injiziert.

Warum RAG und nicht Finetuning?

Finetuning hat seinen Platz -- etwa für domänenspezifische Sprachstile oder spezialisierte Aufgaben. Für den Zugriff auf aktuelle, unternehmensinterne Wissensbestände ist RAG die pragmatischere und kosteneffizientere Lösung.

„Die meisten Unternehmen scheitern nicht an der KI selbst, sondern daran, ihre eigenen Daten zugänglich zu machen. RAG löst genau dieses Problem -- ohne monatelanges Finetuning." — Jamin Mahmood-Wiebe, Gründer von IJONIS

Schritt 1: Wie plane ich die Architektur meiner RAG-Pipeline?

Ein produktives System zur kontextbasierten Antwortgenerierung besteht aus zwei Pipelines: der Indexierungspipeline (Daten vorbereiten) und der Abruf-Pipeline (Daten suchen und Antwort generieren). Entscheidend ist: Beide Pipelines müssen von Anfang an aufeinander abgestimmt sein, damit die Qualität im Zusammenspiel stimmt.

Indexierungspipeline

Die Indexierungspipeline bereitet Ihre Unternehmensdaten für die semantische Suche vor:

1. Datenquellen anbinden: Dokumente, Datenbanken, Confluence-Seiten, E-Mails, CRM-Einträge -- alles, was relevantes Wissen enthält.
2. Parsing und Extraktion: PDFs, DOCX, HTML, Markdown in reinen Text umwandeln. Tabellen, Bilder und strukturierte Daten gesondert behandeln.
3. Chunking: Den Text in semantisch sinnvolle Abschnitte zerlegen (mehr dazu im nächsten Abschnitt).
4. Embedding: Jeden Chunk in einen Vektor umwandeln, der seine semantische Bedeutung kodiert.
5. Speicherung: Vektoren und Metadaten in einer Vektordatenbank ablegen.

Retrieval-Pipeline

Wenn ein Nutzer eine Frage stellt, arbeitet die Retrieval-Pipeline:

1. Query-Verarbeitung: Die Nutzerfrage wird in einen Vektor umgewandelt (mit demselben Embedding-Modell wie bei der Indexierung).
2. Semantische Suche: Die Vektordatenbank findet die ähnlichsten Chunks zur Anfrage.
3. Re-Ranking: Optional werden die Ergebnisse durch ein Cross-Encoder-Modell neu sortiert, um die Relevanz zu erhöhen.
4. Prompt-Assembly: Die gefundenen Chunks werden zusammen mit der Nutzerfrage in einen Prompt verpackt.
5. LLM-Inferenz: Das LLM generiert die Antwort basierend auf dem bereitgestellten Kontext.
6. Quellenangabe: Die Antwort enthält Referenzen zu den Quelldokumenten.

Schritt 2: Welche Chunking-Strategie liefert die besten Ergebnisse?

Die Art, wie Sie Ihre Dokumente in Textabschnitte zerlegen, bestimmt maßgeblich die Qualität Ihres Systems. Zusammengefasst: Zu große Abschnitte verwässern die Relevanz der Suchergebnisse, zu kleine verlieren den nötigen Zusammenhang. Die richtige Balance zu finden, ist eine der einflussreichsten Stellschrauben im gesamten Aufbau.

Naive vs. fortgeschrittene Chunking-Strategien

Unsere Empfehlung

Für die meisten Unternehmensanwendungen ist Recursive Character Splitting mit Overlap der beste Einstieg. Konfigurieren Sie:

• Chunk-Size: 512--1024 Token (abhängig vom Embedding-Modell)
• Overlap: 10--20% (verhindert, dass Kontext an Chunk-Grenzen verloren geht)
• Trennzeichen-Hierarchie: \n\n (Absatz) dann \n (Zeile) dann . (Satz) dann (Wort)

Für technische Dokumentation oder stark strukturierte Inhalte lohnt sich der Umstieg auf Document-Structure Chunking, das Überschriften und Abschnittsgrenzen respektiert.

Schritt 3: Welches Embedding-Modell passt zu meinem Anwendungsfall?

Das Embedding-Modell übersetzt Text in numerische Vektoren, die semantische Bedeutung kodieren. Die Wahl des Modells beeinflusst direkt, wie präzise Ihr System relevante Dokumente findet -- und ob es auch sprachübergreifend funktioniert.

Auswahlkriterien

• Dimensionalität: Mehr Dimensionen erfassen feinere Nuancen, brauchen aber mehr Speicher. 768--1536 Dimensionen sind typisch.
• Mehrsprachigkeit: Für deutsche Unternehmen unverzichtbar. Modelle wie multilingual-e5-large oder text-embedding-3-large (OpenAI) unterstützen Deutsch nativ.
• Max Token-Länge: Bestimmt die maximale Chunk-Grösse. Die meisten Modelle unterstützen 512 Token, neuere bis 8192.
• Retrieval-Benchmarks: Prüfen Sie die Performance auf MTEB (Massive Text Embedding Benchmark) für Ihren Use Case.

Modell-Vergleich

Für DSGVO-sensible Anwendungen ist Self-Hosting entscheidend. Modelle wie multilingual-e5-large oder BGE-M3 laufen problemlos auf einer einzelnen GPU und liefern exzellente Ergebnisse für deutschsprachige Inhalte. Mehr zum Thema DSGVO-konforme KI-Infrastruktur finden Sie in unserem Artikel zu On-Premise-LLMs und DSGVO.

Welche Vektordatenbank eignet sich für den Unternehmenseinsatz?

Die Vektordatenbank speichert Ihre erzeugten Vektoren und ermöglicht schnelle Ähnlichkeitssuchen zur Laufzeit. Die wichtigste Erkenntnis: Die Auswahl hängt weniger von der Technologie selbst ab als von Ihren konkreten Anforderungen an Skalierung, Datenschutz und bestehende Infrastruktur.

Vergleich der gängigen Optionen

Unsere Einschätzung

Wenn Sie bereits PostgreSQL einsetzen, starten Sie mit pgvector. Es ist kein separater Service, integriert sich nahtlos und reicht für die meisten Unternehmensanwendungen. Sobald Sie Millionen von Vektoren verwalten oder Sub-Millisekunden-Latenz brauchen, lohnt der Wechsel zu Qdrant oder Milvus.

Die Daten-Infrastruktur ist das Fundament jedes RAG-Systems. Ohne saubere Pipelines, die Ihre Datenquellen zuverlässig in die Vektordatenbank speisen, wird auch die beste Retrieval-Strategie scheitern.

Wie verbessere ich die Abrufqualität über einfache Vektorsuche hinaus?

Die einfachste Suchstrategie ist "Top-K Similarity Search": Die k ähnlichsten Vektoren zur Anfrage abrufen. In der Praxis reicht das selten aus, weil thematisch ähnliche Ergebnisse nicht immer inhaltlich die richtige Antwort liefern. Fortgeschrittene Strategien verbessern die Qualität daher erheblich.

Naive RAG vs. Advanced RAG

Schlüsseltechniken im Detail

Query Rewriting: Die Nutzerfrage wird vom LLM umformuliert, um bessere Suchergebnisse zu erzielen. Beispiel: "Wie war der Umsatz?" wird zu "Umsatzentwicklung Q4 2025 im Vergleich zum Vorjahr".

HyDE (Hypothetical Document Embeddings): Das LLM generiert ein hypothetisches Antwortdokument, dessen Embedding für die Suche verwendet wird. Funktioniert besonders gut bei abstrakten Fragen.

Hybrid-Suche: Kombination aus semantischer Vektor-Suche und keyword-basierter BM25-Suche. Fängt Fälle ab, in denen exakte Begriffe (Produktnamen, Artikelnummern) gefragt sind.

Cross-Encoder Re-Ranking: Nach der initialen Suche bewertet ein Cross-Encoder-Modell jedes Dokument-Query-Paar einzeln. Deutlich genauer als Bi-Encoder-Ähnlichkeit, aber langsamer. Wird typischerweise auf die Top-20-Ergebnisse angewendet.

Contextual Compression: Irrelevante Teile der abgerufenen Chunks werden entfernt, bevor sie an das LLM übergeben werden. Spart Token und reduziert Rauschen.

Wie messe ich, ob mein RAG-System tatsächlich funktioniert?

Ein RAG-System ohne Evaluation ist wie ein Auto ohne Tacho: Sie fahren, wissen aber nicht wie schnell oder ob Sie in die richtige Richtung unterwegs sind. Entscheidend ist: Systematische Qualitätsmessung muss von Anfang an Teil der Pipeline sein, nicht ein nachträglicher Gedanke.

Die drei Dimensionen der RAG-Evaluation

1. Retrieval-Qualität: Findet das System die richtigen Dokumente?

• Precision@K: Wie viele der abgerufenen Dokumente sind relevant?
• Recall@K: Wie viele der relevanten Dokumente werden gefunden?
• MRR (Mean Reciprocal Rank): Auf welcher Position erscheint das erste relevante Dokument?

2. Generierungsqualität: Ist die Antwort korrekt und nützlich?

• Faithfulness: Basiert die Antwort auf den bereitgestellten Quellen? (Keine Halluzinationen)
• Answer Relevance: Beantwortet die Antwort tatsächlich die gestellte Frage?
• Completeness: Enthält die Antwort alle wichtigen Informationen aus den Quellen?

3. End-to-End-Qualität: Wie gut ist das Gesamterlebnis?

• Correctness: Stimmt die Antwort faktisch? (Verglichen mit einem Ground-Truth-Datensatz)
• Latency: Wie lange dauert es von der Frage bis zur Antwort?
• Cost per Query: Was kostet eine einzelne Abfrage (Embedding + Retrieval + LLM)?

Evaluation-Framework aufbauen

Bauen Sie ein Testset mit 50--100 Frage-Antwort-Paaren auf, die reale Nutzeranfragen abbilden. Für jede Frage dokumentieren Sie:

• Die erwartete Antwort
• Die relevanten Quelldokumente
• Die Schwierigkeitskategorie (einfach, mittel, komplex)

Automatisieren Sie die Evaluation mit Tools wie RAGAS, LangSmith oder Langfuse. Führen Sie die Tests bei jeder Änderung an der Pipeline durch -- neue Chunking-Strategie, anderes Embedding-Modell, veränderte Prompts.

Wie bringe ich mein RAG-System stabil in den Produktivbetrieb?

Ein RAG-System in der Produktion muss mehr leisten als korrekte Antworten zu liefern. Es muss stabil laufen, durchgehend überwacht werden und wartbar bleiben -- auch wenn sich Datenquellen, Nutzerzahlen oder Anforderungen ändern.

Architektur für den Produktivbetrieb

Caching: Häufig gestellte Fragen und ihre Antworten cachen. Semantisches Caching (ähnliche Fragen erkennen) spart LLM-Kosten und reduziert Latenz.

Monitoring: Überwachen Sie:

• Retrieval-Metriken (Latenz, Ergebnis-Anzahl, Ähnlichkeits-Scores)
• LLM-Metriken (Latenz, Token-Verbrauch, Kosten)
• Nutzerfeedback (Daumen hoch/runter, Eskalationsrate)
• Systemmetriken (CPU, RAM, GPU-Auslastung der Embedding-Server)

Datenaktualität: Definieren Sie, wie oft Ihre Datenquellen re-indexiert werden. Für Dokumenten-basierte Systeme reicht oft ein täglicher Batch-Job. Für Echtzeit-Anforderungen brauchen Sie Change-Data-Capture und inkrementelle Indexierung.

Sicherheit: Implementieren Sie rollenbasierte Zugriffssteuerung (RBAC) auf Dokumentenebene. Ein Nutzer darf nur Antworten erhalten, die auf Dokumenten basieren, für die er Leseberechtigung hat. Das erfordert Metadaten-Filter in der Vektordatenbank.

Skalierung

Für den Einstieg reicht eine einzige Instanz Ihrer Vektordatenbank und ein Embedding-Server. Bei wachsendem Volumen:

• Horizontales Skalieren: Mehrere Embedding-Server hinter einem Load Balancer
• Sharding: Vektordatenbank über mehrere Nodes verteilen
• Async-Processing: Indexierungsjobs asynchron über eine Message Queue (z.B. Redis, RabbitMQ)
• Read Replicas: Für Leseoperationen separate Replikas der Vektordatenbank

Welche Fehler machen Unternehmen beim Aufbau von RAG-Systemen am häufigsten?

Aus unserer Projektarbeit bei IJONIS in Hamburg kennen wir die typischen Stolpersteine, mit denen Unternehmen konfrontiert sind. Zusammengefasst: Die meisten Probleme entstehen nicht bei der Wahl der Technologie, sondern bei der Umsetzung grundlegender Engineering-Praktiken.

1. Chunking ignorieren. Die Standard-Einstellungen des Frameworks verwenden und sich wundern, dass die Retrieval-Qualität schlecht ist. Investieren Sie Zeit in die Chunking-Strategie -- sie hat mehr Einfluss auf das Ergebnis als die Wahl des LLMs.

2. Kein Re-Ranking. Die Top-K-Ergebnisse einer Vektor-Suche sind oft "thematisch richtig, inhaltlich daneben". Ein Cross-Encoder Re-Ranker verbessert die Precision typischerweise um 15--30%.

3. Zu grosse Chunks. Mehr Kontext ist nicht immer besser. Chunks über 1024 Token verwässern die Relevanz und kosten mehr Token beim LLM.

4. Fehlende Metadaten. Ohne Metadaten (Quelle, Datum, Abteilung, Dokumenttyp) können Sie nicht filtern, nicht priorisieren und nicht nachvollziehen, woher eine Antwort kommt.

5. Evaluation als Nachgedanke. Ohne Evaluation vor dem Go-Live wissen Sie nicht, ob Ihr System in der Praxis funktioniert. Bauen Sie das Evaluation-Framework parallel zur ersten Pipeline auf.

6. One-Shot-Indexierung. Daten einmal indexieren und vergessen. Unternehmenswissen ändert sich. Planen Sie automatische Re-Indexierung und Datenqualitäts-Checks ein. Warum die Daten-Infrastruktur das Fundament jeder KI-Initiative ist, haben wir in einem separaten Artikel beschrieben -- lesen Sie dazu auch unseren Beitrag zur Dateninfrastruktur für KI.

FAQ: Die häufigsten Fragen zu RAG-Systemen im Unternehmen

Was kostet ein RAG-System im laufenden Betrieb?

Die Betriebskosten hängen vom Volumen ab. Für ein mittelständisches Unternehmen mit 10.000--50.000 Dokumenten und 500--1.000 Anfragen pro Tag rechnen Sie mit: Embedding-API (50--200 EUR/Monat), Vektordatenbank-Hosting (100--500 EUR/Monat), LLM-API für Antwortgenerierung (200--1.000 EUR/Monat). Gesamt: 350--1.700 EUR/Monat. Self-Hosted-Setups mit eigenen GPUs reduzieren die variablen Kosten, erhöhen aber den initialen Investitionsbedarf.

Wie viele Dokumente kann ein RAG-System verarbeiten?

Technisch gibt es keine feste Obergrenze. Moderne Vektordatenbanken wie Milvus oder Qdrant skalieren auf Milliarden von Vektoren. Praktisch wird die Herausforderung bei Millionen von Dokumenten die Datenqualität und die Indexierungsgeschwindigkeit. Wichtiger als die Menge ist die Qualität: 1.000 gut gepflegte, aktuelle Dokumente liefern bessere Ergebnisse als 100.000 veraltete.

Brauche ich ein RAG-System oder reicht ein Chatbot mit langem Kontext?

LLMs mit grossen Kontextfenstern (128K--1M Token) können tatsächlich viele Dokumente gleichzeitig verarbeiten. Für kleine, statische Dokumentensets kann das reichen. RAG wird überlegen, wenn: die Datenmenge das Kontextfenster übersteigt, Daten regelmässig aktualisiert werden, Sie nachvollziehen müssen, welche Quelle die Antwort stützt, oder die Kosten pro Anfrage relevant sind (weniger Token = günstiger).

Wie gehe ich mit mehrsprachigen Inhalten um?

Verwenden Sie ein mehrsprachiges Embedding-Modell (z.B. multilingual-e5-large oder BGE-M3). Diese Modelle bilden semantisch ähnliche Texte in verschiedenen Sprachen nah beieinander im Vektor-Raum ab. Eine deutsche Frage findet so auch relevante englische Dokumente. Für die Antwortgenerierung instruieren Sie das LLM, in der Sprache des Nutzers zu antworten. Bei IJONIS in Hamburg implementieren wir dies als Standard für unsere deutschsprachigen Kunden, die auch englischsprachige Fachliteratur nutzen.

Kann ich ein RAG-System mit bestehenden KI-Agenten kombinieren?

Absolut -- RAG ist eine der wichtigsten Fähigkeiten, die ein KI-Agent haben kann. Der Agent nutzt RAG als Tool: Er formuliert die Suchanfrage, interpretiert die Ergebnisse und entscheidet, ob er weitere Informationen braucht oder die Antwort ausreichend ist. Diese Kombination aus autonomem Handeln und kontextbasiertem Wissen macht Agenten mit RAG-Zugang besonders leistungsfähig.

Fazit: RAG ist kein Feature, sondern eine Architekturentscheidung

Ein RAG-System ist mehr als ein Plugin für Ihr Sprachmodell. Es ist eine grundlegende Architekturentscheidung, die Daten-Pipelines, Infrastruktur, Zugriffssteuerung und Qualitätsmessung umfasst. Der Unterschied zwischen einer Demo und einem produktiven System liegt in den Details: der Chunking-Strategie, dem Embedding-Modell, dem Re-Ranking, dem Monitoring.

Die gute Nachricht: Sie müssen nicht alles auf einmal bauen. Starten Sie mit einem klar definierten Use Case, einer überschaubaren Dokumentenmenge und einer soliden Evaluation. Dann iterieren Sie.

„Wer eine RAG-Pipeline ohne systematische Evaluation in Produktion bringt, fliegt blind. Wir haben in jedem Projekt gesehen: Die Investition in ein solides Testset zahlt sich zehnfach aus." — Jamin Mahmood-Wiebe, Gründer von IJONIS

Bereit, Ihr Unternehmenswissen für KI zugänglich zu machen? Lassen Sie uns gemeinsam Ihre Daten-Infrastruktur analysieren -- wir identifizieren die richtigen Datenquellen, wählen die passende Architektur und bauen ein RAG-System, das in der Produktion besteht.