text to sql bedrock workshop
Module 4: Security for Text-to-SQL
Os data warehouses empresariais representam muitos dos maiores investimentos em tecnologia para empresas de todos os setores nos últimos 20 anos. Embora a IA generativa tenha se mostrado muito promissora na criação de novos conteúdos e na compreensão de grandes corpora de informações em formato não estruturado, como ela melhorará o consumo dos dados que as organizações investiram tanto para torná-los úteis? Essas fontes de dados estão entre as mais confiáveis em uma organização e, em muitos casos, orientam decisões nos mais altos níveis de liderança.
Desde a sua criação na década de 70, a Structure Query Language (SQL) tem sido a linguagem mais onipresente para interagir com bancos de dados, mas ainda é necessário um conhecimento profundo da teoria dos conjuntos, tipos de dados e relacionamentos de chave estrangeira para entender os dados. . A IA generativa oferece uma maneira de preencher essa lacuna de conhecimento e habilidades, traduzindo perguntas em linguagem natural em uma consulta SQL válida.
Os sistemas e pessoas que podem se beneficiar desse padrão de acesso aos bancos de dados incluem pessoas não técnicas que buscam incorporar fontes de dados relacionais em seus processos, como agentes de atendimento ao cliente e associados de call center. Além disso, os casos de uso técnico incluem pipelines Extract-Transform-Load, arquiteturas existentes de Retrieval Augmented Generation (RAG) que integram bancos de dados relacionais e organizações que estão lidando com uma plataforma de dados grande demais para navegar razoavelmente isoladamente.
Os componentes mais difíceis de criar uma consulta SQL precisa a partir da linguagem natural são os mesmos com os quais poderíamos ter lutado quando recém-chegados à linguagem. Conceitos como identificar relacionamentos de chave estrangeira, dividir a questão em consultas menores e aninhadas e unir tabelas adequadamente estão entre os componentes mais difíceis da geração de consultas SQL. De acordo com os pesquisadores, mais de 50% dos testes de geração de SQL falham apenas na vinculação e junção de esquemas.
Além desses componentes principais da consulta, cada mecanismo de banco de dados possui sua própria sintaxe que pode garantir o domínio para escrever uma consulta válida. Além disso, em muitas organizações, existem muitos atributos de dados sobrepostos - um valor é agregado em uma tabela e não agregado em outra, por exemplo - bem como nomes de colunas abreviados que requerem conhecimento tribal para serem usados corretamente.
Então, quão perto estamos de resolver esse problema? A comunidade se uniu em torno de duas tabelas de classificação principais que classificam as abordagens mais bem-sucedidas com conjuntos de dados rotulados: Spider e BIRD. Ambas as tabelas de classificação priorizam a métrica mais importante para medir a precisão de qualquer abordagem para resolver esse problema, chamada Precisão de Execução (EX). Essa métrica simplesmente compara a consulta SQL gerada com a consulta SQL rotulada para determinar se há correspondência ou não. Além disso, o SPIDER mede a precisão da correspondência exata do conjunto (EM) – o conjunto de resultados retornado realmente respondeu à pergunta, independentemente de como a consulta foi escrita – e o BIRD oferece Pontuação de eficiência válida (VES), uma medida do desempenho da consulta SQL gerada. Você pode ler mais sobre cada conjunto de dados de benchmark em suas respectivas páginas.
Os conjuntos de dados Spider e BIRD provaram ser conjuntos de dados confiáveis e robustos para avaliar técnicas de texto para SQL e até mesmo ajustar modelos. Ao longo deste módulo, faremos referência a esses conjuntos de dados e seus placares correspondentes para demonstrar as abordagens mais robustas para Text-to-SQL.
De acordo com a tabela de classificação do BIRD, o estado da arte para o problema de Text-to-SQL é de 60% de precisão de execução. Embora isso ainda esteja muito aquém do desempenho humano, observe que em um ano passamos do modelo T5 de linha de base com desempenho de 7% EM para um ano depois vendo o EM exceder 60%. Estamos entusiasmados em ver como isso melhorará ainda mais no próximo ano, à medida que esses modelos e técnicas continuarem a ser pesquisados.
É importante observar que essas técnicas são otimizadas para uma única coisa: gerar a consulta SQL correta. Essas tabelas de classificação não avaliam alguns aspectos críticos dessas técnicas, principalmente a velocidade. Muitas dessas técnicas demonstram uma velocidade de cadeia de prompts de ponta a ponta de bem mais de alguns segundos, o que muitos casos de uso de business intelligence de disparo zero não conseguem tolerar. Além disso, muitos deles também fazem múltiplas inferências em um LLM para completar o raciocínio necessário, o que pode aumentar consideravelmente o custo por consulta.
Este workshop foi projetado para ser uma progressão das técnicas de Text-to-SQL, começando com uma engenharia robusta de prompts. Todo o código está na forma de Jupyter Notebooks, hospedados no SageMaker Studio. Quando estiver pronto para começar, vá para Configuração para iniciar a implantação dos recursos necessários para este workshop.
Abaixo está um resumo do conteúdo do workshop:
