Exploiter les LLM pour une annotation efficace des données tabulaires

Les données tabulaires sont partout dans nos vies quotidiennes et en ligne, mais étiqueter ces données a souvent nécessité beaucoup d'efforts humains, ce qui rend difficile l'évolutivité pour les tâches d'apprentissage automatique. Cet article présente une nouvelle façon d'utiliser des grands modèles de langage (LLMs) pour aider à comprendre et étiqueter les données tabulaires.

Avec notre méthode, on peut rapidement et facilement étiqueter une énorme quantité de données tabulaires. On peut personnaliser la manière dont l'étiquetage est fait en fonction de besoins spécifiques, en le démontrant avec des exemples comme la création de requêtes SQL et l'identification des colonnes d'entrée-cible dans les tableaux. On partage un ensemble de données appelé AnnotatedTables, qui contient 32,119 bases de données avec des annotations réalisées par des LLMs. Cela inclut 405,616 programmes SQL valides, faisant de cet ensemble de données le plus grand lié aux données tabulaires permettant de tester des requêtes.

Pour montrer à quel point nos méthodes et notre ensemble de données sont utiles, on a réalisé deux études complémentaires.

1. On a regardé si les LLMs pouvaient transformer des programmes SQL en un autre langage de programmation appelé Rel, que les LLMs n'avaient pas appris auparavant, tout en obtenant les mêmes résultats. En ajustant nos prompts en fonction des retours d'exécution, on a constaté que les LLMs pouvaient faire des traductions correctes avec juste quelques exemples.

2. On a évalué les performances d'un modèle de réseau de neurones, TabPFN, sur 2,720 tableaux avec des colonnes d'entrée-cible qui avaient été identifiées et étiquetées par des LLMs. Dans l'ensemble, TabPFN a eu des résultats similaires à une méthode de référence, mais les résultats pouvaient varier énormément d'un tableau de données à l'autre, donc les deux modèles peuvent être utiles selon la situation.

Notre travail met en évidence à quel point les LLMs peuvent être efficaces pour rationaliser le processus d'étiquetage de grandes quantités de données tabulaires diverses.

Les données tabulaires sont l'une des formes de données les plus courantes, utilisées dans des domaines comme la finance, la santé et le marketing. Le format tabulaire nous permet d'organiser des données structurées dans des bases de données relationnelles. Les modèles d'apprentissage automatique peuvent alors comprendre et créer des requêtes SQL pour ces bases de données, et les LLMs sont devenus une méthode clé dans cet espace. Des études récentes montrent que les LLMs peuvent exceller dans la génération de SQL avec des prompts bien conçus grâce à la vaste quantité de code SQL open source sur laquelle ils ont été formés.

Cependant, avoir du code SQL seul n'est pas suffisant pour tous les défis d'apprentissage automatique tabulaires. Par exemple, lors de l'évaluation de la capacité d'un modèle à traduire du texte en SQL, les données tabulaires et le code SQL sont nécessaires pour mesurer le taux de réussite. Bien qu'on puisse avoir beaucoup de code SQL ou de données tabulaires, rassembler les deux en même temps peut s'avérer assez difficile.

Ce problème mène à ce qu'on appelle le problème d'annotation des ensembles de données tabulaires. Des ensembles de données populaires comme WikiSQL et Spider ont des tailles limitées car les méthodes par lesquelles ils ont été étiquetés ne s'échelonnent pas pour exploiter les vastes quantités de données tabulaires ou de code SQL disponibles en ligne. WikiSQL collecte ses données tabulaires à partir de Wikipedia, une source contraignante qui ne capture pas les complexités des données tabulaires du monde réel. Ses programmes SQL sont annotés manuellement via un service appelé Amazon Mechanical Turk, et dans WikiSQL, chaque programme SQL ne consulte qu'une seule table à la fois sans joindre de tables.

En revanche, Spider inclut des requêtes plus complexes à travers plusieurs tables, mais il dépend aussi d'un petit groupe d'étudiants pour les annotations. L'annotation humaine est coûteuse et prend du temps, rendant difficile l'expansion de ces ensembles de données.

