Felipe Barros de Paula Leite; Anderson Canale Garcia

DOI: 10.22167/2675-6528-202600775

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

Equipes de sustentação de sistemas enfrentam desafios diários na criação e execução manual de scripts SQL, um processo suscetível a erros, retrabalho e inconsistências, especialmente em ambientes com equipes reduzidas. Com o objetivo de mitigar essas dificuldades, desenvolveu-se uma solução baseada em Inteligência Artificial para interpretar solicitações em linguagem natural e gerar scripts SQL consistentes, seguros e alinhados à estrutura real dos bancos de dados. A metodologia empregou a extração automática de metadados de bases de dados, sua estruturação padronizada e técnicas de pré-processamento para selecionar entidades relevantes. Integraram-se modelos de linguagem natural para a geração dos comandos SQL, utilizando uma estratégia de duas etapas para otimizar o contexto e reduzir custos. A avaliação da eficácia foi realizada comparando-se os scripts gerados automaticamente com consultas SQL padrão-ouro, elaboradas manualmente. Os resultados preliminares indicaram a viabilidade técnica da solução, que produziu consultas funcionalmente equivalentes ao SQL padrão-ouro na maioria dos casos. A abordagem contribuiu para a padronização da elaboração de scripts, reduziu o esforço manual e minimizou erros humanos, especialmente em cenários com bases de dados extensas, onde a estratégia de duas etapas demonstrou ser eficaz na redução do consumo de “tokens” e latência. Concluiu-se que a solução proposta possui potencial para automatizar a geração de scripts SQL de forma padronizada e segura, sendo aplicável ao contexto de equipes de sustentação de sistemas e adaptável a outros ambientes corporativos com desafios semelhantes.

Palavras-chave: Automação de Processos; Inteligência Artificial; Linguagem Natural; SQL; Sustentação de Sistemas.

1. Introdução

Equipes de sustentação de sistemas desempenham um papel crucial na gestão e manutenção de bases de dados corporativas, lidando diariamente com a criação e execução de scripts SQL. Essas operações são essenciais para garantir a integridade dos sistemas, corrigir falhas emergenciais, realizar manutenções preventivas e gerar informações gerenciais que subsidiam as áreas administrativas e judiciais. No contexto do Tribunal Regional do Trabalho da 21ª Região (TRT21), a demanda por esses scripts é constante e vital para o funcionamento eficiente da instituição.

Contudo, a elaboração manual de scripts SQL apresenta desafios significativos. O processo é frequentemente dependente da experiência individual de cada analista, o que pode levar a inconsistências, retrabalho e falhas capazes de comprometer a integridade e a disponibilidade dos sistemas. Essa dependência do conhecimento tácito de cada profissional dificulta a padronização das atividades e a mensuração da produtividade, especialmente em equipes reduzidas ou que operam em regime de trabalho remoto, onde a heterogeneidade nas abordagens de resolução de problemas se acentua.

Uma parcela considerável das solicitações de scripts SQL envolve tarefas repetitivas, que exigem apenas a alteração de parâmetros específicos, como datas ou identificadores. A execução manual dessas tarefas consome um tempo valioso dos analistas e aumenta a probabilidade de erros humanos. Além disso, a equipe de sustentação do TRT21, sendo reduzida, enfrenta dificuldades operacionais em cenários de ausência de membros, resultando em acúmulo de chamados, aumento do “backlog” e, consequentemente, no descumprimento dos Acordos de Nível de Serviço (SLA). A automação desses processos pode liberar a equipe para atividades de maior valor técnico e analítico (Centenaro, 2025).

Nesse cenário, a Inteligência Artificial (IA) emerge como uma solução promissora para automatizar tarefas repetitivas e reduzir erros humanos na Engenharia de Software (Russell e Norvig, 2021). Modelos de linguagem natural, particularmente aqueles baseados em arquiteturas transformadoras, demonstram capacidade de converter instruções textuais em comandos estruturados, como a geração automática de código SQL (Zhang et al., 2023; OpenAI, 2024). A utilização de Large Language Models (LLMs) “open source” também oferece alternativas acessíveis e eficientes para traduzir linguagem natural em consultas SQL, potencializando a automação de processos (Evangelista, 2023).

