Microsoft, yapay zeka ajanları için görselleştirme dili Flint’i duyurdu

• Flint, yapay zeka ajanlarının insanların düzenleyebileceği kısa tanımlarla ifade gücü yüksek grafikler oluşturmasına yardımcı olan bir görselleştirme ara dilidir
• Derleyici; veri ve anlamsal tipleri, grafik türünü ve kodlamaları yorumlayarak ölçek, eksen, aralık ve yerleşim gibi düşük seviyeli ayarları otomatik olarak doldurur
• 46 grafik türü ve 83 galeri örneği sunar; Vega-Lite, ECharts ve Chart.js ile render etmeyi destekler
• TypeScript / JavaScript ortamlarında npm ile kurulabilir; ajan iş akışlarında MCP sunucusu kullanılabilir
• Backend’lere özgü API farklılıklarını birleşik bir arayüzün arkasında gizleyerek, aynı tanımdan renderer değiştirmeyi veya grafik tasarımı değişikliklerini daha kolay yönetir

---

Flint’in çözmeyi hedeflediği sorun

• Flint, Microsoft Research projesidir; yapay zeka ajanlarının basit ve insanlar tarafından düzenlenebilir grafik tanımlarından grafikler üretmesi için tasarlanmış bir görselleştirme ara dilidir
• Tanım; veri, anlamsal tipler ve grafik tanımından oluşur
  • Örnek tanımda period için YearMonth, totalUsers için Quantity, gameType ve region için Category belirtilir
  • Line Chart içinde region column’a, period x’e, totalUsers y’ye, gameType color’a bağlanarak bölgelere göre aylık aktif kullanıcı çizgi grafiği oluşturulur
• TypeScript / JavaScript ortamlarına npm ile kurulabilir
• Ajan iş akışlarında MCP sunucusu kullanılabilir
• gallery üzerinden 46 grafik türü ve 83 örnek görülebilir

Tanımı grafiğe dönüştürme yöntemi

• Flint, sıkıştırılmış bir tanımdan başlayarak Vega-Lite gibi backend’lerin yerel tanımlarını üretir ve gerekli düşük seviyeli ayrıntıları doldurarak grafiği render eder
• Anlamsal tipler, veri alanlarının anlamını ifade eder
  • Örnekler Rank, YearMonth, Delta, Temperature gibi tipleri içerir
  • Flint buna dayanarak ayrıştırma, ölçek, eksen, biçimlendirme ve renk düzeni gibi grafik ayarlarını çıkarımlar
  • Net yeni kullanıcıları oyuna ve aya göre gösteren bir heatmap’te; zaman değeri ayrıştırıcısı, eksen biçimlendirmesi, diverging renk düzeni ve orta nokta anlamsal tiplere göre belirlenir
• Otomatik yerleşim optimizasyonu, esnek yerleşim modeli ve banking ilkelerine dayanır
  • Derleyici boyut, aralık ve konumlandırmayı dinamik olarak yöneterek grafiğin canvas’a sığacak şekilde ayarlanmasını sağlar
  • Gruplu çubuk grafiklerin sayısı arttığında canvas’ı genişletir ve band width’i azaltarak yoğun sürümün de canvas’a sığmasını sağlar
• Grafik tasarımı değişiklikleri, grafik türü değiştirme ve görsel kodlamaları yeniden bağlama yoluyla yönetilebilir
  • 2000 ABD nüfus sayımındaki cinsiyet ve yaşa göre nüfus dağılımını gösteren faceted bar chart, pyramid chart’a dönüştürülürken kullanıcı yalnızca grafik türünü değiştirir; kalanını derleyici halleder

Render backend’leri ve kullanılabilirlik durumu

• Flint, Vega-Lite, ECharts, Chart.js genelinde 46 grafik türünü destekler
  • Farklı API’leri ve programlama modellerini birleşik bir arayüzün arkasında gizler
  • Vega-Lite’ta yerel sunburst olmadığında ECharts’a geçilebilir
  • Bölge × gameType × game hiyerarşisini görselleştirmek için gruplu çubuk grafiğe kıyasla sunburst chart daha iyi bir alternatif olarak sunulur
• Flint açık kaynaklıdır ve hemen kullanılabilir
• Başlangıç noktası olarak GitHub ve galeri örnekleri sunulur
• Microsoft Research, Flint’i IDEAS Lab ve Renmin University of China ile iş birliği içinde geliştirdi

