Warum die meisten RAG-Deployments scheitern, bevor sie live gehen

Ein Legal-Team eines mittelgroßen Finanzdienstleisters baut vier Monate lang ein RAGRAGVerfahren, mit dem ein KI-Modell aus Ihren eigenen Dokumenten antwortet, indem es relevante Passagen abruft, bevor es eine Antwort erzeugt.Vollständige Definition ansehen →-System, mit dem Analysten interne Compliance-Dokumente abfragen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen. Die Demo läuft hervorragend. Sechs Wochen nach dem Go-live ist die Nutzung um 70 % eingebrochen. Die Analysten sagen, die Antworten „fühlen sich falsch an", und sind zur Keyword-Suche zurückgekehrt. Das Modell war in Ordnung. Das Problem war die Retrieval-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →, und niemand hatte sie separat gemessen.

Diese Geschichte spielt sich, mit kleinen Abweichungen bei Branche und Dokumententyp, 2026 ständig in Enterprise-KI-Programmen ab. RAG ist zur dominierenden Architektur geworden, um LLMs in Organisationen mit sensiblen oder spezialisierten Daten zu bringen, doch die Ausfallrate in der Produktion bleibt hartnäckig hoch. Wer verstehen will, warum, muss die drei unterschiedlichen Stellen trennen, an denen diese Systeme tatsächlich brechen.

Wo RAG wirklich bricht

Die meisten Teams behandeln RAG als ein einziges System, das man ganzheitlich bewertet. Diese Sichtweise ist der erste Fehler. RAG ist eine Pipeline mit mindestens drei unabhängigen Failure Modes: die Retrieval-Schicht, die Context Assembly und der Generierungsschritt. Wer sie vermischt, macht eine Diagnose praktisch unmöglich.

Retrieval ist der stille Killer

Das LLMLLMEin Large Language Model ist ein KI-System, das auf riesigen Textmengen trainiert wurde, um Sprache vorherzusagen und zu erzeugen. Damit sind Aufgaben wie Schreiben, Zusammenfassen und Beantworten von Fragen möglich.Vollständige Definition ansehen → am Ende einer RAG-Pipeline ist meist die unproblematischste Komponente. GPT-4o, Claude 3.5 Sonnet und Gemini 1.5 Pro können durchaus gut formulierte Antworten synthetisieren, wenn sie guten Context bekommen. Die Retrieval-Schicht dagegen ist die Stelle, an der die meisten Produktionssysteme unauffällig auseinanderfallen.

Der Kern des Problems: Dense VectorDense VectorEin Embedding ist ein numerischer Vektor, der Daten (Text, Bilder oder Objekte) so darstellt, dass ihre Bedeutung erfasst wird: Ähnliche Elemente liegen im Raum dicht beieinander.Vollständige Definition ansehen → Search, die mit besseren EmbeddingEmbeddingEin Embedding ist ein numerischer Vektor, der Daten (Text, Bilder oder Objekte) so darstellt, dass ihre Bedeutung erfasst wird: Ähnliche Elemente liegen im Raum dicht beieinander.Vollständige Definition ansehen →-Modellen zur Standardmethode fürs Retrieval wurde, funktioniert gut bei semantischer Ähnlichkeit, versagt aber bei Präzisionsaufgaben. Fragen Sie „Wie hoch war unsere Bruttomarge in Q3 2024?", und eine Cosine-Similarity-Suche über einen Vector StoreVector StoreEine Vector Database speichert Daten als hochdimensionale numerische Vektoren (Embeddings) und findet Inhalte über Ähnlichkeit statt über exakte Treffer. Sie ist die Grundlage für semantische Suche und KI-Anwendungen.Vollständige Definition ansehen → mit Finanzdokumenten liefert häufig Passagen, die semantisch benachbart, numerisch aber falsch sind oder aus einem völlig anderen Zeitraum stammen. Das Modell synthetisiert daraus eine selbstbewusste, flüssige, falsche Antwort.

Hybrid Retrieval, also die Kombination von Dense Vector Search mit BM25 oder anderen Sparse-Keyword-Methoden, schließt einen großen Teil dieser Lücke. Cohere, Weaviate und Elastic haben Benchmarks veröffentlicht, die mit hybriden Ansätzen deutliche Recall-Verbesserungen auf domänenspezifischen Korpora zeigen. Das sind allerdings Herstellerzahlen, die Sie gegen Ihre eigene Dokumentenverteilung validieren sollten, bevor Sie sie als Garantie nehmen.

Die Chunking-Strategie verstärkt Retrieval-Fehler auf Weisen, die vor der Produktion selten sichtbar werden. Fixed-Size-Chunking bei 512 oder 1024 TokensTokensEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →, der Standard in den meisten Tutorials und Starter Kits, schneidet regelmäßig Sätze mitten im Gedanken ab und trennt Tabellen von ihren Headern. Ein abgerufener Chunk mit dem Inhalt „stieg um 14 % gegenüber der Vorperiode" ist ohne den umgebenden Context, der festlegt, was gestiegen ist und welche Vorperiode gemeint ist, nahezu wertlos. Semantic Chunking, das an Bedeutungsgrenzen statt an TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →-Zahlen trennt, reduziert dieses Problem deutlich, erhöht aber Verarbeitungskomplexität und Kosten.

Context Assembly: das Problem, über das niemand spricht

