Sieben RAG-Architekturen jenseits des naiven Ansatzes und wann sich jede eignet

Der erste RAG-Pipeline, den die meisten Menschen erstellen, ist einfach: Die Dokumente werden in Abschnitte aufgeteilt, es werden Embeddings erzeugt, die besten Ergebnisse abgerufen, diese in den Prompt eingefügt und das LLM wird zur Beantwortung aufgefordert. Die Demo funktioniert und die Antworten klingen überzeugend. Dann tauchen echte Fragen auf. Der falsche Abschnitt wird zurückgegeben. Das richtige Dokument erscheint, doch der benötigte Abschnitt fehlt. Manchmal befindet sich die Information zwar in der Datenbank, doch das Modell bekommt sie nie zu sehen.

Das Seltsame ist, dass kein Komponente defekt ist. Die Pipeline erledigt genau das, wofür sie konstruiert wurde. In den Tutorials wird selten die eigentliche Lektion betont: Eine Vektordatenbank zu füllen ist einfach, während es schwierig ist, dem Modell die richtigen Informationen zur Verfügung zu stellen. Diese ursprüngliche Konzeption stellt eine naive Form von RAG dar. Sie hat ihre Verwendungsmöglichkeiten, da sie der natürliche Ausgangspunkt ist, doch wenn die Dokumente unübersichtlich werden, die Fragen schwieriger oder Zuverlässigkeit wichtig ist, erreicht ein solches Abrufen-und-Antworten-Verfahren seine Grenzen. Es folgen sieben weiterführende Architekturen, jede mit dem Problem, das sie löst, ihren wahrscheinlichen Fehlerquellen sowie einer Methode, um zu beurteilen, ob ein bestimmtes System sie benötigt.

Warum RAG existiert

Ein LLM kennt nur das, was es während des Trainings gelernt hat. Wenn man nach internen Unternehmensdokumenten oder aktuellen Ereignissen fragt, gibt es entweder zu, nichts zu wissen, oder schlimmer noch, erfindet eine selbstsichere Antwort. RAG behebt dieses Problem, indem es dem Modell erlaubt, wie bei einer Prüfung Notizen heranzuziehen. Das System findet zunächst relevante Materialien und gibt sie als Referenz weiter, sodass das Modell nicht allein aus dem Gedächtnis antworten muss.

Der grundlegende Ablauf ist wie folgt.

Wenn ein Benutzer eine Frage stellt, durchläuft das System vier Schritte:

1. Sucht in der externen Wissensdatenbank nach relevantem Material
2. Holt die am besten passenden Abschnitte ab
3. Fügt diese Abschnitte dem Prompt neben der Frage hinzu
4. Schickt alles an das LLM, das die Antwort aus diesem Kontext erstellt

Kurz gesagt: Frage stellen, suchen, Informationen abrufen, Kontext hinzufügen, LLM nutzen, Antwort erhalten. Dies funktioniert gut bei kleinen, übersichtlichen Dokumentensätzen. Reale Daten verhalten sich selten so, und es treten in der Regel fünf Schwächen auf:

• Die Teilbereiche verlieren den Kontext. Ein Auszug, der besagt, dass das Umsatzwachstum 3 % beträgt, gibt nicht an, um welche Firma oder welches Quartal es sich handelt.
• Informationen gehen verloren. Tabellen, Diagramme und gescannte Seiten überstehen oft die textbasierte Suche nicht.
• Die erste Suche kann falsch sein, und einfaches RAG versucht nicht, eine andere Suche durchzuführen.
• Frühere Gespräche verschwinden. Ohne Speicherung beginnt jede Sitzung von vorne.
• Fakten bleiben voneinander getrennt. Wenn Informationen über verschiedene Dokumente verteilt sind, kann es notwendig sein, Verbindungen herzustellen, damit eine Antwort sinnvoll wird.

