Vous venez d'autoriser votre agent IA à fouiller dans votre base de données clients, et votre carte bancaire fume déjà ? Le constat est limpide : le problème n'est pas le modèle de langage. Le problème, c'est que votre agent réfléchit comme un stagiaire surpayé qui parcourt la base ligne par ligne. Heureusement, des universitaires texans viennent de lui apprendre à compter.
L'intégration des modèles de langage dans les moteurs de bases de données était censée tout régler. On nous promettait des requêtes sémantiques fluides. On nous vendait la magie du langage naturel appliqué au Big Data. La réalité est beaucoup plus crasseuse. Les développeurs qui ont branché GPT-4 ou Claude 3 sur leurs tables de production ont vite déchanté. La précision est aléatoire. La latence est catastrophique. Et surtout, les coûts d'inférence explosent.
Une simple requête sur quelques dizaines de milliers de lignes peut vous coûter trois dollars. Multipliez ça par cent utilisateurs. Multipliez encore par vingt requêtes par jour. Vous venez de cramer le budget annuel de votre département Data en un mois. Les solutions hybrides de référence, comme Agentic BlendSQL, brûlent les tokens avec une désinvolture qui frise l'indécence.
C'est là qu'entre en piste EnumGRPO. Une équipe de chercheurs de l'Université du Texas à Austin, de l'UIUC et de l'Université Rice a décidé d'arrêter les frais. Ils ont conçu un optimiseur de requêtes agentiques capable d'entrelacer la planification et l'exécution dynamique. Le résultat ? Une division des coûts par 317. Et une amélioration de la précision de 18%. Y a pas photo.
L'illusion tenace du Text-to-SQL
Pendant des années, le marché a cru que le Graal consistait à traduire du langage naturel en requêtes SQL parfaites. Les modèles de frontière excellent à cet exercice. Vous demandez les ventes du trimestre, le modèle pond un SELECT impeccable, le moteur l'exécute gratuitement. Circulez, y a rien à voir.
Sauf que les entreprises ne posent pas des questions simples. Elles posent des questions tordues. "Quelles sociétés du secteur MedTech en phase clinique 3 affichent un ratio d'endettement anormal par rapport à leurs concurrents directs ?" Ce genre de requête nécessite des connaissances externes. Elle nécessite une inférence sémantique floue. Aucun schéma relationnel au monde ne capture l'anormalité clinique. Le SQL pur échoue.
Il a donc fallu inventer des opérateurs sémantiques. Des rustines. On injecte des appels au LLM au beau milieu du plan d'exécution de la base de données. On crée des opérateurs LLMFilter ou LLMMap. Le moteur relationnel filtre ce qu'il peut, puis passe le bébé au réseau de neurones.
Le syndrome du stagiaire millionnaire
Dans la théorie classique des bases de données, l'optimiseur de requêtes est le cerveau de l'opération. Depuis le légendaire System R d'IBM à la fin des années 70, la règle est immuable. L'optimiseur explore des plans équivalents. Il choisit celui qui consomme le moins de CPU et de mémoire. Qu'il filtre avant de joindre ou après, le résultat final reste strictement identique.
Cette garantie d'équivalence explose en vol dès qu'on introduit un LLM. L'opérateur sémantique est intrinsèquement approximatif. Sa précision varie selon le contexte qu'on lui donne. Surtout, chaque appel coûte une blinde. Une milliseconde de CPU ne coûte rien. Une seconde d'API coûte cher.
Si on laisse un agent interroger une base naïvement, il fait ce qu'on appelle de l'évaluation scalaire data-driven. C'est-à-dire qu'il prend la première ligne de la table. Il l'envoie au modèle. Il attend la réponse. Il prend la deuxième ligne. Il l'envoie. Et ainsi de suite. Pour une table de cent mille lignes, il fait cent mille appels. C'est lent. C'est stupide. Et ça coûte une fortune. C'est l'équivalent numérique d'un consultant facturé mille balles de l'heure pour trier des post-its.
Anatomie d'un optimiseur débridé
Les chercheurs d'Austin ont formalisé ce foutoir. Ils ont découpé l'espace des plans d'exécution agentiques en cinq dimensions orthogonales. Cinq leviers pour dompter la bête.
Le premier levier est le paradigme d'exécution. Au lieu d'appeler le LLM pour chaque ligne (le désastre data-driven), l'agent peut passer en mode code-driven. Il demande au modèle de générer une règle Python ou un bloc SQL qui capture la logique sémantique. Ensuite, le moteur de la base exécute cette règle localement. Un seul appel API au lieu de cent mille. La facture fond.
Le deuxième levier concerne le type d'opérateur. L'agent peut évaluer les lignes une par une (scalaire) ou les regrouper dans un gros prompt (agrégé). L'agrégation exploite la fenêtre de contexte géante des modèles récents. Elle réduit le surcoût de l'en-tête du prompt.
Le troisième levier gère le placement. Est-ce qu'on agresse le LLM avec les données brutes avant de les filtrer en SQL ? Non. On fait le ménage d'abord. On applique les filtres relationnels déterministes. On réduit la taille du problème. Ensuite, on envoie les survivants au LLM.
Le quatrième levier limite la portée. Envoyer toute la table au modèle est un suicide financier. EnumGRPO filtre drastiquement les candidats. Il restreint le champ de vision.
Le dernier levier taille dans la largeur. Envoyer toutes les colonnes d'une table quand seules deux suffisent pour la décision est un gaspillage absurde. L'optimiseur sélectionne un contexte étroit. Il transmet l'essentiel. La taille des prompts s'effondre.
L'algorithme qui fait transpirer les APIs
Explorer cet espace combinatoire à la main est impossible. Entraîner un modèle dédié coûterait des millions. L'équipe a choisi une voie plus élégante. L'apprentissage par renforcement in-context. Sans toucher aux poids du modèle. Sans gradient.
Le système génère des variantes de plans. Il les teste. Il calcule une récompense. Cette récompense mélange la précision de l'exécution, le score F1 sur les données trouvées, et une pénalité sévère sur le coût en tokens. L'agent doit maximiser la qualité tout en minimisant la casse financière.
Inspiré par l'approche GRPO de DeepSeek, l'algorithme compare chaque plan à la moyenne de ses concurrents. Il extrait des leçons. Il analyse ses échecs. S'il s'aperçoit qu'un passage en mode scalaire sur une colonne binaire gaspille du token pour rien, il pond une règle textuelle. "Si la colonne cible a peu de modalités, génère du code". Il stocke ces heuristiques. Lors de la prochaine requête, il les injecte directement dans son prompt système. Il s'améliore tout seul.
Les résultats mesurés sur le benchmark SWAN donnent le vertige. Sur 120 requêtes transverses appliquées à des bases de données réelles, les solutions standards s'effondrent. Agentic BlendSQL crache 273 dollars pour un lot de 80 requêtes. Il consomme 81 millions de tokens. Il met 346 secondes en moyenne par question.
EnumGRPO ? Le même lot coûte 86 centimes. Moins d'un dollar. Il n'avale que 739 000 tokens. Son exécution tombe à 153 secondes. C'est une division des coûts par 317.
Fini la fête du token
Prenons l'exemple de la base de données California Schools. BlendSQL s'y perd totalement et facture 46 dollars. EnumGRPO déplace l'effort vers des filtres générés sous forme de code. Sa facture s'arrête à un cinquième de centime. C'est une réduction d'un facteur 24 000. Vous avez bien lu. Vingt-quatre mille.
Le plus impressionnant reste le comportement face à la montée en charge. Si la base de données voit son volume multiplié par cent, les méthodes concurrentes explosent. Leurs coûts partent dans la stratosphère. La latence devient ingérable. L'approche texane, elle, maintient une courbe presque plate. En contraignant le contexte et en privilégiant l'exécution locale des règles symboliques, le système s'isole de la volumétrie brute.
Tout n'est pas parfait pour autant. L'exactitude globale plafonne à 35,4%. Cela laisse un taux d'échec monumental de 64,6% sur les requêtes les plus extrêmes. Quand le système doit mobiliser des connaissances encyclopédiques rares, la gymnastique d'optimisation ne suffit plus. Si l'information n'est ni dans la base ni dans les poids facilement accessibles du LLM, la requête échoue.
De plus, l'architecture reste fondamentalement dépendante du moteur SQL sous-jacent. Si la première étape de filtrage élimine par erreur des lignes pertinentes à cause d'une mauvaise jointure classique, le LLM ne pourra jamais les récupérer. L'aveuglement initial est fatal.
Enfin, la flexibilité des plans d'exécution rend le débogage cauchemardesque. Quand un arbre statique échoue, on regarde le nœud défectueux. Quand un agent dynamique change d'avis en plein vol et passe du mode scalaire à un filtre généré aléatoirement, tracer l'origine d'une erreur exige de décortiquer tout l'historique cognitif de la machine. Les ingénieurs de production vont adorer.
Verdict
EnumGRPO sonne la fin de la récréation pour les agents naïfs. Pousser bêtement des millions de tokens dans l'entonnoir OpenAI en priant pour avoir une bonne réponse était une absurdité économique. En ressuscitant la théorie de l'optimisation des années 70 et en l'appliquant aux opérateurs LLM, ces chercheurs rendent enfin les pipelines sémantiques viables pour l'industrie. Franchement, il était temps. L'époque où l'IA justifiait de jeter l'ingénierie logicielle par la fenêtre est terminée. L'optimisation sauvage vient de se prendre le mur de la rentabilité.
Note finale : 4.5/5. Le seul framework qui comprend que le budget cloud n'est pas infini.
Sources
✦ Idée d'illustration : Une caisse enregistreuse mécanique des années 70 qui écrase violemment une montagne de jetons de casino dorés (tokens). L'ambiance doit être sombre, industrielle et néobrutaliste, avec des câbles réseau qui s'échappent du tiroir-caisse.
