Agentic RAG-Benchmark: Multidatenbank-Routing über 36 LLMs

Wir haben 36 große Sprachmodelle beim Cross-Database-Routing getestet. Jedes Modell erhält eine natürlichsprachliche Frage und 11 SQL-Datenbanken, die auf Absatzebene beschrieben sind, und muss dann entscheiden, welche Datenbank die Antwort enthält, bevor es SQL schreibt. Die 11 Datenbanken wurden aus 80 BIRD-SQL-Kandidaten ausgewählt, indem ihre Beschreibungseinbettungen geclustert wurden, sodass die Kandidaten semantisch nahe beieinander liegen und ihre echten Namen hinter den Bezeichnungen db_01 bis db_11 verborgen sind.

Jedes Modell erhielt denselben eingefrorenen Satz von 759 Fragen bei Temperatur 0, wobei der Bereichshinweis von BIRD vorenthalten wurde.¹ Jede Datenbank wird als ein Tool mit drei Aktionen bereitgestellt: Schemaauflistung, Tabellendetails und Abfrageausführung, unter einem Limit von 10 API-Aufrufen pro Frage. Die Tool-Liste wird für jede Frage permutiert, sodass die Kandidatenposition nicht als Routing-Fähigkeit interpretiert werden kann.

Routing-Genauigkeit bei den schwierigsten Fragen. Der Anteil der 184 schwierigsten Fragen, bei denen die vom Modell angegebene Datenbank mit der Gold-Datenbank übereinstimmt. Eine Frage gilt als eine der 184, wenn zwei unabhängige Signale übereinstimmen. Mindestens 5 ihrer 20 nächsten Nachbarn im Einbettungsraum müssen zu anderen Datenbanken gehören, und eine Jury aus drei Modellen muss sie als verwirrend einstufen. Dies ist die zentrale Routing-Metrik.

Die 184 Fragen stammen aus 6 der 11 Datenbanken, mit Anteilen von 51 (regional_sales), 50 (retail_world), 43 (superstore), 27 (works_cycles), 8 (debit_card_specializing) und 5 (college_completion). Die vier Commerce-Datenbanken tragen 171 der 184, das sind 93 %. Die anderen fünf Datenbanken tragen nichts bei, da sie semantisch so isoliert sind, dass keine ihrer Fragen beide Signale erfüllt. Die Zahl misst daher das Routing unter Datenbanken, die darauf ausgelegt sind, schwer auseinanderzuhalten zu sein, und sie wird von einem Commerce-Cluster dominiert statt über elf Domänen verteilt.

Angegebene Route. Die Datenbank, die das Modell in seiner endgültigen Antwort unter einem expliziten selected_database-Schlüssel angibt. Ein Durchlauf, der keine Datenbank nennt, erhält null Punkte, anstatt den letzten Tool-Aufruf zu erben. Aus Fließtext wiederhergestellte Routen werden ausgeschlossen und separat berichtet.

Ergebnisse des Agentic RAG-Benchmarks

Erneutes Ausführen des Panel-Leaders lässt ihn auf den sechsten Platz fallen

claude-opus-5 routete 0.848 der schwierigsten Fragen korrekt, das sind 156 von 184. Wir führten denselben Durchlauf ein zweites Mal unter identischen Bedingungen durch – selber eingefrorener Satz, gleiche Anonymisierung, Temperatur 0 –, und das Ergebnis betrug 0,8207, also 151 von 184. Dieser zweite Wert ist der veröffentlichte Score von claude-fable-5, das auf Platz sechs liegt. Die Plätze 1 bis 6 reichen von 156 von 184 korrekten Antworten bis hinunter zu 151 von 184, eine Differenz von fünf Fragen, was genau der Verschiebung des Spitzenreiters zwischen zwei Läufen entspricht.

Ein zweites Modell reproduzierte das Muster. qwen3.8-max verschob sich von 0,8315 (153/184) auf 0,8152 (150/184). Die Bereiche für leichte und mittelschwere Fragen veränderten sich bei beiden Modellen um 0,0000, und die restliche Bewegung liegt in den drei schwierigen Bereichen, wobei qwen3.8-max sich auch von 153 auf 152 bei den Fragen verschob, die Nachbarzählung kennzeichnet.