Nehmen wir an, das Retrieval funktioniert korrekt und liefert die fünf relevantesten Passagen. Der nächste Failure Point ist, wie diese Passagen im Prompt zusammengesetzt werden. Die Reihenfolge spielt eine größere Rolle, als die meisten Praktiker erwarten. Forschung von Teams in Stanford und bei DeepMind hat das Phänomen „lost in the middle" dokumentiert: LLMs gewichten Informationen in der Mitte langer Contexts systematisch geringer als Inhalte am Anfang oder Ende. Landet Ihr relevantester abgerufener Chunk auf Position drei von fünf, kann das Modell ihn faktisch abwerten.

Ein Re-Ranking der abgerufenen Passagen vor dem Zusammensetzen des Prompts, mit einem Cross-Encoder-Modell wie denen von Cohere (ein Anbieter mit direktem kommerziellem Interesse an dieser Empfehlung) oder Open-Source-Alternativen wie BGE-Reranker, löst das, indem die Chunks nach Relevanz neu sortiert werden, bevor das LLM sie sieht. Die Latenzkosten sind real, typischerweise 100 bis 300 ms zusätzlich pro Query, und dieser Tradeoff sollte bewusst entschieden werden.

Generierungsfehler sind meist getarnte Retrieval-Fehler

Wenn Nutzer melden, ein RAG-System „erfinde Dinge", liegt die Ursache fast immer darin, dass das Retrieval irrelevanten oder unzureichenden Context liefert. Das Modell halluziniert nicht im umgangssprachlichen Sinn, es tut genau das, wofür es gebaut wurde: eine plausible Vervollständigung zum verfügbaren Context erzeugen. Ist dieser Context schlecht, ist die Vervollständigung selbstbewusst falsch.

Die Lösung ist nicht Prompt EngineeringPrompt EngineeringPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen →. Ein „nutze ausschließlich die bereitgestellten Dokumente" im System-Prompt senkt die Halluzinationsrate bei saubere Retrievals durchaus, bringt aber fast nichts, wenn der abgerufene Context tatsächlich irreführend oder unvollständig ist. Die Retrieval-Qualität unabhängig zu messen, mit Metriken wie Context Precision und Context Recall aus dem RAGAS-Evaluation-Framework, ist der einzige Weg, um herauszufinden, welche Schicht wirklich versagt.

Was das für Teams bedeutet, die RAG bauen oder einkaufen

Wenn Ihre Organisation ein RAG-System ausrollt, ist die Evaluations-Architektur genauso wichtig wie die Systemarchitektur selbst. Etablieren Sie vor dem Launch getrennte Benchmarks für Retrieval-Qualität und Generierungsqualität. Führen Sie sie gegen eine repräsentative Stichprobe echter Nutzer-Queries aus, nicht gegen synthetische, die das Team entworfen hat, das das System gebaut hat.

Die Dokumenten-Vorverarbeitung verdient mehr Investment, als sie üblicherweise bekommt. PDFs mit komplexen Layouts, gescannte Dokumente und in Slides eingebettete Tabellen sind die Orte, an denen das meiste Unternehmenswissen tatsächlich liegt, und genau dort arbeiten Standard-Ingestion-Pipelines am schlechtesten. Tools wie LlamaParse (von LlamaIndex, einem Anbieter) und AWS Textract bewältigen strukturierte Extraktion zuverlässiger als generische PDF-Parser, aber keines von beiden ist eine vollständige Lösung für Dokumentenbibliotheken mit gemischten Formaten.

Für Teams, die RAG-Produkte von Anbietern bewerten: Fragen Sie konkret, wie das Produkt mit Retrieval-Fehlern umgeht, nicht nur mit Halluzinationen. Eine saubere Demo kann jeder Anbieter zeigen. Lassen Sie sich das Verhalten zeigen, wenn der abgerufene Context mehrdeutig oder widersprüchlich ist, denn so wird Ihre Produktionsumgebung die meiste Zeit aussehen.

Konkrete Schritte vor dem nächsten Sprint

• Instrumentieren Sie Ihre Retrieval-Schicht unabhängig von der Generierung. Loggen Sie für jede Query, was abgerufen wurde, nicht nur die finale Antwort.
• Schicken Sie vor dem Launch mindestens 50 echte Nutzer-Queries durch das System und prüfen Sie die abgerufenen Chunks manuell, nicht die generierten Outputs.
• Wenn Ihre Dokumente Tabellen, Datumsangaben oder numerische Daten enthalten, testen Sie Hybrid Retrieval gegen reine Vector Search auf genau diesen Query-Typen, bevor Sie sich standardmäßig für eines von beiden entscheiden.
• Setzen Sie früh ein Latenzbudget und rechnen Sie das Re-Ranking in dieses Budget ein, denn es ist der Schritt, der unter Zeitdruck am häufigsten wegfällt und die Antwortqualität am stärksten beeinflusst.
• Behandeln Sie „das Modell hat halluziniert" als Ausgangshypothese, nicht als Schlussfolgerung. Verfolgen Sie den Fehler bis zum Retrieval-Schritt zurück, bevor Sie Prompts oder Modellparameter ändern.

Das Compliance-Team bei diesem Finanzdienstleister hat sein System schließlich in Ordnung gebracht, nicht durch einen Modellwechsel, sondern durch BM25-Hybrid-Retrieval und den Umstieg auf Semantic Chunking. Die Nutzung erholte sich innerhalb von drei Wochen nach dem erneuten Rollout. Die Lösung war technisch, aber der Insight, der sie ermöglichte, war organisatorisch: Irgendwann hat jemand Retrieval und Generierung als getrennte Probleme gemessen.