Microsoft dévoile Flint, un langage de visualisation pour les agents IA

• Flint est un langage intermédiaire de visualisation qui aide les agents IA à créer des graphiques expressifs à partir de courtes spécifications modifiables par des humains
• Le compilateur interprète les données, les types sémantiques, le type de graphique et les encodages, puis complète automatiquement les réglages de bas niveau comme les échelles, les axes, l’espacement et la mise en page
• Il propose 46 types de graphiques et 83 exemples de galerie, avec prise en charge du rendu via Vega-Lite, ECharts et Chart.js
• Dans les environnements TypeScript / JavaScript, il peut être installé via npm, et dans les workflows d’agents, un serveur MCP peut être utilisé
• Il masque les différences d’API entre backends derrière une interface unifiée, ce qui facilite le changement de moteur de rendu ou la modification de la conception du graphique à partir d’une même spécification

---

Le problème que Flint cherche à résoudre

• Flint est un projet de Microsoft Research, conçu comme un langage intermédiaire de visualisation permettant aux agents IA de générer des graphiques à partir de spécifications simples et éditables par des humains
• La spécification se compose des données, des types sémantiques et de la spécification du graphique
  • Dans l’exemple, period est défini comme YearMonth, totalUsers comme Quantity, et gameType ainsi que region comme Category
  • Dans un Line Chart, region est associé à column, period à x, totalUsers à y et gameType à color, afin de créer un graphique en courbes des utilisateurs actifs mensuels par région
• Il peut être installé via npm dans les environnements TypeScript / JavaScript
• Dans les workflows d’agents, il est possible d’utiliser un serveur MCP
• La gallery permet de consulter 46 types de graphiques et 83 exemples

Comment les spécifications sont transformées en graphiques

• Flint part d’une spécification condensée, génère une spécification native pour un backend comme Vega-Lite, puis complète les détails de bas niveau nécessaires pour rendre le graphique
• Les types sémantiques expriment la signification des champs de données
  • Les exemples incluent des types comme Rank, YearMonth, Delta et Temperature
  • Flint s’en sert pour déduire des réglages du graphique comme l’analyse, les échelles, les axes, le formatage et les palettes de couleurs
  • Dans une heatmap montrant les nouveaux utilisateurs nets par jeu et par mois, l’analyseur des valeurs temporelles, le formatage des axes, ainsi que la palette de couleurs divergente et son point médian sont déterminés à partir des types sémantiques
• L’optimisation automatique de la mise en page repose sur un modèle de mise en page flexible et sur le principe de banking
  • Le compilateur gère dynamiquement la taille, l’espacement et l’agencement pour adapter le graphique au canevas
  • Lorsque le nombre de grouped bar charts augmente, il agrandit le canevas et réduit la band width afin que même une version plus dense tienne dans l’espace disponible
• Les changements de conception du graphique peuvent être gérés par un changement de type de graphique et une réaffectation des encodages visuels
  • Pour transformer un faceted bar chart montrant la répartition de la population américaine de 2000 par sexe et âge en pyramid chart, l’utilisateur n’a qu’à changer le type de graphique, le compilateur se chargeant du reste

Backends de rendu et disponibilité

• Flint prend en charge 46 types de graphiques sur Vega-Lite, ECharts et Chart.js
  • Il masque les différences d’API et de modèles de programmation derrière une interface unifiée
  • Lorsqu’il n’existe pas de sunburst natif dans Vega-Lite, il est possible de basculer vers ECharts
  • Pour visualiser une hiérarchie région × gameType × jeu, un sunburst chart est proposé comme meilleure alternative qu’un grouped bar chart
• Flint est open source et peut être utilisé immédiatement
• GitHub et les exemples de la galerie sont proposés comme point de départ
• Microsoft Research a développé Flint en collaboration avec IDEAS Lab et la Renmin University of China

[GN⁺]

Avis sur Hacker News

• Je comprends pourquoi le marketing insiste sur « pour les agents IA », mais au final, le simple fait que ce soit un langage qui facilite l’expression de graphiques est déjà suffisamment impressionnant et utile

  • On ne le soulignera jamais assez. Dire que c’est « bon pour les agents », cela veut surtout dire que c’est auto-explicatif, que sa manipulation est claire, qu’il offre des valeurs par défaut sûres, une sortie concise ou contrôlable, et une interface programmable — et ces caractéristiques aident aussi les humains
  • Je me demande si ce n’est pas littéralement conçu pour que des agents IA y accèdent via un serveur MCP. Si c’est le cas, mettre l’accent sur les agents IA dans le marketing semble assez important
  • Ça me paraît être le bon résumé. Les explications sophistiquées reviennent surtout à dire en long : « il regarde les données et décide de lui-même à quoi le graphique doit ressembler »
    La page explique aussi que « plutôt que d’exiger des paramètres bas niveau verbeux comme l’échelle, les axes, l’espacement ou la mise en page, le compilateur Flint déduit une configuration de graphique optimisée à partir des données, des types sémantiques, du type de graphique et de l’encodage »
  • C’est facile à générer pour un agent, mais aussi facile à éditer pour un humain, surtout s’il y a une UI
  • En regardant le package, cela semble construit au-dessus de bibliothèques de graphiques existantes

