Usando Ia Generativa para Escolha de Banco de Dados: um Framework Orientado a Requisitos para Geração de Architecture Decision Records (Adrs)

Geovanni de Morais Gava; Luiz Fernando Pereira Nunes

DOI: 10.22167/2675-6528-202602960

Artigo derivado de Trabalho de Conclusão de Curso (TCC), com conteúdo baseado no trabalho original do aluno e adaptado ao formato editorial da Revista E&S com apoio da ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege para síntese e organização textual.

Resumo

O crescimento de aplicações intensivas em dados e a adoção da arquitetura de microsserviços ampliaram a necessidade da persistência poliglota, impondo uma alta carga cognitiva aos arquitetos de software na escolha e justificação de tecnologias de banco de dados. Este trabalho teve como objetivo propor e desenvolver um framework baseado em agentes de Inteligência Artificial (IA) para guiar a seleção tecnológica e gerar Architecture Decision Records (ADRs) fundamentadas. Empregou-se uma metodologia experimental e aplicada para construir uma base de conhecimento técnico. A técnica de Retrieval-Augmented Generation (RAG), juntamente com as bibliotecas LangChain e LangGraph, foi utilizada para orquestrar agentes e ancorar as respostas de um Large Language Model (LLM). O framework extraiu requisitos em linguagem natural, enriqueceu-os com RAG e os enviou ao LLM, que gerou ADRs para auxiliar na avaliação de trade-offs teóricos. Os resultados demonstraram que o agente com RAG reduziu respostas genéricas, aumentando o embasamento teórico e a rastreabilidade. A abordagem RAG comprovou sua eficácia frente a prompts convencionais (zero-shot), favorecendo a geração de ADRs com menor nível de alucinação e alto nível de rastreabilidade teórica. Concluiu-se que a ferramenta automatizada cumpriu a função de mapeamento de requisitos, resultando em documentos técnicos empiricamente embasados e auxiliando a governança e tomada de decisões em arquitetura de software.

Palavras-chave: Bancos de Dados; Inteligência Artificial; LangGraph; LLM; RAG.

1. Introdução

A evolução dos sistemas de informação nas últimas décadas transformou profundamente a maneira como as organizações lidam com o grande volume de informações geradas diariamente. Para processar esses dados de forma estruturada, a adoção de tecnologias robustas é indispensável. Um banco de dados é entendido como uma coleção de dados que, tipicamente, descreve as atividades de uma ou mais organizações relacionadas (Ramakrishnan e Gehrke, 2008).

Historicamente, o modelo relacional dominou esse cenário, ditando como as aplicações corporativas abstraíam e manipulavam seus registros. No entanto, a arquitetura de software moderna exige um entendimento cada vez mais profundo sobre a modelagem e as estruturas físicas de armazenamento. Existe uma lacuna entre a visão do usuário e o armazenamento físico. Ramakrishnan e Gehrke (2008) destacam que, embora um modelo de dados oculte detalhes de baixo nível, ele ainda está mais próximo de como o sistema de gerenciamento de banco de dados armazena os dados do que de como o usuário pensa sobre a empresa.

Apesar da forte consolidação do modelo relacional, o advento de cenários de aplicações intensivas em dados, frequentemente denominados Big Data, e a necessidade de escalabilidade horizontal através de clusters de servidores impulsionaram a ascensão dos bancos de dados NoSQL. Essa transição abriu portas para um novo paradigma no design de software. Como explicam Sadalage e Fowler (2012), estamos entrando em um mundo de Persistência Poliglota, onde as empresas e até mesmo aplicativos individuais usam múltiplas tecnologias para o gerenciamento de dados. Essa flexibilidade tecnológica, contudo, impõe uma pesada carga cognitiva aos arquitetos de software e engenheiros de dados, pois a tomada de decisão arquitetural exige o balanceamento constante entre garantias estruturais. O embate entre propriedades transacionais clássicas e ambientes distribuídos é inevitável, já que bancos de dados relacionais usam transações ACID para lidar com a consistência, o que inerentemente entra em conflito com um ambiente de cluster, fazendo com que os bancos de dados NoSQL ofereçam uma gama de opções para consistência e distribuição (Sadalage e Fowler, 2012).

