Microsoft ने AI एजेंट्स के लिए visualization language Flint जारी की

 (microsoft.github.io)
3 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Flint एक visualization intermediate language है, जो AI एजेंट्स को इंसानों द्वारा edit की जा सकने वाली छोटी specifications से expressive charts बनाने में मदद करती है
  • compiler data, semantic types, chart types और encodings को interpret करके scale, axis, spacing और layout जैसी low-level settings अपने-आप भर देता है
  • यह 46 chart types और 83 gallery examples देता है, और Vega-Lite, ECharts, Chart.js rendering को support करता है
  • TypeScript / JavaScript environment में इसे npm से install किया जा सकता है, और agent workflows में MCP server इस्तेमाल किया जा सकता है
  • backend-specific API differences को एक unified interface के पीछे छिपाकर, एक ही specification से renderer switch करना या chart design बदलना आसान बनाता है

Flint जिस समस्या को हल करना चाहता है

  • Flint Microsoft Research का project है, जिसे AI agents के लिए simple और human-editable chart specifications से charts generate करने के लिए design किया गया है
  • specification data, semantic types और chart specification से मिलकर बनती है
    • example specification में period को YearMonth, totalUsers को Quantity, और gameType व region को Category के रूप में specify किया जाता है
    • Line Chart में region को column, period को x, totalUsers को y, और gameType को color से bind करके region-wise monthly active users line chart बनाया जाता है
  • npm के जरिए TypeScript / JavaScript environment में install किया जा सकता है
  • agent workflows में MCP server इस्तेमाल किया जा सकता है
  • gallery में 46 chart types और 83 examples देखे जा सकते हैं

specification को chart में बदलने का तरीका

  • Flint compressed specification से शुरू करके Vega-Lite जैसे backend-native specifications generate करता है, और जरूरी low-level details भरकर chart render करता है
  • semantic types data fields के meaning को express करते हैं
    • examples में Rank, YearMonth, Delta, Temperature जैसे types शामिल हैं
    • Flint इनके आधार पर parsing, scale, axis, formatting और color scheme जैसी chart settings infer करता है
    • games और months के हिसाब से net new users दिखाने वाले heatmap में time value parser, axis formatting, diverging color scheme और midpoint semantic types के आधार पर तय किए जाते हैं
  • automatic layout optimization elastic layout model और banking principle पर आधारित है
    • compiler size, spacing और arrangement को dynamically manage करके chart को canvas में fit होने लायक adjust करता है
    • grouped bar charts की संख्या बढ़ने पर यह canvas को बड़ा करता है और band width घटाता है, ताकि dense version भी canvas में fit हो सके
  • chart design changes को chart type switching और visual encoding rebinding से handle किया जा सकता है
    • 2000 की US Census के gender और age-wise population distribution वाले faceted bar chart को pyramid chart में बदलते समय, user सिर्फ chart type बदलता है और बाकी compiler संभालता है