A integração de módulos de conversão de linguagem natural para SQL em sistemas corporativos pode aumentar significativamente a eficiência na execução de tarefas repetitivas (Endrizzi, 2024). Essa abordagem permite que solicitações expressas em linguagem natural sejam transformadas em instruções SQL consistentes, seguras e auditáveis, alinhadas à estrutura real dos bancos de dados. A capacidade de interpretar o contexto e os metadados do banco de dados, como tabelas, colunas e relacionamentos, é fundamental para garantir a precisão e a confiabilidade dos scripts gerados, superando as limitações da elaboração manual e promovendo maior padronização.

Diante da problemática da elaboração manual de scripts SQL, que gera inconsistências, retrabalho e sobrecarga para as equipes de sustentação, e considerando o potencial da Inteligência Artificial para otimizar esses processos, este trabalho propõe o desenvolvimento de uma solução baseada em IA capaz de interpretar solicitações em linguagem natural e gerar automaticamente scripts SQL consistentes, seguros e alinhados à estrutura real dos bancos de dados, a partir de informações estruturais obtidas do banco de dados, conforme a abordagem adotada, com aplicação prática na realidade do TRT21.

2. Material e Métodos

A pesquisa caracterizou-se como um estudo aplicado, de natureza prática e experimental, focado no desenvolvimento de uma solução computacional. O objetivo foi automatizar a geração de scripts SQL a partir de solicitações em linguagem natural. O trabalho foi conduzido com base em conhecimentos de Inteligência Artificial, Engenharia de Software e integração de sistemas, aplicado ao contexto do Tribunal Regional do Trabalho da 21ª Região (TRT21).

A solução foi desenvolvida como um sistema web, composto por uma aplicação “frontend” e um “backend”. O “frontend” foi construído com o “framework” Angular, enquanto o “backend” utilizou a linguagem Python e o “framework” FastAPI. Essa arquitetura permitiu centralizar a comunicação com modelos de IA, aumentar a segurança no uso de “tokens” e incorporar funcionalidades adicionais, facilitando testes iterativos.

Para a definição da estrutura de dados que suportaria a geração dos scripts SQL, implementaram-se duas abordagens. A primeira, o modo tradicional, permitiu a conexão direta a bancos de dados PostgreSQL e Oracle. Realizou-se a extração automática de metadados, como tabelas, colunas, tipos de dados, chaves primárias, chaves estrangeiras e comentários, para formar um dicionário de dados estruturado.

No modo tradicional, o usuário podia configurar a geração de um resumo auxiliar com informações sintéticas das tabelas, usado como contexto inicial para identificação de entidades relevantes. O sistema também ofereceu um campo para inserção de instruções contextuais relacionadas ao domínio da aplicação. Um recurso assistido por IA foi empregado para analisar e sugerir comentários em tabelas com descrições ausentes.

A segunda abordagem, o modo Model Context Protocol (MCP), integrou-se especificamente com bancos PostgreSQL. Nessa modalidade, a Inteligência Artificial consultou diretamente a estrutura do banco de dados durante a geração do script SQL. Isso eliminou a necessidade de extração prévia de metadados ou preparação de dicionário, requerendo apenas os parâmetros de conexão com o banco.

Os metadados extraídos foram padronizados em um dicionário estruturado em formato JSON, onde cada tabela era representada como um objeto contendo identificação, descrição, colunas e relacionamentos. Para otimizar custo e volume de contexto em bases de dados extensas, implementou-se um fluxo de geração em duas etapas, utilizando um resumo auxiliar das tabelas na primeira etapa e um dicionário filtrado na segunda, alinhado ao conceito de Retrieval-Augmented Generation (RAG).

A geração dos scripts SQL foi orientada por “prompts” padronizados, contendo regras explícitas para reduzir ambiguidades e evitar a criação de elementos inexistentes. Os “prompts” impunham restrições como o uso exclusivo do “schema” fornecido, a preservação dos nomes originais e a obrigatoriedade de saída em SQL puro. Instruções contextuais foram incorporadas para fornecer informações de domínio ao modelo.

Durante o desenvolvimento, diversos modelos de linguagem natural foram avaliados, incluindo OpenAI (GPT-5.2), Gemini e modelos “open source” via Ollama. O GPT-5.2 foi selecionado como principal modelo para a geração de SQL. Sua escolha baseou-se na maior capacidade de contexto, suporte a entradas extensas e desempenho superior na interpretação de estruturas de dados complexas.

