Seguimos explorando las posibilidades que nos trae la IA. En los post anteriores, hemos interactuado con el modelo, haciendo lo que llamamos un End-to-End, o lo que es lo mismo, haciendo el informe desde 0 (parametrización, ETL, DAX y Lienzos). Pero como todos sabéis, hay algo importantísimo que no analizamos ni llevamos al extremo, que es la optimización del modelo. ¿Será capaz Claude de optimizar un modelo semántico? ¿O simplemente hará la limpieza del gato? Vamos a verlo, y no lo vamos a ver con un modelo de juguete, vamos a verlo con modelo de un tamaño considerable, en el que nuestra tabla de hecho tiene nada más y nada menos que 237.245.485 millones de registros.

 

 

Antes de meternos con Claude MCP, vamos a analizar el modelo y ver qué se puede optimizar en el modelo y que no, ya que como suelo insistir, aquí lo importante no es tener X licenciamiento de un LLM en concreto, sino lo importante es tener el conocimiento y las bases necesarias para saber cuales son las buenas prácticas en el diseño de los modelos semánticos.

 

Para ello, vamos a nuestra querido DAX Studio, esa maravillosa herramienta que nos permite analizar el modelo semántico, cuellos de botella etc…

 

Al abrir DAX Studio, lo primero que vemos que nos llama la atención son las tablas de temporales ocultas que tiene el modelo por tener activada la inteligencia temporal:

¿Lo detectará la IA que eso es una mala práctica? Lo veremos… Ahora vamos a analizar el tamaño del modelo:

Vemos que tenemos un modelo de 7.46Gb en memoria, algo que con una licencia PRO ya no podemos trabajar. El modelo consta de 11 tablas (5 de inteligencia de tiempos) y 6 reales del modelo, y 103 columnas.


Ahora si analizamos las tablas, vemos que el grueso del modelo se lo lleva nuestra tabla de hechos llamada “Sales”, algo lógico y previsible, pero…¿Estará todo en orden dentro de ella? Vamos a ver…

 

Si desplegamos la misma, vemos lo siguiente:

 

Más de la mitad del espacio lo consume la columna “Order Number”, que es una columna suele ser una columna candidata a eliminar del modelo dimensional, ya que no aporta valor. Si por el contrario, negocio nos “obliga” a llevarla al modelo, deberíamos usar técnicas de codificación para intentar optimizarlo.

Luego vemos que hay dos columnas, Total Cost y Total Sales, que son columnas que se pueden calcular mediante iteradores. Aquí convendría valorar, al tener tantos registros, si es más óptimo tener el valor calculado o ver el rendimiento de la medida. Pero aquí lo importante es que estas columnas no son nativas de la tabla en sí, sino que son columnas calculadas en el modelo como podéis ver:


 

 

Actuando sobre lo que acabamos de comentar, estaríamos actuando sobre un 60% del tamaño del modelo que de una manera indirecta, actua sobre nuestras medidas DAX. Y digo indirecta ya que a un modelo más ligero, más rápida será nuestra medida DAX que no es lo mismo que óptima. Por ejemplo, tenemos la siguiente medida para calcular los clientes nuevos:

 

Que si nos la llevamos a DAX Studio, vemos lo siguiente:


Que nos está devolviendo CallbackDataID. ¿Y qué es eso? En palabras llanas y mundanas un CallbackDataID es un mecanismo interno del motor de almacenamiento de Power BI/Analysis Services que aparece cuando el motor de fórmulas (FE) necesita intervenir durante la ejecución de una consulta del motor de almacenamiento (SE).

¿Por qué ocurre? El SE normalmente trabaja de forma autónoma y muy eficiente (columnar, paralelo, cacheado). Pero ciertas funciones DAX no pueden ser traducidas a operaciones nativas del SE y requieren que el FE "llame de vuelta" (callback) para evaluar expresiones fila a fila.


Bien, visto que nuestro informe tiene bastantes puntos de mejora, vamos a ver si es capaz de detectarlos y solucionarlos. Para ello, vamos a Claude Desktop, que lo tenemos conectado a nuestro Power BI Modeling MCP Server y le decimos:

 

 

Y nos devuelve lo siguiente:


Pero no sólo eso, sino que nos ha generado un informe de auditoría del modelo semántico:

 

¿Qué os parece? A mi de verdad que me ha dejado maravillado ya que ha afinado bastante. Ahora le indicamos que actúe sobre la Fase 1, que son las críticas y que habíamos detectado en el análisis previo:

 

Y nos devuelve los siguiente:

 

Nos dice que ha eliminado las dos columnas calculadas y que las tablas de inteligencia de tiempos no puede desactivarlas, por lo que debemos hacerlo manualmente. Vamos hacerle caso, y vamos a DAX Studio al terminar:

 

Y vemos que hemos pasado de un modelo de 7.46Gb a un modelo 6.57Gb casi 1 Gb menos de espacio, que no es poco sólo eliminando dos columnas y quitando la inteligencia de tiempos automática. Ahora una vez corregida la fase 1, vamos a por la 2, a ver que resultado nos arroja, para ello:

Y obtenemos lo siguiente:

 

Vamos a ver la medida “Clientes Nuevos” que indica que la ha refactorizado para ver si realmente tenemos alguna mejora. Vamos al informe, ejecutamos de nuevo el analizador de rendimiento y vemos lo siguiente:


Efectivamente, el tiempo de ejecución de la medida se ha reducido aparentemente. Vamos a DAX Studio para verlo más en detalle. Copiamos y pegamos la consulta para analizarla:


 

Y vemos que efectivamente, la consulta ha disminuido tanto el número de consultas como el tiempo de las mismas. Vemos que nos sigue generando un Callback, por dos Callback que nos generaba en la medida anterior. Esto es un paso… ¿Se podría optimizar más? La respuesta es sí. Claude, nos había propuesto esta medida:

El problema: para cada CustomerKey, ejecuta CALCULATE 2 veces. Con millones de clientes, es extremadamente lento. La solución es reformular la lógica sin iteración: un cliente es "nuevo" si no tiene compras antes del periodo actual. Esto se puede expresar con una simple resta de DISTINCTCOUNT:

 

Pero esta medida, tiene margen de mejora, que es:

 

Y si miramos en el analizador de rendimiento ambas medidas:


 

Nos las llevamos a DAX Studio:

 

 

Y podemos ver que está última medida no nos genera ningún CallBack y vemos que los tiempos de ejecución de las consultas se ha reducido considerablemente.

La potencia que tenemos hoy encima de la mesa es incuestionable. Herramientas como Claude, conectadas a un entorno como el Power BI Modeling MCP Server, son capaces de analizar modelos complejos, detectar problemas reales y proponer mejoras que, hace no tanto, requerían horas de experiencia y revisión manual. Eso ya no es el futuro, es el presente.

Pero aquí es donde viene lo importante. La IA no entiende tu modelo como lo entiendes tú. No conoce el contexto de negocio, no sabe por qué una columna está ahí, ni si una medida responde a una necesidad concreta o a un parche histórico. Lo que hace es aplicar patrones, reglas y probabilidad. Y eso, sin una base sólida detrás, es peligroso.

En este post lo hemos visto claro:

  • Ha detectado problemas reales → bien
  • Ha propuesto mejoras → muy bien
  • Ha optimizado parte del modelo → excelente

Pero también:

  • Ha dejado margen de mejora en DAX
  • Ha necesitado supervisión constante

Y aquí está la clave. La diferencia no la marca la IA. La diferencia la marca quién está delante de la IA.

Porque una persona sin conocimiento:

  • No sabrá validar lo que propone
  • No sabrá detectar lo que falta
  • No sabrá llevar la optimización al siguiente nivel

Mientras que una persona con fundamentos:

  • Entiende el modelo
  • Interpreta lo que devuelve la IA
  • Mejora la solución propuesta
  • Y, sobre todo, toma decisiones con criterio

La IA acelera. Pero no sustituye el conocimiento. La IA ayuda. Pero no piensa por ti. La IA propone. Pero no decide.

Y en el mundo del modelado, donde cada decisión impacta directamente en rendimiento, coste y escalabilidad, esto es más crítico que nunca. Ahora tenemos un copiloto brutal, sí, pero sigue haciendo falta alguien que sepa conducir.

Porque al final, esto no va de usar IA. Va de usarla bien. Y te lanzo la siguiente pregunta:

¿Dejarías que te operase yo a corazón abierto apoyado por una IA? La respuesta es NO, te dejarías operar por un cirujano experto apoyado con una IA, no por mí… Lo mismo aplicamos a nuestro trabajo.

¡Nos vemos en los datos!