Acht RAG-Best Practices getestet an 746 Seiten von Handbüchern

Welche beliebten RAG-Optimierungen haben die Messungen an drei Produkthandbüchern überstanden: Bereinigung von Bindestrichen, Größenanpassung der Blöcke, Routenplanung, Eskalationsschwellenwerte und Neuranking.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20269 Min. Lesezeit2005 Wörter

Quellen: I Measured Every RAG “Best Practice” on 746 Pages of Product Manuals. Only Four Survived.

Ein Support-Bot, der auf drei echten PDFs basiert – einem 408-seitigen Bedienungsheft für Elektrofahrzeuge, einem 329-seitigen Fernsehprogramm und einem 9-seitigen Prospekt mit einer kabellosen Maus – wurde zu einem Testfeld für acht beliebte RAG-Optimierungen. Die Regel war streng: Nichts wurde übernommen, es sei denn, eine Messung an diesem Korpus, bewertet anhand eines gelabelten Antwortbogens, zeigte, dass es funktionierte. Literatur und Gewohnheiten zählten nicht.

Das Ergebnis war eine Steigerung der Genauigkeit von 72 % auf 89 %, während die Anzahl der Prompt-Tokens pro Anfrage von 14 auf 57 % sank. Dies resultierte aus vier Änderungen und nicht aus acht. Zwei der verworfenen Ideen schadeten sogar aktiv, und eine implementierte Optimierung funktionierte letztendlich nie. Die gesamte Untersuchung kostete etwa 0,015 US-Dollar an API-Aufrufen.

So verlief es mit jeder Idee. Der wertvollste Punkt auf der Liste ist überhaupt keine RAG-Technik.

Ein Fehler, größer als jeder Hyperparameter

Bevor Sie die Abfrageanpassungen vornehmen, überprüfen Sie, was tatsächlich im Index angekommen ist. Alle bestätigen, dass das PDF erfolgreich parsen wurde. Die wichtigere Frage ist, in welchem Zustand sich der Text befindet.

Ein Schleifenprogramm liefert die Antwort darauf:

SOFT = ""    # U+00AD, the soft hyphen
for manual in manuals:
    print(manual.name, extract(manual).count(SOFT))

Das Fahrzeughandbuch zeigte 2.272 an.

Ein weicher Bindestrich ist eine Anweisung des Setzers an den Renderer: Brich das Wort hier ab, wenn die Zeile zu Ende geht. Ein PDF-Reader befolgt diese Anweisung und versteckt den Bindestrich, sodass er nicht sichtbar ist, während ein Textextraktor ihn in Rohform weitergibt. Auf der Seite erscheint ein sauberes Wort, während der Index Zeichen wie „ve“, „weicher Bindestrich“, Zeilenumbruch oder „hicle“ enthält.

In diesem Handbuch wurden 999 verschiedene Wörter geteilt, darunter immer wieder das wichtigste Substantiv in jedem Fahrzeughandbuch. Das Wort „Vehicle“ erschien 1.486 Mal als vollständiges Wort, obwohl es 1.580 Mal erscheinen sollte. 94 Vorkommen konnten durch Suchfunktionen nicht gefunden werden.

Dies schädigt gleichzeitig jeden Abrufpfad. Die Schlüsselwortsuche findet nur exakte Zeichenketten – „hicle“ gilt beispielsweise nicht als „vehicle“ – und es gibt keine Teilauswertung. Die Vektorsuche funktioniert schlechter als erwartet, da Embedding-Modelle Text in Unterwortsfragmente zerlegen, wodurch ein Fragment wie „hicle“ in bedeutungslose Teile zerfällt. Selbst bei einem glücklichen Treffer wird ein verfälschter Kontext in die Anfrage eingefügt.

Die Reparatur erfolgt in einer Zeile – mit einer Falle daneben. Auch justified-Text bricht an echten Bindestrichen. Ein fehlerhafter Begriff wie „cus-tomer“ sollte zu „customer“ zusammengefügt werden, doch „toll-free“ muss weiterhin mit Bindestrich geschrieben bleiben; um sie voneinander zu unterscheiden, ist ein Wörterbuch erforderlich. Es gab 95 solcher Fälle, und alle blieben fehlerhaft, wobei die Zahl notiert wurde. Ein bekannter Abstand von 95 Wörtern ist ein völlig anderes Phänomen als eine stille Schätzung, die heimlich ein Korpus verfälscht. Keine Chunk-Größe kann ein Wort wiederherstellen, das der Index niemals als Wort gespeichert hat.

Die beste Chunk-Größe ist eine Falle

