RAG Pipelines im Enterprise — Retrieval-Augmented Generation in der Praxis

Retrieval-Augmented Generation (RAG) ist zum De-facto-Standard für Enterprise-KI-Anwendungen geworden, die mit internen Daten arbeiten müssen. Aber zwischen „funktioniert in der Demo” und „funktioniert in der Produktion” liegt eine Kluft. Wie überbrückt man sie?

Warum RAG und warum jetzt¶

Das Fine-Tuning von LLM-Modellen auf Unternehmensdaten ist teuer, langsam und schwer zu warten. RAG bietet eine elegante Alternative: Halten Sie das Modell allgemein und liefern Sie relevanten Kontext zur Laufzeit. Im Jahr 2026 verfügen wir über ausgereifte Embedding-Modelle, stabile Vektordatenbanken und genügend Produktionserfahrung, um zu wissen, was funktioniert.

Typische Enterprise-Anwendungsfälle umfassen interne Wissensdatenbanken (Dokumentation, Wiki, Prozesse), Kundensupport über Produktdokumentation, Compliance — Suche in Vorschriften und internen Richtlinien sowie Vertrags- und Rechtsdokumentenanalyse.

RAG-Pipeline-Architektur im Jahr 2026¶

Eine moderne RAG-Pipeline hat vier Schlüsselphasen:

• Ingestion: Verarbeitung von Quelldokumenten — Parsing, Bereinigung, Chunking
• Indexing: Generierung von Embeddings und Speicherung in einer Vektordatenbank
• Retrieval: Finden relevanter Chunks basierend auf der Anfrage
• Generation: Zusammenstellung des Prompts mit Kontext und Generierung der Antwort

Jede Phase hat ihre Fallstricke. Schauen wir sie uns im Detail an.

Chunking — Die Grundlage des Erfolgs¶

Chunking ist der am meisten unterschätzte Teil der RAG-Pipeline. Schlechtes Chunking = schlechte Ergebnisse, unabhängig von der Modellqualität. Diese Strategien haben sich in der Praxis bewährt:

• Semantisches Chunking: Statt fester Länge Text an semantischen Grenzen teilen — Überschriften, Absätze, thematische Einheiten. Erfordert Preprocessing, verbessert aber die Retrieval-Qualität dramatisch.
• Überlappung mit Kontext: 10–20 % Überlappung zwischen Chunks stellt sicher, dass Informationen an den Grenzen nicht verloren gehen. Metadaten werden ebenfalls hinzugefügt — Dokumentname, Abschnitt, Datum.
• Hierarchisches Chunking: Zwei Ebenen — Parent Chunks (breiterer Kontext) und Child Chunks (Detail). Retrieval sucht auf Child-Ebene, aber der Parent Chunk wird in den Prompt eingefügt.

Die optimale Chunk-Größe hängt vom Anwendungsfall ab. Für faktisches Q&A typischerweise 256–512 Token, für analytische Aufgaben 512–1024 Token. Immer an realen Daten messen.

Embedding-Modelle — Auswahl und Trade-offs¶

Im Jahr 2026 können wir aus mehreren Embedding-Modell-Kategorien wählen:

• OpenAI text-embedding-3-large: Solide Performance, einfache Integration, aber Daten verlassen den Perimeter
• Cohere embed-v4: Starke multilinguale Performance, geeignet für tschechische Daten
• Open-Source (nomic-embed, BGE, E5): On-Premise hostbar, volle Datenkontrolle
• Domänenspezifische Modelle: Fine-tuned Embeddings für eine bestimmte Domäne — beste Performance, erfordert aber Trainingsinvestition

Für tschechische Enterprise-Kunden empfehlen wir typischerweise einen hybriden Ansatz: Open-Source-Modell On-Premise für sensible Daten, kommerzielle API für weniger sensible Anwendungsfälle.

Retrieval — Mehr als nur Cosine Similarity¶

Naives RAG verlässt sich auf Vektorähnlichkeit. In der Praxis reicht das nicht. Eine moderne Retrieval-Pipeline kombiniert:

