Drei Gründe, warum RAG-Systeme in der Praxis versagen: fragmentierter Kontext, Abweichungen und Fehlnutzung.

Warum RAG-Demos funktionieren und Produktionsysteme nicht

Retrieval-augmented Generation ist zu einer Standardarchitektur für UnternehmenskI geworden. Support-Assistenten, interne Wissenswerkzeuge, Compliance-Berater sowie intelligente Suchprodukte in den Bereichen Banking, Versicherung, Gesundheitswesen, Telekommunikation, Einzelhandel und Regierung nutzen sie alle, um Sprachmodelle mit dem eigenen Wissen eines Unternehmens zu verbinden. Die Idee klingt einfach: Relevante Abschnitte aus einer Wissensdatenbank abrufen und sie dem Modell vor der Antwortung zur Verfügung stellen. In der Produktion umzusetzen ist jedoch weitaus schwieriger, als es ein Proof of Concept vermuten lässt.

Viele Teams bringen ein Prototyp in Betrieb, stoßen aber anschließend bei der Skalierung auf neue Probleme. Die Antworten sind unvollständig. Mit zunehmenden Datenmengen verschlechtert sich die Qualität der Abrufe. Wichtiger Kontext geht verloren, es treten Halluzinationen auf, die Latenz steigt an, und die Nutzer erhalten Antworten, die technisch zwar korrekt sind, aber praktisch nutzlos. Manchmal findet das Abrufsystem genau die richtigen Dokumente, doch das Modell liefert dennoch die falsche Antwort.

Unternehmensspezifische Einstellungen verschärfen all das, da das Wissen über Tausende von Dokumenten, Richtlinien, Verfahren, Betriebsanleitungen und regulatorischen Vorgaben verteilt ist. Eine Geschäftsentscheidung kann von Details abhängen, die über mehrere Abschnitte eines Repositoriums verstreut sind – wodurch die Qualität der Abrufe genauso wichtig wie die Fähigkeiten des Modells wird.

Eine weit verbreitete Fehlvorstellung besagt, dass ein besseres RAG hauptsächlich bedeutet, dass auch das LLM besser ist. Die Wahl des Modells spielt zwar eine Rolle, doch viele Probleme in der Produktion haben ihre Ursache woanders: das Aufteilen in Blöcke, die Sucharchitektur, die Kontextverwaltung, die Ranking-Verfahren sowie die Bewertung. Ein gut konstruiertes Suchsystem in Kombination mit einem leistungsfähigen Modell schlägt oft ein unzureichendes System ab, das mit dem neuesten Modell arbeitet. In regulierten Bereichen wie der Bankwesen lohnt es sich in der Regel mehr, diese Fehlermuster zu kennen, als die internen Abläufe des neuesten Modells zu verstehen – schließlich hängt der Erfolg in der Produktion selten von einem einzigen Modulupdate ab. Es kommt vielmehr darauf an, wie gut Informationen abgerufen, gerankt, strukturiert und dargestellt werden.

Drei Szenarien zeigen, wie Dinge schiefgehen können:

• Ein System liefert relevante Materialien, übersieht aber dennoch wichtige Nuancen.
• Die Qualität der Informationsabrufung nimmt mit dem Wachstum der Wissensbasis ab.

Das Modell gibt falsche Antworten, obwohl die richtigen Dokumente abgerufen wurden.

Die Botschaft hinter all diesen Beispielen ist, dass eine gute RAG-Lösung von einer besseren Dokumentenabfrage, Kontextverwaltung, Bewertung und Systemarchitektur abhängt – und nicht nur von besseren Modellen.

Szenario eins: relevanter Text, aber fehlender Kernpunkt

Eine der frustrierendsten Situationen ist, wenn ein Abfragesystem relevante Abschnitte findet, die Antwort dennoch unzureichend erscheint. Sie mag faktisch korrekt sein, fehlt aber an Kontext, subtilen Details oder den geschäftlichen Nuancen, die ein menschlicher Experte sofort erkennen würde. Dies tritt häufiger bei langen Dokumenten auf, deren Informationen über mehrere Abschnitte verteilt sind.

