Como construir um mecanismo Text2SQL de nível de produção

Interagir com bancos de dados geralmente requer um nível de conhecimento técnico que pode colocar os dados fora do alcance de muitas pessoas. Considere um executivo financeiro que precisa entender os números e tendências financeiras da empresa. Tradicionalmente, esse executivo teria que contar com analistas de SQL para extrair os dados necessários do banco de dados. Essa dependência pode causar atrasos e lacunas de comunicação, especialmente se o executivo precisar refinar suas consultas várias vezes para obter os insights desejados.

Mas o text2SQL, um recurso que converte linguagem natural em instruções de linguagem de consulta estruturada, mudou o jogo. Com o text2SQL, o executivo financeiro pode interagir diretamente com o banco de dados usando linguagem natural. Por exemplo, um usuário pode inserir uma pergunta voltada para o negócio, como "Qual foi o valor médio do pedido para cada cliente no mês passado?"

O mecanismo de IA de conversão de texto em SQL processará a pergunta e gerará a consulta SQL correspondente:

Select customer_id, AVG(order_value) AS average_order_value FROM orders WHERE order_date >= DATE_SUB(CURRDATE(), INTERVAL 1 MONTH) GROUP BY customer_id;

Em seguida, execute-o no banco de dados e exiba os resultados ao usuário.

Neste artigo, explicaremos a função dos LLMs no text2SQL, discutiremos os desafios inerentes a esse recurso e exploraremos o SherloQ, um mecanismo text2SQL altamente preciso e robusto desenvolvido pela equipe da Skypoint .

O papel dos LLMs no text2SQL

A capacidade de converter text2SQL melhorou significativamente com a ajuda de modelos de linguagem grande (LLMs). Esses modelos usam grandes quantidades de dados e arquiteturas de rede neural poderosas para entender e gerar texto semelhante ao humano. Ao treinar em conjuntos de dados diversos, os LLMs podem generalizar em várias tarefas, incluindo a tradução de linguagem natural em consultas SQL.

Por exemplo, o artigo " Language Models are Few-Shot Learners " demonstra como os LLMs podem executar tarefas com exemplos mínimos, destacando sua capacidade de se adaptar a novas tarefas com dados limitados. Essa abordagem reduz significativamente a necessidade de dados extensivos específicos da tarefa, facilitando a implantação de LLMs em vários aplicativos.

O " Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task " fornece um conjunto de dados abrangente para treinamento e avaliação de modelos em consultas SQL complexas em diferentes domínios. Este conjunto de dados tem sido essencial para o avanço do estado da arte em text2SQL ao fornecer um benchmark robusto para desempenho de modelo.

Além disso, " PALM: Scaling Language Modeling with Pathways " explora como técnicas avançadas de treinamento, como dimensionamento de tamanhos de modelos e otimização de caminhos de treinamento, podem melhorar o desempenho do modelo em vários aplicativos, incluindo text2SQL.

Embora esses LLMs sejam altamente eficazes em ambientes controlados, eles frequentemente enfrentam desafios em configurações de produção. Isso inclui lidar com prompts ambíguos, gerenciar esquemas complexos de banco de dados e garantir desempenho em tempo real. Além disso, integrar esses modelos em sistemas existentes requer esforço significativo e manutenção contínua para se adaptar às mudanças de dados e requisitos do usuário. Aqui estão três LLMs que funcionam bem para essa tarefa:

Codificador SQL

O principal propósito do SQLcoder é converter entrada de linguagem natural em consultas SQL. Diferentemente de outros modelos de propósito geral, o SQLCoder foi refinado em dados específicos para SQL, portanto, é especialmente eficaz para entender e gerar consultas SQL. O SQLCoder demonstra um desempenho notável no conjunto de dados Spider, um benchmark complexo e de domínio cruzado para sistemas text2SQL.

