Woran RAG-Projekte scheitern: vier Fehler jenseits der Technik

Der Assistent der Serviceabteilung läuft, die Technik ist sauber gebaut: Chunking an der Struktur, Hybrid Search, Reranking. Trotzdem nennt er einem Techniker die Wartung nach einer Anleitung, die längst überholt ist. Die Suche hat die alte Fassung gefunden, zuverlässig und auf Platz 1. Das Problem liegt nicht im Algorithmus, sondern in dem, was im Index steht.

Das ist der sechste und letzte Teil der Reihe über RAG. Nach der Technik der fünf vorigen Teile geht es um vier Fehler, an denen RAG-Projekte in der Praxis oft scheitern.

Warum du das brauchst

Die Technik lässt sich testen und verbessern, sobald sie einmal läuft. Die vier Fehler dieses Beitrags sind tückischer, weil sie sich nicht als Fehler melden. Das System antwortet, die Antworten klingen gut, und erst ein Techniker an der Pumpe oder eine Datenschutzbeauftragte bemerkt, dass etwas nicht stimmt. Wer sie früh kennt, kann sie im Projektplan unterbringen, bevor sie im Betrieb auffallen. Dazu passt der Befund einer Fallstudie mit drei RAG-Systemen (Barnett et al., 2024): Sie nennt sieben Fehlerpunkte und hält fest, dass sich ein RAG-System erst im Betrieb wirklich validieren lässt.

Wie es funktioniert: vier Fehlerfelder

1. Schlechte Quelldaten

Veraltete, doppelte oder widersprüchliche Dokumente werden genauso gut gefunden wie gültige und dann falsch zitiert. Das Retrieval weiß nicht, welche Fassung gilt. Liegen die alte und die neue Fassung einer Anleitung im Index, ist der Widerspruch im Index später ein Widerspruch in der Antwort. Aufräumen ist deshalb Teil des Projekts und keine Vorarbeit: Jedes Dokument braucht einen Verantwortlichen und ein Gültigkeitsdatum.

2. Kaputtes Parsing

Tabellen, Scans und mehrspaltige PDFs können beim Einlesen ihre Struktur verlieren. Eine Störcode-Tabelle, aus der Zeilen und Spalten durcheinander ausgelesen wurden, liefert Chunks, die gut aussehen und falsch sind. Das fällt oft erst auf, wenn eine Antwort falsch ist. Sieh dir den eingelesenen Text mit eigenen Augen an, bevor du indexierst.

3. Vergessene Berechtigungen

Wenn jeder alle Chunks finden kann, beantwortet der Assistent auch Fragen zu Dokumenten, die die fragende Person nie sehen dürfte, im Servicekontext etwa zu Preislisten oder internen Kalkulationen. Die Zugriffsrechte (ACLs) gehören beim Indexieren mitgespeichert und bei der Suche als Filter angewendet. Eine Anweisung im Prompt ersetzt das nicht: Was im Prompt steht, hat das Modell schon gesehen.

4. Keine Messung

Ohne Testfragen mit bekannter Antwort ist jede Änderung am System Bauchgefühl. Du sammelst Fragen, deren richtige Quelle du kennst, und misst die Suche mit Recall@k (steht die richtige Quelle unter den ersten k Treffern?), MRR (wie weit vorn steht der erste richtige Treffer?) und nDCG (wie gut ist die Reihenfolge?), die Antwort mit Faithfulness (welcher Anteil der Aussagen lässt sich aus den gefundenen Quellen belegen?) und der Relevanz der Antwort zur Frage. Erst dann siehst du, ob eine Änderung etwas verbessert hat und ob ein Fehler im Retrieval oder in der Generierung liegt.

Wie diese Fehler im laufenden Betrieb aussehen können, habe ich in Warum die Wissenssuche nichts findet beschrieben.

Das Labor ist ein Selbstcheck mit acht Fragen, je zwei zu jedem Feld. Beantworte sie für dein eigenes Projekt oder ein Projekt, das du kennst. Jedes Feld bekommt eine Ampel, und für jedes Nein erscheint ein konkreter nächster Schritt.

Worauf du achten solltest

• Reihenfolge nach Risiko. Berechtigungen zuerst, wenn der Assistent mehr als eine Abteilung bedient. Ein Fehler hier ist kein Qualitätsmangel, sondern ein Datenschutzproblem.
• Ein Verantwortlicher je Dokument. Wer ein Dokument pflegt, steht in den Metadaten. Sonst weiß keiner, wann es veraltet.
• Stichproben statt Vertrauen. Sieh dir geparste Tabellen, Scans und mehrspaltige PDFs an, bevor sie in den Index gehen, und wiederhole das, wenn sich Dokumentarten ändern.
• Eine kleine Testmenge reicht für den Anfang. Fang mit den Fragen an, die ein Techniker am häufigsten stellt, und notiere die richtige Quelle dazu. Die Menge wächst mit jedem Fehler, der im Betrieb auffällt.
• Nicht jede Frage ist eine RAG-Frage. Für Aufträge, Bestände und Kennzahlen fragt der Assistent besser das System selbst ab. Genau dafür gibt es das Model Context Protocol.

Fazit

Die Technik von RAG ist beherrschbar. Wo Projekte scheitern, liegt es oft an Daten, Einlesen, Rechten und fehlender Messung. Das sind keine Fragen für Algorithmen, sondern für Verantwortung und Disziplin. Damit endet der RAG-Teil der Reihe. Weiter geht es mit der Frage, wie ein Assistent nicht nur Texte durchsucht, sondern an Systeme angeschlossen wird: MCP erklärt.

Quellen

• Barnett et al.: Seven Failure Points When Engineering a Retrieval Augmented Generation System (2024), Fehlerpunkte in RAG-Systemen, Validierung erst im Betrieb möglich
• Ragas: Faithfulness (Dokumentation) (Stand 2026), Anteil der Aussagen einer Antwort, die durch den gefundenen Kontext gestützt sind
• Microsoft: Evaluate AI Search retrieval quality (Azure Databricks) (2026), Definitionen von Recall@k, MRR und nDCG@k
• Microsoft: Security filter pattern, Azure AI Search (2026), Berechtigungen im Index speichern und bei jeder Suche als Filter anwenden
• Microsoft: Develop a RAG Solution on Azure, Chunking Phase (2026), Chunking als Voraussetzung für RAG, Nachteile zu großer und zu kleiner Chunks, Layout-Analyse für Tabellen
• Microsoft: Develop a RAG Solution on Azure, Information-Retrieval Phase (2026), Auswertung der Suche mit Testfragen, Precision@k, Recall@k und MRR