Avaliando Sistemas de Texto-para-SQL com Dados Reais

Sistemas de Text-to-SQL permitem que os usuários façam perguntas em linguagem simples e traduzam essas perguntas em comandos SQL que podem recuperar dados de um banco de dados. Esses sistemas têm se tornado mais populares, já que a galera quer acessar dados de forma mais fácil, sem precisar saber escrever SQL.

Com o tempo, novos modelos de linguagem avançados ajudaram a melhorar como esses sistemas funcionam. No entanto, enquanto muitos desses sistemas mostram pontuações altas em testes controlados, não teve foco suficiente em como eles se saem em situações reais com perguntas de usuários de verdade.

Este artigo investiga quão robustos os sistemas de Text-to-SQL são quando enfrentam diferentes estruturas de banco de dados, avaliando-os através de um projeto focado em aplicações do mundo real. A gente olha para o FootballDB, um setup que foi usado durante a Copa do Mundo da FIFA 2022, onde os usuários enviaram milhares de perguntas em linguagem natural. Nossa análise inclui perguntas de usuários em tempo real, mostrando como o sistema lida com diferentes tipos de designs de banco de dados.

#A Ascensão dos Sistemas de Text-to-SQL

Bancos de dados relacionais há muito tempo usam SQL como a forma padrão de consultar dados estruturados. Nos últimos anos, mais pessoas, incluindo aquelas sem formação em programação, querem usar esses bancos para tomar decisões. Isso levou ao crescimento dos sistemas de Text-to-SQL, que permitem que os usuários façam perguntas e recebam respostas sem precisar aprender SQL.

Ao longo dos anos, os métodos para converter linguagem simples em SQL têm avançado. Desde sistemas simples baseados em palavras-chave até modelos complexos de deep learning, esses sistemas melhoraram significativamente sua precisão. No entanto, as ferramentas atuais ainda não estão totalmente prontas para uso cotidiano em situações empresariais.

Apesar de diversos benchmarks de desempenho criados a partir de dados sintéticos, ainda não há uma investigação sistemática sobre como esses sistemas se saem com consultas reais de usuários. A maioria das pesquisas anteriores fala mais sobre princípios de design do que sobre avaliações práticas. Este artigo preenche essa lacuna ao fornecer uma análise abrangente baseada em aplicações do mundo real.

#O Projeto FootballDB

O conjunto de dados do FootballDB captura quase um século de dados da Copa do Mundo de futebol. Ele inclui informações sobre jogos, jogadores, times e clubes, desde a Copa do Mundo inaugural em 1930. Nossa equipe atualizou continuamente o conjunto de dados à medida que novos jogos ocorreram durante a Copa do Mundo.

Um total de 6.000 perguntas em linguagem natural foram registradas de usuários durante este projeto. As principais características deste conjunto de dados incluem:

1. Interação Real do Usuário: Todas as perguntas vieram de usuários reais interagindo com o sistema.
2. Informação Abrangente: O conjunto de dados cobre informações sobre 22 Copas do Mundo, 86 seleções nacionais e milhares de jogadores e clubes.
3. Atualizações Contínuas: Novos dados foram adicionados após cada jogo, garantindo que o conjunto de dados permanecesse atual.

#Implantação do Sistema

Nós projetamos a interface do FootballDB para permitir que os usuários fizessem perguntas sobre os dados da Copa do Mundo de forma fácil. O sistema de backend usou PostgreSQL para gerenciar o banco de dados.

Durante a operação ao vivo, usamos um modelo chamado ValueNet para traduzir as consultas dos usuários em comandos SQL. O ValueNet foi escolhido porque seu código-fonte é aberto e foi usado com sucesso em outros projetos.

#Engajamento do Usuário

Para atrair usuários para o nosso sistema, focamos na Copa do Mundo da FIFA. O futebol é um evento universalmente reconhecido, facilitando o interesse de um público diversificado. A implantação começou em outubro de 2022 e durou até a Copa do Mundo. O feedback dos usuários nos ajudou a refinar o sistema ao longo do tempo.

#Iteração de Melhorias

1. Feedback Inicial dos Usuários: As primeiras interações revelaram que os usuários estavam frequentemente mais interessados em consultas sobre clubes de jogadores e histórias de treinadores. Nós expandimos o banco de dados para incluir essa informação.

2. Interface para Especialistas: Criamos uma interface especializada para usuários com algum conhecimento de SQL. Eles podiam fornecer feedback sobre as consultas SQL geradas pelo sistema, ajudando a melhorar a precisão.

3. Validação de Dados: Implementamos um processo de validação manual para garantir que as consultas SQL geradas estavam corretas. Isso exigiu um esforço considerável, mas era essencial para refinar nosso conjunto de dados.

4. Automação de Rotulagem: Começamos a desenvolver técnicas para automatizar partes do processo de rotulagem, que antes era feito manualmente. Isso ajudou a acelerar o tempo necessário para preparar dados para treinar o modelo.

5. Atualização Final do Modelo: Depois de limpar o conjunto de dados, retrainamos o sistema para lidar melhor com as consultas dos usuários. Esse processo melhorou significativamente a precisão do modelo.

#Design do Modelo de Dados