Des travaux récents ont montré que les LLMs peuvent générer avec succès du code SQL à partir d'instructions, nous poussant à nous demander si les LLMs peuvent également étiqueter d'autres types de données et remplacer l'annotation humaine coûteuse pour les ensembles de données tabulaires. Inspirés par la capacité des LLMs à réaliser plusieurs tâches, nous voyons un potentiel dans la résolution du problème d'annotation des ensembles de données tabulaires.

Cet article introduit AnnotatedTables, un ensemble de données tabulaire à grande échelle rempli d'annotations LLM. Pour éviter le goulet d'étranglement des annotations humaines consommatrices de temps, nous utilisons des LLMs pour interpréter les données tabulaires et produire des labels synthétiques. Notre ensemble de données inclut des données tabulaires variées vues dans des applications du monde réel tout en étant suffisamment général pour d'autres sources de données.

Grâce à une conception soignée des prompts, nous guidons les LLMs pour créer du code SQL sans exemples préalables, et cette approche s'est révélée rapide et rentable pour construire un ensemble de données complet sans dépendre des efforts humains. Pour garantir la qualité du code SQL généré par le LLM, nous le validons en exécutant les requêtes sur les données tabulaires, confirmant les résultats de ces requêtes SQL générées.

AnnotatedTables est désormais la plus grande collection de code SQL exécutable lié aux données tabulaires correspondantes. Les programmes SQL ne sont pas les seules annotations que les LLMs peuvent fournir. Certaines colonnes de table peuvent servir d'entrée pour des prédictions, et les LLMs peuvent être utilisés pour identifier ces relations entrée-cible, les rendant utilisables pour la classification tabulaire.

Notre travail démontre comment les LLMs peuvent simplifier et automatiser le processus de création d'ensembles de données tabulaires. Pour valider l'utilité et la qualité de notre ensemble de données, nous avons réalisé deux études supplémentaires. Tout d'abord, nous avons examiné la capacité des LLMs à apprendre un nouveau langage de programmation par le biais d'exemples. Deuxièmement, nous avons élargi une évaluation d'un modèle de classification récent, TabPFN, en utilisant des données réelles diverses. Les deux études soulignent comment l'annotation par LLM peut adapter notre ensemble de données pour répondre à des objectifs de recherche spécifiques.

En résumé, les principales contributions de notre travail sont les suivantes :

• Nous présentons des méthodes utilisant l'apprentissage en contexte avec des LLMs pour comprendre et annoter un grand volume de données tabulaires du monde réel, s'attaquant efficacement aux défis des annotations humaines traditionnelles.
• Nous introduisons un ensemble de données interdomaines, AnnotatedTables, qui est actuellement le plus grand ensemble de données SQL avec des données tabulaires capables d'exécution.
• Nous évaluons la qualité des annotations générées par les LLMs de manière exhaustive tout au long de notre recherche et démontrons le potentiel de recherche d'AnnotatedTables à travers deux études complémentaires.
• Nous introduisons une technique appelée Ingénierie de Prompt Incrémentale pour enseigner aux LLMs comment traduire SQL en programmes Rel avec une précision adéquate, même pour un langage que les LLMs n'avaient pas été formés auparavant.
• Nous utilisons les colonnes d'entrée-cible identifiées et annotées par des LLMs pour évaluer les performances de TabPFN sur diverses tâches de classification tabulaire.

Dans la section des travaux connexes, nous discutons de l'intersection des systèmes de bases de données et de l'apprentissage profond. Les modèles de langage peuvent être formés pour générer des requêtes SQL à partir de descriptions en langage naturel. De plus, les réseaux de neurones peuvent être utilisés pour estimer le nombre de lignes retournées par des requêtes, mettant en œuvre des optimisations. D'autres applications d'apprentissage profond liées aux bases de données incluent la réponse à des requêtes et la détection d'anomalies.

Tous ces domaines pourraient bénéficier d'un grand ensemble de données multi-domaines comme AnnotatedTables. Les annotations LLM peuvent être utilisées pour acquérir de grands ensembles de données d'entraînement au format tabulaire, vitaux pour des tâches comme la génération de texte vers SQL et l'estimation de cardinalité. Le support de notre ensemble de données pour l'exécution des requêtes est nécessaire pour ces tâches afin de valider leur précision.