[GN⁺]

Hacker News yorumları

• “Yapay zeka ajanları için” pazarlamasının neden gerekli olduğunu anlıyorum ama sonuçta grafikleri ifade etmeyi kolaylaştıran bir dil olması bile tek başına yeterince etkileyici ve kullanışlı

  • Bunun altını ne kadar çizsek az. “Ajanlar için iyi” demek, sonuçta kendini açıklayan, nasıl kullanılacağı net olan, güvenli varsayılanlara ve kısa ya da kontrol edilebilir çıktılara, ayrıca programlanabilir bir arayüze sahip olduğu anlamına geliyor; bu özellikler insanlar için de faydalı
  • Bu aslında kelimenin tam anlamıyla AI ajanlarının MCP sunucusu üzerinden erişmesi için yapılmış bir şey değil mi diye düşünüyorum. Öyleyse pazarlamada AI ajanlarını vurgulamak epey önemli görünüyor
  • Sanırım bunu böyle özetlemek doğru. Gösterişli açıklama, sonuçta “veriye bakıp grafiğin nasıl görünmesi gerektiğine kendisi karar veriyor” demenin uzatılmış hali gibi
    Sayfada da “ölçek, eksen, aralık ve yerleşim gibi ayrıntılı düşük seviyeli parametreler istemek yerine, Flint derleyicisi veriden, anlamsal türden, grafik türünden ve kodlamadan optimize edilmiş grafik ayarları çıkarır” deniyor
  • Ajanların üretmesi kolay ama insanların da özellikle bir UI varsa düzenlemesi kolay bir biçim
  • Pakete bakınca bunun mevcut grafik kütüphaneleri üzerine kurulduğu görülüyor

• Ajan sistemlerinde yeni bir örüntü ortaya çıkıyor ve bu proje iyi bir örnek
  LLM’in üretip devrettiği bir ara gösterim (IR) oluyor, bunun üstüne de derleyici ya da kod üretici gibi deterministik bir katman ekleniyor. Yakın gelecekte bu yapıyı daha sık göreceğimizi düşünüyorum

  • Claude’un PPT destesini doğrudan XML olarak üretmek yerine Python kodu yazarak oluşturduğunu ilk gördüğümde epey “hah işte” dedirtmişti. Birçok işin bu yoldan gideceğini düşünüyorum; uzun vadede biraz kısıtlayıcı ve hack gibi hissettirse de şimdilik %100 doğru yaklaşım gibi görünüyor
  • Bu fikre tamamen katılıyorum. Geçen ay boyunca yaptığım tüm ajan kodlama işleri ara gösterim üzerinden ilerledi ve yinelemelerin çoğu da esasen o katmanda yapıldı. Bu yöntemle deterministik kod çıktısına oldukça yaklaşabilmek şaşırtıcı
  • İyi tasarlanmış bir ara katman, AI’dan bağımsız doğrulama ve kontrol imkanı sağlar. Böylece insan-AI etkileşimi yetki devrinden iş birliğine dönüşür
  • Evet. Ajan sistemleri en başından beri böyle bir örüntüydü. Gevşek biçimde üret, sonra girdi doğrulanana kadar deliğe uyan şekil ve boyut çıkana dek tekrar tekrar dene
  • Programlama her zamankinden daha canlı

• Sayfada yok ama veri görselleştirme üretirken erişilebilirliği tasarım aşamasında ele almak gerçekten önemli
  Bu podcast’te bununla ilgili kısa bir röportaj güzel özetlenmiş: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
  Röportaj verilen kişi bu alanda oldukça tanınmış görünen Frank Elavsky ve erişilebilirlik denetimi için sezgisel kurallar, ilkeler ve yönergeler içeren Chartability projesini de oluşturmuş: https://chartability.github.io/POUR-CAF/

  • Flint’te de erişilebilirlik desteği üzerinde çalışılması gerekiyor gibi görünüyor ve bu, erişilebilirlik sorunlarını merkezi olarak ele almak için iyi bir nokta
    Takip için bir issue ekledim: https://github.com/microsoft/flint-chart/issues/48

