RAG in Produktion: Vom Prototyp zum System, das 24/7 läuft

Jedes Team kann an einem Nachmittag einen RAG-Prototyp bauen, der in einer Demo überzeugend wirkt. Aber zwischen „funktioniert in Jupyter” und „läuft 24/7 in Produktion auf echten Daten” liegt eine Kluft, die die meisten Projekte nie überbrücken. Dieser Artikel zeigt, wie man sie überbrückt — ohne Illusionen und ohne Marketing-Abkürzungen.

Was ist RAG und warum die Basisimplementierung nicht reicht¶

Retrieval-Augmented Generation (RAG) ist ein Architekturmuster, bei dem ein Sprachmodell Antworten nicht rein aus dem parametrischen Gedächtnis generiert, sondern zuerst relevanten Kontext aus externen Quellen abruft — Dokumente, Datenbanken, APIs — und erst dann die Antwort formuliert. Das Problem ist, dass diese einfache Version nur bei einfachen Daten funktioniert.

5 häufigste Fehler in Produktions-RAG¶

1 Chunking ohne Strategie¶

Fixiertes Chunking ignoriert die Dokumentstruktur. Lösung: Hierarchisches Chunking, das die Dokumentstruktur respektiert.

2 Ein Embedding-Modell für alles¶

Lösung: Feingetunte Embedding-Modelle auf Domänendaten. Oder zumindest hybrides Retrieval — Kombination aus Vektorsuche mit BM25.

3 Kein Reranking¶

Lösung: Cross-Encoder-Reranker als zweite Stufe. Typischerweise sehen wir 15–25 % Steigerung der Antwortgenauigkeit allein durch Hinzufügen eines Rerankers.

4 Ignorieren von Aktualität und Datenversionierung¶

Lösung: Inkrementelle Indexierungs-Pipeline mit Change Detection.

5 Keine Evaluierungen und Metriken¶

Lösung: Evaluierungs-Pipeline vom ersten Tag an. Retrieval-Metriken, Generierungsmetriken und Golden Test Set.

Bewährte Architekturmuster¶

Drei Schlüsselschichten: Indexierungs-Pipeline, Retrieval-Strategie und Reranking.

Indexierungs-Pipeline¶

Document Parsing, hierarchisches Chunking, Metadaten-Enrichment und Change Detection.

Retrieval-Strategie¶

Multi-Stage Retrieval: Query Rewriting, hybride Suche, Metadaten-Filterung und Parent Document Retrieval.

Reranking als Game Changer¶

Reranking ist der günstigste Weg, die RAG-Systemqualität signifikant zu verbessern.

Monitoring und Evaluierung in Produktion¶

Was messen¶

• Retrieval-Qualität: Recall@k, MRR, nDCG
• Generierungsqualität: Faithfulness, Antwortrelevanz, Halluzinationsrate
• Latenz: P50, P95, P99 für die gesamte Pipeline und einzelne Phasen
• Nutzungsmuster: welche Abfragetypen, wo das System „Ich weiß nicht” sagt
• Kosten pro Abfrage: Embedding-Aufrufe, LLM-Tokens, Reranker-Aufrufe

Bewährte Architekturmuster — Details¶

Nach Dutzenden von Deployments hat sich eine Architektur herauskristallisiert, die domänenübergreifend konsistent funktioniert. Drei Schlüsselschichten: Indexierungs-Pipeline, Retrieval-Strategie und Reranking.

Indexierungs-Pipeline¶

Die Indexierungs-Pipeline ist das Fundament, auf dem alles andere ruht. Input sind Rohdokumente in verschiedenen Formaten, Output ist ein strukturierter, durchsuchbarer Index. Schlüsselkomponenten:

