Benchmark du RAG agentique: routage entre 11 bases de données SQL

La précision de routage est le pourcentage de questions notées pour lesquelles le modèle désigne explicitement la bonne base de données dans sa réponse finale. Le résultat principal utilise les 184 questions signalées comme difficiles à la fois par notre test de similarité et par un jury de trois LLMs. Les déclarations explicites manquantes ne rapportent aucun point.

Constatations sur le routage des bases de données

qwen3.8-max a enregistré une précision de routage de 83,2 % pour une exécution à $25,14

Qwen3.8-max a répondu correctement à 153 des 184 questions de routage difficiles pour un coût enregistré de $25.14. claude-fable-5 a répondu correctement à 151 pour $121.55. Les 759 questions ont toutes été traitées lors des deux exécutions.

Cet écart de deux questions est inférieur à la variation mesurée lors de la répétition de qwen3.8-max. Les coûts enregistrés dépendent du choix du fournisseur et de l’utilisation du cache, si bien que cette comparaison ne permet pas d’établir un classement durable prix-performance.

La précision de routage finale a augmenté pour Grok et Opus, mais a diminué pour Nova

Pour claude-opus-5, la précision sur les questions difficiles a augmenté de 25.0 points de pourcentage entre sa première consultation de base de données et sa déclaration finale. grok-4.5 a gagné 38.0 points au cours de sa propre exécution. gpt-5.4-mini n’a enregistré aucun gain, tandis que nova-lite-v1 a perdu 14.0 points.

Chaque variation compare le début et la fin d’une même exécution. Les questions ayant sollicité plusieurs bases de données au premier tour sont exclues, car elles n’ont pas de premier choix unique.

Ce décompte utilise la première base de données dans l’ordre des appels enregistrés, y compris les premiers tours impliquant plusieurs bases de données. Les variations en points de pourcentage ci-dessus reposent sur un premier choix unique.

Un appel de base de données ne garantit donc pas une correction utile. Ce qui importe est de savoir si le modèle utilise les informations renvoyées pour parvenir au bon choix final. Il s’agit d’une observation des trajectoires enregistrées, sans intervention distincte isolant la valeur des appels supplémentaires.

Résultats du routage des bases de données

Les modèles sont présentés par ordre alphabétique. La méthodologie identifie des différences dans le logiciel utilisé pour les exécuter. Ces conditions comptent lors de l’interprétation de petits écarts de scores.

Les intervalles estiment l’incertitude liée à l’échantillonnage des questions. Les coûts enregistrés couvrent les enregistrements réussis de chaque exécution. Ils reflètent les fournisseurs et les conditions de cache utilisés au moment de la mesure.

Modèles de décision pour le routage des bases de données

Nous avons comparé Jev, Kev-9B, Laya English et six LLMs sur 243 questions examinées issues des mêmes 11 bases de données. Chaque modèle a sélectionné une base de données à partir des descriptions fournies.

Laya a été exécuté localement sur un Apple M4. Kev a été exécuté sur un service A100 dédié accessible via un tunnel SSH. Les autres modèles ont utilisé des APIs hébergées. La latence inclut la requête client complète parmi les réponses valides. La précision inclut chaque question tentée.

Jev a sélectionné la bonne base de données pour 240 questions sur 243, contre 123 pour Laya English : 117 sélections correctes de plus, soit un écart de 48.1 points de pourcentage. Jev a été le modèle hébergé le plus rapide en latence médiane lors de cette exécution. Le déploiement local de Laya a présenté la latence médiane la plus faible au total, parallèlement à une précision nettement inférieure.

Kev-9B a correctement sélectionné 236 bases de données, soit quatre de moins que Jev. Cinq de ses sept erreurs concernaient la base de données des cartes de débit carburant. Sa réponse médiane a pris 952 ms en incluant le réseau et le tunnel SSH. La médiane serveur enregistrée séparément était de 470 ms. Ce déploiement A100 utilisait FP32 et des noyaux de référence. Sa vitesse dépend de cette configuration de service.

Gemini 3.8 Flash et Claude Opus 5 ont tous deux sélectionné la bonne base de données pour chaque question. Opus a mis 1.72 fois plus de temps en médiane et son coût d’API déclaré était 7.58 fois celui de Gemini pour ces questions. La précision était identique pour ces deux modèles sur cet ensemble.

