Microsoft stellt Flint vor, eine Visualisierungssprache für AI-Agenten

• Flint ist eine intermediäre Visualisierungssprache, die AI-Agenten dabei unterstützt, aus kurzen, von Menschen bearbeitbaren Spezifikationen ausdrucksstarke Diagramme zu erstellen
• Der Compiler interpretiert Daten, semantische Typen, Diagrammtyp und Encodings und ergänzt automatisch Low-Level-Einstellungen wie Skalen, Achsen, Abstände und Layout
• Es werden 46 Diagrammtypen und 83 Galeriebeispiele bereitgestellt; unterstützt werden Renderings mit Vega-Lite, ECharts und Chart.js
• In TypeScript-/JavaScript-Umgebungen kann es per npm installiert werden, und in Agent-Workflows kann ein MCP-Server verwendet werden
• Unterschiede zwischen Backend-APIs werden hinter einer einheitlichen Schnittstelle verborgen, sodass sich Renderer-Wechsel oder Änderungen am Diagrammdesign aus derselben Spezifikation leichter umsetzen lassen

---

Das Problem, das Flint lösen will

• Flint ist ein Projekt von Microsoft Research und eine intermediäre Visualisierungssprache, die dafür entwickelt wurde, dass AI-Agenten Diagramme aus einfachen, von Menschen bearbeitbaren Diagrammspezifikationen erzeugen
• Die Spezifikation besteht aus Daten, semantischen Typen und einer Diagrammspezifikation
  • In der Beispielspezifikation wird period als YearMonth, totalUsers als Quantity sowie gameType und region als Category festgelegt
  • In einem Line Chart werden region an column, period an x, totalUsers an y und gameType an color gebunden, wodurch ein Liniendiagramm zu monatlich aktiven Nutzern nach Region entsteht
• Es kann per npm in TypeScript-/JavaScript-Umgebungen installiert werden
• In Agent-Workflows kann ein MCP-Server verwendet werden
• In der Gallery sind 46 Diagrammtypen und 83 Beispiele zu sehen

Wie Spezifikationen in Diagramme umgewandelt werden

• Flint beginnt mit einer kompakten Spezifikation, erzeugt daraus eine backend-native Spezifikation wie für Vega-Lite und rendert das Diagramm, indem es die nötigen Low-Level-Details ergänzt
• Semantische Typen drücken die Bedeutung von Datenfeldern aus
  • Beispiele umfassen Typen wie Rank, YearMonth, Delta und Temperature
  • Auf dieser Basis leitet Flint Diagrammeinstellungen wie Parsing, Skalen, Achsen, Formatierung und Farbschemata ab
  • In einer Heatmap, die netto neue Nutzer nach Spiel und Monat zeigt, werden Parser für Zeitwerte, Achsenformatierung sowie divergierendes Farbschema und Mittelpunkt auf Basis der semantischen Typen bestimmt
• Automatische Layout-Optimierung basiert auf einem elastischen Layout-Modell und dem Banking-Prinzip
  • Der Compiler verwaltet Größe, Abstände und Anordnung dynamisch, damit das Diagramm auf die Zeichenfläche passt
  • Wenn die Zahl gruppierter Balkendiagramme steigt, vergrößert er die Zeichenfläche und verringert die Bandbreite, sodass auch dichtere Versionen auf die Zeichenfläche passen
• Änderungen am Diagrammdesign lassen sich durch den Wechsel des Diagrammtyps und das erneute Binden visueller Encodings umsetzen
  • Wenn ein facettiertes Balkendiagramm zur Verteilung der Bevölkerung nach Geschlecht und Alter aus dem US-Zensus 2000 in ein Pyramidendiagramm umgewandelt wird, muss der Nutzer nur den Diagrammtyp ändern; den Rest übernimmt der Compiler

Rendering-Backends und Verfügbarkeit

• Flint unterstützt 46 Diagrammtypen über Vega-Lite, ECharts und Chart.js hinweg
  • Unterschiedliche APIs und Programmiermodelle werden hinter einer einheitlichen Schnittstelle verborgen
  • Wenn Vega-Lite kein natives Sunburst unterstützt, kann zu ECharts gewechselt werden
  • Für die Visualisierung einer Hierarchie aus Region × gameType × Spiel wird ein Sunburst Chart als bessere Alternative zu einem gruppierten Balkendiagramm vorgeschlagen
