🤖 AI

GADR: Gathering Architecture Decision Records from Meeting Transcriptions

Este artigo apresenta o GADR, um fluxo de trabalho multiagente e autocorretivo que extrai efetivamente decisões arquiteturais de transcrições de reuniões brutas e ruidosas para gerar Registros de Decisão de Arquitetura (ADRs) estruturados no formato Nygard, demonstrando estabilidade e utilidade superiores em comparação com baselines de LLM de passagem única, ao mesmo tempo em que destaca trocas críticas entre a profundidade de enriquecimento baseada em RAG e a fidelidade da transcrição.

Autores originais: Lucas Daniel Costa da Silva, Kiev Gama

Publicado 2026-08-19

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Lucas Daniel Costa da Silva, Kiev Gama

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A arquitetura de software é o blueprint invisível que mantém um sistema digital unido, determinando como suas partes conversam entre si e onde elas residem. Mas um blueprint é inútil se as pessoas que o desenham esquecerem por que escolheram um design específico ou como resolveram um problema. No passado, as equipes tentavam corrigir isso escrevendo cada decisão importante em um documento chamado Registro de Decisão de Arquitetura (Architecture Decision Record). Esses registros pretendem ser notas simples que explicam o que foi decidido, por que foi escolhido e quais alternativas foram rejeitadas, garantindo que futuros desenvolvedores possam entender o histórico do projeto. No entanto, criar esses registros é um trabalho árduo. No mundo real, decisões importantes raramente são feitas em relatórios escritos organizados. Em vez disso, elas acontecem em reuniões desordenadas e não estruturadas, onde as pessoas falam umas sobre as outras, fogem do tópico e deixam seu raciocínio enterrado em conversas casuais. Extrair um registro claro e formal de uma conversa tão caótica tem sido, há muito tempo, uma barreira para manter a organização dos projetos de software.

Uma equipe de pesquisadores da Universidade Federal de Pernambuco, no Brasil, propôs uma nova maneira de preencher essa lacuna usando inteligência artificial. Eles construíram um sistema chamado GADR, que significa Gathering Architecture Decision Records (Coleta de Registros de Decisões de Arquitetura). A ideia central é pegar a transcrição bruta e ruidosa de uma reunião — onde as pessoas podem estar falando em português, interrompendo umas às outras ou discutindo tópicos irrelevantes — e transformá-la automaticamente em um registro de decisão estruturado e legível. Os pesquisadores não pediram simplesmente que um computador resumisse o texto. Em vez disso, eles projetaram um fluxo de trabalho onde múltiplos agentes de software especializados trabalham juntos em um ciclo. Um agente ouve a conversa para encontrar decisões potenciais, outro atua como um crítico para verificar se essas decisões fazem sentido ou se o computador está inventando coisas, e um terceiro agente reúne informações técnicas extras para detalhar os pontos. Esse processo se repete, refinando a saída até que esteja pronta para a revisão humana.

Para testar se essa abordagem realmente funciona, os pesquisadores reuniram transcrições de cinco reuniões reais de desenvolvimento de software. Estas incluíam sessões com estudantes de graduação construindo videogames e plataformas de logística, bem como uma reunião com pesquisadores seniores trabalhando em um projeto de tecnologia de saúde. Eles alimentaram essas transcrições brutas em seu novo sistema multiagente e compararam os resultados com dois métodos mais simples: pedir a uma inteligência artificial para escrever um registro de uma só vez sem exemplos, e pedir que ela escreva um após mostrar a ela alguns exemplos de bons registros. O estudo descobriu que o novo sistema era muito mais estável. Os métodos mais simples frequentemente produziam resultados inconsistentes, às vezes fundindo ideias não relacionadas ou perdendo pontos fundamentais por completo. Em contraste, o sistema multiagente produzia consistentemente registros que seguiam um formato padrão e capturavam as principais decisões discutidas.

Quando os pesquisadores pediram aos estudantes que participaram das reuniões que revisassem os registros gerados, a resposta foi amplamente positiva. De 55 avaliações específicas das decisões, 52 concordaram que o sistema havia identificado corretamente o que foi discutido. Além disso, 51 dessas avaliações afirmaram que os registros gerados eram claros e completos o suficiente para serem úteis. Os estudantes relataram que ler os registros os ajudou a lembrar o raciocínio por trás de suas escolhas, o que é frequentemente a parte mais difícil de recordar na semana ou meses depois do desenvolvimento de software. Arquitetos seniores também revisaram o trabalho e descobriram que o sistema identificou com sucesso cerca de 18 das 23 decisões principais que os especialistas haviam detectado nas mesmas transcrições. Isso sugere que o sistema consegue encontrar as escolhas arquiteturais mais importantes mesmo em meio a uma massa de conversa casual.

