Microsoft presenta Flint, un lenguaje de visualización para agentes de IA

• Flint es un lenguaje intermedio de visualización que ayuda a los agentes de IA a crear gráficos expresivos a partir de especificaciones breves que las personas pueden editar
• El compilador interpreta los datos, los tipos semánticos, el tipo de gráfico y las codificaciones, y completa automáticamente configuraciones de bajo nivel como escalas, ejes, espaciado y diseño
• Ofrece 46 tipos de gráficos y 83 ejemplos de galería, y soporta renderizado con Vega-Lite, ECharts y Chart.js
• En entornos TypeScript / JavaScript se puede instalar con npm, y en flujos de trabajo con agentes se puede usar un servidor MCP
• Oculta las diferencias de API entre backends detrás de una interfaz unificada, lo que facilita cambiar de renderizador o modificar el diseño del gráfico a partir de la misma especificación

---

El problema que Flint busca resolver

• Flint es un proyecto de Microsoft Research, un lenguaje intermedio de visualización diseñado para que los agentes de IA generen gráficos a partir de especificaciones simples y editables por humanos
• La especificación se compone de datos, tipos semánticos y especificación del gráfico
  • Un ejemplo de especificación define period como YearMonth, totalUsers como Quantity, y gameType y region como Category
  • En un Line Chart, vincula region a column, period a x, totalUsers a y y gameType a color para crear un gráfico de líneas de usuarios activos mensuales por región
• Se puede instalar en entornos TypeScript / JavaScript con npm
• En flujos de trabajo con agentes se puede usar un servidor MCP
• En la gallery se pueden ver 46 tipos de gráficos y 83 ejemplos

Cómo convierte especificaciones en gráficos

• Flint parte de una especificación compacta, genera especificaciones nativas para backends como Vega-Lite y completa los detalles de bajo nivel necesarios para renderizar el gráfico
• Los tipos semánticos expresan el significado de los campos de datos
  • Los ejemplos incluyen tipos como Rank, YearMonth, Delta y Temperature
  • Con base en ellos, Flint infiere configuraciones del gráfico como parsing, escalas, ejes, formato y esquemas de color
  • En un mapa de calor que muestra usuarios netos nuevos por juego y por mes, decide el parser de valores temporales, el formato de ejes y el esquema de color divergente con su punto medio según los tipos semánticos
• La optimización automática del layout se basa en un modelo de layout flexible y en el principio de banking
  • El compilador gestiona dinámicamente tamaño, espaciado y disposición para ajustar el gráfico al lienzo
  • Si aumenta el número de gráficos de barras agrupadas, amplía el lienzo y reduce el band width para que incluso una versión más densa quepa en el lienzo
• Los cambios en el diseño del gráfico se pueden manejar cambiando el tipo de gráfico y reasignando las codificaciones visuales
  • Al convertir un faceted bar chart sobre la distribución de población por sexo y edad del censo de EE. UU. de 2000 en un pyramid chart, el usuario solo cambia el tipo de gráfico y el compilador se encarga del resto

Backends de renderizado y disponibilidad

• Flint soporta 46 tipos de gráficos en Vega-Lite, ECharts y Chart.js
  • Oculta distintas API y modelos de programación detrás de una interfaz unificada
  • Si Vega-Lite no tiene soporte nativo para sunburst, se puede cambiar a ECharts
  • Para visualizar una jerarquía de región × gameType × juego, se presenta un sunburst chart como mejor alternativa que un gráfico de barras agrupadas
• Flint es open source y ya se puede usar
• Se ofrecen GitHub y ejemplos de galería como punto de partida
• Microsoft Research desarrolló Flint en colaboración con IDEAS Lab y Renmin University of China

[GN⁺]

Opiniones de Hacker News

• Entiendo por qué hace falta el marketing de “para agentes de IA”, pero al final, solo con ser un lenguaje que facilita expresar gráficos ya resulta suficientemente impresionante y útil

  • Esto no se puede enfatizar lo suficiente. Que “sea bueno para agentes” significa, en última instancia, que es autoexplicativo, tiene una manipulación clara, valores predeterminados seguros, una salida concisa o controlable y una interfaz programable; y esas características también ayudan a las personas
  • Me parece que esto está hecho literalmente para que los agentes de IA accedan a él mediante un servidor MCP. Si es así, resaltar a los agentes de IA en el marketing parece bastante importante
  • Creo que resumirlo así es correcto. Toda la explicación llamativa parece una forma larga de decir: “mira los datos y decide por sí solo cómo debería verse el gráfico”
    En la página también explican que “en lugar de exigir parámetros verbosos de bajo nivel, como escalas, ejes, intervalos y layout, el compilador de Flint deriva configuraciones de gráficos optimizadas a partir de los datos, los tipos semánticos, el tipo de gráfico y la codificación”
  • También es fácil de generar para un agente, pero además es una forma fácil de editar para una persona, sobre todo si hay una UI
  • Viendo el paquete, parece estar construido encima de bibliotecas de gráficos existentes