Stellen Sie sich ein Wissensarchiv einer Bank vor, das die Richtlinien für die Kundenonboarding-Prozesse enthält. Die Hauptanforderungen sind in einem Kapitel zusammengefasst, die Handhabung von Ausnahmen in einem anderen, während die regulatorischen Anforderungen in einem separaten Abschnitt liegen, der vom Risikomanagement betreut wird. Ein Kunde fragt, ob ein bestimmtes Dokument ausreicht, um ein Konto zu eröffnen. Das Suchsystem liefert die Onboarding-Richtlinie, übersieht jedoch die in einer anderen Stelle dokumentierten regulatorischen Ausnahmen. Die Antwort des Modells ist anhand dessen, was es gesehen hat, korrekt, reicht für die Geschäftspraxis jedoch weiterhin nicht aus. Das ist ein System, das nur einen Teil des Dokuments erfassen kann und das Gesamtbild verpasst.

Ingenieure verdächtigen oft zunächst das Modell. Der übliche Schuldige ist dabei die Sucharchitektur.

Feste Datensätze unterbrechen den Gedankengang

Das Erste, was überprüft werden muss, ist die Aufteilung in Blöcke. Viele Implementierungen verwenden Blöcke fester Größe, weil sie einfach zu erstellen sind und in Experimenten gut funktionieren – sie teilen Dokumente in alle paar hundert Token auf und speichern die Teile in einer Vektordatenbank. Das ist zwar einfach, zerstört aber oft logische Beziehungen. Dokumente werden nicht in blockweise, tokengroße Einheiten geschrieben. Sie sind vielmehr nach Ideen, Abschnitten, Richtlinien, Verfahren und Geschäftskonzepten organisiert, und wenn eine Grenze durch eines davon verläuft, zerfallen Kontexte in Fragmente. Eine Richtliniendefinition kann in einem Block landen, während ihre Ausnahme in einem anderen liegt. Der Abrufmechanismus holt die Definition ab, findet die Ausnahme jedoch nie, wodurch das Modell auf der Grundlage unvollständiger Informationen Schlussfolgerungen zieht.

Lösungen für fragmentierten Kontext

Semantisches Chunking ist die übliche Lösung. Anstatt an willkürlichen Tokenzahlen zu schneiden, folgt es natürlichen Strukturen wie Überschriften, Abschnitten, Paragraphen und Themensprüngen, wodurch Beziehungen erhalten bleiben und die Auffindbarkeit deutlich verbessert wird.

Auch dann befindet sich wichtige Information oft an der Grenze zwischen zwei Chunks. Wenn die Chunks völlig unabhängig sind, kann sie dennoch übersehen werden. Überschneidende Chunks helfen hierbei. Wenn benachbarte Chunks einen Teil des Inhalts teilen, entsteht eine Kontinuität über die Grenzen hinweg, da das, was einen Chunk abschließt, auch den nächsten eröffnet – dadurch sinken die Chancen, relevanten Kontext zu verlieren.

Sobald Dokumente komplexer werden, lohnt sich ein Eltern-Kind-Design. Kleine Abschnitte werden eingebettet und gesucht, da sie eine höhere Präzision ermöglichen. Sobald ein kleiner Abschnitt übereinstimmt, lädt das System den größeren Elternabschnitt herunter, in dem er sich befindet, sodass das Modell sowohl die passende Detailinformation als auch deren Umgebung betrachten kann. Es ist, als würde man den richtigen Absatz finden und anschließend den gesamten Abschnitt lesen anstatt nur ein paar vereinzelte Sätze.

Produktionsysteme zeigen außerdem, dass die beste Antwort selten in einem einzigen Abschnitt zu finden ist. Unterstützende Informationen befinden sich oft direkt vor oder nach dem besten Ergebnis, wodurch das Herunterladen nur des am höchsten bewerteten Abschnitts zu unvollständigen Schlussfolgerungen führen kann. Durch die Erweiterung der Suche, um auch benachbarte Abschnitte neben dem Hauptergebnis mit einzubeziehen, bleibt die Kontinuität gewahrt und das Modell kann erkennen, wie sich die einzelnen Teile zueinander verhalten.