Le résultat de DeepSeek inclut 19 défaillances de service ou de sortie : 16 réponses HTTP 429, deux réponses ne respectant pas le format à alias unique exigé et une réponse ayant épuisé le budget de sortie. Il a sélectionné la bonne base de données dans 211 de ses 224 réponses valides, soit 94,2 %. En comptant toutes les tentatives, on obtient les 86,8 % indiqués dans le graphique et le tableau.

Coûts de routage : tarification des API et estimations matérielles

Jev a sélectionné la bonne base de données pour 98,8 % des questions à un coût d’API de $0,0337 par 1 000 tentatives de routage. Qwen3.8 Flash a enregistré une précision de 97,9 % pour $0,0791, tandis que Gemini 3.8 Flash a atteint 100,0 % pour $0.5337. Nous avons mis les coûts à l’échelle à partir de la même charge de 243 questions, en incluant les réponses incorrectes et en excluant les échauffements. Le coût d’API de Jev représentait environ 1/120 de celui de Claude Opus 5 pour les mêmes 243 tentatives de routage.

L’estimation matérielle de Laya était de $0,0141 par 1 000 tentatives à une précision de 50,6 %. Kev a atteint 97,1 % pour un coût estimé de $0.1250. Les deux estimations supposent que la machine louée traite les requêtes en continu. À 10 % d’utilisation, chaque requête supporte dix fois le coût de location, portant Laya à $0,1405 et Kev à $1,2503 par 1 000 tentatives.

Pour les cinq LLM disposant de relevés de frais complets, nous avons divisé les frais d’API déclarés par 243 et multiplié par 1 000. Jev facture $0,042 par million de tokens d’entrée, avec des tokens de sortie gratuit. Ses 194 882 tokens d’entrée enregistrés ont coûté $0,008185 sur 243 tentatives, soit $0,0337 par 1 000.¹

Le coût matériel par 1 000 tentatives est égal au prix de location horaire × le temps de traitement moyen en secondes × 1 000 ÷ (3 600 × l’utilisation). Laya a mis en moyenne 0.2006 seconde par requête sur un Apple M4. Kev a mis en moyenne 0.4734 seconde sur le serveur A100, hors délai réseau et SSH. Nous avons appliqué ces temps à du matériel équivalent chez les fournisseurs cités. Les totaux de performance et de facturation chez ces fournisseurs restent non mesurés.

Pour Kev, nous avons utilisé $0,9508/heure pour une A100 SXM 80 Go chez Vast.ai, l’offre à la demande correspondante la moins chère dans nos données de l’indice des prix de location de GPU.

Pour Laya, nous avons utilisé la M4-S de Scaleway avec 16 Go de mémoire à €0.22/heure. La conversion utilise le taux de la BCE du 22 septembre de $1,1463 par euro. Scaleway impose une location minimale de 24 heures, ce qui porte la location minimale à €5.28, soit environ $6,05, même pour un travail court.²³⁴

La page du modèle de Laya ne mentionnait aucun fournisseur d’inférence Hugging Face. Notre estimation couvre la location d’une machine et l’exécution du modèle sur celle-ci. Le temps de configuration, le stockage, les frais réseau supplémentaires, les taxes et la main-d’œuvre opérationnelle sont exclus des deux estimations matérielles.⁵

Comment les modèles de décision choisissent une base de données

Pour Jev et Laya, l’application fournit le contexte, une question et des options nommées accompagnées de descriptions. Leurs interfaces Choice renvoient une option sélectionnée, des probabilités sur les options et un score de confiance. Le code de l’application décide quoi faire de ce résultat. Pour le routage, les options sont des alias de bases de données tels que db_03 et db_07.⁶⁵

Ce format rend la sortie facile à utiliser dans le code. Un modèle peut toujours choisir la mauvaise base de données. Un score de confiance élevé doit également être validé au regard de l’exactitude observée avant qu’une application ne l’utilise pour ignorer une vérification ou déclencher un repli.

Le checkpoint anglais de Laya utilise un encodeur bidirectionnel ModernBERT avec une tête de décision qui note les options fournies. Les descriptions d’options arrivent avec la requête, ce qui permet à l’application de modifier les choix disponibles. Jev expose une API Choice hébergée. Sa documentation place le contrôle du flux de travail et les actions dans le code de l’application. L’interface partagée n’établit pas que les deux modèles possèdent la même architecture interne.⁵⁷

Kev-9B utilise un adaptateur LoRA et une tête de pointeur sur Qwen3.5-9B-Base. Il note les choix fournis et renvoie leurs probabilités sans générer de texte de réponse. Nous avons utilisé son endpoint Choice compatible avec la même question et les mêmes descriptions de bases de données.⁸

