Pular para o conteúdo

Uma verdade: medidas valem no BI e na IA

Aula 1 de 105 minConhecerAtualizada em 2026-10-04

Vídeo em produção

A gravação desta aula está no lote de produção. O objetivo, o exercício e a documentação já valem. Duração-alvo: 5 min.

Objetivo: Explicar modelo central, releases, grounding

Selo de estado: Preview (teto atual do produto) · Curso ACD-310 — Modelo semântico e modelagem dimensional · Aula 1 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai entender por que o modelo semântico é a única fonte de verdade dos seus números — nos dashboards e nas respostas da IA — e o papel das releases e do grounding em garantir isso.

Vídeo#

Identificador no manifesto: acd-310-01-por-que-um-modelo-semantico · duração-alvo 5 min · tela do produto: /dashboards.

Roteiro:

  1. 00:00–00:50 — O sintoma: três gráficos, três números de "receita" diferentes · tela: /dashboards (lista de painéis da Aurora Varejo)
  2. 00:50–02:00 — O que é o modelo semântico: tabelas, relações e medidas descritas uma vez · tela: /dashboards/[id] (editor, diagrama do modelo)
  3. 02:00–03:10 — Hoje: modelo por dashboard; amanhã (Preview): modelo central por workspace com releases imutáveis · tela: /dashboards/[id] (painel "Modelo semântico do workspace")
  4. 03:10–04:20 — A mesma definição alimentando a IA: grounding em Q&A e text-to-SQL · tela: /ia (Perguntar aos dados)
  5. 04:20–05:00 — Por que isso importa para quem decide: um número, uma vez, auditável · tela: /dashboards/[id] (card "Receita" citado no painel e na resposta da IA)

Conteúdo#

Antes de desenhar a primeira tabela, vale entender por que existe um modelo semântico — porque sem esse "porquê", as próximas nove aulas parecem burocracia.

O problema: cada gráfico decide "receita" de um jeito

Numa planilha ou num dashboard montado sem modelo, cada visual repete, à sua maneira, a mesma decisão de negócio. Um widget soma valor. Outro soma valor_liquido. Um terceiro esquece de excluir devoluções. O resultado é o clássico problema de BI: "o relatório do financeiro mostra R$ 1,2 milhão, o do comercial mostra R$ 1,35 milhão — qual está certo?" Nenhum dos dois está "errado" tecnicamente; eles só nunca combinaram o que "receita" significa.

O modelo semântico resolve isso decidindo, uma vez, como as tabelas se ligam e o que os números significam — para que todo visual, todo relatório e toda resposta de IA falem a mesma língua. Essa é a definição que a documentação de Modelo semântico usa, e é o fio que atravessa as dez aulas deste curso.

Onde isso vive no produto hoje

No ingestia.bi, o modelo vive dentro do editor de cada dashboard (/dashboards/[id], aba do modelo): lá você liga tabelas, define cardinalidade e cria medidas. É o que as aulas 2 a 7 deste curso ensinam a operar.

Mas um modelo por dashboard tem um limite: se dois painéis precisam da mesma "Receita líquida", cada um a reconstrói — e um dia elas divergem. Por isso existe, em Preview, o modelo semântico centralizado por workspace: a mesma definição de tabelas, relações e medidas publicada uma vez e consumida por referência por quantos dashboards precisarem. A publicação gera uma release imutável — uma cópia congelada, numerada (version = anterior + 1) e identificada por checksum — nunca um "sobrescrever silencioso". Editar de novo e publicar cria a versão seguinte; a anterior continua exatamente como estava, para quem ainda a referencia. É esse mecanismo de releases que as aulas 8 e 9 (biblioteca de medidas e governança) detalham.

Nota

O motor de relações, cardinalidade e medidas é GA-candidato — congelado por um conjunto de testes de referência, com resultado idêntico a cada execução. Já o modelo central por workspace (com releases) está em Preview: o mecanismo de publicação existe e é testado, mas o "encaixe" dele em todos os dashboards de um workspace ainda está em consolidação. Nenhuma das duas camadas é GA de produto — o teto continua Preview, como em toda a plataforma.

