Benchmark RAG Agentic: Routage Multi-Bases de Données sur 36 LLMs

Nous avons benchmarké 36 grands modèles de langage sur le routage inter-bases de données. Chaque modèle reçoit une question en langage naturel et 11 bases de données SQL décrites au niveau paragraphe, puis doit décider quelle base détient la réponse avant d'écrire le moindre SQL. Les 11 bases de données ont été tirées de 80 candidats BIRD-SQL en regroupant les embeddings de leurs descriptions, de sorte que les candidats sont sémantiquement proches les uns des autres, et leurs noms réels sont masqués derrière les étiquettes db_01 à db_11.

Chaque modèle a vu le même ensemble figé de 759 questions à température 0, l'indice de domaine de BIRD étant retenu.¹ Chaque base de données est exposée comme un outil avec trois actions : listage du schéma, détail de table et exécution de requête, sous un plafond de 10 appels API par question. La liste d'outils est permutée pour chaque question, de sorte que la position du candidat ne puisse pas être interprétée comme une compétence de routage.

Précision de routage sur les questions les plus difficiles. La part des 184 questions les plus difficiles où la base de données déclarée par le modèle correspond à la base de référence. Une question est comptée comme faisant partie des 184 lorsque deux signaux indépendants concordent. Au moins 5 de ses 20 plus proches voisins dans l'espace d'embedding doivent appartenir à d'autres bases, et un jury de trois modèles doit l'étiqueter comme déroutante. C'est la métrique de routage principale.

Les 184 questions proviennent de 6 des 11 bases de données, selon les parts de 51 (regional_sales), 50 (retail_world), 43 (superstore), 27 (works_cycles), 8 (debit_card_specializing) et 5 (college_completion). Les quatre bases de données de commerce portent 171 des 184, soit 93 %. Les cinq autres bases ne contribuent à rien, car elles sont sémantiquement assez isolées pour qu'aucune de leurs questions ne franchisse les deux signaux. Le nombre mesure donc le routage parmi des bases conçues pour être difficiles à distinguer, et il est dominé par un seul cluster de commerce plutôt que réparti sur onze domaines.

Route déclarée. La base de données que le modèle indique dans sa réponse finale sous une clé explicite selected_database. Une exécution qui ne nomme aucune base obtient zéro au lieu d'hériter de son dernier appel d'outil. Les routes récupérées à partir du texte sont exclues et rapportées séparément.

Résultats du benchmark de RAG Agentic

Réexécuter le leader du panel le fait tomber en sixième position

claude-opus-5 a routé 0.848 des questions les plus difficiles correctement, 156 sur 184. Nous l'avons exécuté une seconde fois dans des conditions identiques, même ensemble figé, même anonymisation, température 0, et il a enregistré 0.8207, 151 sur 184. Ce deuxième score est le score publié de claude-fable-5, qui se classe sixième. Les rangs 1 à 6 s'étendent de 156 sur 184 réponses correctes à 151 sur 184, soit une distance de cinq questions, ce qui est la distance que le leader lui-même a parcourue entre deux exécutions.

Un deuxième modèle a reproduit le schéma. qwen3.8-max est passé de 0.8315 (153/184) à 0.8152 (150/184). Les catégories facile et moyenne ont bougé de 0.0000 pour les deux modèles, et le reste du mouvement se situe dans les trois catégories difficiles, qwen3.8-max passant également de 153 à 152 sur les questions signalées par le comptage de voisins.

qwen3.8-max a le plus petit écart agrégé, 1.6 points contre 2.7, et le plus grand désaccord avec lui-même, routant différemment sur 13 des 184 questions difficiles, contre 8 différences pour opus-5. Un modèle peut reproduire son propre score tout en étant en désaccord avec lui-même sur une question difficile sur quatorze.

Deux limites accompagnent cela. Une répétition donne une différence absolue, pas un écart-type, donc 1.6 à 2.7 points est un plancher du bruit plutôt qu'une description de celui-ci. Et 34 des 36 lignes du panel n'ont aucune exécution répétée. Lisez ces scores par paliers, pas par rangs.

Les 11 noms de base de données seuls routent à 4 points près du catalogue complet