Na prática diária, a seleção da tecnologia de persistência muitas vezes negligencia essas restrições teóricas, como o Teorema CAP e as propriedades ACID versus BASE. A escolha acaba se baseando no viés de popularidade das ferramentas de mercado ou em testes de desempenho empíricos não padronizados, em vez de uma fundamentação sólida. Com a ascensão da Inteligência Artificial Generativa e dos Large Language Models (LLMs), surgiu uma oportunidade de automatizar e apoiar o design de sistemas de forma inteligente. Entretanto, tais modelos sofrem com o fenômeno das “alucinações”, gerando recomendações tecnicamente imprecisas em domínios altamente específicos quando lhes falta conhecimento e embasamento técnico.

Para mitigar esse desafio, costuma-se adotar a técnica de Retrieval-Augmented Generation (RAG), que ancora o raciocínio e a geração de texto da IA em uma base bibliográfica externa focada na engenharia de dados. O uso da técnica de RAG é fundamentado na literatura para a resolução de falhas baseadas em falta de informação e desatualização dos modelos, visto que enriquece a geração de respostas com fontes externas e factuais, mitigando o risco de alucinações técnicas e tornando o documento final altamente rastreável (Huyen, 2025). Além disso, o RAG reduz o custo e a latência ao selecionar apenas a informação estritamente relevante, otimizando o uso do limite de tokens nativo da janela de contexto da IA (Huyen, 2025). Diante deste cenário, a presente pesquisa justifica-se pela oportunidade de unir os avanços dos agentes orquestrados de IA para aprimorar a governança em arquitetura de software.

A necessidade de decisões robustas e teoricamente embasadas na seleção de bancos de dados, combinada com o potencial dos agentes de IA para superar as limitações das saídas genéricas dos LLMs, ressalta a relevância deste estudo. O objetivo central deste trabalho é propor e desenvolver um framework inteligente que, munido de literatura clássica de bancos de dados, seja capaz de interpretar requisitos em linguagem natural, avaliar trade-offs teóricos e gerar, de forma autônoma, um Architecture Decision Record (ADR) consistente, rastreável e com menor número de “alucinações” possível, assim como redução de vieses de mercado.

2. Material e Métodos

A pesquisa realizada caracterizou-se por sua natureza experimental e aplicada, empregando abordagens de desenvolvimento de aplicações com agentes e Modelos de Fundação. Os procedimentos foram conduzidos em simulações controladas de engenharia de software, visando a construção de um framework inteligente. O foco metodológico principal residiu na utilização da técnica de Retrieval-Augmented Generation (RAG) e de agentes autônomos, com o propósito de superar as limitações inerentes às janelas de contexto e a propensão dos Large Language Models (LLMs) a gerar respostas sem rastreabilidade.

A adoção de agentes de Inteligência Artificial justificou-se pela capacidade de combinar diversas ferramentas, conhecimentos, memória e aprendizado com modelos avançados. Essa combinação permitiu a resolução de problemas ambíguos e complexos por meio de múltiplas etapas de raciocínio, conforme destacado por Albada (2025). A construção do framework foi estruturada em etapas operacionais distintas, detalhadas a seguir, para garantir a robustez e a funcionalidade do sistema proposto.

A primeira etapa consistiu na ingestão e processamento de dados para a base de conhecimento do RAG. Para isso, foi estabelecida uma base de conhecimento (grounding) a partir da literatura clássica de sistemas de banco de dados, documentações oficiais de ferramentas e teorias específicas, como topologias, mecanismos de replicação e modelos de consistência, incluindo as propriedades ACID versus BASE e o Teorema CAP. Essa base foi fundamental para ancorar o raciocínio da IA.

Os textos coletados foram fragmentados, processo conhecido como chunking, e convertidos em embeddings. Essa conversão foi realizada por meio de um modelo codificador específico, o Ollama com nomic-embed-text. Posteriormente, os embeddings resultantes foram armazenados em um banco de dados vetorial, utilizando a combinação de PostgreSQL e a extensão pgvector, permitindo a busca indexada de informações relevantes.