• Flint ist Open Source und kann sofort verwendet werden
• Als Einstieg stehen GitHub und Galeriebeispiele zur Verfügung
• Microsoft Research hat Flint in Zusammenarbeit mit IDEAS Lab und der Renmin University of China entwickelt

[GN⁺]

Meinungen auf Hacker News

• Ich verstehe, warum das Marketing „für AI-Agenten“ nötig ist, aber allein die Tatsache, dass es eine Sprache ist, mit der sich Charts leicht ausdrücken lassen, ist schon beeindruckend und nützlich genug

  • Das kann man gar nicht genug betonen. „Gut für Agenten“ bedeutet letztlich, dass etwas selbsterklärend ist, eine klare Bedienbarkeit hat, sichere Defaults sowie knappe oder kontrollierbare Ausgaben und ein programmierbares Interface bietet — und diese Eigenschaften helfen auch Menschen
  • Ich vermute, dass das buchstäblich dafür gebaut wurde, dass AI-Agenten über einen MCP-Server darauf zugreifen. Wenn ja, scheint die Betonung von AI-Agenten im Marketing ziemlich wichtig zu sein
  • So zusammengefasst wirkt es richtig. Die blumige Erklärung scheint letztlich nur eine lange Umschreibung für „es schaut sich die Daten an und entscheidet selbst, wie der Chart aussehen soll“ zu sein
    Auch auf der Seite heißt es: „Statt ausführliche Low-Level-Parameter wie Skalen, Achsen, Abstände und Layout zu verlangen, leitet der Flint-Compiler optimierte Chart-Einstellungen aus Daten, semantischen Typen, Chart-Typen und Encodings ab“
  • Es ist für Agenten leicht zu generieren, aber auch für Menschen — besonders mit UI — in einer Form, die leicht zu bearbeiten ist
  • Wenn man sich das Paket ansieht, ist es auf bestehenden Chart-Bibliotheken aufgebaut

• In Agentensystemen entsteht ein neues Muster, und dieses Projekt ist ein gutes Beispiel dafür
  Es geht um eine Intermediate Representation (IR), die ein LLM erzeugt und weitergibt, worauf dann eine deterministische Schicht wie ein Compiler oder Codegenerator sitzt. Ich denke, wir werden solche Strukturen in naher Zukunft häufiger sehen

  • Als ich zum ersten Mal sah, dass Claude kein PPT-Deck direkt als XML erstellt, sondern Python-Code schreibt, um es zu erzeugen, war das ein ziemlicher Aha-Moment. Viele Aufgaben werden wohl diesen Weg gehen, und langfristig wirkt es etwas eingeschränkt und hacky, aber für den Moment scheint es zu 100 % der richtige Ansatz zu sein
  • Ich stimme dieser Idee vollkommen zu. Im vergangenen Monat liefen alle Agent-Coding-Aufgaben, an denen ich gearbeitet habe, über Intermediate Representations, und die Iteration fand hauptsächlich auf dieser Ebene statt. Es ist erstaunlich, wie nahe man damit an deterministische Code-Ausgaben herankommt
  • Eine gut entworfene Zwischenschicht ermöglicht Validierung und Kontrolle unabhängig von der AI. Dadurch verändert sich die Interaktion zwischen Mensch und AI von Delegation zu Zusammenarbeit
  • Genau. Agentensysteme folgten von Anfang an diesem Muster: locker generieren und dann so lange erneut versuchen, bis die Eingabe validiert wird und Form und Größe in das Loch passen
  • Programmierung ist lebendiger denn je

• Es steht nicht auf der Seite, aber beim Erstellen von Datenvisualisierungen ist es wirklich wichtig, Barrierefreiheit schon in der Designphase zu berücksichtigen
  In diesem Podcast gibt es dazu ein gut zusammengefasstes kurzes Interview: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
  Interviewt wird Frank Elavsky, der in diesem Bereich ziemlich bekannt zu sein scheint, und er hat auch das Chartability-Projekt mit Heuristiken, Prinzipien und Richtlinien für Accessibility-Audits erstellt: https://chartability.github.io/POUR-CAF/

  • Auch Flint wird vermutlich Arbeit an Accessibility-Unterstützung brauchen, und das ist ein guter zentraler Ansatzpunkt, um Accessibility-Probleme zu behandeln
    Ich habe ein Issue zum Tracking hinzugefügt: https://github.com/microsoft/flint-chart/issues/48