Die zunehmende Größe von Wissensbasen erhöht die Anforderungen an die Qualität der Informationsabrufung. Die Vektorsuche ist hervorragend darin, semantisch ähnlichen Inhalt zu finden, kann jedoch genaue Begriffe, Produktnamen, Richtlinienidentifikatoren, regulatorische Referenzen sowie domain-spezifische Schlüsselwörter übersehen. Im Bankwesen kann ein Kunde auf eine bestimmte Vorschrift, Kontotyp oder Transaktionskategorie verweisen, bei der eine exakte Übereinstimmung erforderlich ist. Eine hybride Strategie, die semantische Suche mit Schlüsselwortmethoden wie BM25 kombiniert, berücksichtigt beide Aspekte: Die semantische Suche erfasst die Bedeutung, während die Schlüsselwortsuche die Genauigkeit gewährleistet – gemeinsam decken sie mehr ab als jede Methode für sich allein.

Zuletzt erfolgen die Neubewertung und die Kontextoptimierung, bevor etwas beim Modell ankommt. Nicht jeder abgerufene Abschnitt verdient Platz im endgültigen Prompt. Neubewertungsfunktionen rücken das relevanteste Material nach vorne, während die Kontextoptimierung Überflüssigkeiten entfernt, um den verfügbaren Raum optimal zu nutzen. Das Ziel besteht nicht nur darin, relevante Texte abzurufen, sondern dem Modell ein Verständnis zu vermitteln, das eine erfahrene Person nach dem Lesen der relevanten Abschnitte gewinnen würde. Wenn bei der Abrufung die Beziehungen zwischen Konzepten, Richtlinien, Ausnahmen und Beweisen erhalten bleiben, verbessert sich die Qualität der Antworten erheblich, und subtile Punkte, die in langen Dokumenten versteckt sind, gehen nicht mehr verloren.

Kurz gesagt

Bei diesem Symptom sollten Sie sich die Abrufschicht vor dem Modell ansehen. Überprüfen Sie die Chunking-Strategie, wechseln Sie auf semantisches Chunking mit Überschneidungen, fügen Sie ein Eltern-Kind-Abfragesystem hinzu, erweitern Sie den Abfragebereich auf benachbarte Chunks und kombinieren Sie eine hybride Suche mit Neuranking. Diese Änderungen liefern dem Modell in der Regel einen reichhaltigeren, besser vernetzten Kontext, was typischerweise dazu beiträgt, Nuancen in langen Dokumenten zu bewahren.

Szenario zwei: hervorragend in der Entwicklung, instabil in der Produktion

Eine häufige Geschichte in Unternehmen sieht so aus: Ein RAG-System funktioniert hervorragend während der Entwicklung, beginnt jedoch kurz nach dem Start unzureichende oder inkonsistente Ergebnisse zu liefern. Die Demo verlief gut, die Testabfragen ergaben genaue Antworten, die Informationsabrufung schien zuverlässig und das Vertrauen war hoch. Dann trifft echter Traffic ein. Die Nutzer stellen unterschiedliche Fragen, neue Dokumente gelangen ständig in die Wissensdatenbank, Geschäftsprozesse ändern sich und das Volumen steigt. Antworten, die einst korrekt erschienen, werden inkonsistent, unvollständig oder themenfremd.

Hat sich die Datenlage geändert?

Die erste Überprüfung besteht darin, festzustellen, ob sich die Datenverteilung verändert hat. Entwicklungsumgebungen enthalten eine kleine, sorgfältig ausgewählte und ordentliche Datensammlung. In Produktumgebungen können hingegen Tausende oder Millionen von Dokumenten vorhanden sein, die von verschiedenen Teams in unterschiedlichen Formaten und Standards erstellt wurden. Stellen Sie sich eine Bank vor, die mit einer kleinen Anzahl von Einarbeitungspolitiken beginnt und anschließend Compliance-Verfahren, Prüfungsunterlagen, Betrugsrichtlinien, Produktanleitungen, Kundenkorrespondenz sowie regulatorische Mitteilungen hinzufügt. Eine Abfrage, die früher aus zehn hochrelevanten Dokumenten auswählte, muss sich nun mit Tausenden von teilweise verwandten Dokumenten messen. Der Suchmechanismus kann weiterhin inhaltlich ähnliche Ergebnisse liefern, ohne das am nützlichste Ergebnis zu finden – und das ist oft das erste Anzeichen dafür, dass die Suchleistung mit dem Wachstum der Wissensbasis nachgelassen hat.