Es handelt sich dabei nicht um fünf zufällige Probleme. Sie erklären, warum es unterschiedliche Architekturen gibt, und jede davon behebt eine spezifische Störstelle im grundlegenden Ablauf.

1. Anmerkungen zu den kontextuellen Abschnitten

Vor der Speicherung eines Abschnitts wird eine kurze Anmerkung hinzugefügt, die angibt, worum es geht, damit der Abschnitt auch nach dem Verlassen des ursprünglichen Dokuments noch verständlich ist. Stellen Sie sich vor, man reißt einen Absatz aus einem Buch und gibt ihn einem Fremden ohne Titel oder Kapitelnummer – er kann nicht erkennen, worauf dieser Absatz sich bezieht. Befestigen Sie daher zunächst eine Anmerkung: Dies stammt aus Kapitel 4, über die Umsätze des Unternehmens im zweiten Quartal. Das ist die ganze Idee.

Der reine Abschnitt besagt, dass der Umsatz im Vergleich zum Vorquartal um 3 % gestiegen ist, wobei das Unternehmen und das Jahr unklar sind. Mit einer hinzugefügten Anmerkung wird klar, dass es sich um die Mitteilung von ACME Corp aus dem zweiten Quartal 2023 handelt, gefolgt von derselben Aussage.

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

Der Vorteil ist, dass die abgerufenen Teile für sich genommen sinnvoll sind und die Suchmethode selbst unverändert bleibt, da nur das, was gespeichert wird, sich ändert. Der Nachteil ist die Kosten: Eine Notiz pro Teil kostet Zeit und Geld, noch bevor mit der Suche begonnen werden kann, und eine schlecht verfasste Notiz kann die Suche genauso leicht in die falsche Richtung lenken wie eine gute.

2. Multimodale Suche

Dokumente sind oft überhaupt kein reiner Text. Die Umwandlung einer PDF-Seite in Text kann Tabellen und Diagramme verfälschen, weshalb eine Alternative darin besteht, dem System zu erlauben, die Seite als Bild anzusehen. Vergleichen Sie das Lesen einer Beschreibung eines Diagramms mit dem Anschauen des Diagramms selbst. Eine Beschreibung kann Details weglassen oder Zahlen falsch angeben, während das Original dies nicht tun kann.

Im älteren Verfahren wird eine PDF-Seite in Text umgewandelt, die Tabellenstruktur wird geschätzt und anschließend im Text gesucht, wodurch Zahlen und Strukturen dabei durcheinandergeraten können. Im multimodalen Verfahren wird die Seite direkt als Bild durchsucht.

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

Dies bewältigt Tabellen, Diagramme und Scans, die bei der Textextraktion verfälscht werden, und beseitigt außerdem einen anfälligen Schritt in der Verarbeitungskette. Die Kosten bestehen aus aufwendigerer Rechenleistung im Vergleich zur Suche nach reinem Text sowie in einem jüngeren Ökosystem mit weniger Tools und geringerem Wissensstand der Community.

3. Hybride Suche

Zwei Arten von Suchen laufen gleichzeitig ab – eine, die den Kontext versteht, und eine, die exakte Wörter abgleicht – wobei die Ergebnisse miteinander kombiniert werden. Stellen Sie sich zwei Bibliothekare vor: Der eine versteht, was Sie meinen, auch wenn Ihre Formulierung ungenau ist. Der andere hat kein Verständnis für den Kontext, findet aber immer das Dokument mit dem genau eingegebenen Code. Der Vorteil liegt darin, beide Ansätze zu nutzen.

Nehmen wir die Abfrage „error E0502 borrow checker“. Die auf den Kontext ausgerichtete Suche findet Dokumente zu einem verwandten Thema, selbst ohne den genauen Satz; die Suche nach exakten Wörtern findet den wörtlichen String „E0502“, und das kombinierte Ergebnis vereint beides.

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