En ne voyant que les vrais noms de base de données et aucune description, claude-opus-4.8 route à 0.688 et gemini-3.5-flash à 0.711. En voyant le catalogue complet, les vrais noms plus les 11 descriptions paragraphe, ces deux mêmes modèles obtiennent 0.672 et 0.750, donc pour claude-opus-4.8 les noms seuls obtiennent un score supérieur à celui du catalogue complet.

Remplacer les noms par db_01 à db_11 coûte à opus-4.8 7.0 points et à gemini 4.7. Une exécution sous vrais noms mesure la reconnaissance des noms en même temps que la compréhension, c'est pourquoi tous les chiffres publiés ici proviennent de la condition anonymisée.

Une troisième condition sépare les deux canaux. Garder les vrais noms et permuter les descriptions entre les bases de données fait chuter le routage à 0.148 et 0.055, mesuré sur les deux mêmes modèles sur un pilote de 128 questions.

Les bases de données choisies pour être déroutantes sont environ 20 points plus difficiles que des aléatoires

Nous avons échangé les 10 bases de données distractrices contre 10 tirées au hasard parmi les autres 69 de BIRD, sur les mêmes 128 questions, même base de référence, les deux bras anonymisés. Le routage hard_strict passe de 0.713 à 0.920 pour claude-opus-4.8 et de 0.770 à 0.966 pour gemini-3.5-flash. Les deux bras répondent aux mêmes questions, donc le test est un McNemar avec correction de continuité sur les paires discordantes, donnant p = 8.6e-04 et p = 2.4e-04. Onze candidats choisis aléatoirement placent les deux modèles près du plafond.

Sur le panier facile, le même contraste McNemar n'est pas significatif, p = 0.48 et p = 1.00. Les distracteurs sélectionnés par cluster étaient censés interférer avec les questions que le comptage de voisins signale comme déroutantes et laisser le reste routable quel que soit le panel, et c'est le schéma que montrent les deux bras.

Cette ablation est en mode description seule et en une seule tentative plutôt qu'agentique, avec un tirage aléatoire du panel par question. Elle autorise l'affirmation que la sélection par découverte de cluster produit un routage mesurablement plus difficile qu'une sélection aléatoire. Elle n'autorise pas l'affirmation que le comptage de voisins lui-même cause la difficulté, ce que nous avons testé séparément et trouvé non significatif en soi.

Le premier niveau de routage n'est pas un niveau de prix

qwen3.8-max et kimi-k3 routent tous deux 153 des 184 questions difficiles, 0.8315 chacun, à $25.14 et $40.34 par exécution de 759 questions. claude-fable-5 coûte $121.55 et route 151. Six modèles se situent à moins de 0.03 du leader sur une gamme de coût d'exécution multiplié par 5x.

La colonne coût enregistre ce qui a été facturé pour l'exécution, pas l'économie du modèle. OpenRouter achemine un slug de modèle vers le fournisseur amont qui le sert, et les 594 questions identiques sur le même modèle ont coûté $2.09 dans une exécution et $8.33 dans une autre. Lisez la colonne comme un ordre de grandeur. Une direction survit à cette dérive. Les deux exécutions les plus chères du panel, claude-fable-5 à $121.55 et claude-opus-4.8 à $117.82, ne routent pas plus haut que qwen3.8-max à $25.14.

Un modèle peut exécuter la boucle agentique sans en bénéficier

Restreint aux questions dont le premier tour a sondé une seule base de données, l'écart de précision entre la première base touchée par un modèle et celle qu'il déclare finalement est de +25.0 points pour claude-opus-5 et +38.0 pour grok-4.5. Pour gpt-5.4-mini, cet écart est de 0.0. Pour gpt-oss-120b, il est de -3.8 et pour nova-lite-v1, il est de -14.0. Ces deux modèles abandonnent un premier sondage correct plus souvent qu'ils ne se remettent d'un mauvais.