rendering backends और उपलब्धता की स्थिति

  • Flint Vega-Lite, ECharts, Chart.js में 46 chart types support करता है
    • यह अलग-अलग APIs और programming models को unified interface के पीछे छिपाता है
    • जब Vega-Lite में native sunburst न हो, तो ECharts पर switch किया जा सकता है
    • region × gameType × game hierarchy visualization के लिए grouped bar chart की तुलना में sunburst chart को बेहतर विकल्प के रूप में पेश किया गया है
  • Flint open source है और तुरंत इस्तेमाल किया जा सकता है
  • शुरुआत के लिए GitHub और gallery examples उपलब्ध हैं
  • Microsoft Research ने IDEAS Lab और Renmin University of China के साथ मिलकर Flint बनाया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • “AI agents के लिए” वाली marketing क्यों ज़रूरी है, यह समझ आता है, लेकिन आखिरकार यह सिर्फ़ charts को व्यक्त करना आसान बनाने वाली भाषा है—इतना ही इसे काफ़ी प्रभावशाली और उपयोगी बनाता है

    • इस बात पर जितना ज़ोर दिया जाए कम है। “agents के लिए अच्छा है” का मतलब आखिरकार यह है कि यह self-descriptive है, इसे manipulate करना स्पष्ट है, इसमें सुरक्षित defaults हैं, output concise या controllable है, और programmable interface है—और ये खूबियां इंसानों के लिए भी मददगार हैं
    • लगता है कि इसे सचमुच MCP server के ज़रिए AI agents की access के लिए बनाया गया है। अगर ऐसा है, तो marketing में AI agents पर ज़ोर देना काफ़ी महत्वपूर्ण लगता है
    • इसे ऐसे summarize करना सही लगता है। चमकदार説明 आखिरकार “data को देखकर chart कैसा दिखना चाहिए, यह खुद तय करता है” कहने का लंबा तरीका लगता है
      पेज पर भी लिखा है कि “scale, axis, spacing, layout जैसे verbose low-level parameters मांगने के बजाय, Flint compiler data, semantic types, chart types और encodings से optimized chart configuration निकालता है”
    • agents के लिए generate करना आसान है, लेकिन इंसानों के लिए भी, खासकर UI हो तो, यह edit करने में आसान format है
    • package को देखें तो यह मौजूदा chart libraries के ऊपर बना हुआ दिखता है

  • agent systems में एक नया pattern उभर रहा है, और यह project उसका अच्छा example है
    तरीका यह है कि LLM द्वारा generate करके पास की जाने वाली किसी intermediate representation (IR) को रखा जाए, और उसके ऊपर compiler या code generator जैसी deterministic layer लगाई जाए। निकट भविष्य में ऐसी संरचना ज़्यादा देखने को मिलेगी लगता है

    • जब पहली बार देखा कि Claude PPT deck को सीधे XML में नहीं बनाता, बल्कि उसे generate करने के लिए Python code लिखता है, तो काफ़ी “aha” moment था। लगता है कई tasks इसी रास्ते पर जाएंगे, और long term में यह थोड़ा सीमित और hack जैसा महसूस हो सकता है, लेकिन फिलहाल यह 100% सही approach लगता है
    • इस idea से पूरी तरह सहमत हूं। पिछले एक महीने में किया गया एक agent coding task पूरा intermediate representation के ज़रिए चला, और iterations भी मुख्यतः उसी layer पर हुए। हैरानी होती है कि इस तरीके से deterministic code output के काफ़ी करीब पहुंचा जा सकता है
    • अच्छी तरह design की गई intermediate layer AI से स्वतंत्र रूप से validation और control संभव बनाती है। इससे इंसान और AI की interaction delegation से collaboration में बदल जाती है
    • सही है। agent systems शुरुआत से ही इसी pattern पर रहे हैं। loosely generate करना, फिर input validate होने तक, छेद में फिट होने वाली shape और size मिलने तक बार-बार retry करना
    • programming पहले से कहीं ज़्यादा ज़िंदा है

  • पेज पर नहीं है, लेकिन data visualization बनाते समय accessibility को design stage में शामिल करना सच में महत्वपूर्ण है
    इस podcast में इससे जुड़ा छोटा interview अच्छी तरह summarize किया गया है: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    interviewee Frank Elavsky हैं, जो इस field में काफ़ी प्रसिद्ध लगते हैं, और उन्होंने accessibility audit के लिए heuristics, principles और guidelines वाला Chartability project भी बनाया है: https://chartability.github.io/POUR-CAF/

    • लगता है Flint में भी accessibility support पर काम की ज़रूरत होगी, और accessibility issues को centrally handle करने के लिए यह अच्छी जगह है
      tracking के लिए issue add किया है: https://github.com/microsoft/flint-chart/issues/48

  • उत्सुक हूं कि क्या कोई ठोस explanation है कि यह Vega से कैसे बेहतर या अलग है: https://vega.github.io/vega/docs/specification/
    Vega पहले से ही visualization के लिए expressive DSL है, और लगता है LLM training data में भी काफ़ी व्यापक रूप से शामिल होगा

    • पहले Vega इंसानों के लिए high-level language था, लेकिन अब AI agents के लिए शायद उल्टा थोड़ा low-level हो सकता है। agent को अच्छा दिखने वाला chart बनाने के लिए बहुत सारे low-level parameters लिखने पड़ते हैं, और नतीजतन उसे reliably लिखना मुश्किल हो जाता है
      Flint higher-level abstraction है, इसलिए spec कहीं ज़्यादा छोटी और सरल है, और compiler low-level decisions निकालकर अच्छा दिखने वाला chart बनवाता है। यानी जिन अच्छे charts के लिए पहले लंबा program चाहिए था, उन्हें agent छोटे program से बना सकता है
    • मुझे भी Vega-Lite से comparison को लेकर curiosity थी। Vega-Lite भी relatively high-level और declarative है, और syntax भी Flint जैसा दिखता है

  • “सरल chart specs stable हो सकते हैं, लेकिन system defaults पर निर्भर होने से generated charts की quality कम होती है; complex specs अच्छे दिखने वाले charts बना सकते हैं, लेकिन वे verbose होते हैं, इसलिए agents के लिए उन्हें reliably handle करना मुश्किल है”—इस दावे से बहुत ज़्यादा सहमत नहीं हूं
    analysis agents बनाने के थोड़े-से work experience में यह प्रभावशाली लगा कि LLMs Python और R में visualizations काफ़ी अच्छी तरह बनाते हैं। छोटे open-weight models भी ऐसे ही थे, और ambiguous हिस्सों को थोड़ा iterate करके refine करने पर अक्सर कमियां खत्म हो जाती थीं। सोच रहा हूं कि क्या इस दावे को support करने वाली, या problem points दिखाने वाली कोई research line है

    • सरल spec का इस्तेमाल सरल agents कर सकते हैं। शायद यहां use case यह हो सकता है कि एक बड़ा model एक-एक करके visualizations बनाने के बजाय, छोटे और सस्ते agents parallel में इस्तेमाल किए जाएं
      निजी तौर पर Claude और ChatGPT ggplot models अच्छे generate करते हैं, लेकिन customization बढ़ने पर चीज़ें थोड़ी complex हो जाती हैं
    • expressiveness के साथ-साथ stability और interactivity को भी ध्यान में रखा जा रहा है। non-expert users को target करते समय, या छोटे models इस्तेमाल करते समय, expressive होने के साथ सरल spec मददगार होता है

  • “स्केल, axis, interval, layout जैसे लंबे-चौड़े low-level parameters” वाला वर्णन देखकर लगता है कि Microsoft दो अलग-अलग चीज़ों को मिला रहा है
    LLM इस बात की ज़्यादा परवाह नहीं करता कि code low-level और verbose है या नहीं; वह assembly या SPIR-V भी अच्छी तरह पढ़ सकता है। असली समस्या visual composition है। LLM इंसानों से अलग तरीके से “देखता” है, इसलिए visual comparison के ज़रिए spatial composition समझना उसके लिए स्वाभाविक नहीं है, और इसे bypass करने के लिए code के रूप में visualization जैसी ऐसी representation देनी होगी जिसे LLM आसानी से reason और समझ सके। यानी बस structure ऐसा न हो जो बहुत deeply nested हो या जिसमें hidden state infer करना पड़े
    साथ ही Flint का JSON में string keys के इर्द-गिर्द types संभालने का फैसला भी मानना मुश्किल है। असली spec देखें तो इसे सीधे इंसानों के लिए लिखने में आसान TypeScript library भी बनाया जा सकता था, और शायद वह कहीं बेहतर होता। बाद में source असल में देखने पर यह सिर्फ docs देखकर बनाए गए मेरे assumed mockup से कहीं ज़्यादा complete और sophisticated निकला, लेकिन “string-key JSON बनाम असली generic authoring surface” वाली core शिकायत अब भी बनी हुई है

    • chartType वाला हिस्सा मुझे उतना elegant नहीं लगता, क्योंकि templates को और extensible होना चाहिए। इस हिस्से में सुधार चाहिए
      बाकी हिस्सों में visualization या diagram libraries में JSON इस्तेमाल करना काफी आम है, क्योंकि इसे अलग-अलग rendering contexts में आसानी से ले जाया जा सकता है
    • मैं सहमत हूँ कि JSON सबसे अच्छा spec language नहीं है, लेकिन यह भी सोचने वाली बात है कि क्या यह हर project के अपनी-अपनी नई spec लिखना शुरू करने से बेहतर है
      संबंधित लेख: https://www.openui.com/blog/stop-making-ai-write-json
    • अफसोस, लेकिन LLM में data या code को डालने-निकालने का सबसे भरोसेमंद तरीका अभी JSON से बंधा हुआ लगता है। इससे भी बुरा YAML हो सकता था
      LLM predictability बढ़ाने वाले custom DSL में मेरी रुचि है, और अच्छा लगा कि Microsoft जैसा दिग्गज भी इसे समझता दिख रहा है। https://slangify.org/examples में Contacts example VCARD और JCARD के बीच round-trip conversion करते हुए अपना DSL आसानी से बनाने का तरीका दिखाता है

  • “यह ऐसे visual decisions को explicit करवाता है जिन्हें एक अच्छे compiler को handle करना चाहिए” वाला वर्णन देखकर लगता है कि क्या Graphviz भी इसी वजह से नहीं है
    Declarative language के रूप में JSON का इस्तेमाल देखकर, यह मान भी लें कि LLM JSON अच्छे से handle करते हैं, फिर भी यह इंसानों के consume करने के लिए अच्छी syntax नहीं है

    • दरअसल visualization में इंसानों द्वारा इस्तेमाल की जाने वाली common language के रूप में JSON काफी पहले से मौजूद है। Declarative syntax का फायदा यह है कि user UI में drag-and-drop या clicks के ज़रिए spec को प्रभावी ढंग से manipulate कर सकता है
      Flint को जानबूझकर इस तरह design किया गया है कि agent scale, axis, zero baseline, step size जैसे low-level parameters को skip कर सके। अच्छे दिखने वाले charts के लिए ये elements बहुत महत्वपूर्ण होते हैं, और compiler इन्हें dynamically optimize करता है। इसलिए AI agent के लिए इसे handle करना आसान हो जाता है
    • सही है। सच कहूँ तो यह launch होते ही blocked-सा लगता है, और पहले से मौजूद चीज़ों से खास बेहतर नहीं है

  • semantic types को additional formatting element के रूप में इस्तेमाल करना बहुत उपयोगी है, क्योंकि यह बहुत सारे formatting boilerplate को compact तरीके से encode कर देता है
    जानना चाहूँगा कि क्या Flint type registry को share करने या extensible बनाने की कोई योजना है। यह भी उत्सुकता है कि इसे सीधे data attribute के रूप में क्यों नहीं रखा गया। Vega-Lite के ऊपर higher-level connected charts बनाते समय मैं लगभग इसी तरह की spec तक पहुँचा था

  • इस project का point मुझे ठीक से समझ नहीं आ रहा। GPT-3.5 के समय से ही LLM matplotlib को एक ही बार में generate कर सकते थे, ऐसा लगता है
    मैंने data visualization के लिए LLM का काफी इस्तेमाल किया है, लेकिन कोई खास समस्या नहीं आई। जानना चाहूँगा कि agent को visualization generation में specifically कहाँ दिक्कत आती है, और Flint उसे कैसे solve करता है

    • यहाँ थोड़ा last 20% problem है। Chat window में GPT से बात करते हुए अगर आप लगातार दिशा देते रहें, तो power users के लिए यह कुल मिलाकर ठीक रहता है
      लेकिन इसे end users के लिए किसी tool में डालें, तो अच्छे दिखने वाले charts generate करने की 80% success rate बड़ी समस्या बनने लगती है। Data analysis system बनाते समय मैंने यह अनुभव किया। matplotlib या Vega-Lite को सीधे generate करवाने पर reliability, expressiveness, cost time और tokens—इन सबको साथ हासिल करना मुश्किल होता है, इसलिए इस language को इस trade-off के रूप में design किया गया कि कुछ decisions compiler पर shift कर दिए जाएँ, ताकि generation cost घटे और expressiveness बनी रहे

  • Project page: https://microsoft.github.io/flint-chart/
    MCP setup: https://microsoft.github.io/flint-chart/#/mcp