RAG-Pipelines in der Praxis: Vom Prototyp zur Produktion

Einen RAG-Prototyp zu bauen ist einfach. In einer Stunde hat man LangChain installiert, ein paar PDFs reingeworfen und bekommt halbwegs passende Antworten. Beeindruckend — und komplett nutzlos für den Produktiveinsatz. Denn zwischen "funktioniert in der Demo" und "funktioniert zuverlässig mit 50.000 Dokumenten" liegen Welten.

Dieser Artikel beschreibt, wie RAG-Systeme aussehen müssen, die tatsächlich in Produktion laufen. Keine Theorie aus Tutorials, sondern Erfahrungen aus über zwanzig produktiven Systemen in europäischen Unternehmen.

Warum der Prototyp lügt

Fast jeder RAG-Prototyp liefert in der Demo gute Ergebnisse. Das liegt nicht daran, dass das System gut ist — sondern daran, dass die Demo-Bedingungen unrealistisch sind:

• Kleine Datenmenge: 20 saubere PDFs. In Produktion sind es 50.000 Dokumente in unterschiedlichen Formaten und Qualitäten.
• Perfekte Fragen: Der Demo-Nutzer stellt genau die Fragen, auf die das System optimiert wurde.
• Keine Lastanforderungen: Ein Nutzer, keine parallelen Anfragen, keine Latenz-Erwartungen.
• Kein Monitoring: Niemand misst, wie oft das System falsche oder unvollständige Antworten liefert.

Architektur eines produktiven RAG-Systems

Ein robustes RAG-System besteht aus fünf Kernkomponenten. Jede einzelne kann zum Flaschenhals werden, wenn sie nicht richtig implementiert ist.

1. Dokumenten-Ingestion

Der erste Schritt: Dokumente in maschinenlesbare Form bringen. Klingt banal, ist in der Praxis die häufigste Fehlerquelle.

• PDF-Parsing: Gescannte PDFs brauchen OCR. Tabellen in PDFs sind notorisch schwer zu extrahieren. Wir nutzen dedizierte Parser, die Tabellenstrukturen erkennen.
• Format-Vielfalt: Word, Excel, E-Mail, HTML, Markdown — jedes Format braucht einen eigenen Parser. Einheitliches Zwischenformat ist Pflicht.
• Metadaten: Dokumententyp, Erstelldatum, Autor, Abteilung, Version. Ohne Metadaten kann das System später nicht filtern.
• Deduplizierung: In echten Unternehmensdaten existieren Dokumente in drei Versionen an fünf Orten. Ohne Deduplizierung sinkt die Antwortqualität dramatisch.

2. Chunking-Strategie

Chunking — das Aufteilen von Dokumenten in durchsuchbare Abschnitte — ist die Stellschraube mit dem größten Einfluss auf die Antwortqualität. Und gleichzeitig die Stelle, an der die meisten Projekte scheitern.

Der naive Ansatz: Dokument in 500-Token-Blöcke schneiden. Funktioniert in der Demo, zerstört in der Praxis den Kontext. Ein Absatz wird mitten im Satz getrennt, eine Tabelle in drei Chunks aufgeteilt, ein Verweis auf das vorherige Kapitel wird sinnlos.

Was tatsächlich funktioniert:

• Semantisches Chunking: Abschnitte werden anhand von Überschriften, Absätzen und logischen Einheiten getrennt — nicht nach fester Zeichenzahl.
• Overlap mit Kontext: Jeder Chunk enthält am Anfang eine Zusammenfassung des übergeordneten Dokuments und Abschnitts. Das gibt dem Sprachmodell Orientierung.
• Hierarchisches Chunking: Dokument-Ebene → Kapitel-Ebene → Abschnitts-Ebene. Bei der Suche wird zuerst das relevante Kapitel gefunden, dann der passende Abschnitt.
• Tabellen als Einheiten: Tabellen werden nie aufgeteilt. Sie bekommen einen eigenen Chunk mit der Überschrift der Tabelle als Kontext.

3. Vektordatenbank und Embedding

Wir setzen auf PostgreSQL mit der pgvector-Erweiterung. Das hat einen einfachen Grund: Die meisten Unternehmen haben bereits PostgreSQL im Einsatz. Eine separate Vektordatenbank wie Pinecone oder Weaviate bedeutet zusätzliche Infrastruktur, zusätzliche Kosten und zusätzliche Ausfallmöglichkeiten.

