Responder é fácil. Investigar é que é difícil

A cena

A margem bruta caiu três pontos percentuais no trimestre. O comitê se reúne na quinta-feira. Alguém precisa explicar o que aconteceu.

Esse é um exemplo didático, construído para ilustrar o raciocínio. Não vem de uma empresa específica e os valores não representam nenhum cliente.

Uma ferramenta de GenBI responde a primeira pergunta em segundos. A margem caiu, aqui está o gráfico, aqui está a variação em relação ao trimestre anterior. O número está certo. A consulta está certa. E ninguém decide nada com isso.

O que separa a resposta da decisão não é a qualidade do número. É tudo o que vem depois dele.

O problema, em linguagem de negócio

Investigação analítica não é uma lista de perguntas. É uma cadeia. Cada pergunta só existe porque a anterior foi respondida de um jeito e não de outro.

No caso da margem, o caminho costuma ser assim:

1. 01

   Onde a queda aconteceu

   A quebra por produto, região e canal mostra que a queda não está distribuída. Está concentrada em um canal.

2. 02

   Preço ou custo

   Isso muda a segunda pergunta. Já não interessa a empresa inteira, interessa aquele canal. E dentro dele a pergunta é se a margem caiu porque o preço baixou ou porque o custo subiu. O preço médio se manteve. O custo subiu.

3. 03

   Custo subiu em quê

   A terceira pergunta só faz sentido por causa dessa resposta. Se o custo subiu, subiu em quê? Insumo, frete, fornecedor, algum reajuste contratual.

4. 04

   Ou o mix mudou

   Antes de seguir por aí aparece uma quarta pergunta, que é uma armadilha comum. Talvez nada tenha subido de fato. Talvez o mix tenha mudado, com mais volume de produtos de margem naturalmente mais baixa. O custo unitário médio sobe sem que nenhum custo tenha aumentado.

5. 05

   A comparação decide

   A quinta etapa é a que decide entre as duas explicações. A comparação do mix do trimestre com o do trimestre anterior confirma ou enfraquece a hipótese do mix.

São cinco perguntas encadeadas, e na prática costumam ser dez ou quinze consultas, porque cada uma abre variações. Repare no ponto central: nenhuma dessas perguntas poderia ter sido escrita no começo. Elas foram produzidas pelas respostas anteriores.

É por isso que a experiência de perguntar e receber uma resposta, por melhor que seja, resolve só o primeiro passo.

O mecanismo técnico que produz o problema

A maior parte das interfaces de conversa com dados trata cada pergunta como se fosse a primeira. Ela recebe o texto, recupera um pedaço do esquema, gera uma consulta, executa e devolve o resultado. No turno seguinte, repete o processo quase do zero.

Isso funciona bem para consulta pontual e falha em investigação, porque uma investigação precisa carregar quatro coisas de um passo para o outro:

A pergunta de negócio original. Depois de quatro consultas, o sistema ainda precisa saber que tudo aquilo existe para explicar uma queda de margem, e não para produzir gráficos de custo.

As evidências já obtidas. O preço médio se manteve. Isso já foi verificado e não precisa ser verificado de novo, mas precisa continuar valendo como restrição para as próximas etapas.

A hipótese ativa. Existe uma diferença grande entre consultar dados de custo por curiosidade e consultar dados de custo para testar a hipótese de que o custo explica a queda. A segunda define o que conta como confirmação e o que conta como refutação.

O que já foi descartado. Sem esse registro, o sistema volta a sugerir caminhos que a própria investigação já eliminou, e a pessoa perde tempo explicando de novo.

Some-se a isso a camada semântica. O sistema pode encontrar a coluna certa e ainda assim usar o conceito errado, porque margem pode ser bruta ou líquida, pode considerar ou não frete e devolução, e pode ser calculada por data de emissão ou por data de reconhecimento de receita. A investigação encadeada amplifica esse risco, porque um conceito interpretado de um jeito no passo dois contamina silenciosamente os passos três, quatro e cinco.

O que a evidência pública mostra

Existe um dado útil aqui, e ele não vem de fornecedor.

