Integrando SQL e Modelos de Linguagem pra Acessar Dados Melhor

Informação muitas vezes tá em texto, mas não tem um formato estruturado. Pegar dados de texto em linguagem natural pra encaixar em uma estrutura específica pode ser complicado. Com o crescimento dos grandes modelos de linguagem (LLMs), agora tem um jeito melhor de armazenar e usar informações tiradas de vários documentos. Isso pode permitir que ConsultasSQL acessem dados que Bancos de dados tradicionais não conseguem, usando as informações nos LLMs.

Essa habilidade permitiria que usuários combinassem consultas de LLMs e bancos de dados usando SQL, que é mais detalhada e precisa do que perguntar em linguagem natural. Pra ilustrar essa ideia, sugerimos um jeito de fundamentar isso usando uma configuração típica de banco de dados. A ideia é rodar algumas partes da consulta com comandos que pegam dados do LLM. Pra muitos tipos de consultas SQL, interrogar LLMs pode oferecer dados organizados com bons resultados.

Destacamos algumas questões de pesquisa que precisam ser trabalhadas pra criar um sistema de banco de dados que consiga usar tanto LLMs quanto bancos de dados tradicionais. Algumas questões precisam de novas ideias da área de processamento de linguagem natural, enquanto outras apresentam novos caminhos de pesquisa pra especialistas em bancos de dados.

SQL é popular porque permite consultas claras de dados. Porém, SQL só pode ser usado em dados estruturados com um formato fixo. Isso significa que não pode acessar diretamente informações escritas em texto não estruturado. Várias tecnologias foram desenvolvidas pra extrair dados estruturados de texto não estruturado. Mesmo assim, isso muitas vezes exige que engenheiros configurem processos de extração manualmente, o que pode ser caro e rígido, permitindo apenas pares de dados fixos.

Pegar dados de texto através de consultas é bem desafiador. Recentemente, teve grandes avanços em respostas a perguntas (QA) sobre texto. Nesse caso, uma pergunta em linguagem natural é respondida encontrando informações em um conjunto de documentos. Transformers possibilitaram a criação de grandes modelos de linguagem, que são redes neurais usadas em várias tarefas relacionadas à linguagem natural. Modelos como o GPT foram treinados em grandes conjuntos de dados e conseguem fornecer respostas pra perguntas difíceis sem precisar de informações armazenadas diretamente neles.

Enquanto modelos como esses armazenam uma riqueza de informações factuais, eles não são projetados pra responder a consultas SQL complexas e podem ter dificuldades com isso. Consultar um LLM via SQL é diferente de responder perguntas. Aqui, tratamos uma consulta SQL do usuário como entrada, que o modelo processa pra devolver os dados, enquanto QA envolve tanto perguntar quanto receber informações em linguagem natural.

Propomos usar scripts SQL pra consultar LLMs já treinados. O LLM funciona como um armazenamento de dados que guarda as informações necessárias pra responder a uma consulta. Acreditamos que esse método deve manter características chave do SQL ao trabalhar com essa nova fonte de dados:

1. Consultas podem ser escritas usando SQL padrão sobre uma configuração relacional definida pelo usuário, permitindo consultas complexas e exatas em comparação com comandos padrão de linguagem natural.
2. As respostas devem ser precisas e completas de acordo com o que o LLM armazena. Isso significa que as consultas precisam ser executadas corretamente, já que os LLMs nem sempre fornecem dados corretos.

Erros nos dados podem ser críticos, ao contrário de tarefas onde pequenos erros podem passar despercebidos. Embora LLMs ainda cometam erros, resultados mostram que é possível coletar dados organizados deles. À medida que as capacidades dos LLMs melhoram devido a métodos de treinamento melhores e mais textos utilizados, a confiabilidade e o escopo das informações que eles podem oferecer também aumentam.

Muitas empresas agora estão usando LLMs proprietários recheados de informações específicas. Consultas SQL híbridas podem ajudar a acessar dados estruturados de fontes diversas. O banco de dados gerencia os dados estruturados enquanto o LLM cobre as informações não estruturadas. Essa abordagem pode consultar dados de texto sem precisar de input humano previamente. Sonhamos em executar consultas SQL pra obter dados estruturados de LLMs.

À medida que mais empresas adotam LLMs proprietários, dados especializados estão sendo armazenados dentro desses modelos. Isso pode atender bem a muitas aplicações. Dados frequentemente existem em diferentes formas, como emails ou arquivos PDF. Consultar sua representação em um LLM pode revelar informações que um banco de dados típico poderia perder.