qwen3.8-max weist das kleinere aggregierte Delta von 1,6 Punkten gegenüber 2,7 auf und gleichzeitig die größere Abweichung zu sich selbst: Es routete bei 13 der 184 schwierigen Fragen anders, während opus-5 bei 8 abweicht. Ein Modell kann seinen eigenen Score reproduzieren und dennoch bei einer von vierzehn schwierigen Fragen von sich selbst abweichen.

Hierbei sind zwei Einschränkungen zu beachten. Eine Wiederholung liefert einen absoluten Unterschied, keine Standardabweichung, sodass die Spanne von 1,6 bis 2,7 Punkten eher eine Untergrenze des Rauschens als eine Beschreibung desselben darstellt. Und 34 der 36 Panel-Zeilen haben überhaupt keinen Wiederholungslauf. Lesen Sie diese Scores in Stufen, nicht in Rängen.

Die 11 Datenbanknamen allein routen innerhalb von 4 Punkten des vollständigen Katalogs

Mit den echten Datenbanknamen und ohne jegliche Beschreibungen erzielt claude-opus-4.8 0.688 und gemini-3.5-flash 0.711. Mit dem vollständigen Katalog, also den echten Namen plus allen 11 Absatzbeschreibungen, erreichen dieselben beiden Modelle 0.672 und 0.750, sodass bei claude-opus-4.8 die Namen allein einen höheren Score erzielen als der gesamte Katalog.

Das Ersetzen der Namen durch db_01 bis db_11 kostet opus-4.8 7,0 Punkte und gemini 4,7. Ein Lauf unter echten Namen misst sowohl Namenserkennung als auch Verständnis, weshalb sämtliche hier veröffentlichten Zahlen aus der anonymisierten Bedingung stammen.

Eine dritte Bedingung trennt die beiden Kanäle. Beibehaltung der echten Namen und Permutation der Beschreibungen zwischen den Datenbanken lässt das Routing auf 0.148 und 0.055 fallen, gemessen an denselben beiden Modellen in einem Pilotversuch mit 128 Fragen.

Auf Verwechselbarkeit ausgewählte Datenbanken sind etwa 20 Punkte schwieriger als zufällig gewählte

Wir ersetzten die 10 Distraktor-Datenbanken durch 10 zufällig aus den übrigen 69 von BIRD gezogene, über dieselben 128 Fragen, dieselbe Gold-Datenbank, beide Arme anonymisiert. Das Hard_strict-Routing steigt von 0.713 auf 0.920 bei claude-opus-4.8 und von 0.770 auf 0.966 bei gemini-3.5-flash. Beide Arme beantworten dieselben Fragen, sodass der Test ein McNemar-Test mit Kontinuitätskorrektur über die diskordanten Paare ist, mit p = 8.6e-04 und p = 2.4e-04. Elf zufällig ausgewählte Kandidaten lassen beide Modelle nahe der Decke.

Im einfachen Bereich ist derselbe McNemar-Kontrast nicht signifikant, p = 0,48 und p = 1,00. Cluster-ausgewählte Distraktoren sollten die Fragen stören, die Nachbarzählung als verwirrend kennzeichnet, und die übrigen unabhängig vom Panel routbar belassen, und genau dieses Muster zeigen die beiden Arme.

Diese Ablation ist nur beschreibungsbasiert und erfolgt im Single-Shot-Verfahren statt agentisch, mit einer zufälligen Panel-Auswahl pro Frage. Sie untermauert die Behauptung, dass die Auswahl durch Cluster-Erkennung messbar schwierigeres Routing erzeugt als eine Zufallsauswahl. Sie untermauert hingegen nicht die Behauptung, dass die Nachbarzählung selbst Schwierigkeiten verursacht; dies haben wir separat getestet und für sich allein als nicht signifikant befunden.

Die oberste Routing-Stufe ist keine Preisstufe

qwen3.8-max und kimi-k3 routen beide 153 der 184 schwierigen Fragen, jeweils 0,8315, zu Kosten von $25,14 und $40,34 pro 759-Fragen-Durchlauf. claude-fable-5 kostet $121,55 und routet 151. Sechs Modelle liegen innerhalb von 0,03 des Spitzenreiters über eine 5x-Spanne bei den Durchlaufkosten.

Die Kostenspalte gibt an, was für den Lauf berechnet wurde, und nicht die Modellökonomie. OpenRouter leitet einen Modell-Slug an den jeweils bedienenden Upstream-Anbieter weiter, und dieselben 594 Fragen auf demselben Modell haben in einem Lauf $2,09 und in einem anderen $8,33 gekostet. Lesen Sie die Spalte als Größenordnung. Eine Richtung überdauert diese Drift. Die beiden teuersten Läufe des Panels, claude-fable-5 mit $121,55 und claude-opus-4.8 mit $117,82, routen nicht besser als qwen3.8-max mit $25,14.

