NaturalSQL-7B - um modelo poderoso que converte linguagem natural em SQL

• Alcançou 76,5% no SQL-Eval, mostrando o melhor desempenho em sua faixa de tamanho de modelo
  • Fica abaixo do GPT-4 (83%), mas supera GPT-3.5-Turbo (65%) / Claude-2 (64,5%)
  • Fica acima do sqlcoder-7b (71%) e próximo do sqlcoder-15b (78%)
• Também foi desenvolvido o ChatDB, uma ferramenta que permite criar dashboards no-code sem precisar escrever SQL

Exemplo

• Pergunta: Determine o cliente com o maior valor total de pedidos no mês passado e liste todos os produtos e quantidades que ele pediu.
• Saída:

  WITH LastMonthOrders AS (  
    SELECT o.customerid, o.orderid, op.productid, op.quantity, p.productname, op.quantity * p.unitprice AS total_order_value  
    FROM orders o  
    JOIN order_details op ON o.orderid = op.orderid  
    JOIN products p ON op.productid = p.productid  
    WHERE o.orderdate >= date_trunc('month', CURRENT_DATE) - INTERVAL '1 month'  
    AND o.orderdate < date_trunc('month', CURRENT_DATE)  
  ),  
  CustomerTotalOrderValue AS (  
    SELECT customerid, SUM(total_order_value) AS total_value  
    FROM LastMonthOrders  
    GROUP BY customerid  
    ORDER BY total_value DESC  
    LIMIT 1  
  )  
  SELECT c.customerid, c.companyname, lm.productid, lm.productname, lm.quantity  
  FROM CustomerTotalOrderValue ctov  
  JOIN LastMonthOrders lm ON ctov.customerid = lm.customerid  
  JOIN customers c ON c.customerid = lm.customerid;  
  

• O NaturalQuery lida muito bem com perguntas complexas como a acima, subqueries e proporções.

[xguru]

Comentários no Hacker News

• A pontuação de desempenho no SQL-Eval é de 76,5%, ficando um pouco atrás dos 83% do GPT-4 e dos 78% do sqlcoder-15b.

  • Em que tipos de aplicação um estagiário de ciência de dados em IA como esse poderia ser útil? O que dá para construir com uma IA com 75% de precisão?
  • Como programador que consulta referências com frequência ao trabalhar com SQL, acho que daria para usar uma IA dessas para criar o primeiro rascunho da query.
  • Modelos maiores podem dar resultados melhores em um caso isolado, mas é fácil rodar um modelo 15b em um m1 com 64GB.
  • Em ambientes corporativos, às vezes você não quer vazar informações de esquema para os dados de treinamento da OpenAI e também quer executar queries offline.
  • Quando você quer executar muitas queries, um modelo pequeno e local é útil por reduzir custos.
  • Seria incrível ter um mini cientista de dados para que pessoas não técnicas também possam fazer consultas, mas fico me perguntando como decidir se a query está entre os 25% de casos "incorretos".
  • Talvez dê para aumentar a taxa geral de sucesso com um algoritmo de consenso estilo RAID, em que várias IAs validam as respostas umas das outras.
  • Em grande parte estou só organizando essas ideias, mas talvez outras pessoas tenham mais sugestões. Parabéns ao OP pelo lançamento!

• Acho que os modelos de text-to-SQL não estão resolvendo o problema certo.

  • A parte difícil não é a sintaxe nem saber como escrever uma query com group by, e sim entender o significado dos dados.
  • Ao olhar para uma tabela do Snowflake com 50 colunas, não dá para adivinhar o que são só pelos nomes das colunas.
  • Por exemplo, quando há uma tabela com 10 colunas todas chamadas algo como ...price, você precisa procurar no wiki ou ler as definições no DBT para entender o que realmente significam.
  • Não dá para confiar nas queries geradas pelo modelo; ele entende a sintaxe da query, não os dados.

• Apontam que isso não é open source; como há restrições baseadas no uso, eu chamaria de "source-available".

• Isso é interessante e é uma área que me interessa, mas não acho que seja uma pergunta complexa; é uma questão básica de análise.

  • A maioria dos analistas consegue escrever esse tipo de coisa dormindo.
  • Já tentei usar o ChatGPT para escrever SQL e achei mediano, embora claramente vá melhorar.

• Como muitos usos de IA, isso é muito bom como "semente", especialmente para sugerir ideias como agrupar por faixas.

  • Mas, em quase todo banco de dados, o problema está nos detalhes.
  • Produtos diferentes interpretam "quantidade" de formas diferentes (por exemplo, caixa vs. unidade), cupons e descontos são modelados de maneiras estranhas, peso é assumido em libras/quilogramas e misturado sem indicação de unidade etc.

• Quem diz que isso é inútil por ser preciso só em 75% deveria considerar duas coisas:

  • Essa é a primeira versão e já é mil vezes mais útil para product owners e analistas do que qualquer Airtable que você possa imaginar.
  • Todo mundo quer precisão em todos os desafios, mas já vivemos numa economia do "bom o suficiente", e se isso chegar perto o bastante, provavelmente já será bom o bastante para o negócio.

• Fico curioso para saber como ele se sai no Bird, que é um benchmark mais complexo e realista.

• Pela minha experiência trabalhando com dados, muita gente recebe perguntas da diretoria, precisa entender bem o data warehouse para escrever o SQL que responde a essas perguntas e, às vezes, ainda entregar a resposta em um formato bonito.

  • Às vezes também é preciso antecipar perguntas de acompanhamento da diretoria, como "por que esse número está tão baixo? claramente não deveria estar tão baixo", então é necessário pedir ao engenheiro de dados que verifique se há algum bug.
  • Como acontece com todos os LLMs, não sei se isso vai apenas tornar essa responsabilidade muito mais fácil ou eliminá-la por completo.

• Muito legal, embora a licença não seja padrão, então passa uma aparência de open source.

  • O modelo em si pode ser encontrado aqui: NaturalSQL-6.7B-v0
  • Parece um ótimo modelo base, mas fico em dúvida se text-to-sql é um bom caso de uso para modelos pequenos.
  • Também estamos desenvolvendo ferramentas nessa área e gostaríamos de poder usar o gpt-4 por confiar mais nas respostas dele. Até mesmo o gpt 3.5 ainda não é suficiente para produção.

• Muito legal, mas fico me perguntando se essa licença permitiria o uso com o Vanna: Vanna