Show HN: Natural-SQL-7B, um forte modelo de text-to-SQL

Artigo original ↗ Discussão no Hacker News ↗

Um novo modelo text-to-SQL de 7 bilhões de parâmetros, o Natural-SQL-7B, busca permitir que usuários não técnicos consultem bancos de dados em linguagem natural enquanto roda localmente, levantando esperanças de análises mais baratas e privadas do que soluções baseadas em GPT‑4. Comentadores questionam sua licença personalizada “source available”, seu foco atual em PostgreSQL e se uma taxa de acerto de ~75% é suficiente para uso em produção, especialmente onde a lógica de negócio e os KPIs são sutis ou específicos do domínio. Muitos veem valor em usar esses modelos como ferramentas de rascunho ou em combinação com camadas semânticas, RAG e governança forte de dados, em vez de como substitutos independentes para analistas experientes.

Capacidades e escopo do modelo

  • Modelo text-to-SQL de 7B, ajustado em ~20 mil pares sintéticos PostgreSQL texto→SQL em várias categorias de SQL e tipos de perguntas.
  • Avaliado em ~76,5% no SQL-Eval, ligeiramente abaixo de GPT‑4 e sqlcoder‑15B.
  • Atualmente focado em Postgres; há desejo e parte do planejamento para suporte mais amplo a dialectos (MySQL, DuckDB, MSSQL, BigQuery, Trino).
  • Lida com perguntas de multi-join, agregação e subconsulta que são “difíceis” para usuários não técnicos, mas não há garantia em esquemas muito complexos ou consultas com muita lógica de negócio.

Licenciamento e debate sobre “open source”

  • A licença inclui restrições de uso (por exemplo, não militar), herdadas do modelo base.
  • Vários comentaristas argumentam que isso não é “open source”, mas sim “source/weights available”.
  • Há preocupação de que licenças não padronizadas exijam revisão jurídica, em contraste com as conhecidas MIT/Apache/GPL.
  • Alguns também observam que apenas os pesos do modelo são fornecidos, não o código/dados de treinamento.

Casos de uso, precisão e confiabilidade

  • É visto como útil para:
    • Redigir SQL para desenvolvedores/analistas que possam revisar e corrigir.
    • Alimentar ferramentas locais/cli em que os esquemas não deveriam ser enviados para LLMs na nuvem.
  • Os céticos questionam o que pode ser automatizado com segurança com ~75% de acurácia, especialmente para análises e KPIs críticos para o negócio.
  • Outros observam que humanos também cometem erros; o valor está em acelerar etapas “simples”, com humanos validando os resultados.
  • Ideias levantadas: ensembles/consenso, validação via restrições fortes do banco, uso principalmente onde a correção é fácil de verificar.

Esquema, contexto e semântica

  • Contexto de 4k é pequeno demais para muitos esquemas reais; discute-se usar RAG sobre DDL ou querer contexto de 32k+.
  • Padrão típico: passar o DDL de CREATE TABLE (com comentários) como prompt; alguns usam RAG em documentação/wiki/dbt para ensinar semântica.
  • Vários argumentam que o problema real não é a sintaxe SQL, mas entender o significado dos dados (“o que realmente significa este campo ‘price’ ou ‘active’?”).
  • Há forte apoio a camadas semânticas / grafos de conhecimento / ORMs que codificam a lógica de negócio, com SQL gerado deterministicamente a partir dessa camada em vez de diretamente por LLMs.

Cloud vs local, privacidade e confiança

  • Alguns se recusam a enviar esquemas ou dados para a OpenAI, citando termos que mudam, preocupações regulatórias ou possível acesso governamental.
  • O Azure OpenAI é visto por alguns como mais seguro, mas ficando atrás em recursos/modelos.
  • A configuração local, com pesos disponíveis, deste modelo é atraente para quem tem restrições de privacidade ou governança.

Reflexões mais amplas sobre SQL e ferramentas

  • Debate sobre aprender SQL versus depender de ORMs ou LLMs; muitos enfatizam o valor duradouro do SQL e seus benefícios de desempenho.
  • Outros destacam problemas de ergonomia do SQL e preferem abstrações.
  • Vários observam que LLMs já são úteis para explicar SQL complexo, depurar erros e gerar consultas difíceis com window functions/percentis.