Ein Modell kann die agentische Schleife ausführen, ohne davon zu profitieren

Beschränkt auf Fragen, bei denen der erste Zug nur eine einzige Datenbank sondierte, beträgt die Genauigkeitslücke zwischen der ersten berührten Datenbank und der letztlich angegebenen +25,0 Punkte für claude-opus-5 und +38,0 für grok-4.5. Für gpt-5.4-mini beträgt diese Lücke 0,0. Für gpt-oss-120b sind es -3,8 und für nova-lite-v1 -14,0. Beide dieser Modelle geben eine korrekte erste Sondierung häufiger auf, als sie sich von einer falschen erholen.

Die beiden Gruppen unterscheiden sich in der Explorationsbreite. Über das Panel gepoolt, sondieren Modelle bei leichten Fragen durchschnittlich 1,12 verschiedene Datenbanken und bei den schwierigsten 1,93. kimi-k3 geht von 1,07 auf 2,27 und grok-4.5 von 1,06 auf 2,21, während gpt-oss-120b von 1,01 auf 1,10 und gpt-5.4-nano von 1,11 auf 1,20 geht.

gpt-5.4-nano benötigt 6,5 Züge pro Frage und gibt durchgehend Tool-Aufrufe aus, die Schleife läuft also. Das Ausführen der Schleife bringt ihm 2,2 Punkte.

Einige Anbieter ignorierten unsere Anforderung sequenzieller Tool-Aufrufe. Wenn ein erster Zug mehrere Datenbanken gleichzeitig berührte, schließen wir ihn aus diesem Vergleich aus, der dann bei einigen Modellen mit weniger als 184 Fragen läuft (qwen3.8-max 86, glm-5.2 101, kimi-k3 105).

Sondierung, Wechsel und die Lücke zwischen erster Sondierung und angegebener Route

Die Exploration skaliert mit der Schwierigkeitskennzeichnung. Über alle 36 Modelle und 759 Fragen gepoolt:

Von den 3.122 Datensätzen der schwierigsten Fragen, bei denen ein Modell mindestens einmal die Route wechselte, wechselten 1.717 von einer falschen Datenbank zur richtigen und 90 in die andere Richtung, ein Nettogewinn von 1.627 Datensätzen bei einem Verhältnis von nahe 19 zu 1. Weitere 983 begannen auf einer falschen Datenbank und erreichten nie die richtige, und 332 verließen die korrekte Datenbank und kehrten zu ihr zurück. Alle vier Zählungen verwenden die explizit deklarierte Route, dieselbe Definition wie bei jeder anderen Routing-Zahl hier.

Diese Asymmetrie ist der Grund, warum der Benchmark die deklarierte Route bewertet und nicht die erste Sondierung. Die frühere Version erfasste den ersten Datenbank-Funktionsaufruf des Agenten als seine Routing-Entscheidung. Bei diesem Panel unterschätzt diese Konvention 30 der 36 Modelle um 14,7 bis 38,0 Punkte.

Kosten pro Durchlauf über das 36-Modell-Panel

Die 36 Durchläufe kosteten insgesamt $874,53, von $0,47 bis $121,55. Sechs davon erzielten nach verbleibenden Anbieterfehlern weniger als 759 Fragen (gemini-3.1-pro-preview 744, gemini-3-flash-preview 755, claude-haiku-4.5 750, nova-lite-v1 750, gpt-5.6-luna 758, gpt-5.6-terra 758).

Die Anzahl der Züge reicht von 3,79 bis 7,64 über das Panel und beeinflusst die Rechnung neben dem Preis pro Token. claude-opus-5 benötigt durchschnittlich 3,92 Züge pro Frage bei $62,78, gemini-3.1-pro-preview 7,02 bei $80,01 und gpt-oss-120b 3,79 bei $0,47.

Drei der 36 Durchläufe nutzten Prompt-Caching, die anderen 33 nicht, sodass die Zeilen nicht auf derselben Basis abgerechnet werden und die drei zwischengespeicherten Zeilen niedriger liegen, als es ein nicht zwischengespeicherter Durchlauf desselben Modells wäre.

Prompt-Caching und was die Positionsverzerrungskontrolle kostet