Eine einzige Suche deckt sowohl allgemeine konzeptionelle Fragen als auch präzise technische Begriffe ab, was ein häufiges Problem beseitigt: Eine ausschließlich auf Bedeutungen basierende Suche funktioniert oft unzureichend bei Codes, IDs und Fachjargon. Der Preis dafür ist der Betrieb von zwei Suchsystemen, und die Entscheidung, wie viel Gewicht den Ergebnissen jedes Systems beigemessen werden soll, erfordert sorgfältige Anpassungen.

4. Suchverfahren im Graphen- und Kartenstil

Anstatt isolierte Datenblöcke zu speichern, zeigt dieser Ansatz auf, wie die Personen, Unternehmen und Ideen in den Dokumenten miteinander verbunden sind, gruppiert die verwandten Elemente und erstellt im Voraus eine kurze Zusammenfassung für jede Gruppe. Wenn eine Frage zu umfassend ist, um mit einem einzelnen Datenblock beantwortet zu werden, greift das System auf diese Gruppenzusammenfassungen zurück und kann sogar selbst entscheiden, welche Gruppen einer genauen Betrachtung bedürfen.

Nehmen wir an, jemand möchte die zentralen Themen aller in diesem Jahr veröffentlichten Inhalte erfahren. Kein einzelner Artikel beantwortet diese Frage. Wenn die Organisation in Abteilungen aufgeteilt wäre, von denen jede eine einseitige Zusammenfassung ihrer Arbeit enthält, würde das Lesen dieser Seiten schnell eine Antwort liefern. Das ist die Karte. Eine intelligentere Variante verhält sich wie ein Assistent, der zunächst herausfindet, welche Abteilungen für die Frage relevant sind, anstatt alle Zusammenfassungen ungeachtet dessen zu lesen.

Der Prozess besteht aus zwei Schritten. Zuerst wird die Karte im Voraus erstellt: Es werden herausgefunden, wie Menschen und Ideen miteinander verbunden sind, verwandte Elemente gruppiert und für jede Gruppe eine Zusammenfassung verfasst. Zweitens wird anhand dieser Zusammenfassungen auf eine allgemeine Frage geantwortet.

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

Vorteile: Umfassende thematische Fragen können beantwortet werden, wenn kein einzelner Teil dies allein schafft, Verbindungen zwischen vielen Dokumenten können auf einmal nachverfolgt werden und die selbstauswählende Version überspringt unwichtige Zusammenfassungen. Nachteile: Die Karte erfordert die Erstellung eines echten Projekts, Teile davon müssen jedes Mal neu erstellt werden, wenn sich die Dokumente erheblich ändern, und der Schritt zur Auswahl von Gruppen ist ein weiterer Punkt, an dem das System falsche Entscheidungen treffen kann.

5. Agentenbasierte, iterative Suche

Eine Karte beantwortet die grundlegenden Fragen, doch manche Fragen erfordern trotz der Qualität der Karte mehrere Suchvorgänge. Hier sucht das System, prüft die Ergebnisse, entscheidet, ob sie ausreichen, und wiederholt den Vorgang bei Bedarf. Vergleichen Sie einen Suchmotor mit einem Forschungsassistenten: Der Motor liefert eine Liste und hört auf. Der Assistent liest die Ergebnisse, erkennt, dass sie unzureichend sind, und sucht erneut – wobei er aus seinen Erkenntnissen lernt, beim nächsten Mal gezielter zu suchen.

Der Kreislauf verläuft wie folgt: Eine Frage tritt ein, es wird eine Suche durchgeführt, und das System fragt, ob dies ausreicht. Falls nicht, sucht es erneut unter Verwendung der gewonnenen Erkenntnisse – und wenn auch das fehlschlägt, versucht es einen anderen Ansatz.

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

Es bewältigt Fragen, die tatsächlich mehrere Abfragen erfordern, und gibt nicht nach einer fehlerhaften Suche auf wie ein fester Ablauf. Der Nachteil besteht darin, dass pro zusätzlicher Suche eine weitere Reise nötig ist, was Kosten und Wartezeiten verursacht – außerdem kann ein falsch gewählter Ansatz mehrere Versuche erfordern, bevor der Fehler bemerkt wird.