Les deux groupes diffèrent dans la largeur d'exploration. Regroupés sur le panel, les modèles sondent 1.12 bases de données distinctes sur les questions faciles et 1.93 sur les plus difficiles. kimi-k3 passe de 1.07 à 2.27 et grok-4.5 de 1.06 à 2.21, tandis que gpt-oss-120b passe de 1.01 à 1.10 et gpt-5.4-nano de 1.11 à 1.20.

gpt-5.4-nano dépense 6.5 tours par question et émet des appels d'outil tout au long, donc la boucle tourne effectivement. L'exécution de la boucle lui rapporte 2.2 points.

Certains fournisseurs ont ignoré notre demande d'appels d'outils séquentiels. Quand un premier tour touchait plusieurs bases de données à la fois, nous le retirons de cette comparaison, qui porte alors sur moins de 184 questions pour certains modèles (qwen3.8-max 86, glm-5.2 101, kimi-k3 105).

Sondage, changement et l'écart entre le premier sondage et la route déclarée

L'exploration s'étend avec l'étiquette de difficulté. Regroupé sur l'ensemble des 36 modèles et des 759 questions :

Sur les 3 122 enregistrements de questions les plus difficiles où un modèle a changé de route au moins une fois, 1 717 sont passés d'une mauvaise base de données à la bonne et 90 ont fait le chemin inverse, un gain net de 1 627 enregistrements dans un rapport proche de 19 contre 1. 983 autres ont commencé sur une mauvaise base et n'ont jamais atteint la bonne, et 332 ont quitté la bonne base puis y sont revenus. Ces quatre comptes utilisent la route déclarée explicitement, la même définition que tous les autres chiffres de routage ici.

Cette asymétrie est la raison pour laquelle le benchmark note la route déclarée plutôt que le premier sondage. La version antérieure enregistrait le premier appel de fonction de base de données de l'agent comme sa décision de routage. Sur ce panel, cette convention sous-estime 30 des 36 modèles de 14.7 à 38.0 points.

Coût par exécution sur le panel 36 modèles

Les 36 exécutions ont coûté $874.53 au total, allant de $0.47 à $121.55. Six d'entre elles ont obtenu moins de 759 questions après des erreurs résiduelles du fournisseur (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).

Le nombre de tours varie de 3.79 à 7.64 sur le panel et alimente la facture en plus du prix par token. claude-opus-5 réalise en moyenne 3.92 tours par question à $62.78, gemini-3.1-pro-preview 7.02 à $80.01, et gpt-oss-120b 3.79 à $0.47.

Trois des 36 exécutions ont utilisé la mise en cache du prompt et les 33 autres non, donc les lignes ne sont pas facturées sur la même base et les trois lignes mises en cache se situent plus bas qu'une exécution non mise en cache du même modèle serait.

Mise en cache du prompt, et ce que coûte le contrôle du biais de position

Dans ce benchmark, 44 % de chaque appel de boucle d'outil est un préfixe identique en octets, le prompt système de 362 tokens plus les 11 définitions d'outils à 2 259, soit 2 621 tokens d'un appel qui fait en moyenne environ 6 000. Trois exécutions portaient un point d'arrêt de cache explicite sur ce préfixe. claude-opus-5 a lu 62.2 % de son entrée depuis le cache et a été facturé $62.78 contre $105.54 au prix catalogue, soit 40.5 % de réduction. qwen3.8-max a lu 68.2 %, le plus haut mesuré, sur Alibaba plutôt que Anthropic.

L'économie est limitée par une décision de conception. La liste d'outils est permutée par question, donc le préfixe diffère de l'octet 0 entre les questions et le cache de chaque question est écrit et lu dans ses propres cinq appels environ, jamais à travers l'exécution. Figer l'ordre des outils élargirait le cache et économiserait environ $8.95 par exécution de 759 questions. Nous avons conservé la permutation et l'avons chiffrée.

La mise en cache a modifié la facture et non l'entrée du modèle. Une suite de tests négatifs capture les corps de requête réels avec le drapeau activé et désactivé et exige qu'ils soient identiques en octets une fois les marqueurs de cache retirés, et son test déterminant mute un seul caractère sous un marqueur et exige que la vérification le détecte. Un défaut de coût a néanmoins survécu à cette suite. Le tour de finalisation n'envoie délibérément aucune définition d'outil, donc son préfixe manque chaque entrée en cache, et laisser un point d'arrêt dessus a écrit environ 3.2M de tokens de cache que rien ne pouvait lire, soit environ $4 de la facture d'opus-5. Une revue contradictoire après le déploiement du changement l'a trouvé, tous les garde-fous étant verts.