Imaginamos um sistema que permita consultas de dados além do que tá atualmente disposto em um formato estruturado. Um exemplo de combinar um script criado pelo usuário pra consultar um banco de dados e um LLM pode envolver iterar sobre os dados de ambas as fontes. Essa consulta híbrida permitiria que informações do LLM fossem usadas para tarefas como integração e limpeza de dados.

Esse texto sugere um jeito de conectar bancos de dados tradicionais com LLMs pra novos planos de consulta híbridos. Porém, não tá claro qual arquitetura deve servir de base pra essa solução. Ao olhar pra designs de LLMs e bancos de dados, existem vários caminhos a considerar. Uma direção é fazer o LLM acessar informações externas, incluindo dados estruturados.

Esse método tá ganhando força, mas LLMs atualmente têm um tamanho de entrada limitado, o que dificulta rodar consultas que puxem grandes conjuntos de dados. Uma alternativa é priorizar o banco de dados, usando LLMs como parte do processo clássico de consulta de banco de dados, que é o foco desse trabalho.

Nossas contribuições se concentram em como consultar LLMs pré-treinados e apresentar sinais iniciais do seu potencial. Sugerimos um jeito específico de implementar um protótipo que priorize o banco de dados, rodando consultas SQL básicas sob certas suposições pra suportar uma ampla gama de aplicações.

A estrutura do plano de consulta divide a tarefa complexa em passos mais simples que o LLM pode lidar mais facilmente. Novos operadores físicos pro plano de consulta são propostos. Introduzimos o desafio de consultar LLMs pré-treinados usando SQL.

Pra apoiar essa visão, criamos um protótipo que processa consultas SQL simples baseadas em certas suposições. Isso nos permite gerenciar um amplo conjunto de aplicações. O plano lógico de consulta divide tarefas complexas em passos gerenciáveis adequados pro LLM. Os operadores físicos são representados como comandos pro LLM, gerados a partir da estrutura de entrada e operadores lógicos.

A gente percebe que executar 46 consultas SQL contra LLMs populares pode resultar em dados comparáveis aos obtidos de bancos de dados tradicionais e melhores do que os derivados de reescrever consultas em linguagem natural.

Também discutimos avanços recentes em processamento de linguagem natural e como eles se relacionam com nosso trabalho. Existem desafios em consultar LLMs. Nosso texto descreve a estrutura do nosso protótipo que usa uma abordagem de banco de dados primeiro, e apresentamos resultados iniciais baseados em um conjunto de dados público chamado Spider.

Nossa visão é influenciada por avanços em processamento de linguagem natural, impulsionados pela arquitetura transformer e aprendizado por transferência. O transformer permite um processamento eficiente e levou à criação de enormes modelos de linguagem que são treinados em conjuntos de dados muito grandes. Embora o processo de pré-treinamento possa ser caro, esses modelos podem depois ser ajustados para novas tarefas.

Normalmente, "ajuste fino" com exemplos específicos pra uma tarefa tem sido o método principal pra adaptar modelos. Porém, modelos mais novos podem assumir novas tarefas sem treinamento adicional, apenas oferecendo uma descrição em linguagem natural da tarefa. Adicionar apenas alguns exemplos pode melhorar bastante a precisão.

Nosso objetivo é distinto da tarefa de parsing semântico, que transforma perguntas em linguagem natural em consultas estruturadas. A gente quer recuperar informações de LLMs usando consultas SQL. Isso mantém o formato de saída tradicional encontrado em bancos de dados. Embora alguns fatos possam ser obtidos através de QA, converter consultas SQL em perguntas equivalentes em linguagem natural não é prático pra consultas complexas. Além disso, resultados em texto exigem parsing em um formato estruturado e os LLMs atuais podem ter dificuldades com consultas complexas em linguagem natural.

Pra lidar com alguns desses desafios, estudos recentes mostram que passos de raciocínio intermediários podem ajudar LLMs a gerenciarem tarefas mais complicadas.

Nosso trabalho também é diferente de propostas recentes pra Bancos de Dados Neurais, onde fatos textuais são codificados e frases curtas em linguagem natural são usadas pra consultas. Nós não dependemos de fatos de entrada e focamos em executar scripts SQL tradicionais dentro de LLMs.

Considerações de design pra consultar LLMs giram em torno de garantir uma boa execução de consultas SQL. Olhando pros LLMs do ponto de vista de banco de dados, eles oferecem uma cobertura extensa de fatos a partir de vastas fontes de texto, mas também têm suas limitações. LLMs têm dificuldades com operações de dados detalhadas, mas operadores de consulta tradicionais se saem bem em manipulações complexas de dados dentro de seus conjuntos estruturados.

