A economia real da IA empresarial não está no LLM. Está na camada semântica.
- Time ALGOR
- 9 de ago.
- 8 min de leitura
Eu li o paper “Semantic Layers and the Economics of AI on the Warehouse” e obtive uma conclusão muito clara: muitas empresas estão tentando baratear a IA pelo lugar errado.
A obsessão atual é quase sempre a mesma: escolher um modelo mais barato, reduzir tokens, trocar provedor, comprimir prompts, usar modelos menores ou tentar fazer engenharia de prompt mais eficiente.
Tudo isso pode ajudar é claro.
Mas, na minha leitura, o grande custo oculto da IA corporativa não está apenas no modelo de linguagem. Está na forma como esse modelo acessa, interpreta e consulta os dados da empresa.
O paper apresenta um estudo de caso de produção em uma divisão de banco comercial de um banco multinacional Tier 1, comparando caminhos arquiteturais para IA sobre data warehouse. A tese central é forte: a alavanca real de eficiência não é otimizar o LLM, mas colocar uma camada semântica abaixo dele, capaz de entender o contexto de negócio, calcular métricas corretamente e rotear cada consulta para o caminho correto e mais barato dentro do data warehouse.
A camada semântica é uma espécie de dicionário inteligente do negócio entre a IA e o data warehouse.Data warehouse é como o grande depósito organizado de dados da empresa. É lá que ficam informações importantes sobre clientes, vendas, transações, produtos, regiões, canais, receita e outros indicadores usados para tomar decisões.O erro: deixar o LLM “adivinhar” o negócio
O exemplo do paper é simples e poderoso.
Um analista pergunta: “Qual foi a receita da região Nordeste no último trimestre?”
Para um executivo, essa pergunta parece trivial.
Mas, para um LLM não guiado, ela pode virar um labirinto.
O modelo precisa descobrir onde está a métrica de receita, identificar tabelas candidatas, interpretar colunas, entender códigos regionais, descobrir o calendário fiscal correto, gerar SQL, executar a consulta e torcer para que o número final esteja certo. E, pior: quando outro analista faz pergunta parecida, o processo recomeça do zero.
Esse é o ponto crítico.
O LLM não sabe naturalmente o que “receita”, “cliente ativo”, “região”, “canal”, “últimos 12 meses” ou “share de depósitos” significam dentro daquela empresa.
Ele tenta inferir. Ou seja, a IA tentar deduzir sozinha algo que não foi explicado claramente para ela.
E inferência, no contexto de dados corporativos, pode ser cara, lenta e perigosa.
Minha opinião: quando uma empresa deixa o LLM descobrir sozinho a semântica do negócio, ela está pagando para a IA reaprender todos os dias aquilo que a organização já sabe há anos.
A alternativa: IA guiada por camada semântica
O caminho guiado descrito no estudo muda completamente a lógica.
Em vez de o LLM tentar descobrir o significado de cada métrica, a camada semântica já conhece as definições de negócio. Receita é uma medida. Região é uma dimensão. “Último trimestre” é um cálculo temporal com inteligência fiscal. O motor semântico entende essas relações, planeja a consulta correta e executa o caminho mais barato possível no warehouse.
Aqui está a diferença fundamental:
No modelo não guiado, a IA transforma análise em busca.
No modelo guiado, a IA transforma análise em consulta governada.
Essa distinção é decisiva.
A primeira abordagem tenta descobrir o negócio em tempo real. A segunda usa um modelo de negócio previamente definido, governado e reutilizável.
É aqui que o artigo toca em um tema central para a governança de IA: não basta conectar o LLM ao banco de dados. É preciso conectar o LLM à inteligência semântica da organização.
O número que chama atenção: 21.000x
O estudo afirma que, no benchmark, a eficiência medida chegou a uma ordem de grandeza de aproximadamente 21.000x em redução de custo computacional em determinados agregados. O documento mostra que, em um dia típico, foram gerados 6.665 insights, processados 298 TB de dados, com 67% das consultas abaixo de 0,7 segundos, além de uma redução agregada de tempo computacional de 11.425x e redução de tempo faturado de 21.903x.
A tabela de resultados por consulta, na página 13, é ainda mais ilustrativa.
No agregado das cinco consultas testadas, o caminho nativo processou 3,154 TB, enquanto o caminho com AtScale processou 144 MB, resultando em uma redução de 21.903x em bytes faturados.
Isso não é apenas otimização.
É uma mudança de arquitetura.
O estudo mostra que as maiores reduções aparecem justamente em perguntas de alta cardinalidade, como análises multidimensionais de clientes e canais de transação — exatamente os casos em que agentes não guiados tendem a fazer varreduras pesadas em grandes volumes de linhas.
A economia da IA não é apenas token. É warehouse.
Um dos trechos mais importantes do paper está na tradução de custo.
No benchmark, as mesmas cinco consultas custaram US$ 17,93 no caminho não guiado e US$ 0,0008 no caminho com camada semântica, considerando o preço on-demand do BigQuery informado no estudo. Isso representa uma redução de 99,995%.
Essa informação muda a conversa.
Muitas empresas calculam o custo da IA olhando apenas para o consumo de tokens.
Mas, quando agentes começam a consultar warehouses, data lakes e ambientes analíticos em escala, o custo maior pode vir da computação acionada por perguntas mal planejadas.
O paper é direto: não se conserta a economia da IA empresarial apenas comprando tokens mais baratos; corrige-se adicionando a camada que foi pulada — um motor semântico que conhece o negócio e executa a matemática, para que o LLM não precise fazer isso.
Essa frase deveria estar na mesa de todo CIO, CDO e CAIO.
O problema da IA sem semântica: respostas bonitas, números frágeis
O que mais me preocupa não é apenas o custo.
É a confiabilidade.
O estudo mostra exemplos em que o LLM precisa inferir faixas etárias, normalizar gênero, interpretar canais de transação e aplicar regras fiscais. Em uma consulta sobre faixas etárias, o caminho não guiado precisa decidir onde está a data de nascimento, o que significa “hoje” e quais limites usar para cada faixa; uma execução diferente poderia usar limites diferentes, gerando números aparentemente corretos, mas desalinhados com a segmentação oficial da empresa.
Em outra consulta, sobre gênero, o documento mostra que códigos podem variar entre sistemas legados — M/F, 1/2, MALE/FEMALE — exigindo normalização. No caminho guiado, essas regras ficam incorporadas ao modelo semântico, com governança centralizada e pré-agregação.
Para mim, este é o ponto mais estratégico:
A camada semântica não reduz apenas custo. Ela reduz ambiguidade.
E ambiguidade é um dos maiores inimigos da IA corporativa.
Prompt engineering não resolve o problema de fundo
O paper também compara alternativas avaliadas pelo banco: engenharia de prompt, catálogos de metadados, dbt, MCP isolado e AtScale.
A conclusão do documento é dura: cada alternativa resolvia uma parte do problema, mas nenhuma eliminava o ato de “adivinhar”.
A engenharia de prompt melhora a qualidade da tentativa, mas não impede o LLM de inferir esquema, definição de negócio e SQL(Bando de Dados) em tempo real. Catálogos como Atlan ou ferramentas similares ajudam a descrever onde uma métrica pode estar, mas não calculam a métrica. dbt transforma dados em pipelines ELT, mas não resolve consultas contra dados in-place a cada nova pergunta. MCP, sozinho, é uma interface; ele padroniza como um agente chama uma ferramenta, mas não define o que “receita” significa nem calcula o valor.
O dbt é uma ferramenta que ajuda a empresa a organizar e transformar dados depois que eles já foram colocados dentro do data warehouse.Pense assim:A empresa recebe dados de vários lugares: vendas, clientes, financeiro, sistemas internos, site, aplicativo etc.Esses dados entram no data warehouse ainda “crus”, como ingredientes espalhados em uma cozinha. O dbt funciona como uma “receita de preparo”: ele pega esses dados crus e transforma em tabelas mais organizadas, limpas e prontas para análise.ELT significa:E — Extract: extrair os dados dos sistemas. L — Load: carregar esses dados no data warehouse. T — Transform: transformar os dados já dentro do data warehouse. Então, quandoeu digo que o dbt transforma dados em pipelines ELT, eu quero dizer que o dbt é muito bom para criar processos organizados de transformação de dados dentro do warehouse. Mas o paper ressalta que, nesse caso, o banco precisava responder perguntas sobre dados já existentes sem reconstruir tudo a cada nova pergunta; por isso, o dbt foi considerado a ferramenta errada para aquele problema específico.Em uma frase simples: dbt é como uma linha de montagem que pega dados brutos e transforma em dados prontos para análise.Essa distinção é essencial.
MCP não é camada semântica. Catálogo não é motor de cálculo. Prompt não é governança. dbt não é planner semântico de consulta.
Minha leitura: muitas empresas estão confundindo conectividade com inteligência.
Conectar o agente ao dado não significa que o agente entende o dado.
A arquitetura vencedora: IA + MCP + camada semântica + data warehouse
O paper afirma que a arquitetura completa avaliada é composta por IA + MCP + AtScale + Elastic Data Warehouse. O MCP permite que o agente acesse a ferramenta; a camada semântica define medidas e dimensões; o planejador escolhe o caminho correto e mais barato; e o warehouse executa com menor esforço.
Na comparação lado a lado, AtScale aparece como a única alternativa que satisfaz os quatro critérios avaliados: impedir que o LLM continue adivinhando, calcular a resposta, trabalhar sobre dados in-place e rotear para o caminho correto mais barato.
O fechamento do estudo reforça isso: a solução codifica definições de negócio uma vez, como medidas e dimensões; roteia cada consulta de agente por meio de um planejador consciente de agregados; executa a consulta correta e mais barata no BigQuery; e expõe o resultado por uma interface MCP desenhada para tráfego de agentes.
Na prática, isso aponta para um novo padrão de arquitetura:
o LLM conversa, mas não deve improvisar a matemática do negócio.
A matemática precisa ser governada.
A camada semântica como peça de governança de IA
Minha principal opinião é esta: a camada semântica deve deixar de ser vista apenas como componente técnico de BI e passar a ser tratada como componente crítico de governança de IA.
Por quê?
Porque a empresa do futuro não terá apenas pessoas consultando dashboards.
Terá agentes perguntando, resumindo, recomendando, decidindo, priorizando, alertando, negociando e automatizando decisões com base em dados corporativos.
Se esses agentes não tiverem acesso a definições governadas, eles poderão produzir respostas convincentes com números errados.
E número errado em ambiente corporativo não é detalhe.
Pode virar decisão errada. Orçamento errado. Risco mal avaliado. Cliente mal classificado. Receita superestimada. Meta distorcida. Estratégia equivocada.
A camada semântica é o lugar onde a empresa diz para a IA:
“Na nossa organização, esta métrica significa isso. Este cálculo é feito assim. Este calendário fiscal segue esta regra. Esta dimensão tem esta taxonomia. Este número é governado por esta definição.”
Sem isso, a IA pode até responder rápido.
Mas responder rápido sem semântica é apenas acelerar a incerteza.
O alerta para conselhos e executivos
Executivos não deveriam perguntar apenas qual modelo a empresa vai usar.
Deveriam perguntar:
A IA entende nossas métricas oficiais? Sabe a diferença entre receita bruta, líquida, recorrente e reconhecida? Sabe o calendário fiscal da empresa? Sabe quais dimensões são oficiais? Sabe quais regras foram aprovadas por finanças, risco, comercial e compliance? Sabe quando consultar agregado e quando consultar tabela-base? Sabe evitar scans desnecessários? Sabe explicar a origem do número?
Se a resposta for não, então a empresa não tem uma arquitetura de IA analítica. Tem apenas um LLM tentando ser analista de dados no escuro.
Meu ponto de cautela
Apesar da força do estudo, eu faria uma observação importante: trata-se de um case study publicado pela AtScale, com benchmark descrito a partir de uma carga de trabalho real de um banco Tier 1, mas os detalhes específicos de código-fonte foram recriados genericamente para ilustração. O próprio documento informa que os SQLs apresentados são reconstruções ilustrativas, não as consultas reais do benchmark.
Portanto, eu trataria os números como um sinal arquitetural forte, mas recomendaria que cada empresa fizesse seu próprio benchmark.
A pergunta não é apenas “vou obter exatamente 21.000x?”.
A pergunta correta é:
quanto estou pagando hoje para meus agentes de IA redescobrirem, em tempo real, regras de negócio que já deveriam estar modeladas?
No final eu penso que:
A grande mensagem do paper, para mim, é simples e estratégica:
A IA empresarial não será escalável se continuar operando sem semântica.
O LLM é uma interface poderosa. O MCP é um padrão importante de conexão. O data warehouse é a base computacional. Mas a camada semântica é o contrato de significado entre a empresa e a máquina.
Sem esse contrato, o agente adivinha.
Com esse contrato, o agente consulta.
E essa diferença muda tudo: custo, velocidade, governança, confiabilidade e escalabilidade.
A próxima fase da IA corporativa não será vencida apenas por quem tiver o melhor modelo.
Será vencida por quem tiver os melhores significados governados.
Porque, no fim, a pergunta mais importante não é se a IA sabe responder.
É se ela sabe responder com o mesmo significado que a empresa usa para decidir.
Paper
Comentários