RAG-Pipeline: Praxisleitfaden für Unternehmen

Jeder redet über RAG — Retrieval-Augmented Generation. Das Prinzip klingt einfach: Statt ein Sprachmodell alles aus dem Gedächtnis beantworten zu lassen, gibst du ihm relevante Dokumente als Kontext mit. Keine Halluzinationen, aktuelle Daten, volle Kontrolle. In der Praxis scheitern aber überraschend viele RAG-Projekte — nicht am Modell, sondern an der Pipeline davor.

Dieser Leitfaden zeigt, wie eine RAG-Pipeline aufgebaut ist, wo die typischen Fehler liegen, und welche Tools sich 2026 bewährt haben.

Was RAG ist — und was es nicht ist

RAG kombiniert zwei Schritte: Retrieval (relevante Informationen aus einer Wissensbasis holen) und Generation (ein LLM formuliert daraus eine Antwort). Das Konzept stammt aus einem Meta-Paper von 2020 und hat sich seitdem zum Standard für wissensbasierte KI-Anwendungen entwickelt.

Was RAG nicht ist: ein Ersatz für saubere Daten. Wenn deine Dokumente veraltet, widersprüchlich oder schlecht strukturiert sind, liefert auch die beste Pipeline Müll. "Garbage in, garbage out" gilt hier besonders.

Der entscheidende Vorteil gegenüber Fine-Tuning: RAG braucht kein Modell-Training. Du kannst Dokumente jederzeit aktualisieren, ohne das Modell anzufassen. Das macht RAG zur pragmatischen Wahl für Unternehmenswissen, das sich regelmäßig ändert — Handbücher, Richtlinien, Produktdaten, Support-Dokumentation.

Die fünf Stufen einer RAG-Pipeline

Eine produktionsreife RAG-Pipeline besteht aus fünf Stufen. Jede einzelne kann das Gesamtergebnis ruinieren — oder deutlich verbessern.

Stufe 1: Dokumentenaufbereitung

Bevor Dokumente in die Pipeline gehen, müssen sie in ein einheitliches Format gebracht werden. PDF, Word, HTML, Markdown, E-Mails — alles muss als sauberer Text vorliegen.

Hier passieren die ersten Fehler: PDF-Extraktion liefert oft kaputte Tabellen, fehlende Überschriften oder zusammengezogene Spalten. Tools wie Unstructured oder Docling helfen, aber eine manuelle Stichprobe der Ergebnisse ist Pflicht.

Praxistipp: Bevor du an Embeddings oder Vector Stores denkst — schau dir zehn zufällige Dokumente nach der Extraktion an. Wenn die Texte dort nicht stimmen, wird der Rest nicht besser.

Stufe 2: Chunking

Ganze Dokumente in einen Embedding-Vektor zu packen, funktioniert nicht — der Kontext wird zu breit und die Relevanz verwässert. Deshalb werden Dokumente in kleinere Abschnitte (Chunks) zerlegt.

Die Chunk-Größe ist der wichtigste Parameter in der ganzen Pipeline. Zu kleine Chunks verlieren den Zusammenhang. Zu große Chunks verwässern die Relevanz beim Retrieval. Ein guter Startpunkt liegt bei 512 bis 1024 Tokens mit einer Überlappung von 10–20 %.

Aber: Fixe Chunk-Größen sind selten optimal. Besser ist semantisches Chunking — Abschnitte entlang natürlicher Grenzen wie Überschriften, Absätzen oder Themenwechseln trennen. LlamaIndex und LangChain bieten dafür fertige Splitter.

Stufe 3: Embedding

Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt — eine mathematische Repräsentation des Inhalts. Semantisch ähnliche Texte landen nah beieinander im Vektorraum.

Die Modellwahl macht einen echten Unterschied. Für deutschsprachige Inhalte empfehlen sich Modelle, die explizit auf Deutsch trainiert wurden oder starke mehrsprachige Leistung zeigen. MTEB-Benchmarks helfen bei der Auswahl — achte dabei auf die Retrieval-Scores, nicht nur auf die Gesamtwertung.

Gängige Optionen 2026:

• OpenAI text-embedding-3-large: Stark bei Mehrsprachigkeit, aber Cloud-abhängig
• Cohere embed-v4: Gute Balance aus Qualität und Geschwindigkeit
• BGE-M3 / E5-Mistral: Open Source, lokal einsetzbar, starke Retrieval-Leistung
• Jina Embeddings v3: Speziell für längere Dokumente optimiert

Wichtig: Verwende für Dokumente und Suchanfragen immer dasselbe Embedding-Modell. Ein Modellwechsel macht den gesamten Vector Store unbrauchbar — alle Dokumente müssen neu eingebettet werden.

Stufe 4: Vector Store

Die Embeddings landen in einer Vektordatenbank, die schnelle Ähnlichkeitssuchen ermöglicht. Bei einer Suchanfrage wird die Frage ebenfalls eingebettet und die ähnlichsten Chunks abgerufen.

Die Auswahl hängt vom Einsatzszenario ab:

• Chroma: Leichtgewichtig, ideal für Prototypen und kleinere Datenmengen
• Qdrant: Performant, filterfähig, gut für Produktion
• Milvus: Skalierbar auf Millionen von Vektoren, Kubernetes-native
• pgvector: PostgreSQL-Erweiterung — wenn du bereits Postgres nutzt, brauchst du keine extra Datenbank

Für die meisten Unternehmensprojekte ist pgvector der pragmatischste Einstieg: keine neue Infrastruktur, keine neue Betriebskompetenz, und gut genug für hunderttausende Dokumente.

