Die häufigsten Probleme bei der Nutzung von Retrieval-augmented Generation (RAG) in der Praxis sind gut dokumentiert und zeigen sich vor allem im großen Maßstab.
RAG hat sich als Standardansatz etabliert, um Dokumente mit großen Sprachmodellen (LLMs) zu verbinden. Das Prinzip ist einfach: Ein Korpus wird eingebettet, die relevantesten Teile werden durch Vektorsuche abgerufen und in einen Prompt integriert. Während diese Methode in Demos und vielen Produktionssystemen gut funktioniert, treten bei der Anwendung in der Praxis vorhersehbare und dokumentierte Fehler auf.
Herausforderungen bei der Anwendung von RAG
Ein häufiges Problem ist die Relevanz der abgerufenen Informationen. Beispielsweise könnte ein Nutzer nach einer Elternzeitregelung fragen, doch der Abruf liefert die Version von 2022, die von 2024 und einen kulturellen Blogbeitrag. Obwohl alle Teile hohe Werte in der Vektorähnlichkeit aufweisen, beantworten sie nicht die eigentliche Frage des Nutzers.
Das Modell erkennt nicht, dass die abgerufenen Inhalte veraltet oder thematisch irrelevant sind. Es kombiniert die Teile zu einer scheinbar fundierten, detaillierten Antwort, die jedoch faktisch falsch ist. Dies ist ein Beispiel für thematische Ähnlichkeit ohne faktische Relevanz und stellt das vorherrschende Problem in Produktionssystemen dar.
Ein weiteres, subtileres Problem ist die Kontextvergiftung. In Unternehmensdatenbanken existieren häufig mehrere Versionen desselben Dokuments. Wenn der Abruf Teile aus beiden Versionen zurückgibt, erkennt das Modell die Widersprüche nicht. Es wählt eine Version aus, kombiniert beide oder präsentiert eine selbstbewusste Synthese. Der Leser erhält eine Antwort, die möglicherweise falsch ist, ohne dass sowohl der Nutzer als auch das Modell dies bemerken.
Übermäßige Komplexität als falsche Lösung
Wenn RAG nicht die gewünschten Ergebnisse liefert, ist die gängige Reaktion, das System zu verkomplizieren: höhere Dimensionen der Einbettungen, ausgeklügelte Nachbewertung und mehrstufige Abrufe. Diese Ansätze verschärfen jedoch oft die Probleme.
Ein globales Fertigungsunternehmen hatte ein Budget von 400.000 US-Dollar für sein RAG-System eingeplant. Im ersten Jahr beliefen sich die Kosten auf 1,2 Millionen US-Dollar, und die endgültige Genauigkeit bei technischen Dokumentationsanfragen betrug nur 23 %. Das Projekt wurde eingestellt. Ein Gesundheitsunternehmen verzeichnete im sechsten Monat monatliche Kosten von 75.000 US-Dollar für die Vektordatenbank. Diese Ergebnisse spiegeln ein breiteres Muster wider: Unternehmensimplementierungen von RAG hatten im Jahr 2025 eine Fehlerrate von 72 % im ersten Jahr.
Höhere Dimensionen der Einbettungen und ausgeklügelte Vektormodelle führen nicht automatisch zu einer besseren Leistung. Sie erhöhen die Rechenkosten und lenken von der entscheidenden Frage ab, ob die gewählte Abrufarchitektur überhaupt die richtige ist.
Alternative Ansätze bei RAG-Problemen
Lange Kontextabfragen
Eine direkte Alternative zur Überkomplexität eines schwächelnden RAG-Systems besteht darin, den Abruf ganz zu überspringen. Wenn der Korpus in das Kontextfenster des Modells passt, kann er geladen und vom Modell gelesen werden. Eine Benchmark-Studie hat gezeigt, dass LLMs mit langen Kontexten bei QA-Aufgaben konstant besser abschneiden als RAG, wenn die Rechenressourcen verfügbar sind, während abrufbasierte Ansätze am meisten zurückfallen.
Der Kostenunterschied ist erheblich. Bei 1 Million Tokens liegt die Latenz 30 bis 60 Mal langsamer als bei einer RAG-Pipeline, bei etwa 1.250 Mal den Kosten pro Anfrage. Mit Prompt-Caching für stark frequentierte Anwendungen kann der lange Kontext jedoch kosteneffektiv werden.
Eine gängige Entscheidungsregel lautet: Wenn der Korpus in das Kontextfenster passt und das Anfragevolumen moderat ist, ist die Verwendung von langen Kontextabfragen der sauberere Ausgangspunkt. Abruf sollte nur hinzugefügt werden, wenn der Korpus das Fenster überschreitet, die Latenz die Service-Level-Ziele (SLOs) verletzt oder das Anfragevolumen den wirtschaftlichen Break-Even-Punkt überschreitet.
Speicherkompression
Wenn der Korpus zu groß für das Kontextfenster ist, sollte eine Zusammenfassung vor dem Abruf erfolgen. Die zusammenfassungsbasierte Abrufmethode komprimiert Dokumente, bevor sie injiziert werden, anstatt rohe Teile abzurufen. Benchmarks zeigen, dass dieser Ansatz in der Leistung mit vollständigen langen Kontextmethoden vergleichbar ist, während abrufbasierte Verfahren konstant hinter beiden zurückbleiben.
Ein konkretes Ergebnis: Ein ordnungserhaltender RAG-Ansatz, der 48.000 gut gewählte Tokens verwendet, übertraf den vollständigen Kontextabruf bei 117.000 Tokens um 13 F1-Punkte, bei einem Siebtel des Token-Budgets. Ein gut komprimiertes relevantes Dokument übertrifft einen rohen Dump von tangential verwandten Teilen.
Strukturierter Abruf
Wenn Abruf die richtige Architektur ist, besteht die Lösung darin, nach Abfragetyp zu routen, anstatt bessere Einbettungen einheitlich anzuwenden. Eine Studie von EMNLP 2024 stellte Self-Route vor, das es dem Modell ermöglicht, zu klassifizieren, ob eine Anfrage vollständigen Kontext oder fokussierten Abruf benötigt, bevor sie ausgeführt wird. Einfache Faktenabfragen gehen an fokussierte RAG, während komplexe Mehrschrittfragen, die ein globales Verständnis erfordern, an einen langen Kontext weitergeleitet werden.
Das Ergebnis: bessere Gesamtgenauigkeit bei niedrigeren Rechenkosten. Adaptive Systeme, die diesen hybriden Ansatz verwenden, haben durch hybride Suche und Nachbewertung eine Verbesserung der Abrufgenauigkeit um 15 bis 30 % gezeigt.
Graphenbasierte Argumentation
Für Anfragen, die das Verständnis von Beziehungen über einen Datensatz erfordern, anstatt einen bestimmten Abschnitt abzurufen, scheitert der Vektorabruf aufgrund seines Designs. Diese sind die Mehrschrittfragen: Welche Entscheidungen hat der Vorstand im dritten Quartal zurückgenommen, und was war jeweils der angegebene Grund? Kein einzelner Teil beantwortet dies. Die Antwort liegt in den Verbindungen zwischen den Dokumenten.
Microsoft Research stellte 2024 GraphRAG vor. Das System erstellt aus dem Korpus ein Wissensgraph, der dann die Beziehungen zwischen Entitäten durchläuft, anstatt Vektoren abzugleichen. Es adressiert direkt den Fehlerfall, den das Standard-RAG nicht bewältigen kann: die Synthese über mehrere Dokumente, die relationale Argumentation erfordert.
Der Nachteil sind die Kosten. Die Extraktion von Wissensgraphen ist 3 bis 5 Mal teurer als das Baseline-RAG und erfordert eine domänenspezifische Anpassung. GraphRAG ist den Aufwand wert für thematische Analysen und Mehrschrittargumentationen, jedoch nicht für einfache Faktenabfragen.
Fazit
RAG ist für viele Anwendungsfälle ein vernünftiger Standardansatz. Es bricht jedoch auf vorhersehbare Weise: Abrufirrelevanz, wenn das Vokabular übereinstimmt, aber die Semantik abweicht, Kontextvergiftung, wenn widersprüchliche Versionen im Korpus existieren, und strukturelle Grenzen, wenn die Chunk-Größe sowohl Abruf als auch Kohärenz nicht gleichzeitig erfüllen kann. Die Hinzufügung von Komplexität zu einem fehlerhaften Abrufdesign macht diese Probleme teurer.
Es gibt vier bessere Ansätze, je nach Situation:
- Wenn der Korpus in das Kontextfenster passt, vermeidet die Verwendung von langen Kontextabfragen das Abrufproblem vollständig.
- Wenn eine Kontextkompression notwendig ist, übertrifft die Zusammenfassung vor dem Abruf den Rohabruf von Teilen.
- Wenn Anfragen nach Typ variieren, verbessert die explizite Routenführung mit strukturiertem Abruf sowohl Genauigkeit als auch Kosten.
- Wenn Anfragen relationale Synthese über Dokumente erfordern, ist graphenbasierte Argumentation die richtige Architektur.
Die Architektur sollte dem Abfragetyp entsprechen.
Ein interessanter Aspekt der Entwicklung in diesem Bereich ist die Evolution von Prompt Engineering zu Concept Engineering. Darüber hinaus bietet ein Intensivkurs zur Generativen KI spannende Einblicke in die neuesten Technologien. Schließlich zeigt ein neues Framework, dass KI-Modelle menschliche Unterstützung beim Roboter-Coding benötigen.
„`
Quellen: kdnuggets
Bildquelle: KI generiert