O Spider 2.0 é um conjunto de avaliação criado para medir modelos de linguagem em fluxos de texto para SQL parecidos com os de empresas de verdade. São 632 problemas construídos a partir de aplicações reais, com bases que passam de mil colunas, hospedadas em ambientes como BigQuery e Snowflake, e tarefas que exigem ler metadados, documentação de dialeto e às vezes o código do próprio projeto. Segundo os autores, no lançamento em 2024 o melhor modelo da época resolvia 17,1% das tarefas, e um modelo bastante usado ficava em 10,1%, contra mais de 86% no Spider 1.0, que era o teste anterior e bem mais simples.

O detalhe mais interessante, porém, é o que aconteceu depois.

Consultei o quadro público de resultados do Spider 2.0 em 3 de setembro de 2026. Esta é uma observação própria sobre dados públicos, não um experimento controlado, e vale com as limitações que descrevo adiante. Três padrões aparecem:

Primeiro, o teto subiu muito. Os primeiros colocados no cenário Spider 2.0-Snow hoje passam de 90% de acerto. O problema que parecia intransponível em 2024 foi, em boa medida, resolvido.

Segundo, quem resolveu foram arquiteturas, não modelos isolados. Praticamente todos os líderes são sistemas com nome próprio, montados como agentes que executam etapas, inspecionam o ambiente, testam e corrigem. Não são chamadas diretas a um modelo.

Terceiro, e aqui está o ponto do artigo, o mesmo modelo produz resultados muito diferentes conforme o processo montado em volta dele. No mesmo cenário e com o mesmo modelo por trás, uma configuração que acrescenta uma etapa de deliberação aparece cerca de oito pontos acima da configuração sem essa etapa. A diferença não veio de trocar o modelo. Veio de mudar o que acontece entre uma consulta e a próxima.

Há um quarto sinal que reforça a tese pelo lado contrário. Existe um cenário do mesmo teste em que a tarefa exige entender o código de transformação do próprio projeto, e não apenas consultar o banco. Nesse cenário, o melhor resultado público está bem abaixo do topo dos outros. Quando o desafio deixa de ser escrever SQL e passa a ser entender a lógica que a empresa construiu em cima dos seus dados, a dificuldade volta a subir.

Essa é exatamente a diferença entre responder e investigar.

O que o mercado está chamando de Agentic BI

O termo circula com sentidos diferentes, e vale separar o que é fato datável do que é interpretação.

Como fato: a Gartner publicou em fevereiro de 2026 um Market Guide para Agentic Analytics, o que indica que a categoria deixou de ser conversa de fornecedor e passou a ter contorno de mercado reconhecido. Páginas de fornecedores citados no documento reproduzem uma previsão da consultoria de que, até 2028, boa parte do uso exploratório de análise vai acontecer em modelos de linguagem de uso geral, enquanto o relatório de produção continua nas plataformas tradicionais de BI. Como essa citação chega por meio de material comercial, ela deve ser lida como o que é, uma previsão de consultoria reproduzida por quem tem interesse no tema.

Também circula, em relatos de imprensa sobre as previsões da consultoria para dados e analytics, a recomendação de que fluxos analíticos sejam redesenhados para incluir uma etapa obrigatória de avaliação, e o alerta de que uma parte relevante dos projetos de IA agêntica deve ser cancelada por falta de valor claro e de controles.

Onde a IA entra e onde a pessoa entra

Vale ser específico, porque dizer que a IA não substitui o ser humano não ajuda ninguém a decidir nada.

No caso da margem, a IA pode interpretar a pergunta inicial, propor as quebras que fazem sentido, gerar e executar as consultas, comparar segmentos e períodos, organizar as evidências obtidas em cada passo, apontar quando um resultado é compatível com mais de uma explicação e sugerir qual seria a próxima verificação. Ela pode também manter o registro do caminho, que é a parte mais chata e a que as pessoas mais deixam de fazer.

A pessoa que conhece o negócio faz outra coisa. Define o que a empresa chama de margem, e essa definição não sai dos dados. Escolhe quais hipóteses merecem esforço, porque quase sempre há mais hipóteses plausíveis do que tempo. Percebe a informação que está faltando, como um reajuste contratual que não está em nenhuma tabela. Avalia se a comparação faz sentido, por exemplo se comparar dois trimestres com sazonalidades diferentes engana mais do que explica. E decide quando existe evidência suficiente para agir, que é um julgamento de risco, não um cálculo.

Há uma linha que precisa ficar clara em qualquer sistema desse tipo. Encontrar que custo e margem se movem juntos é uma associação. Associação orienta a investigação e pode fortalecer uma hipótese. Ela não estabelece causa. Um sistema que apresenta correlação com linguagem de explicação está produzindo confiança que os dados não sustentam.

