Aproveitando LLMs para Anotação Eficiente de Dados Tabulares

Dados tabulares estão em todo lugar na nossa vida diária e online, mas rotular esses dados muitas vezes exige muito esforço humano, dificultando a escalabilidade para tarefas de aprendizado de máquina. Este artigo apresenta uma nova maneira de usar Modelos de Linguagem Grande (LLMs) para ajudar a entender e rotular dados tabulares.

Com nosso método, conseguimos rotular rapidamente e facilmente uma grande quantidade de dados tabulares. Podemos personalizar como o rotulamento é feito com base em necessidades específicas, demonstrando isso com exemplos como a criação de consultas SQL e identificação de colunas de entrada e alvo em tabelas. Estamos compartilhando um conjunto de dados chamado AnnotatedTables, que contém 32.119 bancos de dados com anotações feitas por LLMs. Isso inclui 405.616 programas SQL válidos, tornando-o o maior conjunto de dados SQL vinculado a dados tabulares que permite testes de consultas.

Para mostrar quão úteis são nossos métodos e nosso conjunto de dados, realizamos dois estudos de acompanhamento.

1. Analisamos se os LLMs podiam converter programas SQL para uma linguagem de programação diferente chamada Rel, que os LLMs não tinham aprendido antes, mas ainda assim obtendo os mesmos resultados. Ajustando nossos prompts com base no feedback da execução, descobrimos que os LLMs podiam fazer traduções decentes com apenas alguns exemplos.

2. Avaliamos como um modelo de rede neural, o TabPFN, se saiu em 2.720 tabelas com colunas de entrada-alvo que haviam sido identificadas e rotuladas por LLMs. No geral, o TabPFN teve um desempenho semelhante a um método base, mas os resultados podiam diferir muito de uma tabela de dados para outra, então ambos os modelos podem ser úteis dependendo da situação.

Nosso trabalho destaca quão eficazes os LLMs podem ser em simplificar o processo de rotulagem de grandes quantidades de dados tabulares diversos.

Dados tabulares são uma das formas mais comuns de dados, usados em áreas como finanças, saúde e marketing. O formato tabular nos permite organizar dados estruturados em bancos de dados relacionais. Modelos de aprendizado de máquina podem então entender e criar consultas SQL para esses bancos de dados, e os LLMs se tornaram um método chave nesse espaço. Estudos recentes mostram que os LLMs podem se sair bem na geração de SQL com prompts bem elaborados devido à grande quantidade de código SQL de código aberto que foram treinados.

No entanto, ter apenas código SQL não é suficiente para todos os desafios de aprendizado de máquina tabulares. Por exemplo, ao testar quão bem um modelo pode traduzir texto para SQL, tanto os dados tabulares quanto o código SQL são necessários para medir a taxa de sucesso. Embora possamos ter muitos de ambos, código SQL ou dados tabulares, reunir os dois ao mesmo tempo pode ser bem desafiador.

Esse problema leva ao que chamamos de problema de anotação de conjuntos de dados tabulares. Conjuntos de dados populares anteriores, como WikiSQL e Spider, têm tamanhos limitados porque as maneiras como foram rotulados não escalam para explorar as vastas quantidades de dados tabulares ou código SQL disponíveis online. O WikiSQL coleta seus dados tabulares da Wikipedia, uma fonte restrita que não captura as complexidades dos dados tabulares do mundo real. Seus programas SQL são anotados manualmente através de um serviço chamado Amazon Mechanical Turk, e no WikiSQL, cada programa SQL consulta apenas uma tabela de cada vez, sem juntar tabelas.

Em contraste, o Spider inclui consultas mais complexas em várias tabelas, mas também depende de um pequeno grupo de estudantes universitários para anotações. A anotação humana é cara e demorada, dificultando a expansão desses conjuntos de dados.

Trabalhos recentes mostraram que os LLMs podem gerar com sucesso código SQL a partir de instruções, nos levando a considerar se os LLMs também podem rotular outros tipos de dados e substituir a rotulagem humana cara para conjuntos de dados tabulares. Inspirados pela capacidade dos LLMs de realizar múltiplas tarefas, vemos promessas em abordar o problema de anotação de conjuntos de dados tabulares.