• Bunun Vega’nın kendisinden nasıl daha iyi ya da farklı olduğuna dair somut bir açıklama olup olmadığını merak ediyorum: https://vega.github.io/vega/docs/specification/
  Vega zaten görselleştirme için ifade gücü yüksek bir DSL ve LLM eğitim verilerinde de epey yaygın biçimde yer alıyor olmalı

  • Eskiden Vega insanlar için yüksek seviyeli bir dildi ama bugün AI ajanları için biraz düşük seviyeli kalıyor olabilir. Ajanların iyi görünen grafikler üretmesi için çok sayıda düşük seviyeli parametre kullanması gerekiyor ve bunun sonucu olarak güvenilir biçimde yazması zorlaşıyor
    Flint daha yüksek seviyeli bir soyutlama olduğu için belirtim çok daha kısa ve basit; derleyici de düşük seviyeli kararları çıkararak iyi görünen grafikler oluşturuyor. Yani eskiden uzun bir program gerektiren iyi grafikleri artık ajanlar kısa bir programla oluşturabiliyor
  • Ben de bunun Vega-Lite ile kıyaslandığında nasıl olduğunu merak etmiştim. Vega-Lite da nispeten yüksek seviyeli ve bildirimseldir, ayrıca sözdizimi de Flint’e benziyor gibi görünüyor

• “Basit grafik belirtimleri kararlı olabilir ama sistem varsayılanlarına dayandıkları için üretilen grafik kalitesi düşük olur; karmaşık belirtimler ise iyi görünen grafikler üretebilir ama çok ayrıntılı olduklarından ajanların bunları güvenilir biçimde işlemesi zordur” iddiasına pek katılmıyorum
  Analiz ajanları geliştirdiğim az sayıdaki iş deneyiminde, LLM’lerin Python ve R ile görselleştirmeleri oldukça iyi ürettiği beni etkilemişti. Küçük açık ağırlıklı modeller için de durum aynıydı ve belirsiz kısımları biraz yineleyerek düzeltince dezavantajlar çoğu zaman ortadan kalkıyordu. Bu iddiayı destekleyen ya da sorunun nerede ortaya çıktığını gösteren bir araştırma çizgisi olup olmadığını merak ediyorum

  • Daha basit belirtimler, daha basit ajanlar tarafından kullanılabilir. Muhtemelen buradaki kullanım alanı, tek bir büyük modelin görselleştirmeleri tek tek üretmesi yerine küçük ve ucuz ajanların paralel kullanılması olabilir
    Benim deneyimimde Claude ve ChatGPT ggplot tarzı şeyleri iyi üretiyor ama özelleştirme arttıkça biraz karmaşıklaşıyor
  • Sadece ifade gücü değil, kararlılık ve etkileşimlilik de hesaba katılıyor. Uzman olmayan kullanıcılara hitap ederken ya da küçük modeller kullanırken, hem güçlü ifade sunan hem de basit kalan belirtimler yardımcı oluyor

• “Ölçek, eksen, aralık, yerleşim gibi uzun ve düşük seviyeli parametreler” açıklaması, Microsoft’un burada iki farklı şeyi birbirine karıştırdığı izlenimini veriyor.
  LLM’ler kodun düşük seviyeli ya da uzun olup olmadığını aslında çok da umursamıyor; assembly ya da SPIR-V’yi de gayet iyi okuyabiliyorlar. Asıl sorun görsel kompozisyon. LLM’ler insanlar gibi “görmediği” için, görsel karşılaştırma yoluyla mekânsal düzeni anlamak onlar için doğal değil; bunu aşmak için de LLM’nin akıl yürütüp anlayabileceği, kod biçimindeki görselleştirmeler gibi bir temsil sunmak gerekiyor. Yani yapı, derin biçimde iç içe geçmiş ya da gizli durumu çıkarsamayı gerektiren bir şey olmadığı sürece sorun yok.
  Ayrıca Flint’in JSON içinde string anahtar merkezli tip kullanma kararına katılmak zor. Gerçek spesifikasyona bakınca bunun pekala insanların yazması kolay bir TypeScript kütüphanesi olarak da yapılabileceği görülüyor; bence bu çok daha iyi olurdu. Sonradan kaynağa gerçekten baktığımda, yalnızca belgelere bakıp varsaydığım mockup’tan çok daha olgun ve rafine olduğunu gördüm; ama “string anahtarlı JSON’a karşı gerçek generics tabanlı yazım yüzeyi” yönündeki temel şikayetim hâlâ duruyor.

  • chartType kısmının, şablonların daha genişletilebilir olması gerektiği için çok zarif olmadığını düşünüyorum. Buranın düzeltilmesi gerekiyor.
    Diğer kısımlarda ise görselleştirme ya da diyagram kütüphanelerinin JSON kullanması oldukça yaygın. Çünkü farklı render bağlamlarına kolayca taşınabiliyor.
  • JSON’un en iyi spesifikasyon dili olmadığına katılıyorum, ama her projenin kendi spesifikasyonunu yeniden yazmaya başlamasından daha iyi olup olmadığı ayrıca düşünülmeli.
    İlgili yazı: https://www.openui.com/blog/stop-making-ai-write-json
  • Ne yazık ki LLM’lerde veri ya da kod alıp vermenin en istikrarlı yolu hâlâ JSON gibi görünüyor. Daha kötüsü YAML da olabilirdi.
    LLM öngörülebilirliğini artıran özel DSL’lerle ilgileniyorum ve Microsoft gibi bir devin de bunu anlamış görünmesi sevindirici. https://slangify.org/examples içindeki Contacts örneği, VCARD ile JCARD arasında çift yönlü dönüşüm yaparken özel bir DSL’in nasıl kolayca oluşturulabildiğini gösteriyor.

