O número está certo. A decisão pode estar errada.

O problema não começa na inteligência artificial

Quando uma resposta gerada por IA apresenta um número inesperado, a primeira reação costuma ser atribuir o problema ao modelo. É possível que o modelo tenha escolhido uma tabela inadequada, aplicado um filtro incorreto ou produzido uma consulta inválida. Esses problemas existem e precisam ser tratados.

Entretanto, há uma classe diferente de falha. Nela, a consulta é válida, o banco retorna o resultado esperado para aquela consulta e a operação matemática está correta. O problema está na interpretação do que o resultado representa.

Termos como vendas, clientes ativos, receita, margem, região e estoque parecem objetivos, mas frequentemente carregam decisões implícitas. Vendas pode significar pedidos realizados, pedidos faturados, receita líquida ou quantidade de itens. Cliente ativo pode ser aquele que comprou nos últimos trinta dias, aquele que possui contrato vigente ou aquele que interagiu com a empresa em determinado período. Região pode representar uma divisão geográfica, comercial, logística ou gerencial.

Enquanto a análise depende de poucas pessoas, parte dessa ambiguidade pode ser compensada pela experiência. Um analista que trabalha há anos com uma área conhece as convenções utilizadas nas reuniões, sabe quais filtros são esperados e consegue perguntar quando percebe que o pedido está incompleto. O conhecimento permanece na cabeça das pessoas e é reconstruído a cada nova análise.

O GenBI muda essa dinâmica porque aproxima a pergunta dos dados. Mais pessoas podem fazer perguntas, em mais situações e com menos intermediação. Isso é uma oportunidade extraordinária, mas também aumenta o impacto das definições que antes ficavam implícitas.

A diferença entre estar correto e significar a mesma coisa

No exemplo inicial, o problema não está necessariamente no cálculo do faturamento nem no cálculo da meta. O problema está na comparação entre dois universos diferentes.

A consulta pode fazer um JOIN entre as tabelas, agrupar os dados por região e calcular o percentual de atingimento. Nada disso garante que o conceito de região seja equivalente nos dois processos.

Essa é uma distinção fundamental para qualquer ambiente analítico: mesmo nome não significa mesmo conceito.

Em uma organização madura, uma dimensão compartilhada por diferentes processos precisa representar a mesma definição, utilizar uma chave compatível e obedecer às mesmas regras de negócio. Quando vendas e metas utilizam a dimensão região de forma realmente consistente, a comparação se torna semanticamente possível. Se uma das áreas possui dados apenas para parte da região, surge outro problema, relacionado à cobertura. A definição pode ser a mesma, mas os dados disponíveis podem não abranger o mesmo universo.

Por isso, uma comparação confiável depende de pelo menos três perguntas. Estamos falando da mesma coisa? Temos dados para as mesmas entidades ou períodos? As métricas estão no mesmo nível de análise?

Antes de qualquer JOIN, existe uma pergunta sobre o grão

Outro conceito decisivo é a granularidade, também chamada de grain. Ela responde a uma pergunta aparentemente simples: o que exatamente uma linha representa?

Uma tabela pode ter uma linha por pedido. Outra pode ter uma linha por item do pedido. Uma terceira pode ter uma linha por cliente e dia. Todas podem estar corretas, desde que o evento representado esteja claramente definido.

O problema surge quando uma medida de um nível é levada para outro nível sem o devido tratamento. Suponha que um pedido de R$ 1.000 possua três itens. Se o cabeçalho do pedido for combinado diretamente com a tabela de itens e o valor total for somado depois do JOIN, o valor do pedido poderá aparecer três vezes. O resultado será R$ 3.000, embora a empresa tenha vendido apenas R$ 1.000 naquele pedido.

O banco não necessariamente está errado. Ele apenas está obedecendo às linhas produzidas pela combinação. A medida foi duplicada porque o nível do pedido foi misturado ao nível dos itens.

A situação fica ainda mais delicada quando duas tabelas representam processos independentes. Imagine uma tabela de vendas e outra de devoluções, ambas relacionadas ao cliente. Se João possui três vendas e duas devoluções, um JOIN direto entre esses fatos pode produzir seis combinações. Uma venda específica não está automaticamente relacionada a cada uma das devoluções. A combinação artificial pode multiplicar as medidas e criar uma narrativa que não existia nos eventos originais.

Esses problemas são conhecidos na modelagem dimensional como fan trap e chasm trap. Os nomes são técnicos, mas a ideia é bastante concreta. No primeiro caso, um registro de um lado se abre em vários registros do outro lado. No segundo, dois conjuntos independentes de eventos se cruzam por uma dimensão comum e podem produzir combinações indevidas.

O que isso muda em um sistema de GenBI

Uma pessoa experiente pode perceber que uma consulta está misturando granularidades e reformulá-la. Um sistema de GenBI precisa transformar esse conhecimento em regras que possam ser aplicadas de maneira consistente.

Quando uma pergunta envolve vendas e metas por região e mês, por exemplo, as duas fontes podem possuir grãos diferentes. Vendas pode registrar uma linha por item de pedido, enquanto metas pode registrar uma linha por mês, região e categoria. A resposta desejada, contudo, pode exigir uma linha por região e mês.

Nesse caso, o caminho seguro é levar cada fonte separadamente ao grão da análise. A fato de vendas deve ser agregada por região e mês. A fato de metas deve ser agregada por região e mês. Somente depois os dois resultados devem ser combinados.

Esse padrão é frequentemente resumido pela expressão aggregate then join. A regra não significa que fatos diferentes nunca possam ser comparados. Significa que a comparação precisa respeitar o nível analítico da resposta antes que os resultados sejam unidos.