Stufe 5: Retrieval und Generierung

Bei einer Nutzeranfrage passiert Folgendes: Die Frage wird eingebettet, die k ähnlichsten Chunks abgerufen (typisch: 3–8), und zusammen mit der Frage als Kontext an das LLM übergeben. Das Modell formuliert daraus eine Antwort.

Der einfache Ansatz — Top-k Vektor-Suche — funktioniert oft schon gut. Für bessere Ergebnisse gibt es zwei bewährte Erweiterungen:

Hybrid Search: Kombination aus Vektor-Suche (semantische Ähnlichkeit) und klassischer Volltextsuche (BM25). Damit findest du auch exakte Begriffe, die rein semantisch durchrutschen würden — etwa Produktnummern, Paragraphen oder Fachbegriffe.

Re-Ranking: Nach dem initialen Retrieval bewertet ein Cross-Encoder die Chunk-Frage-Paare nochmal einzeln und sortiert nach tatsächlicher Relevanz. Das verbessert die Präzision deutlich, kostet aber zusätzliche Latenz. Cohere Rerank und BGE Reranker sind gängige Optionen.

Die häufigsten Fehler in der Praxis

Nach dutzenden RAG-Implementierungen sehen wir immer wieder dieselben Muster:

1. Zu viel Kontext, zu wenig Relevanz

Mehr Chunks heißt nicht bessere Antworten. Wenn du 20 Chunks als Kontext mitgibst, ertrinkt das LLM in Informationen und verliert den Fokus. Starte mit 3–5 Chunks und erhöhe nur, wenn die Antwortqualität nachweislich steigt.

2. Kein Evaluation-Framework

Ohne systematische Auswertung weißt du nicht, ob deine Pipeline gut funktioniert. Erstelle ein Test-Set mit 50–100 Frage-Antwort-Paaren aus echten Nutzerfragen. Miss Retrieval-Recall (findet die Pipeline die richtigen Chunks?) und Antwortqualität (stimmt die generierte Antwort?).

RAGAS ist das Standard-Framework dafür. Es misst Faithfulness (ist die Antwort durch die Quellen gedeckt?), Relevancy (sind die abgerufenen Chunks relevant?) und Answer Correctness.

3. Metadaten ignorieren

Chunks ohne Metadaten sind wie Bücher ohne Inhaltsverzeichnis. Speichere mindestens: Quelldokument, Erstellungsdatum, Dokumenttyp und Abschnitt. Damit kannst du beim Retrieval filtern ("nur Dokumente aus 2026") und dem Nutzer die Quelle anzeigen.

4. Einmalige Einrichtung statt laufender Pflege

Eine RAG-Pipeline ist kein "Set and Forget"-System. Dokumente ändern sich, neue kommen dazu, alte werden ungültig. Plane von Anfang an eine Aktualisierungsstrategie: Wie kommen neue Dokumente in die Pipeline? Wie werden veraltete entfernt? Wer prüft die Qualität?

Werkzeuge und Frameworks

Die Landschaft ist 2026 ausgereift. Hier die wichtigsten Bausteine:

LangChain — das umfangreichste Ökosystem für RAG-Pipelines. Bietet fertige Integrationen für praktisch jeden Vector Store, jedes Embedding-Modell und jedes LLM. Kann überdimensioniert sein für einfache Setups.

LlamaIndex — speziell auf Datenanbindung und Retrieval fokussiert. Stärker strukturiert als LangChain, weniger Konfigurationsaufwand für Standard-RAG-Setups.

Haystack — von Deepset (deutsches Unternehmen), Pipeline-basierter Ansatz mit starkem Fokus auf Produktion und Evaluation. Gute Wahl für Teams, die eine opinionated Lösung bevorzugen.

OpenWebUI — bringt eine eingebaute RAG-Pipeline mit: Dokumente hochladen, automatisches Chunking und Embedding, Suche im Chat. Für den schnellen Einstieg die einfachste Option — mehr dazu in unserem OpenWebUI-Leitfaden.

RAG im Unternehmen: Unser Ansatz

Bei SEADEV setzen wir RAG-Pipelines als Teil unserer AI-Software-Lösungen um. Die typische Architektur:

• Embedding: Open-Source-Modelle (BGE-M3 oder E5-Mistral), lokal gehostet über vLLM
• Vector Store: pgvector oder Qdrant, je nach Skalierungsanforderung
• Orchestrierung: Windmill für Dokumenten-Ingestion-Workflows
• LLM: Flexibel über LiteLLM — lokale Modelle oder Cloud-APIs, je nach Anforderung
• Frontend: OpenWebUI für generelle Nutzung, eigene UIs für strukturierte Prozesse

Alles DSGVO-konform, on-premise oder in unserem eigenen Rechenzentrum. Kein Vendor Lock-in.

Fazit: RAG ist kein Hexenwerk — aber auch kein Selbstläufer

Eine funktionierende RAG-Pipeline aufzubauen, ist keine Raketenwissenschaft. Die Konzepte sind klar, die Tools ausgereift, die Dokumentation umfangreich. Was die guten Implementierungen von den schlechten unterscheidet, ist Sorgfalt bei den Grundlagen: saubere Daten, durchdachtes Chunking, systematische Evaluation.

Starte klein — ein Dokumententyp, ein Use Case, ein Test-Set. Wenn das funktioniert, skaliere. Nicht umgekehrt.

Wenn du überlegst, eine RAG-Pipeline für dein Unternehmen aufzubauen — ob als Prototyp oder für den Produktivbetrieb — meld dich bei uns. Wir helfen dir, den richtigen Einstieg zu finden.