A técnica de Retrieval-Augmented Generation (RAG) foi empregada para mitigar falhas decorrentes da falta de informação e da desatualização dos modelos, enriquecendo a geração de respostas com fontes externas e factuais. Isso contribuiu para reduzir o risco de alucinações técnicas e aumentar a rastreabilidade do documento final (Huyen, 2025). Adicionalmente, o RAG otimizou o uso do limite de tokens da janela de contexto da IA, selecionando apenas informações estritamente relevantes e, consequentemente, reduzindo custos e latência (Huyen, 2025).

A segunda etapa envolveu a implementação do agente, onde se utilizou as bibliotecas LangChain e LangGraph para construir a orquestração e a máquina de estados do agente conversacional. O LangGraph foi escolhido por sua capacidade de fornecer um framework de orquestração modular baseado em grafos direcionados, suportando fluxos de trabalho cíclicos e assíncronos, o que é crucial para arquiteturas de agentes robustas (Albada, 2025).

O LangGraph modelou o processo de geração do Architecture Decision Record (ADR) como um grafo de estados. Nesse fluxo, um nó ingestor foi responsável por analisar e validar a entrada do usuário, enquanto um nó redator executou a busca no RAG, avaliou a relevância do conteúdo recuperado, invocou o Large Language Model (LLM) e formatou a saída final em markdown e no padrão ABNT.

A biblioteca LangChain atuou como uma camada de abstração para os componentes de IA, oferecendo peças prontas e intercambiáveis. Isso incluiu funcionalidades de carregamento e divisão de documentos, como o PyPDFLoader para carregar PDFs e o RecursiveCharacterTextSplitter para dividir o texto em chunks com overlap. Para embeddings, utilizou-se o OllamaEmbeddings, que abstraiu a chamada ao Ollama para gerar vetores.

Para o armazenamento vetorial, empregou-se o PGVector, que abstraiu a lógica de inserção, seleção e busca por similaridade no PostgreSQL, eliminando a necessidade de escrever SQL manualmente. As interfaces comuns, definidas pelo langchain-core, garantiram a flexibilidade para trocar modelos de embedding ou bancos vetoriais sem alterar o restante do código do sistema.

A terceira etapa focou na engenharia de prompts e recuperação, onde os prompts do sistema estabeleceram regras explícitas para a IA. O modelo foi instruído a decompor o problema do usuário, identificar trade-offs com base nos requisitos extraídos, no Teorema CAP e nas restrições arquiteturais recuperadas pelo fluxo do RAG, antes de tomar a decisão final. O prompt completo enviado ao LLM foi composto por quatro camadas distintas.

A primeira camada, o System Prompt, definiu o papel do LLM como arquiteto sênior, as regras de escrita e a estrutura do ADR, incluindo seções obrigatórias como Contexto, Decisão, Consequências, Alternativas e Referências, além de instruções de formatação e citação ABNT. A segunda camada, de requisitos expandidos, consistiu em seis perguntas de múltipla escolha sobre estrutura de dados, natureza das buscas, proporção de operações, volumetria e escalabilidade, Teorema CAP e transações multi-registro, cujas respostas foram transformadas em texto legível.

A terceira camada, de follow-up context, foi opcional e utilizada quando o usuário indicava “não tenho certeza” em alguma pergunta da camada anterior. Nesse caso, duas perguntas de contexto do tipo Sim/Não eram feitas para clarificação, enriquecendo o prompt. A quarta camada, de contexto RAG, anexava chunks relevantes encontrados pelo RAG ao final do prompt, fornecendo conhecimento técnico e referências bibliográficas para embasar as respostas.

A quarta e última etapa compreendeu a avaliação e os cenários de validação do framework. O sistema foi submetido a testes simulados baseados em três padrões típicos de System Design: alta ingestão de eventos com prioridade em escalabilidade de escrita linear (AP), transações financeiras distribuídas com prioridade em forte consistência e durabilidade (CP/ACID), e um catálogo de produtos com buscas flexíveis.

Para avaliar a efetividade da abordagem, os Architecture Decision Records (ADRs) gerados com o suporte do fluxo RAG e dos agentes foram comparados com as respostas obtidas pela abordagem zero-shot, que se baseava apenas no conhecimento paramétrico do modelo. A avaliação foi de natureza qualitativa, focando na consistência factual e na rastreabilidade das justificativas, verificando a coerência com as referências da arquitetura das tecnologias. Os anexos V e VI do trabalho original contêm as ADRs geradas para os cenários sem e com a utilização do RAG, respectivamente.