Mit pgvector liegen Ihre Vektoren, Metadaten und Nutzdaten in einer Datenbank. Joins, Transaktionen, Backups — alles funktioniert wie gewohnt.

Wichtige Konfigurationsaspekte:

• Embedding-Modell: Wir nutzen multilingual-e5-large für mehrsprachige Systeme oder nomic-embed-text für performante Self-Hosted-Installationen. Die Wahl des Embedding-Modells beeinflusst die Retrieval-Qualität stärker als das LLM.
• Indexierung: HNSW-Index für schnelle Nearest-Neighbor-Suche. Bei Datenmengen über 100.000 Chunks ist die Index-Konfiguration entscheidend für die Antwortzeit.
• Dimensionen: 768 oder 1.024 Dimensionen je nach Modell. Mehr Dimensionen bedeuten nicht automatisch bessere Ergebnisse.

4. Hybrid-Retrieval

Reine Vektorsuche funktioniert gut für semantische Ähnlichkeit, versagt aber bei exakten Begriffen. Wenn ein Nutzer nach der Seriennummer "XR-4472-B" sucht, findet die Vektorsuche alles Mögliche — nur nicht exakt diesen String.

Die Lösung: Hybrid-Retrieval. Kombination aus Vektorsuche (semantisch) und Volltextsuche (exakt), gewichtet nach Anfrage-Typ.

In unseren Tests verbessert Hybrid-Retrieval die Trefferquote im Vergleich zur reinen Vektorsuche um 15 – 25 %. Der Re-Ranking-Schritt bringt nochmals 5 – 10 %.

5. LLM-Generierung

Der letzte Schritt: Das Sprachmodell generiert eine Antwort auf Basis der gefundenen Chunks. Hier entscheiden Prompt-Design und Guardrails über die Qualität.

• System-Prompt: Definiert Tonalität, Antwortformat und Verhaltensregeln. Muss für jeden Use Case individuell abgestimmt werden.
• Kontext-Fenster: Die gefundenen Chunks werden als Kontext in den Prompt eingefügt. Die Reihenfolge und Formatierung beeinflusst die Antwortqualität erheblich.
• Quellenangabe: Jede Antwort enthält Verweise auf die Ursprungsdokumente. Ohne Nachvollziehbarkeit kein Vertrauen.
• Halluzinations-Guard:Wenn die gefundenen Chunks die Frage nicht beantworten, sagt das System "Dazu liegen mir keine Informationen vor" — statt eine plausibel klingende Antwort zu erfinden.

Die typischen Produktionsprobleme

Jedes RAG-System trifft in Produktion auf die gleichen Herausforderungen. Hier sind die häufigsten — und wie wir sie lösen.

Problem 1: Retrieval-Genauigkeit sinkt bei großen Datenmengen

Mit wachsender Dokumentenzahl steigt die Wahrscheinlichkeit, dass irrelevante Chunks in den Ergebnissen auftauchen. Die Antwortqualität sinkt schleichend.

Problem 2: Latenz

Nutzer erwarten Antworten in unter drei Sekunden. Eine typische RAG-Pipeline braucht ohne Optimierung sechs bis zehn Sekunden: Embedding der Anfrage (200 ms), Vektorsuche (100 ms), Re-Ranking (500 ms), LLM-Generierung (3 – 8 Sekunden).

• Streaming: Antworten werden Token für Token gestreamt. Der Nutzer sieht sofort den Anfang der Antwort.
• Caching: Häufige Anfragen und ihre Ergebnisse werden in Redis zwischengespeichert. Wiederholte Fragen werden in unter 200 ms beantwortet.
• Embedding-Cache: Embedding-Berechnungen für wiederkehrende Anfragemuster werden gecacht.
• Modellwahl: Nicht jede Anfrage braucht GPT-4o. Einfache Fragen werden an ein schnelleres, kleineres Modell geroutet.

Problem 3: Dokumenten-Updates

Dokumente ändern sich. Richtlinien werden aktualisiert, Handbücher ergänzt, Verträge verlängert. Ein RAG-System, das auf veralteten Daten antwortet, ist schlimmer als gar kein System.