RAG Agentic et RAG standard

La génération augmentée de récupération place une étape de récupération devant un modèle de langage. La question est encodée, les fragments les plus proches reviennent d'un index, et le modèle répond à partir d'eux. Le chemin est fixe, et rien dans le pipeline ne choisit quoi que ce soit.

Le RAG Agentic confie les décisions de récupération au modèle. Il choisit la source à interroger, lit ce qui revient, et peut interroger de nouveau, changer de source, ou affiner la requête avant de répondre. La récupération cesse d'être une étape exécutée une fois et devient une boucle que le modèle pilote.

Ce premier choix, quelle source détient la réponse, est ce que mesure ce benchmark. Chaque modèle voit 11 bases de données SQL décrites au niveau paragraphe, avec leurs noms cachés, et doit en choisir une avant d'écrire le moindre SQL. Il peut ensuite en sonder une deuxième, une troisième et changer d'avis. Sur les questions les plus difficiles, le panel sonde 1.93 bases de données en moyenne, et 47.3 % des exécutions en touchent plus d'une.

Comment fonctionne le routage agentique de bases de données

Le harnais donne au modèle une question et un catalogue de 11 descriptions paragraphes, une par base de données, sans noms de tables ou de colonnes. En plus du catalogue, il attache 11 outils, un par base, chacun exposant trois actions : get_schema renvoie la liste des tables, get_table_schema renvoie les colonnes d'une table, et execute_query exécute du SQL sur cette base. La sortie du schéma est limitée à 4 000 caractères et les résultats de requête à 50 lignes.

À partir de là, le modèle pilote. Il choisit un outil, lit la réponse dans la même conversation, et peut sonder une base différente, demander le détail d'une table, ou exécuter une requête sur la base sur laquelle il s'est arrêté. Il peut changer de base à chaque tour, et 47.3 % des questions les plus difficiles sont effectivement sondées sur plus d'une.

La boucle se termine de deux manières. Soit le modèle cesse de demander des outils, soit il utilise son neuvième appel autorisé d'outil. Dans les deux cas, le harnais envoie alors un appel de finalisation sans outil attaché, dans lequel le modèle déclare sa base de données choisie et son SQL. Cet appel s'exécute inconditionnellement, pour chaque modèle et chaque question, donc le budget d'appels est de neuf tours d'outil plus un, au maximum 10 appels API.

Le budget égal est une correction d'une conception antérieure. Cette conception ajoutait le tour de finalisation pour les modèles qui n'avaient pas encore émis de SQL, ce qui accordait un appel supplémentaire à une habitude de sortie plutôt qu'à une compétence. Le plafond n'est pas non plus un quota. Le panel fait en moyenne entre 3.79 et 7.64 tours d'outil par question, car un modèle peut arrêter de sonder tôt.

Méthodologie du benchmark RAG Agentic

Le benchmark mesure deux compétences séparément. Le routage décide quelle base détient la réponse, et la génération SQL décide si la requête renvoie les bonnes lignes. Le routage est la contribution et porte le titre principal. La correction SQL est mesurée par rapport aux requêtes de référence BIRD et est rapportée avec sa propre incertitude sur la page de benchmark text-to-SQL.