A eficácia da solução foi avaliada por um procedimento de comparação entre consultas SQL geradas automaticamente pelo sistema e consultas SQL consideradas padrão-ouro. As consultas padrão-ouro foram elaboradas manualmente pelo autor. O conjunto de testes consistiu em solicitações em linguagem natural que representavam demandas recorrentes da equipe de sustentação de sistemas.

Os critérios de avaliação incluíram validade sintática da consulta, equivalência semântica dos resultados, uso correto de relacionamentos entre tabelas e aplicação adequada de filtros. Uma consulta foi considerada correta se apresentasse equivalência funcional ao SQL padrão-ouro, mesmo com diferenças sintáticas. A acurácia da solução foi calculada como a proporção de consultas corretamente geradas em relação ao total de casos de teste, seguindo metodologia similar a avaliações de sistemas NL2SQL.

3. Resultados e Discussão

A presente seção detalha os achados da pesquisa, abrangendo a implementação e a arquitetura da solução desenvolvida, bem como os resultados preliminares obtidos na avaliação das consultas SQL geradas. A abordagem adotada visou mitigar os desafios inerentes à elaboração manual de scripts SQL em equipes de sustentação de sistemas, propondo uma alternativa baseada em Inteligência Artificial. Os resultados demonstram a viabilidade técnica da solução e seu potencial para promover maior padronização, segurança e eficiência na gestão de bases de dados, conforme o objetivo central do estudo. A discussão dos achados é fundamentada na metodologia aplicada e na literatura pertinente, buscando contextualizar as contribuições e limitações observadas.

A solução foi concebida com uma arquitetura robusta, dividida em um “frontend” e um “backend”, visando otimizar a interação do usuário e o processamento das solicitações. O “frontend”, desenvolvido com o “framework” Angular, estrutura a interação em três etapas cruciais: a configuração da chave de acesso aos modelos de Inteligência Artificial, a definição do dicionário de dados que serve como base para a geração dos scripts, e a submissão da solicitação em linguagem natural para a geração do comando SQL. Essa modularidade permitiu um desenvolvimento iterativo e ajustes contínuos, garantindo a flexibilidade necessária para adaptar a ferramenta a diferentes provedores de IA e cenários de uso.

Na etapa de configuração da chave de acesso, a solução oferece a flexibilidade de escolha entre diversos provedores de modelos de linguagem, incluindo opções como OpenAI, Claude, Gemini, DeepSeek, e até mesmo provedores locais. Essa capacidade de integração é fundamental para que as equipes de sustentação possam selecionar a ferramenta mais adequada às suas necessidades e políticas de segurança. A maioria dos testes de avaliação foi realizada utilizando modelos da OpenAI, especificamente o GPT-5.2, devido à sua capacidade avançada de processamento e ao limite superior de “tokens”, característica essencial para lidar com bases de dados que contêm mais de cem tabelas, um cenário comum em ambientes corporativos complexos.

A definição da estrutura de dados, que é o pilar para a geração precisa dos scripts SQL, foi implementada por meio de duas abordagens distintas. A primeira, denominada modo tradicional, permite a conexão direta a bancos de dados PostgreSQL e Oracle. Essa funcionalidade automatiza a extração de metadados, englobando tabelas, colunas, tipos de dados, chaves primárias e estrangeiras, além de comentários associados. A partir desses dados, o sistema constrói um dicionário de dados estruturado, que serve como referência para a IA. Essa automação reduz significativamente o esforço manual e a propensão a erros, que são comuns em processos de entrada de dados manuais.

No modo tradicional, o usuário tem a opção de configurar a geração de um resumo auxiliar das tabelas, que contém informações sintéticas e é utilizado como contexto inicial. Este resumo é crucial para a identificação de entidades relevantes em bases de dados extensas, otimizando o processo de geração de scripts. Adicionalmente, o sistema oferece um campo para a inserção de instruções contextuais, permitindo que o usuário forneça informações de domínio ou regras de negócio específicas. Esse recurso aprimora a aderência das consultas geradas às particularidades do ambiente, garantindo que os scripts sejam não apenas sintaticamente corretos, mas também semanticamente alinhados às necessidades da organização.