In diesem Benchmark sind 44 % eines jeden Tool-Loop-Aufrufs ein byte-identischer Präfix, der System-Prompt mit 362 Tokens plus die 11 Tool-Definitionen mit 2.259 Tokens, also 2.621 Tokens eines Aufrufs, der im Durchschnitt etwa 6.000 Tokens umfasst. Drei Durchläufe nutzten einen expliziten Cache-Breakpoint für diesen Präfix. claude-opus-5 las 62,2 % seiner Eingabe aus dem Cache und wurde mit $62,78 berechnet, gegenüber $105,54 zum Listenpreis – ein Rabatt von 40,5 %. qwen3.8-max las 68,2 %, der höchste von uns gemessene Wert, und zwar bei Alibaba statt Anthropic.

Die Einsparung wird durch eine Designentscheidung begrenzt. Die Tool-Liste wird pro Frage permutiert, sodass sich der Präfix ab Byte 0 zwischen den Fragen unterscheidet und der Cache jeder Frage innerhalb ihrer eigenen etwa fünf Aufrufe geschrieben und gelesen wird, niemals über den gesamten Durchlauf hinweg. Das Einfrieren der Tool-Reihenfolge würde den Cache erweitern und etwa $8,95 pro 759-Fragen-Durchlauf einsparen. Wir behielten die Permutation bei und bezifferten deren Kosten.

Das Caching veränderte die Rechnung, nicht die Eingabe des Modells. Eine Negativtest-Suite erfasst die echten Request-Bodies mit ein- und ausgeschaltetem Flag und verlangt, dass sie byte-identisch sind, sobald die Cache-Markierungen entfernt wurden. Ihr lasttragender Test mutiert ein einzelnes Zeichen unter einer Markierung und verlangt, dass die Prüfung dies erkennt. Ein Kostenfehler überlebte diese Suite dennoch. Der Finalisierungsschritt sendet bewusst keine Tool-Definitionen, sodass sein Präfix jeden zwischengespeicherten Eintrag verfehlt, und das Setzen eines Breakpoints darauf schrieb etwa 3,2 Millionen Tokens an Cache, die nichts lesen konnte, grob $4 von opus-5s Rechnung. Eine feindliche Überprüfung nach Auslieferung der Änderung entdeckte dies, obwohl alle Prüfungen grün waren.

Agentic RAG und Standard-RAG

Retrieval-Augmented Generation stellt einen Abrufschritt vor ein Sprachmodell. Die Frage wird eingebettet, die nächstgelegenen Chunks kommen aus einem Index zurück, und das Modell antwortet daraus. Der Pfad ist festgelegt, und nichts in der Pipeline wählt etwas aus.

Agentic RAG übergibt die Abrufentscheidungen dem Modell. Es wählt aus, welche Quelle abgefragt wird, liest die Rückgabe und kann erneut abfragen, die Quelle wechseln oder die Abfrage verfeinern, bevor es antwortet. Der Abruf hört auf, ein einmaliger Schritt zu sein, und wird zu einer Schleife, die das Modell steuert.

Diese erste Wahl – welche Quelle die Antwort enthält – misst dieser Benchmark. Jedes Modell sieht 11 SQL-Datenbanken, die auf Absatzebene beschrieben sind, mit verborgenen Namen, und muss eine auswählen, bevor es SQL schreibt. Es kann dann eine zweite und dritte sondieren und seine Meinung ändern. Bei den schwierigsten Fragen sondiert das Panel durchschnittlich 1,93 Datenbanken, und 47,3 % der Durchläufe berühren mehr als eine.

Wie agentisches Datenbank-Routing funktioniert

Das Testgerüst gibt dem Modell eine Frage und einen Katalog mit 11 Absatzbeschreibungen, eine pro Datenbank, ohne Tabellen- oder Spaltennamen. Daneben werden 11 Tools bereitgestellt, eines pro Datenbank, jedes mit drei Aktionen: get_schema gibt die Tabellenliste zurück, get_table_schema gibt die Spalten einer Tabelle zurück und execute_query führt SQL auf dieser Datenbank aus. Die Schema-Ausgabe ist auf 4.000 Zeichen und die Abfrageergebnisse auf 50 Zeilen begrenzt.