• Jeu de données : parties train et dev de BIRD-SQL, 759 questions figées et épinglées par hachage.
• Bases de données : 11, sélectionnées parmi 80 candidats BIRD par regroupement agglomératif de leurs embeddings de description à une similarité cosinus de 0.65.
• Signal de difficulté : pour chaque question, ses 20 plus proches voisins comptés par combien appartiennent à une base de données différente.
• Paniers de difficulté : facile 222, moyen 118, qq_only_hard 165, jury_only_hard 70, hard_strict 184.
• Condition principale : anonymisée. Noms de base de données remplacés par db_01 à db_11 dans les noms d'outils et dans la sortie du schéma.
• Condition d'indice : aucun. L'indice de domaine BIRD est retenu pour chaque modèle.
• Outils : 1 par base de données, chacun exposant 3 actions (get_schema, get_table_schema, execute_query), 11 au total, ordre permuté par question.
• Vocabulaire : un appel API est une requête au modèle. Un tour d'outil est un appel API qui porte la liste d'outils et peut revenir avec des appels d'outils. Un appel d'outil est une action de base de données à l'intérieur d'un tour, au maximum 11 par tour. L'appel de finalisation est le dernier appel API, envoyé sans outils.
• Budget de tours : au maximum 10 appels API par question, jusqu'à 9 tours d'outil plus exactement un appel de finalisation qui s'exécute toujours.
• Tours d'outil utilisés : 3.79 à 7.64 par question en moyenne sur le panel, car un modèle peut arrêter de sonder tôt. Le champ enregistré compte les tours d'outil et exclut l'appel de finalisation, donc son plafond est 9 plutôt que 10.
• Température : 0. Appels d'outils séquentiels demandés. Questions mélangées une fois avec une graine fixe avant toute tranche.
• Métrique de routage : précision finale du routage sur la base de données explicitement déclarée.
• Métrique SQL : correspondance d'exécution avec la requête de référence BIRD, rapportée comme une fourchette à trois valeurs.
• Panel : 36 modèles, une seule exécution chacun sauf deux répétitions, $874.53 sur les exécutions du panel plus $85.37 sur les répétitions.

Quelles bases de données portent les questions difficiles. Cinq des onze ne contribuent à aucune des 184 questions les plus difficiles du tout. Ce sont california_schools plus les quatre isolées sémantiquement (financial, synthea, superhero, toxicology), qui fournissent néanmoins 27 des 165 questions signalées par voisinage entre elles.

La taxonomie de difficulté. Deux signaux indépendants étiquettent chaque question. Le premier encode toutes les 1 922 questions appartenant aux 11 bases de données et compte, parmi les 20 plus proches voisins de chaque question, combien se trouvent dans une base de données différente. Le second est un jury de trois modèles interrogés sur le caractère déroutant de la question entre bases. Le panier le plus difficile exige les deux plutôt que de les mélanger.

Aucun signal n'est significatif seul. La conjonction l'est. Mesurée sur un modèle, la précision de routage sur les questions signalées par les deux signaux était 0.803 fois la précision sur les questions faciles de cette même base de données, IC 95 % [0.685, 0.943], p = 0.007. Nous comparons à l'intérieur de chaque base de données, puis regroupons entre bases avec un rapport de risque logarithmique à variance inverse et une correction de continuité de 0.5. Cela regroupe sur 5 bases de données au lieu de 6, car regional_sales porte des questions difficiles mais pas de faciles et n'a donc rien à apparier. Trois choses gardent le contraste exploratoire. Il repose sur un modèle et cinq strates, et il est observationnel plutôt que randomisé.

Ce que voit le modèle. Chaque modèle reçoit une description paragraphe de toutes les 11 bases de données, sans noms de tables ou de colonnes, plus les 11 outils de base de données. L'anonymisation supprime le nom et non le domaine. Les descriptions disent encore de quoi parle chaque base, et une fois que le modèle appelle get_schema, il voit de vrais noms de tables et de colonnes. La condition mesure la compréhension de la description.

Notation de la route. La base de données déclarée est celle que le modèle nomme sous une clé explicite selected_database lors du tour de finalisation. Un modèle qui ne produit aucune déclaration explicite obtient zéro pour cette question. Les routes déduites du texte restent hors du titre et sont publiées séparément. Une version antérieure de ce travail portait trois définitions différentes de la métrique, et la variante grattée dans le texte gonflait six lignes du panel de 0.6 à 4.9 points.

Notation du SQL. La correction est décidée en exécutant les deux requêtes et en comparant les ensembles de résultats. Notre audit à cinq modèles a signalé 31.1 % des requêtes de référence BIRD comme cassées, donc cet axe est rapporté comme une fourchette à trois valeurs plutôt qu'un score unique. Les règles de notation, l'audit de référence et la fourchette complète se trouvent sur la page text-to-SQL liée ci-dessus.