Actuellement, la plupart des ensembles de données SQL courants reposent sur des annotations humaines, alors que notre approche est la première à créer un ensemble de données tabulaire annoté par des LLMs. Cette innovation nous permet de générer un volume significatif d'annotations qui correspondent ou même dépassent ce qui est disponible sur le web. Bien que les ensembles de données SQL existants contiennent souvent des descriptions en anglais, nous n'évaluons pas ou ne garantissons pas leur qualité, car les programmes SQL peuvent être validés par exécution, tandis que les descriptions en anglais ne le peuvent pas.

Les LLMs ont également été précédemment appliqués à l'annotation de données dans des champs de texte, souvent avec des performances supérieures à celles des annotateurs humains. Ils peuvent détecter des discours nuisibles et fournir des explications en langage naturel en tant qu'annotations nécessaires. De plus, les LLMs sont utilisés pour évaluer la génération de langage naturel, s'alignant étroitement avec les évaluations humaines.

Pour construire notre ensemble de données, nous commençons par collecter des données tabulaires publiques. Notre objectif est de tirer parti de la richesse des données non annotées disponibles en ligne, en se concentrant sur des tableaux soigneusement sélectionnés à partir d'applications concrètes en science des données. Nous avons constaté que Kaggle, une plateforme de science des données, répond bien à nos critères. Kaggle héberge des tableaux qui sont crowdsourcés par une communauté d'enthousiastes et de professionnels des données. Les utilisateurs peuvent partager et analyser des ensembles de données sur une large gamme de sujets du monde réel.

Les évaluations et les avis des utilisateurs contribuent à la curation de données utilisables et fiables. Bien que des ensembles de données individuels de Kaggle aient été étudiés dans des recherches antérieures, notre approche agrège et examine ces données collectivement, révélant une collection substantielle et diversifiée de données de qualité. En utilisant l'API publique de Kaggle, nous avons recherché des ensembles de données entre 10 mégaoctets et 1 gigaoctet pour garantir une collecte et un traitement des données plus rapides. Nous avons également veillé à ce que chaque ensemble de données respecte une note minimale d'utilisabilité pour filtrer les ensembles de données de mauvaise qualité. Au total, nous avons collecté 70,000 ensembles de données Kaggle pour un traitement ultérieur.

La méthode que nous avons utilisée pour annoter les données avec des LLMs est à la fois flexible et automatisée, et peut potentiellement être appliquée à d'autres sources au-delà des ensembles de données Kaggle.

Pour aider les LLMs à interpréter les données tabulaires, nous avons développé une description textuelle pour chaque base de données dans le cadre du prompt. Comme utiliser des tables entières dans un prompt pourrait dépasser les limites d'entrée des LLMs, nous avons opté pour des descriptions plus courtes qui incluent le schéma de base et des lignes d'exemple. Le schéma décrit la structure de la table, en listant le nom de la table, les noms des colonnes et le type de données de chaque colonne.

Pour extraire le schéma, nous avons découvert que les données tabulaires étaient stockées dans des fichiers CSV au sein des ensembles de données Kaggle. Étant donné que les fichiers CSV ne contiennent pas de noms de table, nous avons utilisé les noms de fichiers à cette fin. La ligne d'en-tête des fichiers CSV fournissait les noms des colonnes. Notre inspection initiale a révélé que les noms de colonnes et les noms de fichiers sont généralement clairs et descriptifs, permettant au LLM d'interpréter facilement les informations de la table.

Un logiciel d'analyse de données existant appelé pandas a été utilisé pour charger les tables et dériver les types de données des colonnes. Notre méthode d'extraction de schéma s'est révélée efficace et pratique. Certains ensembles de données Kaggle peuvent inclure plusieurs tables, nécessitant la création de plusieurs schémas. Ensemble, ces schémas décrivent la structure de la base de données, indiquant combien de tables existent, les colonnes et types au sein de ces tables, et si une colonne pourrait servir de clé de JOIN.

Des lignes d'exemple de la table sont également cruciales, permettant aux LLMs de construire des requêtes SQL efficacement, comme des instructions WHERE pour filtrer les données. Par exemple, dans une requête comme SELECT * FROM CUSTOMERS WHERE COUNTRY='MEXICO', le nom de la table et le nom de la colonne peuvent être dérivés du schéma, tandis que la valeur 'MEXICO' serait trouvée dans une ligne de la table. Ainsi, nous fournissons des lignes d'exemple avec le schéma afin que les LLMs puissent créer des instructions WHERE en SQL de manière précise.