O mesmo modelo, agora alimentando a IA

A segunda metade do título desta aula — "vale no BI e na IA" — é o motivo pelo qual modelar bem compensa duas vezes. Quando existe um modelo semântico publicado, as capacidades de IA (texto para SQL, perguntas e respostas sobre o painel) usam os ids do modelo — tabelas, relações, medidas — em vez de adivinhar a partir de colunas cruas. A página Como a IA entende seus dados chama isso de grounding: dar ao modelo de linguagem a estrutura e as definições certas antes de pedir uma resposta.

O grounding traz dois ganhos concretos, direto da documentação:

  • Menos ambiguidade. Se um termo como "receita" casa com duas medidas diferentes, a IA recusa responder antes de gastar token e pergunta qual delas você quis dizer — em vez de chutar uma.
  • Verificabilidade. Se uma resposta citar um id que não existe no modelo publicado, a saída é descartada. SQL sem fundamento no modelo real não chega até você.

Na prática, isso quer dizer: a medida central Receita que você vai criar na aula 8 não é só um número bonito num cartão de KPI — é a mesma definição que a IA cita quando alguém pergunta "qual foi a receita de julho?" em /ia. Um modelo bem feito melhora o BI e a IA ao mesmo tempo, porque os dois bebem da mesma fonte.

Erros comuns de quem ainda não pensa em "modelo"

  • Tratar modelo como etapa opcional. Para um gráfico isolado sobre uma tabela só, você pode ignorar modelagem — o wizard de texto para SQL resolve perguntas pontuais sem exigir um modelo. Mas qualquer dashboard que cruza duas tabelas ou mais já se beneficia de ter isso formalizado.
  • Confundir "modelo do dashboard" com "modelo central do workspace". Hoje o primeiro é o caminho normal (GA-candidato no motor); o segundo é Preview e serve para quando várias dashboards precisam da mesma definição.
  • Esperar que o modelo central seja automático. Publicar uma release não migra os dashboards existentes sozinho — o "encaixe" por referência é trabalho em andamento, por isso o selo continua Preview.

Por que isso justifica as próximas nove aulas

Cada conceito que vem a seguir — fato e dimensão (aula 2), a estrela da Aurora (aula 3), cardinalidade e anti-fan-out (aula 4), papéis e pontes (aula 5), calendário (aula 6), colunas calculadas e hierarquias (aula 7), a biblioteca de medidas (aula 8) e a governança de releases (aula 9) — existe para que a "uma verdade" desta aula seja real, não um slogan. A aula 10 fecha o curso te ensinando a diagnosticar quando algo nessa cadeia quebra.

Faça você mesmo#

Esta é uma aula de conhecimento (kind: conhecer): não há exercício operacional no console — o objetivo é consolidar o conceito antes de colocar a mão na massa a partir da aula 2.

  1. Abra /dashboards e escolha um painel existente da Aurora Varejo (ou o de exemplo, se ainda não criou nenhum).
  2. Observe dois visuais que usem a mesma grandeza (por exemplo, dois cartões de "receita" em páginas diferentes) e confira se os números batem.
  3. Abra a aba do modelo do dashboard e localize onde a medida que alimenta esses visuais está definida.
  4. Releia a seção "O mesmo modelo, agora alimentando a IA" acima e, se o workspace tiver IA habilitada, abra /ia e pergunte algo simples sobre um número que você já conhece (ex.: "qual a receita total?").
  5. Compare a resposta da IA com o número do dashboard.

Você terminou quando conseguir explicar, sem olhar a aula, por que um modelo semântico bem definido evita "cada relatório com um número diferente" tanto num gráfico quanto numa resposta de IA.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

Capacidades ensinadas#

C02.1 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".

Carregando seu progresso…