Wo RAG-Pipelines blind handeln: Erfassung von Fehlern in agierenden Mustern

Das Standardverfahren für retrieval-augmented generation folgt einer einfachen Abfolge: Informationen abrufen, generieren und antworten. Es eignet sich für Demonstrationen, doch bei produktiven Anfragen treten schnell seine Schwachstellen zutage. Der Informationsabrufmechanismus liefert irrelevante Teile, der Nutzer formuliert die Frage in Begriffen, die in Ihren Dokumenten nie vorkommen, die Antwort befindet sich überhaupt nicht im Index – oder das Modell schreibt etwas, was der abgerufte Text tatsächlich nicht unterstützt. Mehr Dokumente in den Prompt einzufügen, löst keines dieser Probleme, denn das Problem liegt nicht in der Menge des Kontexts, sondern im Fehlen einer Entscheidung darüber, was als Nächstes zu tun ist.

Diese Entscheidungsstufe ist es, was man unter agentic RAG versteht. Diese Anleitung behandelt sie als eine Reihe gezielter Reaktionen auf spezifische Fehlermuster statt als eine einzige Architektur, damit Sie Ihren eigenen Prozess betrachten, den Schritt finden können, an dem er derzeit blind handelt, und das kleinste Muster auswählen können, um dieses Problem zu beheben.

Warum der One-Shot-Pipeline fehlschlägt

Eine herkömmliche RAG-Anwendung führt eine feste Abfolge von Schritten aus. Sie nimmt die Frage entgegen, führt eine Ähnlichkeitssuche in einer Vektordatenbank durch, behält die besten Ergebnisse, gibt sie an ein LLM weiter und liefert das zurück, was dieses ausgibt. Die stillschweigende Annahme ist, dass der Suchvorgang erfolgreich war.

Wenn diese Annahme nicht zutrifft, bemerkt nichts in der Pipeline das:

• Schlechte Dokumente werden dennoch an das Modell weitergegeben, und das Modell versucht, darauf zu antworten.
• Eine Abfrage mit einem Wortschatz, der nicht zu den Dokumenten passt, liefert nur wenig wertvolle Ergebnisse.
• Falls in der Wissensdatenbank einfach keine Antwort vorhanden ist, hat das System keinen alternativen Weg.

Ein nützlicher Perspektivwechsel besteht darin, aufzuhören, nur danach zu fragen, wie die Informationsabrufung verbessert werden kann, und stattdessen zu überlegen, was das System tun sollte, wenn die Ablaufung nicht gut genug ist. Jedes der unten aufgeführten Muster ist eine Antwort auf eine Variante dieser zweiten Frage. Wenn Sie vor dem Eintauchen in die einzelnen Muster einen umfassenderen Vergleich der Informationsabrufungsarchitekturen wünschen, sehen Sie sich RAG vs agentic RAG vs graph RAG an.

Bewertung der Informationsabrufung und Neuschreibung der Anfrage

Nehmen wir eine Frage wie „Wie handhabt LangGraph die Persistenz?“ an. Angenommen, der Informationsabrufer liefert fünf Abschnitte, von denen nur einer relevant ist. Ein lineares Verarbeitungsverfahren leitet alle fünf Abschnitte weiter und lässt das Modell sie sortieren, was die nützlichen Informationen schwächt und zu Verwirrung führt.

In einem agierenden Workflow wird zunächst ein Bewertungsschritt eingefügt. Ein Bewertungsmechanismus, oft eine einfache Anfrage an ein kleines LLM mit einer Ja/Nein-Beurteilungskriterie, prüft, ob die abgerufenen Dokumente ausreichend relevant sind, um die Frage zu beantworten. Sind sie es nicht, sucht der Workflow nicht einfach erneut mit dem gleichen Text. Stattdessen wird anhand dessen, was der erste Versuch ergeben hat, eine verbesserte Abfrage erstellt und erneut nach Informationen gesucht. Der entstehende Kreislauf besteht aus:

• Daten abrufen
• Die Ergebnisse bewerten
• Die Abfrage überarbeiten, falls sie unzureichend sind
• Erneut Daten abrufen

Der Kreislauf an sich ist nicht der wertvolle Teil. Entscheidend ist, dass das System erkennen kann, dass sein erster Versuch unzureichend war. In der Praxis ist außerdem eine Abbruchbedingung erforderlich, beispielsweise eine maximale Anzahl an Überarbeitungen, damit eine Frage, die der Index nicht beantworten kann, nicht endlos im Kreis läuft.