Pour la ligne d'exemple, nous avons sélectionné la première ligne de chaque table et l'avons convertie en un format textuel pour le LLM. Nos descriptions de schéma et de ligne d'exemple sont suffisamment larges pour qu'elles puissent être utilisées pour presque toutes les formes de données tabulaires.

À travers l'apprentissage zero-shot, nous avons dirigé les LLMs pour générer du code SQL qui interroge nos tables collectées, ce qui est l'un des types d'annotation. Actuellement, ChatGPT d'OpenAI est l'un des LLMs les plus efficaces pour diverses tâches, et nous avons choisi de l'utiliser comme notre LLM d'annotation.

Lors de la génération de SQL pour chaque base de données, nous créons un prompt comprenant des instructions, le schéma de la base de données et la ligne d'exemple de chaque table. L'instruction demande au LLM de produire des requêtes SQL "que des utilisateurs typiques pourraient écrire pour accéder à cette base de données." Elle demande également des requêtes plus complexes pour améliorer la valeur de l'ensemble de données, en encourageant particulièrement plus de JOINs lorsque plusieurs tables sont disponibles.

Pour chaque ensemble de données Kaggle avec des données tabulaires, nous avons demandé au LLM de générer quinze annotations de programmes SQL avec des explications en langage naturel.

Certains programmes SQL générés peuvent être incorrects, donc nous avons mis en place un système pour vérifier la qualité de ces annotations. Puisqu'AnnotatedTables a accès aux données tabulaires, nous avons validé les programmes SQL en les exécutant. Si un programme SQL s'exécute et retourne des résultats non vides, nous le considérons valide. Les programmes qui retournent des résultats vides sont marqués comme tels. Pour garantir des comparaisons précises lors de notre étude complémentaire sur la traduction SQL-vers-Rel, nous n'utilisons pas de requêtes SQL qui retournent des résultats vides.

Nous avons reconnu dans notre recherche que nous ne validons pas les descriptions en anglais générées par le LLM. Tous les artefacts de données intermédiaires sont rendus publics dans le cadre d'AnnotatedTables.

En examinant la qualité des annotations, nous avons constaté que les LLMs pouvaient créer des programmes SQL reflétant efficacement l'intention humaine. Nous avons trouvé un pourcentage élevé (82.25%) de programmes SQL valides, indiquant une bonne qualité globale. Le LLM pouvait créer des requêtes complexes comportant une gamme de composants SQL.

Dans presque toutes les catégories de composants SQL sauf les JOINs, les pourcentages de requêtes valides dépassaient 50%. Cependant, les requêtes de JOIN n'ont atteint qu'un taux de validité de 49.47%, ce qui pourrait indiquer un besoin de compréhension plus approfondie ou de compétences en programmation lors de la jonction de plusieurs tables.

Nous avons noté que certaines instructions SQL simples apparaissaient fréquemment, comme SELECT * FROM table, qui représentaient une grande partie (48.4%) des programmes SQL valides. Bien que ces instructions soient valides, elles sont moins informatives que des requêtes plus compliquées pour un apprentissage ultérieur.

Dans nos prompts, nous avons dirigé le LLM à créer des programmes SQL "avec une complexité relativement élevée," atteignant un certain succès. Cependant, l'objectif contradictoire de créer des requêtes complexes et correctes peut amener les LLMs à produire des requêtes plus simples pour maintenir la précision.

Comme montré, des annotations SQL invalides peuvent surgir pour diverses raisons. Parfois, le LLM crée des noms de tables inexistants ou laisse du texte de remplacement, ou dans certains fichiers CSV, les noms de colonnes peuvent être numériques, ce qui est invalide dans les requêtes SQL. De plus, bien que certains programmes SQL corrects puissent retourner des résultats vides, ils sont étiquetés comme invalides aux fins de mesure de précision d'exécution.

Nous avons utilisé AnnotatedTables pour étudier la capacité des LLMs à apprendre un nouveau langage de programmation, Rel.

Étant donné qu'il existe peu d'exemples de code Rel open source disponibles, nous nous sommes tournés vers l'apprentissage en contexte à quelques exemples comme solution naturelle. Bien que l'ICL ait été étudié, traduire entre deux langages de programmation distincts est un défi de recherche unique.