Von da an steuert das Modell. Es wählt ein Tool, liest die Antwort innerhalb derselben Konversation und kann eine andere Datenbank sondieren, die Details einer Tabelle anfordern oder eine Abfrage auf der Datenbank ausführen, auf die es sich festgelegt hat. Es kann in jedem Zug die Datenbank wechseln, und 47,3 % der schwierigsten Fragen werden tatsächlich auf mehr als einer Datenbank sondiert.

Die Schleife endet auf eine von zwei Arten. Entweder hört das Modell auf, Tools anzufordern, oder es nutzt seinen neunten tool-fähigen Aufruf. In beiden Fällen sendet das Testgerüst dann einen Finalisierungsaufruf ohne angehängte Tools, in dem das Modell seine gewählte Datenbank und sein SQL angibt. Dieser Aufruf läuft bedingungslos für jedes Modell und jede Frage, sodass das Aufrufbudget neun Tool-Züge plus einen beträgt, maximal 10 API-Aufrufe.

Das gleiche Budget ist eine Korrektur eines früheren Designs. Jenes Design fügte den Finalisierungsschritt für Modelle hinzu, die noch kein SQL ausgegeben hatten, und gewährte damit einen zusätzlichen Aufruf basierend auf einer Ausgabegewohnheit und nicht auf Fähigkeit. Das Limit ist auch keine Quote. Das Panel benötigt durchschnittlich zwischen 3,79 und 7,64 Tool-Züge pro Frage, weil ein Modell die Sondierung frühzeitig beenden kann.

Methodik des Agentic RAG-Benchmarks

Der Benchmark misst zwei Kompetenzen getrennt. Routing entscheidet, welche Datenbank die Antwort enthält, und die SQL-Generierung entscheidet, ob die Abfrage die richtigen Zeilen liefert. Das Routing ist der Kernbeitrag und trägt die Hauptmetrik. Die SQL-Korrektheit wird anhand der Gold-Abfragen von BIRD gemessen und mit eigener Unsicherheit auf der Text-to-SQL-Benchmark-Seite berichtet.

• Datensatz: BIRD-SQL Trainings- und Entwicklungssplits, 759 Fragen eingefroren und per Hash fixiert.
• Datenbanken: 11, ausgewählt aus 80 BIRD-Kandidaten durch agglomeratives Clustern ihrer Beschreibungseinbettungen bei einem Kosinus von 0,65.
• Schwierigkeitssignal: die 20 nächsten Nachbarn jeder Frage gezählt danach, wie viele zu einer anderen Datenbank gehören.
• Schwierigkeitsbereiche: easy 222, medium 118, qq_only_hard 165, jury_only_hard 70, hard_strict 184.
• Primäre Bedingung: anonymisiert. Datenbanknamen durch db_01 bis db_11 in Tool-Namen und Schema-Ausgabe ersetzt.
• Hinweis-Bedingung: keine. Der Bereichshinweis von BIRD wird jedem Modell vorenthalten.
• Tools: 1 pro Datenbank, jedes stellt 3 Aktionen bereit (get_schema, get_table_schema, execute_query), insgesamt 11, Reihenfolge pro Frage permutiert.
• Vokabular: Ein API-Aufruf ist eine einzelne Anfrage an das Modell. Ein Tool-Zug ist ein API-Aufruf, der die Tool-Liste enthält und mit Tool-Aufrufen zurückkommen kann. Ein Tool-Aufruf ist eine einzelne Datenbankaktion innerhalb eines Zuges, maximal 11 pro Zug. Der Finalisierungsaufruf ist der letzte API-Aufruf, der ohne Tools gesendet wird.
• Zug-Budget: maximal 10 API-Aufrufe pro Frage, bis zu 9 Tool-Züge plus genau ein Finalisierungsaufruf, der stets läuft.
• Verwendete Tool-Züge: 3,79 bis 7,64 pro Frage im Durchschnitt über das Panel, da ein Modell die Sondierung frühzeitig beenden kann. Das aufgezeichnete Feld zählt Tool-Züge und schließt den Finalisierungsaufruf aus, sein Limit ist daher 9 statt 10.
• Temperatur: 0. Sequentielle Tool-Aufrufe angefordert. Fragen wurden einmal mit einem festen Seed gemischt, bevor ein Ausschnitt erfolgte.
• Routing-Metrik: endgültige Routing-Genauigkeit über die explizit deklarierte Datenbank.
• SQL-Metrik: Ausführungsübereinstimmung mit BIRDs Gold-Query, ausgewiesen als Drei-Werte-Korridor.
• Panel: 36 Modelle, je ein Einzeldurchlauf außer zwei Wiederholungen, $874,53 für die Panel-Durchläufe plus $85,37 für die Wiederholungen.