Conditions influant sur la sélection de la base de données

Des bases de données similaires ont réduit la précision de routage d’environ 20 points

Nous avons testé la méthode de sélection de base de données dans une expérience distincte sur 128 questions. Chaque question conservait sa base de données correcte, tandis que les 10 autres candidates provenaient soit de notre groupe sélectionné, soit d’un tirage aléatoire.

Sur le sous-ensemble difficile, claude-opus-4.8 a obtenu 71,3 % avec des candidates similaires et 92,0 % avec des candidates aléatoires. gemini-3.5-flash a obtenu 77,0 % et 96,6 %. Les deux différences présentaient des valeurs p inférieures à 0.001 dans les tests appariés.

Cette expérience utilisait des descriptions et une réponse de modèle par question, sans boucle d’outils agentique. Elle appuie la conclusion plus étroite selon laquelle la sélection de candidates similaires rend le choix de la base de données plus difficile. L’écart mesuré ne doit pas être présenté comme l’effet de l’exploration agentique.

Les noms seuls ont produit une précision de 68,8 % et de 71,1 % dans un pilote

Dans un autre pilote de 128 questions, claude-opus-4.8 a sélectionné la bonne base de données 68,8 % du temps à partir des seuls noms. Son score avec les noms et les descriptions était de 67,2 %. gemini-3.5-flash a obtenu 71,1 % avec les noms et 75,0 % avec le catalogue complet.

Des noms tels que california_schools et toxicology révèlent directement le sujet. Pour le benchmark principal, nous remplaçons les noms de bases de données par des alias allant de db_01 à db_11. Les descriptions expliquent toujours le domaine de chaque base de données, et les réponses des outils exposent ses noms de tables et de colonnes.

Fiabilité des comparaisons de routage et de coûts

Les exécutions répétées ont modifié la précision de routage de 1.6 à 2.7 points

claude-opus-5 a sélectionné la bonne base de données pour 156 des 184 questions difficiles lors de sa première exécution et 151 lors de sa répétition. Sa précision est passée de 84,8 % à 82,1 %. qwen3.8-max est passé de 153 réponses correctes à 150, soit une baisse de 83,2 % à 81,5 %.

Les deux répétitions ont utilisé les mêmes questions, anonymisation, température et réglages de fournisseur que leurs exécutions d’origine. qwen3.8-max a changé sa réponse sur 13 questions difficiles, même si son total n’a varié que de trois. Des améliorations sur certaines questions ont annulé des erreurs sur d’autres.

Ces répétitions montrent que de petits écarts de score peuvent disparaître lors d’une autre exécution. Une seule répétition par modèle ne permet pas d’établir une distribution des résultats, et les 35 autres modèles n’ont pas de mesure répétée.

Les coûts enregistrés dépendent du fournisseur et des réglages de cache

Le cache de prompts réutilise les entrées déjà traitées afin de réduire les coûts facturés des entrées. L’exécution de claude-opus-5 a coûté $62,78, contre une estimation de $105,54 aux tarifs catalogue sans cache pour la même utilisation enregistrée. Cette estimation implique une économie de 40,5 %. Il s’agit d’une comparaison comptable, sans exécution distincte de précision sans cache.

Le RAG agentique et la sélection des bases de données

Le RAG agentique donne à un modèle contrôle des décisions de récupération. Il peut choisir une source, inspecter la réponse et effectuer une autre requête. Un simple pipeline de RAG récupère le contexte selon une séquence prédéterminée avant de générer une réponse.

Ce benchmark teste la sélection de sources à l’aide d’outils de base de données SQL. Il ne contient ni index de documents, ni passages récupérés, ni score d’ancrage des réponses. Les résultats décrivent donc une partie d’un système de récupération agentique. La recherche documentaire est couverte séparément dans notre benchmark de recherche agentique.

Un modèle commence avec de courtes descriptions de bases de données. Il peut demander des listes de tables, inspecter des colonnes, exécuter des requêtes SQL et changer de base de données. Sa réponse finale contient un choix de base de données et une requête. Notre benchmark text-to-SQL indique la précision SQL et deux scores de revue supplémentaires.

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

Méthodologie du benchmark du RAG agentique

L’ensemble de questions est un sous-ensemble figé de BIRD-SQL, qui associe des questions en langage naturel à des requêtes de référence SQL.⁹

