SIQL — NL-to-SQL

O NL-to-SQL do SIQL transforma uma pergunta escrita em português num SELECT válido sobre as tabelas certas do lakehouse, ancorado na ontologia e no knowledge graph da plataforma. Escrever SQL para um lakehouse que você não conhece de cor significa abrir o catálogo, adivinhar nomes de tabela e torcer. Aqui você digita "mostre transações suspeitas em 2024" e recebe o SQL pronto — com trilhos de governança de fábrica: somente leitura, sempre limitado, restrito ao escopo semântico resolvido e nunca executado automaticamente. Você revisa, copia e decide.

Onde fica: aba NL-to-SQL em Descobrir›Intelligent Query Layer. Requer a permissão SIQL:ADMIN.

Como funciona

O caminho da pergunta ao SQL, em nove etapas:

1. A pergunta é quebrada em termos relevantes (as palavras vazias são descartadas).
2. Cada termo é casado com os conceitos da ontologia — só entram correspondências com pontuação a partir de 0,6.
3. Os conceitos resolvem, no grafo semântico, as tabelas do escopo; a união de todas elas forma a lista de "Tabelas Resolvidas".
4. O modelo de linguagem recebe a pergunta acompanhada dessa lista fechada — e só pode usar as tabelas que estão nela.
5. A resposta volta estruturada, com o SQL, a confiança, a explicação e as tabelas efetivamente referenciadas.
6. O SQL passa pela validação de somente leitura — qualquer comando de escrita, DDL ou múltiplos comandos na mesma resposta é rejeitado.
7. Um LIMIT é injetado ou ajustado para o teto configurado.
8. A plataforma confere que as tabelas referenciadas estão contidas nas Tabelas Resolvidas; fora disso, a resposta é descartada.
9. A geração fica registrada na auditoria.

Em nenhum momento o sistema executa o SQL — você copia e cola onde quiser.

Trilhos de segurança

1. Somente leitura — INSERT, UPDATE, DELETE, DROP, ALTER, MERGE, TRUNCATE, CREATE, GRANT, REVOKE, REPLACE, UPSERT, LOAD, COPY, EXECUTE, EXEC e CALL são rejeitados, assim como qualquer resposta com mais de um comando.
2. Limite rígido — LIMIT sempre presente; o teto é configurável em datta.siql.semantic.nl-to-sql.max-limit (padrão 10 000 linhas).
3. Escopo fechado — se o SQL referenciar tabela fora da lista resolvida, a resposta é rejeitada e marcada como degradada (degraded=true).
4. Limite de uso — 30 gerações por hora por usuário, controladas por um contador distribuído com fallback em memória.
5. Auditoria exaustiva — os eventos SIQL.NL_TO_SQL_* cobrem gerado, rejeitado, falha de interpretação da resposta, modelo degradado, fora-de-escopo, bloqueio por limite de uso e nenhuma tabela resolvida.
6. Privacidade — o prompt não inclui dados do usuário, apenas a pergunta e o esquema/ontologia. Qualquer dado pessoal que apareça na explicação é mascarado antes de ser exibido.

Usando a aba NL-to-SQL

1. Abra Descobrir›Intelligent Query Layer e clique na aba NL-to-SQL.
2. Digite a pergunta no campo de texto — por exemplo, "top 10 processos por valor".
3. Clique em Gerar SQL.
4. O resultado aparece com o SQL em destaque e etiquetas com a confiança, o custo estimado e as entidades resolvidas:

SELECT * FROM hive.public.processos ORDER BY valor DESC LIMIT 10

1. Revise. Se estiver bom, clique em Copiar SQL — o SQL vai para a área de transferência e não é executado pela tela.
2. Execute no cliente que preferir (Trino, DATTAX) quando e como quiser.

O SQL gerado é dialeto Trino 480.

O que esperar do resultado

A meta de acurácia é de pelo menos 75% num conjunto de 20 perguntas representativas do domínio. Nos cinco exemplos acima, a acurácia observada foi de 4 em 5 (80%) — contando o bloqueio da última como o comportamento correto. É justamente por isso que a revisão humana faz parte do fluxo: a confiança e a explicação são exibidas para apoiar a sua decisão.

Solução de problemas

A geração também está disponível por API para integrações administrativas, com a mesma permissão e o mesmo limite de 30 chamadas por hora — veja a referência de API.