Este artigo apresenta o AnnotatedTables, um conjunto de dados tabular em grande escala repleto de anotações de LLM. Para evitar o gargalo de anotações humanas demoradas, usamos LLMs para interpretar dados tabulares e produzir rótulos sintéticos. Nosso conjunto de dados inclui dados tabulares variados vistos em aplicações do mundo real, além de ser geral o suficiente para outras fontes de dados.

Através do design cuidadoso de prompts, orientamos os LLMs a criar código SQL sem exemplos prévios, e essa abordagem se mostrou uma maneira rápida e econômica de construir um conjunto de dados abrangente sem depender do esforço humano. Para garantir a qualidade do código SQL gerado pelo LLM, validamos executando as consultas nos dados tabulares, confirmando os resultados dessas consultas SQL geradas.

O AnnotatedTables é agora a maior coleção de código SQL executável relacionado aos dados tabulares correspondentes. Programas SQL não são as únicas anotações que os LLMs podem fornecer. Algumas colunas da tabela podem servir como entrada para previsões, e os LLMs podem ser usados para identificar esses relacionamentos de entrada-alvo, tornando-os utilizáveis para classificação tabular.

Nosso trabalho demonstra como os LLMs podem simplificar e automatizar o processo de criação de conjuntos de dados tabulares. Para validar a utilidade e a qualidade do nosso conjunto de dados, realizamos dois estudos adicionais. Primeiro, examinamos a capacidade dos LLMs de aprender uma nova linguagem de programação através de exemplos. Em segundo lugar, ampliamos uma avaliação de um modelo de classificação recente, o TabPFN, usando dados diversos do mundo real. Ambos os estudos destacam como a anotação por LLM pode adaptar nosso conjunto de dados para atender a objetivos de pesquisa específicos.

Em resumo, as principais contribuições do nosso trabalho são as seguintes:

• Apresentamos métodos usando aprendizado em contexto com LLMs para entender e anotar um grande volume de dados tabulares do mundo real, abordando efetivamente os desafios das anotações humanas tradicionais.
• Introduzimos um conjunto de dados interdomínio, o AnnotatedTables, que atualmente é o maior conjunto de dados SQL com dados tabulares executáveis.
• Avaliamos a qualidade das anotações geradas pelos LLMs de forma abrangente ao longo de nossa pesquisa e demonstramos o potencial de pesquisa do AnnotatedTables através de dois estudos de acompanhamento.
• Introduzimos uma técnica chamada Engenharia de Prompt Incremental para ensinar os LLMs a traduzir SQL para programas Rel com precisão adequada, mesmo para uma linguagem que os LLMs não haviam sido treinados previamente.
• Utilizamos as colunas de entrada-alvo identificadas e anotadas por LLMs para avaliar o desempenho do TabPFN em várias tarefas de classificação tabular.

Na seção de trabalhos relacionados, discutimos a interseção de sistemas de banco de dados e aprendizado profundo. Modelos de linguagem podem ser treinados para gerar consultas SQL a partir de descrições em linguagem natural. Além disso, redes neurais podem ser usadas para estimar o número de linhas retornadas por consultas, implementando otimizações. Outras aplicações de aprendizado profundo relacionadas a bancos de dados incluem resposta a consultas e detecção de anomalias.

Todas essas áreas poderiam se beneficiar de um grande conjunto de dados multi-domínio como o AnnotatedTables. As anotações dos LLMs podem ser usadas para adquirir grandes conjuntos de dados de treinamento em formato tabular, vitais para tarefas como geração de texto para SQL e estimativa de cardinalidade. O suporte do nosso conjunto de dados para executar consultas é necessário para que essas tarefas validem sua precisão.

