O Copilot chegou ao Power BI com uma promessa: qualquer pessoa pode fazer perguntas em linguagem natural e receber respostas inteligentes sobre os dados. Na prática, o que muita gente descobre é que o Copilot às vezes responde errado, às vezes não entende a pergunta e às vezes devolve um resultado que não faz sentido nenhum.
A culpa, quase sempre, não é do Copilot. É do modelo.
O Copilot não conserta um modelo ruim. Ele amplifica um modelo bom — e escancara um modelo ruim.
Neste artigo vou explicar como o Copilot enxerga seu modelo semântico, por que o Star Schema é o padrão recomendado para IA, o que deixa o Copilot “burro” mesmo com bons dados e como montar um Golden Dataset verdadeiramente “Copilot ready”.
| Para quem é este artigo? Este artigo é para profissionais de Power BI que já conhecem os fundamentos de modelagem e querem entender como preparar seus modelos para trabalhar bem com o Copilot e o Q&A. Se você ainda está aprendendo Star Schema, recomendo ler primeiro o artigo sobre Modelagem Dimensional aqui no Opus Data. |
Como o Copilot enxerga o seu modelo
Antes de falar sobre o que fazer, é importante entender como o Copilot funciona por dentro — porque isso muda completamente a forma de pensar sobre modelagem para IA.
O Copilot não lê DAX como um analista experiente. Ele não “entende” o seu negócio. O que ele faz é interpretar o modelo semântico através de:
| Elemento do modelo | Como o Copilot interpreta |
| Nomes de tabelas e colunas | Vocabulário para entender a pergunta em linguagem natural |
| Relacionamentos (1:*) | Caminho para navegar entre tabelas sem ambiguidade |
| Cardinalidade | Define se a resposta vai ser precisa ou ambígua |
| Direção de filtro | Determina como os dados se propagam nas consultas |
| Medidas DAX | As métricas que o Copilot usa para calcular e responder |
| Pastas de medidas | Contexto semântico — o Copilot sabe que medidas são relacionadas |
Isso significa uma coisa fundamental: modelagem é mais importante que visual para IA. Um dashboard bonito com um modelo bagunçado vai produzir respostas ruins no Copilot. Um modelo semântico limpo e bem estruturado — mesmo com visuais simples — vai produzir respostas muito melhores.
| A regra de ouro. Se um humano se confunde olhando o diagrama do modelo, o Copilot também vai se confundir. A clareza do modelo para humanos é um proxy direto para a qualidade das respostas do Copilot. |
Star Schema — o padrão ouro para Copilot
O Star Schema é explicitamente recomendado pela Microsoft para modelos semânticos no Power BI — e essa recomendação ficou ainda mais importante com a chegada do Copilot.
Por quê? Porque o Star Schema tem exatamente as características que facilitam a interpretação por IA:
- Uma tabela fato central com as métricas de negócio
- Dimensões bem definidas ao redor
- Relacionamentos 1:* claros (um para muitos, sempre da dimensão para o fato)
- Sem cadeias de joins complexos que criam ambiguidade
Exemplo clássico
Dim_Produto ┐
Dim_Cliente ├── Fato_Vendas ── Medidas DAX
Dim_Tempo ┘
Com esse modelo, quando o usuário pergunta “Qual foi o faturamento por categoria de produto no último trimestre?”, o Copilot consegue:
- Identificar “faturamento” como a medida Valor Vendas na Fato_Vendas
- Identificar “categoria de produto” como a coluna Categoria na Dim_Produto
- Identificar “último trimestre” usando a Dim_Tempo
- Navegar os relacionamentos 1:* sem ambiguidade
- Retornar uma resposta correta
Os benefícios diretos do Star Schema para o Copilot:
- Melhor interpretação de perguntas em linguagem natural
- Resultados mais consistentes e confiáveis
- Performance melhor nas consultas
- Menos necessidade de DAX complexo
- Menos erros de ambiguidade
| O Star Schema é o padrão ouro para o modelo semântico no Power BI justamente porque elimina ambiguidades para a IA. |
Snowflake Schema — pode usar, mas com cuidado
O Snowflake Schema não é proibido, mas é menos amigável à IA. Ele normaliza as dimensões — subdividindo-as em tabelas menores — o que cria mais joins e mais possibilidades de ambiguidade para o Copilot.
Quando o Snowflake faz sentido
- Dimensões muito grandes onde a redundância gera problemas de armazenamento
- Hierarquias complexas — como organização corporativa ou produtos muito normalizados
- Limitações impostas pelo Data Warehouse de origem (sistemas legados)
Riscos do Snowflake para o Copilot
- Mais joins → mais ambiguidade na interpretação das perguntas
- Perguntas simples podem gerar respostas estranhas ou incorretas
- O Copilot “se perde” em múltiplas tabelas descritivas sem um caminho claro
| Regra prática. Se puder usar Star Schema, use. Snowflake é exceção, não padrão. Quando usar Snowflake, certifique-se de que os nomes das colunas são semânticos o suficiente para o Copilot entender o contexto sem precisar navegar por todas as tabelas. |
O que deixa o Copilot “burro” — erros comuns em projetos reais
Baseado em projetos reais, estes são os problemas de modelagem que mais prejudicam o desempenho do Copilot:
❌ Problemas estruturais
- Tabela única gigante (o “planilhão”): uma única tabela com centenas de colunas misturando fatos e dimensões. O Copilot não consegue identificar o que é métrica e o que é atributo descritivo.
- Muitas tabelas fato misturadas: quando há múltiplos processos de negócio numa mesma tabela (vendas + devoluções + metas), o Copilot não sabe qual granularidade usar.
- Sem uma Dim_Tempo bem definida: perguntas como “ano passado”, “mês atual” ou “últimos 30 dias” dependem criticamente de uma dimensão de tempo com granularidade correta. Sem ela, o Copilot vai errar ou devolver dados inconsistentes.
❌ Problemas de relacionamento
- Relacionamentos Muitos para Muitos (*:*) sem semântica clara: o Copilot não sabe como filtrar e pode duplicar ou suprimir dados incorretamente.
- Filtros bidirecionais desnecessários: criam ambiguidade sobre como os filtros se propagam, levando a resultados inesperados.
- Relacionamentos entre dimensões: violam o princípio do Star Schema e criam caminhos de navegação confusos.
❌ Problemas de nomenclatura e organização
- Colunas técnicas expostas (ID_, FLAG_, CD_, vlr_): o Copilot não consegue mapear esses nomes para as perguntas do usuário em linguagem natural.
- Medidas misturadas com colunas calculadas: dificulta a identificação do que é uma métrica de negócio.
- Nomes de medidas codificados (Measure_01, calc_vlr): o Copilot não tem como saber o que esse nome significa sem contexto.
Por que o Copilot precisa de uma boa Dim_Tempo
A dimensão de tempo merece atenção especial — é o elemento do modelo que mais impacta a qualidade das respostas do Copilot em perguntas cotidianas.
Quando você diz “ano passado”, parece óbvio para um humano. Para o Copilot, essa frase exige uma série de resoluções:
- Qual é o “agora”? O sistema precisa saber qual é a data atual para calcular “ano passado”. Se esse contexto não estiver bem definido ou atualizado, o sistema pode assumir uma data errada.
- Como traduzir para uma consulta estruturada? “Ano passado” precisa virar algo como: data BETWEEN ‘2025-01-01’ AND ‘2025-12-31’. Sem uma Dim_Tempo com os campos corretos, essa tradução pode falhar ou ser imprecisa.
- Ano calendário ou últimos 12 meses? “Ano passado” pode ser interpretado de duas formas diferentes. Uma boa Dim_Tempo com campos explícitos (Ano, Trimestre, Mês) reduz essa ambiguidade.
Uma Dim_Tempo completa deve ter no mínimo:
- Data (granularidade diária)
- Ano
- Ano Mês (ex: 2025-03)
- Mês (número)
- Mês Nome (Janeiro, Fevereiro…)
- Trimestre
- Dia da Semana
| Dica prática. Quanto mais explícito você for na pergunta, melhor o Copilot responde. “Faturamento de janeiro a dezembro de 2025” é muito mais fácil de processar do que “faturamento do ano passado”. Porém, com uma boa Dim_Tempo, as perguntas relativas também funcionam bem. |
O template Golden Dataset “Copilot ready”
Com base nas boas práticas da Microsoft e na experiência em projetos reais, este é o template de modelo semântico que funciona melhor com o Copilot. Lembre: é um modelo fictício que ilustra os princípios — adapte para o seu cenário específico.
1. Tabela Fato — Fato_Vendas
Uma granularidade clara: 1 linha = 1 venda. Apenas chaves e métricas brutas.
| Tipo | Exemplo |
| Chaves | IdData, IdProduto, IdCliente, IdCanal |
| Métricas | Valor Venda, Quantidade, Custo |
| ❌ NÃO colocar | Nomes, descrições, textos longos |
Regras da tabela fato:
- Sem colunas calculadas de negócio — tudo em medidas DAX
- Métricas brutas apenas — cálculos ficam nas medidas
- Chaves inteiras (não DateTime com hora)
2. Tabelas Dimensão
Dim_Tempo (obrigatória e crítica)
- Data
- Ano
- Ano Mês
- Mês
- Mês Nome
- Trimestre
- Dia da Semana
Dim_Produto
- IdProduto
- Produto
- Categoria
- Subcategoria
- Marca
Dim_Cliente
- IdCliente
- Cliente
- Segmento
- Cidade
- Estado
- Região
Dim_Canal
- IdCanal
- Canal Venda
| Dimensões achatadas. Prefira dimensões desnormalizadas (Star Schema) — coloque Categoria e Subcategoria direto na Dim_Produto em vez de criar tabelas separadas. O Copilot entende melhor o contexto quando os atributos estão na mesma dimensão. |
3. Relacionamentos
✅ Sempre que possível:
- 1:* (Dim → Fato) — um da dimensão, muitos do fato
- Direção de filtro única (da dimensão para o fato)
- Coluna chave inteira (não DateTime)
❌ Evitar:
- Muitos para Muitos (*:*) sem semântica clara
- Filtros bidirecionais sem necessidade real
- Relacionamentos entre dimensões
4. Medidas DAX
— Pasta: Medidas | Vendas
Valor Vendas = SUM(Fato_Vendas[Valor Venda])
Quantidade Vendida = SUM(Fato_Vendas[Quantidade])
Custo Total = SUM(Fato_Vendas[Custo])
Margem = [Valor Vendas] – [Custo Total]
Margem % = DIVIDE([Margem], [Valor Vendas])
Boas práticas para medidas:
- Nomes legíveis — como o usuário falaria (‘Valor Vendas’, não ‘vlr_vnd’)
- Organizadas em pastas por tema (Vendas, Financeiro, Clientes)
- Tudo que é cálculo = medida, nunca coluna calculada
5. Nomenclatura — o fator mais subestimado
O Copilot usa os nomes de tabelas, colunas e medidas para interpretar as perguntas em linguagem natural. Esse é um dos fatores que mais impacta a qualidade das respostas — e um dos mais negligenciados.
| ❌ Ruim | ✅ Bom |
| vlr_vnd | Valor Vendas |
| qt | Quantidade |
| dt_ref | Data |
| calc_01 | Margem % |
| ID_PROD | IdProduto |
| FLAG_ATIVO | Ativo |
| Measure_01 | Ticket Médio |
| vlr_vd_calc | Receita Líquida |
A regra é simples: nomeie como o usuário de negócio falaria, não como o sistema de origem registra.
6. O que NÃO entra no Golden Dataset
- Dados raw (Bronze): dados brutos sem limpeza ou padronização.
- Lógicas intermediárias (Silver): transformações que ainda não estão prontas para consumo.
- Colunas técnicas: IDs duplicados, flags, códigos legados, campos de auditoria.
- Métricas temporárias: cálculos de teste ou protótipos que não devem ser expostos ao usuário.
- Tabelas criadas só para visualização: lógica de apresentação não pertence ao modelo semântico.
A arquitetura completa — do Bronze ao Copilot
O Golden Dataset não existe isolado — ele é o resultado de um processo de transformação em camadas que segue a arquitetura Medallion:
Bronze → Silver → Gold
↓
Power BI Semantic Model (Golden Dataset)
↓
Dashboards | Copilot | Q&A
É exatamente na camada Gold que o Copilot funciona melhor. O modelo semântico do Power BI deve consumir dados já tratados e modelados — nunca dados brutos ou intermediários.
| O insight fundamental. O Copilot não “entende dados” — ele entende modelos semânticos. A qualidade das respostas é diretamente proporcional à qualidade do modelo semântico que você construiu. |
Checklist prático — modelo Copilot ready
Use esta checklist antes de publicar um modelo semântico no Power BI Service:
Estrutura
- Star Schema como padrão — uma tabela fato por processo de negócio
- Dimensões compartilhadas quando fizer sentido (Dim_Tempo usada por múltiplas fatos)
- Dim_Tempo com todos os campos necessários para períodos relativos
Relacionamentos
- ✅ 1:* (Um para muitos) — sempre que possível
- ✅ Direção de filtro simples (Dim → Fato)
- ❌ Evitar bidirecional
- ❌ Evitar Many-to-Many sem semântica clara
Medidas
- ✅ Tudo que é cálculo = medida DAX
- ✅ Pasta de medidas organizada por tema
- ❌ Nenhuma lógica de negócio em coluna calculada
- ❌ Nomes codificados (Measure_01, vlr_calc)
Nomenclatura
- ✅ Nomes legíveis como o usuário falaria (‘Valor Vendas’, ‘Qtd Pedidos’)
- ✅ Tabelas com nomes claros (Fato_Vendas, Dim_Cliente)
- ❌ Colunas técnicas expostas (ID_, FLAG_, CD_, _calc)
- ❌ Abreviações que só fazem sentido internamente
O que não está no modelo
- ❌ Dados Bronze ou Silver
- ❌ Colunas de auditoria ou controle interno
- ❌ Métricas temporárias ou de teste
Conclusão
O Copilot no Power BI é uma ferramenta poderosa — mas só quando o modelo semântico está à altura. Não existe atalho: IA boa requer modelagem boa.
Se você usar Star Schema, dimensões claras, medidas bem nomeadas e um Golden Dataset reutilizável, você vai ter respostas muito melhores do Copilot, menos DAX complexo, datasets que outros times podem reutilizar e governança de dados de verdade.
O investimento em modelagem semântica de qualidade nunca foi tão estratégico quanto agora — porque é exatamente essa camada que determina o quanto a IA vai conseguir ajudar os usuários de negócio a tomar decisões com dados.
Escrito por Fabio Leandro Ribeiro — Customer Engineer Data/AI na Microsoft. Criador do canal Opus Data no YouTube.