• Un nouveau motif apparaît dans les systèmes d’agents, et ce projet en est un bon exemple
  L’idée est d’avoir une représentation intermédiaire (IR) que le LLM génère puis transmet, avec au-dessus une couche déterministe comme un compilateur ou un générateur de code. On verra probablement cette architecture bien plus souvent dans un futur proche

  • La première fois que j’ai vu Claude générer un deck PPT non pas directement en XML mais en écrivant du code Python pour le produire, ça a été un vrai moment « ah ah ». Beaucoup de tâches semblent prendre cette direction ; à long terme cela peut paraître un peu limité et bricolé, mais pour l’instant cela semble être l’approche 100 % juste
  • Je suis entièrement d’accord avec cette idée. Depuis un mois, tout mon travail de coding agent est passé par une représentation intermédiaire, et les itérations se faisaient surtout à ce niveau. Il est surprenant de voir à quel point on peut ainsi se rapprocher d’une sortie de code déterministe
  • Une couche intermédiaire bien conçue permet validation et contrôle indépendamment de l’IA. Cela fait passer l’interaction humain-IA de la délégation à la collaboration
  • Oui. Les systèmes d’agents fonctionnent ainsi depuis le début : on génère de manière souple, puis on réessaie encore et encore jusqu’à obtenir la forme et la taille qui rentrent dans le trou, tant que l’entrée n’est pas validée
  • La programmation n’a jamais été aussi vivante

• Ce n’est pas sur la page, mais quand on crée de la visualisation de données, il est vraiment important d’intégrer l’accessibilité dès la phase de conception
  Ce podcast contient une courte interview pertinente qui résume bien le sujet : https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
  La personne interviewée est Frank Elavsky, qui semble assez connu dans ce domaine, et qui a aussi créé le projet Chartability, avec des heuristiques, principes et recommandations pour les audits d’accessibilité : https://chartability.github.io/POUR-CAF/

  • Flint semble aussi avoir besoin d’un travail de prise en charge de l’accessibilité, et c’est un bon point central pour traiter ces questions
    J’ai ajouté un ticket de suivi : https://github.com/microsoft/flint-chart/issues/48

• Je me demande s’il existe une explication concrète de ce que cela fait de mieux ou de différent par rapport à Vega lui-même : https://vega.github.io/vega/docs/specification/
  Vega est déjà un DSL expressif pour la visualisation, et il semble probable qu’il soit assez largement présent dans les données d’entraînement des LLM

  • Autrefois, Vega était un langage de haut niveau pour les humains, mais aujourd’hui il est peut-être au contraire un peu bas niveau pour les agents IA. Pour produire de beaux graphiques, l’agent doit renseigner beaucoup de paramètres bas niveau, ce qui rend l’écriture difficile de manière fiable
    Flint est une abstraction de plus haut niveau : les spécifications sont bien plus courtes et simples, et le compilateur déduit les décisions bas niveau pour produire de beaux graphiques. En d’autres termes, cela permet à un agent de créer avec un programme court un bon graphique qui demandait auparavant un long programme
  • Je me demandais aussi comment cela se compare à Vega-Lite. Vega-Lite est lui aussi relativement haut niveau et déclaratif, et sa syntaxe ressemble à celle de Flint

• Je ne suis pas vraiment convaincu par l’affirmation selon laquelle « les spécifications de graphiques simples peuvent être stables mais produisent des graphiques de faible qualité parce qu’elles dépendent des valeurs par défaut du système, tandis que les spécifications complexes peuvent produire de beaux graphiques mais sont trop verbeuses pour qu’un agent les manipule de manière fiable »
  D’après ma petite expérience de création d’agents d’analyse, j’ai trouvé impressionnant à quel point les LLM produisent bien des visualisations en Python et en R. Même de petits modèles open weights s’en sortaient aussi, et avec un peu d’itération sur les parties ambiguës, les défauts disparaissaient souvent. Je me demande s’il existe un courant de recherche qui étaye cette affirmation ou montre précisément où surgissent les problèmes

  • Des spécifications plus simples peuvent être utilisées par des agents plus simples. J’imagine que l’usage visé ici n’est pas qu’un seul grand modèle crée les visualisations une par une, mais plutôt que de petits agents peu coûteux soient utilisés en parallèle
    Personnellement, Claude et ChatGPT génèrent bien des modèles ggplot, mais quand le niveau de personnalisation augmente, cela devient un peu complexe
  • Ils prennent en compte non seulement l’expressivité, mais aussi la fiabilité et l’interactivité. Quand on s’adresse à des utilisateurs non experts ou qu’on utilise de petits modèles, des spécifications simples mais expressives peuvent aider