Atualmente, a maioria dos conjuntos de dados SQL comuns depende de anotações humanas, enquanto nossa abordagem é a primeira a criar um conjunto de dados tabular anotado por LLMs. Essa inovação nos permite gerar um volume significativo de anotações que correspondem ou até superam o que está disponível na web. Embora os conjuntos de dados SQL existentes frequentemente contenham descrições em inglês, não avaliamos nem garantimos sua qualidade, já que programas SQL podem ser validados por execução, enquanto descrições em inglês não podem.

Os LLMs também foram aplicados anteriormente à anotação de dados em campos de texto, geralmente apresentando desempenho melhor do que anotadores humanos. Eles podem detectar discurso prejudicial e fornecer explicações em linguagem natural como anotações necessárias. Além disso, os LLMs são usados para avaliar a geração de linguagem natural, alinhando-se de perto com as avaliações humanas.

Na construção do nosso conjunto de dados, começamos coletando dados tabulares públicos. Nosso objetivo é aproveitar a riqueza de dados não anotados disponíveis online, focando em tabelas organizadas a partir de aplicações práticas de ciência de dados. Descobrimos que o Kaggle, uma plataforma de ciência de dados, atende bem aos nossos critérios. O Kaggle hospeda tabelas que são coletadas pela comunidade de entusiastas e profissionais de dados. Os usuários podem compartilhar e analisar conjuntos de dados sobre uma ampla gama de tópicos do mundo real.

Classificações e percepções dos usuários contribuem para a curadoria de dados utilizáveis e confiáveis. Embora conjuntos de dados individuais do Kaggle tenham sido estudados em pesquisas anteriores, nossa abordagem agrega e examina esses conjuntos coletivamente, revelando uma coleção substancial e diversificada de dados de qualidade. Usando a API pública do Kaggle, buscamos conjuntos de dados entre 10 megabytes e 1 gigabyte para garantir uma coleta e processamento de dados mais rápidos. Também garantimos que cada conjunto de dados atendesse a uma classificação mínima de usabilidade para filtrar conjuntos de baixa qualidade. No total, coletamos 70.000 conjuntos de dados do Kaggle para processamento posterior.

O método que usamos para anotar dados com LLMs é tanto flexível quanto automatizado, e pode ser potencialmente aplicado a outras fontes além dos conjuntos de dados do Kaggle.

Para ajudar os LLMs a interpretar dados tabulares, desenvolvemos uma descrição textual para cada banco de dados como parte do prompt. Como usar tabelas inteiras em um prompt pode exceder os limites de entrada do LLM, optamos por descrições mais curtas que incluam o esquema básico e linhas de exemplo. O esquema descreve a estrutura da tabela, listando o nome da tabela, os nomes das colunas e o tipo de dados de cada coluna.

Para extrair o esquema, descobrimos que os dados tabulares estavam armazenados em arquivos CSV dentro dos conjuntos de dados do Kaggle. Como os arquivos CSV não contêm nomes de tabelas, confiamos nos nomes dos arquivos para esse propósito. A linha de cabeçalho dos arquivos CSV forneceu os nomes das colunas. Nossa inspeção inicial revelou que os nomes das colunas e os nomes dos arquivos são geralmente claros e descritivos, permitindo que o LLM interprete facilmente as informações da tabela.

Um software de análise de dados existente chamado pandas foi empregado para carregar as tabelas e derivar os tipos de dados das colunas. Nosso método de extração de esquema se mostrou eficaz e prático. Alguns conjuntos de dados do Kaggle podem incluir várias tabelas, exigindo a criação de múltiplos esquemas. Juntos, esses esquemas delineiam a estrutura do banco de dados, indicando quantas tabelas existem, as colunas e tipos dentro dessas tabelas, e se alguma coluna pode servir como uma chave de JUNÇÃO.

Linhas de exemplo da tabela também são cruciais, permitindo que os LLMs construam consultas SQL de forma eficaz, como declarações WHERE para filtrar dados. Por exemplo, em uma consulta como SELECT * FROM CUSTOMERS WHERE COUNTRY='MEXICO', o nome da tabela e o nome da coluna podem ser derivados do esquema, enquanto o valor 'MEXICO' seria encontrado em uma linha da tabela. Assim, fornecemos linhas de exemplo juntamente com o esquema para que os LLMs possam criar declarações WHERE em SQL com precisão.