• Está apareciendo un nuevo patrón en los sistemas de agentes, y este proyecto es un buen ejemplo
  Consiste en tener alguna representación intermedia (IR) que genera y entrega el LLM, y encima poner una capa determinista como un compilador o generador de código. Creo que en un futuro cercano veremos este tipo de estructura con más frecuencia

  • Cuando vi por primera vez que Claude no creaba un deck de PPT directamente en XML, sino que escribía código Python para generarlo, fue un momento bastante revelador. Creo que muchas tareas irán por ese camino y, aunque a largo plazo se siente un poco limitado y como un hack, por ahora parece el enfoque 100% correcto
  • Estoy totalmente de acuerdo con esta idea. Durante el último mes, todo un trabajo de codificación con agentes lo hice mediante una representación intermedia, y las iteraciones también ocurrieron principalmente en esa capa. Sorprende lo cerca que se puede llegar así a una salida de código determinista
  • Una capa intermedia bien diseñada permite validación y control de forma independiente de la IA. Con esto, la interacción entre humanos e IA pasa de la delegación a la colaboración
  • Exacto. Los sistemas de agentes fueron así desde el principio: generar de forma laxa y seguir reintentando hasta que la entrada sea validada, hasta que salga una forma y tamaño que encajen en el hueco
  • La programación está más viva que nunca

• No aparece en la página, pero al crear visualizaciones de datos es realmente importante incorporar la accesibilidad desde la etapa de diseño
  En este podcast hay una entrevista breve y bien resumida sobre el tema: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
  El entrevistado es Frank Elavsky, que parece ser bastante conocido en este campo, y también creó el proyecto Chartability, que contiene heurísticas, principios y guías para auditorías de accesibilidad: https://chartability.github.io/POUR-CAF/

  • Parece que Flint también necesitaría trabajo de soporte de accesibilidad, y este es un buen punto para tratar los problemas de accesibilidad de forma centralizada
    Agregué un issue para hacer seguimiento: https://github.com/microsoft/flint-chart/issues/48

• Me pregunto si hay una explicación concreta de cómo esto es mejor o diferente que Vega en sí: https://vega.github.io/vega/docs/specification/
  Vega ya es un DSL expresivo para visualizaciones, y seguramente está incluido de forma bastante amplia en los datos de entrenamiento de los LLM

  • Antes, Vega era un lenguaje de alto nivel para las personas, pero ahora quizá sea más bien un poco de bajo nivel para agentes de IA. Para que un agente cree un gráfico atractivo, tiene que escribir muchos parámetros de bajo nivel, y eso hace que sea difícil generarlo de forma estable
    Flint es una abstracción de más alto nivel, por lo que la especificación es mucho más corta y simple, y el compilador deriva las decisiones de bajo nivel para crear gráficos atractivos. Es decir, permite que un agente cree con un programa corto buenos gráficos que antes requerían un programa largo
  • Yo también tenía curiosidad por cómo se compara con Vega-Lite. Vega-Lite también es relativamente de alto nivel y declarativo, y su sintaxis parece similar a la de Flint

• No me convence mucho la afirmación de que “las especificaciones simples de gráficos pueden ser estables, pero dependen de los valores predeterminados del sistema y la calidad de los gráficos generados es baja; mientras que las especificaciones complejas pueden crear gráficos atractivos, pero son verbosas y difíciles de manejar de forma estable para un agente”
  En mi limitada experiencia creando agentes de análisis, me impresionó lo bien que los LLM generan visualizaciones con Python y R. Incluso modelos pequeños de pesos abiertos lo hacían igual, y muchas veces las desventajas desaparecían al iterar un poco sobre las partes ambiguas. Me pregunto si existe alguna línea de investigación que respalde esta afirmación o muestre en qué puntos surgen los problemas

  • Una especificación más simple puede ser usada por un agente más simple. Tal vez el uso aquí sea que agentes pequeños y baratos trabajen en paralelo, en lugar de que un solo modelo grande haga las visualizaciones una por una
    Personalmente, Claude y ChatGPT generan bien el modelo de ggplot, pero cuando hay mucha personalización se vuelve un poco más complicado
  • Además de la expresividad, también se están considerando la estabilidad y la interactividad. Cuando el público objetivo son usuarios no expertos o se usan modelos pequeños, ayuda tener una especificación simple pero expresiva