Ao fundir LLMs com sistemas tradicionais de bancos de dados, vemos o potencial pra um sistema híbrido que pode consultar tanto tabelas convencionais quanto os fatos contidos em LLMs. Porém, desafios em consultas aos LLMs devem ser considerados. Aqui estão algumas questões críticas:

#1. Tuplas e Chaves

LLMs não entendem inherentemente o conceito de dados estruturados ou tuplas. Eles representam as relações entre itens, como “Roma está na Itália”, mas uma consulta pedindo nomes de cidades pode assumir que um nome identifica uma cidade de forma única. Isso nem sempre é verdade, já que existem cidades com o mesmo nome em diferentes locais.

Por exemplo, LLMs podem ter conhecimento de chaves como códigos de aeroportos, mas geralmente não têm uma chave universal pra todas as entidades, o que pode levar à confusão. No nosso protótipo inicial, assumimos que cada item na consulta tem uma chave que pode ser expressa por um único atributo, como seu nome. No entanto, podemos modificar isso pra lidar com chaves mais complexas que considerem o contexto.

#2. Ambiguidade de Esquema

Ambiguidade é um desafio comum na linguagem. Semelhante à questão de entidade, palavras e rótulos de atributos podem ter significados diferentes. Uma consulta pedindo "tamanho" poderia significar população ou área de terra.

Nas nossas primeiras tentativas, assumimos que os rótulos de atributos nas consultas são claros. Essa abordagem ajuda a garantir que o sistema consiga criar bons comandos automaticamente.

#3. Conhecimento Factual nos LLMs

LLMs não têm a capacidade de saber o que eles sabem. Essa limitação vem de como os transformers operam, especificamente em sua saída. Quando um LLM fornece dados, isso pode ser baseado em um conhecimento sólido ou simplesmente um palpite. Portanto, resultados de LLMs não podem ser totalmente confiáveis, já que eles não fornecem fontes com suas respostas.

No entanto, mostramos que é possível extrair informações factuais de LLMs ao responder consultas SQL. Novos modelos de LLM estão cada vez mais capazes de fornecer dados factuais mais precisos.

O design de alto nível para o sistema que propomos assume que o esquema é fornecido com a consulta. O sistema processa consultas SQL sobre dados armazenados em um LLM pré-treinado. Esse design permite que os desenvolvedores criem suas aplicações de uma maneira padrão, pois as complexidades de usar um LLM estão ocultas dentro do sistema.

O conceito central é usar LLMs pra criar operadores de dados especializados em planos de consulta tradicionais. Já que tuplas não são acessíveis diretamente, nós as recuperamos acessando valores chave de atributos. Em seguida, extraímos outros atributos enquanto percorremos o plano de consulta.

Por exemplo, se a consulta envolve filtrar por um atributo que não tá na tupla, os dados relevantes ainda podem ser recuperados executando um comando logo antes da operação. Uma vez que todas as tuplas necessárias são coletadas, operações regulares como junções podem ser executadas sobre elas.

O plano de consulta serve como uma divisão simples da tarefa total, guiando o LLM por cada passo. Esse método utiliza as forças tanto do LLM quanto dos operadores tradicionais.

#Comandos

Comandos apropriados pro LLM são criados misturando um conjunto de templates com os rótulos e condições da consulta SQL. Por exemplo, se a consulta SQL envolve filtrar políticos por idade, um comando checaria se um político específico se encaixa nos critérios.

Templates oferecem um jeito simples de criar comandos. Isso poderia ser mais desenvolvido pra utilizar resultados da engenharia de comandos, o que poderia refinar o processo.

#Fluxo de Trabalho

Os principais processos no manuseio de consultas envolvem:

1. Gerar um plano lógico de consulta a partir da consulta SQL e do esquema.
2. Acessar o LLM pra reunir tuplas e outros atributos necessários com base na estrutura da consulta.
3. Transformar as respostas do LLM em dados estruturados.
4. Aplicar algoritmos tradicionais a qualquer operação que envolva atributos já recuperados.

Duas etapas principais tornam o uso prático desse sistema alcançável. Primeiro, já que relações podem ser grandes, usamos comandos até que não entremos mais resultados novos. Segundo, precisamos limpar os dados coletados do LLM. Por exemplo, valores numéricos podem ser recuperados em vários formatos, então normalizamos eles pra um formato numérico padrão.

Em contraste com o método tradicional de extrair dados estruturados de texto, LLMs e comandos permitem que isso seja feito sem intervenção humana. A abordagem banco de dados primeiro significa que comandos podem ser criados automaticamente como parte do plano lógico.