Ausweichstrategien, wenn der Index keine Antwort hat

Umschreiben hilft nur, wenn die Informationen irgendwo in Ihrem Korpus vorhanden sind. Oft ist das jedoch nicht der Fall. Stellen Sie sich einen Assistenten vor, der auf Dokumentationen basiert, die vor einem Monat gesammelt wurden, und ein Benutzer fragt nach einer Funktion, die erst gestern angekündigt wurde. Kein Umschreiben wird ein Dokument zutage fördern, das niemals indiziert wurde.

Korrigierendes RAG behebt dieses Problem. Nach der Bewertung der abgerufenen Dokumente betrachtet der Workflow ein unzureichendes Ergebnis als Signal, den Ansatz zu korrigieren – beispielsweise durch die Abfrage einer anderen Quelle wie einer Websuche. Der lineare Ablauf von Abrufen und Erstellen wird dadurch zu:

• Abrufen
• Bewertung der Dokumente
• Korrektur, falls die Bewertung schlecht ist
• Erstellen

„Richtig“ ist absichtlich weit gefasst. Je nach Anwendung kann das bedeuten, die Abfrage umzuschreiben, eine andere Quelle zu konsultieren oder eine andere Aktion auszuführen. Das entscheidende Merkmal ist, dass ein fehlgeschlagener Abruf einen anderen Weg auslöst anstelle einer unzureichenden Antwort. Bedenken Sie, dass das Hinzufügen eines Web-Fallbacks Ihr Vertrauensmodell verändert: Öffentlicher Web-Inhalt ist weniger sorgfältig kuratiert als Ihre eigene Dokumentation, sodass Sie Antworten, die darauf angewiesen sind, möglicherweise kennzeichnen oder filtern möchten.

Jede Frage an die richtige Quelle leiten

Eine weitere stillschweigende Annahme im grundlegenden RAG ist, dass jede Frage auf denselben Abrufmechanismus zugreifen sollte. Viele reale Systeme verfügen gleichzeitig über mehrere Wissensquellen: interne Unternehmensdokumentation, öffentliche Produktdokumentationen, ein oder mehrere Vektordatenspeicher sowie eine aktuelle Websuche.

Diese Quellen sind nicht austauschbar. Auf eine Frage zu einer internen HR-Politik sollte man nicht über das öffentliche Internet antworten. Eine Frage zu einer letzte Woche veröffentlichten Bibliotheksversion sollte nicht ausschließlich auf einem Vektorlagersystem beruhen, das vor dieser Veröffentlichung erstellt wurde.

Adaptive RAG fügt zu Beginn eine Routungsentscheidung hinzu. Bevor etwas abgerufen wird, klassifiziert das System die Frage und entscheidet, welche Quelle am besten geeignet ist, sie zu beantworten, wertet anschließend den aus dieser Quelle zurückgegebenen Kontext aus. Der Abrufweg wird für jede Frage individuell gewählt und nicht für alle festgelegt. Ein Router kann so einfach sein wie eine Klassifizierungsanfrage oder ein Satz von Regeln; er muss nicht komplex sein, um eine ganze Kategorie falscher Antworten aus Quellen derselben Art zu vermeiden.

Die Antwort überprüfen, nicht nur die Dokumente

Eine subtilere Fehlerquelle entgeht leicht: Eine hervorragende Informationsauswahl garantiert noch keine gute Antwort. Das Modell kann genau die richtigen Abschnitte erhalten und dennoch eine Antwort liefern, die über diese hinausgeht oder vom ursprünglichen Fragestellung abweicht.

Die Lösung besteht darin, auch die Ausgabe zu bewerten. Nach der Erstellung kann ein agiler Arbeitsablauf folgende Fragen stellen:

• Ist jede Aussage in der Antwort auf dem ausgewählten Kontext begründet?
• Beantwortet die Antwort tatsächlich das, was der Benutzer gefragt hat?
• Hat das Modell Informationen hinzugefügt, die vom Kontext nicht gestützt werden?