O SQLCoder gera a consulta SQL correta para novos esquemas não vistos no treinamento com uma precisão de 64,6% . Ele supera o GPT-3.5-turbo e o text-davinci-003, que são modelos com mais de 10x seu tamanho. Isso destaca a capacidade do SQLCoder de lidar com consultas SQL diversas e complexas, o que é crítico para ambientes de produção.

GPT 3.5/GPT 4

GPT-3.5 e GPT-4 (Generative Pre-trained Transformer) são alguns dos modelos de linguagem de propósito geral mais avançados e eficazes. Ambos os modelos se destacam no aprendizado de poucas tentativas, adaptando-se rapidamente a novas tarefas com exemplos mínimos, o que é ideal para criar consultas SQL a partir de entrada limitada.

Por exemplo, quando avaliado no conjunto de dados Spider, o GPT-3.5-turbo tem uma porcentagem de consultas SQL geradas corretamente em novos esquemas não vistos no treinamento de 60,6%, enquanto o GPT-4 atinge 74,3%.

Esses modelos exibem desempenho robusto, particularmente na compreensão do contexto e na geração de consultas SQL precisas a partir de entradas complexas de linguagem natural. No entanto, seu design de propósito geral às vezes requer ajuste fino adicional para resultados ideais em aplicativos especializados, como geração de SQL.

SQL do PaLM

PaLM (Pathways Language Model) SQL é outro modelo poderoso desenvolvido pelo Google. Os recursos e a arquitetura avançados do PaLM SQL o tornam altamente eficiente na tradução de linguagem natural para consultas SQL e no manuseio de esquemas de banco de dados complexos e diversos com maior precisão.

Apesar dos avanços em LLMs, depender de um único LLM para text2SQL em produção pode ser problemático. Um único modelo não será capaz de lidar com a ampla variedade de consultas, esquemas de banco de dados e requisitos de latência em tempo real de um ambiente de dados corporativos de forma eficaz.

Ambientes de produção exigem robustez, adaptabilidade e a capacidade de lidar com prompts ambíguos de usuários empresariais do mundo real. Portanto, um mecanismo text2SQL deve exibir três propriedades para ser considerado de nível de produção:

Capacidade de entender diversas formulações de consulta - Prompts de usuário sintaticamente diferentes podem ser reduzidos à mesma consulta SQL; um bom mecanismo text2SQL deve ser capaz de entender a motivação por trás de um prompt de usuário, mantendo o contexto do modelo de dados em mente, e deve formular a consulta SQL adequadamente.

Capacidade de trabalhar com esquemas de banco de dados e modelos de dados ambíguos - Os modelos de dados de produção tendem a ser caóticos, com várias equipes diferentes dentro de uma organização contribuindo para eles e os dados mudando de propriedade diversas vezes ao longo de seu ciclo de vida.

Um bom mecanismo text2SQL deve ter a capacidade de desambiguar o modelo de dados para o usuário e garantir que o ruído e a ambiguidade não levem a alucinações, uma característica dos LLMs atuais que afasta muitos usuários de produção.

Ele deve garantir que o funcionamento do mecanismo não adicione latências significativas à execução da consulta - Respostas que um usuário espera em tempo real devem retornar em tempo real. Isso significa que o mecanismo deve formular consultas ótimas dentro das três primeiras tentativas, no máximo.

Apresentando SherloQ

SherloQ é o mecanismo text2SQL da Skypoint que traduz consultas de linguagem natural para SQL. Embora alavancar um (LLM) interno personalizado para geração de consultas seja uma parte significativa de sua arquitetura, a eficácia do SherloQ vem de uma combinação de componentes avançados projetados para aprimorar os recursos de consulta de dados. O SherloQ ostenta alta precisão na tradução de consultas, tratamento de erros robusto e integração perfeita com sistemas de banco de dados de produção, tornando-o adequado para ambientes de dados em larga escala.

Nas próximas seções, nos aprofundaremos nos detalhes arquitetônicos internos do SherloQ e compartilharemos alguns dos resultados que alcançamos usando-o em ambientes de produção.

Componentes arquitetônicos do SherloQ