3. Resultados e Discussão

A implementação do framework proposto demonstrou a viabilidade do uso de agentes conversacionais, guiados pela técnica de Retrieval-Augmented Generation (RAG), para a execução de tarefas analíticas complexas, como a seleção e a justificação técnica de bancos de dados. As rodadas de execução, realizadas em cenários de validação controlados, evidenciaram diferenças significativas entre as recomendações geradas por um Large Language Model (LLM) em abordagem zero-shot e aquelas enriquecidas com contexto bibliográfico externo, fornecido pelo RAG. Essa distinção ressaltou a capacidade do framework de mitigar vieses e alucinações, promovendo decisões mais embasadas e rastreáveis.

Os testes foram estruturados em três cenários distintos, cada um representando um padrão comum de design de sistemas, permitindo uma avaliação abrangente da performance do framework. A análise comparativa focou na consistência factual, na profundidade da justificativa e na rastreabilidade das fontes teóricas utilizadas. Observou-se que a ausência do RAG frequentemente levava a escolhas baseadas em popularidade ou analogias superficiais, enquanto a sua aplicação direcionava o LLM para soluções mais robustas e alinhadas com os requisitos técnicos específicos de cada contexto.

Ingestão de Eventos (Escrita Linear / AP)

No cenário que simulava a ingestão massiva de telemetria e logs, onde a escala de dados poderia atingir Petabytes e a disponibilidade (AP) era a prioridade máxima em face de falhas parciais de rede, a abordagem zero-shot do LLM sugeriu o Redis. Essa recomendação baseou-se na velocidade de escrita e na simplicidade da estrutura chave-valor, mas ignorou as restrições físicas de memória RAM e a persistência para volumes tão elevados, o que tornaria o custo proibitivo e aumentaria o risco de perda de dados em caso de falha de energia. Alternativas como MySQL, PostgreSQL e MongoDB foram descartadas por não suportarem o volume de escrita ou não serem otimizadas para operações puras de chave-valor.

Em contraste, o framework enriquecido com RAG, ao processar os mesmos requisitos, recomendou o ScyllaDB. A decisão foi fundamentada na capacidade do ScyllaDB de lidar com grandes volumes de dados através de seu modelo de família de colunas e chave-valor, otimizado para acesso em altíssima velocidade por chave primária (Sadalage; Fowler, 2012). O agente destacou a arquitetura “shard-per-core” do ScyllaDB, ideal para cargas intensas de escrita (ScyllaDB, 2023), e sua escalabilidade linear em múltiplos servidores (Scabora, 2016). Além disso, a implementação do modelo masterless favorece a disponibilidade no teorema CAP, com consistência eventual ajustável (ScyllaDB, 2023; Sadalage; Fowler, 2012).

As consequências positivas da escolha do ScyllaDB incluíram alta disponibilidade nativa e escalabilidade linear para Petabytes, juntamente com baixíssima latência de escrita devido à ausência de bloqueios globais (ScyllaDB, 2023). Contudo, foram identificadas desvantagens, como a inadequação para consultas que exigem múltiplos JOINs complexos (Scabora, 2016) e a necessidade de uma modelagem de dados orientada às consultas. As alternativas consideradas e descartadas pelo agente com RAG foram Redis, devido ao custo inviável de memória RAM para volumetria massiva; PostgreSQL, por seu controle de concorrência limitar a escrita massiva (Ramakrishnan; Gehrke, 2008); e Neo4j, por ser otimizado para conexões e não para alta ingestão de logs (Robinson et al., 2015).

Transações Financeiras (Forte Consistência / CP)