Die Suchleistung eigenständig messen

Zuerst sollte die Informationsauswahl unabhängig vom Sprachmodell bewertet werden. Ein häufiger Fehler besteht darin, das LLM für schlechte Antworten verantwortlich zu machen, obwohl der Informationsabrufmechanismus nie den richtigen Kontext bereitgestellt hat. Metriken wie Recall@K und Precision@K klären dies schnell: Wenn das richtige Dokument nicht unter den obersten Ergebnissen erscheint, hatte das Modell nie eine Chance. Oft muss an dem Informationsabrufprozess selbst gearbeitet werden.

Eine häufige Ursache ist der Drift der Embeddings. Ein Embedding-Modell, das mit einem kleinen Datensatz gut funktioniert hat, kann Schwierigkeiten bekommen, wenn sich die Dokumente verändern, da unterschiedliche Typen, Schreibweisen und Fachbegriffe im Laufe der Zeit seine Wirksamkeit verringern. Die Wissensdatenbank einer Bank könnte beispielsweise Richtlinien von Compliance-Teams, Handbücher von Geschäftsteams und Spezifikationen von Ingenieuren enthalten. All das gehört zwar derselben Organisation an, doch die Sprache variiert stark; wenn die Embeddings diese Unterschiede nicht erfassen, sinkt die Qualität.

Chunking-Strategien können ebenfalls veraltet werden. Ein Ansatz, der für Hunderte von Dokumenten funktioniert hat, kann bei Hunderttausenden versagen, weil schlecht strukturierte Chunks Störungen in der Ähnlichkeitssuche verursachen und es erschweren, das Relevante zu finden. Deshalb benötigt ein produktionsreifes RAG eine kontinuierliche Bewertung und nicht nur einen einmaligen Aufbau.

Echte Anfragen unterscheiden sich von Testanfragen

Anfragemuster verdienen Aufmerksamkeit. Entwicklungstests konzentrieren sich auf ideale Fragen, da die Ingenieure die Daten bereits kennen. Reale Nutzer stellen oft vage oder unvollständig formulierte Fragen und verwenden Begriffe, die in der Wissensdatenbank nicht enthalten sind. Ein Serviceagent könnte nach „Premium-Konten-Schließungsregeln“ suchen, während die offiziellen Dokumente von „Verfahren zur Beendigung von Konten wertvoller Kunden“ sprechen. Die Menschen erkennen den Zusammenhang sofort, doch die Systeme mögen ihn nicht erkennen. Die Beobachtung der Interaktionen echter Nutzer bringt in der Regel Schwächen zum Vorschein, die durch Tests nie aufgedeckt werden.

Ein Blick ins Pipeline-Interieur

Die Überwachbarkeit der Datenerfassung ist eine weitere wertvolle Technik. Für jede Produktionsanfrage sollte die Sichtbarkeit Folgendes umfassen:

• welche Dokumente zurückgegeben wurden
• der Grund für die Erfassung jedes Dokuments
• die Ähnlichkeitswerte
• der endgültige Kontext, der an das LLM gesendet wird
• die erzeugte Antwort

Ohne diese Überwachung ist das Debuggen reine Spekulation. Mit ihr zeigen die Spuren oft an, ob ein Problem bei der Datenerfassung, beim Neuranking, bei der Erstellung des Prompts oder bei der Generierung entstanden ist.

Sonnt sich die Datenmenge weiter aus, können zusätzliche Schichten vor der Vektorsuche eingefügt werden, wie beispielsweise hybride Suchverfahren, Metadatenfilter, Dokumentklassifizierung, Neuranker oder branchenspezifische Pipelines. Eine Bankfrage zu Hypotheken sollte beispielsweise zunächst in Materialien zu Hypotheken gesucht werden, bevor die gesamte Unternehmens-Wissensdatenbank durchsucht wird. Die Eingrenzung des Suchraums verbessert sowohl die Genauigkeit als auch die Qualität der Antworten.