No entanto, os pesquisadores foram cuidadosos ao notar que o sistema não é perfeito e não deve ser confiado para escrever a versão final de um documento sem supervisão humana. O sistema às vezes adicionava detalhes que não estavam na reunião original. Por exemplo, em um caso envolvendo um videogame, o sistema incluiu um número específico de usuários esperados que nunca foi mencionado pelos estudantes; ele havia extraído esse número de registros de outro projeto enquanto buscava contexto. Isso destaca um compromisso: o sistema torna os registros mais ricos e educativos ao adicionar contexto técnico, mas corre o risco de incluir informações que nunca foram de fato acordadas pela equipe. Os pesquisadores concluíram que o melhor uso dessa ferramenta é como um gerador de rascunhos. Ele pode transformar uma reunião caótica em um primeiro rascunho estruturado que um humano pode rapidamente verificar, corrigir e aprovar.

O estudo sugere que o maior obstáculo para manter a documentação de software atualizada não é a falta de boas ideias, mas o esforço necessário para escrevê-las. Ao automatizar a extração inicial de decisões a partir de conversas desordenadas, essa abordagem reduz essa barreira. Ela não substitui a necessidade de julgamento humano, mas desloca o trabalho de escrever do zero para revisar e refinar. Para os estudantes no estudo, isso significou que eles puderam aprender com suas próprias discussões de forma mais eficaz, vendo seus pensamentos informais transformados em documentação profissional. Os pesquisadores acreditam que essa mudança, de criar documentação para revisar, é um passo significativo para a forma como as equipes gerenciam o conhecimento que constrói seu software.

Resumo Técnico: GADR – Coleta de Registros de Decisão de Arquitetura a partir de Transcrições de Reuniões

Declaração do Problema

As abordagens atuais baseadas em Grandes Modelos de Linguagem (LLMs) para gerar Registros de Decisão de Arquitetura (ADRs) dependem de uma premissa crítica, frequentemente não examinada: a de que os dados de entrada já são razoavelmente estruturados (por exemplo, documentos curados ou artefatos de código). Na prática, as decisões arquiteturais emergem de transcrições de reuniões informais, ruidosas, onde as escolhas são implícitas, fragmentadas e entrelaçadas com diálogos fora do tópico. Estratégias de prompting de passagem única (zero-shot ou few-shot) lutam sob essas condições, levando à degradação da atenção, saídas desorganizadas e redução da precisão devido a informações irrelevantes. Além disso, os métodos existentes falham em abordar o esforço significativo necessário para capturar o Conhecimento Arquitetural (AK) a partir de dados conversacionais brutos, dificultando a adoção de ADRs como um mecanismo para melhorar a Gestão de Conhecimento Arquitetural (AKM).

Metodologia

O artigo propõe o GADR, um fluxo de trabalho multiagente e autocorretivo projetado para extrair decisões arquiteturais de transcrições de reuniões brutas e gerar rascunhos de ADR no formato Nygard. Diferente de pipelines lineares, o GADR utiliza uma arquitetura baseada em grafos (implementada via LangGraph) que opera como uma máquina de estados finitos (FSM) com um estado compartilhado e mutável ( $S$ ).

Arquitetura Central

O fluxo de trabalho é decomposto em nós específicos que leem e atualizam o estado compartilhado, que inclui a transcrição original, texto em inglês normalizado, flags de detecção de idioma, decisões candidatas, vetores de crítica, contadores de iteração e artefatos finais de ADR.