Nossos experimentos foram conduzidos usando LLMs populares pra avaliar uma variedade de consultas SQL. O foco foi em um conjunto de dados chamado Spider, que inclui vários bancos de dados e consultas SQL correspondentes. Examinamos um grupo seleto de 46 consultas para as quais antecipamos conseguir respostas de um LLM.

Percebemos que diferentes LLMs produzem resultados variados com base em uma consulta SQL. Pra cada consulta SQL feita, coletamos diferentes tipos de dados do LLM. Esses resultados podem ser comparados pra ver quão bem o LLM se sai em relação a bancos de dados tradicionais.

#Cardinalidade e Conteúdo

Analisamos os resultados de duas maneiras: cardinalidade e conteúdo.

1. Cardinalidade observa o número correto de itens retornados nos resultados.

2. Conteúdo examina a precisão de cada valor retornado em comparação com respostas conhecidas como corretas.

Resultados sugerem que modelos menores perdem muitos resultados em comparação com modelos maiores como o GPT. Pra consultas mais simples, essa abordagem retorna uma alta taxa de precisão nos resultados, enquanto junções complexas tendem a ser mais problemáticas.

Os tempos de execução da API e outras métricas de desempenho não foram acompanhados devido a fatores externos que influenciam isso. Nós descobrimos que em média, modelos GPT levam um tempo considerável pra processar consultas.

#Direções de Pesquisa

Nosso objetivo é aprimorar a execução de consultas SQL sobre LLMs enquanto alcançamos precisão e eficiência semelhantes às consultas executadas em bancos de dados tradicionais. Embora nosso protótipo atual não alcance esse objetivo, descrevemos várias etapas futuras pra avançar essa visão.

#Otimização de Consultas

A otimização de consultas pode ser estruturada em torno de planos lógicos e físicos. Uma vantagem chave na nossa estrutura é a geração automática de comandos pro plano lógico. No entanto, combinar operadores pra dados tradicionais e LLMs exigiria mais exploração. Precisamos desenvolver estratégias que minimizem a execução de comandos sem complicar as consultas desnecessariamente.

Pra aprimorar o plano físico, questões importantes giram em torno de gerar comandos automaticamente quando dados apenas rótulos de atributos. Quanto mais específicos os comandos criados, melhores os resultados.

#Conhecimento do Desconhecido

Pra lidar com o desafio de misturar fatos e imprecisões, propomos um processo de verificação usando outro modelo. Essa abordagem pode ajudar a solidificar a precisão dos dados retornados pelo LLM.

Modelos aumentados de recuperação apresentam uma avenida promissora pra separar a compreensão da linguagem do conhecimento factual. Mais trabalho é necessário pra garantir resultados confiáveis dos LLMs.

#Consultas Sem Esquema

Atualmente, usuários precisam fornecer um esquema pra suas consultas. Um desenvolvimento significativo seria permitir que usuários consultassem sem precisar declarar um esquema, embora isso traga desafios. Por exemplo, duas consultas que visam obter resultados semelhantes deveriam gerar resultados equivalentes, apesar das diferenças na formulação.

Encontrar maneiras de garantir essa consistência seria um desafio importante pro desenvolvimento do sistema.

No geral, enquanto nosso sistema tá fundamentado em um design de banco de dados primeiro, reconhecemos que uma arquitetura de LLM primeiro tem suas vantagens. A interseção de dados estruturais e saídas de LLM apresenta uma variedade de oportunidades pra trabalhos futuros.

#Atualizações e Custos

Nossa expectativa é que consultar LLMs não será tão comum quanto consultar bancos de dados tradicionais. LLMs servem como uma fonte pra casos específicos, mas não como substitutos. Treinar e usar LLMs pode ser caro, então encontrar maneiras de incorporar novas informações sem um extenso re-treinamento é uma consideração importante.

#Cobertura e Viés

LLMs tendem a se concentrar em cenários comuns, o que pode levar a lacunas nos resultados. É crucial ficar atento a essa limitação, bem como aos viéses incorporados nesses modelos a partir dos dados que foram treinados.

Esse texto delineia uma visão pro campo de bancos de dados, demonstrando o potencial de consultar grandes modelos de linguagem usando SQL. O objetivo é fazer a ponte entre bancos de dados tradicionais e LLMs pra criar sistemas híbridos que melhorem a execução de consultas.

Melhorar a factualidade e a cobertura dos LLMs expandirá seu papel nos sistemas de banco de dados. Ao apresentar um protótipo e o uso de SQL pra consultar LLMs, esperamos inspirar mais pesquisas e colaborações entre os campos de banco de dados e NLP, levando a soluções inovadoras que acessam informações valiosas escondidas em texto não estruturado.