Welche Datenbanken die schwierigen Fragen tragen. Fünf der elf steuern überhaupt keine der 184 schwierigsten Fragen bei. Es handelt sich um california_schools plus die vier semantisch isolierten (financial, synthea, superhero, toxicology), die jedoch zusammen 27 der 165 nachbar-gekennzeichneten Fragen liefern.

Die Schwierigkeitstaxonomie. Zwei unabhängige Signale kennzeichnen jede Frage. Das erste bettet alle 1.922 Fragen der 11 Datenbanken ein und zählt, wie viele der 20 nächsten Nachbarn jeder Frage in einer anderen Datenbank liegen. Das zweite ist eine Jury aus drei Modellen, die gefragt wird, ob die Frage datenbankübergreifend verwirrend ist. Der schwierigste Bucket erfordert beide und nicht deren Mischung.

Keines der Signale ist für sich allein signifikant. Die Konjunktion ist es. An einem Modell gemessen betrug die Routing-Genauigkeit bei den durch beide Signale gekennzeichneten Fragen das 0.803-Fache der Genauigkeit bei den leichten Fragen derselben Datenbank, 95-%-KI [0.685, 0.943], p = 0.007. Wir vergleichen innerhalb jeder Datenbank und poolen dann über Datenbanken mit einem invers-varianzlog-Risikoverhältnis und einer Kontinuitätskorrektur von 0,5. Der Pool umfasst 5 Datenbanken statt 6, da regional_sales nur schwierige, aber keine leichten Fragen enthält und daher keinen Vergleichspartner hat. Drei Dinge machen den Kontrast explorativ: Er beruht auf einem Modell und fünf Schichten, und er ist beobachtend und nicht randomisiert.

Was das Modell sieht. Jedes Modell erhält eine Absatzbeschreibung aller 11 Datenbanken, ohne Tabellen- oder Spaltennamen, sowie die 11 Datenbank-Tools. Die Anonymisierung entfernt den Namen, nicht die Domäne. Die Beschreibungen geben weiterhin an, worum es in jeder Datenbank geht, und sobald das Modell get_schema aufruft, sieht es echte Tabellen- und Spaltennamen. Die Bedingung misst das Beschreibungsverständnis.

Bewertung der Route. Die deklarierte Datenbank ist diejenige, die das Modell unter einem expliziten selected_database-Schlüssel im Finalisierungsschritt angibt. Ein Modell, das keine explizite Deklaration liefert, erhält null Punkte für diese Frage. Aus Fließtext abgeleitete Routen bleiben von der Hauptmetrik ausgeschlossen und werden separat veröffentlicht. Eine frühere Version dieser Arbeit enthielt drei verschiedene Definitionen der Metrik, und die aus Fließtext extrahierte Variante blähte sechs Panel-Zeilen um 0,6 bis 4,9 Punkte auf.

Bewertung des SQL. Die Korrektheit wird durch Ausführung beider Abfragen und Vergleich der Ergebnismengen entschieden. Unser Fünf-Modell-Audit kennzeichnete 31,1 % der Gold-Abfragen von BIRD als fehlerhaft, daher wird diese Achse als Drei-Werte-Korridor ausgewiesen und nicht als Einzelwert. Die Bewertungsregeln, das Gold-Audit und der gesamte Korridor finden sich auf der oben verlinkten Text-to-SQL-Seite.

Wiederherstellung von Tool-Aufrufen. Fünf Modellfamilien serialisieren Tool-Aufrufe in Formaten, die der Standardparser nicht akzeptiert. Eine Wiederherstellungsschicht parst diese Formen, anstatt sie als Stille zu werten, und jede Wiederherstellung wird pro Datensatz und pro Durchlauf aufgezeichnet. Abgeschnittene Aufrufe werden nie rekonstruiert. Sechs der 36 Zeilen weisen einen Wiederherstellungsanteil ungleich null auf. Fünf davon sind fußnotengroß, 0,4 % bis 4,4 %. Die sechste ist größer. llama-4-maverick liegt bei 97,9 %, sodass nahezu jeder Tool-Aufruf in dieser Zeile über den Adapter wiederhergestellt wurde und diese Zeile das Modell plus die Wiederherstellungsschicht misst und nicht das Modell allein. Ein Modell, minimax-m2.7, erzählt, ohne überhaupt einen Tool-Aufruf auszugeben, und wir schließen es aus dem Panel aus, anstatt ihm null Punkte zu geben.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Getestete Modelle