Deux signaux définissent la difficulté. Le test de similarité compte combien des 20 plus proches voisins d’une question appartiennent à d’autres bases de données. Trois LLMs évaluent si la question est trompeuse entre les bases de données. L’appartenance au groupe le plus difficile exige au moins cinq voisins inter-bases et une étiquette de jury trompeuse.

Le routage utilise la base de données nommée dans le champ explicite selected_database. Un itinéraire déduit de la prose est exclu du résultat principal. La justesse SQL est notée séparément et ne détermine pas le crédit de routage.

Le harnais est le logiciel qui présente les outils et enregistre les réponses des modèles. Le panel principal contient 36 exécutions OpenRouter et une exécution Codex CLI. Parmi les exécutions via API, 19 utilisaient la v3, 15 utilisaient une version antérieure, et deux combinaient des enregistrements des deux versions. Dans la v3, une couche de récupération analyse les formats alternatifs d’appel d’outil pris en charge. Pour llama-4-maverick, la part enregistrée de format non natif était de 97,9 %, de sorte que ce résultat dépend fortement de l’adaptateur. minimax-m2.7 a été exclu parce qu’il n’a pas émis les appels d’outils de base de données exigés par la tâche.

GPT-6 Astra a été exécuté dans Codex CLI, dont l’identifiant de harnais enregistré est codex_cli_transcript_v1. Comme la configuration diffère, les différences de score ne peuvent pas être attribuées au modèle seul. GPT-6 Astra a terminé les 759 questions. Il a sélectionné la bonne base de données sur 155 des 184 questions difficiles et a enregistré une précision de routage de 95,3 % sur l’ensemble complet. Son exécution n’a pas fait état de coûts en dollars.

Benchmark de routage des modèles de décision

L’expérience de routage distincte a utilisé 243 questions inchangées sélectionnées parmi 394 candidates après la mise en réserve de 17 questions de développement. L’ensemble de requêtes contenait 204 questions initialement faciles et 39 initialement difficiles. Ces étiquettes de difficulté n’ont pas été revalidées pour cette tâche, et la sélection n’était pas une évaluation aveugle sur jeu réservé.

Quatre descriptions de bases de données ont été corrigées à l’aide des schémas sources et du texte des questions avant la collecte des prédictions mesurées. Les sept autres ont conservé leurs descriptions compactes. Chaque modèle a reçu la même question, les mêmes 11 alias et descriptions, et le même ordre des options pour cette question. Le SQL de référence, les étiquettes sources et les preuves supplémentaires n’ont pas été fournis. Jev et Laya ont utilisé leur interface Choice native. Les LLMs ont reçu pour instruction de renvoyer un seul alias. Les modèles ne disposaient d’aucun outil de base de données.

Nous avons exécuté Jev 1.13.0 via son API hébergée et le checkpoint épinglé Laya English localement avec Apple M4 MPS, 16 Gio de mémoire et quatre threads Torch. La limite de 404 tokens de Laya pour la tête de contexte et la limite de 48 tokens par option n’ont produit aucune troncature d’entrée. Six LLMs ont été exécutés via OpenRouter avec des fournisseurs et des réglages de raisonnement fixes. Le raisonnement demandé était faible pour Gemini 3.8 Flash, minimal pour Gemini 3.5 Flash Lite et élevé pour Opus. Il était désactivé pour DeepSeek, Qwen et Haiku. Chaque modèle a eu un échauffement exclu, une requête en cours et aucune reprise. L’ordre de soumission des modèles a pivoté entre les questions.

Kev-9B a été ajouté le 22 septembre dans une exécution distincte, en préservant les huit résultats d’origine. Ses 243 charges de requête correspondaient exactement aux entrées Jev d’origine, y compris l’ordre des options. Nous avons épinglé la révision de checkpoint 2629c06a et utilisé une A100 SXM 80 Go avec FP32, attention SDPA et LoRA non fusionné. Le prétraitement des dates et le cache de préfixes étaient désactivés. Après avoir vérifié l’API sur les 17 questions de développement réservées, nous avons exécuté un échauffement exclu et 243 requêtes en série sans reprise. Le service était réservé à notre usage. Chaque réponse a confirmé que l’entrée complète avait été conservée. Les temps serveur incluent la tokenisation et l’inférence synchronisée. Le graphique utilise les temps client, y compris le surcoût SSH et réseau.