Falls die Antwort fehlschlägt, kann der Workflow sie überarbeiten oder neu erzeugen. Dadurch gibt es zwei getrennte Überprüfungen, die separat betrachtet werden sollten: ob die richtigen Informationen abgerufen wurden und ob diese Informationen korrekt verwendet wurden. Die Trennung erleichtert außerdem das Debuggen erheblich, da ein Fehler der Abrufphase oder der Erstellungsphase zugeschrieben werden kann, anstatt einfach „der Bot lag falsch“ zu sagen. Der Artikel zu der Bewertung von RAG nach Fehlerstufe erläutert diese Idee ausführlicher.

Pause für eine menschliche Entscheidung

Manche Ergebnisse sollten nicht automatisch entschieden werden. Typische Auslöser für eine menschliche Überprüfung sind:

• Beweise, die unklar oder widersprüchlich sind
• Antworten, die eine formelle Freigabe vor der Verwendung benötigen
• Niedriges Vertrauensniveau seitens der System-eigenen Bewertungstools

eine Entwurfsantwort, die eindeutig überarbeitet werden muss

Durch das Verfahren mit menschlicher Beteiligung im RAG wird im Workflow ein Kontrollpunkt eingefügt, an dem jemand das Ergebnis freigeben, ablehnen oder vor Fortsetzung der Ausführung bearbeiten kann. Dies ist kein Rückzug von der Automatisierung. Das System kümmert sich weiterhin selbst um die routinemäßigen Fälle und leitet nur jene weiter, die tatsächlich eine Beurteilung erfordern – was in der Regel eine weitaus bessere Nutzung der Zeit der Prüfer ist als das Überprüfen von allem oder gar nichts. Graphbasierte Orchestrierungsframeworks wie LangGraph eignen sich hervorragend dafür, da sie den Workflow-Zustand am Kontrollpunkt speichern und nach der Reaktion des Benutzers fortsetzen können.

Aufteilung der Arbeit auf spezialisierte Agenten

Sobald die Arbeitsabläufe komplexer werden, ist es schwierig, einen einzelnen Agenten mit allen Verantwortlichkeiten zu betreuen und ihn effektiv anzuleiten. Einige Probleme lassen sich natürlicherweise in unterschiedliche Aufgabenbereiche aufteilen: Informationsabruf, Recherche, Bewertung usw.

Durch eine mehragentige Überwachungsstruktur übernimmt ein Agent die Koordination. Der Überwacher entscheidet, welcher Spezialist den nächsten Schritt ausführen soll, während die Spezialisten jeweils eine spezifische Aufgabe bearbeiten. Es geht nicht darum, aus reiner Gründlichkeit weitere Agenten hinzuzufügen; jeder zusätzliche Agent verursacht Verzögerungen, höhere Kosten sowie weitere Anweisungen, die gepflegt werden müssen. Es lohnt sich erst dann, wenn das Problem tatsächlich mehrere Schritte oder Spezialisierungen erfordert und die Anweisungen für einen einzelnen Agenten zu einer unübersichtlichen Liste von Sonderfällen werden.

Paralleler, unabhängiger Informationsabruf

Nicht jeder Schritt muss auf den vorherigen warten. Wenn eine Antwort Informationen aus mehreren unabhängigen Quellen benötigt, führt das Abfragen dieser nacheinander – zuerst Quelle A, dann B, anschließend C – sowie das Erstellen der Antwort zu Zeitverschwendung.

Mit dem parallelen Vorgehen werden die Abfragen gleichzeitig durchgeführt: Die Anfrage wird gleichzeitig an A, B und C gesendet, und ihre Ergebnisse werden vor der Erstellung der Antwort zusammengeführt. Unabhängige Abruf- oder Verarbeitungsaufgaben laufen nebeneinander und werden am Ende kombiniert. Dadurch können komplexe Arbeitsabläufe sowohl schneller abgewickelt als auch einfacher strukturiert werden, da jeder Zweig selbstständig ist. Der Nachteil besteht darin, dass der Kombinationsschritt mit überschneidenden oder widersprüchlichen Ergebnissen umgehen muss und entscheiden muss, was zu tun ist, falls ein Zweig fehlschlägt oder eine Zeitüberschreitung auftritt.

Planung vor Ausführung

Manche Fragen können überhaupt nicht durch eine einzige Suche beantwortet werden. Sie erfordern mehrere Suchvorgänge, Zwischenvorverarbeitungen oder Denkphasen, deren Reihenfolge wichtig ist.

