Résumé technique : L'analyse de données en milieu réel : Évaluation des grands modèles de langage face aux complexités des données réelles

Énoncé du problème

Les évaluations actuelles destinées à tester les grands modèles de langage (LLM) dans l'analyse de données ne reflètent pas les environnements du monde réel. Les jeux de données existants (par exemple, WikiTableQuestions, Spider) reposent généralement sur des environnements à table unique et à petite échelle, et se concentrent principalement sur la récupération de faits via le parsing sémantique ou le text-to-SQL. Ces benchmarks négligent des défis pratiques critiques, notamment :

• Échelle et complexité : La nécessité de traiter des tables massives (des millions de lignes) et de fusionner plusieurs tables hétérogènes.
• Dépendance contextuelle : Le rôle essentiel des métadonnées et des connaissances externes (par exemple, les dictionnaires de données) nécessaires pour interpréter les données brutes.
• Portée des tâches : L'absence d'évaluation de la capacité de découverte proactive d'informations. Les tâches existantes se concentrent sur la réponse à des requêtes spécifiques, manquant la capacité des analystes de données à générer des conclusions de niveau expert sans prompt explicite de l'utilisateur.

Par conséquent, l'ensemble de compétences orienté vers la « découverte » reste largement non évalué, créant un fossé entre la vision de systèmes d'analyse de données autonomes et leurs performances réelles dans des scénarios complexes du monde réel.

Méthodologie : DataGovBench

Pour combler ces lacunes, les auteurs introduisent DataGovBench, un benchmark dérivé de répertoires de données ouvertes gouvernementales (par exemple, Data.gov, Data.gov.uk). Le benchmark est construit via un processus en trois étapes :

1. Curation des données : Les auteurs ont identifié 53 plateformes de données ouvertes et ont filtré les jeux de données selon des critères stricts : au moins un fichier tabulaire avec plus de 5 000 lignes, des métadonnées disponibles (descriptions) et la présence de connaissances externes (par exemple, des dictionnaires de données). L'ensemble final comprend 178 jeux de données uniques, présentant une moyenne de 210 000 lignes et 18 colonnes, la plus grande table contenant 11,9 millions de lignes. Notamment, plus de 36 % des jeux de données sont multi-tabulaires, et plus de 57 % incluent des connaissances externes sous divers formats (PDF, XLSX, etc.).

2. Définition des tâches : Le benchmark évalue les LLM sur deux tâches complémentaires :

   • Table QA (Questions-Réponses sur table) : Les modèles doivent répondre à des questions simples ou décomposables (raisonnement multi-étapes) avec des sorties textuelles ou visuelles. Pour gérer les grandes tables, les auteurs proposent la Sériatisation de table spécifique au type de caractéristique (Feature Type-Specific Table Serialization), une technique qui crée un résumé compact d'une table en représentant les colonnes selon leurs types de données (par exemple, en listant les catégories uniques pour les colonnes catégorielles, le min/max pour les colonnes numériques) plutôt que les lignes brutes.
   • Table Insight (Aperçu de table) : Les modèles doivent effectuer une analyse exploratoire ouverte pour générer une liste de conclusions de niveau expert et un résumé sans requête utilisateur spécifique. La vérité de terrain pour cette tâche est dérivée des rapports officiels accompagnant les jeux de données, garantissant une évaluation objective des aperçus subjectifs.

