KI-Systeme in der Produktion: RAG-Pipelines richtig bauen
Die meisten RAG-Tutorials zeigen, wie man in einem Jupyter-Notebook mit 20 Zeilen LangChain schnell etwas zum Laufen bringt. Produktive RAG-Systeme sind ein grundlegend anderes Problem. Der Unterschied zwischen einer Demo, die im Meeting gut ankommt, und einem System, das zuverlässig korrekte Antworten im Tagesbetrieb liefert, liegt in den Architekturentscheidungen, die vor der ersten Zeile Retrieval-Code getroffen werden.
Dieser Leitfaden beschreibt die Architekturentscheidungen, die in der Praxis den Unterschied machen — basierend auf 20+ produktiven RAG-Systemen, darunter Compliance-Systeme mit 38 API-Routen und Pipelines, die täglich Tausende Dokumente verarbeiten.
Warum RAG in der Produktion schwieriger ist
Produktive RAG-Systeme scheitern auf drei Arten, die in Tutorials nie auftauchen:
Retrieval-Genauigkeit bricht bei Skalierung ein
Sobald der Dokumentenbestand über ein paar Hundert Chunks hinauswächst, liefert naive Cosinus-Ähnlichkeit zunehmend irrelevante Ergebnisse. Das Modell halluziniert, weil das Kontextfenster mit Beinahe-Treffern gefüllt ist.
Chunking-Strategie zerstört Kontext
Feste Zeichenlängen-Chunks zerschneiden Sätze, Tabellen und Code-Blöcke mitten im Gedanken. Die abgerufenen Chunks sind syntaktisch intakt, aber semantisch unbrauchbar.
Latenz ist ohne Optimierung inakzeptabel
Embedding + Retrieval + Reranking + LLM-Generierung dauert bei naiver Implementierung 8–15 Sekunden. In der Produktion braucht man unter 2 Sekunden, sonst springen Nutzer ab.
Die produktive RAG-Architektur
Eine produktive RAG-Pipeline hat zwei getrennte Zuständigkeiten: die Ingestion-Pipeline (läuft einmal pro Dokument, offline) und die Query-Pipeline (läuft bei jeder Nutzeranfrage, muss schnell sein). Diese beiden dürfen nie vermischt werden.
Ingestion-Pipeline
Schritt 1: Dokumentenverarbeitung
Jeder Dokumenttyp braucht korrekte Verarbeitung. PDFs benötigen Layout-bewusstes Parsing — Tabellen, Überschriften und Fußnoten sind relevant. Tools wie PyMuPDF oder pdfplumber liefern hier gute Ergebnisse. Für Word- und HTML-Dateien sollte Boilerplate (Header, Footer) vor dem Chunking entfernt werden.
Praxistipp: Alle Dokumente vor dem Chunking in normalisiertes Markdown umwandeln. So lässt sich dieselbe Chunking-Logik formatunabhängig verwenden.
Schritt 2: Chunking-Strategie
Keine festen Zeichenlängen verwenden. Stattdessen semantisches Chunking basierend auf der Dokumentstruktur: Absatzgrenzen, Abschnittsüberschriften oder Satzgruppierungen. Bei juristischen oder Compliance-Dokumenten nach Paragraphen bzw. Klauseln aufteilen — das sind die natürlichen Retrieval-Einheiten.
chunks = split_by_headers(doc, max_tokens=512)
# Schlecht: feste Zeichenlänge (zerstört Kontext)
chunks = [doc[i:i+512] for i in range(0, len(doc), 512)]
Overlap zwischen Chunks (10–15% empfohlen) verhindert Informationsverlust an Chunk-Grenzen. Den Overlap in Metadaten speichern, nicht im Content, um doppeltes Retrieval zu vermeiden.
Schritt 3: Embedding + Speicherung
Für die Produktion eignet sich pgvector. Es verarbeitet Millionen von Vektoren effizient, integriert sich in den vorhandenen PostgreSQL-Stack und unterstützt HNSW-Indizes für Sub-Millisekunden-ANN-Suche. Chunk-Inhalt, Metadaten (Quelldatei, Seite, Abschnitt, Datum) und Embedding in derselben Tabelle speichern.
CREATE TABLE chunks (
id uuid PRIMARY KEY,
content text,
metadata jsonb,
embedding vector(1536)
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);
Query-Pipeline
Schritt 4: Hybride Suche
Semantische Suche (Vektor-Ähnlichkeit) mit Keyword-Suche (BM25 oder PostgreSQL-Volltextsuche) kombinieren. Semantische Suche versteht konzeptuelle Anfragen; Keyword-Suche findet exakte Begriffe, Codes und Eigennamen. Keine der beiden allein reicht aus.
Ergebnisse mit Reciprocal Rank Fusion (RRF) zusammenführen — einfach, parameterfrei und in der Praxis besser als gewichtete Mittelwerte.
Schritt 5: Reranking
Nach dem initialen Retrieval die Top-20-Ergebnisse durch einen Cross-Encoder-Reranker schicken. Modelle wie bge-reranker-v2-m3 vergleichen Query und Dokument direkt und verbessern die Präzision der finalen Top-5 deutlich.
Schritt 6: LLM-Antwortgenerierung
Das LLM bekommt die rerankten Chunks als Kontext und generiert eine Antwort mit Quellenangaben. Wichtig: Immer eine System-Prompt verwenden, die das Modell anweist, nur aus den bereitgestellten Quellen zu antworten und bei Unsicherheit dies klar zu kommunizieren.
Produktionsreife Optimierungen
Caching
Häufige Anfragen mit Redis cachen. Embedding-Cache für wiederkehrende Queries spart Kosten und senkt die Latenz auf unter 200ms für Cache-Hits.
Streaming-Antworten
Server-Sent Events (SSE) für die LLM-Antwort verwenden. Der Nutzer sieht sofort die ersten Tokens, während der Rest generiert wird. Gefühlte Latenz sinkt von 3 Sekunden auf unter 500ms.
Monitoring
Retrieval-Qualität messen: Precision@5, Recall und Nutzerzufriedenheit tracken. Ohne Monitoring weiß man nicht, ob das System schleichend an Qualität verliert, wenn neue Dokumente hinzukommen.
Fazit
Produktive RAG-Pipelines erfordern Entscheidungen auf jeder Ebene: Layout-bewusstes Parsing, semantisches Chunking, hybride Suche, Reranking und Antwort-Streaming. Keiner dieser Schritte ist optional, wenn das System skalieren und zuverlässig korrekte Antworten liefern soll.
Der wichtigste Grundsatz: Ingestion und Query sind zwei getrennte Systeme. Wer sie sauber trennt, kann jede Komponente unabhängig optimieren, testen und skalieren.
RAG-Pipeline für Ihr Unternehmen?
Rogue AI baut produktive RAG-Systeme — von der Dokumentenverarbeitung bis zur Antwortgenerierung mit Quellenangaben.
Projekt besprechen