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

Ein Legal-Team eines mittelgroßen Finanzdienstleisters baut vier Monate lang ein RAG-System, mit dem Analysten interne Compliance-Dokumente abfragen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.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-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.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 LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.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 VectorAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.Vollständige Definition ansehen → Search, die mit besseren EmbeddingEmbeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.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 StoreA vector database stores data as high-dimensional numeric vectors (embeddings) and retrieves items by similarity rather than exact matches, powering semantic search and AI applications.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 TokensTokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.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 TokenTokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.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 is the practice of designing and refining text inputs to guide large language models toward accurate, relevant, and reliable outputs.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.