A arquitetura do SherloQ contém várias peças móveis que trabalham cada uma para melhorar a precisão, confiabilidade e latência do sistema. Aqui está uma visão geral da arquitetura:

Entrada do usuário - A entrada do usuário é uma consulta em linguagem natural.

Agente de estado Eeecutor - Nossa implementação de uma interface LangChain que rastreia o estado durante todo o processo de execução. Ele aproveita o Redis e o DataStax Astra DB para rastrear o estado do raciocínio e da memória durante a execução. O executor gerencia o fluxo de operações coordenando entre diferentes módulos.

Ele garante que as entradas do usuário sejam corretamente analisadas, processadas e encaminhadas para componentes subsequentes, mantendo um fluxo da entrada até a geração da consulta SQL.

Ferramenta de estado - Uma classe estendida da Ferramenta Base Langchain que tem uma variável de estado e passa esse estado para a respectiva ferramenta. Ao manter uma variável de estado, a ferramenta de estado mantém o controle dos dados necessários que precisam ser encaminhados para as respectivas ferramentas. Isso garante consistência no fluxo de dados, evitando qualquer perda de informações durante a transição entre agentes.

As ferramentas de estado do SherloQ :

• A ferramenta de geração de consultas usa as consultas de poucos disparos recuperadas, o contexto do modelo de dados e o esquema do BD para gerar a consulta SQL inicial. Ela aprimora a precisão e a relevância das consultas SQL geradas usando informações de esquema analisadas e aprendendo com exemplos contextuais.

• A ferramenta de repetição analisa qualquer erro gerado durante a execução da consulta e regenera uma consulta que aborda o erro.

• A ferramenta DB ajuda a buscar o esquema do banco de dados e metadados correspondentes (anotações, comentários, etc.) que seriam úteis para a geração da consulta. As informações do esquema recuperadas são armazenadas em cache usando um mecanismo de cache baseado em tempo para otimizar o desempenho e reduzir as consultas ao banco de dados. Ela também executa a consulta no banco de dados e retorna os resultados ou um rastreamento de pilha de erros.

Entradas de dados e técnicas para melhorar o desempenho do SherloQ

Para melhorar o desempenho do SherloQ, empregamos várias técnicas e fornecemos ao modelo entradas de dados importantes. Elas consistem em decomposição estruturada, exemplos de poucos disparos, recuperação de contexto do modelo de dados, reflexão e um mecanismo de repetição. Cada parte é essencial para melhorar a capacidade do modelo de produzir consultas SQL precisas e relevantes a partir de entradas de linguagem natural.

Decomposição Estruturada

Na decomposição estruturada, o prompt do usuário é dividido em suas partes fundamentais. Focar e identificar os componentes essenciais da consulta ajuda o modelo a produzir SQL preciso. Por exemplo:

Entrada: Qual é a quantidade atual disponível para todos os itens fornecidos pela XYZ Corp?

Saída: ["quantidade atual disponível", "todos os itens", "fornecido pela XYZ Corp"]

Exemplos de poucos tiros

O modelo recebe perguntas de referência na forma de alguns exemplos de SQL, que o ajudam a gerar consultas SQL com base em padrões semelhantes. Esses exemplos melhoram a capacidade do modelo de gerar com precisão novas consultas SQL para vários prompts, ajudando-o a reconhecer a estrutura e o formato das consultas pretendidas. Aqui estão alguns exemplos:

Exemplo 1

Entrada: Mostrar itens com quantidade inferior a 20 unidades disponíveis.

Saída: SELECT * FROM estoque ONDE Quantidade_Disponível < 20;

Exemplo 2

Entrada: Liste fornecedores com itens com preços acima de US$ 100.

Saída: SELECIONE * DE fornecedores ONDE ID_do_fornecedor EM (SELECIONE ID_do_fornecedor DE itens ONDE Preço_unitário > 100);

