Enterprise-RAG-Pipelines aufbauen: Architektur, Stolperfallen und Best Practices

Retrieval-Augmented Generation (RAG) hat sich als Standardmuster etabliert, um Large Language Models mit unternehmenseigenem Wissen zu versorgen. Doch die meisten RAG-Prototypen schaffen es nie in die Produktion. Der Abstand zwischen einer Demo, die „meistens funktioniert", und einem System, das verlässliche, nachvollziehbare Antworten liefert, ist größer als die meisten Teams erwarten.

Bei CC Conceptualise haben wir RAG-Pipelines für Mandanten aus Recht, Finanzdienstleistungen und Fertigung aufgebaut. Dieser Leitfaden fasst die Architekturentscheidungen zusammen, die den größten Einfluss haben.

Die Referenzarchitektur

Eine produktionsreife RAG-Pipeline besteht aus fünf Schichten — und jede einzelne kann die Antwortqualität stillschweigend verschlechtern, wenn sie falsch konfiguriert ist:

1. Ingestion — Dokumentenparsing, Formatnormalisierung, Metadatenextraktion
2. Chunking — Zerlegung der Dokumente in abrufbare Einheiten
3. Embedding — Umwandlung der Chunks in dichte Vektoren
4. Indexierung & Retrieval — Speicherung der Vektoren und Abruf relevanter Chunks zur Abfragezeit
5. Generierung — Übergabe des abgerufenen Kontexts an ein LLM zur Antwortsynthese

Faustregel: Wenn die Antwortqualität schlecht ist, liegt das Problem fast immer in den Schichten 1–4 — nicht im LLM selbst.

Chunking-Strategien, die in der Praxis funktionieren

Chunking ist die Stelle, an der die meisten Pipelines zuerst scheitern. Drei Ansätze, nach steigender Komplexität:

Fixed-Size-Chunking

Alle N Token aufteilen mit M Token Überlappung. Einfach, vorhersagbar, aber semantisch blind. Ein 512-Token-Chunk kann eine Tabelle halbieren oder eine Überschrift von ihrem Inhalt trennen.

• Einsatzbereich: Homogene Textkorpora (z. B. Transkripte, reine Textdatenbanken)
• Typische Einstellungen: 256–512 Token, 50–100 Token Überlappung

Semantisches Chunking

Satzgrenzen und Themenwechsel nutzen, um Chunks variabler Länge zu erzeugen. Bibliotheken wie LangChains SemanticChunker oder LlamaIndex' SentenceSplitter implementieren diesen Ansatz.

• Einsatzbereich: Dokumente mit gemischten Formaten, längere Berichte
• Vorsicht: Zu kleine Chunks verlieren Kontext; zu große verwässern die Relevanz

Dokumentstruktur-bewusstes Chunking

Die native Struktur des Dokuments — Überschriften, Abschnitte, Tabellen, Listen — wird erkannt und als Chunk-Grenze verwendet. Diesen Ansatz empfehlen wir für Enterprise-Deployments.

• Tabellenintegrität wahren. Eine über zwei Chunks verteilte Tabelle ist nutzlos. Tabellen als eigenständige Chunks mit Beschriftung extrahieren.
• Überschriften-Hierarchien beibehalten. Übergeordnete Überschriften jedem Chunk voranstellen, damit das Retrieval den Kontext versteht.
• Metadaten mitführen. Quelldokument, Seitenzahl, Abschnittstitel und Änderungsdatum müssen mit jedem Chunk gespeichert werden.

Embedding-Modell auswählen

Das Embedding-Modell bestimmt, wie gut Ihr Retrieval semantische Ähnlichkeit erkennt. Die wichtigsten Entscheidungskriterien:

Faktor	Empfehlung
Dimensionalität	768–1536 Dimensionen sind der Sweet Spot. Höhere Werte verbessern den Recall, erhöhen aber Speicher und Latenz.
Mehrsprachigkeit	Für deutsch-englische Korpora eignen sich multilinguale Modelle wie e5-large-v2 oder Azures text-embedding-3-large.
Domänen-Feintuning	Allgemeine Embeddings liefern bei Fachvokabular schlechtere Ergebnisse. Ab einem Recall unter 85 % lohnt sich domänenspezifisches Fine-Tuning.
Maximale Tokenlänge	Modelle kürzen über ihr Limit hinaus. Wenn Ihre Chunks 512 Token überschreiten, wählen Sie ein Modell mit 8192-Token-Kontext.

Unsere Empfehlung für Azure-zentrierte Organisationen: Starten Sie mit text-embedding-3-large über Azure OpenAI. Es verarbeitet mehrsprachige Inhalte zuverlässig und integriert sich nativ in Azure AI Search.

Vektordatenbank: Managed Service oder Eigenbetrieb?

Die Wahl der Vektordatenbank hat langfristige betriebliche Konsequenzen:

Azure AI Search (Empfehlung für die meisten Azure-Unternehmen)

• Vorteile: Managed Service, hybride Suche (Vektor + Keyword + Semantic Ranking), Azure-RBAC-Integration, Metadaten-Filterung
• Nachteile: Kosten skalieren mit Indexgröße; eingeschränkte Kontrolle über HNSW-Parameter
• Geeignet für: Teams, die produktionsreifes Retrieval ohne eigenen Infrastrukturbetrieb wollen

