3 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Flint adalah bahasa perantara visualisasi yang membantu agen AI membuat chart yang ekspresif dari spesifikasi singkat yang dapat diedit manusia
  • Kompilernya menafsirkan data, tipe semantik, jenis chart, dan encoding untuk secara otomatis mengisi pengaturan tingkat rendah seperti skala, sumbu, jarak, dan tata letak
  • Menyediakan 46 jenis chart dan 83 contoh galeri, serta mendukung rendering Vega-Lite, ECharts, dan Chart.js
  • Di lingkungan TypeScript / JavaScript, Flint dapat diinstal melalui npm, dan dalam workflow agen dapat menggunakan server MCP
  • Perbedaan API antar-backend disembunyikan di balik antarmuka terpadu, sehingga perpindahan renderer atau perubahan desain chart dari spesifikasi yang sama bisa ditangani dengan lebih mudah

Masalah yang ingin diselesaikan Flint

  • Flint adalah proyek Microsoft Research, sebuah bahasa perantara visualisasi yang dirancang agar agen AI dapat menghasilkan chart dari spesifikasi chart yang sederhana dan dapat diedit manusia
  • Spesifikasi terdiri dari data, tipe semantik, dan spesifikasi chart
    • Contoh spesifikasi menetapkan period sebagai YearMonth, totalUsers sebagai Quantity, serta gameType dan region sebagai Category
    • Pada Line Chart, region diikat ke column, period ke x, totalUsers ke y, dan gameType ke color untuk membuat chart garis pengguna aktif bulanan per wilayah
  • Dapat diinstal di lingkungan TypeScript / JavaScript melalui npm
  • Dalam workflow agen, dapat menggunakan server MCP
  • Di gallery, Anda dapat melihat 46 jenis chart dan 83 contoh

Cara mengubah spesifikasi menjadi chart

  • Flint memulai dari spesifikasi yang dipadatkan, lalu menghasilkan spesifikasi native backend seperti Vega-Lite dan merender chart dengan melengkapi detail pengaturan tingkat rendah yang diperlukan
  • Tipe semantik mengekspresikan makna dari field data
    • Contohnya mencakup tipe seperti Rank, YearMonth, Delta, dan Temperature
    • Berdasarkan ini, Flint menyimpulkan pengaturan chart seperti parsing, skala, sumbu, pemformatan, dan skema warna
    • Pada heatmap yang menampilkan pengguna baru bersih menurut game dan bulan, parser nilai waktu, pemformatan sumbu, serta skema warna divergen dan titik tengah ditentukan berdasarkan tipe semantik
  • Optimisasi tata letak otomatis didasarkan pada model tata letak elastis dan prinsip banking
    • Kompiler secara dinamis mengelola ukuran, jarak, dan penempatan agar chart menyesuaikan dengan kanvas
    • Saat jumlah grouped bar chart bertambah, kanvas diperbesar dan band width diperkecil agar versi yang lebih rapat tetap muat di kanvas
  • Perubahan desain chart dapat ditangani dengan pergantian jenis chart dan rebinding encoding visual
    • Saat mengubah faceted bar chart distribusi populasi menurut gender dan usia dari sensus AS tahun 2000 menjadi pyramid chart, pengguna hanya perlu mengganti jenis chart dan sisanya ditangani oleh kompiler

Backend rendering dan status ketersediaan

  • Flint mendukung 46 jenis chart di Vega-Lite, ECharts, dan Chart.js
    • Menyembunyikan API dan model pemrograman yang berbeda di balik antarmuka terpadu
    • Saat Vega-Lite tidak memiliki sunburst native, pengguna dapat beralih ke ECharts
    • Untuk visualisasi hierarki region × gameType × game, sunburst chart diajukan sebagai alternatif yang lebih baik daripada grouped bar chart
  • Flint bersifat open source dan dapat langsung digunakan
  • GitHub dan contoh galeri disediakan sebagai titik awal
  • Microsoft Research membangun Flint bersama IDEAS Lab dan Renmin University of China