Um recurso assistido por Inteligência Artificial foi incorporado para analisar tabelas que carecem de comentários ou possuem descrições genéricas. Essa funcionalidade visa apoiar a documentação do banco de dados, sugerindo descrições mais informativas e precisas com base na estrutura das tabelas e seus relacionamentos. A melhoria na documentação do banco de dados é um benefício secundário, mas significativo, que contribui para a manutenção e compreensão do sistema a longo prazo, facilitando o trabalho das equipes de sustentação e reduzindo a dependência do conhecimento tácito.

A segunda abordagem para a definição da estrutura de dados é o modo Model Context Protocol (MCP), implementado especificamente para bancos de dados PostgreSQL. Nesta modalidade, a Inteligência Artificial consulta diretamente a estrutura do banco de dados durante o processo de geração do script SQL. Isso elimina a necessidade de extração prévia de metadados, criação de dicionário estruturado ou preparação de contexto textual auxiliar por parte do usuário. Embora simplifique a interação, o modo MCP apresenta restrições de compatibilidade, sendo limitado a bancos PostgreSQL e a modelos de linguagem que suportam essa integração, como OpenAI e Claude.

O “backend” da solução foi desenvolvido em Python, utilizando o “framework” FastAPI, com o propósito de centralizar a comunicação com os modelos de Inteligência Artificial. Essa arquitetura visa aumentar a segurança no gerenciamento dos “tokens” de acesso e permitir a incorporação de funcionalidades adicionais, como regras de processamento e controle de fluxo de dados. A separação entre “frontend” e “backend” demonstrou ser eficaz para garantir maior controle sobre as informações enviadas aos modelos de linguagem, otimizando a performance e a segurança da aplicação.

Ao longo do desenvolvimento do sistema, diversas estratégias para disponibilizar a estrutura do banco de dados ao modelo de linguagem foram avaliadas. Inicialmente, a inserção manual do dicionário de dados por meio de texto livre revelou-se suscetível a erros e ineficiente para bases de dados extensas. Posteriormente, a funcionalidade de upload de arquivos para descrição do dicionário também apresentou limitações relacionadas ao tamanho e à confiabilidade das informações. Essas dificuldades levaram à adoção da conexão direta ao banco de dados como estratégia principal, que se mostrou mais confiável e reduziu a dependência de entradas manuais.

A extração de metadados foi padronizada em um dicionário estruturado em formato JSON, onde cada tabela é representada como um objeto contendo informações de identificação, descrição, colunas e relacionamentos. Esse formato foi concebido para ser compatível com diferentes sistemas gerenciadores de banco de dados e para otimizar sua utilização tanto na geração direta do SQL quanto em estratégias de otimização de contexto. A padronização do dicionário de dados em JSON é crucial para a interoperabilidade da solução e para a consistência na interpretação dos metadados pelos modelos de linguagem.

Para reduzir custos operacionais e o volume de contexto enviado aos modelos de linguagem em bases de dados extensas, foi implementada uma estratégia de geração em duas etapas. Na primeira etapa, o modelo de linguagem recebe um resumo auxiliar das tabelas, que contém o nome, a descrição e, opcionalmente, colunas com comentários, chaves primárias e estrangeiras, conforme a configuração do usuário. Esse resumo permite que a IA identifique quais tabelas são potencialmente relevantes para atender à solicitação em linguagem natural, filtrando o contexto antes de enviar o dicionário completo.

A geração dos scripts SQL é orientada por “prompts” padronizados, que incluem regras explícitas para reduzir ambiguidades e evitar a criação de tabelas, colunas ou relacionamentos inexistentes. Essas regras impõem restrições, como o uso exclusivo do “schema” fornecido, a preservação dos nomes originais como símbolos atômicos e a obrigatoriedade de saída em SQL puro, garantindo que o resultado possa ser executado diretamente em ferramentas de banco de dados. A inclusão de instruções contextuais no “prompt” permite fornecer informações de domínio ou orientações de negócio ao modelo, adaptando a geração do SQL ao contexto específico da aplicação sem redefinir a estrutura do banco de dados.

Em cenários com grande volume de metadados, o sistema utiliza o fluxo de geração em duas etapas. Na primeira etapa, o modelo recebe apenas o resumo das tabelas e identifica as entidades relevantes para a solicitação. Na segunda etapa, o sistema filtra o dicionário estruturado em JSON e constrói o “prompt” final, contendo apenas o subconjunto de metadados necessários para a geração do script SQL. Esse modelo de “prompt” foi adotado para garantir previsibilidade, reduzir alucinações e aumentar a confiabilidade dos scripts SQL gerados, especialmente em ambientes corporativos com bases de dados extensas e complexas.