Dedizierte Vektordatenbanken (Qdrant, Weaviate, Pinecone)

• Vorteile: Feingranulare Anpassung der Index-Parameter, oft besserer Recall bei großen Datenmengen
• Nachteile: Ein weiterer Dienst, den man betreiben, absichern und überwachen muss
• Geeignet für: Teams mit spezifischen Performance-Anforderungen oder Multi-Cloud-Strategie

PostgreSQL mit pgvector

• Vorteile: Keine neue Infrastruktur, wenn Postgres bereits im Einsatz ist; transaktionale Konsistenz mit relationalen Daten
• Nachteile: Performance lässt ab ~5 Mio. Vektoren spürbar nach; begrenzte Filtermöglichkeiten
• Geeignet für: Prototypen oder kleine Korpora unter 1 Mio. Chunks

Retrieval-Qualität: Die Metriken, die zählen

Bewerten Sie RAG-Qualität nicht nach Gefühl. Legen Sie quantitative Baselines fest:

• Recall@k — Wie viele der tatsächlich relevanten Chunks erscheinen in den Top-k-Ergebnissen? Zielwert: >90 % bei k=10.
• Precision@k — Wie viele der abgerufenen Chunks sind tatsächlich relevant? Niedrige Precision bedeutet, dass das LLM Rauschen erhält.
• Mean Reciprocal Rank (MRR) — Wie hoch rankt der erste relevante Chunk? Entscheidend für Kostenoptimierung, denn weniger Chunks bedeuten weniger Token.

Erstellen Sie ein Golden Dataset. 50–100 Frage-Antwort-Paare mit annotierten Quell-Chunks. Führen Sie Retrieval-Evaluierungen bei jeder Pipeline-Änderung durch. Diese eine Maßnahme verhindert mehr Regressionen als jede andere.

Halluzinierung eindämmen

RAG reduziert Halluzinierungen, eliminiert sie aber nicht. Schutzmaßnahmen:

• Quellen explizit zitieren. Das LLM anweisen, Chunk-IDs oder Dokumentnamen zu referenzieren. Wenn es keine Quelle nennen kann, soll es das klar kommunizieren.
• Konfidenz-Schwellenwert setzen. Wenn der Top-Retrieval-Score unter einem Schwellenwert liegt, „Ich habe dazu nicht genügend Informationen" zurückgeben statt zu raten.
• Strukturierte Ausgabe verwenden. Antworten als JSON mit den Feldern answer, sources und confidence zurückgeben. Das ermöglicht programmatische Validierung.
• Human-in-the-Loop für kritische Bereiche. In regulierten Branchen sollten RAG-Antworten bei grenzwertiger Konfidenz zur manuellen Prüfung markiert werden.

Aus der Praxis: Ein Finanzdienstleister konnte die Halluzinierungsrate von 12 % auf unter 2 % senken — durch die Kombination aus erzwungener Quellenangabe und einem Retrieval-Score-Schwellenwert von 0,78 auf dem Semantic Ranker von Azure AI Search.

Betriebliche Aspekte

Kostenmanagement

Embedding-Generierung ist ein einmaliger Aufwand pro Dokument, aber Re-Indexierung bei Schemaänderungen kann teuer werden. Planen Sie Ihr Chunk-Schema sorgfältig, bevor Sie Millionen von Dokumenten einlesen.

Aktualität

Legen Sie frühzeitig eine Update-Strategie fest. Nächtliche Vollindexierung? Inkrementelle Updates über Change Feeds? Azure AI Search unterstützt Indexer mit Change Tracking auf Blob Storage und Cosmos DB.

Sicherheit

Enterprise-RAG-Pipelines indexieren häufig vertrauliche Dokumente. Implementieren Sie dokumentbasierte Zugriffssteuerung in Ihrer Retrieval-Schicht. Azure AI Search unterstützt Security-Filter — nutzen Sie diese, um sicherzustellen, dass Nutzer nur Chunks abrufen, für die sie autorisiert sind.

Erste Schritte

Wenn Sie RAG für Ihre Organisation evaluieren, starten Sie mit diesen drei Schritten:

1. Dokumentenkorpus auditieren. Formate, Sprachen, durchschnittliche Dokumentenlänge und Schutzklassifizierung katalogisieren.
2. Golden Evaluation Set erstellen. Mindestens 50 Fragen mit annotierten Quellpassagen.
3. Prototyp mit Azure AI Search + Azure OpenAI bauen. Diese Kombination liefert in Tagen, nicht Wochen, eine produktionsreife Baseline.

Weiterführende Ressourcen

• EU AI Act: Was Engineering-Teams jetzt umsetzen müssen — Wenn Ihr RAG-System Hochrisiko-Entscheidungen trifft, verstehen Sie die Compliance-Anforderungen.
• Data-Lakehouse-Architektur auf Azure — Die Datenschicht, die Ihre RAG-Pipeline mit verwalteten, qualitätsgesicherten Daten versorgt.
• LLMs im Unternehmen: Sicherheit, Kosten und Governance — Deckt die LLM-Schicht ab, die auf Ihrer RAG-Pipeline aufsetzt.

Sie benötigen Unterstützung beim Design einer RAG-Architektur für Ihren konkreten Anwendungsfall? Sprechen Sie uns an — wir haben das branchenübergreifend umgesetzt und teilen gerne unsere Erfahrungen.