1 komentar

 
GN⁺ 3 jam lalu
Pendapat Hacker News
  • Saya paham kenapa pemasaran dengan istilah “untuk agen AI” diperlukan, tetapi pada akhirnya fakta bahwa ini adalah bahasa yang memudahkan representasi chart saja sudah cukup mengesankan dan berguna

    • Ini memang layak ditekankan berkali-kali. “Bagus untuk agen” pada akhirnya berarti self-descriptive, jelas cara memanipulasinya, punya default yang aman serta output yang ringkas atau dapat dikendalikan, dan antarmuka yang bisa diprogram, dan karakteristik seperti ini juga membantu manusia
    • Rasanya ini memang secara harfiah dibuat agar agen AI bisa mengaksesnya lewat server MCP. Kalau begitu, menekankan agen AI dalam pemasaran tampaknya cukup penting
    • Rasanya ringkasan seperti ini yang paling tepat. Penjelasan yang panjang dan mewah pada akhirnya terdengar seperti versi panjang dari “melihat data lalu menentukan sendiri bagaimana chart seharusnya ditampilkan”
      Di halamannya juga dijelaskan bahwa “alih-alih meminta parameter tingkat rendah yang bertele-tele seperti skala, sumbu, spasi, dan layout, compiler Flint menurunkan pengaturan chart yang dioptimalkan dari data, tipe semantik, tipe chart, dan encoding”
    • Mudah dihasilkan oleh agen, tetapi juga mudah diedit oleh manusia, terutama jika ada UI
    • Dari paketnya terlihat bahwa ini dibangun di atas library chart yang sudah ada
  • Pola baru sedang muncul dalam sistem agen, dan proyek ini adalah contoh yang bagus
    Caranya adalah dengan menempatkan sebuah representasi perantara (IR) yang dihasilkan dan diteruskan oleh LLM, lalu menambahkan lapisan deterministik seperti compiler atau code generator di atasnya. Sepertinya kita akan lebih sering melihat struktur seperti ini dalam waktu dekat

    • Saat pertama kali melihat Claude tidak membuat dek PPT langsung dalam XML melainkan menulis kode Python untuk menghasilkannya, itu terasa seperti momen “aha”. Sepertinya banyak pekerjaan akan bergerak ke jalur ini, dan dalam jangka panjang ini mungkin terasa agak terbatas dan seperti hack, tetapi untuk sementara tampaknya ini pendekatan yang 100% tepat
    • Saya sepenuhnya setuju dengan ide ini. Selama sebulan terakhir, semua pekerjaan agent coding yang saya lakukan berjalan lewat representasi perantara, dan iterasi juga terutama dilakukan pada lapisan itu. Mengejutkan bahwa dengan cara ini kita bisa sangat dekat ke output kode yang deterministik
    • Lapisan perantara yang dirancang dengan baik memungkinkan validasi dan kontrol secara independen dari AI. Dengan begitu, interaksi manusia dan AI berubah dari pendelegasian menjadi kolaborasi
    • Betul. Sistem agen memang sudah seperti ini sejak awal. Menghasilkan secara longgar, lalu terus mencoba lagi sampai bentuk dan ukurannya pas dengan lubang yang ada, hingga inputnya tervalidasi
    • Pemrograman lebih hidup dari sebelumnya
  • Ini tidak ada di halamannya, tetapi saat membuat visualisasi data, sangat penting untuk memasukkan aksesibilitas sejak tahap perancangan
    Di podcast ini ada wawancara singkat terkait yang dirangkum dengan baik: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    Narasumbernya adalah Frank Elavsky, yang tampaknya cukup terkenal di bidang ini, dan ia juga membuat proyek Chartability yang berisi heuristik, prinsip, dan panduan untuk audit aksesibilitas: https://chartability.github.io/POUR-CAF/

  • Saya penasaran apakah ada penjelasan yang konkret tentang bagaimana ini lebih baik atau berbeda dibanding Vega sendiri: https://vega.github.io/vega/docs/specification/
    Vega sendiri sudah merupakan DSL yang ekspresif untuk visualisasi, dan sepertinya juga cukup luas masuk ke data pelatihan LLM

    • Dulu Vega adalah bahasa tingkat tinggi untuk manusia, tetapi sekarang untuk agen AI justru bisa jadi agak tingkat rendah. Agar agen bisa membuat chart yang enak dilihat, ia harus menulis banyak parameter tingkat rendah, sehingga hasilnya jadi sulit ditulis secara stabil
      Flint adalah abstraksi tingkat yang lebih tinggi, sehingga spesifikasinya jauh lebih pendek dan sederhana, dan compiler-lah yang menurunkan keputusan tingkat rendah untuk menghasilkan chart yang enak dilihat. Dengan kata lain, chart bagus yang dulu memerlukan program panjang kini bisa dibuat agen dengan program pendek
    • Saya juga penasaran bagaimana perbandingannya dengan Vega-Lite. Vega-Lite juga relatif tingkat tinggi dan deklaratif, dan sintaksnya tampak mirip dengan Flint
  • Saya tidak terlalu sepakat dengan klaim bahwa “spesifikasi chart sederhana bisa stabil tetapi kualitas chart yang dihasilkan rendah karena bergantung pada default sistem, sedangkan spesifikasi yang kompleks bisa menghasilkan chart yang enak dilihat tetapi terlalu bertele-tele sehingga sulit ditangani agen secara stabil”
    Dari sedikit pengalaman kerja membuat agen analisis, saya terkesan bahwa LLM cukup bagus membuat visualisasi dengan Python dan R. Hal yang sama juga berlaku untuk model kecil dengan bobot terbuka, dan jika bagian yang ambigu diulang serta diperhalus sedikit, kekurangannya sering kali hilang. Saya penasaran apakah ada alur riset yang mendukung klaim ini atau menunjukkan di mana masalahnya muncul

    • Spesifikasi yang lebih sederhana bisa dipakai agen yang lebih sederhana. Mungkin use case di sini bukan satu model besar yang membuat visualisasi satu per satu, melainkan agen kecil dan murah yang dipakai secara paralel
      Secara pribadi, menurut saya Claude dan ChatGPT cukup bagus menghasilkan model ggplot, tetapi saat kustomisasinya makin banyak, memang jadi agak rumit
    • Yang dipertimbangkan bukan hanya ekspresivitas, tetapi juga stabilitas dan interaktivitas. Jika sasarannya pengguna non-ahli atau memakai model kecil, spesifikasi yang sederhana namun tetap ekspresif akan membantu
  • Penjelasan seperti “parameter tingkat rendah yang bertele-tele seperti skala, sumbu, spasi, dan tata letak” terasa seperti Microsoft sedang mencampuradukkan dua hal yang berbeda.
    LLM pada dasarnya tidak terlalu peduli apakah kode itu tingkat rendah atau bertele-tele, dan bahkan bisa membaca assembly atau SPIR-V dengan baik. Masalah yang sebenarnya adalah komposisi visual. LLM “melihat” secara berbeda dari manusia, sehingga memahami susunan spasial melalui perbandingan visual bukan hal yang alami baginya, dan untuk mengakalinya perlu diberikan representasi yang mudah ditalar dan dipahami LLM, seperti visualisasi dalam bentuk kode. Artinya, asalkan bukan struktur yang sangat bertingkat atau mengharuskan penalaran atas keadaan yang tersembunyi, itu sudah cukup
    Selain itu, sulit untuk setuju dengan keputusan Flint yang menangani tipe di JSON dengan berpusat pada kunci string. Jika melihat spesifikasi aslinya, ini sebenarnya bisa saja dibuat sebagai library TypeScript yang ramah ditulis manusia, dan sepertinya itu akan jauh lebih baik. Setelah kemudian benar-benar melihat source-nya, ternyata hasilnya jauh lebih matang dan canggih daripada mockup yang saya asumsikan hanya dari dokumentasinya, tetapi keluhan inti soal “JSON dengan kunci string vs permukaan penulisan generik yang sungguhan” tetap ada

    • Bagian chartType menurut saya kurang elegan karena template-nya harus lebih bisa diperluas. Bagian ini memang perlu diperbaiki
      Untuk bagian lain, penggunaan JSON di library visualisasi atau diagram cukup umum karena mudah dipindahkan ke konteks rendering yang berbeda
    • Saya setuju bahwa JSON bukan bahasa spesifikasi yang optimal, tetapi masih perlu dipikirkan apakah itu lebih baik daripada tiap proyek mulai menulis spesifikasinya sendiri-sendiri
      Tulisan terkait: https://www.openui.com/blog/stop-making-ai-write-json
    • Sayangnya, untuk LLM, cara paling stabil untuk memasukkan dan mengeluarkan data atau kode tampaknya masih terikat pada JSON. Setidaknya bukan YAML yang lebih buruk
      Saya tertarik pada DSL kustom yang bisa meningkatkan prediktabilitas LLM, dan senang melihat raksasa seperti Microsoft tampaknya juga memahami hal ini. Contoh Contacts di https://slangify.org/examples adalah cara membuat DSL sendiri dengan mudah sambil bolak-balik mengonversi VCARD dan JCARD secara langsung
  • Dari penjelasan bahwa ini “memaksa keputusan visual yang seharusnya ditangani compiler yang baik menjadi eksplisit”, saya jadi merasa bukankah Graphviz ada justru karena alasan yang sama?
    Melihat JSON dipakai sebagai bahasa deklaratif, saya mengakui LLM memang pandai menangani JSON, tetapi itu bukan sintaks yang enak dikonsumsi manusia

    • Sebenarnya, sebagai bahasa umum yang ditulis manusia untuk visualisasi, JSON sudah ada cukup lama. Keuntungan sintaks deklaratif adalah pengguna bisa memanipulasi spesifikasi secara efektif lewat drag-and-drop atau klik di UI
      Flint sengaja dirancang agar agen melewati parameter tingkat rendah seperti skala, sumbu, baseline 0, dan ukuran langkah. Elemen-elemen ini sangat penting untuk chart yang enak dilihat, dan dioptimalkan secara dinamis oleh compiler. Karena itu, AI agent jadi lebih mudah menanganinya
    • Betul. Sejujurnya, ini terasa langsung mentok begitu dirilis, dan tidak terlihat lebih baik dari yang sudah ada sebelumnya
  • Menggunakan tipe semantik sebagai elemen format tambahan sangat berguna karena bisa mengenkode banyak boilerplate format dengan ringkas
    Saya penasaran apakah ada rencana untuk membuat registry tipe Flint bisa dibagikan atau diperluas. Saya juga penasaran kenapa itu tidak diletakkan langsung sebagai properti data. Saat membuat chart terhubung tingkat lebih tinggi di atas Vega-Lite, saya sampai pada spesifikasi yang hampir sama

  • Saya kurang paham inti proyek ini. Sejak era GPT-3.5, rasanya LLM sudah bisa menghasilkan matplotlib dalam sekali jalan
    Saya sudah cukup sering memakai LLM untuk visualisasi data dan tidak banyak menemui masalah. Saya penasaran contoh konkret di mana agent kesulitan saat membuat visualisasi, dan bagaimana Flint menyelesaikannya

    • Ada sedikit masalah 20% terakhir di sini. Jika Anda mengarahkan terus lewat percakapan dengan GPT di chat, untuk power user ini umumnya cukup baik
      Tetapi saat dimasukkan ke alat untuk pengguna akhir, tingkat keberhasilan 80% dalam membuat chart yang enak dilihat mulai menjadi masalah besar. Saya mengalami hal ini saat membangun sistem analisis data. Jika dibiarkan menghasilkan matplotlib atau Vega-Lite secara langsung, sulit mencapai stabilitas, daya ekspresif, serta biaya waktu dan token sekaligus; karena itu bahasa ini dirancang sebagai kompromi yang memindahkan sebagian keputusan ke compiler untuk menurunkan biaya generasi sambil mempertahankan daya ekspresif
  • Halaman proyek: https://microsoft.github.io/flint-chart/
    Pengaturan MCP: https://microsoft.github.io/flint-chart/#/mcp