A arquitetura geral da solução desenvolvida, que integra o usuário/analista, o “frontend” (Web/Angular), o “backend” (FastAPI) e os modelos de Inteligência Artificial, permite um fluxo de trabalho eficiente. O usuário configura a conexão e o modelo, informa o pedido em linguagem natural, o “frontend” gerencia a interface, e o “backend” centraliza as chamadas para a IA, protegendo credenciais e aplicando regras de processamento. O resultado é um script SQL gerado, que pode ser de consulta, atualização ou exclusão, e um retorno ao usuário, evidenciando a automação e a integração dos componentes.

A etapa inicial do sistema, que envolve a configuração da chave de acesso e a seleção do provedor e do modelo de linguagem, é fundamental para definir as capacidades de contexto e processamento disponíveis. Essa interface permite ao usuário escolher entre diversos provedores de IA, como OpenAI, Claude, Gemini, DeepSeek e Ollama (para modelos locais), e selecionar o modelo específico, como o gpt-5.4-mini da OpenAI. A clareza na configuração dos “tokens” de API e a orientação sobre a segurança das chaves são aspectos importantes para a usabilidade e a segurança da solução.

A funcionalidade de conexão direta ao banco de dados, seja PostgreSQL ou Oracle, é um dos pilares da solução no modo tradicional. Essa interface permite ao usuário inserir os parâmetros de conexão, como host, porta, nome do banco, usuário e senha, e opcionalmente definir os schemas a serem considerados. Ao clicar em “Conectar e Obter Dicionário”, o sistema extrai automaticamente todas as tabelas, colunas, chaves e comentários, formando o dicionário de dados. Essa automação reduz significativamente os erros associados à entrada manual de informações e aumenta a confiabilidade do dicionário utilizado nos testes.

Como alternativa ao modo tradicional, a configuração da conexão via MCP para PostgreSQL oferece uma interface simplificada. O usuário informa apenas os parâmetros de conexão (host, porta, banco de dados, usuário, senha e schemas opcionais), e a IA consulta diretamente o banco durante a geração do script. Embora mais simples operacionalmente, essa abordagem é restrita à compatibilidade entre o banco PostgreSQL e os modelos de linguagem que suportam o MCP, como OpenAI e Claude, tornando-a uma opção complementar para cenários específicos.

A configuração da geração do resumo auxiliar de tabelas, empregado na estratégia de duas etapas do modo tradicional, é demonstrada por uma interface que permite ao usuário selecionar quais informações serão incluídas no resumo. As opções incluem a inclusão de colunas com comentários, chaves primárias (PK) e chaves estrangeiras (FK). Esse mecanismo é relevante para reduzir o volume de informações enviado ao modelo de linguagem em bases de dados extensas, otimizando o consumo de “tokens” e a latência das respostas.

A funcionalidade de análise automática e sugestão de comentários para tabelas é apresentada por uma interface que permite ao usuário acionar a IA para analisar tabelas sem comentários ou com descrições genéricas. O objetivo é apoiar a documentação do banco de dados, sugerindo descrições mais informativas a partir da estrutura das tabelas e de seus relacionamentos. Esse recurso contribui para a melhoria da qualidade dos metadados, facilitando a compreensão e a manutenção do banco de dados por toda a equipe.

A inserção de instruções contextuais é uma funcionalidade crucial para refinar a geração dos scripts SQL. Uma interface dedicada permite ao usuário adicionar informações sobre o contexto de negócio, a importância de tabelas específicas ou qualquer orientação que ajude a IA a compreender melhor o schema dos dicionários. Por exemplo, instruções como a identificação da tabela de usuários principal ou a tabela de documentos principal, e a orientação para sempre realizar “joins” com elas quando necessário, contribuem para maior aderência das consultas geradas às regras de negócio do sistema.

