LO
ContrainteAutomatisation cognitive2024-11-12
Sur 632 flux de données d'entreprise tirés de vrais entrepôts, un agent de code en a résolu 21.3 % — contre 91.2 % sur la version académique de la même tâche
Ingénieur de donnéespage du métier →
Date de l'événement / signalement
2024-11-12
Stade de la preuve
ContrainteUn échec, un retour en arrière, une réglementation ou un coût freine l'adoption. Cela peut abaisser une appréciation ou élargir son incertitude.
Tâches concernées
Construire la chaîne de traitement
Extraire d'une source, remodeler, charger quelque part d'interrogeable, et programmer l'ensemble.
En cours d'automatisation✓ Appuyé sur des preuves
Détenir ce qu'un chiffre veut dire
Définir l'utilisateur actif, le chiffre d'affaires, l'attrition — et tenir cette définition quand deux équipes veulent qu'elle signifie autre chose.
Encore menée par des humains✓ Appuyé sur des preuves
Où ceci s'applique
632 problèmes construits à partir de vraies applications de données sur BigQuery et Snowflake, avec des bases dépassant souvent 1 000 colonnes. Ce qui les rend difficiles est énoncé par les auteurs et c'est exactement l'environnement quotidien de ce métier : la réponse exige de chercher dans les métadonnées de la base et la documentation du dialecte, de lire la base de code du projet, de tenir un contexte très long, et d'émettre plusieurs requêtes dans différents dialectes qui dépassent fréquemment 100 lignes. Les 21.3 % correspondent à un cadre d'agent sur o1-preview fin 2024 et seront périmés ; le constat durable est l'écart avec les 91.2 % sur Spider 1.0 et les 73.0 % sur BIRD, qui est une mesure de la part de la difficulté qui vit dans l'entrepôt plutôt que dans le SQL. Cela ne dit rien de l'emploi, et rien des chaînes que l'on construit plutôt que l'on interroge — cela teste la production de la requête, non l'exploitation du système qui continue de la produire.
Ce que cela veut dire
La difficulté de ce métier est mesurable et l'essentiel n'est pas dans le SQL. Quand la même classe de tâche est posée sur un vrai entrepôt — un millier de colonnes, plusieurs dialectes, de la documentation à chercher, une base de code à lire — le taux de réussite tombe d'environ neuf sur dix à environ deux sur dix. Cet écart est un chiffre pour ce que les ingénieurs de données disent sans être crus : la requête est la partie facile, et savoir quelle table est la bonne, c'est le métier.
Ce que cela ne montre pas encore
Un score de banc d'essai n'est pas la décision d'un employeur, et un score bas n'est pas une sécurité. Le chiffre vient d'un cadre d'agent sur une génération de modèles fin 2024 et doit être supposé avoir bougé ; ce qui bouge moins vite, c'est la raison pour laquelle il était bas. Cela teste aussi la production d'une requête correcte, qui n'est qu'une des tâches de ce métier — rien ici ne porte sur la construction d'une chaîne, sur ce qui arrive quand le schéma en amont change, ni sur qui est appelé quand les chiffres cessent d'arriver.
Ce que vous pouvez vérifier
Choisissez un chiffre que votre entreprise suit pour se piloter et remontez jusqu'aux tables qui le calculent. Comptez combien des décisions du parcours sont écrites quelque part. C'est ce décompte, non le SQL, qu'un outil devrait reproduire.
Cela change-t-il l'évaluation ?
Non. L'indice d'impact n'est jamais déplacé par un seul événement. Ce que ce dossier a fait : 2 jugements de tâche liés ci-dessus reposes désormais sur une preuve au lieu d'une inférence.
Source
Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2411.07763) · vérifié 2026-09-12 · Claude (VOLO agent) — arXiv abstract page read; the 632-problem count, the 1,000-column note and the 21.3% / 91.2% / 73.0% comparison taken from the authors' own abstract · interprété 2026-09-12 · Claude (VOLO agent)
Source primaire — publiée par la partie qui a fait la chose, ou par l'autorité de référence. Aucune contresignature nécessaire.
Ce dossier est cité dans