• Hybridsuche: Vektorsuche + BM25 (Keyword-Suche). Fusion-Algorithmus (RRF — Reciprocal Rank Fusion) kombiniert Ergebnisse beider Ansätze.
• Query-Transformation: Vor der Suche die Anfrage transformieren — Synonym-Erweiterung, Zerlegung komplexer Fragen in Sub-Queries, HyDE (Hypothetical Document Embeddings).
• Reranking: Ein Cross-Encoder-Modell ordnet die Top-K-Ergebnisse der ersten Runde neu. Langsamer, aber deutlich genauer. Cohere Rerank oder Open-Source-Alternativen (BGE-reranker).
• Metadaten-Filterung: Filterung nach Datum, Abteilung, Dokumenttyp — reduziert Rauschen und beschleunigt Retrieval.

Vektordatenbanken — Technologiewahl¶

Der Vektordatenbank-Markt hat sich 2026 konsolidiert. Hauptoptionen:

• pgvector (PostgreSQL): Wenn Sie bereits Postgres haben, ein guter Start. HNSW-Indizes bewältigen Millionen von Vektoren. Vorteil: eine Datenbank für alles.
• Qdrant: Rust-basiert, hohe Performance, gute Filterung. In der EU beliebt wegen On-Premise-Deployment-Optionen.
• Weaviate: Integrierte Vektorisierung, GraphQL-API, Multi-Tenancy. Geeignet für SaaS-Plattformen.
• Managed Services (Pinecone, Azure AI Search): Einfachster Betrieb, aber Daten in der Cloud des Anbieters.

Für die meisten Enterprise-Projekte empfehlen wir pgvector als Startpunkt — es minimiert die operationelle Komplexität und die meisten Teams kennen Postgres bereits.

Evaluierung — Wie man RAG-Qualität misst¶

Ohne systematische Evaluierung wissen Sie nicht, ob die RAG-Pipeline tatsächlich funktioniert. Wir messen auf drei Ebenen:

• Retrieval-Qualität: Precision@K, Recall@K, MRR (Mean Reciprocal Rank) — liefert der Retriever relevante Dokumente?
• Generierungsqualität: Faithfulness (stimmt die Generierung mit dem Kontext überein?), Relevanz (beantwortet sie die Frage?), Vollständigkeit
• End-to-End: Benutzerzufriedenheit, Korrektheit der Antwort verifiziert durch einen Domänenexperten

Frameworks wie RAGAS automatisieren die Evaluierung mittels LLM-as-Judge-Ansatz. Aber Vorsicht — automatische Evaluierung ist nur indikativ. Für Produktionssysteme ist regelmäßige menschliche Evaluierung an einer Datenstichprobe unerlässlich.

Häufige Fehler und wie man sie vermeidet¶

• Preprocessing ignorieren: Garbage in, garbage out. Investieren Sie in Datenbereinigung — Duplikatentfernung, Tabellenparsen, Extraktion aus PDFs.
• Zu viel Kontext: Mehr Chunks ≠ bessere Antworten. Der „Lost in the Middle”-Effekt bewirkt, dass das Modell relevante Informationen in der Mitte eines langen Kontexts ignoriert.
• Fehlende Observability: Loggen Sie jeden Pipeline-Schritt — welche Chunks zurückgegeben wurden, was der Confidence Score war, wie der finale Prompt aussah.
• Statische Pipeline: Daten ändern sich; die Pipeline muss Aktualisierungen widerspiegeln. Implementieren Sie inkrementelle Indexierung und Versionierung.

RAG ist eine Ingenieursdisziplin, keine Magie¶

Eine qualitativ hochwertige RAG-Pipeline erfordert dieselbe Ingenieurdisziplin wie jedes andere Produktionssystem. Chunking, Embedding, Retrieval, Evaluierung — jeder Schritt erfordert Messung, Iteration und Optimierung an realen Daten.

Unser Tipp: Beginnen Sie mit einer einfachen Pipeline, messen Sie Baseline-Metriken und iterieren Sie dann. Die meisten Verbesserungen kommen von besserem Chunking und Reranking, nicht vom Austausch des LLM-Modells.