Der siebte und letzte Teil unserer Serie über moderne Retrieval-Augmented Generation (RAG)-Systeme.
Bisher haben wir in dieser Serie Schritt für Schritt eine stärkere Retrieval-Pipeline aufgebaut.
Wir begannen mit Keyword-Suche und BM25. Dann haben wir uns die Vektorsuche angesehen. Dann kombinierten wir beides mit Hybridsuche und RRF. Dann habe ich im vorherigen Beitrag Reranking und den Unterschied zwischen Bi-Encodern und Cross-Encodern erklärt. Der Kernpunkt war, dass das Retrieval zunächst gute Kandidaten finden sollte, und das Reranking dann die stärksten Belege auswählen soll.
Das gibt uns einen guten Retrieval-Stack, aber selbst eine starke Retrieval-Pipeline kann Schwierigkeiten haben, wenn der Nutzer eine komplexe Frage mit mehreren Informationsbedürfnissen stellt.
Echte Nutzerfragen sind unordentlich. Sie enthalten oft mehrere Informationsbedürfnisse in einem Satz.
Zum Beispiel:
It stops after we changed the gripper motor and shows F217, maybe calibration was missed.
Also, do we still use motor 700-1842 in the AX-360 variant? Das ist nicht eine Retrieval-Aufgabe. Es sind mehrere.
Das System muss den Alarm untersuchen. Es muss den Austauschkontext prüfen. Es muss nach Kalibrierungsanweisungen suchen. Es muss auch die Teilekompatibilität für eine bestimmte Maschinenvariante prüfen.
Wenn wir diese gesamte Frage als eine Suchanfrage senden, erhalten wir möglicherweise unvollständige Ergebnisse.
Ein besserer Ansatz ist Query Planning und Zerlegung.
Das System zerlegt die ursprüngliche Frage in kleinere Teilanfragen.
Zum Beispiel:
1. servo alarm F217 after gripper motor replacement
Source: service tickets
2. calibration steps after gripper motor replacement
Source: maintenance manuals
3. compatibility of motor 700-1842 with AX-360
Source: parts catalog Jede Teilanfrage ist fokussiert.
Jede Teilanfrage kann an die Quelle gesendet werden, wo die Antwort am wahrscheinlichsten zu finden ist. Das ist bereits deutlich besser, als alles überall zu durchsuchen.
Ein Service-Ticket-System ist nützlich für bekannte Vorfälle. Ein Wartungshandbuch ist nützlich für Verfahren. Ein Teilekatalog ist nützlich für Teilenummern und Kompatibilität. Eine Variantentabelle ist nützlich für Maschinenkonfigurationen.
Eine gute Quellenauswahl verbessert sowohl Qualität als auch Latenz. Hier beginnt das Retrieval agentischer zu werden. Agentisches Retrieval bedeutet, dass das System nicht nur einmal sucht.
Es plant. Es sucht. Es prüft die Ergebnisse. Es entscheidet, ob etwas fehlt. Dann sucht es möglicherweise erneut. Eine klassische RAG-Pipeline sieht wir folgt aus: Anfrage, Retrieval und Generierungsphase. Ein agentischer Retrieval-Ablauf sieht eher so aus:
Das ist wichtig für reale Fragen.
Der erste Retrieval-Durchgang findet möglicherweise die F217-Alarmbeschreibung und die Kalibrierungsanweisung, aber nicht die betroffenen Varianten.
Oder er findet die Teilenummer, aber nicht, ob sie noch im AX-360 verwendet wird.
Ein agentischer Retriever kann die abgerufenen Belege reflektieren und fragen:
Do I have enough information to answer the full question?
Which part is still unanswered?
Do I need another source?
Is there a contradiction between sources? Wenn etwas fehlt, kann er eine Follow-up-Suche durchführen.
Zum Beispiel:
AX-360 gripper motor BOM 700-1842 replacement partDer letzte Schritt ist die Ergebniszusammenführung.
Wenn mehrere Teilanfragen über mehrere Quellen hinweg suchen, sollte das System nicht einfach alle Abschnitte in den LLM-Prompt kippen.
Es sollte die Belege strukturieren.
Zum Beispiel:
Fault evidence:
F217 is related to servo following error or position mismatch.
The issue appears after gripper motor replacement in several service tickets.
Procedure evidence:
The maintenance manual requires recalibration after gripper motor replacement.
The calibration procedure includes checking end positions and drive parameters.
Compatibility evidence:
Motor 700-1842 is listed for AX-360 in the parts catalog.
The same motor is also used in AX-340.Diese Art von strukturierten Belegen ist deutlich nützlicher als eine zufällige Liste von Abschnitten.
Das LLM kann nun eine Antwort generieren, die vollständig, fundiert und leichter zu überprüfen ist.
RAG sollte nicht auf Vektorsuche reduziert werden. Das ist der Kernpunkt dieser gesamten Serie.
Vektorsuche ist nützlich, aber sie ist nur ein Teil des Retrieval-Stacks.
Echte Nutzer stellen unübersichtliche Fragen. Sie vermischen Symptome, Annahmen, Teilenummern, Varianten und Follow-up-Fragen in einem Satz.
Die zur Beantwortung benötigten Informationen können über Handbücher, Tickets, Kataloge, Konfigurationstabellen und interne Dokumentation verteilt sein.
Deshalb werden starke RAG-Systeme als Stack aufgebaut.
Die Keyword-Suche liefert Precision für exakte Begriffe. Die Vektorsuche liefert semantischen Recall. Die Hybridsuche kombiniert beides. RRF fusioniert die Rankings. Reranking verbessert die Precision. Query Planning zerlegt komplexe Fragen. Agentisches Retrieval steuert den gesamten Prozess.
Meiner Meinung nach ist das die Richtung, in die sich praktisches RAG entwickelt.
Nicht einfach größere Modelle. Nicht einfach größere Kontextfenster. Sondern bessere Retrieval-Systeme, die wissen, was sie suchen sollen, wo sie suchen sollen, wann sie erneut suchen sollen und wie sie dem Modell die richtigen Belege liefern können.