A etapa final de submissão do pedido em linguagem natural é o ponto de entrada principal para a geração automática do script SQL. Uma interface intuitiva permite ao usuário digitar sua solicitação, como “quero os usuários advogados que estão com OAB válida e ativos no sistema”. A ativação da “Geração em 2 etapas” é visível, indicando que o modo otimizado será usado para identificar tabelas relevantes e gerar o SQL de forma mais precisa e econômica em “tokens”. Após a submissão, o sistema processa a solicitação e retorna o script SQL correspondente.

Avaliação preliminar da solução

Durante os testes preliminares, especialmente com bases de dados extensas que continham mais de cem tabelas, observou-se que o envio integral do dicionário de dados aos modelos de linguagem resultava em um elevado consumo de “tokens”. Esse consumo excessivo impactava negativamente o custo operacional da solução e sua eficiência geral. A latência das respostas também aumentava consideravelmente, tornando evidente a necessidade de um mecanismo mais sofisticado para gerenciar o contexto enviado aos modelos de linguagem, a fim de otimizar o desempenho do sistema.

Diante desse desafio, a estratégia adotada pode ser caracterizada como uma aplicação do conceito de Retrieval-Augmented Generation (RAG). Essa abordagem envolve a recuperação seletiva de informações relevantes a partir de uma base de conhecimento externa, que, neste contexto, corresponde aos metadados do banco de dados corporativo. Em vez de fornecer o dicionário de dados completo ao modelo de linguagem, o pré-processamento identifica entidades e termos relevantes na solicitação em linguagem natural e seleciona apenas um subconjunto dos metadados necessários para a geração do script SQL. Essa filtragem resultou em uma redução substancial do consumo de “tokens”, diminuição da latência das respostas e otimização dos custos operacionais, além de aumentar a aderência das consultas geradas à estrutura real do banco de dados.

Durante o desenvolvimento da solução, foram avaliados diferentes modelos de linguagem natural, incluindo alternativas baseadas em nuvem e modelos executados localmente. Entre os modelos testados localmente, destacam-se o mistral, codellama e sqlcoder, disponibilizados por meio da ferramenta Ollama. No entanto, esses modelos apresentaram limitações relevantes quando submetidos a grandes volumes de contexto, especialmente em cenários com dicionários de dados extensos. Verificou-se perda de coerência nas respostas, dificuldade na manutenção de relacionamentos corretos entre tabelas e maior propensão à geração de consultas inconsistentes, o que levou à decisão de não dar continuidade aos testes com esses modelos no escopo deste trabalho.

Testes também foram conduzidos com modelos da plataforma Gemini, utilizando as versões gratuitas disponíveis. Contudo, os resultados obtidos não demonstraram desempenho satisfatório em termos de precisão semântica e aderência ao dicionário fornecido, especialmente em consultas mais complexas. A incapacidade de gerar scripts SQL com a precisão e a confiabilidade necessárias para o ambiente de sustentação de sistemas levou à exclusão desses modelos das avaliações subsequentes. A escolha do modelo de linguagem é um fator crítico para a eficácia da solução, e a seleção rigorosa é essencial.

O modelo GPT-5.2 da OpenAI foi selecionado como o principal modelo para a geração de SQL devido à sua superior capacidade de contexto, suporte a entradas extensas e melhor desempenho na interpretação de estruturas complexas de dados. Essas características revelaram-se essenciais para lidar com dicionários de dados volumosos e para a implementação bem-sucedida da estratégia de geração em duas etapas adotada neste trabalho. Assim, os testes e análises apresentados nos resultados preliminares concentraram-se exclusivamente nos scripts SQL gerados a partir do modelo GPT-5.2, que demonstrou ser o mais adequado para os requisitos do estudo.

A abordagem inicial, baseada no envio completo do dicionário de dados aos modelos de linguagem, apresentou desempenho satisfatório apenas em cenários com bases de dados pequenas ou médias. Em bases maiores, o aumento significativo no consumo de “tokens”, a maior latência nas respostas e a elevação dos custos associados ao uso da IA tornaram essa abordagem inviável. Esse cenário reforçou a necessidade de um mecanismo de pré-processamento capaz de filtrar e selecionar apenas os metadados relevantes para cada solicitação, confirmando a eficácia da estratégia de duas etapas na otimização do contexto.

