Microsoft、AIエージェント向けの可視化言語 Flint を公開

 (microsoft.github.io)
3 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Flint は、AIエージェントが人間が編集可能な短い仕様で表現力の高いチャートを作成できるよう支援する 可視化中間言語 である
  • コンパイラがデータと セマンティック型、チャート種別、エンコーディングを解釈し、スケール・軸・間隔・レイアウトといった低レベル設定を自動で補完する
  • 46種類のチャートタイプ と 83 のギャラリー例を提供し、Vega-Lite、ECharts、Chart.js のレンダリングをサポートする
  • TypeScript / JavaScript 環境では npm でインストールでき、エージェントのワークフローでは MCP サーバー を利用できる
  • バックエンドごとの差異のある API を統一インターフェースの背後に隠し、同じ仕様からのレンダラー切り替えやチャート設計変更をより容易にする

Flint が解決しようとする問題

  • Flint は Microsoft Research のプロジェクトで、AIエージェントがシンプルで人間が編集可能なチャート仕様からチャートを生成できるよう設計された可視化中間言語である
  • 仕様はデータ、セマンティック型、チャート仕様で構成される
    • 例の仕様では period を YearMonth、totalUsers を Quantity、gameType と region を Category として指定している
    • Line Chart では region を column、period を x、totalUsers を y、gameType を color にバインドし、地域別の月間アクティブユーザーのラインチャートを作成する
  • npm から TypeScript / JavaScript 環境にインストールできる
  • エージェントのワークフローでは MCP サーバー を利用できる
  • gallery では 46種類のチャートタイプ と 83 の例を見ることができる

仕様をチャートに変換する仕組み

  • Flint は圧縮された仕様から始めて、Vega-Lite のようなバックエンドネイティブ仕様を生成し、必要な低レベルの詳細設定を補完してチャートをレンダリングする
  • セマンティック型 はデータフィールドの意味を表現する
    • 例には Rank、YearMonth、Delta、Temperature のような型が含まれる
    • Flint はこれに基づいて、解析、スケール、軸、書式設定、配色体系といったチャート設定を推論する
    • ゲームと月ごとの純新規ユーザー数を示すヒートマップでは、時間値のパーサー、軸の書式設定、発散カラースキームと中間点をセマンティック型に基づいて決定する
  • 自動レイアウト最適化 は、柔軟なレイアウトモデルと banking 原則に基づいている
    • コンパイラがサイズ、間隔、配置を動的に管理し、チャートがキャンバスに収まるよう調整する
    • グループ化棒グラフの数が増えると、キャンバスを広げて band width を縮小し、高密度な版もキャンバス内に収める
  • チャート設計の変更は、チャート種別の切り替えと視覚エンコーディングの再バインドで処理できる
    • 2000年の米国国勢調査の性別・年齢別人口分布を示す faceted bar chart を pyramid chart に変える際、ユーザーはチャート種別だけを変更し、残りはコンパイラが処理する