6. Mehr-Agenten-Auffindung

Hier plant, sucht, überprüft und schreibt kein einziges System alleine. Diese Aufgaben werden auf kleinere, spezialisierte Systeme aufgeteilt, wobei jedes System eine Aufgabe besonders gut erledigt, während ein Koordinator den gesamten Prozess steuert. Eine einzelne Person, die gleichzeitig recherchiert, schreibt und Fakten überprüft, leistet in der Regel nur mittelmäßige Arbeit in allen drei Bereichen. Ein kleines Team mit einem Planer, einem Suchenden, einem Überprüfer und einem Schreiber erbringt in der Regel bessere Ergebnisse in jedem Bereich.

Eine Frage kommt ein, ein Planer entscheidet, was nachgeschlagen werden muss, die Suchenden gehen danach suchen – manchmal gleichzeitig aus verschiedenen Quellen – und ein Prüfer überprüft die Ergebnisse auf Genauigkeit.

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

Jeder Teil der Aufgabe erhält volle Aufmerksamkeit, anstatt dass ein einziges System alles gleichzeitig bewältigen muss, und parallele Suchvorgänge sparen Zeit. Andererseits erhöhen mehr kooperierende Systeme die Kosten pro Frage, und ein falsches Endergebnis erfordert erhebliche Anstrengungen, um es über mehrere Schritte hinweg zurückverfolgen zu können.

7. memorbasierte Suche

In diesem Ansatz sucht das System nicht nur in einer festen Dokumentensammlung, sondern auch in seiner eigenen Historie mit dem Benutzer und betrachtet frühere Gespräche als etwas, worauf man zurückgreifen kann, anstatt sie nach ihrem Ende zu vergessen. Stellen Sie sich einen Arzt vor, der vor jedem Besuch Ihre Akte durchliest, im Gegensatz zu einem, der von Ihnen jedes Mal die gesamte Krankengeschichte erzählen lässt. Der größte Teil dessen, was Sie beim letzten Besuch gesagt haben, befindet sich immer noch irgendwo in einer Datei, und ein gutes System hält ähnlichweise das Wichtige zur Hand und greift darauf zu, wenn es relevant ist.

Dadurch kann ein System auf Dinge zurückgreifen, die Tage oder Wochen zuvor erwähnt wurden, ohne alles gleichzeitig laden zu müssen. Es hilft bei persönlichen oder anhaltenden Aufgaben, nicht nur bei einmaligen Dokumentensuchen. Die Nachteile sind ein zusätzliches Speichersystem, das auf der Dokumentensuche aufbaut und somit mehr Komponenten erfordert, sowie die Tatsache, dass ältere Erinnerungen manchmal komprimiert oder zusammengefasst werden, um Platz zu sparen – dadurch können Details verloren gehen.

Auswahl

Naives RAG versagt stillschweigend. Es stürzt nicht ab und gibt keinen Fehler an. Die Benutzer erhalten einfach Antworten, die auf falschen Informationen beruhen, und alles scheint in Ordnung zu sein, bis jemand nachprüft.

Jede der oben genannten Architekturen existiert, weil jemand eine falsche Antwort auf eine bestimmte, behebbare Ursache zurückführte. Daher ist die neueste Option nicht automatisch die zu wählende. Wählen Sie diejenige, die zur Art der Störung bei der Informationsabrufung passt. Betrachten Sie den aktuellen Ablauf und fragen Sie sich ehrlich: Wenn die Suche falsch antwortet, hat sie dann das Falsche gefunden, ist ein Teil des Inhalts seinen Kontext verloren gegangen, oder hat das System nicht einmal eine zweite Überprüfung vorgenommen? Schon diese Frage weist auf die benötigte Architektur hin.