Catatan penulis: Artikel ini membahas cara Flint-interactive menggunakan “peristiwa semantik + operasi pembaruan” untuk mengurangi biaya dan kesalahan saat agent membuat grafik interaktif, serta mengulas tiga cara integrasinya.
Jika Anda membuat agent AI untuk analisis data atau pelaporan, Anda mungkin pernah mengalami situasi ini: agent bisa dengan cepat membuat grafik statis, tetapi begitu ditambah fitur “klik untuk memfilter” atau “seleksi kotak yang terhubung”, hasilnya harus diperbaiki berkali-kali. Kadang tata letaknya bergeser, kadang penyorotannya tidak berfungsi. Satu masalah selesai, masalah lain muncul. Token dan waktu pun habis untuk debugging.
Microsoft Research merilis Flint-interactive pada 22 Oktober 2026. Ini adalah bahasa visualisasi data interaktif yang dibangun di atas Flint. Artikel ini tidak merekomendasikan pustaka grafik baru, melainkan menggunakan Flint-interactive sebagai studi kasus untuk membahas cara merancang spesifikasi output tingkat tinggi bagi agent, agar agent tidak perlu banyak menulis kode rendering tingkat rendah.
Manfaat utama: Setelah membaca artikel ini, Anda akan memahami hambatan biaya dan keandalan saat agent membuat grafik interaktif, mengenal pendekatan “serahkan logika visual kepada compiler, jelaskan logika interaksi dengan peristiwa semantik”, serta mengetahui skenario yang cocok untuk tiga cara integrasi: dalam percakapan, dalam aplikasi, dan melalui interaksi kustom.
Mengapa meminta agent langsung menulis kode interaksi di luar Flint-interactive itu mahal
Meminta agent langsung menulis kode grafik interaktif tampak seperti pilihan paling fleksibel. Namun, blog penelitian tersebut menunjukkan bahwa bahkan dengan model mutakhir yang sangat canggih, ada dua hambatan yang jelas saat diterapkan dalam praktik.
Hambatan pertama adalah biaya pembuatan yang tinggi. Agent jarang bisa menghasilkan grafik interaktif yang memuaskan dalam satu putaran. Biasanya, diperlukan beberapa putaran penalaran, penulisan kode, dan debugging, yang masing-masing menghabiskan token dan waktu. Hambatan kedua adalah keandalan yang rendah. Visualisasi interaktif memang kompleks. Grafik dengan interaksi yang kaya mudah mengalami masalah tata letak atau interaksi yang tidak berfungsi, dan perbaikannya pun bisa memunculkan masalah baru.
Lalu, apakah interaksi bawaan pustaka grafik bisa menjadi solusi? Menurut blog tersebut, interaksi bawaan beberapa pustaka visualisasi kurang ekspresif sehingga sulit digunakan untuk membuat grafik interaktif yang disesuaikan. Pada dasarnya, yang dibutuhkan adalah bahasa deskripsi interaksi yang “ekspresif sekaligus cukup abstrak”.
| Pendekatan | Yang perlu dihasilkan agent | Masalah utama | Kesesuaian |
|---|---|---|---|
| Menulis kode rendering tingkat rendah secara langsung | Pendengar peristiwa, deteksi objek yang terkena interaksi, logika penggambaran ulang | Debugging berkali-kali, konsumsi token tinggi, mudah memunculkan bug baru | Paling ekspresif, tetapi kurang stabil |
| Hanya menggunakan interaksi bawaan pustaka grafik | Mengaktifkan atau menonaktifkan beberapa opsi konfigurasi | Jenis interaksi terbatas dan sulit disesuaikan | Stabil, tetapi kurang ekspresif |
| Spesifikasi Flint-interactive | Pemetaan dari peristiwa semantik ke operasi pembaruan | Perlu mempelajari sistem spesifikasi baru | Menyeimbangkan ekspresivitas dan keandalan |
Jika agent Anda perlu sering berganti model untuk menjalankan tugas pembuatan dengan banyak putaran seperti ini, Anda bisa mengakses berbagai model populer melalui antarmuka terpadu APIYI di apiyi.com. Dengan kode pemanggilan yang sama, Anda dapat membandingkan jumlah putaran dan konsumsi tiap model, lalu mengetahui seberapa mahal pendekatan “menulis kode tingkat rendah” untuk kebutuhan Anda.
Poin penting Flint-interactive
| Poin | Penjelasan | Manfaat bagi developer |
|---|---|---|
| Peristiwa semantik | Kompiler menerjemahkan pemicu mentah seperti klik, seret, dan penekanan tombol menjadi “elemen grafik dan data apa yang dipilih” | Agent tidak perlu menangani koordinat piksel dan deteksi elemen yang terkena interaksi |
| Operasi pembaruan | Operasi tingkat tinggi seperti set-style, set-annotation, dan set-viewport mendeskripsikan perubahan tampilan | Tidak perlu memanipulasi elemen grafis khusus renderer |
| Mesin status Flint Canvas | Melacak interaksi pengguna pada kanvas dan mengelola status rendering | Runtime dikelola oleh framework, sehingga mengurangi kekacauan status |
| Dapat dikombinasikan | Pembuatan peristiwa dan pembaruan visual dapat dikombinasikan serta dihubungkan dengan tabel, teks, dan komponen | Memudahkan pembuatan cerita data dan dasbor yang saling terhubung |
Peristiwa semantik: Flint-interactive hanya peduli pada “data apa yang dipilih pengguna”
Peristiwa semantik adalah konsep paling mendasar dalam Flint-interactive. Dengan pendekatan tradisional, agent harus menangani “mouse ditekan pada koordinat （x， y） lalu diseret ke mana”, kemudian menghitung sendiri titik data yang tercakup dalam area tersebut. Di Flint, kompiler melakukan langkah ini dan langsung menghasilkan peristiwa bermakna seperti “pengguna memilih beberapa kelompok negara ini dengan kotak seleksi”.
Analogi yang mirip dalam pengembangan frontend adalah perbedaan antara “peristiwa DOM native” dan “peristiwa bisnis”. Saat menulis logika bisnis, kamu tidak perlu memikirkan koordinat mousedown; kamu hanya perlu tahu bahwa “pengguna memilih pesanan A”. Peristiwa semantik menerapkan abstraksi serupa pada visualisasi, dan kompiler menjamin ketepatannya.
Operasi pembaruan: Flint-interactive menggunakan hasil deklaratif sebagai pengganti penggambaran ulang imperatif
Setelah menerima peristiwa semantik, logika interaksi hanya perlu menjawab satu pertanyaan: seperti apa tampilan yang diinginkan? Operasi pembaruan yang disebutkan dalam blog mencakup set style untuk menyorot data, set annotation untuk menambahkan label pada titik tertentu, dan set viewport untuk menggeser atau memperbesar tampilan.
Ini mirip dengan hubungan antara SQL dan perulangan yang ditulis manual. Saat menulis SQL, kamu mendeskripsikan “hasil yang diinginkan”, lalu database menentukan cara menjalankannya. Saat menulis interaksi Flint, kamu mendeskripsikan “data mana yang perlu disorot”, lalu kompiler menerjemahkannya menjadi perubahan konkret pada kanvas, termasuk deteksi elemen yang terkena interaksi dan pembaruan visual di tingkat dasar.
Mesin status: Flint Canvas mengelola runtime interaksi
Flint Canvas pada dasarnya adalah mesin status yang terus melacak interaksi pengguna pada kanvas dan mengelola status rendering. Bagi agent, ini berarti ia tidak perlu memelihara sendiri status perantara yang rawan kesalahan, seperti “apa yang sedang dipilih” atau “apakah sorotan sebelumnya sudah dihapus”.
Diagram di atas menggambarkan pembagian utama dalam blog: logika visual dikelola oleh kompiler, sedangkan logika interaksi dideskripsikan oleh pengguna pada tingkat semantik. Agent hanya menangani pemetaan di tengah—“peristiwa apa menghasilkan pembaruan apa”—sementara kedua ujung yang paling rawan kesalahan diserahkan kepada framework.
Prinsip yang bisa diterapkan di luar Flint-interactive: merancang spesifikasi keluaran tingkat tinggi untuk agent
Di luar Flint-interactive, pelajaran yang paling berguna dari kasus ini adalah keputusan rekayasanya: jangan minta agent menghasilkan keluaran pada lapisan yang paling mudah membuatnya keliru. Kode rendering tingkat rendah memiliki dependensi yang kompleks dan siklus umpan balik yang panjang, sehingga biaya coba-coba berulang di lapisan ini menjadi tinggi.
Dengan pendekatan berbeda, Flint mengubah masalah pemrograman yang terbuka menjadi masalah “melakukan pemetaan dengan kosakata terbatas”. Ruang keluaran agent menjadi lebih kecil dan strukturnya lebih rapi, sehingga lebih mudah divalidasi. Pendekatan ini juga bisa diterapkan pada orkestrasi alur kerja, pembuatan formulir, dan tata letak laporan.
| Kriteria | Cocok dihasilkan oleh agent | Cocok ditangani compiler atau runtime |
|---|---|---|
| Apakah mengekspresikan maksud bisnis | Ya, misalnya “sorot anggota grup yang sama setelah negara dipilih” | Tidak, misalnya konversi koordinat piksel |
| Apakah bergantung pada banyak state implisit | Sedikit, cukup dijelaskan dalam satu pemetaan | Banyak, perlu dilacak terus-menerus |
| Apakah kesalahan mudah ditemukan | Struktur spesifikasi jelas dan mudah divalidasi | Detail rendering tersebar dan sulit ditelusuri |
| Apakah bisa digunakan ulang | Bisa dijadikan preset, seperti linked-brush | Infrastruktur umum yang cukup diimplementasikan sekali |
Saat merancang format keluaran untuk agent Anda, gunakan tabel ini untuk memeriksa setiap lapisan. Jika suatu lapisan memenuhi kriteria “mengekspresikan maksud, memiliki sedikit dependensi state, dan mudah divalidasi”, lapisan itu cocok ditangani agent. Sebaliknya, serahkan ke kode deterministik atau compiler.
Perlu dicatat, blog penelitian tersebut tidak memberikan data kuantitatif tentang pengurangan konsumsi token atau peningkatan tingkat keberhasilan. Sebaiknya uji sendiri manfaat prinsip desain ini pada tugas Anda, alih-alih langsung menerapkan kesimpulannya.
Panduan cepat Flint-interactive: 3 cara integrasi
Blog tersebut menjelaskan tiga cara penggunaan untuk pengguna grafik, pengembang aplikasi, dan perancang interaksi. Berikut urutannya, dari yang paling ringan hingga yang paling kompleks.
| Cara integrasi | Pengguna sasaran | Output agent atau aplikasi | Skenario umum |
|---|---|---|---|
| Dalam percakapan (Flint-MCP + MCP Apps) | Pengguna grafik | Spesifikasi grafik Flint + interaction_spec |
Menjelajahi data dalam chat dan membawa data terpilih ke pertanyaan lanjutan |
| Integrasi dalam aplikasi (Flint Interactive Canvas) | Pengembang aplikasi | Fungsi penanganan peristiwa semantik + operasi pembaruan yang dikirim ke Canvas | Dasbor, cerita data, serta interaksi terpadu antara grafik dan tabel |
| Interaksi khusus (API pemrograman) | Perancang interaksi | Trigger + fungsi handle khusus | Interaksi khusus di luar preset, seperti DimpVis |
Cara pertama: Menggunakan Flint-interactive dalam percakapan (MCP)
Ini adalah cara yang paling ringan. Dengan Flint-MCP dan MCP Apps, kamu bisa langsung menggunakan Flint Interactive di lingkungan chat atau canvas. Ikuti panduan pengaturan MCP resmi untuk konfigurasinya. Setelah terhubung, alurnya kurang lebih seperti ini:
- Ikuti panduan pengaturan MCP resmi untuk menghubungkan Flint-MCP ke lingkungan chat atau canvas yang mendukung MCP Apps;
- Beri tahu agent grafik yang ingin dibuat dan interaksi yang dibutuhkan, misalnya “dukung pemilihan dengan kotak dan sorot negara dalam kelompok yang sama”;
- Selain spesifikasi grafik Flint, agent akan membuat
interaction_specdan menampilkan grafik interaktif dalam percakapan; - Pilih data pada grafik. Data yang dipilih dapat diteruskan sebagai konteks untuk percakapan berikutnya.
Langkah keempat ini sangat berguna. Setelah memilih sekumpulan data yang menyimpang dengan kotak, pengguna bisa langsung bertanya, “Kenapa beberapa titik ini lebih tinggi?” Agent menerima hasil pemilihan yang terstruktur, bukan deskripsi teks yang kurang jelas.
Jalur dua: Integrasikan Flint-interactive Canvas ke dalam aplikasi
Jika ingin menggunakannya di dasbor atau cerita data sendiri, Anda bisa memilih Flint Interactive Canvas. Aliran datanya bersifat dua arah:
- Grafik → aplikasi: Flint Canvas mengirimkan peristiwa semantik yang diterima aplikasi melalui fungsi penangan peristiwa. Peristiwa ini bisa digunakan untuk memfilter tabel, memperbarui grafik lain, atau mengubah status aplikasi;
- Aplikasi → grafik: Saat komponen aplikasi perlu mengubah grafik, cukup kirim operasi pembaruan ke Flint Canvas.
Contoh di blog menunjukkan hubungan dua arah antara grafik dan tabel: mengeklik baris tabel akan menyorot titik pada grafik, dan sebaliknya. Bagi produk pelaporan, inilah dasar pengalaman yang menghubungkan grafik dan teks. Blog tersebut juga menyebutkan bahwa Anda bisa membagikan skill interaction-author kepada agent pemrograman agar ia membantu menambahkan preset interaksi ke aplikasi.
Jalur tiga: Buat interaksi kustom Flint-interactive dengan API pemrograman
Ketika interaksi preset, seperti linked-brush untuk memilih area secara terhubung, tidak lagi memadai, Anda bisa menggunakan API pemrograman untuk menentukan pemicu atau trigger dan fungsi handle kustom. Keduanya memetakan peristiwa semantik menjadi serangkaian pembaruan grafik yang disesuaikan.
Contoh di blog menunjukkan cara menyorot suatu negara saat diklik dan menambahkan label namanya. Handler ini menggabungkan operasi set-style dan set-annotation, tanpa perlu mengolah penanda grafis yang khusus untuk renderer tertentu. Dalam contoh DimpVis yang lebih kompleks, pengguna dapat menyeret titik di sepanjang jalur waktu untuk mengamati perubahan suhu dan curah hujan di semua kota.
🚀 Saran untuk memulai: Gunakan jalur satu terlebih dahulu untuk memeriksa lewat percakapan apakah data Anda cocok untuk interaksi, lalu putuskan apakah perlu menggunakan jalur dua atau tiga. Model yang menggerakkan agent dapat diakses secara terpadu melalui APIYI apiyi.com. Dengan kode yang sama, Anda bisa beralih di antara beberapa model populer dan melihat mana yang lebih konsisten menghasilkan
interaction_specyang valid.
Mengevaluasi keandalan agent dalam menghasilkan spesifikasi Flint-interactive
Blog tersebut tidak menjelaskan model atau agent mana yang lebih baik dalam menghasilkan spesifikasi Flint. Jadi, sebelum meluncurkannya, sebaiknya buat alur evaluasi sederhana. Beberapa metrik yang bisa diperhatikan:
| Metrik evaluasi | Cara pengamatan | Keterangan |
|---|---|---|
| Tingkat keberhasilan pada percobaan pertama | Hitung persentase hasil yang dapat dirender dan diinteraksikan dengan benar sejak percobaan pertama | Langsung mencerminkan biaya pembuatan |
| Rata-rata putaran perbaikan | Catat jumlah putaran percakapan yang diperlukan hingga hasil dapat digunakan | Berkaitan dengan penggunaan token dan waktu |
| Kesesuaian dengan tujuan interaksi | Periksa secara manual apakah perilaku interaksi sesuai dengan kebutuhan | Spesifikasi yang valid belum tentu sesuai dengan tujuan |
| Stabilitas regresi | Periksa apakah interaksi lain tetap berfungsi setelah satu interaksi diubah | Berkaitan dengan masalah keandalan yang disebutkan dalam blog |
Siapkan sekumpulan kebutuhan interaksi yang tetap sebagai set pengujian. Gunakan petunjuk yang sama untuk mencoba dua pendekatan: “langsung menulis kode rendering” dan “menghasilkan spesifikasi Flint”. Dengan antarmuka agregasi berbagai model seperti APIYI, Anda bisa membandingkan beberapa model dalam satu skrip tanpa perlu mengintegrasikan SDK masing-masing penyedia secara terpisah.
Pertanyaan Umum FAQ
Q1: Apa itu Flint-interactive?
Flint-interactive adalah bahasa visualisasi data interaktif yang dikembangkan Microsoft Research di atas Flint. Bahasa ini menggunakan compiler untuk menerjemahkan interaksi pengguna menjadi peristiwa semantik, lalu mengubah grafik melalui operasi pembaruan tingkat tinggi. Dengan spesifikasi yang ringkas, pengguna dan agent dapat mendeskripsikan interaksi seperti klik, pemfilteran, zoom, penyorotan, dan keterkaitan antar-grafik.
Q2: Apa bedanya Flint-interactive dengan meminta agent langsung menulis kode interaksi grafik?
Saat langsung menulis kode, agent harus menangani peristiwa, deteksi titik yang diklik, dan penggambaran ulang sekaligus. Cara ini fleksibel, tetapi membutuhkan lebih banyak putaran debugging dan lebih rentan terhadap kesalahan. Flint-interactive menyerahkan logika visual kepada compiler, sehingga agent hanya perlu mendeskripsikan “peristiwa semantik apa yang memicu pembaruan apa”. Hasilnya lebih ringkas dan strukturnya lebih mudah divalidasi.
Q3: Kapan Flint-interactive dirilis?
Blog Microsoft Research menerbitkan riset ini pada 22 Oktober 2026 sebagai hasil penelitian terbaru. Materi referensi tidak menjelaskan secara rinci lisensi open source, tingkat kematangan, atau kesiapannya untuk produksi. Sebelum menggunakannya dalam proyek resmi, sebaiknya periksa informasi terbaru di repositori resmi.
Q4: Untuk skenario apa Flint-interactive paling cocok?
– **Analisis data berbasis percakapan**: memilih titik data dengan kotak seleksi dalam chat, lalu menggunakan hasilnya untuk pertanyaan lanjutan;
– **Laporan dan dasbor**: menghubungkan beberapa grafik dan memfilter tabel detail dengan mengklik grafik;
– **Cerita berbasis data**: menyoroti bagian terkait antara grafik dan paragraf secara dua arah, seperti dalam narasi interaktif pada jurnalisme data.
Q5: Bagaimana menyiapkan pemanggilan model saat membangun agent yang menggunakan Flint-interactive?
Flint menangani “apa yang dihasilkan”, sedangkan modelnya tetap perlu diintegrasikan secara terpisah. Cara yang praktis adalah mengakses beberapa model populer melalui APIYI apiyi.com dan menjalankan kebutuhan interaksi yang sama lewat satu antarmuka. Bandingkan tingkat spesifikasi yang langsung bisa digunakan pada percobaan pertama dan jumlah putaran perbaikannya, lalu tentukan model yang akan digunakan di lingkungan produksi.
Q6: Bagaimana penanggung jawab produk menentukan apakah tim perlu menggunakan Flint-interactive?
Mulailah dengan menjawab dua pertanyaan: apakah pengguna benar-benar perlu mengeksplorasi grafik, dan apakah grafik interaktif yang dibuat agent saat ini sering membutuhkan pengerjaan ulang? Jika jawabannya ya untuk keduanya, jalur pertama layak dicoba dalam pengujian skala kecil. Pada tahap pengujian, platform APIYI dapat membantu beralih model dengan cepat agar biaya validasi tetap rendah.
Q7: Apa saja keterbatasan Flint-interactive yang sudah diketahui atau masih perlu dikonfirmasi?
– **Kurangnya data kuantitatif**: blog tersebut tidak mencantumkan angka spesifik tentang penghematan token atau peningkatan tingkat keberhasilan;
– **Kecocokan model belum diketahui**: tidak dijelaskan model mana yang paling baik dalam menghasilkan spesifikasi Flint;
– **Jenis interaksi terbatas**: interaksi di luar preset perlu dibuat sendiri menggunakan API pemrograman. Tim resmi mendorong pengguna untuk mengajukan preset baru di GitHub agar pilihan interaksi bertambah.
Poin Utama Flint-interactive
- Sumber biaya: Ketika agent menulis kode interaksi secara langsung, dibutuhkan beberapa putaran debugging yang menghabiskan banyak token. Proses perbaikan juga berisiko menimbulkan bug baru;
- Peristiwa semantik: Kompiler menerjemahkan tindakan mentah seperti klik dan seret menjadi informasi tentang “data mana yang dipilih”;
- Operasi pembaruan: Gunakan set-style, set-annotation, dan set-viewport untuk mendeklarasikan perubahan tampilan tanpa menyentuh proses rendering tingkat rendah;
- Pemisahan tanggung jawab: Logika visual ditangani kompiler, logika interaksi dijelaskan pada lapisan semantik, dan mesin status Canvas dikelola oleh runtime;
- Tiga jalur: Gunakan MCP dalam percakapan, Canvas di dalam aplikasi, dan API pemrograman untuk interaksi kustom;
- Prinsip yang bisa diterapkan di tempat lain: Rancang spesifikasi output tingkat tinggi untuk agent, lalu serahkan lapisan yang paling rawan kesalahan kepada sistem deterministik;
- Validasi penerapan: Bandingkan beberapa model melalui antarmuka terpadu APIYI untuk menguji stabilitas pembuatan spesifikasi.
Kesimpulan
Pendekatan peristiwa semantik Flint-interactive dapat dirangkum dalam tiga poin:
- Identifikasi masalah yang tepat: Grafik interaktif sulit dibuat bukan karena model kurang andal, melainkan karena belum ada bahasa interaksi tingkat tinggi yang cukup ekspresif;
- Pembagian tanggung jawab yang jelas: Kompiler menangani penguraian peristiwa dan pembaruan tampilan, sementara agent hanya menjelaskan pemetaan “peristiwa → pembaruan”;
- Opsi integrasi bertahap: Mulai dari mencoba dalam percakapan, mengintegrasikan ke aplikasi, hingga membuat interaksi kustom, semuanya bisa dilakukan sesuai kebutuhan.
Bagi tim yang sedang mengembangkan agent untuk laporan atau analisis data, prinsip desain Flint tetap bisa menjadi bahan pertimbangan untuk meninjau ulang format output agent, meski belum berencana menggunakannya.
Saat melakukan pengujian, Anda bisa menggunakan APIYI apiyi.com untuk mengakses beberapa model populer melalui satu antarmuka. Bandingkan hasilnya dengan serangkaian kebutuhan interaksi yang sama agar lebih cepat menemukan kombinasi model dan spesifikasi yang cocok untuk bisnis Anda.
📚 Referensi
- Microsoft Research Blog – Flint-interactive: Blog riset resmi Flint-interactive
- Tautan:
microsoft.com/en-us/research/blog/flint-interactive-a-language-for-creating-interactive-data-visualizations - Keterangan: Membahas peristiwa semantik, operasi pembaruan, mesin status Canvas, serta tiga cara penggunaan: MCP, Canvas, dan API pemrograman. Blog ini juga menyediakan panduan pengaturan MCP, kumpulan contoh interaktif, dan akses ke API pemrograman.
Penulis: Tim Teknis APIYI
Diskusi teknis: Kunjungi APIYI di apiyi.com untuk berbagi pengalaman praktis tentang integrasi agent dan berbagai model. Informasi selengkapnya tersedia di pusat dokumentasi docs.apiyi.com.