Para o cenário de transações financeiras distribuídas, que exigia um alto grau de consistência (CP) e garantia de transações isoladas, o LLM em abordagem zero-shot sugeriu o MongoDB. Embora o modelo tenha tentado justificar a escolha com base na capacidade de organizar dados como tabelas e suporte a transações multi-documento, as descrições sobre recuperação a falhas e a superioridade do modelo relacional para integridade referencial rígida foram imprecisas, caracterizando uma alucinação de conhecimento não paramétrico. O MongoDB não é um banco relacional nativo, o que poderia causar ineficiência em JOINs complexos, e garantir ACID estrito exigiria configurações que reduziriam a performance. Alternativas como Cassandra, SQLite e Neo4j foram descartadas por não suportarem transações ACID estritas ou não serem adequadas para o contexto financeiro.

Com a integração do RAG, o framework recuperou com sucesso fragmentos da literatura de Ramakrishnan e Gehrke (2008) sobre o Protocolo de Bloqueio de Duas Fases (2PL) e as propriedades ACID. Baseado nesse embasamento, o agente recomendou o PostgreSQL, priorizando a “Consistência” frente à falha de partições no Teorema CAP. A decisão foi justificada pelo modelo relacional que garante a integridade através de esquemas fixos (Ramakrishnan; Gehrke, 2008), suporte a JOINs e agregações complexas via SQL, e eficiência com carga mista sob concorrência. O PostgreSQL é otimizado para servidores únicos de alta performance e implementa protocolos de bloqueio que garantem a Consistência CP (Ramakrishnan; Gehrke, 2008), com garantias ACID nativas e fundamentais para operações financeiras (Hiremath, 2018).

As consequências positivas da escolha do PostgreSQL incluíram robustez no controle de transações concorrentes via isolamento (Ramakrishnan; Gehrke, 2008) e a maturidade do ecossistema para auditoria financeira (Hiremath, 2018). Como pontos negativos, foram apontados a menor disponibilidade em caso de falhas severas de rede, comparado a sistemas AP, e a dificuldade de escalabilidade horizontal em relação a bancos NoSQL (Sadalage; Fowler, 2012). As alternativas descartadas pelo RAG foram MongoDB, pois a estrutura tabular rígida e JOINs são nativamente superiores em RDBMS (Ramakrishnan; Gehrke, 2008); Cassandra, por priorizar disponibilidade em vez de consistência forte ACID (Sadalage; Fowler, 2012); e ScyllaDB, por não ser focado em transações ACID multi-tabela (ScyllaDB, 2023).

Catálogo de Produtos (Buscas Flexíveis / AP)

No cenário de um catálogo de produtos com buscas flexíveis, onde a prioridade era a disponibilidade (AP) e a necessidade de lidar com dados flexíveis (JSON) e buscas textuais, a abordagem zero-shot do LLM sugeriu o Neo4j. Essa escolha foi baseada na premissa superficial de que “produtos possuem categorias”, o que levou a uma analogia inadequada com bancos de grafos. Embora o Neo4j seja excelente para sistemas de recomendação e visualização intuitiva de árvores de produtos, ele não é otimizado para buscas textuais do tipo “fuzzy search” em larga escala, e sua performance pode degradar em buscas que não utilizam os relacionamentos. Alternativas como Elasticsearch, PostgreSQL e Cassandra foram descartadas por serem apenas motores de busca, muito rígidos para atributos dinâmicos ou complexos para buscas textuais.

O framework enriquecido com RAG, por sua vez, identificou corretamente o MongoDB como a solução mais adequada. A decisão foi fundamentada na capacidade do MongoDB de armazenar atributos dinâmicos de produtos em documentos JSON (Sadalage; Fowler, 2012) e de oferecer índices de texto para buscas flexíveis (Płuciennik; Zgorzałek, 2017). O agente destacou a eficiência do MongoDB para workloads de leitura massiva, seu suporte a sharding para volumes massivos de dados (Sadalage; Fowler, 2012), a possibilidade de configuração para alta disponibilidade (AP) e a aceitabilidade da consistência eventual para catálogos de produtos.