Größere Abschnitte enthalten mehr Kontext und passen daher zu mehr Fragen, ziehen aber gleichzeitig auch zusätzlichen, irrelevanten Text dauerhaft in jede Abfrage ein. Es gibt eine Überlappung, damit eine Antwort, die an einer Grenze liegt, nicht in zwei Teile geteilt wird.

Nine Konfigurationen wurden anhand der Lösungskarte überprüft. Die Genauigkeit lässt sich kostenlos messen, während die Kosten das sind, was dafür bezahlt werden muss.

Die Überlappung hat sich nie ihren Platz verdient – allerdings nicht auf die Weise, wie es auf den ersten Blick scheint. Bei 700 Zeichen brachte das Weglassen der Überlappung einen Gewinn von 11 Punkten, was bedrohlich erscheint, bis die andere Kombination geprüft wird: Bei 1800 Zeichen erzielten eine Überlappung von 0, 100 und 200 jeweils genau 89 %. Eine Vergleichsanalyse besagt, die Überlappung sei teuer, während eine andere behauptet, sie habe keinerlei Auswirkung.

Was beide Ergebnisse erklärt, ist eine Statistik, die fast gar nicht in den Bericht aufgenommen wurde. In jeder Konfiguration, selbst der kleinsten, passte jede Antwort vollständig in einen einzigen Abschnitt, und keine Antwort wurde jemals an einer Grenze abgeschnitten. Die Überlappung diente als Schutz vor einem Problem, das diesem Korpus fehlt, weshalb ihr gemessener Wert zwischen Null und negativ lag. Die Überprüfung, wie oft Antworten tatsächlich eine Grenze überschreiten, sollte der Zahlung dieses Aufschlags vorausgehen.

Dann kommt die Falle. Die beste Bewertung von 89 % wurde bei 1400 Zeichen mit 200 Prozent Überlappung erzielt. Wenn man diese Wahl trifft, müssen pro Abfrage 1.283 Token statt 750 gesendet werden, was im Laufe der Lebensdauer des Produkts zu 71 % mehr Daten bedeutet. Bei 18 Fragen bedeutet 89 % 16 richtige Antworten und 83 % 15 richtige Antworten. Die beste Konfiguration ist genau um eine Frage besser als die günstigste.

Daher sollte der Gewinner nicht automatisch ermittelt werden. Man sollte die günstigste Konfiguration wählen, deren Ergebnis sich nicht vom des Gewinners unterscheiden lässt – was hier bedeutet, dass alle Ergebnisse innerhalb von 8 Punkten liegen dürfen. Unter dieser Regel waren sechs von neun Konfigurationen unentschieden, und die günstigste davon gewann. Die Genauigkeit stieg von 72 % auf 83 %, zudem entstand ein geringerer Kostenaufwand – der erste „kostenlose“ Erfolg des Projekts, erreicht durch die Weigerung, die gemessene Kennzahl zu optimieren.

Ein Filter, der 22 Punkte kostete

Das Korpus umfasst drei Produkte. Eine Frage zum Maus hat keinen Grund, in einem 408-seitigen Automanual zu suchen, da die anderen beiden Dokumente nur zu Fehlern führen können. Der Plan bestand darin, das Produkt zu erkennen und die Suche auf dieses Manuell zu beschränken.

Ein Klassifikator erledigte dies. Er wählte 78 % der Zeit richtig, und zwar in weniger als 4 ms – ohne jeden Kostenaufwand. Das ist eine solide Mehrheit im Vergleich zur Suche in dreimal so viel Text. Dennoch sank die Genauigkeit um 22 Punkte.

Es dauerte erstaunlich lange, bis das Mechanismus sichtbar wurde. Ein falscher Filter führt nicht dazu, dass die richtige Antwort herabgestuft wird – er löscht sie vielmehr. Ohne Filter findet eine verwirrende Suche in allen drei Handbüchern dennoch den richtigen Abschnitt, vielleicht an Stelle 4 statt 1, und ein Neuranking-Algorithmus kann ihn retten. Mit Filterung sucht eine falsch gerichtete Frage im falschen Dokument, und der richtige Abschnitt wird nicht herabgestuft, weil er nicht im Kandidatensatz vorhanden ist.

Ein Klassifikator, der zu 78 Prozent richtig liegt, kostet daher nicht etwas an Qualität. Er setzt eine feste Obergrenze von 78 Prozent für alles, was danach kommt – unabhängig davon, wie gut der Rest der Verarbeitungskette ist.