• Dokument-Parsing: Unstructured.io oder Custom-Parser für PDF, DOCX, HTML. OCR für gescannte Dokumente. Extraktion von Tabellen und Bildern als separate Entitäten.
• Hierarchisches Chunking: Abschnitte → Absätze → Sätze. Jeder Chunk trägt Metadaten über seinen Platz in der Hierarchie. Parent-Child-Beziehungen ermöglichen die Rückgabe breiteren Kontexts beim Retrieval.
• Metadaten-Enrichment: Automatische Dokumenttyp-Klassifizierung, Entity-Extraktion (Namen, Daten, Beträge), Tag-Zuweisung. Metadaten werden separat indiziert und für das Filtern beim Retrieval verwendet.
• Change Detection: Content-Hashing (SHA-256) zur Änderungserkennung. Nur was sich tatsächlich geändert hat, wird reindexiert. Alte Versionen werden archiviert, nicht gelöscht.

Retrieval-Strategie¶

Naives „Query einbetten → Cosine-Suche → Top-k” hat in der Produktion zwei fundamentale Schwächen: Single-Step Retrieval kann komplexe Abfragen nicht bewältigen, und rein vektorbasierte Suche verliert exakte Begriffe. Deshalb verwenden wir Multi-Stage Retrieval:

• Query Rewriting: Das LLM reformuliert die Benutzeranfrage in 2–3 Varianten, die für das Retrieval optimiert sind. „Wie funktioniert eine Rücksendung?” → „Rücksendungs-Bearbeitungsverfahren”, „Rücksendungsrichtlinien-Bedingungen”, „Frist für Rücksendungsantrag”.
• Hybride Suche: Parallele Vektor- + BM25-Volltextsuche. Ergebnisse werden via Reciprocal Rank Fusion (RRF) zusammengeführt. Vektorsuche erfasst Semantik, BM25 erfasst exakte Begriffe und Abkürzungen.
• Metadaten-Filterung: Vor der Suche werden Filter angewendet — Dokumenttyp, Gültigkeitsdatum, Benutzerberechtigungen. Wir durchsuchen nicht den gesamten Index, sondern eine relevante Teilmenge.
• Parent Document Retrieval: Wenn ein Chunk hoch bewertet wird, aber zu kurz für vollen Kontext ist, lädt das System automatisch den Parent-Chunk (den gesamten Abschnitt), damit das Modell ausreichend Kontext hat.

Reranking als Game Changer¶

Reranking ist der günstigste Weg, die RAG-Systemqualität signifikant zu verbessern. Ein Bi-Encoder (Embedding-Modell) ist schnell, aber ungenau — er vergleicht Query und Dokument unabhängig voneinander. Ein Cross-Encoder ist langsam, aber präzise — er verarbeitet Query und Dokument zusammen und erzeugt einen echten Relevanz-Score.

In der Praxis gibt der Bi-Encoder die Top-50-Kandidaten in ~20ms zurück, der Cross-Encoder sortiert sie in ~100ms neu, und das Modell erhält die Top-5 tatsächlich relevantesten Chunks. Die Latenz steigt minimal, die Antwortqualität erheblich — wir sehen typischerweise eine 15–25 % Steigerung der Antwortgenauigkeit allein durch Hinzufügen eines Rerankers.

Monitoring und Evaluierung in Produktion¶

Ein RAG-System ohne Monitoring ist eine Black Box. Sie wissen nicht, ob es funktioniert, bis sich jemand beschwert. Und die Beschwerden kommen spät — nach Dutzenden schlechter Antworten, die das Vertrauen der Benutzer untergraben haben. Deshalb bauen wir Monitoring von Tag eins an.

Was messen¶

• Retrieval-Qualität: Recall@k, MRR (Mean Reciprocal Rank), nDCG. Misst, ob der Retriever die richtigen Dokumente zurückgibt. Erfordert ein Golden Test Set mit manuell annotierten Query–relevantes-Dokument-Paaren.
• Generierungsqualität: Faithfulness (die Antwort wird durch den abgerufenen Kontext gestützt), Antwortrelevanz (die Antwort beantwortet tatsächlich die Frage), Halluzinationsrate (das Modell behauptet etwas, das nicht im Kontext steht).
• Latenz: P50, P95, P99 für die gesamte Pipeline und einzelne Phasen (Retrieval, Reranking, Generierung). Benutzer warten nicht länger als 3 Sekunden — wenn die Pipeline länger braucht, haben Sie ein Problem.
• Nutzungsmuster: Welche Abfragetypen Benutzer stellen, wo das System „Ich weiß nicht” sagt, wo Benutzer erneut fragen (ein Signal der Unzufriedenheit).
• Kosten pro Abfrage: Embedding-Aufrufe, LLM-Tokens, Reranker-Aufrufe. In der Produktion mit Tausenden täglicher Abfragen summieren sich Kosten schnell.