La précision divise les choix corrects et valides par l’ensemble des 243 questions prévues, y compris les défaillances de service et de sortie. La latence médiane mesure la requête client non diffusée complète parmi les réponses valides, en excluant l’échauffement. Les coûts d’API des LLM déclarés couvrent les requêtes mesurées. Les coûts matériels de Laya et de location de Kev n’ont pas été mesurés, et l’estimation au prix catalogue de Jev repose sur une base comptable différente. La comparaison décrit cet ensemble préparé et ces conditions de déploiement. Les données sources publiques, les révisions des descriptions, le jugement des évaluateurs, les dates de mesure différentes et l’absence de répétitions limitent la généralisation.

Limites

Le sous-ensemble difficile se concentre sur le commerce. Quatre bases de données fournissent 171 de ses 184 questions, soit 92,9 %. Cinq des 11 bases de données n’en fournissent aucune. Cela appuie des conclusions sur le choix entre des bases de données similaires au sein d’un domaine, avec des preuves limitées pour d’autres combinaisons de domaines.

Sept exécutions contiennent moins de 759 enregistrements notés après des erreurs de fournisseur. Cinq possèdent aussi moins de 184 enregistrements de questions difficiles. Leurs dénominateurs du tableau indiquent les questions terminées. Les enregistrements manquants sont exclus, ce qui peut favoriser un modèle si les questions omises étaient plus difficiles.

Les intervalles de Wilson couvrent l’incertitude d’échantillonnage dans un modèle au niveau des questions. Ils omettent la variation entre les exécutions répétées, la dépendance entre les questions issues de la même base de données et l’incertitude introduite par le harnais. Les changements de fournisseur et la récupération des appels d’outils limitent également les comparaisons entre les exécutions.

Les données publiques du benchmark peuvent être apparues dans l’entraînement des modèles. Des contrôles utilisant 138 paraphrases validées et 65 questions nouvellement rédigées n’ont constaté aucune baisse de précision chez les modèles testés à moindre coût. Leur couverture était limitée à six et trois bases de données respectivement. Ils ne résolvent pas la contamination pour l’ensemble du panel, et aucun contrôle n’a utilisé des bases de données publiées après la date limite d’entraînement des modèles.

La troncature des schémas peut masquer des tables utiles. Dans works_cycles, la limite de 4 000 caractères ne laisse visibles que 26 des 66 tables dans la liste initiale des schémas. Le modèle peut demander plus de détails, mais la vue initiale est incomplète.

Pour aller plus loin

• Text-to-SQL : comparaison de la précision des LLM
• RAG Frameworks : LangChain vs LangGraph vs LlamaIndex
• Meilleurs outils, frameworks et bibliothèques RAG
• Recherche agentique en 2026 : benchmark de 8 APIs de recherche pour agents

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 du RAG agentique: routage entre 11 bases de données SQL}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Consulté le 23 septembre 2026}
}

Journal des modifications

16 mises à jour

Toutes16Général13Méthodologie3

202620252024

1. 11 août

   La section « Qu'est-ce qui rend une question difficile dans ce benchmark ? » a été mise à jour avec un nouveau contenu.

2. 11 août

   La méthodologie a été mise à jour pour clarifier la répartition des questions les plus difficiles entre les bases de données.

3. 7 août

   La section de méthodologie de référence RAG Agentic a été remplacée par une nouvelle couvrant 36 LLM et 11 bases de données.

4. 29 juin

   Ajout de nouveaux modèles au benchmark : Claude Fable 5, Claude Opus 4.8, Gemini 3.5 Flash, Grok 4.3, Claude Opus 4.7.

5. 20 fév

   La section méthodologie a été mise à jour avec de nouveaux détails sur l'environnement de la base de données, l'architecture de l'agent et le processus d'évaluation.

6. 23 jan

   Ajout d'une section sur les modèles à long contexte par rapport au RAG agentique.

7. 23 jan

   Suppression des métriques agentiques supplémentaires de la méthodologie.

Liens de référence

1.

Models - TypeSafe AI

Mintlify

2.

Apple Silicon Pricing | Scaleway

3.

Euro exchange rates charts

4.

Apple silicon M4 as-a-Service. Cloud Mac | Scaleway

5.

convaiinnovations/laya · Hugging Face

6.

Choice - TypeSafe AI

Mintlify

7.

How to build with TypeSafe - TypeSafe AI

Mintlify

8.

jaredpalmer/kev-9b · Hugging Face

9.

BIRD-bench

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des 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