Die Lösung besteht nicht in einem präziseren Klassifikator, sondern darin, sich zurückhalten zu können: Wenden Sie den Filter nur dann an, wenn Sie sich sicher sind, und durchsuchen Sie alles, wenn die Ergebnisse der beiden besten Produkte ähnlich hoch bewertet sind. Bei einer Frage wie „Wie verbinde ich es über Bluetooth?“ hat das Wort „es“ große Bedeutung, und der Klassifikator ist genauso unsicher wie jeder andere auch.

Oder die Inferenz ganz überspringen

Der günstigste Router wird in einem Dropdown-Menü angezeigt. Für ein solches Tool kostet es nur einen Tastendruck, herauszufinden, um welches Produkt es bei der Frage geht – einen Tastendruck, den der Benutzer ohnehin oft ausführt, wenn er die Chat-Funktion von einer Produkt-Hilfeseite aufruft. Dadurch wird eine Mehrdeutigkeit sofort beseitigt, die der Klassifikator nur erraten kann, und der Filter ist jedes Mal korrekt.

Die Zahlen sind genau. Der Klassifikator hat 4 von 18 Fragen falsch zugeordnet. Die Suche ohne Filter fand 15 Antworten, die Suche mit Filter fand 11, und jede Fehlzuordnung verwandelte eine Treffer in keinen Treffer. Wenn man die Fehlzuordnungen beseitigt, bleibt die Genauigkeit erhalten, während auch die von dem Filter versprochene Präzision erreicht wird.

Die Optimierung, die nie durchgeführt wurde

Dieser Teil wäre aus Gründen des Erscheinungsbilds verlockend, zu löschen.

Der Plan bestand darin, bei zuverlässigen Suchergebnissen mit einem günstigen 20B-Modell zu antworten und bei unsicheren Ergebnissen auf ein 120B-Modell umzusteigen. Falsche Antworten neigen dazu, dort aufzutreten, wo die Suche unsicher war, und der Neurankierer liefert bereits eine Zuverlässigkeitsbewertung, sodass der zusätzliche Aufwand nichts kostet.

Der Schwellenwert wurde auf 0,0 gesetzt, was prinzipiell erschien: Ein Cross-Encoder gibt einen Logit-Wert aus, sigmoid(0) entspricht 0,5, und ein Wert unter Null deutet darauf hin, dass der oberste Teil wahrscheinlich weniger relevant als relevant ist. Die Darstellung der tatsächlichen Verteilung zeigte jedoch etwas anderes – die beobachteten Höchstwerte lagen mindestens bei 3,24, hatten einen Median von 8,29 und ein Maximum von 10,00.

Der Schwellenwert lag unter dem niedrigsten je gemessenen Wert, weshalb er niemals ausgelöst wurde, nicht einmal ein einziges Mal. Die Eskalationsrichtlinie entsprach bytegenau der ständigen Verwendung des günstigeren Modells plus den damit verbundenen Overhead-Kosten – also einer Zeile in der Ergebnistabelle, die eigentlich nichts misst, aber wie eine Erkenntnis aussieht. Ein Schwellenwert von Null ist keine neutrale Standardwertung. Es handelt sich dabei um eine Behauptung bezüglich einer Verteilung, die niemand überprüft hat, und jeder absolute Logit-Schwellenwert weist diesen Fehler auf, da sich die Verteilung ändert, wenn sich der Reranker oder das Korpus verändert.

Die Lösung bestand darin, die Zahl abzuleiten. Es sollten nur die beiden Endpunkte für „echt“, „immer günstig“ und „immer teuer“ ausgeführt werden, wobei die Punktzahl, Richtigkeit und Kosten jeder Frage aufgezeichnet wurden. Jeder Zwischenschwellenwert bedeutet anschließend eine erneute Verarbeitung der bereits im Speicher vorhandenen Datensätze, ohne zusätzliche API-Aufrufe, sowie eine vollständige Durchsicht statt einer stichprobenartigen.

Die Auswertung brachte eine Überraschung: Jeder Schwellenwert ändert nur die Kosten, während die Genauigkeit unverändert bleibt. Die Diagnose zeigt den Grund dafür. Von zwölf Fragen konnte nur eine wiederhergestellt werden, was bedeutet, dass das günstige Modell versagt hat und das teure Modell erfolgreich war. Diese Frage erzielte 10,00 Punkte, den höchsten Wert im Bereich, während die Fragen, die das günstige Modell bereits richtig beantwortet hatte, eine Medianwert von 8,29 aufwiesen. Der einzige Fehler, der eine Eskalation rechtfertigte, war jener, bezüglich dessen das System am sichersten war – daher kann keine Regel, die auf Eskalation bei Unsicherheit beruht, ihn bei irgendeinem Schwellenwert erkennen. Das Routingsignal versagt daran, das vorherzusagen, wofür es eigentlich bestimmt ist.

