Wenn ein RAG-basierter Assistent — also einer, der mit den Dokumenten des Unternehmens antwortet — falsche Antworten gibt, ist die instinktive Reaktion immer dieselbe: „Wir brauchen ein stärkeres Modell“ oder „Wir schreiben den Prompt neu“. Fast immer ist das der falsche Zug — und obendrein der teuerste. Der Engpass liegt weiter vorn, in einer Komponente, über die wenig gesprochen wird: dem Retrieval, also der Suche, die entscheidet, welche Dokumente dem Modell vor die Augen kommen. Wenn das Dokument mit der Antwort nicht auf seinem Tisch landet, kann kein Modell — so groß es auch sein mag — sie erfinden.
Dies ist die natürliche Fortsetzung der fünf Lektionen aus unserer RAG-Plattform, in denen wir schrieben, dass „sich die Qualität im Retrieval entscheidet“. Hier erklären wir, warum — und vor allem, wie man es merkt, bevor man Geld ausgibt.
Die Zahl, die in den Präsentationen kursiert
Überall kursiert die Zahl „95% der Projekte mit generativer KI scheitern“. Sie stammt aus einem Report des MIT (The GenAI Divide, 2025), dem zufolge 95% der Pilotprojekte keine messbare Wirkung auf die Gewinn-und-Verlust-Rechnung erzielen — bei 30–40 Milliarden Dollar an Investitionen.
Drei ehrliche Anmerkungen, bevor man diese Zahl verwendet: Sie ist kein spezifischer Befund zu RAG, sondern zu GenAI-Piloten im Allgemeinen; „keine messbare Wirkung auf die Zahlen“ heißt nicht „das System funktioniert nicht“; und die Methodik des Reports wurde wegen der Fragilität der Stichprobe im Verhältnis zum Titel kritisiert.
Dennoch benennt der Report eine Ursache, die sich mit unserer Erfahrung in der Praxis deckt: Das Problem liegt nicht in der Qualität der Modelle, sondern in der Integration — im Kontext, den man ihnen gibt. Die These dieses Artikels ist daher enger gefasst und besser zu verteidigen: In der Mehrheit der RAG-Projekte, die wir haben stranden sehen, ist die erste Ursache die Suche, nicht das Modell. Und diese These lässt sich messen, nicht nur erzählen.
Die Obergrenze, die kein Modell durchbrechen kann
Ein RAG-System ist eine Kette aus zwei Gliedern: Es gibt eine Komponente, die die relevanten Passagen in Ihren Dokumenten sucht, und ein Modell, das die Antwort schreibt, indem es diese Passagen liest. Alle Aufmerksamkeit (und das Budget) gilt üblicherweise dem zweiten Glied. Doch es gilt eine ebenso banale wie ignorierte Regel:
Die maximale Qualität der Antworten ist durch die Qualität der Suche begrenzt: Wird die richtige Passage nicht gefunden, kann das Modell nur „Ich weiß es nicht“ sagen — oder erfinden.
Eine dritte Option gibt es nicht. Das Modell zu wechseln verschiebt die Wahl zwischen diesen beiden, löst aber das Problem nicht. Deshalb ist die erste sinnvolle Investition kein größeres Modell, sondern zu messen, wie oft die Suche das richtige Dokument liefert. Tut sie es 6-mal von 10, liegt die Genauigkeits-Obergrenze des gesamten Systems bei 60% — und kein Feinschliff am Prompt wird sie anheben.
Warum die Suche danebenliegt
Die wiederkehrenden Ursachen sind wenige und konkret:
- Schlecht zerteilte Dokumente. Um durchsuchbar zu sein, werden die Dokumente in Fragmente zerlegt. Erfolgt der Schnitt mechanisch, wird eine Tabelle in der Mitte geteilt, eine Regel von ihrer Ausnahme getrennt — und das Fragment „in diesem Fall verkürzt sich die Frist auf 15 Tage“ sagt nicht mehr, von welchem Fall es spricht.
- Verschiedene Wörter für dieselbe Sache. Der Nutzer fragt „Kann ich eine überfällige Rechnung in Raten zahlen?“, das Dokument spricht vom „Rückzahlungsplan für offene Posten“. Null gemeinsame Wörter: Die Stichwortsuche wird es nie finden.
- Die Korrektur, die das umgekehrte Problem schafft. Die typische Antwort ist der Wechsel zur „semantischen“ Suche, die die Bedeutung jenseits der Wörter versteht. Stimmt — doch sie ist genau dort schwach, wo die andere stark ist: Produktcodes, Kürzel, Artikelnummern, Eigennamen. Den Fehlercode
ERR_5012findet die Stichwortsuche auf Anhieb; die semantische lässt ihn zwischen ähnlichen Konzepten „untergehen“. - Kein Abnahmetest. Die Erbsünde: Ohne einen Satz echter Fragen mit der erwarteten Antwort ist jede Änderung eine Wette und jedes Meeting ein Austausch von Meinungen.
Die Lösung: zwei Suchen zusammenarbeiten lassen
Der Kernpunkt: Die Wortsuche und die Bedeutungssuche irren bei unterschiedlichen, komplementären Fragen. Es ist keine Wahl zwischen den beiden — es braucht beide.
Die hybride Suche tut genau das: Sie führt die beiden Suchen parallel aus und verschmilzt deren Ranglisten nach einem Kriterium, das den Konsens belohnt — ein Dokument, das von beiden gefunden wird, auch wenn nicht ganz oben, schlägt ein Dokument, das nur bei einer auf Platz eins steht. Und das ist das richtige Verhalten: Eine Passage, die sowohl über die Wörter als auch über die Bedeutung gefunden wird, ist mit ziemlicher Sicherheit die gesuchte.
Ein reales Beispiel, das wir mit den Zahlen in der Hand überprüft haben. Frage: „Kann ich eine bereits überfällige Rechnung in Raten zahlen?“. Das richtige Dokument — das zum „Rückzahlungsplan für offene Forderungen“ — lag in der Rangliste der Wortsuche auf Platz fünf und in der der Bedeutungssuche auf Platz vier: Mit nur einer der beiden Techniken wäre es nie unter die ersten drei Passagen gelangt, die das Modell liest, und die Antwort wäre falsch gewesen. Mit der Verschmelzung der beiden Ranglisten stieg es auf den ersten Platz — weil es das einzige war, das in beiden vorkam.
| Suchstrategie | Position des richtigen Dokuments | Liest das Modell es? |
|---|---|---|
| Nur Stichwörter | 5. | ✗ |
| Nur Bedeutung | 4. | ✗ |
| Hybrid (Verschmelzung der beiden) | 1. | ✓ |
Zwei wichtige Punkte für Entscheider. Erstens: Das ist keine exotische Technologie — die hybride Suche ist in den großen Enterprise-Suchmaschinen (Elasticsearch, OpenSearch, Azure AI Search) serienmäßig integriert; man aktiviert sie, man erfindet sie nicht. Zweitens: Nach der Suche braucht es einen Schritt zur Neuordnung der Ergebnisse, denn die Modelle lesen besser, was oben im Kontext steht — ein in der Literatur dokumentiertes Detail, das allein die wahrgenommene Qualität spürbar verändert.
Es ist dieselbe Philosophie wie bei unserer Plattform ACME ECMS IA & RAG Integration: mehrere Suchachsen über der Wissensbasis und Neuordnung der Passagen vor der Generierung. Das ist keine Theorie: Es ist das auf jener Seite veröffentlichte Schema.
Woran man erkennt, ob es funktioniert (bevor man vertraut)
Der Abnahmetest ist überraschend einfach, und fast niemand macht ihn. Man baut ein Testset: 50–100 reale Fragen — gesammelt bei denen, die das System nutzen werden, nicht am Schreibtisch erfunden — jede mit der Angabe des Dokuments, das die Antwort enthält. Dann misst man eine einzige Sache, an der isolierten Suche, noch bevor das Modell ins Spiel kommt: Wie oft erscheint das richtige Dokument unter den ersten Ergebnissen?
Diese Zahl ist die Obergrenze des gesamten Projekts. Vor und nach jedem Eingriff gemessen — Aktivierung der hybriden Suche, Neuordnung, besserer Zuschnitt der Dokumente — verwandelt sie Diskussionen in Entscheidungen: Man sieht in einer Tabelle, was die Lage verbessert hat und um wie viel, und hört auf, dem „schwachen Modell“ Schuld zuzuschreiben, die woanders liegt.
Die fünf Fragen an die, die es für Sie bauen
- Gibt es ein Testset mit unseren eigenen Fragen und den erwarteten Antworten? Können wir es sehen?
- Wie hoch ist der Prozentsatz der Fälle, in denen die Suche das richtige Dokument unter die ersten Ergebnisse bringt — gemessen an unserem Bestand?
- Nutzt die Suche beide Achsen — Stichwörter und Bedeutung — oder nur eine?
- Gibt es einen Schritt zur Neuordnung der Ergebnisse, bevor das Modell sie liest?
- Wenn eine Antwort falsch ist, können Sie uns sagen, ob das richtige Dokument gefunden worden war? (Wenn ja, liegt das Problem in der Generierung; wenn nein, in der Suche. Nach unserer Erfahrung ist es fast immer Letztere.)
Kommen auf diese Fragen vage Antworten, fährt das Projekt auf Sicht — ganz gleich, welches Modell darunterliegt.
Das Fazit
RAG scheitert nicht, weil das Modell dumm ist. Es scheitert, weil man ihm das falsche Dokument zu lesen gibt — und ihm dann vorwirft, schlecht geantwortet zu haben.
Bevor Sie in ein größeres Modell investieren: die Suche messen, die fehlende Achse aktivieren, die Neuordnung hinzufügen. Nach unserer Erfahrung ist das die Reihenfolge von Eingriffen mit dem besten Verhältnis zwischen Ergebnis und Kosten — aber es ist eine Erfahrung, kein Theorem: Das Testset aus Ihren Fragen ist der einzige Schiedsrichter, der zählt.
Wenn Ihr Dokumenten-Assistent in der Pilotphase gestrandet ist, können wir gemeinsam hineinschauen — natürlich beginnend mit der Messung.
Quellen.
- MIT Media Lab, Project NANDA — The GenAI Divide: State of AI in Business 2025 (Juli 2025); Zusammenfassung in Fortune, 18. August 2025. Die Methodik war wegen der Fragilität der Stichprobe Gegenstand unabhängiger Kritik.
- Zur Verschmelzung der Ranglisten (Reciprocal Rank Fusion): Cormack, Clarke, Büttcher, SIGIR 2009; Dokumentation von Azure AI Search, Elastic und OpenSearch. Das zitierte Zahlenbeispiel wurde von der Redaktion nachgerechnet und verifiziert.
- Zum Nachlassen der Lesequalität in langen Kontexten: Liu et al., Lost in the Middle, TACL 2024.