レンダリングバックエンドと利用可能状況

  • Flint は Vega-Lite、ECharts、Chart.js 全体で 46 種類のチャートタイプをサポートする
    • 異なる API やプログラミングモデルを統一インターフェースの背後に隠している
    • Vega-Lite にネイティブの sunburst がない場合は ECharts に切り替えられる
    • 地域 × gameType × game の階層構造の可視化には、グループ化棒グラフより sunburst chart のほうが優れた代替案として示されている
  • Flint は オープンソース であり、すぐに利用できる
  • 出発点として GitHub とギャラリーの例が提供されている
  • Microsoft Research は IDEAS Lab および Renmin University of China と協力して Flint を構築した

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsでの意見

  • 「AIエージェント向け」というマーケティングがなぜ必要なのかは分かるが、結局のところチャートを表現しやすい言語というだけでも十分に印象的で有用

    • これはいくら強調してもしすぎることはない。「エージェントに向いている」というのは結局、自己説明的で、操作感が明確で、安全なデフォルト値と簡潔または制御可能な出力、プログラム可能なインターフェースを備えているという意味で、こうした特性は人間にとっても役に立つ
    • これは文字どおり MCPサーバーを通じてAIエージェントがアクセスできるように作られたものではないかと思う。だとすれば、マーケティングでAIエージェントを強調するのはかなり重要に見える
    • こう要約するのが正しそう。派手な説明は結局、「データを見てチャートがどう見えるべきかを自動で決める」という話を長く言っているように思える
      ページでも「スケール、軸、間隔、レイアウトのような冗長な低レベルパラメータを要求する代わりに、Flintコンパイラがデータ、意味型、チャートタイプ、エンコーディングから最適化されたチャート設定を導き出す」と説明している
    • エージェントが生成しやすいだけでなく、人間にとっても、特にUIがあれば編集しやすい形式
    • パッケージを見ると、既存のチャートライブラリの上に構築された形になっている

  • エージェントシステムで新しいパターンが現れており、このプロジェクトは良い例
    LLMが生成して渡す何らかの**中間表現（IR）**を置き、その上にコンパイラやコード生成器のような決定的な層を重ねる方式。近い将来、こうした構造をもっと頻繁に見ることになりそう

    • ClaudeがPPTデッキを直接XMLで作るのではなく、Pythonコードを書いて生成するのを初めて見たとき、かなり「なるほど」と思った。多くの作業がこの経路に進みそうで、長期的には少し制約が強くハックっぽく感じられるが、当面は100%正しいアプローチに見える
    • このアイデアには完全に同意する。この1か月で行ったあるエージェントによるコーディング作業はすべて中間表現を通じて進め、反復も主にその層で行った。この方式で決定的なコード出力にかなり近づけることには驚かされる
    • よく設計された中間層は、AIとは独立して検証と制御を可能にする。これにより、人間とAIの相互作用は委任から協業へと変わる
    • その通り。エージェントシステムは最初からこういうパターンだった。緩く生成し、入力が検証されるまで、穴に合う形と大きさが出るまで再試行し続ける方式
    • プログラミングはこれまで以上に健在

  • ページにはないが、データ可視化を作るときにアクセシビリティを設計段階で反映することは本当に重要
    このポッドキャストには関連する短いインタビューがよくまとまっている: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    インタビュー対象はこの分野でかなり有名そうなFrank Elavskyで、アクセシビリティ監査用のヒューリスティック、原則、ガイドラインを含むChartabilityプロジェクトも作っている: https://chartability.github.io/POUR-CAF/

  • これがVega自体よりどう優れているのか、あるいはどう違うのかについて具体的な説明があるのか気になる: https://vega.github.io/vega/docs/specification/
    Vegaはすでに可視化のための表現力豊かなDSLであり、LLMの学習データにもかなり広く含まれていそう

    • 以前はVegaが人間にとっては高水準言語だったが、今ではAIエージェントにとってはむしろ少し低水準かもしれない。エージェントが見栄えのよいチャートを作るには低レベルパラメータを多く書く必要があり、その結果、安定して記述するのが難しくなる
      Flintはより高いレベルの抽象化なので、仕様がずっと短く単純で、コンパイラが低レベルの判断を導き出して見栄えのよいチャートを作れるようにする。つまり、以前なら長いプログラムが必要だった良いチャートを、エージェントが短いプログラムで作れるようにしてくれる
    • 私もVega-Liteと比べるとどうなのか気になっていた。Vega-Liteも比較的高水準で宣言的で、構文もFlintに似ているように見える

  • 「単純なチャート仕様は安定している可能性があるが、システムのデフォルトに依存するため生成されるチャートの品質が低く、複雑な仕様は見栄えのよいチャートを作れるが冗長なのでエージェントが安定して扱いにくい」という主張にはあまり強く共感できない
    分析エージェントを作った少数の作業経験では、LLMがPythonとRで可視化をかなりうまく作ることに感心した。小さな公開重みモデルでも同様で、曖昧な部分を少し反復して詰めれば欠点が消えることが多かった。この主張を裏付ける、あるいは問題が生じる箇所を示す研究の流れがあるのか気になる

    • より単純な仕様は、より単純なエージェントが使える。おそらくここでの用途は、1つの大きなモデルが可視化を1つずつ作るのではなく、小さく安価なエージェントが並列に使う方向かもしれない
      個人的にはClaudeとChatGPTはggplotモデルをうまく生成するが、カスタマイズが多くなると少し複雑になる
    • 表現力だけでなく、安定性とインタラクティブ性も考慮している。専門家ではないユーザーを対象にする場合や小さなモデルを使う場合には、表現力がありつつ単純な仕様が役に立つ

  • 「スケール、軸、間隔、レイアウトのような冗長な低レベルパラメータ」という説明は、Microsoftが異なる2つのものを混同しているように思える
    LLMはコードが低レベルで冗長かどうか自体をあまり気にせず、アセンブリやSPIR-Vも問題なく読める。本当の問題は視覚的な構成だ。LLMは人間とは違う形で「見る」ため、視覚的比較による空間構成の理解が自然ではなく、回避するにはコード形式の可視化のように、LLMが推論して理解しやすい表現を提供する必要がある。つまり、深くネストされていたり、隠れた状態を推論しなければならない構造でなければよい
    それに、FlintがJSONで文字列キー中心に型を扱うという判断には賛同しにくい。実際の仕様を見ると、単に人間が書きやすいTypeScriptライブラリとして作ることもできたし、そのほうがずっとよかったように思える。後でソースを実際に見ると、ドキュメントだけを見て想定したモックよりもはるかに完成度が高く精巧だったが、「文字列キーのJSON対本物のジェネリックな記述面」という核心的な不満は依然として残る

    • chartTypeの部分は、テンプレートがもっと拡張可能であるべきなので、あまり洗練されていないと思う。この部分は修正が必要
      それ以外の部分では、可視化やダイアグラムのライブラリでJSONを使うのはかなり一般的だ。異なるレンダリング文脈へ簡単に移せるためだ
    • JSONが最適な仕様言語ではないことには同意するが、各プロジェクトがそれぞれ独自の仕様を新たに書き始めるより良いのかは考えるべき問題だ
      関連記事: https://www.openui.com/blog/stop-making-ai-write-json
    • 残念ながら、LLMにデータやコードを入出力する最も安定した方法としてはJSONに縛られているように思える。もっと悪いYAMLだった可能性もある
      LLMの予測可能性を高めるカスタムDSLには関心があり、Microsoftのような巨大企業もこれを理解したようでうれしい。https://slangify.org/examplesのContactsの例は、VCARDとJCARDを相互変換しながら、独自DSLを簡単に作る方法だ

  • 「優れたコンパイラが処理すべき視覚的な判断を明示的に行わせる」という説明を見ると、Graphvizは同じ理由で存在しているのではないかと思う
    宣言言語としてJSONを使っているのを見ると、LLMがJSONをうまく扱えることは認めるとしても、人間が消費しやすい構文ではない

    • 実際、可視化において人間が使う共通言語としてのJSONは、かなり以前から存在している。宣言型構文の利点は、ユーザーがUIでドラッグ＆ドロップやクリックによって仕様を効果的に操作できる点にある
      Flintは、エージェントがスケール、軸、ゼロ基準、ステップサイズのような低レベルパラメータを飛ばせるよう意図的に設計されている。こうした要素は見栄えのよいチャートに非常に重要で、コンパイラが動的に最適化する。そのためAIエージェントにとって扱いやすくなる
    • その通り。正直なところ、これはリリース直後から行き詰まっている感じで、既存のものより特に優れているわけではない

  • セマンティック型を追加のフォーマット要素として使うのは非常に有用だ。多くのフォーマットの定型句を簡潔にエンコードしてくれるためだ
    Flintの型レジストリを共有したり拡張可能にしたりする計画があるのか気になる。そもそもデータ属性自体として持たせない理由も気になる。Vega-Liteの上で、より高レベルな連結型チャートを作ったとき、ほぼ同じ仕様にたどり着いた

  • このプロジェクトの要点がよく分からない。GPT-3.5の時代から、LLMはmatplotlibを一発で生成できていたように思う
    データ可視化にLLMをかなり使ってきたが、特に問題はなかった。エージェントが可視化生成の具体的にどこで苦労していて、Flintがそれをどう解決するのか、事例が知りたい

    • ここには少し最後の20%問題がある。チャット欄でGPTとやり取りしながら継続的に方向を示せば、パワーユーザーにとってはおおむね問題ない
      しかしエンドユーザー向けのツールに組み込むと、見栄えのよいチャートを生成できる成功率80%が大きな問題になり始める。データ分析システムを作ったときに、こうしたことを経験した。matplotlibやVega-Liteを直接生成させると、安定性、表現力、コスト・時間・トークンを同時に満たすのは難しく、そのため一部の判断をコンパイラに移して生成コストを下げつつ表現力を維持する折衷案として、この言語を設計した

  • プロジェクトページ: https://microsoft.github.io/flint-chart/
    MCP設定: https://microsoft.github.io/flint-chart/#/mcp