Récupération des appels d'outils. Cinq familles de modèles sérialisent les appels d'outils dans des formats que l'analyseur standard n'accepte pas. Une couche de récupération analyse ces formes plutôt que de les noter comme silence, et chaque récupération est enregistrée par enregistrement et par exécution. Les appels tronqués ne sont jamais reconstruits. Six des 36 lignes portent une part de récupération non nulle. Cinq d'entre elles sont de l'ordre de la note de bas de page, 0.4 % à 4.4 %. La sixième est plus grande. llama-4-maverick se situe à 97.9 %, donc presque chaque appel d'outil dans cette ligne a été récupéré par adaptateur et cette ligne mesure le modèle plus la couche de récupération plutôt que le modèle seul. Un modèle, minimax-m2.7, raconte sans émettre aucun appel d'outil, et nous l'excluons du panel au lieu de le noter zéro.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Modèles testés

Quatre lignes portent un dénominateur de questions difficiles plus petit après que deux passes de relance aient laissé des erreurs résiduelles de fournisseur, à 182 pour gemini-3.1-pro-preview, gemini-3-flash-preview et nova-lite-v1, et 181 pour claude-haiku-4.5. Ces questions sont retirées du dénominateur plutôt que notées comme échecs, de sorte que chaque pourcentage porte sur les enregistrements qui ont été exécutés.

Précision de routage (toutes 759) : La même mesure sur l'ensemble figé complet, y compris les bras de contrôle facile et moyen. Le bras facile est saturé par conception.

Les intervalles 95 % : Chaque intervalle dans le tableau ci-dessus est un intervalle de Wilson sur les questions difficiles notées pour ce modèle, soit 184 pour la plupart des lignes et 182 ou 181 pour les quatre lignes ayant perdu des questions à cause d'erreurs résiduelles de fournisseur. Il couvre l'incertitude d'échantillonnage des questions et rien d'autre. Il ne couvre pas le regroupement des questions à l'intérieur des bases de données, et il ne couvre pas la variation d'une exécution à l'autre, que nous avons mesurée séparément à 1.6 à 2.7 points et qui est le terme le plus grand pour deux modèles proches l'un de l'autre.

Hasard et niveaux de référence. Le hasard est de 0.091 sur 11 bases de données. La classe majoritaire est 0.196 sur les 759 questions et 0.277 sur les plus difficiles. Trois récupérateurs non agentiques obtiennent 0.471 (TF-IDF), 0.495 (BM25) et 0.522 (base de données la plus proche par embedding) globalement, et 0.207 à 0.230 sur les plus difficiles. Ces trois mesures ont été prises sur l'ensemble de 594 questions antérieur et n'ont pas été réexécutées sur les 759, ce sont donc des points de référence historiques plutôt que des niveaux de référence pour ce panel. Le hasard et la classe majoritaire sont calculés sur les 759 figées et sont directement comparables.

Limites

Les deux modèles réexécutés se trouvent dans le premier niveau, où les questions sont les plus difficiles et les scores les plus compressés. Aucun modèle du milieu du tableau n'a été répété, de sorte que le terme de bruit en dehors du premier niveau n'est pas mesuré.

Les contrôles de contamination bornent l'effet, ils ne l'éliminent pas. Nous avons réécrit les questions difficiles pour préserver le sens et la référence tout en changeant la formulation. Sur les 138 paraphrases sur 184 qui ont passé les trois portes de validité, le routage n'a pas chuté, et l'effet de panel était significatif dans la direction opposée, 0.543 à 0.583, McNemar p = 0.032. Chaque question est notée dans les deux bras, le couplage est donc réel : 87 paires ont favorisé la paraphrase contre 60. Soixante-cinq questions rédigées de zéro et appariées sur la difficulté, le style de formulation et le mélange de bases de données ont obtenu un score à +0.012 de l'ensemble publié, p = 0.74. Cette dernière comparaison se fait entre deux ensembles de questions indépendants plutôt qu'appariés, c'est donc une comparaison à deux proportions et le plus faible des deux plans. Le contrôle rédigé couvre 3 des 11 bases de données, le contrôle paraphrase 6, et tous deux ont été exécutés uniquement sur des modèles bon marché. Un contrôle sur des bases de données publiées après les dates de coupure des modèles n'a pas été tenté, et 560 des 759 questions (73.8 %) proviennent de la partie train de BIRD, la part la plus susceptible d'avoir été mémorisée.

