Microsoft công bố Flint, ngôn ngữ trực quan hóa dành cho AI agent

 (microsoft.github.io)
3 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Flint là một ngôn ngữ trung gian cho trực quan hóa giúp AI agent tạo các biểu đồ giàu khả năng biểu đạt từ những đặc tả ngắn gọn mà con người có thể chỉnh sửa
  • Trình biên dịch diễn giải dữ liệu, kiểu ngữ nghĩa, loại biểu đồ và mã hóa, rồi tự động điền các thiết lập cấp thấp như thang đo, trục, khoảng cách và bố cục
  • Cung cấp 46 loại biểu đồ và 83 ví dụ trong thư viện, đồng thời hỗ trợ kết xuất bằng Vega-Lite, ECharts và Chart.js
  • Trong môi trường TypeScript / JavaScript có thể cài đặt bằng npm, còn trong workflow của agent có thể dùng máy chủ MCP
  • Ẩn khác biệt API giữa các backend phía sau một giao diện thống nhất, giúp dễ xử lý hơn việc chuyển renderer hoặc thay đổi thiết kế biểu đồ từ cùng một đặc tả

Vấn đề Flint muốn giải quyết

  • Flint là một dự án của Microsoft Research, được thiết kế như một ngôn ngữ trung gian cho trực quan hóa để AI agent tạo biểu đồ từ các đặc tả biểu đồ đơn giản, con người có thể chỉnh sửa
  • Đặc tả gồm dữ liệu, kiểu ngữ nghĩa và đặc tả biểu đồ
    • Đặc tả ví dụ chỉ định period là YearMonth, totalUsers là Quantity, còn gameType và region là Category
    • Trong Line Chart, liên kết region với column, period với x, totalUsers với y và gameType với color để tạo biểu đồ đường người dùng hoạt động hằng tháng theo từng khu vực
  • Có thể cài đặt trong môi trường TypeScript / JavaScript bằng npm
  • Trong workflow của agent có thể dùng máy chủ MCP
  • Có thể xem 46 loại biểu đồ và 83 ví dụ trong gallery

Cách biến đặc tả thành biểu đồ

  • Flint bắt đầu từ đặc tả được nén, tạo đặc tả native cho backend như Vega-Lite, rồi điền các chi tiết cấp thấp cần thiết để kết xuất biểu đồ
  • Kiểu ngữ nghĩa biểu thị ý nghĩa của các trường dữ liệu
    • Ví dụ bao gồm các kiểu như Rank, YearMonth, Delta, Temperature
    • Dựa trên đó, Flint suy luận các thiết lập biểu đồ như parsing, thang đo, trục, định dạng và bảng màu
    • Trong heatmap hiển thị số người dùng mới ròng theo game và tháng, trình phân tích giá trị thời gian, định dạng trục, bảng màu phân kỳ và điểm giữa được quyết định dựa trên kiểu ngữ nghĩa
  • Tối ưu hóa bố cục tự động dựa trên mô hình bố cục co giãn và nguyên tắc banking
    • Trình biên dịch quản lý động kích thước, khoảng cách và sắp xếp để điều chỉnh biểu đồ vừa với canvas
    • Khi số lượng grouped bar chart tăng lên, Flint mở rộng canvas và giảm band width để cả phiên bản dày đặc cũng vừa với canvas
  • Thay đổi thiết kế biểu đồ có thể được xử lý bằng cách chuyển loại biểu đồ và liên kết lại mã hóa thị giác
    • Khi đổi faceted bar chart về phân bố dân số theo giới tính và độ tuổi trong Điều tra dân số Mỹ năm 2000 thành pyramid chart, người dùng chỉ cần đổi loại biểu đồ, phần còn lại do trình biên dịch xử lý

