Análise Agentiva: Arquitetura, Contexto e o Papel da Camada Semântica

Um sistema de análise agentiva é aquele em que agentes alimentados por LLM quebram autonomamente uma questão de dados em subtarefas, recuperam contexto relevante, executam consultas, avaliam os resultados e retornam uma resposta fundamentada. Não há um humano coordenando cada passo.

Se você assistiu a uma demonstração de fornecedor de BI recentemente, ouviu alguma versão disso: conecte seu armazém, construa uma camada semântica, faça perguntas em inglês simples (linguagem natural). É uma proposta sólida. A maioria das equipes acredita, configura e depois se pergunta por que a fila de analistas ainda parece a mesma na manhã de segunda-feira.

Veja o que realmente foi construído: uma interface de linguagem natural em cima de definições de métricas estáticas. Você pergunta, ele responde. Você para de perguntar, ele para de funcionar. Útil? Claro. Mas ainda é um sistema que espera por você, e isso é uma limitação arquitetônica significativa, não um pequeno inconveniente.

A análise agentiva é uma oferta diferente por completo. Um agente alimentado por LLM não espera ser perguntado. Ele recebe uma pergunta ou detecta uma anomalia por conta própria, a quebra em partes menores, puxa o contexto certo de uma camada semântica, executa as consultas, verifica se os resultados são válidos e retorna com uma resposta sintetizada mostrando exatamente como chegou lá.

Por que essa distinção é importante? Porque muda a forma como você arquiteta sua pilha, onde seu tempo de engenharia realmente vai, e se os números que saem do seu sistema são aqueles que seu CFO aprovaria ou aqueles que apenas parecem corretos até que alguém verifique a tabela de onde vieram.

O Que "Análise Agentiva" Realmente Significa

O termo "agentivo" é aplicado a praticamente qualquer coisa que coloque um LLM perto de um banco de dados. Portanto, vale a pena ser preciso sobre o que realmente significa em um contexto de análise.

A análise agentiva é onde a IA para de esperar para ser perguntada. Em vez de retornar um gráfico em resposta a uma pergunta, um agente alimentado por LLM quebra a pergunta em partes, puxa o contexto certo de uma camada semântica, executa consultas contra seu armazém de dados, verifica se os resultados realmente se sustentam e retorna com uma resposta sintetizada mostrando exatamente como chegou lá. Nenhum humano coordenando cada passo. O sistema dirige.

Duas propriedades arquitetônicas separam isso do BI NLQ padrão ou de um assistente de IA generativa: autonomia baseada em loop e execução fundamentada.

O BI NLQ funciona em um ciclo de solicitação/resposta de uma única vez. Você pergunta, ele responde. Se a resposta estiver incompleta, você reformula e pergunta novamente. Assistentes de IA generativa estão cada vez mais ganhando conectividade com armazéns e execução de ferramentas por meio de padrões abertos como MCP, mas não são projetados para raciocínio de dados em múltiplas etapas da maneira que os sistemas de análise agentiva são.

Um sistema agentivo executa um loop em vez disso:

Perceber é o ponto de entrada: uma pergunta chega, ou um gatilho automatizado é acionado, como uma violação de limite de anomalia ou uma verificação programada. Raciocinar é onde o agente quebra essa pergunta em sub-perguntas menores, cada uma com dependências de dados específicas. Agir é onde ele chama ferramentas: busca semântica no glossário de negócios, execução de SQL contra o armazém, mapeamento de relacionamentos entre entidades. Observar é a verificação: os dados retornados realmente responderam à sub-pergunta, ou o agente precisa investigar mais? Relatar é a saída: todos os resultados intermediários sintetizados em uma resposta em linguagem natural com toda a cadeia de raciocínio visível.

Aquela etapa de Agir é onde as coisas ficam interessantes, e onde as arquiteturas tendem a divergir. Um agente chamando ferramentas contra um esquema de tabela bruta tem que adivinhar: nomes de colunas, condições de junção, o que uma determinada métrica realmente significa. Um agente chamando ferramentas contra uma camada semântica fundamentada recupera definições autoritativas e gera SQL que corresponde à forma como seus analistas realmente calculam a receita. Essa diferença é sobre o que o resto deste artigo realmente trata.

Por Que Painéis Atingem um Teto de Engenharia

A análise baseada em painéis tem um problema estrutural de latência que não é discutido o suficiente. Em uma pesquisa da Gartner de 2024, mais de 60% dos líderes de dados classificaram "reduzir o tempo para ação" como sua principal prioridade para investimentos em análise, e os painéis são uma razão central pela qual essa lacuna existe. Um painel reflete as perguntas que seu analista pensou em fazer durante a sessão de planejamento da última sprint. As perguntas que seu diretor de RevOps dispara no Slack na tarde de terça-feira, aquelas que envolvem correlações de múltiplas métricas ou tendências que precisam ser explicadas, nunca estariam em nenhum painel porque ninguém pensou em fazê-las duas semanas atrás, quando foi construído.

O BI self-service ajuda, mas apenas até certo ponto. Perguntas simples (receita por região, negócios fechados neste mês) vão para o self-service. As mais difíceis, como por que a taxa de vitória caiu 12% em contas empresariais no terceiro trimestre enquanto as de PME se mantiveram estáveis, ainda precisam de um analista para traduzir a intenção em SQL, validar a lógica de junção e confirmar que "ARR líquido" na exportação do Salesforce realmente significa a mesma coisa que "ARR líquido" no armazém antes que alguém possa responder.

E é aí que o verdadeiro problema reside. Definições de métricas, lógica de junção e regras de negócios tendem a se acumular na cabeça das pessoas, em threads do Slack, em LookML não documentados, em comentários de arquivos SQL que apenas um analista sabe que existem. Quando você aponta um LLM diretamente para um esquema bruto, ele tem que adivinhar: o que significa opp_arr_adjusted, qual tabela accounts deve ser unida, deve usar closed_date ou booked_date para reconhecimento de ARR? Essas adivinhações são de onde vêm as alucinações de agentes em tarefas de dados. O ingrediente que falta é contexto, não um modelo melhor.

O problema piora à medida que sua organização de dados cresce. A lacuna entre o que está documentado e o que as pessoas realmente sabem se amplia com o tempo. Uma arquitetura de análise agentiva bem projetada fecha essa lacuna na camada de infraestrutura, antes que o LLM veja uma consulta.

A Arquitetura de Três Camadas de um Sistema de Análise Agentiva em Produção

Construir análises agentivas que realmente funcionem em produção significa acertar três camadas. Cada uma tem um nível diferente de complexidade de engenharia, e cada uma desempenha um papel distinto em se o seu agente retorna respostas em que você pode confiar.

Camada 1: Acesso a Dados

Esta camada cobre conectores para armazéns (Snowflake, BigQuery, Databricks, Redshift) e para ferramentas de BI, modelos dbt, logs de consulta e repositórios de documentos. Honestamente, este é em grande parte um problema resolvido. Ecossistemas de conectores maduros e APIs estáveis significam que a configuração é principalmente trabalho de configuração. O har