Vier Zeilen weisen einen kleineren Nenner bei den schwierigen Fragen auf, nachdem zwei Wiederholungsdurchläufe verbleibende Anbieterfehler hinterlassen haben: 182 für gemini-3.1-pro-preview, gemini-3-flash-preview und nova-lite-v1 und 181 für claude-haiku-4.5. Diese Fragen werden aus dem Nenner entfernt, anstatt als Fehler gewertet zu werden, sodass jede Prozentangabe sich auf die tatsächlich ausgeführten Datensätze bezieht.

Routing-Genauigkeit (alle 759): Dieselbe Messung über den gesamten eingefrorenen Satz, einschließlich der leichten und mittelschweren Kontrollarme. Der leichte Arm ist konstruktionsbedingt gesättigt.

Die 95-%-Intervalle: Jedes Intervall in der obigen Tabelle ist ein Wilson-Intervall über die für das jeweilige Modell bewerteten schwierigen Fragen, was bei den meisten Zeilen 184 und bei den vier Zeilen, die Fragen durch verbleibende Anbieterfehler verloren haben, 182 oder 181 beträgt. Es deckt die Unsicherheit der Fragenstichprobe ab und sonst nichts. Es deckt nicht die Clusterung von Fragen innerhalb von Datenbanken ab und auch nicht die Variation zwischen Durchläufen, die wir separat mit 1,6 bis 2,7 Punkten gemessen haben und die für zwei nahe beieinander liegende Modelle die größere Größe darstellt.

Zufall und Baselines. Der Zufallswert beträgt 0.091 über 11 Datenbanken. Die Mehrheitsklasse liegt bei 0.196 über die 759 Fragen und bei 0.277 bei den schwierigsten. Drei nicht-agentische Retrieval-Modelle erzielen insgesamt 0.471 (TF-IDF), 0.495 (BM25) und 0.522 (nächstgelegene Datenbank per Embedding) und 0.207 bis 0.230 bei den schwierigsten. Diese drei wurden am früheren 594-Fragen-Set gemessen und wurden nicht auf den 759 erneut durchgeführt, sie sind daher historische Referenzpunkte und keine Baselines für dieses Panel. Zufall und Mehrheitsklasse sind auf dem eingefrorenen 759-Satz berechnet und direkt vergleichbar.

Einschränkungen

Beide Modelle mit Wiederholungsläufen befinden sich in der obersten Stufe, wo die Fragen am schwierigsten und die Scores am stärksten komprimiert sind. Kein Modell aus dem Mittelfeld wurde wiederholt, sodass der Rauschterm außerhalb der Spitzengruppe ungemessen ist.

Kontaminationskontrollen begrenzen den Effekt, sie beseitigen ihn nicht. Wir haben die schwierigen Fragen umformuliert, um Bedeutung und Gold zu erhalten, während der Wortlaut geändert wurde. Bei den 138 von 184 Paraphrasen, die alle drei Validierungstore passierten, sank das Routing nicht, und der Panel-Effekt war in die entgegengesetzte Richtung signifikant, 0.543 auf 0.583, McNemar p = 0.032. Jede Frage wird in beiden Armen bewertet, die Paarung ist also real: 87 Paare favorisierten die Paraphrase gegenüber 60. Fünfundsechzig von Grund auf neu verfasste Fragen, die hinsichtlich Schwierigkeit, Formulierungsstil und Datenbankmischung abgestimmt waren, lagen innerhalb von +0.012 des veröffentlichten Satzes, p = 0,74. Dieser letzte Vergleich erfolgt zwischen zwei unabhängigen Fragesätzen und nicht paarweise, es handelt sich also um einen Zwei-Anteil-Vergleich und das schwächere der beiden Designs. Die verfasste Kontrolle deckt 3 der 11 Datenbanken ab, die Paraphrase-Kontrolle 6, und beide liefen ausschließlich auf günstigen Modellen. Eine Kontrolle mit Datenbanken, die nach den Modell-Cutoffs veröffentlicht wurden, wurde nicht versucht, und 560 der 759 Fragen (73,8 %) stammen aus dem Trainingssplit von BIRD, dem Teil, der am ehesten auswendig gelernt wurde.