Como alternativa ao fluxo tradicional baseado em dicionário de dados estruturado, os testes exploratórios com o Model Context Protocol (MCP) para PostgreSQL indicaram uma experiência de uso mais simples. Nessa modalidade, a estrutura do banco de dados é consultada diretamente pela IA, reduzindo a necessidade de preparação prévia de contexto pelo usuário. Essa simplificação operacional é uma vantagem significativa, pois minimiza a carga de trabalho do analista e acelera o processo de geração de scripts.

Em contrapartida, a abordagem MCP mostrou-se condicionada à compatibilidade com bancos PostgreSQL e com modelos de linguagem que oferecem suporte a esse tipo de integração, como OpenAI e Claude. Essa restrição limita sua aplicação em cenários mais amplos quando comparada à abordagem tradicional, que é mais flexível em termos de tipos de banco de dados. Dessa forma, o MCP foi compreendido como uma alternativa complementar, voltada à simplificação operacional em cenários específicos onde as condições de compatibilidade são atendidas.

A avaliação preliminar da solução foi realizada utilizando um conjunto de cinco casos de teste, que representavam demandas recorrentes da equipe de sustentação de sistemas. Para cada solicitação em linguagem natural, foi definido um SQL padrão-ouro, elaborado manualmente, para comparação. Os casos incluíam pedidos como “Processos distribuídos no mês de dezembro de 2025”, “Excluir etiquetas associadas ao processo de id 123”, “Documentos do processo de id 123”, “Comentários arquivados associados ao processo de id 123” e “Buscar o nome das partes do processo no polo ativo do processo de número 0000XXX-XX.2025.5.21.0015”.

Observou-se que a solução produziu consultas funcionalmente equivalentes ao SQL padrão-ouro na maioria dos casos analisados. No modo tradicional, o caso “Processos distribuídos no mês de dezembro de 2025” resultou em uma consulta parcial, enquanto os demais casos foram considerados corretos. No modo MCP, todos os cinco casos de teste geraram consultas corretas. As divergências identificadas no modo tradicional ocorreram principalmente em situações que exigiam inferências não explicitamente representadas nos metadados ou em solicitações com maior grau de ambiguidade semântica.

No caso específico do resultado parcial no modo tradicional, a limitação não esteve relacionada à geração sintática do SQL, mas sim à seleção incompleta das informações necessárias para compor a consulta esperada. Isso sugere que, embora a abordagem proposta seja promissora, ainda depende do aprimoramento dos mecanismos de seleção de contexto e da representação do conhecimento de negócio. A acurácia da solução foi calculada como a proporção de consultas corretamente geradas em relação ao total de casos de teste, seguindo metodologia semelhante à adotada em avaliações de sistemas NL2SQL descritas na literatura.

A introdução do “backend” em FastAPI contribuiu significativamente para a segurança no gerenciamento dos “tokens” e possibilitou maior controle sobre o fluxo de informações enviadas aos modelos de linguagem. Essa arquitetura robusta permitiu a implementação de regras de processamento antes do envio das informações, garantindo a integridade e a segurança dos dados. A funcionalidade de conexão direta ao banco de dados mostrou-se mais eficiente e confiável do que as abordagens baseadas em entrada manual ou upload de arquivos, reduzindo erros humanos e inconsistências no dicionário de dados, elementos cruciais para a confiabilidade do sistema.

De forma geral, a solução proposta demonstrou ser tecnicamente viável e apresenta potencial para automatizar a geração de scripts SQL de maneira padronizada e segura. Os ajustes em andamento concentram-se na definição de critérios eficientes de seleção de tabelas e relacionamentos, visando aprimorar o desempenho do sistema em bases de dados de grande porte. A abordagem contribui para a padronização da elaboração de scripts, reduz a dependência do conhecimento individual dos analistas e minimiza erros humanos, conforme o objetivo de apoiar equipes de sustentação de sistemas corporativos.

Em síntese, a pesquisa demonstrou a viabilidade de uma solução baseada em Inteligência Artificial para a geração automatizada de scripts SQL a partir de linguagem natural. A arquitetura desenvolvida, com suas abordagens de extração de metadados e a estratégia de geração em duas etapas, mostrou-se eficaz na redução de custos e na melhoria da precisão, especialmente em bases de dados extensas. Embora o modo MCP ofereça simplicidade, sua aplicabilidade é restrita pela compatibilidade. Os resultados preliminares indicam que a solução tem potencial para padronizar processos, reduzir erros e otimizar o trabalho das equipes de sustentação, respondendo ao problema de pesquisa e ao objetivo do estudo.