O design da estrutura do banco de dados é crítico para o quão bem os sistemas de Text-to-SQL funcionam. Nós focamos em dois objetivos principais:

1. Simplificar Consultas: Nosso objetivo era criar uma estrutura que facilitasse para os usuários escrever perguntas.

2. Reduzir Erros: Queríamos minimizar as chances de o sistema gerar consultas SQL incorretas.

#Modelo de Dados Inicial

A versão inicial do nosso modelo de dados tinha 13 tabelas contendo vários detalhes sobre o torneio. Durante o processo de validação, encontramos algumas fraquezas na estrutura, especialmente em como os dados estavam conectados.

#Mudanças Através da Iteração

1. Versão 2: Modificamos o modelo de dados para facilitar o processo de escrita de consultas. Essa versão visava reduzir o número de junções complexas entre tabelas.

2. Versão 3: Mais refinamentos foram feitos para aumentar a experiência do usuário. Tabelas desnecessárias foram removidas e relações mais intuitivas foram criadas, permitindo que os usuários fizessem perguntas mais simples.

#Avaliação Experimental

Realizamos uma análise detalhada para avaliar como diferentes sistemas de Text-to-SQL se saem com o conjunto de dados do FootballDB. Focamos em várias questões-chave de pesquisa:

1. Impacto dos Modelos de Dados: Como diferentes designs de banco de dados afetam a precisão das traduções SQL?

2. Desempenho do Modelo de Linguagem: Como modelos de linguagem pequenos, médios e grandes se comparam na execução dessas tarefas?

3. Efeito do Tamanho dos Dados de Treinamento: Como o volume de dados de treinamento influencia o desempenho do sistema?

4. Complexidade das Consultas: Qual o papel da complexidade das consultas dos usuários?

5. Tempo de Inferência: Quão rápido esses sistemas podem processar consultas em cenários em tempo real?

#Configuração Experimental

Dos 6.000 interações de usuários registradas, filtramos os dados para criar um conjunto de treinamento de 1.000 perguntas. Depois, avaliamos os sistemas com base em vários tamanhos de dados de treinamento para ver como isso afetou a precisão deles.

#Métricas de Desempenho

Para avaliar a eficiência do sistema, usamos uma medida simples conhecida como correspondência exata de execução. Esse método verifica se os resultados das consultas SQL do sistema correspondem aos resultados esperados.

#Descobertas de Desempenho do Sistema

Testamos vários sistemas de Text-to-SQL, incluindo modelos de linguagem pequenos, médios e grandes. O desempenho de cada sistema foi afetado por vários fatores:

1. Modelo de Dados: Alguns sistemas se saíram melhor com modelos de dados simplificados, enquanto outros mostraram pouca diferença de desempenho entre diferentes modelos.

2. Tamanho do Modelo de Linguagem: Nossas descobertas indicaram que modelos maiores geralmente oferecem melhor precisão. No entanto, isso vem com um custo maior em recursos computacionais.

3. Tamanho dos Dados de Treinamento: Mais dados de treinamento tendem a melhorar o desempenho geral, mas o ganho foi marginal após um certo ponto.

4. Complexidade das Consultas: Consultas mais complexas resultaram em menor precisão entre os sistemas.

#Análise do Tempo de Inferência

Medimos quanto tempo cada sistema levou para gerar uma resposta após receber uma consulta de usuário. Os resultados variaram bastante, com alguns modelos levando mais de cinco minutos para responder a uma pergunta.

#Lições Aprendidas

Através das fases de implantação e avaliação, descobrimos insights importantes que podem guiar o design de futuros sistemas de Text-to-SQL:

1. Treinamento de Usuários: Educar os usuários sobre o conteúdo do banco de dados pode ajudar a reduzir perguntas fora do escopo.

2. Características para Especialistas: Oferecer recursos avançados para usuários que têm conhecimento pode melhorar o feedback do sistema e ajudar a refinar o desempenho.

3. Automação no Processamento de Dados: Encontrar maneiras de automatizar tarefas que consomem muito tempo, como rotulagem de consultas, pode economizar tempo e recursos.

4. Importância dos Modelos de Dados: A escolha do modelo de dados afeta significativamente o desempenho geral dos sistemas de Text-to-SQL, com designs mais simples geralmente resultando em melhor manejo de consultas dos usuários.

5. Filtragem de Consultas: Reduzir a complexidade das consultas SQL geradas pode melhorar o desempenho sem precisar de mais dados de treinamento.

#Conclusão

Este estudo enfatiza a importância de avaliações do mundo real para sistemas de Text-to-SQL e como eles podem ser melhorados ao considerar várias escolhas de design. Ao liberar o conjunto de dados do FootballDB, esperamos ajudar outros pesquisadores a desenvolver e testar seus sistemas de forma eficaz. Embora o desafio de traduzir consultas em linguagem natural para SQL ainda não esteja totalmente resolvido, nossas descobertas destacam o potencial de crescimento e melhoria nessa área.

O trabalho também traz à tona as limitações práticas dos sistemas atualmente disponíveis, especialmente em relação ao tempo de inferência, que precisa ser abordado para uma adoção mais ampla em aplicações do mundo real. Daqui pra frente, o desafio continua a ser otimizar esses sistemas para um melhor desempenho, tornando-os acessíveis para usuários do dia a dia.