Fazit ist, dass Produktions-RAG-Systeme lebende Systeme sind, die sich mit ihren Daten weiterentwickeln. Man sollte nicht davon ausgehen, dass eine Lösung, die bereits am ersten Tag gut funktioniert, auch nach sechs Monaten weiterhin gleich gut performt – daher sind kontinuierliche Überwachung, Bewertung und Neutraining der Abrufkomponenten unerlässlich, um die Qualität auf großem Niveau zu gewährleisten.

Kurz gesagt

Falls ein System in der Entwicklung gut funktioniert, aber in der Produktion schlecht abschneidet, sollte man zunächst Probleme beim Dokumentenabruf von Problemen bei der Erstellung von Inhalten trennen. Analysieren Sie die Abruffunktionen, prüfen Sie die abgerufenen Dokumente, überprüfen Sie die Qualität der Embeddings, untersuchen Sie tatsächliche Abfragemuster und stellen Sie eine gute Überwachungsmöglichkeit für den gesamten Prozess sicher. Wenn das Volumen zunimmt, sollten Sie hybride Suchverfahren, Metadatenfilterung, Neuranking sowie domänenspezifische Abrufmethoden in Betracht ziehen, um relevante und genaue Ergebnisse zu erhalten.

Szenario drei: richtige Dokumente, falsche Antwort

Viele Ingenieure gehen davon aus, dass die Aufgabe erledigt ist, sobald das Abrufen funktioniert. Eines der schwierigsten Szenarien bei RAG ist das Gegenteil: Das System findet die richtigen Dokumente, doch das Modell gibt weiterhin falsche Antworten. Das ist besonders frustrierend, weil der übliche Debugging-Instinkt direkt auf das Abrufen verweist, obwohl der Abrufmechanismus seine Arbeit möglicherweise perfekt erledigt. Der Fehler liegt darin, wie das Modell den Kontext verarbeitet und darauf basierend Schlussfolgerungen zieht.

Stellen Sie sich einen Assistenten für Bankvorschriften vor, der Fragen zur Geldwäscherbekämpfung beantwortet. Ein Benutzer fragt, ob ein Kundenkonto weiterhin aktiv bleiben kann, während die KYC-Überprüfung aussteht. Das Abrufen liefert die richtigen Richtliniedokumente, und die entsprechende Regel ist im Kontext enthalten. Dennoch besagt die Antwort, dass das Konto unbegrenzt lange aktiv bleiben kann. Die notwendigen Informationen waren vorhanden, doch das Modell konnte sie nicht richtig nutzen.

Kontextüberlastung und „Verloren im Mittel“

Eine Ursache ist die Kontextüberlastung. Je mehr Dokumente abgerufen werden, desto mehr muss das Modell aufnehmen – und nicht alles ist gleichermaßen wichtig, wodurch entscheidende Details in einer langen Anfrage untergehen können. Dies wird oft als das Problem des „Verlorengehens in der Mitte“ bezeichnet: Modelle neigen dazu, sich auf Material am Anfang und Ende des Kontexts zu konzentrieren und das, was in der Mitte steht, zu übersehen. Die richtige Antwort kann buchstäblich in der Anfrage enthalten sein und dennoch ignoriert werden.

Die Lösung besteht darin, die Qualität des Kontextes vor der Menge zu bevorzugen. Teams versuchen oft, die Genauigkeit durch das Abrufen mehrerer Informationen zu erhöhen, doch mehr Kontext führt nicht immer zu besseren Antworten – einige hochwertige Abschnitte übertrumpfen häufig einen Haufen nur schwach miteinander verbundener Informationen. Eine Neubewertung ist hier wertvoll, da dadurch die relevantesten Abschnitte bereits vor dem Modell geordnet werden. Drei hochrelevanten Dokumente mit klaren Unterstützungsbelegen können besser funktionieren als zehn mäßig relevante.