Para o GenBI, essa informação não deveria depender apenas da capacidade de raciocínio do modelo de linguagem. O sistema pode utilizar IA para interpretar que a pessoa deseja comparar vendas e metas por região. Porém, o conhecimento sobre o grão de cada fato, a definição das métricas e as relações autorizadas precisa estar disponível em metadados, regras semânticas ou mecanismos equivalentes de governança.

A separação de responsabilidades é importante. A IA interpreta a linguagem e ajuda a formular o plano. A camada semântica define o significado dos conceitos. O planejador verifica quais fontes e estratégias são adequadas. O mecanismo de execução aplica as regras e produz o resultado.

A Semantic Layer como contrato de significado

Uma coluna chamada net_amount não é automaticamente compreendida como receita líquida por qualquer pessoa ou sistema. Ela pode representar um valor antes ou depois de impostos, descontos, devoluções ou ajustes. Para que a IA responda a perguntas de negócio com consistência, o conceito de receita precisa estar definido em uma camada que conecte o vocabulário da organização à estrutura física do dado.

Essa é uma das funções de uma Semantic Layer. Ela pode registrar que "receita", "faturamento líquido" e outras expressões são formas de chegar a um conceito canônico, desde que a organização tenha decidido que são equivalentes naquele contexto. Também pode indicar qual medida deve ser utilizada, qual agregação é permitida, qual é o grain adequado, quais dimensões podem ser aplicadas e quais exceções precisam ser consideradas.

A camada semântica não elimina toda ambiguidade por decreto. Quando a empresa ainda não decidiu o que significa "vendas", o GenBI não deveria inventar uma definição com base apenas na semelhança entre nomes de colunas. Em situações realmente ambíguas, a melhor resposta pode ser uma pergunta de esclarecimento.

Essa mudança de postura é relevante. Um sistema confiável não é aquele que sempre responde alguma coisa. É aquele que sabe quando possui informação suficiente para responder e quando precisa tornar a incerteza visível.

O papel da modelagem na confiabilidade da IA

É comum tratar modelagem dimensional como uma preocupação restrita ao desenvolvimento do Data Warehouse. No contexto de GenBI, essa visão é limitada. As decisões tomadas na modelagem determinam várias decisões que o sistema precisará tomar durante a interação com o usuário.

O grain informa o nível em que uma medida pode ser analisada. As dimensões informam os contextos pelos quais o evento pode ser filtrado e agrupado. As definições semânticas estabelecem o significado dos indicadores. O histórico determina o que pode ser respondido sobre o passado. As regras de segurança delimitam quais dados cada usuário pode consultar.

Quando essas informações estão explícitas, o GenBI recebe uma base mais confiável para interpretar perguntas e planejar análises. Quando permanecem dispersas em documentos, consultas antigas, conhecimento tácito e convenções não registradas, a ferramenta precisa reconstruir a arquitetura a cada pergunta. Em ambientes simples, isso pode funcionar razoavelmente bem. Em ambientes complexos, o risco de respostas inconsistentes cresce.

Isso não significa que toda organização precise construir a mesma arquitetura ou que um único padrão resolva todos os cenários. Modelos simples podem permitir consultas diretas. Ambientes com muitos fatos, diferentes granularidades, alta volumetria e regras de negócio complexas podem exigir camadas semânticas ou estruturas de serving mais específicas para o consumo analítico.

A decisão importante é não confundir facilidade de conexão com compreensão do negócio. Uma IA pode localizar tabelas relacionadas, identificar nomes parecidos e gerar SQL válido. Isso não prova que ela compreendeu a definição empresarial por trás daqueles dados.

Uma pergunta para levar à prática

Na próxima vez que alguém disser que um número está errado, talvez valha a pena fazer uma investigação um pouco mais cuidadosa. O número foi calculado incorretamente? A consulta utilizou a fonte errada? A medida foi multiplicada por causa do grain? A cobertura dos dados é diferente? Ou duas áreas estão usando a mesma palavra para representar conceitos diferentes?

Essas perguntas não são apenas relevantes para quem constrói pipelines, Data Warehouses ou ferramentas de IA. Elas também são importantes para quem utiliza indicadores para tomar decisões. Uma liderança que entende a diferença entre um resultado matematicamente correto e uma comparação semanticamente válida consegue fazer perguntas melhores e identificar riscos que poderiam passar despercebidos em um dashboard bem apresentado.

O GenBI pode tornar a análise mais rápida, mais acessível e mais iterativa. Porém, velocidade não transforma uma definição ambígua em uma definição correta. A IA pode reduzir o tempo entre a pergunta e a resposta. A qualidade da decisão ainda depende da qualidade do significado atribuído aos dados.

A pergunta central, portanto, não é apenas "a IA acertou o número?". Também precisamos perguntar:

O número representa exatamente aquilo que a organização acredita que ele representa?

É nessa diferença entre cálculo e significado que começa uma parte importante da engenharia de GenBI.

Continue a conversa na GenBI Community BR

Questões como granularidade, métricas, dimensões, semântica, segurança e investigação de negócio raramente pertencem a uma única área. Elas exigem a conversa entre profissionais de BI, dados, analytics, IA, engenharia, negócio e liderança.

A GenBI Community BR foi criada para aproximar essas perspectivas em torno de desafios reais. Se você já enfrentou números divergentes, métricas ambíguas, modelos difíceis de consultar ou dúvidas sobre como aplicar IA aos dados da empresa, participe da comunidade e traga sua experiência para a conversa.

A inscrição é gratuita e não exige cartão. Conheça a comunidade em genbi.com.br.