Plan-and-execute RAG löst dieses Problem, indem es das Denken über die Aufgabe vom Ausführen selbst trennt. Der Ablauf sieht dann so aus:

• Die Frage erhalten
• Einen Plan erstellen
• Die geplanten Schritte ausführen
• Die Ergebnisse bewerten
• Antworten

Der Planer bestimmt, was erledigt werden muss; die Ausführung kümmert sich um die einzelnen Schritte. Dies ist besonders nützlich für mehrteilige Fragen, wie zum Beispiel Vergleiche in mehreren Dokumenten, bei denen ein direkter Einsatz von Tools oft zu oberflächlichen oder unvollständigen Antworten führt. Ein Plan gibt außerdem etwas zum Überprüfen, falls etwas schiefgeht – was bei einem Agenten, der jeden Schritt improvisiert, schwieriger ist.

Was macht ein RAG-System eigentlich zu einem agilen System?

Das Aufrufen eines LLM oder das Bezeichnen etwas als Agent macht ein System noch nicht automatisch agierend. Die entscheidende Eigenschaft ist, dass das System seine Situation bewerten und seinen nächsten Schritt wählen kann. Ein fester Ablauf setzt voraus, dass zunächst Informationen abgerufen und anschließend eine Antwort gegeben wird. Ein agierendes System kann sich eine Reihe von Fragen stellen:

• Ist für diese Frage überhaupt eine Informationsabfrage notwendig?
• Ist das Erhaltene tatsächlich nützlich?
• Sollte es mit einer anderen Abfrage erneut suchen?
• wäre eine andere Quelle besser geeignet?
• Wird die Antwort durch Beweise gestützt?
• Muss ein Mensch eingreifen?
• Sollte ein anderer, spezialisierter Agent übernehmen?
• würde eine vorherige Planung der Aufgabe bessere Ergebnisse liefern?

Jede Frage entspricht einem der oben genannten Muster, weshalb es hilft, agierendes RAG als eine Sammlung von Entscheidungspunkten statt als ein monolithisches Design zu betrachten. Diese Muster lassen sich natürlich auf Graph-Orchestrierung übertragen: Bewertung und Routing werden zu bedingten Kanten, Schleifen zu Zyklen mit einem Zähler im Zustand, die menschliche Überprüfung zu einer Unterbrechung und das Fan-Out zu parallelen Zweigen, die sich wieder verbinden.

Vergleichen Sie das Muster mit dem Fehler

Keine Anwendung benötigt alle diese Muster, und jedes von ihnen führt zu Verzögerungen, Kosten sowie zusätzlichen Komponenten. Wählen Sie entsprechend dem tatsächlich beobachteten Fehler aus:

• Falls die Qualität der Informationsbeschaffung das Hauptproblem ist, reicht möglicherweise die Umformulierung der Abfragen mit einem Relevanzbewerter aus.
• Falls die Wissensdatenbank Lücken aufweist, fügen Sie eine Ersatzquelle hinzu.
• Falls Sie mehrere Wissensquellen nutzen, fügen Sie ein Routing hinzu.
• Falls einige Entscheidungen einer Überwachung bedürfen, fügen Sie einen menschlichen Kontrollpunkt hinzu.

Falls der Workflow unterschiedliche Spezialistenaufgaben oder unabhängige Abfragen beinhaltet, sollten Sie einen Überwacher oder eine parallele Verteilung in Betracht ziehen.

Falls Fragen mehrere abhängige Schritte erfordern, fügen Sie eine Planungsebene hinzu.

Zusammenfassung

Die Frage, die zu nützlichen Verbesserungen führt, lautet nicht, wie man ein RAG-System agiler macht. Vielmehr geht es darum, wo das System derzeit blind handelt: Dokumente weiterleitet, die niemand überprüft hat, in falschen Quellen sucht, einer unbegründeten Antwort vertraut oder eine Entscheidung durchsetzt, die eigentlich von einem Menschen getroffen werden sollte. Instrumentalisieren Sie den Workflow, damit Sie erkennen können, welche dieser Fehler am häufigsten auftreten, fügen Sie den kleinstmöglichen Entscheidungspunkt hinzu, der den häufigsten Fehler abfängt, und messen Sie erneut, bevor Sie den nächsten hinzufügen.