Para a linha de exemplo, escolhemos a primeira linha de cada tabela e a convertendo em um formato textual para o LLM. Nossas descrições de esquema e linha de exemplo são amplas o suficiente para que possam ser usadas para quase todas as formas de dados tabulares.

Através do aprendizado zero-shot, orientamos os LLMs a gerar código SQL que consulta nossas tabelas coletadas, que é um dos tipos de anotação. Atualmente, o ChatGPT da OpenAI está entre os LLMs mais eficientes para várias tarefas, e escolhemos usá-lo como nosso LLM de anotação.

Ao gerar SQL para cada banco de dados, criamos um prompt que inclui instruções, o esquema do banco de dados e a linha de exemplo de cada tabela. A instrução pede ao LLM para produzir consultas SQL "que usuários típicos possam escrever para acessar este banco de dados." Ela também solicita consultas mais complexas para melhorar o valor do conjunto de dados, especialmente incentivando mais JUNÇÕES quando várias tabelas estão disponíveis.

Para cada conjunto de dados do Kaggle com dados tabulares, pedimos ao LLM para gerar quinze anotações de programas SQL junto com explicações em linguagem natural.

Alguns programas SQL gerados podem estar incorretos, então estabelecemos um sistema para verificar a qualidade dessas anotações. Como o AnnotatedTables tem acesso aos dados tabulares, validamos os programas SQL executando-os. Se um programa SQL roda e retorna resultados não vazios, consideramos válido. Programas que retornam resultados vazios são marcados como tais. Para garantir comparações precisas durante nosso estudo de acompanhamento sobre tradução SQL-Rel, não usamos consultas SQL que retornam resultados vazios.

Reconhecemos em nossa pesquisa que não validamos as descrições em inglês geradas pelo LLM. Todos os artefatos de dados intermediários são tornados públicos como parte do AnnotatedTables.

Ao examinar a qualidade das anotações, descobrimos que os LLMs poderiam criar programas SQL refletindo a intenção humana de forma eficaz. Encontramos uma alta porcentagem (82,25%) de programas SQL válidos, indicando boa qualidade geral. O LLM poderia criar consultas complexas apresentando uma variedade de componentes SQL.

Em quase todas as categorias de componentes SQL, exceto JUNÇÕES, as porcentagens de consultas válidas superaram 50%. No entanto, consultas de JUNÇÃO apenas alcançaram uma taxa de validade de 49,47%, apontando potencialmente para uma necessidade de entendimento mais profundo ou habilidade de programação ao juntar várias tabelas.

Notamos que algumas declarações SQL simples apareceram frequentemente, como SELECT * FROM table, que representou uma grande parte (48,4%) dos programas SQL válidos. Embora essas declarações sejam válidas, elas são menos informativas do que consultas mais complicadas para aprendizado adicional.

Em nossos prompts, orientamos o LLM a criar programas SQL "com complexidade relativamente alta", alcançando algum sucesso. No entanto, o objetivo conflitante de criar consultas complexas e corretas pode levar os LLMs a produzir consultas mais simples para manter a precisão.

Como mostrado, anotações SQL inválidas podem surgir por várias razões. Às vezes, o LLM cria nomes de tabelas inexistentes ou deixa texto de espaço reservado, ou em alguns arquivos CSV, os nomes das colunas podem ser numéricos, o que é inválido em consultas SQL. Além disso, enquanto alguns programas SQL corretos podem retornar resultados vazios, eles são rotulados como inválidos para medir a precisão da execução.

Utilizamos o AnnotatedTables para estudar a capacidade dos LLMs de aprender uma nova linguagem de programação, Rel.

Como há exemplos limitados de código Rel de código aberto disponíveis, recorremos ao aprendizado em contexto de poucos exemplos como uma solução natural. Embora o ICL tenha sido estudado, traduzir entre duas linguagens de programação distintas é um desafio de pesquisa único.