• Change Detection: Automatische Erkennung geänderter Dokumente via Dateisystem-Watcher oder API-Polling.
• Inkrementelles Re-Indexing: Nur geänderte Dokumente werden neu verarbeitet — nicht der gesamte Index.
• Versionshistorie: Alte Chunk-Versionen werden archiviert, nicht gelöscht. Bei Bedarf können Antworten auf einem bestimmten Dokumentenstand basieren.

Self-Hosted vs. Cloud: Eine pragmatische Entscheidung

Die Entscheidung, ob Sie Ihr RAG-System selbst hosten oder auf Cloud-APIs setzen, hat erhebliche Auswirkungen auf Kosten, Datenschutz und Betriebsaufwand.

Unser Ansatz: Cloud-API für den Start, Self-Hosted als Option für die Skalierung. Die Architektur wird von Anfang an so gebaut, dass der Wechsel ohne Neuentwicklung möglich ist. Das Sprachmodell ist eine austauschbare Komponente, kein Fundament.

Monitoring: Woher wissen Sie, ob es funktioniert?

Ein RAG-System ohne Monitoring ist ein Blindflug. Diese Metriken überwachen wir in jedem produktiven System:

• Retrieval Recall: Wie oft enthält das Retrieval-Ergebnis die tatsächlich relevanten Chunks? Zielwert: über 85 %.
• Answer Faithfulness: Basiert die Antwort auf den bereitgestellten Chunks — oder halluziniert das Modell? Automatisierte Prüfung via LLM-as-Judge.
• Latenz (P95): 95 % aller Anfragen sollten in unter fünf Sekunden beantwortet werden. Streaming reduziert die wahrgenommene Wartezeit.
• Nutzerfeedback: Daumen-hoch/runter auf jede Antwort. Einfach, aber unersetzbar für die langfristige Qualitätssicherung.
• Fallback-Rate:Wie oft antwortet das System mit "Dazu liegen mir keine Informationen vor"? Ein Anstieg deutet auf Lücken in der Dokumentenbasis hin.

Kosten eines produktiven RAG-Systems

Ein realistischer Überblick über die laufenden Kosten nach dem initialen Projektbudget:

Dazu kommt der Wartungsaufwand: Modell-Updates, Dokumenten-Aktualisierungen, Optimierung der Retrieval-Qualität. Rechnen Sie mit EUR 300 – 800 pro Monat für laufende Betreuung, abhängig von der Systemkomplexität.

Checkliste: Ist Ihr Unternehmen bereit für RAG?

Bevor Sie in ein RAG-Projekt investieren, prüfen Sie diese Voraussetzungen:

• Dokumentenbasis: Mindestens 100+ Dokumente, die regelmäßig genutzt und aktualisiert werden.
• Klarer Use Case: Eine konkrete Frage, die Mitarbeiter heute manuell beantworten — mit messbarem Zeitaufwand.
• Datenqualität: Dokumente sind aktuell, widerspruchsfrei und in maschinenlesbarem Format verfügbar.
• Interner Sponsor: Eine Person mit Entscheidungskompetenz, die das Projekt vorantreibt.
• Budget: Mindestens EUR 8.000 für die Entwicklung plus EUR 300 – 800 monatliche Betriebskosten.
• Akzeptanz: Toleranz dafür, dass das System nicht perfekt ist. 85 – 90 % Trefferquote ist ein guter Wert.

Fazit: Produktive RAG-Systeme sind Handwerk, keine Magie

RAG ist keine Raketenwissenschaft, aber auch kein Tutorial-Projekt. Der Unterschied zwischen einer Demo und einem produktiven System liegt in den Details: saubere Ingestion, intelligentes Chunking, Hybrid-Retrieval, robustes Monitoring. Jede einzelne Komponente ist beherrschbar — aber sie müssen zusammenspielen.

Die gute Nachricht: Mit der richtigen Architektur und realistischen Erwartungen liefern RAG-Systeme messbaren Geschäftswert. Mitarbeiter finden Informationen schneller, Kunden bekommen bessere Antworten, und Wissen, das bisher in Dokumenten-Friedhöfen lag, wird wieder nutzbar.