• La descripción de “parámetros de bajo nivel verbosos como escala, ejes, intervalos y layout” parece indicar que Microsoft está mezclando dos cosas distintas.
  A los LLM no les importa demasiado si el código en sí es de bajo nivel y verboso; también pueden leer bien ensamblador o SPIR-V. El verdadero problema es la composición visual. Como los LLM “ven” de manera diferente a las personas, entender la composición espacial mediante comparación visual no les resulta natural; para sortearlo, hay que darles una representación que puedan razonar y entender con facilidad, como una visualización en forma de código. Es decir, basta con que no sea una estructura profundamente anidada ni una que requiera inferir estados ocultos.
  Además, me cuesta estar de acuerdo con la decisión de Flint de manejar los tipos en JSON centrado en claves de texto. Viendo la especificación real, también podrían haberlo hecho como una biblioteca TypeScript fácil de escribir para humanos, y creo que eso habría sido mucho mejor. Más tarde, al ver el código fuente real, resultó estar mucho más completo y refinado que el mockup que había imaginado solo con la documentación, pero mi queja central sobre “JSON con claves de texto frente a una superficie de autoría con genéricos reales” sigue en pie.

  • La parte de chartType me parece poco elegante porque las plantillas deberían ser más extensibles. Esa parte necesita ajustes.
    En lo demás, usar JSON en bibliotecas de visualización o diagramación es bastante común, porque permite trasladarlo fácilmente entre distintos contextos de renderizado.
  • Coincido en que JSON no es el lenguaje de especificación óptimo, pero vale la pena pensar si es mejor que cada proyecto empiece a escribir su propia especificación desde cero.
    Artículo relacionado: https://www.openui.com/blog/stop-making-ai-write-json
  • Lamentablemente, parece que estamos atados a JSON como la forma más estable de meter y sacar datos o código de un LLM. Podría haber sido YAML, que es peor.
    Me interesan los DSL personalizados que aumenten la predictibilidad de los LLM, y me alegra ver que hasta un gigante como Microsoft parece entenderlo. El ejemplo de Contacts en https://slangify.org/examples muestra una forma de crear fácilmente un DSL propio convirtiendo de ida y vuelta entre VCARD y JCARD.

• Al leer la explicación de que “obliga a explicitar decisiones visuales que debería manejar un buen compilador”, pienso que Graphviz existe por una razón similar.
  Viendo que usan JSON como lenguaje declarativo, aunque reconozco que los LLM manejan bien JSON, no es una sintaxis agradable para que la consuman las personas.

  • De hecho, JSON existe desde hace bastante tiempo como lenguaje común escrito por humanos para visualizaciones. La ventaja de una sintaxis declarativa es que el usuario puede manipular la especificación de manera eficaz desde la UI, arrastrando y soltando o haciendo clic.
    Flint fue diseñado deliberadamente para que los agentes omitan parámetros de bajo nivel como escala, ejes, base en 0 y tamaño de paso. Estos elementos son muy importantes para un gráfico agradable, y el compilador los optimiza dinámicamente. Por eso es más fácil de manejar para los agentes de IA.
  • Sí. Sinceramente, esto se siente bloqueado apenas sale, y no parece particularmente mejor que lo que ya existía.

• Usar tipos semánticos como elemento adicional de formato es muy útil, porque codifica de forma concisa mucho boilerplate de formato.
  Me pregunto si hay planes para compartir o hacer extensible el registro de tipos de Flint. También me pregunto por qué no ponerlo directamente como atributo de los datos. Al crear gráficos conectados de más alto nivel sobre Vega-Lite, llegué a una especificación casi idéntica.

• No termino de entender el punto de este proyecto. Desde la época de GPT-3.5, creo que los LLM ya podían generar matplotlib de una sola vez.
  He usado bastante LLM para visualización de datos y no tuve grandes problemas. Me gustaría ver ejemplos concretos de en qué parte de la generación de visualizaciones tienen dificultades los agentes y cómo Flint lo resuelve.

  • Aquí hay un poco del problema del último 20%. Si estás hablando con GPT en una ventana de chat y lo vas guiando continuamente, en general está bien para usuarios avanzados.
    Pero cuando lo incorporas en una herramienta para usuarios finales, una tasa de éxito del 80% al generar gráficos agradables empieza a ser un gran problema. Me pasó al construir un sistema de análisis de datos. Si haces que genere directamente matplotlib o Vega-Lite, es difícil lograr al mismo tiempo estabilidad, expresividad, costo, tiempo y tokens; por eso diseñamos este lenguaje como un punto intermedio: trasladar algunas decisiones al compilador para reducir el costo de generación y mantener la expresividad.

• Página del proyecto: https://microsoft.github.io/flint-chart/
  Configuración de MCP: https://microsoft.github.io/flint-chart/#/mcp