Tous les programmes SQL dans AnnotatedTables peuvent être exécutés, ce qui permet d'évaluer efficacement la précision de la traduction. Les programmes SQL imitent l'utilisation typique des bases de données, et traduire ces requêtes nous permet de créer un ensemble de données substantiel de programmes Rel précieux pour des recherches ultérieures.

Dans l'apprentissage d'un nouveau langage de programmation, obtenir suffisamment de données d'entraînement peut être un défi. Nos résultats indiquent que la précision de la traduction s'améliore régulièrement avec plus d'exemples en contexte, atteignant environ 40% de précision avec 45 exemples de traduction.

Pour formuler la tâche de traduction SQL-vers-Rel, nous commençons par un programme SQL exécutable qui fonctionne sur une table spécifique. Notre objectif est de développer un modèle capable de traduire le programme SQL en un programme Rel, en veillant à ce que les deux produisent les mêmes résultats de requête lorsqu'ils sont exécutés sur la même table.

La précision d'exécution mesure à quelle fréquence les programmes SQL et Rel traduits produisent les mêmes résultats non vides. Cependant, comparer directement les programmes SQL et Rel peut être difficile en raison des différences inhérentes entre les langages.

Pour améliorer les capacités de traduction, nous avons introduit une technique appelée Ingénierie de Prompt Incrémentale (IPE), qui utilise des retours d'exécution pour affiner les exemples de traduction appris. Nous avons commencé avec quelques exemples initiaux de traduction SQL-vers-Rel, en instruisant le modèle de langage à traduire des programmes SQL non vus, et avons calculé la précision d'exécution pour chaque étape.

Le retour d'expérience nous permet d'identifier où le LLM échoue à traduire et d'ajouter ces exemples à la prochaine série d'entraînement, augmentant progressivement le nombre d'exemples jusqu'à atteindre une précision de traduction satisfaisante.

À travers le processus IPE, nous avons observé une précision de traduction améliorée à mesure que nous ajoutions plus d'exemples. Une fois que nous avons dépassé 30 exemples, les exemples supplémentaires ont offert des retours décroissants, convergeant autour de 40% de précision.

Pour notre évaluation de TabPFN, nous avons utilisé AnnotatedTables pour tester ses performances de classification sur de nombreux ensembles de données divers. TabPFN est un nouveau type de réseau de neurones formé avec des données synthétiques tirées d'un a priori bayésien.

Une fois entraîné, il traite toutes les données à la fois, faisant des prédictions en un seul passage avant. Étant donné ses résultats avancés dans des benchmarks plus petits, nous étions curieux de voir comment TabPFN se mesurerait aux complexités des données tabulaires du monde réel.

TabPFN est comparé aux méthodes standard et à quelques cadres AutoML de premier plan, utilisant divers ensembles de données pour évaluer sa résilience. En étendant notre évaluation à 2,720 problèmes de classification, nous dépassons largement les benchmarks précédents.

Dans notre configuration expérimentale, nous maintenons les mêmes paramètres que les auteurs originaux pour TabPFN et formons AutoGluon en utilisant une limite de temps d'une ou cinq minutes, en ne divisant les données qu'une seule fois par table pour gagner du temps.

Nous nous appuyons sur les annotations LLM pour identifier les colonnes d'entrée et cibles appropriées au sein des ensembles de données Kaggle pour TabPFN. Ce processus garantit que les colonnes d'entrée sont numériques tandis que la cible est catégorique pour une classification efficace.

Dans nos résultats, TabPFN montre de solides performances sur les 2,720 problèmes de classification testés, avec quelques résultats significatifs comparés à AutoGluon, démontrant que les LLMs peuvent identifier avec précision les colonnes d'entrée-cible et la structure tabulaire nécessaire pour des tâches de classification efficaces.

Enfin, l'utilisation d'AnnotatedTables a mis en évidence le potentiel des LLMs à révolutionner la façon dont nous créons des ensembles de données pour l'apprentissage automatique. La capacité d'utiliser des LLMs pour automatiser le processus d'annotation peut réduire les coûts et faciliter l'accès des chercheurs aux données personnalisées dont ils ont besoin pour leurs projets spécifiques, ouvrant la voie à de nouvelles avenues en science des données.