• “İyi bir derleyicinin ele alması gereken görsel kararları açıkça belirtmeye zorluyor” denince, Graphviz tam da aynı nedenle var değil mi diye düşündürüyor.
  Bildirimsel dil olarak JSON kullanmaları, LLM’lerin JSON’la iyi çalıştığını kabul etsem bile, bunun insanlar için tüketmesi rahat bir sözdizimi olduğu anlamına gelmiyor.

  • Aslında görselleştirmede insanların yazdığı ortak bir dil olarak JSON uzun zamandır var. Bildirimsel sözdiziminin avantajı, kullanıcıların UI içinde sürükle-bırak ya da tıklama ile spesifikasyonu etkili biçimde değiştirebilmesi.
    Flint, ajanların ölçek, eksen, sıfır tabanı, adım boyutu gibi düşük seviyeli parametreleri atlayabilmesi için kasıtlı olarak tasarlanmış. Bunlar iyi görünen grafikler için çok önemli öğeler ve derleyici bunları dinamik olarak optimize ediyor. Bu yüzden AI ajanları için kullanımı daha kolay oluyor.
  • Evet. Açıkçası bu daha çıkar çıkmaz tıkanmış gibi hissettiriyor ve elde zaten var olanlardan belirgin biçimde daha iyi görünmüyor.

• Ek bir biçim öğesi olarak anlamsal tipler kullanmak çok faydalı. Çünkü birçok format boilerplate’ini kısa biçimde kodlayabiliyor.
  Flint tip kayıt defterini paylaşılabilir ya da genişletilebilir yapma planları olup olmadığını merak ediyorum. Neden bunun doğrudan veri özelliğinin kendisi olarak bırakılmadığını da merak ediyorum. Vega-Lite üzerinde daha üst düzey bağlı grafikler kurarken neredeyse aynı spesifikasyona ulaşmıştım.

• Bu projenin esas amacını pek anlayamıyorum. GPT-3.5 zamanından beri LLM’ler tek seferde matplotlib üretebiliyor gibiydi.
  Veri görselleştirmede LLM’leri çok kullandım ve özel bir sorun yaşamadım. Ajanların görselleştirme üretiminde tam olarak nerede zorlandığını ve Flint’in bunu nasıl çözdüğünü gösteren örnekler merak ettiriyor.

  • Burada biraz son %20 sorunu var. Sohbet penceresinde GPT ile konuşup yönlendirmeyi sürekli siz yaparsanız, bu genelde ileri seviye kullanıcılar için yeterince iyi oluyor.
    Ama bunu son kullanıcıya yönelik bir araca koyduğunuzda, iyi görünen grafik üretiminde %80 başarı oranı ciddi bir sorun hâline gelmeye başlıyor. Veri analizi sistemleri geliştirirken bunu yaşadım. Doğrudan matplotlib ya da Vega-Lite üretmesini istediğinizde, aynı anda istikrar, ifade gücü, maliyet, süre ve token kullanımını sağlamak zorlaşıyor; bu yüzden bazı kararları derleyiciye taşıyıp üretim maliyetini düşürürken ifade gücünü koruyan bir orta yol olarak bu dili tasarladılar.

• Proje sayfası: https://microsoft.github.io/flint-chart/
  MCP ayarı: https://microsoft.github.io/flint-chart/#/mcp