• La description parlant de « paramètres de bas niveau verbeux comme l’échelle, les axes, l’espacement ou la mise en page » donne l’impression que Microsoft mélange deux choses différentes
  En soi, un LLM ne se soucie pas vraiment du fait que le code soit de bas niveau ou verbeux, et il peut aussi bien lire de l’assembleur ou du SPIR-V. Le vrai problème, c’est la composition visuelle. Un LLM ne « voit » pas comme un humain, donc comprendre une organisation spatiale par comparaison visuelle ne lui est pas naturel. Pour contourner cela, il faut fournir une représentation que le LLM peut raisonner et comprendre facilement, comme une visualisation sous forme de code. Autrement dit, il suffit d’éviter des structures profondément imbriquées ou qui obligent à inférer des états cachés
  J’ai aussi du mal avec la décision de Flint de gérer les types dans du JSON centré sur des clés de chaîne de caractères. En regardant la spécification réelle, ça aurait tout aussi bien pu être conçu comme une bibliothèque TypeScript agréable à écrire pour les humains, et cela aurait probablement été bien meilleur. En voyant ensuite le code source, j’ai constaté que c’était bien plus abouti et sophistiqué que la maquette que j’avais imaginée à partir de la seule documentation, mais la critique de fond — « JSON à clés de chaîne contre une vraie surface d’écriture générique » — reste entière

  • Pour la partie chartType, je pense qu’il faudrait un modèle plus extensible, donc ce n’est pas très élégant. Cette partie a besoin d’être corrigée
    Pour le reste, utiliser du JSON dans les bibliothèques de visualisation ou de diagrammes est assez courant. Cela permet de passer facilement d’un contexte de rendu à un autre
  • Je suis d’accord sur le fait que le JSON n’est pas le langage de spécification idéal, mais il reste à voir si ce n’est pas malgré tout préférable au fait que chaque projet se mette à réécrire sa propre spécification
    Article lié : https://www.openui.com/blog/stop-making-ai-write-json
  • Malheureusement, on semble rester coincés avec le JSON comme méthode la plus fiable pour faire entrer et sortir des données ou du code d’un LLM. Ça aurait pu être pire : du YAML
    Je m’intéresse aux DSL sur mesure qui améliorent la prévisibilité des LLM, et je suis ravi de voir qu’un dinosaure comme Microsoft semble l’avoir compris aussi. L’exemple Contacts sur https://slangify.org/examples montre une manière de créer facilement son propre DSL tout en convertissant dans les deux sens entre VCARD et JCARD

• Quand je lis que « cela force à expliciter des décisions visuelles qu’un bon compilateur devrait gérer », je me demande si Graphviz n’existe pas justement pour cette raison
  Le fait d’utiliser du JSON comme langage déclaratif montre bien que, même si les LLM manipulent bien le JSON, ce n’est pas une syntaxe agréable à consommer pour des humains

  • En réalité, le JSON existe depuis longtemps comme langage commun écrit par des humains pour les visualisations. L’avantage d’une syntaxe déclarative, c’est que les utilisateurs peuvent manipuler efficacement la spécification dans une UI via du glisser-déposer ou des clics
    Flint a été conçu intentionnellement pour permettre aux agents d’ignorer des paramètres de bas niveau comme l’échelle, les axes, l’origine à 0 ou la taille des pas. Ces éléments sont très importants pour produire un beau graphique, et le compilateur les optimise dynamiquement. Cela le rend donc plus facile à utiliser pour des agents IA
  • Oui. Honnêtement, ça donne l’impression d’être bloqué dès le lancement, sans être particulièrement meilleur que ce qui existait déjà

• Utiliser des types sémantiques comme élément de format supplémentaire est très utile. Cela permet d’encoder de façon concise beaucoup de boilerplate lié au format
  Je me demande s’il est prévu de partager ou d’étendre le registre de types de Flint. Je me demande aussi pourquoi cela n’est pas directement porté par les attributs de données eux-mêmes. J’étais arrivé à une spécification presque identique en construisant des graphiques connectés de plus haut niveau au-dessus de Vega-Lite

• Je ne comprends pas très bien l’intérêt principal de ce projet. Depuis l’époque de GPT-3.5, les LLM semblaient déjà capables de produire du matplotlib d’un seul coup
  J’ai beaucoup utilisé des LLM pour la visualisation de données sans rencontrer de problème particulier. J’aimerais voir des exemples concrets des points précis où les agents peinent à générer des visualisations, et de la façon dont Flint résout cela

  • Il y a ici un petit problème des derniers 20 %. Si vous discutez avec GPT dans une fenêtre de chat et continuez à le recadrer, c’est généralement acceptable pour un power user
    Mais quand on l’intègre dans un outil destiné aux utilisateurs finaux, un taux de réussite de 80 % pour générer de beaux graphiques commence à devenir un gros problème. J’ai rencontré cela en construisant un système d’analyse de données. Si on lui fait générer directement du matplotlib ou du Vega-Lite, il est difficile d’obtenir en même temps stabilité, expressivité, coût en temps et coût en tokens. Ce langage a donc été conçu comme un compromis : transférer certaines décisions vers le compilateur afin de réduire le coût de génération tout en conservant l’expressivité

• Page du projet : https://microsoft.github.io/flint-chart/
  Configuration MCP : https://microsoft.github.io/flint-chart/#/mcp