Ein Nebeneffekt trat ebenfalls auf. Der Live-Test ergab 92 %, während die Wiederholung der bereits bezahlten Datensätze 83 % vorhersagte. Der Unterschied rührt nicht von einem bestimmten Schwellenwert her, sondern davon, dass der LLM-Bewerter identische Antworten bei einer zweiten Prüfung unterschiedlich bewertet und dadurch eine 9-Punkte-Steigerung vermeidet, die lediglich Rauschen darstellt.

Die Änderung, die sich zweimal auszahlte

Die Neubewertung war der sauberste Lösungsweg, und der Grund dafür lohnt es, ihn sowohl zu verstehen als auch anzuwenden.

Bei einer Vektorabfrage werden die Frage sowie jeder Datensatz einzeln durch ein Modell eingespeist, das sie niemals als Paar betrachtet. Ein Cross-Encoder hingegen nimmt das Paar als einzige Eingabe und bewertet es direkt – was zwar präziser ist, aber für die Verarbeitung eines gesamten Korpus viel zu langsam ist. Deshalb holt der Prozess kostengünstig 25 Kandidaten ab, sortiert sie erneut und behält die besten 4.

Die Recall-Rate stieg von 83 % auf 89 %. Noch aussagekräftiger ist jedoch, wo die Ergebnisse anfielen. Vor der Neubewertung lag der richtige Ergebnisabschnitt in der Regel auf Platz zwei oder drei, weshalb fünf Ergebnisse zur Sicherheit ausgewählt wurden. Danach war er meist auf Platz eins, und vier Ergebnisse reichten aus. Wenn man sich mit der Basisgenauigkeit zufriedengibt, können es bereits zwei Ergebnisabschnitte sein, was zu 57 % weniger Tokens führt.

Weil die Reihenfolge verbessert wird, erreichen weniger Ergebnisabschnitte dieselbe Genauigkeit, und es werden nur die Prompt-Tokens abgerechnet. Diese Änderung sichert eine höhere Genauigkeit und bringt gleichzeitig einen Rabatt mit sich. Der Preis beträgt 73 ms lokaler CPU-Zeit, im Vergleich zu 1.252 ms bei einem Aufruf eines LLM – ein Unterschied, den niemand bemerkt.

Was übernommen wird

Prüfen Sie die Eingabe, bevor Sie den Retriever verwenden. Eine einfache Schleife kann entweder Probleme wie das mit Bindestrichen aufdecken oder bestätigen, dass keine Grenzen vorhanden sind, was spätere Aktionen sicherer macht.
Ein Standardwert in der Konfiguration ist entweder die Messung einer anderen Person – oder die von niemandem. Ein Überschneidungswert von 100 hat nie geholfen und eine Schwellenwert von 0,0 hat sich nie ausgelöst; in der Produktion würden sich beide Fälle ebenfalls nicht melden. Das einzige Symptom wäre eine höhere Rechnung ohne Erklärung.
Betrachten Sie, wie sich eine Optimierung in den Fällen verhält, in denen sie Fehler macht – und nicht nur, wie oft sie Fehler macht. Ein Filter, der zu 22 Prozent Fehler macht, aber lediglich die Ergebnisse neu ordnet, ist noch in Ordnung. Einer, der zu 22 Prozent Fehler macht und dadurch eine Antwort unerreichbar macht, hingegen nicht.
Eine abgelehnte Idee ist ein Ergebnis. Vier Ideen, die nicht implementiert werden, sind vier weitere Elemente ohne Wartung, Überwachung, Versionsverwaltung oder Nachtschichten-Alarme.

Es gibt eine Einschränkung. Der Antwortschlüssel enthält 18 überprüfte Frage-Zitat-Paare, sodass eine einzelne Frage 5,6 Punkte wert ist. Der 22-Punkte-Kollaps betrifft vier Fragen, was ausreicht, um darauf zu reagieren. Das Ergebnis eines 11-Punkte-Überlappungsfalls betrifft zwei Fragen, wodurch die Richtung bestenfalls angegeben werden kann. Ein auf den eigenen Daten eines Teams basierender Antwortschlüssel sollte Vorrang vor der Vertrauensseligkeit gegenüber den Zahlen Dritter haben. Die vollständige Ausführung dauert auf einer Laptop-CPU etwa fünf Cent, wobei eine harte Budgetobergrenze eine Ausnahme darstellt, anstatt die Zahl auf einer Rechnung anzugeben.