Evaluierungs-Pipeline¶

Automatisierte Evaluierungen laufen nach jeder Änderung — anderes Chunking, neues Embedding-Modell, Prompt-Anpassung. Ohne dies schießen Sie blind. Wir verwenden eine Kombination aus:

• Offline-Eval: Golden Test Set (100–500 manuell verifizierte Paare), automatisierte Metriken über das RAGAS-Framework, Regressionstests bei jedem Deploy.
• Online-Eval: LLM-as-Judge auf einer Stichprobe von Produktionsabfragen (5–10 %), Benutzer-Feedback (Daumen hoch/runter), Eskalation an einen Menschen bei niedrigem Konfidenzwert.
• Drift Detection: Überwachung der Verteilung von Embedding-Vektoren und Retrieval-Scores im Zeitverlauf. Wenn sich die Verteilung ändert, haben sich wahrscheinlich die Daten oder das Benutzerverhalten geändert.

Wie wir RAG bei CORE SYSTEMS bauen¶

Bei CORE SYSTEMS behandeln wir RAG als Data-Engineering-Problem, nicht als KI-Experiment. Das Modell ist nur eine Komponente — und meist nicht die komplexeste. Der Großteil der Arbeit steckt in der Daten-Pipeline, der Indexqualität und der operativen Zuverlässigkeit.

Jedes Projekt beginnt mit einem Datenaudit-Workshop: Wir kartieren Datenquellen, bewerten Dokumentqualität und -struktur, identifizieren Edge Cases (gescannte PDFs, Excel-Tabellen, mehrsprachige Inhalte). Erst dann entwerfen wir die Architektur — denn die Chunking-Strategie für juristische Verträge ist grundlegend anders als die Strategie für Produktdokumentation.

Wir liefern End-to-End: Indexierungs-Pipeline, Retrieval Engine, Generierungsschicht, Evaluierungs-Framework und Monitoring-Dashboard. Alles läuft auf der Infrastruktur des Kunden — wir unterstützen Azure, AWS und On-Premise, denn in regulierten Branchen dürfen Daten den Perimeter nicht verlassen. Wir betreiben, was wir bauen — das zwingt uns, Dinge zu bauen, die tatsächlich in der Produktion funktionieren.

Wir verwenden einen Open-Source-Stack (LlamaIndex, pgvector/Qdrant, RAGAS), ergänzt durch proprietäre Komponenten für Governance, Sicherheit und Enterprise-Integrationen. Wir sind nicht an einen einzigen LLM-Anbieter gebunden — wir unterstützen OpenAI, Anthropic, Azure OpenAI und lokale Modelle über vLLM/Ollama, denn die Modellwahl ist eine Business-Entscheidung, keine technische Einschränkung.

Fazit: RAG in Produktion ist Data Engineering¶

Die größte Erkenntnis aus Dutzenden RAG-Deployments? Die Qualität eines RAG-Systems wird zu 80 % durch Datenqualität und Retrieval bestimmt, nicht durch die Modellqualität. Besseres Chunking, bessere Embeddings, Reranking und saubere Daten-Pipelines bringen mehr als ein Upgrade von GPT-4o auf ein neueres Modell.

Unternehmen, die RAG als Data-Engineering-Problem angehen — mit einer robusten Pipeline, systematischer Messung und operativer Disziplin — werden ein System haben, das 24/7 läuft. Der Rest wird weiterhin in Jupyter demonstrieren und sich fragen, warum es in der Produktion nicht funktioniert.