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

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.