Backend kết xuất và trạng thái sẵn dùng

  • Flint hỗ trợ 46 loại biểu đồ trên Vega-Lite, ECharts, Chart.js
    • Ẩn các API và mô hình lập trình khác nhau phía sau một giao diện thống nhất
    • Khi Vega-Lite không có sunburst native, có thể chuyển sang ECharts
    • Với trực quan hóa cấu trúc phân cấp khu vực × gameType × game, sunburst chart được đề xuất là phương án thay thế tốt hơn grouped bar chart
  • Flint là mã nguồn mở và có thể dùng ngay
  • GitHub và các ví dụ trong gallery được cung cấp làm điểm bắt đầu
  • Microsoft Research xây dựng Flint với sự hợp tác của IDEAS Lab và Renmin University of China

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Tôi hiểu vì sao cần kiểu marketing “dành cho AI agent”, nhưng rốt cuộc chỉ riêng việc đây là một ngôn ngữ giúp biểu diễn biểu đồ dễ dàng cũng đã đủ ấn tượng và hữu ích rồi

    • Điều này nhấn mạnh bao nhiêu cũng không thừa. “Tốt cho agent” rốt cuộc có nghĩa là tự mô tả, có cảm giác thao tác rõ ràng, có mặc định an toàn, đầu ra ngắn gọn hoặc có thể kiểm soát, và có giao diện lập trình được; những đặc tính này cũng hữu ích cho con người
    • Tôi nghĩ đây chẳng phải đúng là thứ được tạo ra để AI agent truy cập thông qua MCP server sao. Nếu vậy thì việc nhấn mạnh AI agent trong marketing có vẻ khá quan trọng
    • Tóm tắt như vậy có vẻ đúng. Những mô tả hoa mỹ cuối cùng có vẻ chỉ là cách nói dài dòng rằng “xem dữ liệu rồi tự quyết định biểu đồ nên trông như thế nào”
      Trên trang cũng giải thích rằng “thay vì yêu cầu các tham số cấp thấp dài dòng như scale, trục, khoảng cách, layout, trình biên dịch Flint suy ra cấu hình biểu đồ được tối ưu từ dữ liệu, kiểu ngữ nghĩa, kiểu biểu đồ và encoding”
    • Không chỉ dễ để agent tạo ra, mà với con người, đặc biệt nếu có UI, đây cũng là dạng dễ chỉnh sửa
    • Nhìn vào package thì có vẻ nó được xây dựng trên các thư viện biểu đồ hiện có

  • Một mẫu hình mới đang xuất hiện trong các hệ thống agent, và dự án này là một ví dụ hay
    Đó là cách đặt một biểu diễn trung gian (IR) nào đó do LLM tạo ra và chuyển tiếp, rồi đặt lên trên nó một lớp quyết định luận như compiler hoặc code generator. Tôi nghĩ trong tương lai gần ta sẽ thấy cấu trúc như vậy thường xuyên hơn

    • Lần đầu thấy Claude không trực tiếp tạo deck PPT bằng XML mà viết mã Python để tạo ra nó, tôi đã có một khoảnh khắc khá “à ha”. Tôi nghĩ nhiều tác vụ sẽ đi theo con đường này; về dài hạn thì nó có vẻ hơi hạn chế và như một cách hack, nhưng trong lúc này thì có vẻ là hướng tiếp cận đúng 100%
    • Tôi hoàn toàn đồng ý với ý tưởng này. Trong một tháng qua, mọi tác vụ coding agent của tôi đều được thực hiện thông qua biểu diễn trung gian, và việc lặp cũng chủ yếu diễn ra ở tầng đó. Thật đáng ngạc nhiên là bằng cách này có thể tiến khá gần tới đầu ra mã mang tính quyết định
    • Một tầng trung gian được thiết kế tốt cho phép xác minh và kiểm soát độc lập với AI. Như vậy tương tác giữa con người và AI sẽ chuyển từ ủy nhiệm sang cộng tác
    • Đúng vậy. Hệ thống agent ngay từ đầu đã theo mẫu hình này. Tạo một cách lỏng lẻo, rồi liên tục thử lại cho đến khi đầu vào được xác minh và có hình dạng, kích thước khớp với lỗ cần lấp
    • Lập trình vẫn sống động hơn bao giờ hết

  • Trang này không nói tới, nhưng khi tạo trực quan hóa dữ liệu, việc đưa khả năng tiếp cận vào ngay từ giai đoạn thiết kế là cực kỳ quan trọng
    Podcast này có một cuộc phỏng vấn ngắn liên quan được tóm tắt tốt: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    Người được phỏng vấn là Frank Elavsky, có vẻ khá nổi tiếng trong lĩnh vực này, và anh ấy cũng tạo ra dự án Chartability, bao gồm các heuristic, nguyên tắc và hướng dẫn để audit khả năng tiếp cận: https://chartability.github.io/POUR-CAF/

    • Tôi nghĩ Flint cũng sẽ cần làm phần hỗ trợ khả năng tiếp cận, và đây là điểm rất phù hợp để xử lý tập trung các vấn đề về accessibility
      Tôi đã thêm issue để theo dõi: https://github.com/microsoft/flint-chart/issues/48

  • Tôi tò mò liệu có giải thích cụ thể nào về việc nó tốt hơn hoặc khác Vega bản thân nó như thế nào không: https://vega.github.io/vega/docs/specification/
    Vega vốn đã là một DSL giàu khả năng biểu đạt cho trực quan hóa, và có lẽ cũng được đưa khá rộng rãi vào dữ liệu huấn luyện của LLM

    • Trước đây Vega là ngôn ngữ cấp cao đối với con người, nhưng bây giờ đối với AI agent thì ngược lại có thể hơi cấp thấp. Để agent tạo ra biểu đồ đẹp, phải dùng nhiều tham số cấp thấp, và kết quả là khó viết một cách ổn định
      Flint là một mức trừu tượng cao hơn, nên đặc tả ngắn và đơn giản hơn nhiều, còn compiler suy ra các quyết định cấp thấp để tạo biểu đồ đẹp. Nói cách khác, nó cho phép agent tạo ra biểu đồ tốt, vốn trước đây cần chương trình dài, bằng một chương trình ngắn
    • Tôi cũng tò mò nếu so với Vega-Lite thì thế nào. Vega-Lite cũng tương đối cấp cao và khai báo, cú pháp trông cũng giống Flint

  • Tôi không thực sự đồng cảm lắm với lập luận rằng “đặc tả biểu đồ đơn giản có thể ổn định nhưng phụ thuộc vào mặc định của hệ thống nên chất lượng biểu đồ tạo ra thấp, còn đặc tả phức tạp có thể tạo biểu đồ đẹp nhưng dài dòng nên agent khó xử lý ổn định”
    Từ một số ít kinh nghiệm làm agent phân tích, điều khiến tôi ấn tượng là LLM tạo trực quan hóa bằng Python và R khá tốt. Các mô hình trọng số mở nhỏ cũng vậy, và nhiều khi chỉ cần lặp lại để tinh chỉnh một chút các phần mơ hồ là nhược điểm biến mất. Tôi tò mò liệu có dòng nghiên cứu nào ủng hộ lập luận này hoặc chỉ ra những điểm dễ phát sinh vấn đề không

    • Đặc tả đơn giản hơn thì agent đơn giản hơn có thể dùng được. Có lẽ mục đích ở đây là để các agent nhỏ và rẻ dùng song song, thay vì một mô hình lớn tạo từng trực quan hóa một
      Cá nhân tôi thấy Claude và ChatGPT tạo mô hình ggplot tốt, nhưng khi có nhiều tùy biến thì hơi phức tạp hơn
    • Không chỉ xét khả năng biểu đạt, họ còn cân nhắc cả độ ổn định và tính tương tác. Khi nhắm tới người dùng không phải chuyên gia hoặc dùng mô hình nhỏ, một đặc tả vừa giàu khả năng biểu đạt vừa đơn giản sẽ hữu ích

  • Mô tả “các tham số cấp thấp dài dòng như tỉ lệ, trục, khoảng cách, bố cục” có vẻ như Microsoft đang trộn lẫn hai thứ khác nhau
    LLM không thật sự quá bận tâm việc bản thân mã là cấp thấp hay dài dòng; chúng cũng có thể đọc tốt assembly hay SPIR-V. Vấn đề thật sự là cấu trúc thị giác. Vì LLM “nhìn” khác con người, việc hiểu cấu trúc không gian thông qua so sánh thị giác không tự nhiên; để đi đường vòng thì cần cung cấp một biểu diễn dễ để LLM suy luận và hiểu, như trực quan hóa dưới dạng mã. Nói cách khác, miễn là đó không phải một cấu trúc lồng sâu hoặc phải suy luận trạng thái ẩn là được
    Ngoài ra, khó đồng ý với quyết định của Flint khi xử lý kiểu trong JSON xoay quanh khóa chuỗi. Nhìn vào đặc tả thực tế, họ hoàn toàn có thể làm nó thành một thư viện TypeScript dễ dùng cho con người, và có lẽ như vậy sẽ tốt hơn nhiều. Sau này khi thật sự xem mã nguồn, nó hoàn thiện và tinh vi hơn nhiều so với bản mockup tôi từng giả định chỉ dựa trên tài liệu, nhưng bất mãn cốt lõi về “JSON khóa chuỗi so với bề mặt viết generic thật sự” vẫn còn

    • Phần chartType thì tôi thấy không thanh lịch lắm vì template cần mở rộng được hơn. Phần này cần sửa
      Ở các phần khác, việc dùng JSON trong thư viện trực quan hóa hoặc biểu đồ là khá phổ biến, vì có thể dễ dàng chuyển sang các ngữ cảnh render khác nhau
    • Tôi đồng ý JSON không phải ngôn ngữ đặc tả tối ưu, nhưng cũng đáng cân nhắc liệu nó có tốt hơn việc mỗi dự án lại bắt đầu viết một đặc tả riêng hay không
      Bài liên quan: https://www.openui.com/blog/stop-making-ai-write-json
    • Đáng tiếc là với LLM, có vẻ chúng ta đang bị trói vào JSON như cách ổn định nhất để đưa dữ liệu hoặc mã vào/ra. Cũng có thể tệ hơn là YAML
      Tôi quan tâm đến các DSL tùy chỉnh giúp tăng tính dự đoán được của LLM, và vui vì có vẻ một gã khổng lồ như Microsoft cũng hiểu điều này. Ví dụ Contacts ở https://slangify.org/examples là cách dễ dàng tự tạo DSL trong khi chuyển đổi qua lại giữa VCARD và JCARD

  • Nhìn mô tả “bắt phải nêu tường minh các quyết định thị giác mà một compiler tốt nên xử lý”, tôi tự hỏi chẳng phải Graphviz tồn tại vì cùng lý do đó sao
    Thấy họ dùng JSON làm ngôn ngữ khai báo; dù công nhận LLM xử lý JSON tốt, đây không phải cú pháp dễ tiêu thụ cho con người

    • Thực ra JSON với tư cách ngôn ngữ chung cho con người trong trực quan hóa đã tồn tại từ khá lâu rồi. Ưu điểm của cú pháp khai báo là người dùng có thể thao tác đặc tả một cách hiệu quả trong UI bằng kéo-thả hoặc nhấp chuột
      Flint được thiết kế có chủ đích để agent bỏ qua các tham số cấp thấp như tỉ lệ, trục, mốc 0, kích thước bước. Những yếu tố này rất quan trọng để có biểu đồ đẹp, và compiler sẽ tối ưu động. Vì vậy AI agent có thể xử lý dễ hơn
    • Đúng. Thành thật mà nói, cái này có cảm giác đã bị kẹt ngay khi ra mắt, và cũng không đặc biệt tốt hơn những thứ đã có

  • Việc dùng kiểu ngữ nghĩa như một yếu tố định dạng bổ sung rất hữu ích, vì nó mã hóa gọn rất nhiều boilerplate định dạng
    Tôi tò mò liệu có kế hoạch chia sẻ registry kiểu của Flint hoặc làm nó có thể mở rộng không. Tôi cũng tò mò vì sao không đặt hẳn nó làm thuộc tính dữ liệu. Khi tạo các biểu đồ liên kết cấp cao hơn trên Vega-Lite, tôi gần như đã đi đến cùng một đặc tả

  • Tôi không rõ trọng tâm của dự án này là gì. Từ thời GPT-3.5, có vẻ LLM đã có thể tạo ra matplotlib trong một lần
    Tôi đã dùng LLM khá nhiều cho trực quan hóa dữ liệu nhưng không gặp vấn đề gì đáng kể. Tôi muốn xem ví dụ cụ thể agent gặp khó ở đâu trong việc tạo trực quan hóa, và Flint giải quyết chuyện đó như thế nào

    • Ở đây có một chút vấn đề 20% cuối cùng. Nếu trò chuyện với GPT trong cửa sổ chat và liên tục định hướng, thì với power user nhìn chung là ổn
      Nhưng khi đưa vào công cụ dành cho người dùng cuối, tỉ lệ thành công 80% trong việc tạo biểu đồ đẹp bắt đầu trở thành vấn đề lớn. Tôi đã gặp chuyện này khi xây dựng hệ thống phân tích dữ liệu. Nếu để nó trực tiếp tạo matplotlib hoặc Vega-Lite thì khó đạt đồng thời độ ổn định, sức biểu đạt, chi phí thời gian và token; vì vậy ngôn ngữ này được thiết kế như một thỏa hiệp: chuyển một số quyết định sang compiler để giảm chi phí tạo, đồng thời vẫn giữ sức biểu đạt

  • Trang dự án: https://microsoft.github.io/flint-chart/
    Cấu hình MCP: https://microsoft.github.io/flint-chart/#/mcp