Alinhamento de Idioma de Entrada: O sistema primeiro detecta o idioma da transcrição. Se não for inglês, ele traduz o texto para o inglês para garantir consistência na tokenização e eficiência de raciocínio antes da extração.
Extração de Decisão Arquitetural: Um agente atua como um arquiteto de software sênior para identificar decisões, justificativas e alternativas rejeitadas. Em iterações subsequentes, este nó refina as saídas com base no feedback da crítica, fundindo sobreposições e dividindo preocupações fragmentadas.
Avaliação Crítica: Um módulo dedicado revisa as decisões provisórias para reduzir alucinações e inconsistências. Ele categoriza o feedback em tipos específicos: Sobreposição, Fragmentação, Escolhas Ausentes, Ruído e Duplicidade de Escopo.
Enriquecimento por RAG e Formatação: Este nó enriquece as decisões aceitas usando Geração Aumentada de Recuperação (RAG). Ele realiza a recuperação híbrida de uma base de conhecimento local ChromaDB (contendo ADRs históricos do projeto) e busca na web (via API Tavily). O conteúdo recuperado é reclassificado para filtrar fatos técnicos relevantes antes de gerar o ADR final em Markdown com Contexto, Decisão, Opções Consideradas e Consequências.

Configuração de Avaliação

O estudo emprega uma metodologia de Pesquisa de Engenharia, avaliando o artefato contra três questões de pesquisa relativas à eficácia da extração, qualidade do artefato, utilidade de recall e desempenho comparativo.

Dataset: Cinco transcrições de reuniões do mundo real de cursos de arquitetura de software (envolvendo equipes de estudantes e pesquisadores seniores) cobrindo diversos domínios (ex: jogos online, mobilidade urbana, P&D em saúde).
Baselines: O fluxo de trabalho GADR foi comparado contra Prompting Zero-shot e Prompting Few-shot (usando exemplos estáticos de um dataset de referência MSR).
Participantes: A avaliação envolveu 15 estudantes (participantes das reuniões gravadas) e 4 arquitetos de software seniores que forneceram aproximações de verdade fundamental (ground-truth) das decisões discutidas.

Principais Resultados

O estudo apresenta evidências preliminares de uma prova de viabilidade, em vez de uma validação industrial definitiva.

Estabilidade e Estrutura: O fluxo de trabalho Agentic RAG produziu saídas significativamente mais estáveis com menor variância entre múltiplas execuções em comparação com os baselines zero-shot e few-shot. Demonstrou maior adesão à estrutura Nygard de ADR e às convenções de nomenclatura.
Eficácia de Extração (RQ1): O agente cobriu com sucesso aproximadamente 18 de 23 decisões identificadas por especialistas seniores. No entanto, ocasionalmente classificou discussões tentativas como decisões aceitas ou omitiu preocupações técnicas detalhadas.
Qualidade do Artefato (RQ2): Em pesquisas com participantes, 51 de 55 avaliações consideraram os ADRs gerados claros e completos. Os participantes concordaram que os rascunhos ajudaram a recordar decisões anteriores e a entender a justificativa por trás delas.
O Trade-off do RAG: Embora o enriquecimento por RAG tenha melhorado a profundidade e o valor pedagógico dos ADRs ao adicionar terminologia arquitetural e contexto externo, introduziu o risco de "contaminação contextual". Em alguns casos, o sistema inseriu métricas ou restrições (ex: contagens específicas de usuários) recuperadas de ADRs externos que não estavam presentes na transcrição da reunião original, necessitando de revisão humana para garantir a rastreabilidade.

Significância e Alegações

Os autores posicionam o GADR não como um substituto totalmente autônomo para a documentação humana, mas como um mecanismo de suporte à decisão semi-automatizado.

Redução de Barreiras de Adoção: A principal contribuição é demonstrar que dados de reuniões brutos e não estruturados podem ser transformados em rascunhos de ADR passíveis de revisão. Isso desloca a barreira primária para a adoção de AKM do esforço de escrever a documentação para o esforço mais leve de revisá-la.
Valor Pedagógico: O sistema mostra-se particularmente promissor em ambientes educacionais, ajudando arquitetos novatos a formalizar discussões informais e aprender como documentar trade-offs e consequências.
Necessidade de Humano no Ciclo (Human-in-the-Loop): O artigo afirma explicitamente que, embora o fluxo de trabalho agêntico melhore o determinismo e a adesão estrutural, os artefatos gerados devem permanecer como "rascunhos revisáveis". A validação humana é necessária para distinguir a extração fiel do contexto recuperado, porém não relacionado, e para corrigir extrapolações não suportadas.

O estudo conclui que a orquestração explícita do processo de extração (via fluxos de trabalho multiagentes) é superior ao prompting de passagem única para inputs ruidosos, mas enfatiza que a documentação resultante requer supervisão humana para garantir a fidelidade ao contexto original da reunião.