3. Pipeline d'annotation :

   • Paires de QA : Générées via un pipeline "human-in-the-loop" utilisant un ensemble de quatre LLM (GPT-4o, GPT-4o-mini, Gemini 2.0 Flash, Gemini 1.5 Pro). Les questions subissent une notation automatisée, une génération de réponses (via l'exécution de code Python) et une vérification humaine rigoureuse pour garantir la clarté, la correction et la complexité analytique.
   • Insights : Extraits de rapports d'experts du domaine en utilisant des LLM (NotebookLM, Gemini) pour structurer les conclusions en phrases déclaratives et résumés, suivis d'une vérification manuelle.

Configuration expérimentale

Les auteurs ont évalué une gamme diversifiée de modèles, incluant des LLM open-source (Llama 3.1, Qwen3, DeepSeek-R1), des modèles de table spécialisés (TableGPT2), et des modèles propriétaires de pointe (GPT-4o, GPT-5.1, Claude Sonnet 4.6, Gemini 2.5 Flash).

Deux cadres d'évaluation ont été testés :

1. LLM Direct : Les modèles génèrent des réponses directement.
2. Frameworks Agentiques :
   • Agent de Réponse (Answer Agent) : Un agent modulaire comprenant la sérialisation, la génération de code avec auto-correction, et un module de réflexion (utilisant un VLM/MLLM pour la validation visuelle).
   • Agent d'Aperçu (Insight Agent) : Une extension du framework AgentPoirot, utilisant une structure de graphe orienté acyclique dirigé (DAG) pour générer de manière itérative des questions, des réponses et des aperçus, en agrégeant le contexte de tous les nœuds précédents plutôt qu'une simple structure d'arbre.

Les métriques d'évaluation comprenaient l'Exact Match (EM) pour le texte, le MLLM-as-a-judge pour les visualisations, et les scores LLaMA-3-Eval (adaptés pour GPT-4o) pour la qualité des aperçus, mesurés tant au niveau du résumé qu'au niveau des aperçus individuels.

Résultats clés

Des expériences approfondies révèlent des écarts de performance significatifs, indiquant que les systèmes actuels sont loin de satisfaire les demandes d'analyse de données du monde réel :

• Faible précision : Même les modèles propriétaires les plus performants avec un support agentique atteignent des scores absolus faibles. Dans le cadre "Whole" de la Table QA (nécessitant que toutes les sous-questions soient correctes), le meilleur score est inférieur à 0,4. Pour la Table Insight, les meilleurs modèles scorent moins de 0,35 pour l'alignement au niveau de l'aperçu et moins de 0,5 pour l'alignement au niveau du résumé.

• Support Agentique : Bien que les frameworks agentiques (Answer Agent) améliorent les performances par rapport aux LLM de base (par exemple, une amélioration relative d'environ 27 % pour Gemini 2.5 Flash en QA), les gains sont insuffisants pour surmonter la difficulté du benchmark.

• Comparaison de modèles : Les modèles open-source accusent un retard important par rapport à leurs homologues propriétaires. Les modèles de table spécialisés (TableGPT2-7B) ont mal performé (score < 0,1), suggérant que les capacités de raisonnement général sont actuellement plus critiques que le pré-entraînement spécifique aux tables pour ces tâches complexes.

• Analyse d'erreurs :

  • Table QA : Les erreurs les plus fréquentes étaient les Erreurs de Filtre de Condition (32,4 %, par exemple, l'échec à éviter les doubles comptages) et les Erreurs de Transformation (23,2 %, par exemple, le parsing des formats de date/heure ou la conversion de chaînes de caractères numériques). Les modèles ont également eu des difficultés avec la gestion du contexte dans les scénarios multi-tours et la sélection de la bonne table à partir des métadonnées dans les jeux de données multi-tables.
  • Table Insight : Bien que les agents aient performé raisonnablement bien sur la Pertinence Thématique, ils ont fréquemment échoué sur l'Alignement Narratif et la Correspondance des Détails Qualitatifs. Crucialement, les agents ont totalement échoué sur la Correspondance des Détails Quantitatifs, étant incapables de calculer ou de présenter avec précision des valeurs numériques spécifiques dans leurs analyses générées.

• Résultats d'ablation :

  • Sérialisation vs Lignes Brutes : Fournir plus de lignes brutes (jusqu'à 200) a dégradé les performances par rapport à la ligne de base de 10 lignes. En revanche, la sérialisation spécifique au type de caractéristique a considérablement amélioré les performances en fournissant une représentation compacte et fiable.
  • SQL vs Python : Les approches Text-to-SQL ont performé nettement moins bien que la génération de code Python pour ce benchmark, avec des taux plus élevés d'erreurs de syntaxe et de sélection de colonnes.

Signification et Revendications

L'article affirme que DataGovBench fournit un benchmark exigeant et réaliste qui expose les limites des systèmes d'analyse de données basés sur les LLM. Ses principales contributions sont :

1. Réalisme : C'est le premier benchmark qui combine de manière holistique des QA décomposables et complexes ainsi que la génération d'aperçus avec des jeux de données à grande échelle et multi-tabulaires nécessitant des métadonnées et des connaissances externes.
2. Identification de l'écart de performance : Il démontre que même les modèles de pointe, qu'ils soient autonomes ou agentiques, luttent avec les nuances de l'analyse de données du monde réel, particulièrement en ce qui concerne le raisonnement de niveau narratif et la récupération précise de faits à partir de tables complexes.
3. Feuille de route de recherche : À travers une analyse qualitative détaillée, les auteurs identent des modes de défaillance spécifiques (par exemple, l'incapacité à synthétiser des arguments centraux, les erreurs de calcul quantitatif) et des capacités manquantes, offrant un guide clair pour que la communauté se concentre sur la recherche de futurs agents capables de gérer les complexités des données réelles.

Les auteurs concluent que, bien que les LLM aient déplacé le paradigme de l'interaction humain-donnée, des avancées significatives sont nécessaires avant que ces systèmes ne puissent satisfaire de manière autonome les exigences de l'analyse de données professionnelle.