Das Weglassen der nicht bewerteten Datensätze verschiebt die Hauptmetrik um maximal 0,90 Punkte. Sechs Zeilen verloren Fragen durch verbleibende Anbieterfehler, und diese Fragen verlassen den Nenner, anstatt als Fehler gezählt zu werden, was einen Score aufbläht, wenn die Verluste auf schwierige Fragen fallen. Würde man jede verlorene Frage als falsch werten, verschöbe sich gemini-3.1-pro-preview von 0,8242 auf 0,8152 bei den schwierigsten Fragen (-0,90 Pkt.) und von 0,9140 auf 0,8959 über die 759 (-1,81 Pkt.), gemini-3-flash-preview -0,81 Pkt., claude-haiku-4.5 -0,79 Pkt., nova-lite-v1 -0,13 Pkt. Sieben Rangpositionen tauschen bei den schwierigsten Fragen, jede davon benachbart und jede innerhalb der 1,6- bis 2,7-Punkte-Schwankungsbreite zwischen Durchläufen. Die Konvention ist daher bei der Auflösung dieses Panels nicht tragend.

Die schwierigsten Fragen stellen eine Messung des Commerce-Clusters dar. Vier Commerce-Datenbanken tragen 171 der 184 schwierigen Fragen, und fünf Datenbanken tragen keine. Die Hauptaussage verallgemeinert sich auf das Routing unter einander verwechselbaren Datenbanken, was der Benchmark messen soll, und nicht auf domänenübergreifendes Routing im Allgemeinen. Eine Erweiterung würde bedeuten, schwierige Fragen aus einem zweiten semantischen Cluster hinzuzufügen, was der aktuelle Korpus nicht bieten kann.

Das Panel lief auf einem gemischten Testgerüst. Neunzehn Modelle wurden bewertet, nachdem die Wiederherstellungsschicht für Tool-Aufrufe hinzugefügt wurde, fünfzehn davor, und zwei überspannen die Änderung. Ein Modell in der früheren Gruppe, das einen nicht standardmäßigen Tool-Aufruf ausgab, wurde so gewertet, als hätte es geschwiegen. Eine Durchsicht der Wiederherstellungsschicht über alle 27.306 gespeicherten Datensätze ergab keinen wiederherstellbaren Aufruf in einer der früheren Zeilen, sodass die gemessenen Kosten dieser Mischung null betragen, aber eine Serialisierung, die kein Parser verarbeiten kann, wäre für diese Durchsicht ebenfalls unsichtbar.

Durchläufe sind nicht bit-reproduzierbar. OpenRouter bediente kimi-k2.6 innerhalb eines einzigen Durchlaufs von 19 verschiedenen Upstream-Anbietern und deepseek-v4-pro von 12, wobei sich das Serialisierungsverhalten zwischen ihnen unterscheidet. Drei der 36 Durchläufe fixierten einen Anbieter.

Die Anonymisierung betrifft nur den Namen. Die Beschreibungen nennen weiterhin ihre Domänen, und der erste Tool-Aufruf liefert echte Tabellen- und Spaltennamen, sodass diese Bedingung das Verständnis einer Beschreibung misst und nicht die Wiedererkennung eines Namens.

Die Schema-Ausgabe wird auf 4.000 Zeichen abgeschnitten. works_cycles ist mit 66 Tabellen die größte Datenbank, von denen 26 den Schnitt überdauern. Diese Datenbank trägt 149 der 759 Fragen. Abfrageergebnisse sind auf 50 Zeilen begrenzt.

Die Routing-Achse läuft aus dem Spielraum. Der leichte Kontrollarm ist bei den Top-Modellen mit 222 von 222 erschöpft, und der schwierigste Bucket komprimiert sechs Modelle in fünf Fragen. Dieser Benchmark kann Frontier-Modelle beim Routing nicht mehr voneinander trennen.

Weiterführende Literatur

• RAG Frameworks: LangChain vs LangGraph vs LlamaIndex
• Beste RAG-Tools, Frameworks und Bibliotheken
• Agentic Search in 2026: Benchmark von 8 Such-APIs für Agenten
• Top 5 Open-Source Agentic AI Frameworks 2026
• Text-to-SQL: Vergleich der LLM-Genauigkeit

FAQs

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Agentic RAG-Benchmark: Multidatenbank-Routing über 36 LLMs}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Abgerufen am 11. August 2026}
}

Referenzlinks

1.

BIRD-bench

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenanalyst bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten