Agentes de IA con herramientas de línea de comandos para gestionar modelos semánticos

Este contenido fue traducido mediante IA y no ha sido revisado por un editor humano. Las imágenes y los gráficos permanecen en su idioma original.

Conclusiones clave

• Este artículo forma parte de una serie. Empieza por la primera parte, aquí.
• Los agentes de IA pueden escribir código y usar herramientas de línea de comandos para administrar modelos semánticos. La CLI de Tabular Editor 2 permite al agente modificar y consultar el modelo, además de ejecutar el Best Practice Analyzer. La CLI de Fabric permite al agente usar cualquiera de las API de Fabric directamente.
• Las interfaces programáticas son lo más flexibles posible y van bien para resultados deterministas mediante scripts. Con este enfoque, puedes hacer cualquier cosa que pueda especificarse en código. Cuando tengas un script o comando que funcione, puedes añadirlo a un repositorio de ejemplos o convertirlo en una macro para reutilizarlo fácilmente en escenarios futuros. Esto no solo es útil para resultados deterministas; además, tu agente mejora y amplía continuamente sus capacidades al tener estos ejemplos a mano para consultarlos.
• Sin embargo, este enfoque es complejo y exige mucho esfuerzo. Tienes que invertir mucho esfuerzo en crear buenas instrucciones y recopilar scripts de ejemplo para empezar. Sin esto, los agentes tienden a alucinar y a perder mucho tiempo. Además, los scripts pueden consumir muchos tokens y ser menos eficaces para explorar o buscar en un modelo que otros enfoques.
• Usa la CLI con archivos de metadatos locales o modelos remotos con la integración de Git habilitada. Así te aseguras de poder rastrear y gestionar los cambios, y revertirlos si el agente comete un error. Te recomendamos aislar el desarrollo agéntico en su propio Workspace, separado del desarrollo humano, ya que todavía es inmaduro y los errores son frecuentes.

Este resumen lo elabora el autor, no la IA.

Uso de herramientas de línea de comandos para modificar modelos semánticos

Esta serie te enseña distintos enfoques para usar la IA y facilitar cambios en un modelo semántico mediante agentes. Un agente para modelos semánticos dispone de herramientas que le permiten leer, consultar y aplicar cambios en un modelo semántico. Usar agentes de esta forma se conoce como desarrollo agéntico, y puede ser una forma útil de complementar las herramientas y flujos de trabajo de desarrollo tradicionales en determinados escenarios.

Hay varias formas de que la IA realice cambios en un modelo semántico, como modificar archivos de metadatos, usar servidores MCP o escribir código. Cada enfoque tiene ventajas y desventajas, y si vas a usar IA para hacer cambios en modelos semánticos, lo más probable es que uses los tres.

Este artículo trata sobre el uso de la interfaz de línea de comandos (CLI) de Tabular Editor 2 para ejecutar C# Scripts y cambiar un modelo semántico, y sobre el uso de la CLI de Fabric para administrarlo.

¿Qué es una herramienta de línea de comandos?

Presentamos brevemente las herramientas de línea de comandos en un artículo anterior. En resumen, estas herramientas te ofrecen una forma alternativa de interactuar con el software en un terminal, escribiendo y ejecutando comandos. Esta interfaz de línea de comandos es una alternativa a una interfaz gráfica de usuario (GUI), y es muy adecuada para agentes.

En este artículo hablamos de dos herramientas de línea de comandos, aunque hay muchas más que podrías usar con Power BI o Fabric:

• Tabular Editor 2 CLI, que usas para ayudarte a desarrollar y administrar modelos semánticos. Viene incluido con Tabular Editor 2; si tienes TE2, entonces tienes su CLI.
• Fabric CLI, que usas para obtener información de Fabric o realizar acciones en Fabric desde la línea de comandos. Debes instalarlo en Python con el paquete ms-fabric-cli.

Aquí tienes un ejemplo de un agente (Claude Code) que usa la CLI de Tabular Editor 2 para modificar un modelo semántico abierto en Power BI Desktop:

Este ejemplo es del primer artículo de esta serie y muestra al agente de programación trabajando con un modelo local abierto en Power BI Desktop. Refactoriza un modelo de tamaño medio para usar una función DAX (la sintaxis de error se debe a un problema en Power BI). Mostraremos algunos ejemplos más adelante, pero primero entendamos qué está pasando aquí.

¿En qué se diferencian los servidores MCP y las herramientas CLI?

Es comprensible que pueda haber cierta confusión entre un agente que usa un servidor MCP y un agente que usa una herramienta CLI. Por ejemplo, en el contexto de los modelos semánticos, ambos pueden interactuar programáticamente con el modelo semántico a través de la biblioteca TOM. Sin embargo, lo hacen de formas distintas. Estas son las principales diferencias funcionales:

• Los servidores MCP proporcionan información (nombres de herramientas, descripciones, recursos) que se carga previamente en el contexto. Con las herramientas CLI no ocurre así; el agente solo sabe que debe usarlas en función de sus datos de entrenamiento u otros archivos personalizados de prompts e instrucciones.
• Los servidores MCP normalmente permiten que la IA ejecute patrones fijos de código con herramientas. Cuando una IA llama a una herramienta, no puede modificar ni ampliar la llamada a la herramienta. En cambio, los agentes que usan herramientas CLI suelen tener más flexibilidad. Combinan comandos con otros (como las “pipes” en Bash). Esto permite al agente ampliar o modificar el resultado de la CLI, o simplemente ser más eficiente con su salida. Daremos un ejemplo de esto más adelante.
• Los servidores MCP son un enfoque específico para ampliar las capacidades de los LLM. Las herramientas CLI se diseñan como cualquier software y pueden usarlas tanto los agentes como las personas. Las herramientas CLI pueden hacerse más amigables para los agentes con salidas y comandos mejores y más descriptivos.

Puedes entenderlo con algunos ejemplos adicionales más adelante.

Diagrama del escenario

El siguiente diagrama muestra una visión general sencilla de cómo puedes usar herramientas de línea de comandos para facilitar el desarrollo agéntico de un modelo semántico:

Este enfoque es muy parecido a cuando trabajas con servidores MCP. Aquí tienes un recorrido:

1. El usuario prepara el contexto, especialmente en lo relativo a cómo debería usar el agente las herramientas de línea de comandos y ejemplos de comandos y C# Scripts. Esto es muy importante.
2. El usuario proporciona instrucciones y prompts para que el agente de programación empiece a trabajar.
3. El agente de programación puede trabajar con modelos locales en Power BI Desktop, metadatos de modelos locales o modelos remotos en un Workspace de PPU o Fabric a través del punto de conexión XMLA. Realiza cambios mediante la CLI de TE2 y ejecuta acciones en Fabric mediante la CLI de Fabric.
4. El usuario valida los cambios en Power BI Desktop o Tabular Editor.
5. Idealmente, el usuario se asegura de que ha configurado control de código fuente para rastrear, gestionar y revertir cambios si es necesario. Esto se hace más fácilmente al trabajar con archivos de metadatos locales, pero también es posible al trabajar con Power BI Desktop o con modelos remotos.

Demostraciones: cómo se ve esto en la práctica

Este enfoque funciona mejor con un agente que vive en la línea de comandos, como GitHub Copilot CLI, Claude Code o Gemini CLI. Mostraremos ejemplos con Claude Code, ya que es el agente de programación que más hemos usado para probar este enfoque.

Ejemplo con Claude Code

Aquí tienes algunos ejemplos de un agente que usa la CLI de Tabular Editor 2.

Primero, aquí tienes un ejemplo sencillo en el que se organiza la tabla Date: se asignan columnas a carpetas de visualización y se configuran correctamente sus propiedades SortByColumn.

Esto, por supuesto, no es todo lo que puedes hacer. Por ejemplo, aquí se ve a un agente configurando un modelo con actualización incremental:

La actualización incremental es molesta de configurar incluso para una persona en la interfaz de usuario. Hacer que el agente lo haga puede ser una forma cómoda y rápida de configurarlo, y de hacer que el proceso de varios pasos sea más comprensible. Esto es especialmente cierto cuando tienes escenarios complejos, como tablas híbridas personalizadas o particiones personalizadas. Sin embargo, esto también puede ser complejo para un agente. En nuestras pruebas, el agente a menudo se confundía cuando veía ejemplos o contexto relacionados con la actualización incremental, lo que hacía que su rendimiento empeorara, y con frecuencia implementaba políticas de actualización que “rompían” el modelo:

De hecho, normalmente es más rápido, más barato y más fiable hacer que el agente use la CLI de TE2 para probar sus scripts en un sandbox y luego que te entregue una macro reutilizable que puedas usar en la GUI de TE2 o TE3. Puedes ver el mismo proceso ejecutándose con una macro de actualización incremental a continuación en una fracción del tiempo, y además es mucho más fácil de entender y de seguir como usuario:

Cómo empezar

Este enfoque es el más flexible, pero también el más complejo en cuanto a configuración. Para usar este enfoque, necesitas tener instalados Tabular Editor 2 y la CLI de Fabric, además de sus distintos requisitos previos. Aquí tienes la lista completa de lo que necesitas:

• Tabular Editor 2 y la CLI de Fabric, además de sus dependencias.
• Tu modelo puede estar en uno de estos tres formatos:
  • Abierto en Power BI Desktop.
  • Guardado en formato PBIP, o su definición en model.bim, TMDL o database.json.
  • Publicado en un Workspace con PPU o en modo de licencia de capacidad de Fabric.
• Un agente de programación que tenga una herramienta de Bash o PowerShell capaz de ejecutar comandos.
• Archivos de contexto y ejemplos tanto para Tabular Editor 2 (incluidos C# Scripts) como para la CLI de Fabric (incluidos los comandos y los endpoints de las API que quieras usar).
• Idealmente, también deberías contar con alguna forma de rastrear y gestionar los cambios en tu modelo.

Diferencias frente a otros enfoques

Hay varias diferencias clave entre este enfoque y los demás. En algunos sentidos, es bastante similar a los servidores MCP, ya que facilita la interacción programática con el modelo semántico. Sin embargo, se diferencia en que este código es arbitrario: lo escribe y lo ejecuta el LLM (o en forma de scripts), en lugar de estar predefinido en una lista fija de herramientas. El agente depende por completo de tus instrucciones y ejemplos para ser “bueno” a la hora de usar la CLI, sobre todo si no está muy presente en los datos de entrenamiento (por ejemplo, en herramientas más nuevas).

Beneficios

Estos son los beneficios clave de este enfoque:

• Flexibilidad: Con este enfoque, el agente no tiene restricciones y puede hacer cualquier cambio que sea capaz de especificar en código. Esto abre muchas más posibilidades, incluso para escenarios muy de nicho y poco comunes. Sin embargo, ten en cuenta que no sabrá cómo hacerlo de forma predeterminada y depende de tus instrucciones y ejemplos para conseguirlo… esta flexibilidad también conlleva ciertos riesgos (consulta los desafíos a continuación).
• Escalabilidad: El beneficio más interesante es que, con el tiempo, puedes mejorar y ampliar las capacidades de tu agente. Cuantos más scripts produzca el agente, más material tendrá para usar como referencia en ejemplos futuros. Incluso puedes hacer que el agente convierta C# Scripts en macros que puedas agregar y usar en la interfaz de usuario de Tabular Editor (TE2 y TE3).
• Seguridad ante cambios: Al igual que con los servidores MCP, es menos probable que “rompas” modelos al hacer cambios, ya que los cambios no permitidos generarán errores y se rechazará la operación de escritura, Los errores también pueden ser útiles para el LLM y permitirle mejorar el script que escribió.
• Bueno para buscar en modelos grandes y complejos: Los agentes de desarrollo que tienen acceso a estas herramientas de la CLI pueden usarlas para acceder con más facilidad a determinados objetos o propiedades en un modelo semántico, sin tener que leer archivos o definiciones completos. Esto puede suponer muchos menos tokens con el tiempo.

Desafíos

Estos son algunos desafíos que son únicos de este enfoque:

• Menos fiable sin contexto: Notarás que este enfoque es el más “torpe”, con más errores y problemas al principio. Sin embargo, a medida que sigas ampliando el contexto y los ejemplos, obtendrás mejores resultados. Aquí podrían ayudar el contexto de otras personas y futuras mejoras en la CLI para hacerla más “amigable para agentes”. Ten en cuenta, no obstante, que el contexto también puede producir resultados peores con malos ejemplos o por darles demasiada importancia.
• Configuración compleja: Este enfoque requiere más tiempo y esfuerzo de configuración. Tienes que incluir algunos ejemplos de cómo usar la CLI y comandos útiles; de lo contrario, puede alucinar.
• Difícil revertir cambios: Este enfoque tiene la misma salvedad que el enfoque de servidores MCP. No puedes ver ni deshacer los cambios fácilmente. Por ello, te recomendamos que uses herramientas de CLI sobre metadatos del modelo o modelos remotos en Workspaces aislados que hayas configurado con integración de Git.
• Riesgos de seguridad: Permitir que un agente escriba y ejecute código arbitrario puede ser problemático. Cuando está escribiendo C# Scripts, por ejemplo, en teoría podría usar esos scripts para llamar a APIs externas o modificar archivos y sistemas locales. Para evitarlo, tienes que gestionar diligentemente los permisos de los agentes y permitirles operar solo con suficiente supervisión humana.

Cuándo podrías usar este enfoque

Este enfoque es útil en dos escenarios principales:

• Cuando necesitas flexibilidad: Un ejemplo clave es cuando quieres implementar un cambio específico pero complejo, como la actualización incremental.
• Cuando quieres ejecutar scripts y macros con resultados deterministas: Por ejemplo, agregar tablas de fechas o de parámetros, o patrones comunes de DAX a tu modelo. Aquí es donde los C# Scripts y las macros también son útiles en la GUI de Tabular Editor.

Cuándo podrías no usar este enfoque

Hay algunos casos en los que este enfoque no es ideal:

• Existen opciones más simples: Manténlo simple, Si puedes hacer la tarea con una herramienta fiable de servidor MCP o modificando los metadatos del modelo, entonces haz eso.
• No te sientes cómodo con la complejidad o la línea de comandos: Si la configuración de este enfoque te resulta abrumadora o incómoda, o no te gusta usar la línea de comandos, entonces este enfoque no es para ti.
• Estás en Mac o Linux (solo CLI de TE2): Actualmente, la CLI de Tabular Editor solo es compatible con Windows. Sin embargo, la CLI de Fabric funciona muy bien con agentes en Mac o Linux. Esto significa que cualquier desarrollo agentivo de modelos semánticos en una máquina Linux o Mac quedará restringido a la modificación de archivos de metadatos.

En resumen, este enfoque te ofrece la máxima flexibilidad, pero a costa de la complejidad necesaria para que funcione como tú quieres. Cuando tienes necesidades específicas que no puedes cubrir con otros enfoques y estás dispuesto a profundizar para hacerlo realidad, este enfoque puede ser el más adecuado. Es especialmente atractivo cuando consideras que los scripts del agente se pueden conservar y reutilizar, lo que le permite ampliar y mejorar sus capacidades con el tiempo.

En conclusión

Si das buenas instrucciones a un agente, puede usar la CLI de Tabular Editor 2 para hacer cambios en un modelo mediante C# Scripts y administrar el modelo mediante la CLI de Fabric, Con este enfoque, el agente puede realizar prácticamente cualquier cambio o ejecutar cualquier operación sobre un modelo semántico. Es especialmente útil para cambios y patrones deterministas, igual que los scripts y las macros en la GUI de Tabular Editor. Sin embargo, no puede hacerlo a menos que le des buenas instrucciones y ejemplos.

Con esto cerramos nuestra serie de artículos que analizan el estado actual del desarrollo agentivo para modelos semánticos. Cada uno de los tres enfoques —agentes sobre metadatos, servidores MCP o herramientas de CLI— tiene fortalezas y debilidades, pero pueden complementarse entre sí. Todos estos enfoques pueden ser una forma útil e interesante de ampliar los flujos de trabajo de desarrollo tradicionales, y es probable que sigan mejorando con el tiempo a medida que esta tecnología madure.