Agentic RAG-Benchmark: Routing über 11 SQL-Datenbanken
We benchmarked 40+ LLMs on 759 questions that require choosing among 11 SQL databases. The benchmark measures whether each model identifies the right database, explores alternatives and states a final choice.
Routing-Genauigkeit ist der Prozentsatz der bewerteten Fragen, bei denen das Modell in seiner endgültigen Antwort explizit die richtige Datenbank nennt. Die Hauptkennzahl verwendet die 184 Fragen, die sowohl von unserem Ähnlichkeitstest als auch von einer Jury aus drei LLMs als schwierig markiert wurden. Fehlende explizite Deklarationen werden nicht gewertet.
Erkenntnisse zum Datenbank-Routing
qwen3.8-max erzielte 83,2 % Routing-Genauigkeit bei einem Lauf für $25,14
Qwen3.8-max beantwortete 153 von 184 schweren Routing-Fragen korrekt, bei aufgezeichneten Kosten von $25.14. claude-fable-5 beantwortete 151 bei $121.55. Alle 759 Fragen wurden in beiden Läufen abgeschlossen.
Dieser Unterschied von zwei Fragen ist kleiner als die Veränderung, die bei der Wiederholung von qwen3.8-max gemessen wurde. Aufgezeichnete Kosten hängen von der Anbieterwahl und der Cache-Nutzung ab, daher kann dieser Vergleich kein dauerhaftes Preis-Leistungs-Ranking begründen.
Endgültige Routing-Genauigkeit stieg für Grok und Opus, fiel aber für Nova
Bei claude-opus-5 stieg die Genauigkeit bei schweren Fragen zwischen der ersten Datenbankprüfung und der endgültigen Deklaration um 25.0 Prozentpunkte. grok-4.5 gewann innerhalb seines eigenen Laufs 38.0 Punkte. gpt-5.4-mini verzeichnete keinen Zuwachs, während nova-lite-v1 14.0 Punkte verlor.
Jede Änderung vergleicht Anfang und Ende eines Laufs. Fragen, die im ersten Zug mehrere Datenbanken berührten, werden ausgeschlossen, weil sie keine einzelne erste Wahl haben.
Diese Zählung verwendet die erste Datenbank in der aufgezeichneten Aufrufreihenfolge, einschließlich der ersten Züge mit mehreren Datenbanken. Die oben genannten Änderungen in Prozentpunkten verwenden eine einzelne erste Wahl.
Ein Datenbankaufruf garantiert daher keine nützliche Korrektur. Entscheidend ist, ob das Modell die zurückgegebenen Informationen nutzt, um zur richtigen endgültigen Wahl zu gelangen. Dies ist eine Beobachtung der aufgezeichneten Trajektorien ohne einen separaten Eingriff, der den Wert zusätzlicher Aufrufe isoliert.
Ergebnisse des Datenbank-Routings
Modelle erscheinen alphabetisch. Die Methodik erfasst Unterschiede in der Software, mit der sie ausgeführt wurden. Diese Bedingungen sind wichtig, wenn kleine Punktabstände interpretiert werden.
Die Intervalle schätzen die Unsicherheit der Fragenstichprobe. Die aufgezeichneten Kosten decken die erfolgreichen Datensätze in jedem Lauf ab. Sie spiegeln die Anbieter- und Caching-Bedingungen wider, die zum Zeitpunkt der Messung verwendet wurden.
Entscheidungsmodelle für das Datenbank-Routing
Wir verglichen Jev, Kev-9B, Laya English und sechs LLMs anhand von 243 überprüften Fragen aus denselben 11 Datenbanken. Jedes Modell wählte eine Datenbank aus den bereitgestellten Beschreibungen aus.
Laya lief lokal auf einem Apple M4. Kev lief auf einem dedizierten A100-Dienst, der über einen SSH-Tunnel erreichbar war. Die anderen Modelle verwendeten gehostete APIs. Die Latenz umfasst die vollständige Client-Anfrage unter den gültigen Antworten. Die Genauigkeit umfasst jede versuchte Frage.
Jev wählte bei 240 von 243 Fragen die richtige Datenbank, verglichen mit 123 bei Laya English: 117 korrekte Auswahlen mehr, ein Unterschied von 48.1 Prozentpunkten. Jev war in diesem Lauf das schnellste gehostete Modell nach medianer Latenz. Die lokale Bereitstellung von Laya hatte insgesamt die niedrigste mediane Latenz, bei deutlich geringerer Genauigkeit.
Kev-9B wählte 236 Datenbanken korrekt aus, vier weniger als Jev. Fünf seiner sieben Fehler betrafen die Kraftstoff-Debitkarten-Datenbank. Seine mediane Antwort dauerte 952 ms einschließlich Netzwerk und SSH-Tunnel. Der separat aufgezeichnete Server-Median betrug 470 ms. Diese A100-Bereitstellung verwendete FP32 und Referenz-Kernel. Ihre Geschwindigkeit hängt von dieser Serving-Konfiguration ab.
Gemini 3.8 Flash und Claude Opus 5 wählten beide für jede Frage die richtige Datenbank. Opus benötigte im Median 1.72 Mal so lange, und seine gemeldeten API-Kosten waren für diese Fragen 7.58 Mal so hoch wie die von Gemini. Die Genauigkeit war für diese beiden Modelle in diesem Set gleich.
Das Ergebnis von DeepSeek umfasst 19 Dienst- oder Ausgabefehler: 16 HTTP-429-Antworten, zwei Antworten, die das geforderte Format mit nur einem Alias verletzten, und ein erschöpftes Ausgabebudget. Es wählte die richtige Datenbank in 211 seiner 224 gültigen Antworten, also 94,2 %. Werden alle Versuche gezählt, ergibt sich der im Diagramm und in der Tabelle gezeigte Wert von 86,8 %.
Routing-Kosten: API-Preise und Hardware-Schätzungen
Jev wählte bei 98,8 % der Fragen die richtige Datenbank zu API-Kosten von $0,0337 pro 1.000 Routing-Versuchen. Qwen3.8 Flash verzeichnete 97,9 % Genauigkeit bei $0,0791, während Gemini 3.8 Flash bei $0,5337 100,0 % erreichte. Wir skalierten die Kosten anhand derselben Arbeitslast von 243 Fragen, einschließlich falscher Antworten und ohne Warm-ups. Jevs API-Kosten betrugen etwa 1/120 der Kosten von Claude Opus 5 für dieselben 243 Routing-Versuche.
Layas Hardware-Schätzung betrug $0,0141 pro 1.000 Versuche bei 50,6 % Genauigkeit. Kev erreichte 97,1 % bei geschätzten $0.1250. Beide Schätzungen gehen davon aus, dass die gemietete Maschine kontinuierlich Anfragen verarbeitet. Bei 10 % Auslastung trägt jede Anfrage zehnmal die Mietkosten, wodurch Laya auf $0,1405 und Kev auf $1,2503 pro 1.000 Versuche steigen.
Für die fünf LLMs mit vollständigen Abrechnungsdatensätzen teilten wir die gemeldeten API-Kosten durch 243 und multiplizierten mit 1.000. Jev berechnet $0,042 pro eine Million Eingabe-Tokens, mit kostenlos Ausgabe-Tokens. Seine 194.882 aufgezeichneten Eingabe-Tokens kosteten über 243 Versuche $0,008185, also $0,0337 pro 1.000.1
Hardware-Kosten pro 1.000 Versuchen entsprechen dem stündlichen Mietpreis × mittlere Verarbeitungssekunden × 1.000 ÷ (3.600 × Auslastung). Laya benötigte durchschnittlich 0.2006 Sekunden pro Anfrage auf einem Apple M4. Kev benötigte durchschnittlich 0.4734 Sekunden auf dem A100-Server, ohne Netzwerk- und SSH-Verzögerung. Wir wendeten diese Zeiten auf passende Hardware bei den angegebenen Anbietern an. Leistung und Abrechnungssummen bei diesen Anbietern bleiben ungemessen.
Für Kev verwendeten wir $0,9508/Stunde für eine A100 SXM mit 80 GB bei Vast.ai, das günstigste passende On-Demand-Angebot in unseren Daten des GPU-Mietpreisindex.
Für Laya verwendeten wir Scaleways M4-S mit 16 GB Arbeitsspeicher zu €0.22/Stunde. Die Umrechnung nutzt den EZB-Kurs vom 22 September von $1,1463 pro Euro. Scaleway verlangt eine Mindestmiete von 24 Stunden, wodurch die Mindestmiete €5.28 oder etwa $6,05 beträgt, selbst für einen kurzen Auftrag.234
Layas Modellseite führte keinen Hugging Face Inference Provider auf. Unsere Schätzung umfasst das Mieten einer Maschine und das Ausführen des Modells darauf. Einrichtungszeit, Speicher, Netzwerk-Extras, Steuern und Betriebsarbeit sind in beiden Hardware-Schätzungen ausgeschlossen.5
Wie Entscheidungsmodelle eine Datenbank auswählen
Für Jev und Laya liefert die Anwendung den Kontext, eine Frage und benannte Optionen mit Beschreibungen. Ihre Choice-Schnittstellen geben eine ausgewählte Option, Wahrscheinlichkeiten über die Optionen und einen Konfidenzwert zurück. Der Anwendungscode entscheidet, was mit diesem Ergebnis geschieht. Beim Routing sind die Optionen Datenbank-Aliasse wie db_03 und db_07.65
Dieses Format erleichtert die Verwendung der Ausgabe im Code. Ein Modell kann dennoch die falsche Datenbank wählen. Ein hoher Konfidenzwert muss außerdem anhand der beobachteten Korrektheit validiert werden, bevor eine Anwendung ihn nutzt, um eine Überprüfung zu überspringen oder ein Fallback auszulösen.
Layas englischer Checkpoint verwendet einen bidirektionalen ModernBERT-Encoder mit einem Entscheidungskopf, der die bereitgestellten Optionen bewertet. Die Optionsbeschreibungen treffen mit der Anfrage ein, sodass die Anwendung ihre verfügbaren Auswahlmöglichkeiten ändern kann. Jev stellt eine gehostete Choice-API bereit. Seine Dokumentation ordnet Workflow-Steuerung und Aktionen dem Anwendungscode zu. Die gemeinsame Schnittstelle belegt nicht, dass die beiden Modelle dieselbe interne Architektur haben.57
Kev-9B verwendet einen LoRA-Adapter und einen Pointer-Head auf Basis von Qwen3.5-9B-Base. Er bewertet die bereitgestellten Auswahlmöglichkeiten und gibt ihre Wahrscheinlichkeiten zurück, ohne Antworttext zu generieren. Wir verwendeten seinen kompatiblen Choice-Endpunkt mit derselben Frage und denselben Datenbankbeschreibungen.8
Bedingungen, die Datenbankauswahl beeinflussen
Ähnliche Datenbanken reduzierten die Routing-Genauigkeit um etwa 20 Punkte
Wir testeten die Methode zur Datenbankauswahl in einem separaten Experiment mit 128 Fragen. Jede Frage behielt ihre richtige Datenbank, während die anderen 10 Kandidaten entweder aus unserer ausgewählten Gruppe oder aus einer Zufallsziehung stammten.
In der schweren Teilmenge erreichte claude-opus-4.8 mit ähnlichen Kandidaten 71,3 % und mit zufälligen Kandidaten 92,0 %. gemini-3.5-flash erreichte 77,0 % und 96,6 %. Beide Unterschiede wiesen in gepaarten Tests p-Werte unter 0.001 auf.
Dieses Experiment verwendete Beschreibungen und eine Modellantwort pro Frage, ohne die agentische Tool-Schleife. Es stützt die engere Erkenntnis, dass die Auswahl ähnlicher Kandidaten die Datenbankwahl erschwert. Die gemessene Lücke sollte nicht als Effekt der agentischen Exploration dargestellt werden.
Allein Namen erzielten in einem Pilotversuch eine Genauigkeit von 68,8 % und 71,1 %
In einem weiteren Pilotversuch mit 128 Fragen wählte claude-opus-4.8 allein anhand der Namen in 68,8 % der Fälle die richtige Datenbank. Sein Ergebnis mit Namen und Beschreibungen betrug 67,2 %. gemini-3.5-flash erreichte 71,1 % anhand der Namen und 75,0 % anhand des vollständigen Katalogs.
Namen wie california_schools und toxicology verraten das Thema direkt. Für den Haupt-Benchmark ersetzen wir Datenbanknamen durch Aliase von db_01 bis db_11. Die Beschreibungen erläutern weiterhin die Domäne jeder Datenbank, und Tool-Antworten legen ihre Tabellen- und Spaltennamen offen.
Zuverlässigkeit von Routing- und Kostenvergleichen
Wiederholungsläufe veränderten die Routing-Genauigkeit um 1.6 bis 2.7 Punkte
claude-opus-5 wählte im ersten Lauf bei 156 von 184 schweren Fragen die richtige Datenbank und bei der Wiederholung bei 151. Seine Genauigkeit fiel von 84,8 % auf 82,1 %. qwen3.8-max ging von 153 korrekten Antworten auf 150 zurück, ein Rückgang von 83,2 % auf 81,5 %.
Beide Wiederholungen verwendeten dieselben Fragen, Anonymisierung, Temperatur und Anbietereinstellungen wie ihre ursprünglichen Läufe. qwen3.8-max änderte seine Antwort bei 13 schweren Fragen, obwohl sich seine Gesamtzahl nur um drei veränderte. Verbesserungen bei einigen Fragen glichen Fehler bei anderen aus.
Diese Wiederholungen zeigen, dass kleine Punktabstände bei einem weiteren Lauf verschwinden können. Eine Wiederholung pro Modell kann keine Verteilung der Ergebnisse begründen, und die anderen 35 Modelle haben keine Wiederholungsmessung.
Aufgezeichnete Kosten hängen von Anbieter- und Caching-Einstellungen ab
Prompt-Caching verwendet bereits verarbeitete Eingaben wieder, um die in Rechnung gestellten Eingabekosten zu senken. Der Lauf von claude-opus-5 kostete $62,78, verglichen mit geschätzten $105,54 bei ungecachten Listenpreisen für dieselbe aufgezeichnete Nutzung. Diese Schätzung impliziert eine Einsparung von 40,5 %. Es handelt sich um einen buchhalterischen Vergleich ohne separaten ungecachten Genauigkeitslauf.
Agentic RAG und Datenbankauswahl
Agentic RAG gibt einem Modell die Kontrolle über Abrufentscheidungen. Es kann eine Quelle auswählen, die Antwort prüfen und eine weitere Anfrage stellen. Eine einfache RAG-Pipeline ruft Kontext vor der Generierung einer Antwort in einer vorgegebenen Reihenfolge ab.
Dieser Benchmark testet die Quellenauswahl mithilfe von SQL-Datenbank-Tools. Er enthält keinen Dokumentindex, keine abgerufenen Passagen und keinen Antwort-Grounding-Score. Die Ergebnisse beschreiben daher einen Teil eines agentischen Abrufsystems. Die Dokumentensuche wird separat in unserem Agentic-Search-Benchmark behandelt.
Ein Modell beginnt mit kurzen Datenbankbeschreibungen. Es kann Tabellenlisten anfordern, Spalten prüfen, SQL ausführen und die Datenbank wechseln. Seine endgültige Antwort enthält eine Datenbankauswahl und eine Abfrage. Unser Text-to-SQL-Benchmark berichtet über SQL-Genauigkeit und zwei ergänzende Bewertungswerte.
Als bevorzugte Quelle hinzufügenMethodik des Agentic-RAG-Benchmarks
Der Fragensatz ist eine eingefrorene Teilmenge von BIRD-SQL, die natürlichsprachliche Fragen mit SQL-Referenzabfragen paart.9
Zwei Signale bestimmen die Schwierigkeit. Der Ähnlichkeitstest zählt, wie viele der 20 nächsten Nachbarn einer Frage zu anderen Datenbanken gehören. Drei LLMs bewerten, ob die Frage über Datenbanken hinweg verwechselbar ist. Die Zugehörigkeit zur schwierigsten Gruppe erfordert mindestens fünf datenbankübergreifende Nachbarn und ein Verwirrungslabel der Jury.
Das Routing verwendet die Datenbank, die im expliziten selected_database Feld genannt wird. Eine aus Fließtext abgeleitete Route wird von der Hauptkennzahl ausgeschlossen. Die SQL-Korrektheit wird separat bewertet und bestimmt nicht die Routing-Gutschrift.
Der Harness ist die Software, die Tools präsentiert und Modellantworten aufzeichnet. Das Hauptpanel enthält 36 OpenRouter-Läufe und einen Codex-CLI-Lauf. Unter den API-Läufen verwendeten 19 v3, 15 eine frühere Version, und zwei kombinierten Datensätze aus beiden Versionen. In v3 analysiert eine Recovery-Schicht unterstützte alternative Tool-Call-Formate. Für llama-4-maverick betrug der aufgezeichnete Anteil nicht-nativer Formate 97,9 %, daher hängt dieses Ergebnis stark vom Adapter ab. minimax-m2.7 wurde ausgeschlossen, weil es die für die Aufgabe erforderlichen Datenbank-Tool-Aufrufe nicht ausgab.
GPT-6 Astra lief innerhalb der Codex CLI, deren aufgezeichneter Harness-Identifier codex_cli_transcript_v1 ist. Da sich das Setup unterscheidet, können Punktunterschiede nicht allein dem Modell zugeschrieben werden. GPT-6 Astra schloss alle 759 Fragen ab. Es wählte bei 155 von 184 schweren Fragen die richtige Datenbank und verzeichnete 95,3 % Routing-Genauigkeit über das gesamte Set. Sein Lauf wies keine Dollar-Kosten aus.
Routing-Benchmark für Entscheidungsmodelle
Das separate Routing-Experiment verwendete 243 unveränderte Fragen, die aus 394 Kandidaten ausgewählt wurden, nachdem 17 Entwicklungsfragen reserviert worden waren. Das Abfrageset enthielt 204 ursprünglich einfache und 39 ursprünglich schwere Fragen. Diese Schwierigkeitslabels wurden für diese Aufgabe nicht erneut validiert, und die Auswahl war keine blinde Hold-out-Bewertung.
Vier Datenbankbeschreibungen wurden vor der Erfassung der gemessenen Vorhersagen anhand von Quellschemata und Fragetext korrigiert. Die anderen sieben behielten ihre kompakten Beschreibungen. Jedes Modell erhielt dieselbe Frage, 11 Aliase und Beschreibungen sowie dieselbe Optionsreihenfolge für diese Frage. Referenz-SQL, Quelllabels und ergänzende Evidenz wurden vorenthalten. Jev und Laya verwendeten ihre native Choice-Schnittstelle. Die LLMs wurden angewiesen, einen Alias zurückzugeben. Die Modelle hatten keine Datenbank-Tools.
Wir führten Jev 1.13.0 über seine gehostete API und den gepinnten Laya-English-Checkpoint lokal mit Apple M4 MPS, 16 GiB Arbeitsspeicher und vier Torch-Threads aus. Layas Limit von 404 Token für den Kontextkopf und von 48 Token für Optionen verursachte keine Eingabetrunkierung. Sechs LLMs liefen über OpenRouter mit festen Anbietern und Reasoning-Einstellungen. Das angeforderte Reasoning war niedrig für Gemini 3.8 Flash, minimal für Gemini 3.5 Flash Lite und hoch für Opus. Es war deaktiviert für DeepSeek, Qwen und Haiku. Jedes Modell hatte einen ausgeschlossenen Warm-up, eine laufende Anfrage und keine Wiederholungsversuche. Die Reihenfolge der Modelleinreichungen wechselte zwischen den Fragen.
Kev-9B wurde am 22 September in einem separaten Lauf hinzugefügt, wobei die ursprünglichen acht Ergebnisse erhalten blieben. Seine 243 Anfrage-Payloads stimmten exakt mit den ursprünglichen Jev-Eingaben überein, einschließlich der Optionsreihenfolge. Wir pinnten die Checkpoint-Revision 2629c06a und verwendeten eine A100 SXM mit 80 GB, FP32, SDPA-Attention und unmerged LoRA. Datumsvorverarbeitung und Prefix-Caching waren deaktiviert. Nachdem wir die API anhand der 17 reservierten Entwicklungsfragen geprüft hatten, führten wir einen ausgeschlossenen Warm-up und 243 serielle Anfragen ohne Wiederholungsversuche durch. Der Dienst war für unsere Nutzung reserviert. Jede Antwort bestätigte, dass die vollständige Eingabe erhalten blieb. Die Server-Timings umfassen Tokenisierung und synchronisierte Inference. Das Diagramm verwendet Client-Timings einschließlich SSH- und Netzwerk-Overhead.
Die Genauigkeit teilt korrekte, gültige Auswahlen durch alle 243 geplanten Fragen, einschließlich Dienst- und Ausgabefehlern. Die mediane Latenz misst die vollständige nicht-streamende Client-Anfrage unter den gültigen Antworten, ohne Warm-up. Die gemeldeten LLM-API-Kosten decken die gemessenen Anfragen ab. Laya-Hardware- und Kev-Mietkosten wurden nicht gemessen, und Jevs Listenpreis-Schätzung ist eine andere Abrechnungsgrundlage. Der Vergleich beschreibt dieses kuratierte Set und diese Bereitstellungsbedingungen. Öffentliche Quelldaten, Beschreibungsrevisionen, Urteile der Prüfer, unterschiedliche Messdaten und das Fehlen von Wiederholungen schränken die Verallgemeinerung ein.
Einschränkungen
Die schwere Teilmenge konzentriert sich auf Handel. Vier Datenbanken tragen 171 ihrer 184 Fragen bei, also 92,9 %. Fünf der 11 Datenbanken tragen nichts bei. Dies stützt Aussagen über die Auswahl zwischen ähnlichen Datenbanken innerhalb einer Domäne, mit begrenzter Evidenz für andere Domänenkombinationen.
Sieben Läufe enthalten nach Anbieterfehlern weniger als 759 bewertete Datensätze. Fünf haben außerdem weniger als 184 Datensätze zu schweren Fragen. Ihre Tabellen-Nenner zeigen die abgeschlossenen Fragen. Fehlende Datensätze werden ausgeschlossen, was ein Modell begünstigen kann, wenn die ausgelassenen Fragen schwieriger waren.
Wilson-Intervalle decken die Stichprobenunsicherheit unter einem Modell auf Fragenebene ab. Sie lassen Variationen über Wiederholungsläufe, Abhängigkeiten zwischen Fragen derselben Datenbank und durch den Harness eingeführte Unsicherheit außen vor. Anbieterwechsel und Tool-Call-Recovery schränken Vergleiche zwischen Läufen ebenfalls ein.
Öffentliche Benchmark-Daten könnten im Modelltraining enthalten gewesen sein. Kontrollen mit 138 validierten Paraphrasen und 65 neu verfassten Fragen fanden bei den getesteten kostengünstigeren Modellen keinen Genauigkeitsrückgang. Ihre Abdeckung war auf sechs beziehungsweise drei Datenbanken begrenzt. Sie lösen das Problem der Kontamination nicht für das gesamte Panel, und keine Kontrolle verwendete Datenbanken, die nach den Trainingsstichtagen der Modelle veröffentlicht wurden.
Schema-Trunkierung kann nützliche Tabellen verbergen. In works_cycles lässt das Limit von 4.000 Zeichen in der anfänglichen Schema-Auflistung 26 von 66 Tabellen sichtbar. Das Modell kann weitere Details anfordern, aber die anfängliche Ansicht ist unvollständig.
Fazit
qwen3.8-max verzeichnete eine Routing-Genauigkeit nahe an der von Fable, zu niedrigeren gemessenen Laufkosten. Während der Exploration verbesserten Opus und Grok ihre ersten Datenbankwahlen, während Novas endgültige Genauigkeit sank.
Ähnliche Datenbankkandidaten machten die Auswahl in einem separaten Zwei-Modell-Experiment um etwa 20 Punkte schwieriger. Wiederholungsläufe veränderten die Ergebnisse ebenfalls, was die Aussagekraft kleiner Unterschiede zwischen Modellen einschränkt. Diese Ergebnisse betreffen die Datenbankwahl unter den getesteten Bedingungen, nicht die Genauigkeit eines vollständigen Dokumentenabrufsystems.
Weiterführende Lektüre
- Text-to-SQL: Vergleich der LLM-Genauigkeit
- RAG-Frameworks: LangChain vs. LangGraph vs. LlamaIndex
- Beste RAG-Tools, Frameworks und Bibliotheken
- Agentic Search 2026: Benchmark von 8 Such-APIs für Agents
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: Routing über 11 SQL-Datenbanken}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/agentic-rag}},
note = {AIMultiple. Abgerufen am 25. September 2026}
}Ergebnisse und Zeitstempel von 365 Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 6 CSV-Dateien und eine README enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
16 AktualisierungenDer Abschnitt „Was macht eine Frage in diesem Benchmark schwierig?“ wurde mit neuem Inhalt aktualisiert.
Die Methodik wurde aktualisiert, um zu verdeutlichen, wie die schwierigsten Fragen auf die Datenbanken verteilt sind.
Der Abschnitt zur Agentic RAG-Benchmark-Methodik wurde durch einen neuen ersetzt, der 36 LLMs und 11 Datenbanken abdeckt.
Neue Modelle zum Benchmark hinzugefügt: Claude Fable 5, Claude Opus 4.8, Gemini 3.5 Flash, Grok 4.3, Claude Opus 4.7.
Der Methodik-Abschnitt wurde mit neuen Details zur Datenbankumgebung, Agentenarchitektur und dem Evaluierungsprozess aktualisiert.
Ein Abschnitt über Langkontextmodelle im Vergleich zu Agentic RAG wurde hinzugefügt.
Zusätzliche Agentenmetriken aus der Methodik entfernt.
Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.