Todos os programas SQL no AnnotatedTables podem ser executados, tornando possível avaliar a precisão da tradução de maneira eficaz. Os programas SQL imitam o uso típico do banco de dados, e traduzir essas consultas nos permite criar um conjunto de dados considerável de programas Rel valiosos para pesquisas subsequentes.

Ao aprender uma nova linguagem de programação, conseguir dados de treinamento suficientes pode ser desafiador. Nossos resultados indicam que a precisão da tradução melhora continuamente com mais exemplos em contexto, alcançando cerca de 40% de precisão com 45 exemplos de tradução.

Para formular a tarefa de tradução SQL-Rel, começamos com um programa SQL executável que opera em uma tabela específica. Nosso objetivo é desenvolver um modelo capaz de traduzir o programa SQL em um programa Rel, garantindo que ambos gerem os mesmos resultados de consulta quando executados na mesma tabela.

A precisão da execução mede com que frequência os programas SQL e Rel traduzidos produzem os mesmos resultados não vazios. No entanto, comparar programas SQL e Rel diretamente pode ser difícil devido às diferenças inerentes entre as linguagens.

Para melhorar as capacidades de tradução, introduzimos uma técnica chamada Engenharia de Prompt Incremental (IPE), que emprega feedback de execução para refinar os exemplos de tradução aprendidos. Começamos com alguns exemplos iniciais de tradução SQL-Rel, instruindo o modelo de linguagem a traduzir programas SQL não vistos e calculamos a precisão da execução para cada etapa.

O feedback nos permite identificar onde o LLM falha na tradução e adicionar esses exemplos à próxima rodada de treinamento, aumentando o número de exemplos progressivamente até alcançarmos uma precisão de tradução satisfatória.

Através do processo IPE, observamos uma melhoria na precisão da tradução à medida que adicionamos mais exemplos. Uma vez que superamos 30 exemplos, exemplos adicionais ofereceram retornos decrescentes, convergindo em torno da marca de 40% de precisão.

Para nossa avaliação do TabPFN, usamos o AnnotatedTables para testar seu desempenho de classificação em muitos conjuntos de dados diversos. O TabPFN é um novo tipo de rede neural treinada com dados sintéticos extraídos de um prior bayesiano.

Uma vez treinado, processa todos os dados de uma vez, fazendo previsões em uma única passada. Dado seus resultados avançados em benchmarks menores, estávamos curiosos para ver como o TabPFN se comportaria diante das complexidades dos dados tabulares do mundo real.

O TabPFN é comparado a métodos padrão e a alguns dos principais frameworks de AutoML, usando vários conjuntos de dados para avaliar sua resiliência. À medida que ampliamos nossa avaliação para 2.720 problemas de classificação, vamos muito além dos benchmarks anteriores.

Em nossa configuração experimental, mantemos os mesmos parâmetros dos autores originais para o TabPFN e treinamos o AutoGluon usando um orçamento de tempo de um ou cinco minutos, dividindo os dados apenas uma vez por tabela para economizar tempo.

Confiamos nas anotações dos LLMs para identificar colunas de entrada e alvo adequadas nos conjuntos de dados do Kaggle para o TabPFN. Esse processo garante que as colunas de entrada sejam numéricas enquanto o alvo é categórico para uma classificação eficaz.

Em nossas descobertas, o TabPFN mostrou um desempenho sólido em todos os 2.720 problemas de classificação testados, com alguns resultados significativos em comparação com o AutoGluon, demonstrando que os LLMs podem identificar com precisão colunas de entrada-alvo e a estrutura tabular necessária para tarefas de classificação eficazes.

Por último, usar o AnnotatedTables destacou o potencial dos LLMs para revolucionar a forma como criamos conjuntos de dados de aprendizado de máquina. A capacidade de usar LLMs para automatizar o processo de anotação pode reduzir custos e facilitar para os pesquisadores obterem os dados personalizados de que precisam para seus projetos específicos, abrindo portas para novas oportunidades na ciência de dados.