Real-Time Data Mesh — Streaming-Datenarchitektur für Enterprise

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 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 inkludiert — 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 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. Modernes Retrieval kombiniert:

• Hybridsuche: Vektorsuche + BM25 (Keyword-Suche). Fusion-Algorithmus (RRF) kombiniert Ergebnisse beider Ansätze.
• Query-Transformation: Synonym-Erweiterung, Sub-Query-Zerlegung, HyDE (Hypothetical Document Embeddings).
• Reranking: Cross-Encoder-Modell ordnet Top-K-Ergebnisse neu. Langsamer, aber deutlich genauer.
• Metadaten-Filterung: Filterung nach Datum, Abteilung, Dokumenttyp — reduziert Rauschen und beschleunigt Retrieval.

Vektordatenbanken — Technologiewahl¶

Der Markt hat sich 2026 konsolidiert:

• pgvector (PostgreSQL): Guter Start, wenn Sie Postgres haben. HNSW-Indizes bewältigen Millionen von Vektoren.
• Qdrant: Rust-basiert, hohe Performance, gute Filterung. In der EU beliebt.
• Weaviate: Integrierte Vektorisierung, GraphQL-API, Multi-Tenancy.
• Managed Services (Pinecone, Azure AI Search): Einfachster Betrieb, aber Daten in der Cloud des Anbieters.

Für die meisten Projekte empfehlen wir pgvector — minimiert Komplexität und die meisten Teams kennen Postgres bereits.

Evaluierung — RAG-Qualität messen¶

Wir messen auf drei Ebenen:

• Retrieval-Qualität: Precision@K, Recall@K, MRR — liefert der Retriever relevante Dokumente?
• Generierungsqualität: Faithfulness, Relevanz, Vollständigkeit
• End-to-End: Benutzerzufriedenheit, Korrektheit der Antwort verifiziert durch Domänenexperten

RAGAS automatisiert die Evaluierung via LLM-as-Judge. Aber für die Produktion ist regelmäßige menschliche Evaluierung an einer Datenstichprobe unerlässlich.

Häufige Fehler¶

• Preprocessing ignorieren: Garbage in, garbage out.
• Zu viel Kontext: „Lost in the Middle”-Effekt — Modell ignoriert Informationen im Mittelbereich.
• Fehlende Observability: Loggen Sie jeden Pipeline-Schritt.
• Statische Pipeline: Daten ändern sich; implementieren Sie inkrementelle Indexierung.

RAG ist Engineering, keine Magie¶

Unser Tipp: Einfach anfangen, Baseline messen, iterieren. Die meisten Verbesserungen kommen von besserem Chunking und Reranking, nicht vom Austausch des LLM.