• Ich frage mich, ob es eine konkrete Erklärung gibt, wie das besser oder anders ist als Vega selbst: https://vega.github.io/vega/docs/specification/
  Vega ist bereits eine ausdrucksstarke DSL für Visualisierungen und dürfte auch in LLM-Trainingsdaten recht breit enthalten sein

  • Früher war Vega für Menschen eine High-Level-Sprache, aber heute kann es für AI-Agenten eher etwas low-level sein. Damit ein Agent gut aussehende Charts erstellt, muss er viele Low-Level-Parameter verwenden, wodurch das Ergebnis schwer stabil zu schreiben ist
    Flint ist eine höhere Abstraktionsebene, sodass die Spezifikation viel kürzer und einfacher ist, während der Compiler die Low-Level-Entscheidungen ableitet, um gut aussehende Charts zu erzeugen. Anders gesagt: Gute Charts, für die früher lange Programme nötig waren, können Agenten damit mit kurzen Programmen erstellen
  • Ich habe mich auch gefragt, wie es im Vergleich zu Vega-Lite aussieht. Vega-Lite ist ebenfalls relativ high-level und deklarativ, und die Syntax scheint Flint ähnlich zu sein

• Die Aussage, dass „einfache Chart-Spezifikationen zwar stabil sein können, aber wegen ihrer Abhängigkeit von System-Defaults eine niedrige Qualität der erzeugten Charts haben, während komplexe Spezifikationen gut aussehende Charts erzeugen können, aber so ausführlich sind, dass Agenten sie schwer stabil handhaben können“, überzeugt mich nicht besonders
  Aus meiner begrenzten Arbeitserfahrung mit Analyse-Agenten fand ich beeindruckend, dass LLMs mit Python und R ziemlich gute Visualisierungen erstellen. Das galt auch für kleine Open-Weight-Modelle, und oft verschwanden die Nachteile, wenn man Unklarheiten durch ein paar Iterationen verfeinerte. Ich frage mich, ob es eine Forschungslinie gibt, die diese Behauptung stützt oder zeigt, wo Probleme entstehen

  • Einfachere Spezifikationen können von einfacheren Agenten verwendet werden. Vielleicht ist der Anwendungsfall hier eher, dass kleine, günstige Agenten parallel genutzt werden, statt dass ein einziges großes Modell Visualisierungen nacheinander erstellt
    Persönlich erstellen Claude und ChatGPT das ggplot-Modell gut, aber wenn viel Customizing hinzukommt, wird es etwas kompliziert
  • Neben Ausdrucksstärke werden auch Zuverlässigkeit und Interaktivität berücksichtigt. Wenn man sich an Nicht-Experten richtet oder kleine Modelle einsetzt, hilft eine Spezifikation, die ausdrucksstark und zugleich einfach ist

• Die Beschreibung mit „weitschweifigen Low-Level-Parametern wie Skalierung, Achsen, Abständen und Layout“ wirkt so, als würde Microsoft zwei verschiedene Dinge vermischen.
  Ein LLM kümmert es nicht besonders, ob Code Low-Level und ausführlich ist; es kann auch Assembly oder SPIR-V gut lesen. Das eigentliche Problem ist die visuelle Komposition. Da LLMs anders „sehen“ als Menschen, ist ein Verständnis räumlicher Anordnung durch visuellen Vergleich für sie nicht natürlich. Um das zu umgehen, muss man ihnen eine Darstellung liefern, die sie leicht schlussfolgern und verstehen können, etwa Visualisierungen in Codeform. Mit anderen Worten: Solange die Struktur nicht tief verschachtelt ist oder versteckte Zustände erschlossen werden müssen, ist es in Ordnung.
  Außerdem fällt es mir schwer, Flints Entscheidung zuzustimmen, Typen in JSON über String-Keys zu behandeln. Wenn man sich die tatsächliche Spezifikation ansieht, hätte man daraus auch einfach eine menschenfreundliche TypeScript-Bibliothek machen können, und das wäre vermutlich viel besser gewesen. Als ich mir später den Source tatsächlich ansah, war er deutlich ausgereifter und raffinierter als das Mock-up, das ich nur anhand der Dokumentation angenommen hatte; der zentrale Einwand „String-Key-JSON versus echte generische Autorenoberfläche“ bleibt aber bestehen.

  • Den chartType-Teil finde ich nicht besonders elegant, weil die Templates erweiterbarer sein müssten. Dieser Teil sollte überarbeitet werden.
    In anderen Bereichen ist die Verwendung von JSON in Visualisierungs- oder Diagrammbibliotheken ziemlich üblich, weil es sich leicht in unterschiedliche Rendering-Kontexte übertragen lässt.
  • Ich stimme zu, dass JSON nicht die optimale Spezifikationssprache ist, aber man sollte überlegen, ob es wirklich schlechter ist, als wenn jedes Projekt anfängt, seine eigene Spezifikation neu zu schreiben.
    Verwandter Artikel: https://www.openui.com/blog/stop-making-ai-write-json
  • Leider scheint man für die stabilste Methode, Daten oder Code in LLMs hinein- und herauszubekommen, an JSON gebunden zu sein. Es hätte auch das noch schlimmere YAML sein können.
    Ich interessiere mich für Custom-DSLs, die die Vorhersagbarkeit von LLMs erhöhen, und es ist erfreulich, dass offenbar auch ein Gigant wie Microsoft das verstanden hat. Das Contacts-Beispiel unter https://slangify.org/examples zeigt eine Methode, mit der man durch Hin- und Rückkonvertierung zwischen VCARD und JCARD leicht eine eigene DSL erstellt.