Supprimer les enregistrements non notés déplace le score principal d'au plus 0.90 points. Six lignes ont perdu des questions à cause d'erreurs résiduelles de fournisseur et ces questions quittent le dénominateur plutôt que d'être comptées comme échecs, ce qui gonfle un score si les pertes tombent sur des questions difficiles. En notant chaque question perdue comme erronée, gemini-3.1-pro-preview passe de 0.8242 à 0.8152 sur les plus difficiles (-0.90 pt) et de 0.9140 à 0.8959 sur les 759 (-1.81 pt), gemini-3-flash-preview -0.81 pt, claude-haiku-4.5 -0.79 pt, nova-lite-v1 -0.13 pt. Sept positions de classement s'échangent sur les plus difficiles, toutes adjacentes et toutes à l'intérieur du bruit d'exécution à exécution de 1.6 à 2.7 points. La convention n'est donc pas porteuse à la résolution de ce panel.

Les questions les plus difficiles sont une mesure de cluster de commerce. Quatre bases de données de commerce portent 171 des 184 questions difficiles et cinq bases n'en portent aucune. Le score principal se généralise au routage entre bases de données mutuellement déroutantes, ce que le benchmark a été construit pour mesurer, et non au routage inter-domaines en général. L'élargir signifie ajouter des questions difficiles d'un second cluster sémantique, ce que le corpus actuel ne peut fournir.

Le panel a tourné sur un harnais mixte. Dix-neuf modèles ont été notés après l'ajout de la couche de récupération d'appels d'outils, quinze avant, et deux chevauchent le changement. Un modèle du groupe antérieur qui émettait un appel d'outil non standard le voyait noté comme silence. Le balayage de la couche de récupération sur l'ensemble des 27 306 enregistrements stockés n'a trouvé aucun appel récupérable dans aucune des lignes antérieures, donc le coût mesuré du mixte est nul, mais une sérialisation qu'aucun analyseur ne gère serait également invisible à ce balayage.

Les exécutions ne sont pas reproductibles bit à bit. OpenRouter a servi kimi-k2.6 depuis 19 fournisseurs amont distincts au sein d'une même exécution et deepseek-v4-pro depuis 12, et le comportement de sérialisation diffère entre eux. Trois des 36 exécutions ont épinglé un fournisseur.

L'anonymisation est uniquement sur le nom. Les descriptions nomment encore leurs domaines, et le premier appel d'outil renvoie de vrais noms de tables et de colonnes, donc cette condition mesure la compréhension d'une description plutôt que la reconnaissance d'un nom.

La sortie de schéma est tronquée à 4 000 caractères. works_cycles est la plus grande base avec 66 tables, et 26 d'entre elles survivent à la coupure. Cette base porte 149 des 759 questions. Les résultats de requête sont plafonnés à 50 lignes.

L'axe de routage arrive à court de marge de progression. Le bras de contrôle facile est épuisé à 222 sur 222 pour les meilleurs modèles, et le panier le plus difficile compresse six modèles en cinq questions. Ce benchmark ne peut plus séparer les modèles de pointe les uns des autres sur le routage.

Pour en savoir plus

• Frameworks RAG : LangChain vs LangGraph vs LlamaIndex
• Meilleurs outils, frameworks et bibliothèques RAG
• Recherche agentique en 2026 : Benchmark de 8 APIs de recherche pour agents
• Top 5 des frameworks IA agentiques open-source en 2026
• Text-to-SQL : Comparaison de la précision des LLM

FAQ

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark RAG Agentic: Routage Multi-Bases de Données sur 36 LLMs}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Consulté le 11 Août 2026}
}

Liens de référence

1.

BIRD-bench

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et analyste de données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire