Microsoft revela Flint, linguagem de visualização para agentes de IA

 (microsoft.github.io)
3 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Flint é uma linguagem intermediária de visualização que ajuda agentes de IA a criar gráficos expressivos a partir de especificações curtas e editáveis por humanos
  • O compilador interpreta os dados, os tipos semânticos, o tipo de gráfico e as codificações, preenchendo automaticamente configurações de baixo nível como escala, eixos, espaçamento e layout
  • Oferece 46 tipos de gráfico e 83 exemplos na galeria, com suporte a renderização em Vega-Lite, ECharts e Chart.js
  • Em ambientes TypeScript / JavaScript, pode ser instalado via npm, e em fluxos de trabalho com agentes é possível usar um servidor MCP
  • Oculta as diferenças de API entre os backends atrás de uma interface unificada, facilitando trocar o renderizador ou alterar o design do gráfico a partir da mesma especificação

O problema que o Flint tenta resolver

  • Flint é um projeto da Microsoft Research, uma linguagem intermediária de visualização projetada para que agentes de IA gerem gráficos a partir de especificações simples e editáveis por humanos
  • A especificação é composta por dados, tipos semânticos e especificação do gráfico
    • Um exemplo de especificação define period como YearMonth, totalUsers como Quantity e gameType e region como Category
    • Em um Line Chart, vincula region à coluna, period ao eixo x, totalUsers ao eixo y e gameType à cor para criar um gráfico de linhas de usuários ativos mensais por região
  • Pode ser instalado em ambientes TypeScript / JavaScript via npm
  • Em fluxos de trabalho com agentes, é possível usar o servidor MCP
  • Na galeria, é possível ver 46 tipos de gráfico e 83 exemplos

Como a especificação é transformada em gráfico

  • O Flint parte de uma especificação compacta, gera uma especificação nativa do backend, como Vega-Lite, e renderiza o gráfico preenchendo os detalhes de baixo nível necessários
  • Tipos semânticos expressam o significado dos campos de dados
    • Os exemplos incluem tipos como Rank, YearMonth, Delta e Temperature
    • Com base nisso, o Flint infere configurações do gráfico como parsing, escalas, eixos, formatação e esquema de cores
    • Em um mapa de calor que mostra novos usuários líquidos por jogo e por mês, ele determina com base nos tipos semânticos o parser de valores temporais, a formatação dos eixos, o esquema de cores divergente e o ponto médio
  • A otimização automática de layout é baseada em um modelo de layout elástico e no princípio de banking
    • O compilador gerencia dinamicamente tamanho, espaçamento e posicionamento para ajustar o gráfico à área disponível
    • Quando o número de gráficos de barras agrupadas aumenta, ele amplia a área de desenho e reduz a band width para que versões mais densas também caibam no canvas
  • Alterações no design do gráfico podem ser tratadas trocando o tipo de gráfico e refazendo o vínculo das codificações visuais
    • Ao transformar um faceted bar chart da distribuição populacional por sexo e idade do censo dos EUA de 2000 em um pyramid chart, o usuário precisa mudar apenas o tipo de gráfico, e o compilador cuida do restante

Backends de renderização e disponibilidade

  • O Flint oferece suporte a 46 tipos de gráfico em Vega-Lite, ECharts e Chart.js
    • Esconde APIs e modelos de programação diferentes atrás de uma interface unificada
    • Quando o Vega-Lite não tem suporte nativo a sunburst, é possível trocar para ECharts
    • Para visualizar a hierarquia região × gameType × game, um sunburst chart é apresentado como alternativa melhor do que um gráfico de barras agrupadas
  • O Flint é open source e já pode ser usado
  • Há um GitHub e exemplos da galeria como ponto de partida
  • A Microsoft Research desenvolveu o Flint em colaboração com a IDEAS Lab e a Renmin University of China

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Entendo por que esse marketing de “para agentes de IA” é necessário, mas no fim das contas o fato de ser uma linguagem que facilita a expressão de gráficos já é suficientemente impressionante e útil

    • Isso não pode ser enfatizado demais. Dizer que “é bom para agentes” no fundo significa que é autoexplicativo, tem manipulação clara, padrões seguros e saída concisa ou controlável, além de uma interface programável, e essas características também ajudam humanos
    • Acho que isso foi literalmente feito para que agentes de IA acessem por meio de um servidor MCP. Se for esse o caso, destacar agentes de IA no marketing parece bem importante
    • Acho que esse resumo faz sentido. A explicação mais elaborada no fim parece apenas uma forma longa de dizer “olha para os dados e decide por conta própria como o gráfico deve ser mostrado”
      A página também explica: “em vez de exigir parâmetros verbosos de baixo nível como escala, eixos, espaçamento e layout, o compilador do Flint deriva configurações de gráfico otimizadas a partir dos dados, do tipo semântico, do tipo de gráfico e da codificação”
    • É fácil para agentes gerarem, mas também é um formato fácil de editar para humanos, especialmente se houver uma UI
    • Pelo pacote, parece ser algo construído sobre bibliotecas de gráficos já existentes

  • Um novo padrão está surgindo em sistemas de agentes, e este projeto é um bom exemplo disso
    Trata-se de ter alguma representação intermediária (IR) que o LLM gera e repassa, e então colocar por cima uma camada determinística como um compilador ou gerador de código. Acho que veremos essa estrutura com mais frequência no futuro próximo

    • Quando vi Claude gerar um deck de PPT escrevendo código Python em vez de montar XML diretamente, foi um momento bem de “ahá”. Parece que muitas tarefas vão por esse caminho e, no longo prazo, isso pode parecer um pouco limitado e meio gambiarra, mas por enquanto parece a abordagem 100% correta
    • Concordo totalmente com essa ideia. No último mês, todo trabalho de agent coding que fiz passou por representações intermediárias, e a iteração também aconteceu principalmente nessa camada. É surpreendente como dá para chegar bem perto de uma saída de código determinística desse jeito
    • Uma camada intermediária bem projetada permite validação e controle independentemente da IA. Isso muda a interação entre humanos e IA de delegação para colaboração
    • Exato. Sistemas de agentes já eram esse padrão desde o começo. Gerar de forma solta e continuar tentando até sair o formato e o tamanho certos para encaixar no buraco, com validação da entrada no processo
    • Programação está mais viva do que nunca

  • Não está na página, mas ao criar visualizações de dados é muito importante incorporar acessibilidade já na fase de design
    Este podcast resume bem uma entrevista curta sobre o tema: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    O entrevistado é Frank Elavsky, que parece ser bem conhecido nessa área, e também criou o projeto Chartability, com heurísticas, princípios e diretrizes para auditoria de acessibilidade: https://chartability.github.io/POUR-CAF/

  • Fico curioso se existe alguma explicação concreta de como isso é melhor ou diferente do próprio Vega: https://vega.github.io/vega/docs/specification/
    O Vega já é uma DSL expressiva para visualização, e imagino que também esteja amplamente presente nos dados de treinamento de LLMs

    • Antigamente, o Vega era uma linguagem de alto nível para humanos, mas agora, para agentes de IA, talvez seja um pouco baixo nível demais. Para um agente fazer um gráfico bonito, ele precisa usar muitos parâmetros de baixo nível, e isso acaba dificultando a escrita estável
      O Flint é uma abstração de nível mais alto, então a especificação é muito mais curta e simples, e o compilador deriva as decisões de baixo nível para produzir gráficos visualmente bons. Em outras palavras, ele permite que agentes criem, com programas curtos, bons gráficos que antes exigiam programas longos
    • Eu também queria saber como isso se compara ao Vega-Lite. O Vega-Lite também é relativamente de alto nível e declarativo, e a sintaxe parece parecida com a do Flint

  • Não concordo muito com a afirmação de que “especificações simples de gráfico podem ser estáveis, mas dependem dos padrões do sistema e geram gráficos de baixa qualidade, enquanto especificações complexas podem produzir gráficos bonitos, mas são verbosas e difíceis para agentes lidarem de forma estável”
    Pela pouca experiência que tive construindo agentes de análise, achei impressionante como LLMs fazem visualizações muito bem em Python e R. O mesmo valia para modelos pequenos de pesos abertos, e em muitos casos bastava iterar um pouco sobre as ambiguidades para que as desvantagens desaparecessem. Fico curioso se existe alguma linha de pesquisa que sustente essa afirmação ou mostre onde surgem os problemas

    • Especificações mais simples podem ser usadas por agentes mais simples. Talvez o uso aqui seja mais para agentes pequenos e baratos rodando em paralelo, em vez de um único modelo grande gerando visualizações uma por uma
      Pessoalmente, acho que Claude e ChatGPT geram bem modelos de ggplot, mas quando a customização aumenta fica um pouco mais complicado
    • Estão considerando não só expressividade, mas também estabilidade e interatividade. Para usuários não especialistas ou ao usar modelos pequenos, uma especificação simples que ainda seja expressiva ajuda bastante

  • A descrição de “parâmetros de baixo nível verbosos, como escala, eixo, espaçamento e layout” faz parecer que a Microsoft está misturando duas coisas diferentes
    O LLM em si não liga muito se o código é de baixo nível e verboso; ele também consegue ler bem assembly ou SPIR-V. O problema real é a composição visual. Como o LLM “vê” de forma diferente de humanos, entender composição espacial por comparação visual não é algo natural, e, para contornar isso, é preciso oferecer uma representação que o LLM consiga raciocinar e entender com facilidade, como uma visualização em forma de código. Em outras palavras, desde que não seja uma estrutura profundamente aninhada ou que exija inferir estados ocultos, tudo bem
    Também é difícil concordar com a decisão do Flint de tratar tipos em JSON com foco em chaves de string. Olhando a especificação real, isso poderia simplesmente ter sido feito como uma biblioteca TypeScript agradável de usar por humanos, e isso provavelmente teria sido muito melhor. Depois, ao ver o código-fonte de fato, ele pareceu muito mais completo e sofisticado do que o mockup que eu tinha imaginado só pela documentação, mas a reclamação central de “JSON com chaves de string versus uma superfície real de escrita com genéricos” continua

    • A parte de chartType não me parece muito elegante, porque os templates precisariam ser mais extensíveis. Essa parte precisa de ajuste
      Tirando isso, usar JSON em bibliotecas de visualização ou diagramação é algo bem comum. Porque é fácil de transportar entre diferentes contextos de renderização
    • Concordo que JSON não é a linguagem de especificação ideal, mas vale pensar se ainda assim não é melhor do que cada projeto começar a criar sua própria especificação do zero
      Texto relacionado: https://www.openui.com/blog/stop-making-ai-write-json
    • Infelizmente, parece que JSON continua sendo o formato ao qual estamos presos como forma mais confiável de colocar e tirar dados ou código de LLMs. Poderia ser YAML, que seria pior
      Tenho interesse em DSLs customizadas para aumentar a previsibilidade dos LLMs, e é bom ver que até um gigante como a Microsoft parece ter entendido isso. O exemplo Contacts em https://slangify.org/examples mostra uma forma de criar facilmente uma DSL própria enquanto converte de ida e volta entre VCARD e JCARD

  • Ao ler a explicação de que “isso faz você explicitar decisões visuais que um bom compilador deveria resolver”, dá a impressão de que Graphviz já existe exatamente por esse motivo
    Ver JSON sendo usado como linguagem declarativa reforça que, mesmo admitindo que LLMs lidam bem com JSON, isso não o torna uma sintaxe agradável para consumo humano

    • Na verdade, JSON como linguagem comum para humanos em visualização já existe há bastante tempo. A vantagem de uma sintaxe declarativa é que o usuário pode manipular a especificação com eficiência na UI por arrastar e soltar ou clicar
      O Flint foi projetado intencionalmente para permitir que agentes ignorem parâmetros de baixo nível como escala, eixo, linha de base zero e tamanho de passo. Esses elementos são muito importantes para um gráfico visualmente bom, e o compilador os otimiza dinamicamente. Por isso, fica mais fácil para agentes de IA lidarem com isso
    • Sim. Sinceramente, isso parece bloqueado já no lançamento e não é particularmente melhor do que o que já existia

  • Usar tipos semânticos como elemento adicional de formatação é muito útil. Porque isso codifica de forma concisa uma grande quantidade de boilerplate de formato
    Fico curioso se há planos para compartilhar o registro de tipos do Flint ou torná-lo extensível. Também queria entender por que isso não fica simplesmente como parte dos próprios atributos dos dados. Ao criar gráficos vinculados de nível mais alto sobre o Vega-Lite, cheguei praticamente à mesma especificação

  • Não entendo muito bem qual é o ponto principal deste projeto. Desde a época do GPT-3.5, os LLMs já pareciam capazes de gerar matplotlib de uma vez só
    Já usei bastante LLMs para visualização de dados e não tive grandes problemas. Queria ver exemplos concretos de onde exatamente agentes têm dificuldade ao gerar visualizações e como o Flint resolve isso

    • Há um pouco de um problema dos 20% finais aqui. Se você conversa com o GPT na janela de chat e vai ajustando a direção, para usuários avançados isso geralmente funciona bem
      Mas, quando você coloca isso em uma ferramenta para usuários finais, uma taxa de sucesso de 80% na geração de gráficos bonitos começa a virar um grande problema. Passei por isso ao construir um sistema de análise de dados. Se você fizer o modelo gerar matplotlib ou Vega-Lite diretamente, é difícil obter ao mesmo tempo confiabilidade, expressividade, custo, tempo e uso de tokens; então essa linguagem foi desenhada como um meio-termo que transfere algumas decisões para o compilador, reduzindo o custo de geração sem perder expressividade

  • Página do projeto: https://microsoft.github.io/flint-chart/
    Configuração do MCP: https://microsoft.github.io/flint-chart/#/mcp