4. Conclusão

O presente estudo buscou desenvolver uma solução baseada em Inteligência Artificial para interpretar solicitações em linguagem natural e gerar scripts SQL consistentes, seguros e alinhados à estrutura real dos bancos de dados, com foco em equipes de sustentação de sistemas. Verificou-se a viabilidade técnica da solução, que integrou um “frontend” em Angular e um “backend” em Python/FastAPI para gerenciar a comunicação com modelos de IA. Implementaram-se duas abordagens para a definição da estrutura de dados: o modo tradicional, que extrai metadados de bancos PostgreSQL e Oracle para formar um dicionário JSON, e o modo Model Context Protocol (MCP), que permite à IA consultar diretamente a estrutura de bancos PostgreSQL. Para otimizar o desempenho em bases de dados extensas, adotou-se uma estratégia de geração em duas etapas, inspirada no conceito de Retrieval-Augmented Generation (RAG), que seleciona apenas os metadados relevantes, resultando em significativa redução do consumo de “tokens”, da latência e dos custos operacionais. Os testes preliminares, realizados com o modelo GPT-5.2 da OpenAI, indicaram que a solução produziu consultas funcionalmente equivalentes ao SQL padrão-ouro na maioria dos casos, contribuindo para a padronização da elaboração de scripts e a minimização de erros humanos.

A principal contribuição do trabalho reside na oferta de uma ferramenta que padroniza a elaboração de scripts SQL, reduzindo a dependência do conhecimento individual dos analistas e liberando a equipe para atividades de maior valor técnico. Contudo, identificou-se como limitação a ocorrência de resultados parciais no modo tradicional em situações que exigiam inferências não explicitamente contidas nos metadados ou em solicitações com ambiguidade semântica, o que aponta para a necessidade de aprimoramento dos mecanismos de seleção de contexto. A abordagem MCP, embora simplifique a operação, mostrou-se restrita à compatibilidade com bancos PostgreSQL e modelos de linguagem específicos. Para estudos futuros, sugere-se a ampliação do conjunto de casos de teste, a definição de métricas quantitativas mais detalhadas para avaliar a acurácia das consultas geradas e a investigação de estratégias complementares de recuperação de contexto, como a seleção semântica de tabelas e relacionamentos. Recomenda-se também aprofundar a análise comparativa entre as abordagens tradicional e MCP, considerando critérios como precisão, custo operacional, tempo de resposta e aplicabilidade em diversos cenários corporativos. A solução proposta possui potencial de aplicação prática no contexto do TRT21 e é adaptável a outros ambientes organizacionais com desafios semelhantes na geração de scripts SQL.

Referências Bibliográficas

CENTENARO, Belisa Renata Arnhold. IA Generativa para Consultas SQL a Partir de Linguagem Natural: Uma Avaliação Utilizando Dados Educacionais Brasileiros. Araranguá: Universidade Federal de Santa Catarina, 2025. Disponível em: https://repositorio.ufsc.br/handle/123456789/266444. Acesso em: 25 out. 2025.

ENDRIZZI, Nícolas Cristiel. Desenvolvimento de um Módulo para Conversão de Linguagem Natural em SQL em um Sistema de Gestão. Lajeado, RS: Universidade do Vale do Taquari, 2024. Disponível em: https://repositorio.univates.br/handle/10737/4210. Acesso em: 25 out. 2025.

EVANGELISTA, Gabriel de Melo. Uso de LLM Open Source na Tradução de Linguagem Natural para SQL. Recife: Universidade Federal de Pernambuco, 2023. Disponível em: https://repositorio.ufpe.br/handle/123456789/52701. Acesso em: 25 out. 2025.

OPENAI. ChatGPT: Technical Report. San Francisco: OpenAl, 2024. Disponível em: https://openai.com/research/chatgpt . Acesso em: 25 out. 2025.

RUSSELL, Stuart; NORVIG, Peter. Inteligência Artificial: Uma Abordagem Moderna. 4 ed. tradução de Regina Célia Simille. Rio de Janeiro: GEN LTC, 2022.

ZHANG, Wei; LI, Ming; WANG, Hao. SQL Generation from Natural Language Using Transformers. Journal of Artificial Intelligence Research, v. 72, p. 123-145, 2023.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy