The Augmented Consultant by Hugo Lourenço Silva
Power BI

Reviewing 200 DAX measures with Claude

Publicado

O que um agente de IA encontra num modelo inchado, o que lhe escapa, e porque é que a revisão humana continua a decidir.

Um modelo de Power BI que já está em produção há alguns anos tende a acabar no mesmo sítio: mais de 200 medidas, construídas por várias pessoas que entretanto saíram, e ninguém que diga com confiança em que medida confiar para algo tão básico como a receita. Cada novo pedido acrescenta só mais uma medida à pilha, porque escrever uma nova é mais rápido do que entender as antigas. É um dos padrões mais familiares em BI legado.

É assim que reviso um modelo desses, o que um agente de IA encontra de forma fiável, e onde ainda precisa de mim. Quando pego num, paro de acrescentar medidas e começo com uma revisão read-only: o Claude Code ligado ao local Power BI MCP server, atualmente em preview. Uso-o para inventariar os objetos do modelo, inspecionar definições de medidas e dependências, e correr queries DAX de validação dirigidas.

Como faço uma revisão destas

O objetivo não é deixar o agente reescrever o modelo. É deixá-lo ler o modelo a uma escala que eu não consigo, e entregar-me um mapa sobre o qual posso agir.

  1. Inventariar cada medida, coluna, relação e dependência através do MCP.
  2. Agrupar as medidas por padrões de DAX normalizados, semelhanças de nomes e sinais de dependência.
  3. Classificar cada achado como candidato a duplicado, problema de naming, falha de documentação, ou lógica que precisa de revisão. Nada é “redundante” ainda, apenas um candidato.
  4. Validar cada alteração proposta com queries DAX dirigidas, verificações de report e de consumidores a jusante quando disponíveis, e contexto de negócio, antes de a aplicar.

Um revisor humano costuma percorrer as medidas uma a uma e vai perdendo a visão de conjunto. Um agente consegue inventariar, recuperar e comparar o modelo inteiro de forma muito mais sistemática. É essa diferença que justifica usá-lo.

O que faz aparecer

Um primeiro grupo de candidatos costuma ter este aspeto:

Total Sales      = SUMX(Sales, Sales[Qty] * Sales[Price])
Revenue          = SUMX(Sales, Sales[Qty] * Sales[Price])
Sales Amount LY  = SUMX(Sales, Sales[Qty] * Sales[Price])  -- não é de ano anterior nenhum

Três nomes, um cálculo, e uma terceira medida cujo nome promete um valor de ano anterior que nunca calcula. O agente propõe uma única medida canónica Total Sales, um mapa de renomeação para as referências que apontam para os duplicados, e marca a mal nomeada para revisão.

Um modelo destes costuma esconder dez ou mais grupos do mesmo género, e nem todos são duplicados a sério. Algumas medidas diferem só numa chamada a FORMAT. Essas não são candidatas a fusão imediata: o FORMAT pode mudar o tipo de retorno de número para texto, alterar o comportamento de ordenação, ou partir um visual ou um cálculo a jusante que espera um número.

Outras estão embrulhadas num CALCULATE que parece redundante e precisa de validação antes de simplificar. No fim, um modelo que anuncia 200 ideias pode revelar bastantes menos padrões de cálculo distintos, vestidos com muitos mais nomes do que precisa.

Os nomes podem enganar. As display folders podem enganar. O DAX aproxima-te da verdade, mas a intenção de negócio continua a viver fora da fórmula.

Onde se engana

É esta a parte que importa, porque um agente que nunca falhasse seria só um argumento de venda.

Vai marcar como duplicadas medidas que não o são. Duas medidas podem parecer idênticas até reparares num único KEEPFILTERS:

Sales Bikes =
CALCULATE([Total Sales], 'Product'[Category] = "Bikes")

Sales Bikes (Keep Filters) =
CALCULATE([Total Sales], KEEPFILTERS('Product'[Category] = "Bikes"))

A primeira substitui um filtro existente em Product[Category]. A segunda cruza-se com ele. Num report já filtrado por Accessories, uma pode ainda devolver vendas de Bikes enquanto a outra devolve vazio. DAX parecido, comportamento de negócio diferente.

O agente vê duas expressões quase iguais. Só o contexto do report, a intenção de negócio e o impacto a jusante te dizem se têm de ficar separadas. Junta-as por palavra do agente e um report de que alguém depende pode começar a devolver números diferentes em silêncio.

É por isso que cada achado é um candidato, não um veredicto. O agente lê mais depressa do que qualquer humano e nunca se cansa na medida 174. Mas não sabe qual de duas medidas quase iguais é a que o negócio usa, nem que a “redundante” é estrutural num único report que ninguém lhe disse que existia.

Deleguei a leitura, não a decisão

Esta distinção é o método todo. Não deleguei a decisão. Deleguei a leitura. O agente deu-me um mapa que eu nunca conseguiria construir à mão no tempo que tinha: cada candidato a duplicado, cada medida sem descrição, cada nome que promete algo que o DAX não entrega. Depois sentei-me com esse mapa e decidi, medida a medida, o que manter, o que juntar e o que deixar em paz por ser discretamente importante.

A auditoria foi rápida por causa do agente e correta por causa da revisão.

Antes de ligar um modelo a um agente

Uma cautela que importa mais em consultoria do que em quase qualquer outro sítio. Dependendo do cliente MCP e do fornecedor do LLM, os metadados, schemas e resultados de queries expostos através das ferramentas podem ser processados fora da fronteira de compliance do Fabric.

Antes de ligar um modelo de cliente a um agente, confirma o cliente aprovado, o fornecedor do modelo, a configuração do tenant, as permissões, o âmbito de acesso e os termos de tratamento de dados. Começa com análise read-only, trabalha a partir de um backup ou de um branch PBIP, e lembra-te de que o servidor ainda está em preview.

O agente não decidiu o que o modelo devia tornar-se. Tornou o modelo legível o suficiente para eu decidir.

Referências