Aufforderungen, die eine Bezugnahme erfordern

Auch die Gestaltung der Aufforderungen spielt eine Rolle. Anstatt dem Modell freie Antworten zu ermöglichen, sollte es angewiesen werden, die Antwort strikt auf dem abgerufenen Kontext zu stützen und klar anzugeben, wenn die vorhandenen Informationen nicht ausreichen, um eine Antwort zu stützen. Dadurch wird unbegründetes Schlussfolgern stark eingeschränkt.

Zitatenbasierte Generierung ist ebenfalls hilfreich. Wenn das Modell spezifische Abschnitte oder Dokumentidentifikatoren benennen muss, ist es viel einfacher zu überprüfen, ob eine Antwort auf den abgerufenen Belegen beruht – was in regulierten Branchen wie der Bankwesen, wo Prüfbarkeit und Erklärbarkeit erforderlich sind, von Bedeutung ist.

Konfliktierende Quellen

Überprüfen Sie, ob die abgerufenen Dokumente miteinander im Widerspruch stehen. Große Organisationen halten oft mehrere Versionen von Richtlinien, Verfahren und Leitfäden bereit; wenn bei der Abfrage veraltete und aktuelle Versionen zusammen angezeigt werden, weiß das Modell möglicherweise nicht, welche Vorrang hat. Metadatenfilterung und Dokumentversionierung werden daher unerlässlich.

Ziel ist es nicht nur, Informationen abzurufen, sondern sicherzustellen, dass das Modell die relevantesten Belege erkennen, priorisieren und darauf aufbauen kann. Ein RAG-System ist nur dann erfolgreich, wenn Abfrage und Schlussfolgerungserstellung zusammenwirken.

Kurz gesagt

Wenn die richtigen Dokumente zurückkommen, aber die Antwort weiterhin falsch ist, sollte man untersuchen, wie das Modell den Kontext verwendet: Überlastung, Effekte des „Verlorengehens“ im Kontext, widersprüchliche Quellen sowie eine schwache Grundlage. Zu versuchende Lösungen sind das Neuranking, das Kürzen des Kontexts, Antworten, die auf ihre Quellen verweisen, Metadatenfilter sowie Anfragen, die das Modell zwingen, sich ausschließlich auf die abgerufenen Beweise zu stützen. Oft liegt das Problem gar nicht im Abrufen der Informationen, sondern darin, wie der Kontext genutzt wird.

Was die drei Fälle gemeinsam haben

Der Aufbau eines guten RAG-Systems erfordert weitaus mehr als nur die Verbindung einer Vektordatenbank mit einem LLM. Konzeptionsbeispiele wirken oft beeindruckend, doch die wahren Herausforderungen treten erst dann auf, wenn die Systeme in die Produktion gehen und zuverlässig im großen Maßstab laufen müssen. In diesen drei Szenarien treten Kontextfragmente in großen Dokumenten auf, die Qualität der Informationsabrufung nimmt mit dem Wachstum der Repositorien ab, und selbst wenn die richtigen Informationen abgerufen werden, kann das Modell versagen, darauf zu schließen.

Das wiederkehrende Thema ist, dass die Qualität der Informationsabrufung genauso wichtig ist wie die Leistungsfähigkeit des Modells. Selbst das fortschrittlichste LLM kann fehlenden Kontext, schlecht strukturierte Datenblöcke, schwache Strategien zur Informationsabrufung oder irrelevante Inhalte in der Anfrage nicht ausgleichen. Die Verbesserung der Architektur zur Informationsabrufung bringt oft mehr Vorteile als der Austausch des Modells. Für Ingenieure, Architekten und technische Leiter ist es ein durchdachtes Design – sinnvolle Aufteilung in Datenblöcke, solide Pipelines zur Informationsabrufung, Bezug zum Kontext, Neubewertung sowie kontinuierliche Evaluation – das Produktivsysteme von auffälligen Demonstrationen unterscheidet. Unternehmensweite KI dreht sich nicht nur um die Erstellung von Antworten, sondern um die Erstellung von relevanten, fundierten, erklärbaren und stets zuverlässigen Antworten.