Como aplicar isso em um projeto de GenBI

Se você está avaliando uma ferramenta ou construindo uma, estas são perguntas que separam demonstração de operação:

O sistema guarda o caminho da análise? Depois de uma investigação de dez consultas, existe um registro do que foi perguntado, do que foi executado, do que voltou e em que ordem? Se esse registro só existe na rolagem de um chat, ele não serve para revisão.

A consulta executada é recuperável? Não basta mostrar o gráfico. Precisa ser possível ver o SQL que produziu aquele número e executá-lo de novo obtendo o mesmo resultado.

A hipótese é um objeto explícito? Ou o sistema apenas encadeia perguntas sem saber o que está tentando confirmar ou derrubar?

Existe ponto de revisão definido? Quais etapas rodam sozinhas e em qual momento uma pessoa precisa aprovar antes de seguir. Isso é decisão de projeto, não configuração acidental.

Os conceitos de negócio estão definidos em algum lugar estável? Se margem, receita e cliente ativo não têm definição consistente, a investigação encadeada vai multiplicar a ambiguidade a cada passo, e o erro do passo dois vai chegar disfarçado de conclusão no passo cinco.

Como o sistema é avaliado? Existe um conjunto de perguntas conhecidas com respostas verificadas, rodado quando o modelo, o prompt ou o modelo de dados mudam? Sem isso, não há como saber se uma alteração melhorou ou piorou o resultado.

Limites, riscos e o que este artigo não afirma

Os resultados do Spider 2.0 medem tarefas de texto para SQL em ambientes preparados para avaliação. Eles não medem investigação de negócio com ambiguidade de métrica, contexto organizacional e informação fora do banco, que é justamente a parte mais difícil do problema descrito aqui. Usar esses números como prova de que o GenBI está resolvido seria um erro. Eu os uso para outra coisa, que é mostrar que o ganho recente veio da arquitetura em volta do modelo.

A comparação entre configurações no quadro de resultados é uma leitura de dados públicos feita em uma data específica. Submissões diferentes podem usar orçamentos de computação, número de tentativas e engenharia de prompt bem diferentes. A leitura correta é direcional, e não uma medida limpa do efeito de uma etapa de deliberação.

Registrar o caminho da análise também não é governança. É pré-requisito. Governança envolve quem pode ver o quê, quem aprova definição de métrica, o que acontece quando duas áreas discordam e como uma decisão é auditada depois. Registro sem governança produz muito histórico e nenhuma responsabilidade.

E automatizar a etapa errada custa caro. Automatizar a geração de consulta economiza minutos. Automatizar a escolha da hipótese economiza minutos e transfere para o sistema o julgamento que deveria ser da pessoa. São coisas diferentes e é comum vê-las tratadas como a mesma.

Consequências práticas

Para quem lidera negócio, a pergunta a fazer ao avaliar uma ferramenta muda. Em vez de pedir uma demonstração de pergunta e resposta, peça uma investigação completa de um desvio real, do primeiro sintoma até a hipótese testável, e peça para ver o registro do caminho no final.

Para quem trabalha com dados e engenharia, o trabalho crítico se desloca. Deixa de ser só qualidade do SQL gerado e passa a incluir definição semântica estável, registro de execução, reprodutibilidade e um conjunto de avaliação que permita saber se uma mudança melhorou o sistema.

Para quem trabalha com IA, o desenho relevante não é o prompt. É o estado. O que persiste entre um passo e o outro, o que é descartado, o que exige aprovação humana e como isso tudo fica registrado.

Para discutir

Quando um indicador muda na sua empresa, quantas consultas são necessárias até chegar a uma hipótese que possa ser testada?

Esse caminho fica registrado em algum lugar ou depende da memória de quem conduziu a análise?

Na sua operação, o maior atraso está em encontrar o dado, em concordar sobre o que a métrica significa ou em testar a hipótese?

Convite

O problema descrito aqui não é só de SQL nem só de negócio. Ele aparece quando as duas perspectivas não conversam, e é resolvido quando conversam. É esse tipo de discussão prática, em cima de dores reais trazidas por empresas, que queremos aprofundar na GenBI Community BR.

Conheça a comunidade em genbi.com.br.