Microsoft เปิดตัว Flint ภาษาสร้างภาพข้อมูลสำหรับ AI Agent

 (microsoft.github.io)
3 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Flint เป็นภาษากลางสำหรับการสร้างภาพข้อมูลที่ช่วยให้ AI Agent สร้างแผนภูมิที่สื่อความหมายได้จากสเปกสั้น ๆ ที่มนุษย์แก้ไขได้
  • คอมไพเลอร์จะตีความข้อมูล, semantic type, ประเภทแผนภูมิ และการเข้ารหัส แล้วเติมการตั้งค่าระดับต่ำอย่างสเกล แกน ระยะห่าง และเลย์เอาต์ให้โดยอัตโนมัติ
  • มีแผนภูมิ 46 ประเภทและตัวอย่างในแกลเลอรี 83 รายการ พร้อมรองรับการเรนเดอร์ด้วย Vega-Lite, ECharts และ Chart.js
  • ในสภาพแวดล้อม TypeScript / JavaScript สามารถติดตั้งผ่าน npm ได้ และในเวิร์กโฟลว์ของ Agent สามารถใช้ MCP server ได้
  • ซ่อนความแตกต่างของ API ระหว่างแบ็กเอนด์ไว้หลังอินเทอร์เฟซเดียว ทำให้จัดการการสลับ renderer หรือการเปลี่ยนการออกแบบแผนภูมิจากสเปกเดียวกันได้ง่ายขึ้น

ปัญหาที่ Flint ต้องการแก้

  • Flint เป็นโปรเจกต์ของ Microsoft Research ออกแบบมาเป็นภาษากลางสำหรับการสร้างภาพข้อมูลที่ช่วยให้ AI Agent สร้างแผนภูมิจากสเปกแผนภูมิที่เรียบง่ายและมนุษย์แก้ไขได้
  • สเปกประกอบด้วยข้อมูล, semantic type และสเปกแผนภูมิ
    • ตัวอย่างสเปกระบุ period เป็น YearMonth, totalUsers เป็น Quantity และ gameType กับ region เป็น Category
    • ใน Line Chart จะ bind region เข้ากับ column, period เข้ากับ x, totalUsers เข้ากับ y และ gameType เข้ากับ color เพื่อสร้างแผนภูมิเส้นผู้ใช้งานรายเดือนตามภูมิภาค
  • สามารถติดตั้งในสภาพแวดล้อม TypeScript / JavaScript ผ่าน npm ได้
  • ในเวิร์กโฟลว์ของ Agent สามารถใช้ MCP server ได้
  • ดูแผนภูมิ 46 ประเภทและตัวอย่าง 83 รายการได้ที่ gallery

วิธีเปลี่ยนสเปกให้เป็นแผนภูมิ

  • Flint เริ่มจากสเปกแบบย่อ แล้วสร้างสเปก native ของแบ็กเอนด์อย่าง Vega-Lite จากนั้นเติมรายละเอียดระดับต่ำที่จำเป็นเพื่อเรนเดอร์แผนภูมิ
  • semantic type แสดงความหมายของฟิลด์ข้อมูล
    • ตัวอย่างมีประเภทอย่าง Rank, YearMonth, Delta, Temperature
    • Flint ใช้ข้อมูลนี้ในการอนุมานการตั้งค่าแผนภูมิ เช่น การ parse, สเกล, แกน, การจัดรูปแบบ และชุดสี
    • ใน heatmap ที่แสดงจำนวนผู้ใช้ใหม่สุทธิแยกตามเกมและเดือน จะกำหนด parser ของค่าด้านเวลา, การจัดรูปแบบแกน, ชุดสีแบบ diverging และจุดกึ่งกลางโดยอิงจาก semantic type
  • การปรับเลย์เอาต์อัตโนมัติ อิงกับโมเดลเลย์เอาต์แบบยืดหยุ่นและหลักการ banking
    • คอมไพเลอร์จัดการขนาด ระยะห่าง และการจัดวางแบบไดนามิก เพื่อปรับให้แผนภูมิเข้ากับ canvas
    • เมื่อจำนวน grouped bar chart เพิ่มขึ้น จะขยาย canvas และลด band width เพื่อให้เวอร์ชันที่หนาแน่นขึ้นยังพอดีกับ canvas
  • การเปลี่ยนการออกแบบแผนภูมิทำได้ด้วยการสลับประเภทแผนภูมิและ rebind การเข้ารหัสเชิงภาพ
    • เมื่อต้องเปลี่ยน faceted bar chart ของการกระจายประชากรตามเพศและอายุจากสำมะโนประชากรสหรัฐฯ ปี 2000 ให้เป็น pyramid chart ผู้ใช้เพียงเปลี่ยนประเภทแผนภูมิ ส่วนที่เหลือคอมไพเลอร์จะจัดการให้