• Wenn ich die Beschreibung lese, dass es „visuelle Entscheidungen explizit macht, die ein guter Compiler übernehmen sollte“, frage ich mich, ob Graphviz nicht genau aus demselben Grund existiert.
  Dass JSON als deklarative Sprache verwendet wird: Ich erkenne an, dass LLMs gut mit JSON umgehen können, aber eine Syntax, die für Menschen angenehm zu konsumieren ist, ist es nicht.

  • Tatsächlich gibt es JSON als gemeinsame, von Menschen verwendete Sprache für Visualisierung schon seit ziemlich langer Zeit. Der Vorteil deklarativer Syntax ist, dass Nutzer die Spezifikation in einer UI durch Drag-and-drop oder Klicken effektiv manipulieren können.
    Flint ist bewusst so entworfen, dass Agenten Low-Level-Parameter wie Skalierung, Achsen, Nullbasis und Schrittgröße überspringen können. Solche Elemente sind für gut aussehende Charts sehr wichtig und werden vom Compiler dynamisch optimiert. Dadurch lässt es sich für AI-Agenten leichter handhaben.
  • Stimmt. Ehrlich gesagt fühlt sich das direkt zum Start schon ausgebremst an und ist nicht wirklich besser als das, was es bereits gab.

• Semantische Typen als zusätzliches Formatierungselement zu verwenden, ist sehr nützlich, weil sie viel Formatierungs-Boilerplate kompakt codieren.
  Ich frage mich, ob es Pläne gibt, das Flint-Typregister gemeinsam nutzbar oder erweiterbar zu machen. Außerdem frage ich mich, warum man es nicht direkt als Dateneigenschaft selbst anlegt. Beim Erstellen von höherstufigen, verknüpften Charts auf Basis von Vega-Lite bin ich bei nahezu derselben Spezifikation gelandet.

• Ich verstehe den Sinn dieses Projekts nicht so recht. Seit GPT-3.5-Zeiten konnten LLMs meiner Erinnerung nach matplotlib in einem Durchgang erzeugen.
  Ich habe LLMs viel für Datenvisualisierung verwendet und bin dabei kaum auf Probleme gestoßen. Mich würden Beispiele interessieren, wo Agenten bei der Erstellung von Visualisierungen konkret Schwierigkeiten haben und wie Flint das löst.

  • Hier gibt es ein bisschen das Problem der letzten 20 %. Wenn man im Chatfenster mit GPT spricht und es immer weiter in die richtige Richtung lenkt, ist das für Power-User meist in Ordnung.
    Baut man es aber in ein Tool für Endnutzer ein, wird eine Erfolgsquote von 80 % bei der Erstellung gut aussehender Charts zu einem großen Problem. Das habe ich beim Bau eines Datenanalyse-Systems erlebt. Wenn man matplotlib oder Vega-Lite direkt generieren lässt, ist es schwierig, gleichzeitig Stabilität, Ausdrucksstärke sowie Kosten in Zeit und Tokens zu erreichen. Deshalb wurde diese Sprache als Kompromiss entworfen, der einige Entscheidungen in den Compiler verlagert, um die Generierungskosten zu senken und gleichzeitig die Ausdrucksstärke zu erhalten.

• Projektseite: https://microsoft.github.io/flint-chart/
  MCP-Konfiguration: https://microsoft.github.io/flint-chart/#/mcp