As consequências positivas da escolha do MongoDB incluíram agilidade no desenvolvimento devido ao mapeamento direto entre objetos e documentos (Płuciennik; Zgorzałek, 2017), além da facilidade de expansão para novos mercados e categorias de produtos. Contudo, foram observadas desvantagens, como o consumo de espaço em disco superior ao modelo relacional devido à desnormalização (Sadalage; Fowler, 2012) e a falta de otimização para consultas de relacionamentos complexos, típicas de grafos (Robinson et al., 2015). As alternativas descartadas pelo RAG foram Neo4j, pois a complexidade de grafos não era necessária para buscas textuais de catálogo (Robinson et al., 2015); ScyllaDB, por não possuir a flexibilidade de campos dinâmicos do modelo de documentos (ScyllaDB, 2023); e PostgreSQL, devido à rigidez do esquema que dificulta atributos variáveis (Płuciennik; Zgorzałek, 2017).

A qualidade da saída final da ferramenta foi expressa na geração de Architecture Decision Records (ADRs) com rigor analítico. O modelo foi guiado por instruções explícitas inseridas no prompt, limitando o uso apenas à base de conhecimento estendida. Isso permitiu que o framework superasse a instabilidade comum da geração sintética, atestando que a arquitetura sistêmica intrínseca do software serve como critério primário de escolha, mitigando a dependência de benchmarks empíricos de internet, que são frequentemente inconsistentes. A capacidade de gerar ADRs rastreáveis e teoricamente embasadas representa um avanço significativo na governança e tomada de decisões em arquitetura de software, validando a eficácia da abordagem RAG para aprimorar a inteligência generativa em domínios técnicos específicos.

4. Conclusão

O presente estudo teve como objetivo propor e desenvolver um framework inteligente, baseado em agentes de Inteligência Artificial, para guiar a seleção de tecnologias de banco de dados e gerar Architecture Decision Records (ADRs) fundamentadas. Verificou-se que a abordagem de Retrieval-Augmented Generation (RAG), em conjunto com a orquestração de agentes, demonstrou ser eficaz na interpretação de requisitos em linguagem natural e na avaliação de trade-offs teóricos. Os resultados evidenciaram uma redução significativa de respostas genéricas e “alucinações” em comparação com modelos de linguagem em abordagem zero-shot, aumentando o embasamento teórico e a rastreabilidade das recomendações. Observou-se que o framework foi capaz de fornecer soluções robustas e alinhadas aos requisitos técnicos específicos em cenários diversos, como a ingestão massiva de eventos, transações financeiras com forte consistência e catálogos de produtos com buscas flexíveis, recomendando ScyllaDB, PostgreSQL e MongoDB, respectivamente, com justificativas ancoradas na literatura.

A principal contribuição deste trabalho reside na criação de uma ferramenta automatizada que aprimora a governança em arquitetura de software, ao mapear requisitos e gerar documentos técnicos empiricamente embasados. A capacidade de produzir ADRs com rigor analítico e rastreabilidade teórica representa um avanço significativo, pois mitiga a dependência de vieses de mercado ou de benchmarks empíricos inconsistentes, priorizando a arquitetura sistêmica intrínseca do software como critério primário de escolha. Assim, o framework desenvolvido auxilia diretamente arquitetos de software no complexo processo de tomada de decisão, promovendo escolhas mais informadas e confiáveis.

Referências Bibliográficas

Abhinav Hiremath; Comparative Analysis of Relational vs NoSQL Databases in Web Applications Dataset. Vol. 06, Issue: 03, March: 2018

ALBADA, Michael. Building Applications with Al Agents: Designing and Implementing Multiagent Systems. 1. ed. Santa Rosa: O’Reilly Media, 2025

HUYEN, Chip. Al Engineering: Building Applications with Foundation Models. 1. ed. [S. I.]: O’Reilly Media, 2024.

PŁUCIENNIK, E.; ZGORZAŁEK, K. The multi-model databases-a review. In: SPRINGER. 2017.

Ramakrishnan, R.; Gehrke, J. Sistemas de gerenciamento de banco de dados. 3. ed. McGraw Hill Brasil, 2008.

ROBINSON, I.; WEBBER, J.; EIFREM, E. Graph databases: new opportunities for connected data. [S.I.]: “O’Reilly Media, Inc.”, 2015.

Sadalage, P. J.; Fowler, M. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley, 2012.

SCABORA, L. D. C. Avaliação do Star Schema Benchmark aplicado a bancos de dados NoSQL distribuídos e orientados a colunas. 2016.

ScyllaDB. ScyllaDB Architecture Overview. ScyllaDB Documentation, 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