แบ็กเอนด์เรนเดอร์และสถานะการใช้งาน

  • Flint รองรับแผนภูมิ 46 ประเภทครอบคลุม Vega-Lite, ECharts, Chart.js
    • ซ่อน API และโมเดลการเขียนโปรแกรมที่แตกต่างกันไว้หลังอินเทอร์เฟซเดียว
    • เมื่อ Vega-Lite ไม่มี sunburst แบบ native ก็สามารถสลับไปใช้ ECharts ได้
    • สำหรับการสร้างภาพข้อมูลโครงสร้างลำดับชั้น ภูมิภาค × gameType × game มีการเสนอว่า sunburst chart เป็นทางเลือกที่ดีกว่า grouped bar chart
  • Flint เป็นโอเพนซอร์สและพร้อมใช้งานทันที
  • มี GitHub และตัวอย่างในแกลเลอรีเป็นจุดเริ่มต้น
  • Microsoft Research สร้าง Flint ร่วมกับ IDEAS Lab และ Renmin University of China

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • เข้าใจว่าทำไมการตลาดแบบ “สำหรับ AI agent” ถึงจำเป็น แต่แค่เป็นภาษาที่ทำให้การอธิบายแผนภูมิได้ง่ายขึ้นก็น่าประทับใจและมีประโยชน์มากพออยู่แล้ว

    • เรื่องนี้จะเน้นย้ำแค่ไหนก็ไม่พอ คำว่า “เหมาะกับ agent” ท้ายที่สุดแล้วหมายถึงมัน อธิบายตัวเองได้, มีการจัดการที่ชัดเจน, มีค่าเริ่มต้นที่ปลอดภัย, เอาต์พุตที่กระชับหรือควบคุมได้, และมีอินเทอร์เฟซที่ตั้งโปรแกรมได้ ซึ่งคุณสมบัติเหล่านี้ก็ช่วยมนุษย์ด้วยเหมือนกัน
    • ดูเหมือนว่านี่ก็แปลตรงตัวว่าเป็นสิ่งที่ทำให้ AI agent เข้าถึงผ่าน MCP server ไม่ใช่หรือ ถ้าอย่างนั้นการเน้น AI agent ในการตลาดก็ดูสำคัญพอสมควร
    • สรุปแบบนี้น่าจะถูกต้อง คำอธิบายหรู ๆ ท้ายที่สุดก็ดูเหมือนเป็นการพูดยาว ๆ ว่า “ดูข้อมูลแล้วตัดสินใจเองว่าแผนภูมิควรแสดงออกมาอย่างไร”
      ในหน้าดังกล่าวก็อธิบายว่า “แทนที่จะบังคับให้ต้องระบุพารามิเตอร์ระดับล่างที่ยืดยาวอย่าง scale, axis, spacing, layout ตัวคอมไพเลอร์ของ Flint จะอนุมานการตั้งค่าแผนภูมิที่เหมาะที่สุดจากข้อมูล, semantic type, chart type และ encoding”
    • ไม่ใช่แค่ให้ agent สร้างได้ง่าย แต่คนก็ แก้ไขได้ง่าย ด้วย โดยเฉพาะถ้ามี UI
    • ดูจากแพ็กเกจแล้ว มันถูกสร้างครอบอยู่บน ไลบรารีแผนภูมิ ที่มีอยู่เดิม

  • มีแพตเทิร์นใหม่กำลังเกิดขึ้นในระบบ agent และโปรเจ็กต์นี้เป็นตัวอย่างที่ดี
    คือมี การแทนค่ากลาง (IR) บางอย่างที่ LLM สร้างแล้วส่งต่อ จากนั้นค่อยมีชั้นที่เป็น deterministic อย่างคอมไพเลอร์หรือตัวสร้างโค้ดมาครอบอีกที คิดว่าในอนาคตอันใกล้เราจะเห็นโครงสร้างแบบนี้บ่อยขึ้น

    • ตอนที่เห็น Claude ไม่ได้สร้าง PPT deck เป็น XML ตรง ๆ แต่เขียน โค้ด Python เพื่อสร้างมันแทน ตอนนั้นเป็นช่วง “อ๋อ” เลย คิดว่างานจำนวนมากน่าจะไปในทิศทางนี้ และในระยะยาวมันอาจดูจำกัดนิด ๆ และเหมือนแฮ็ก แต่ในช่วงนี้ดูเป็นแนวทางที่ถูกต้อง 100%
    • เห็นด้วยกับไอเดียนี้เต็มที่ ในเดือนที่ผ่านมา งาน agent coding ที่ทำทั้งหมดก็ผ่าน การแทนค่ากลาง และการวนซ้ำก็เกิดขึ้นที่ชั้นนั้นเป็นหลัก น่าทึ่งที่วิธีนี้พาเข้าใกล้เอาต์พุตโค้ดแบบ deterministic ได้มากทีเดียว
    • ชั้นกลางที่ออกแบบมาดีทำให้สามารถ ตรวจสอบและควบคุม ได้โดยไม่ขึ้นกับ AI แบบนี้ความสัมพันธ์ระหว่างมนุษย์กับ AI ก็เปลี่ยนจากการมอบหมายงานเป็นการร่วมมือกัน
    • ใช่เลย ระบบ agent เป็นแพตเทิร์นแบบนี้มาตั้งแต่แรกอยู่แล้ว คือสร้างแบบหลวม ๆ ก่อน แล้วลองใหม่ซ้ำ ๆ จนกว่ารูปร่างและขนาดจะพอดีกับช่อง เมื่ออินพุตผ่านการตรวจสอบ
    • การเขียนโปรแกรมยังมีชีวิตชีวายิ่งกว่าที่เคย

  • แม้ในหน้าจะไม่ได้พูดถึง แต่การคำนึงถึง การเข้าถึง (accessibility) ตั้งแต่ขั้นออกแบบเวลาทำ data visualization นั้นสำคัญมากจริง ๆ
    พอดแคสต์นี้มีบทสัมภาษณ์สั้น ๆ ที่สรุปเรื่องนี้ไว้ดี: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    ผู้ให้สัมภาษณ์คือ Frank Elavsky ซึ่งดูจะเป็นที่รู้จักมากพอสมควรในวงการนี้ และยังสร้างโปรเจ็กต์ Chartability ที่รวม heuristic, หลักการ และแนวทางสำหรับการตรวจสอบด้าน accessibility ไว้ด้วย: https://chartability.github.io/POUR-CAF/

    • ดูเหมือนว่า Flint เองก็ควรมีงานรองรับ accessibility ด้วย และนี่เป็นจุดที่เหมาะสำหรับจัดการปัญหา accessibility แบบรวมศูนย์
      เพิ่ม issue สำหรับติดตามไว้แล้ว: https://github.com/microsoft/flint-chart/issues/48

  • สงสัยว่ามีคำอธิบายที่ชัดเจนไหมว่าอันนี้ดีกว่าหรือแตกต่างจาก Vega เองอย่างไร: https://vega.github.io/vega/docs/specification/
    Vega ก็เป็น DSL ที่มีพลังในการอธิบาย visualization อยู่แล้ว และก็น่าจะถูกใส่อยู่ในข้อมูลฝึกของ LLM อย่างกว้างขวางพอสมควร

    • เมื่อก่อน Vega อาจเป็นภาษาระดับสูงสำหรับมนุษย์ แต่ตอนนี้สำหรับ AI agent มันอาจจะค่อนข้าง ระดับล่าง ไปหน่อย ถ้า agent จะสร้างแผนภูมิที่ดูดีได้ ก็ต้องใช้พารามิเตอร์ระดับล่างจำนวนมาก ทำให้เขียนได้อย่างเสถียรยาก
      Flint เป็นนามธรรมระดับสูงกว่า ทำให้สเปกสั้นและเรียบง่ายกว่ามาก และให้คอมไพเลอร์อนุมานการตัดสินใจระดับล่างเพื่อสร้างแผนภูมิที่ดูดี กล่าวคือ ช่วยให้ agent สร้างแผนภูมิที่ดีด้วยโปรแกรมสั้น ๆ ได้ จากเดิมที่เคยต้องใช้โปรแกรมยาว
    • ผมเองก็สงสัยเหมือนกันว่าเทียบกับ Vega-Lite แล้วเป็นอย่างไร Vega-Lite ก็ถือว่าค่อนข้างระดับสูงและเป็นเชิงประกาศ และไวยากรณ์ก็ดูคล้าย Flint เหมือนกัน

  • ยังไม่ค่อยเห็นด้วยมากนักกับข้ออ้างที่ว่า “สเปกแผนภูมิแบบง่ายอาจเสถียร แต่คุณภาพของแผนภูมิที่สร้างออกมาต่ำเพราะพึ่งค่าเริ่มต้นของระบบ ขณะที่สเปกที่ซับซ้อนอาจทำให้ได้แผนภูมิที่ดูดี แต่ก็ยืดยาวจน agent จัดการอย่างเสถียรได้ยาก”
    จากประสบการณ์ทำงานเล็กน้อยในการสร้าง agent สำหรับงานวิเคราะห์ กลับน่าประทับใจว่า LLM สร้าง visualization ด้วย Python และ R ได้ดีพอสมควร แม้แต่โมเดลน้ำหนักเปิดขนาดเล็กก็ทำได้เหมือนกัน และถ้ามีจุดกำกวม การวนแก้เพิ่มอีกนิดก็มักลบข้อเสียพวกนั้นได้ เลยสงสัยว่ามีงานวิจัยที่รองรับข้ออ้างนี้หรือแสดงให้เห็นว่าปัญหาเกิดตรงไหนหรือไม่

    • สเปกที่ง่ายกว่าย่อมเปิดให้ agent ที่ง่ายกว่านำไปใช้ได้ บางทีกรณีใช้งานตรงนี้อาจไม่ใช่การให้โมเดลใหญ่ตัวเดียวสร้าง visualization ทีละอัน แต่เป็นการใช้ agent ขนาดเล็กและต้นทุนต่ำ หลายตัวแบบขนานมากกว่า
      โดยส่วนตัว Claude กับ ChatGPT สร้างโมเดล ggplot ได้ดี แต่พอมีการปรับแต่งเยอะ ๆ ก็เริ่มซับซ้อนขึ้นนิดหน่อย
    • ไม่ได้มองแค่เรื่องความสามารถในการอธิบายเท่านั้น แต่รวมถึง ความเสถียร และความสามารถในการโต้ตอบด้วย ถ้ากลุ่มเป้าหมายเป็นผู้ใช้ที่ไม่ใช่ผู้เชี่ยวชาญ หรือใช้โมเดลขนาดเล็ก สเปกที่เรียบง่ายแต่ยังมีพลังในการอธิบายก็จะช่วยได้

  • คำอธิบายที่ว่า “พารามิเตอร์ระดับล่างที่ยืดยาวอย่างสเกล แกน ระยะห่าง และเลย์เอาต์” ทำให้รู้สึกว่า Microsoft กำลังเอาสองเรื่องที่ต่างกันมาปนกัน
    LLM ไม่ได้ใส่ใจมากนักว่าโค้ดระดับล่างหรือยืดยาวหรือไม่ มันอ่านได้ดีแม้แต่ assembly หรือ SPIR-V ปัญหาที่แท้จริงคือ องค์ประกอบเชิงภาพ ต่างหาก LLM “มอง” ไม่เหมือนมนุษย์ จึงไม่ถนัดในการเข้าใจโครงสร้างเชิงพื้นที่ผ่านการเปรียบเทียบด้วยสายตา และถ้าจะอ้อมข้อจำกัดนี้ ก็ต้องให้ตัวแทนของภาพในรูปแบบที่ LLM ใช้เหตุผลและเข้าใจได้ง่าย เช่นการแสดงภาพในรูปโค้ด กล่าวคือ ขอแค่มันไม่ใช่โครงสร้างที่ซ้อนลึกหรือมีสถานะซ่อนอยู่จนต้องอนุมานก็พอ
    อีกอย่าง ผมไม่ค่อยเห็นด้วยกับการที่ Flint เลือกจัดการชนิดข้อมูลใน JSON โดยยึดคีย์สตริงเป็นหลัก พอดูสเปกจริงแล้ว รู้สึกว่ามันทำเป็น ไลบรารี TypeScript ที่คนเขียนใช้งานสะดวกกว่านี้ได้ และน่าจะดีกว่ามาก ภายหลังพอไปดูซอร์สจริงก็พบว่ามันสมบูรณ์และประณีตกว่าม็อกอัปที่เดาจากเอกสารอย่างมาก แต่ข้อไม่พอใจหลักเรื่อง “JSON แบบคีย์สตริง เทียบกับพื้นผิวการเขียนแบบ generic จริง ๆ” ก็ยังคงอยู่

    • ส่วน chartType ผมมองว่าไม่ค่อยสวยงามนัก เพราะเทมเพลตควรขยายต่อได้มากกว่านี้ ตรงนี้น่าจะแก้ไข
      แต่ส่วนอื่น ๆ การใช้ JSON ในไลบรารีด้าน visualization หรือ diagram ก็ถือว่าพบได้ค่อนข้างทั่วไป เพราะมันย้ายไปยังบริบทการเรนเดอร์ต่าง ๆ ได้ง่าย
    • เห็นด้วยว่า JSON ไม่ใช่ภาษาสำหรับสเปกที่ดีที่สุด แต่จะดีกว่าหรือไม่ถ้าเทียบกับการที่แต่ละโปรเจกต์เริ่มเขียนสเปกของตัวเองขึ้นมาใหม่ทั้งหมด ก็คงต้องคิดกันอีกที
      บทความที่เกี่ยวข้อง: https://www.openui.com/blog/stop-making-ai-write-json
    • น่าเสียดาย แต่ตอนนี้วิธีที่เสถียรที่สุดในการรับส่งข้อมูลหรือโค้ดกับ LLM ดูเหมือนจะยังผูกอยู่กับ JSON อย่างน้อยก็ยังดีกว่าเป็น YAML ที่แย่กว่า
      ผมสนใจ custom DSL ที่ช่วยเพิ่มความคาดเดาได้ของ LLM และก็ดีใจที่ดูเหมือนยักษ์ใหญ่อย่าง Microsoft จะเข้าใจเรื่องนี้ด้วย ตัวอย่าง Contacts ใน https://slangify.org/examples เป็นวิธีสร้าง DSL เองได้ง่าย ๆ โดยแปลงไปมาระหว่าง VCARD กับ JCARD

  • พออ่านคำอธิบายว่า “บังคับให้ต้องระบุการตัดสินใจเชิงภาพที่ควรเป็นหน้าที่ของคอมไพเลอร์ที่ดี” ก็อดคิดไม่ได้ว่า Graphviz ก็มีอยู่ด้วยเหตุผลเดียวกันไม่ใช่หรือ
    พอเห็นว่าใช้ JSON เป็นภาษาประกาศ ก็ยอมรับว่า LLM จัดการ JSON ได้ดี แต่ก็ไม่ใช่ไวยากรณ์ที่มนุษย์อ่านใช้งานได้สบาย

    • ที่จริงแล้ว JSON ในฐานะภาษากลางที่คนใช้ร่วมกันสำหรับงาน visualization นั้นมีมานานพอสมควรแล้ว ข้อดีของไวยากรณ์เชิงประกาศคือผู้ใช้สามารถจัดการสเปกได้อย่างมีประสิทธิภาพผ่าน UI แบบลากวางหรือคลิก
      Flint ถูกออกแบบมาโดยตั้งใจให้เอเจนต์ข้ามพารามิเตอร์ระดับล่างอย่างสเกล แกน เส้นฐานที่ 0 หรือขนาดขั้นไปได้ องค์ประกอบเหล่านี้สำคัญมากต่อการทำให้กราฟดูดี และคอมไพเลอร์จะปรับให้เหมาะสมแบบไดนามิก จึงทำให้ AI agent ใช้งานได้ง่ายขึ้น
    • ใช่ พูดตรง ๆ คือมันให้ความรู้สึกเหมือนตันตั้งแต่เปิดตัว และไม่ได้ดูดีกว่าสิ่งที่มีอยู่ก่อนแล้วเท่าไร

  • การเพิ่ม semantic types เป็นองค์ประกอบเพิ่มเติมของฟอร์แมตนั้นมีประโยชน์มาก เพราะช่วยเข้ารหัสรูปแบบสำเร็จรูปของฟอร์แมตจำนวนมากให้กระชับขึ้น
    อยากรู้ว่ามีแผนจะทำให้ Flint type registry แชร์กันได้หรือขยายต่อได้หรือไม่ และก็สงสัยด้วยว่าทำไมถึงไม่เก็บมันไว้เป็นคุณสมบัติของข้อมูลโดยตรง ผมเคยได้สเปกที่แทบเหมือนกันตอนทำ linked chart ระดับสูงกว่าบน Vega-Lite

  • ผมยังไม่ค่อยเข้าใจประเด็นของโปรเจกต์นี้เท่าไร ตั้งแต่ยุค GPT-3.5 ดูเหมือน LLM ก็สร้าง matplotlib ออกมาได้ในครั้งเดียวอยู่แล้ว
    ผมใช้ LLM กับ data visualization มาค่อนข้างมากและไม่ค่อยเจอปัญหา เลยอยากเห็นตัวอย่างว่าเอเจนต์ติดขัดตรงไหนในการสร้างภาพข้อมูล และ Flint แก้ปัญหานั้นอย่างไร

    • ตรงนี้มีปัญหาแบบ 20% สุดท้าย อยู่เล็กน้อย ถ้าคุยกับ GPT ในแชตแล้วคอยช่วยบอกทิศทางไปเรื่อย ๆ มันก็มักจะพอใช้ได้สำหรับผู้ใช้สาย power user
      แต่พอเอาไปใส่ในเครื่องมือสำหรับผู้ใช้ปลายทาง อัตราความสำเร็จ 80% ในการสร้างกราฟที่ดูดีจะเริ่มกลายเป็นปัญหาใหญ่ ผมเจอเรื่องนี้ตอนสร้างระบบวิเคราะห์ข้อมูล ถ้าให้มันสร้าง matplotlib หรือ Vega-Lite โดยตรง จะยากมากที่จะได้ทั้งความเสถียร ความสามารถในการแสดงผล ต้นทุนด้านเวลา และจำนวนโทเค็นพร้อมกัน เลยออกแบบภาษานี้เป็นทางประนีประนอม โดยย้ายการตัดสินใจบางส่วนไปไว้ที่คอมไพเลอร์ เพื่อลดต้นทุนการสร้างขณะยังรักษาความสามารถในการแสดงผลไว้

  • หน้าโปรเจกต์: https://microsoft.github.io/flint-chart/
    การตั้งค่า MCP: https://microsoft.github.io/flint-chart/#/mcp