Selecionamos dinamicamente os exemplos de poucos disparos mais semelhantes usando correspondência de similaridade semântica do Astra DB, que é nosso banco de dados vetorial. O banco de dados vetorial nos permite encontrar os exemplos que são mais próximos em estrutura e conteúdo da nova consulta de entrada, garantindo que o modelo possa alavancar os padrões mais relevantes para gerar consultas SQL precisas.

Em nosso ambiente de produção, temos uma média de cerca de dois exemplos de few-shot por consulta. Em nossa experiência, simplesmente adicionar mais exemplos de few-shot para melhorar a precisão não é uma prática escalável.

Contexto do modelo de dados

O contexto do modelo de dados contém detalhes específicos do domínio que podem ser úteis na criação de uma consulta SQL. Por exemplo, no contexto de dados financeiros para uma rede hospitalar, podem ser coisas como códigos de métricas financeiras e suas descrições. Esse contexto é usado pelo modelo para garantir que as consultas SQL criadas correspondam à estrutura de dados do domínio. A inclusão do contexto do modelo de dados é opcional e é necessária somente quando a tabela é complexa e requer conhecimento do domínio para formar uma consulta SQL.

Por exemplo:

Códigos métricos: " MGMTFEE " -> Descrição: "Taxas cobradas pela administração de propriedades – Taxas de administração"

Esquema de banco de dados SQL

O esquema SQL DB é a representação estruturada dos dados disponíveis. O esquema é enriquecido pela anotação da tabela e de suas colunas. Ele inclui nomes e descrições de tabelas, juntamente com as colunas, suas descrições e tipos de dados.

Fornecer o esquema ajuda o modelo a entender a estrutura do banco de dados e o significado associado a cada tabela e coluna, garantindo que as consultas SQL geradas estejam sintaticamente corretas e utilizem os elementos corretos do banco de dados.

Reflexão

Reflexão se refere à capacidade do modelo de avaliar e avaliar suas próprias respostas passadas, comportamento ou conteúdo gerado. Ela permite que o modelo refine suas respostas identificando e corrigindo erros ou fraquezas. O processo inclui considerar consultas vistas anteriormente pelo mecanismo Sherloq, juntamente com feedback durante a fase de geração de consultas.

Esses cenários ajudam o modelo a replicar os sucessos ou evitar as falhas de perguntas semelhantes que ele viu no passado. Esta etapa também aproveita o Astra DB para encontrar as consultas semanticamente mais semelhantes à atual.

Mecanismo de repetição

O SherloQ incorpora um mecanismo de repetição usando os erros recebidos do banco de dados. Quando uma consulta SQL gerada resulta em um erro, o mecanismo usa um agente com um modelo predefinido para corrigir a consulta:

“””

Sua tarefa é corrigir uma consulta SQL incorreta gerada a partir de uma pergunta para torná-la compatível com ANSI SQL. Siga estas diretrizes: Analise cuidadosamente a pergunta, o esquema do banco de dados e a mensagem de erro recebida para garantir respostas precisas. Utilize Table Aliases para evitar confusão.

Por exemplo, SELECT t1.col1, t2.col1 FROM table1 AS t1 JOIN table2 AS t2 ON t1.id = t2.id .

Ao calcular rações, sempre converta o numerador para um float. Use o formato abaixo:

Tarefa:

Gere uma consulta SQL para responder à pergunta [QUESTION] {user_input} [/QUESTION] A consulta a ser correta é: {sql_query} A mensagem de erro recebida durante a última execução é: {error_message}

Resposta:

Com base nas entradas acima, aqui está a consulta SQL corrigida: {response_sql} “””

Comparando resultados: antes e depois da implementação do SherloQ

Com o uso de LLMs avançados e um sistema bem projetado, o SherloQ produz consultas SQL que são mais precisas e relevantes para o contexto. Aqui, comparamos os resultados dos prompts do usuário antes e depois do SherloQ usando as métricas de latência e precisão.

Comparação usando uma questão de produção

Aqui, olhamos para um dos nossos clientes de produção, um conhecido operador de moradia para idosos. Um dos seus casos de uso é a equipe financeira usando a plataforma da Skypoint para entender e raciocinar sobre as métricas financeiras consolidadas de suas diferentes instalações de moradia para idosos.

Solicitação do usuário: "Determine a tendência trimestral das despesas de limpeza do gerente de instalações ao longo de 2022."

Antes de SherloQ

• Consulta gerada

  • SELECIONE SOMA(Numerador_do_Valor_Total) / SOMA(Denominador_do_Valor_Total) COMO DESPESAS_DE_Limpeza DE skypoint_metric_fact_denormalized_vw ONDE Nome_da_Instalação = 'CM' E Ano = 2022 E Nome_da_Métrica = 'Despesa_de_Limpeza' AGRUPAR POR Número_do_Trimestre';

    
    

• Problemas identificados

  • A consulta agrupa por Quarter_Number, mas não o seleciona, o que pode causar resultados incompletos.

  • Uso de Metric_Name em vez de um identificador mais específico como Metric_Code.

  • A divisão potencial por zero não é manipulada em SUM(Total_Amount_Denominator).

    
    

• Latência média: 29 segundos

  A configuração anterior ao SherloQ usava uma combinação de GPT-3.5 junto com engenharia de prompt e mais de 5 consultas de poucos disparos por prompt do usuário.

Com SherloQ

• Consulta gerada

  • SELECIONE Ano, Número_Trimestre, SOMA(Numerador_Valor_Total) / COALESCE(SOMA(NULLIF(Denominador_Valor_Total,0)),1) COMO Despesas_de_Limpeza DE skypoint_metric_fact_denormalized_vwONDE Código_Métrica = 'EXPOTHHOU' E Nome_Instalação = 'CM' E Ano = 2022 AGRUPAR POR Número_Trimestre, Ano ORDEM POR Número_Trimestre ASC;

    
    

• Melhorias observadas
• A consulta inclui Quarter_Number, fornecendo o detalhamento trimestral necessário.
• O campo Metric_Code é usado, fornecendo um identificador mais preciso para a métrica.
• A função COALESCE(SUM(NULLIF(Total_Amount_Denominator,0)),1) manipula possíveis erros de divisão por zero.
• Os resultados são ordenados por Quarter_Number para refletir a tendência trimestral.
• Latência média: 10 segundos

Com base em benchmarks em cargas de trabalho de produção, abaixo estão os resultados que relatamos sobre precisão e confiabilidade antes e com o SherloQ:

• Antes de SherloQ

  • Precisão: 65%

  • Confiabilidade: 60%

    
    

• Com SherloQ

  • Precisão: 92%

  • Confiabilidade: 90%

    
    

Os resultados acima foram extraídos de um conjunto de benchmark interno que executa cada prompt 100 vezes com identificadores separados para negar os efeitos do cache (em nossos sistemas internos, bem como nos modelos). O conjunto mede a precisão comparando a resposta retornada com uma resposta de benchmark e a confiabilidade medindo com que frequência ele retornaria respostas semelhantes.

A comparação ilustra claramente as vantagens do SherloQ em transformar consultas de linguagem natural em consultas SQL precisas. O desempenho geral melhorou em 30% após o SherloQ. As consultas geradas anteriormente sofreram com problemas como resultados incompletos e falta de tratamento de erros, impactando tanto a precisão quanto a confiabilidade.

Com o SherloQ, as consultas geradas são mais precisas, eficientes e robustas, com melhorias notáveis em latência, precisão e confiabilidade. Esse aprimoramento mostra a capacidade do SherloQ de fornecer recuperação de dados confiável, tornando-o uma ferramenta valiosa para organizações que buscam otimizar seus processos de consulta de dados.

Para explorar outras partes da plataforma Skypoint ou reservar uma demonstração do SkyPoint AI, visite o site do Skypoint .

Por Alok Raj, engenheiro-chefe de IA, Skypoint, e Sayandip Sarkar, chefe de engenharia, Skypoint