TypeChat: plataforma de IA baseada em chat

 (microsoft.github.io)
3 pontos por GN⁺ 2023-07-21 | 2 comentários | Compartilhar no WhatsApp
  • A maior dificuldade ao adicionar entrada em linguagem natural a apps existentes é transformar a intenção do usuário em uma estrutura confiável para o software, e o TypeChat é uma biblioteca que busca resolver esse ponto com tipos TypeScript
  • Como as respostas em texto livre dos LLMs são instáveis para parsing, o TypeChat orienta as respostas para JSON e adiciona validação de schema, transformando-as em dados que o app consegue processar
  • Tipos TypeScript conseguem representar estruturas JSON com precisão e, por serem um formato que os LLMs viram muito durante o treinamento, são úteis como schema de resposta
  • Se a resposta não corresponder ao tipo, é possível realimentar os erros do compilador TypeScript para corrigi-la, aumentando a segurança de tipos antes do pós-processamento ou da confirmação do usuário
  • O TypeChat pode ser instalado com npm install typechat; é open source sob licença MIT e também oferece integração com a API da OpenAI e com o serviço Azure OpenAI

Transformando solicitações em linguagem natural em dados que o app consegue processar

  • Modelos de linguagem de grande porte modernos podem ser conectados facilmente a assistentes de chat, mas integrar linguagem natural de forma confiável a interfaces de apps existentes é um desafio à parte
  • O TypeChat se concentra em transformar solicitações dos usuários em um formato que o app consiga processar e em viabilizar ações nas quais desenvolvedores e usuários possam confiar
  • A biblioteca publicada usa as definições de tipos da base de código para obter respostas de IA estruturadas, com o objetivo de oferecer segurança de tipos
  • A instalação pode ser feita com o seguinte comando
npm install typechat

Usando JSON e tipos em vez de parsing de linguagem natural

  • LLMs são, por padrão, voltados a conversas em linguagem natural, como inglês; mesmo que regras como “responda em lista com marcadores” sejam colocadas no prompt, isso é difícil para softwares comuns parsearem de forma confiável
  • Ao pedir uma resposta em JSON, geralmente é possível gerar uma resposta em um formato mais fácil para o app lidar
    • No exemplo, um pedido de 1 “blueberry muffin” e 1 “grande latte” é convertido em um JSON com um array items
  • Exemplos simples ajudam a induzir a estrutura, mas não definem suficientemente o que a IA deve retornar nem fornecem critérios de validação

Usando tipos TypeScript como schema de resposta

  • O TypeChat inclui tipos TypeScript no prompt para orientar a estrutura JSON que o LLM deve retornar
  • O tipo Response do schema de exemplo inclui items: Item[], e Item tem os campos name, quantity e os campos opcionais size e notes
  • TypeScript é adequado para descrever JSON com precisão e, como LLMs foram expostos a muitas definições de tipos, é útil para orientar o formato da resposta
  • Se a resposta não corresponder ao tipo, o compilador TypeScript a valida com base na definição de tipos, que é código TypeScript válido
  • O feedback de erros do compilador é usado para orientar a correção da resposta, tornando mais robusto o fluxo para obter uma resposta compatível com os tipos

Forma de uso e exemplos do TypeChat

  • O TypeChat pode ser usado em uma abordagem de schema de dados que transforma a intenção do usuário em uma resposta estruturada
  • O código de exemplo define uma interface SentimentResponse que classifica o sentimento da frase de entrada do usuário como negative, neutral ou positive
  • Ele cria um modelo de linguagem baseado em variáveis de ambiente com createLanguageModel(process.env), lê o arquivo de schema e cria um tradutor com createJsonTranslator<SentimentResponse>
  • Se translator.translate(request) tiver sucesso, imprime response.data.sentiment; se falhar, imprime a mensagem de erro
  • Além de schemas de dados, também é possível usar schemas de API para compor programas básicos
  • A forma de uso pode ser consultada na docs e nos examples

Open source e neutralidade de modelo

  • O TypeChat é open source sob licença MIT e está disponível no GitHub
  • Por conveniência, oferece integrações básicas com a API da OpenAI e com o serviço Azure OpenAI
  • O objetivo de design é a neutralidade de modelo, buscando uma abordagem utilizável com APIs no estilo chat completion
  • Atualmente, o TypeChat funciona melhor com modelos treinados tanto em prosa quanto em código
  • O pacote está disponível no npm, então pode ser testado imediatamente

Leituras relacionadas

2 comentários

 
sungwoo 2023-07-26

kkk, vi a notícia e ia postar, mas não dá pra competir com a IA
 
GN⁺ 2023-07-21
Opiniões do Hacker News

  • Não sei bem qual é o valor agregado aqui
    A mensagem central enviada ao LLM é esta: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    No fim, parece uma forma de fazer com que dados estruturados sejam retornados por meio de um prompt fixo, com um pouco de automação e dependência de fornecedor por cima. A maioria dessas bibliotecas para LLMs é mais próxima de APIs toscas que encapsulam APIs de nível inferior; scripts que fazem a mesma coisa podem ser criados facilmente e são mais flexíveis conforme o modelo e as necessidades do usuário mudam
    Por exemplo, se você quiser mudar o prompt ou usar classes Python, há uma grande diferença de trabalho entre usar uma biblioteca dessas e uma abordagem que expõe ao usuário chamadas de API e templates de texto (https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...)

    • O valor está aqui: 1) rodar o verificador de tipos do TypeScript no resultado retornado pelo LLM, 2) se houver erros de tipo, reuni-los e transformá-los em um “prompt de correção” para induzir uma saída com maior probabilidade de passar na verificação de tipos, 3) lidar de forma limpa também com os casos em que a heurística do item 2 falha
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      Pela minha experiência testando a mesma ideia, a heurística do item 2 funciona surpreendentemente bem para tipos relativamente simples, ou seja, registros e arrays não profundamente aninhados e uso limitado de variáveis de tipo. Só com a abordagem de dar ao LLM um prompt para retornar valores de tipos relativamente simples já dá para criar aplicações úteis, e esta biblioteca tem valor por reduzir a necessidade de implementar diretamente esse padrão de solicitação e por oferecer integração padrão com bases de código TypeScript
    • Quase todas as bibliotecas de LLM que aparecem hoje em dia são assim. No fim, tudo se resume a pedir ao LLM que faça algo de uma determinada maneira, e já vi que, em condições complexas, ele segue menos as instruções e volta ao comportamento padrão
      Ainda assim, parece que usar bibliotecas é o caminho certo, então continuo observando qual abordagem vai amadurecer o suficiente
    • Não entendo onde estaria a dependência de fornecedor. Isto é uma biblioteca open source, e o arquivo linkado também inclui configurações de dois fornecedores, ChatGPT e Bard
    • O valor está em transformar dados não estruturados em dados estruturados e garantir que eles satisfaçam as restrições do schema
      Por exemplo, se você tiver 1.000 respostas de pesquisa em texto livre sobre um produto, pode criar um schema e rodar o TypeChat em cada uma delas para obter um dataset a partir desse texto livre. É extremamente útil
    • Quanto melhores ficam as abstrações, mais fácil fica programar coisas úteis

  • Tem uma parte que eu não entendo
    Não sei por que passar por um procedimento complicado em que você espera receber uma resposta válida, acrescenta um validador na etapa final para detectar respostas incorretas e implora ao modelo para responder na sintaxe desejada
    Dá para garantir uma sintaxe JSON válida amostrando apenas tokens que se encaixem no formato solicitado. Em vez de escolher de forma gulosa o token com maior pontuação a cada vez, basta escolher, entre os tokens compatíveis com o formato solicitado, aquele com maior pontuação
    O Guidance da Microsoft já faz isso: https://github.com/microsoft/guidance
    Mas a OpenAI parece não expor as pontuações completas de todos os tokens, apenas o token de maior pontuação. Se você roda o modelo localmente, usar Guidance é simples, dá para garantir que o JSON esteja correto todas as vezes, e a geração também é mais rápida, então isso é estranho

    • É parecido com a história dos M&M's marrons[0]. Se o modelo está retornando dados semanticamente corretos, é de se esperar que pelo menos acerte a sintaxe. Se não consegue fazer isso, você teria que descartar a resposta de qualquer forma
      Além disso, acho que seria difícil capturar toda a complexidade dos tipos TypeScript dessa maneira
      [0] https://www.snopes.com/fact-check/brown-out/
    • Dessa forma você consegue garantir JSON sintaticamente correto, mas saber se ele é semanticamente correto é outra questão
      Se o modelo realmente quer colocar outro token e você o força a inserir {, a qualidade do texto gerado depois pode cair. Não tenho certeza, é só algo que me veio à cabeça
    • Acho a abordagem de amostrar apenas tokens válidos muito promissora
      Já fiz fine-tuning de um LLM open source para parsing de JSON, e mesmo sem amostragem guiada de tokens, 70B parâmetros pode ser exagero dependendo do uso. Vi resultados bastante bons com modelos bem menores, e combinar fine-tuning de modelos pequenos com amostragem guiada de tokens parece interessante
      Dito isso, para aplicações muito genéricas, o fine-tuning pode não ser perfeito. Fica complicado se entrar um input que não era esperado no dataset de treinamento
    • LLMs conseguem lidar com cenários mais complexos. Por exemplo, em uma máquina de venda automática, se você simplesmente disser o pedido sem passar por todo o processo de compra, ele consegue inferir algo como “algumas barras de chocolate” e casar isso com o estoque
      Claro que na web isso não faz sentido. É muito mais fácil clicar em alguns produtos com o mouse
    • Como o Llama.cpp explicou recentemente, ele adicionou amostragem baseada em gramática, que restringe a seleção de tokens para seguir um formato fixo
      https://github.com/ggerganov/llama.cpp/pull/1773

  • Parece que, sempre que eu penso em alguma coisa, Anders Hejlsberg vai lá e cria.
    Requisições e respostas estruturadas são 100% a próxima evolução dos LLMs. As pessoas já estão ficando cansadas de chatbots, e seria incrível poder plugar qualquer backend sem se preocupar com parsing de texto e prompts.

    • Quero acoplar a um LLM rodando localmente interfaces acionáveis que eu mesmo forneça. Coisas como “verificar a hora”, “consultar o calendário”, “enviar uma mensagem ao usuário”.
      O TypeChat parece estar no caminho certo. Dá para imaginar uma camada extra do tipo “encaixe esta entrada JSON em uma das ações possíveis, se der”.
      Vejo um futuro híbrido bem limpo em que bots, ou seja, LLMs etc., costuram camadas de código reais. Às vezes como parte da coleta e da marcação, às vezes como parte da resposta à entrada.
      No geral é uma área muito interessante, mas tudo está andando tão rápido que ainda não mergulhei fundo. Sinto que vale esperar a poeira baixar um pouco, já que muita gente inteligente está trabalhando nisso. Mesmo assim, acho que a interface doméstica com que eu sonhava já chegou a um ponto em que dá para construir.
    • Acabei de implementar algo parecido ontem, mas com foco em funções em vez de objetos.
    • Como mapper dinâmico na camada de backend, isso pode ser enorme.
      Por exemplo, tente acompanhar payloads de API que mudam com frequência ao redor de um consumer Java. Em bancos, com payloads JSON gigantes e ambiente de backend em Java, criamos uma camada NodeJS separada para manter a sanidade.
      Mapeamento é uma área em que LLMs podem brilhar.
    • Vale dar uma olhada: https://news.ycombinator.com/item?id=36750083

  • Uma leitura provocativa: estamos entrando aos poucos na fase de ferramentização da IA. As pessoas percebem que não há muita criação de valor real aqui, mas foi investido tanto em IA que o dinheiro continua entrando. Também é um bom tema para publicar artigos acadêmicos, e o LangChain é quase uma piada, mas recebeu US$ 10 milhões em seed.
    DeFi/crypto passou por essa fase há 2 anos. Depois de alguns anos em um limbo estranho, as pessoas vão lentamente perceber que IA é uma funcionalidade, não um produto; que seu escopo de aplicação é limitado; e que ela não vai salvar o mundo. Não teremos carros autônomos por causa de todos os edge cases, e ela também não fará cirurgias porque pode matar pessoas.
    Venho dizendo que até as ferramentas de IA mais úteis, como o Copilot, são, no máximo, úteis apenas de forma periférica. No melhor caso, reduzem alguns cliques no Google, e os agentes não são nada “inteligentes”. Há alguns anos tivemos uma bolha parecida com chatbots[1], e hoje ninguém liga. O “metaverso” acabou muito mais rápido, mas a mesma mentalidade de manada estava em ação. Uma coisa é “a próxima grande onda” até deixar de ser.
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • Discordo fortemente da ideia de que IA seja apenas uma bolha de escopo limitado.
      Você escolheu justamente alguns dos casos de uso mais difíceis para IA, como carros autônomos e cirurgia. O trabalho da maioria das pessoas não envolve vida ou morte, então é muito adequado à automação. Mesmo que o elemento humano permaneça em profissões de vida ou morte, é bem provável que elas sejam reforçadas por agentes de IA. Por exemplo, a cirurgia pode continuar sendo feita por humanos, mas pode se tornar obrigatório que médicos ou enfermeiros façam diagnósticos com IA.
      Você está mesmo comparando a bolha dos chatbots de alguns anos atrás com o momento atual? O ChatGPT chegou a 100 milhões de usuários em poucos meses, e muita gente de fato experimentou. A bolha dos chatbots de alguns anos atrás mal tinha presença.
      Copilot etc. parecem úteis apenas perifericamente porque estamos vendo a pior versão que eles terão. O ChatGPT mudou minha vida, e ele ainda nem executa código. O Code Interpreter executa, mas ainda não testei.
      Por volta de 2030, humanos provavelmente já não estarão digitando código, e sim dando prompts às máquinas e comandando agentes de IA. Até lá, é bem provável que a maior parte dos empregos também seja automatizada.
      IA não é só uma moda; ela vai transformar todas as indústrias, e muito mais rápido do que as pessoas imaginam. O cinismo que compara IA ao metaverso e minimiza suas implicações é absurdo e falta imaginação. Ainda há muito a fazer, especialmente no lado dos agentes de IA, mas provavelmente chegaremos lá muito antes do que as pessoas pensam, e o impacto será enorme.
    • Toda vez que uso o ChatGPT, sinto que estou vendo uma tecnologia diferente daquela que outras pessoas veem. Dizem que ele responde a todas as perguntas e ensina qualquer coisa, mas, na prática, parece um serviço de fazenda de conteúdo. O Copilot é parecido: em geral é mais fácil escrever o código eu mesmo do que encontrar a opção menos ruim entre exemplos ruins e corrigir bugs.
      Dito isso, o AlphaGo não demorou para sair de um estado em que “alucinava” jogadas ruins e se tornar o melhor jogador do mundo. Se isso for possível com modelos de linguagem, o GPT-x pode acabar com toda a discussão atual.
    • Discordo fortemente de “não há criação de valor real”. Tenho um contraexemplo muito claro no meu caso de uso.
      GPT-4 é tremendamente útil quando uma pessoa experiente faz tarefas adjacentes em que suas habilidades em geral se aplicam, mas seu conhecimento de domínio é fraco.
      Escrevo código há 10 anos e recentemente comecei a aprender machine learning pela primeira vez; uso GPT-4 todos os dias e estou muito satisfeito.
      Claro que as arestas às vezes podem incomodar. Para mim, são gerenciáveis e não dão grande trabalho. Acostumei a ignorar ou contornar, e há claramente uma habilidade em usar esse tipo de ferramenta.
      Acho que o valor entregue continuará crescendo. Ainda nem colhemos todos os frutos baixos e os de altura média.
    • A diferença fundamental em relação a DeFi/crypto é que, naquele caso, por mais tecnicamente impressionante que fosse, as pessoas precisavam mudar completamente o que faziam para obter o primeiro benefício.
      A IA moderna — na prática, geralmente LLMs — é imediatamente aplicável de forma ampla a quase todos os setores da economia. Por isso, muita gente já está criando e lançando funcionalidades. Há um valor enorme nessa tecnologia. Ela vai transformar completamente o mundo? Não. Mas é suficiente para criar novas categorias de produtos e melhorar de forma fundamental uma grande parte das capacidades dos produtos existentes.
    • Acho uma interpretação bastante razoável. A IA tem muitos usos e é realmente boa em algumas coisas, mas não é a solução universal que as pessoas esperam.

  • Não entendo por que, entre os assistentes de voz da Apple, Google, Amazon e Microsoft, nenhum ainda integrou LLMs ao serviço, e por que a OpenAI ainda não lançou seu próprio assistente de voz.
    Além disso, se sites expusessem uma URL padrão para interações com IA, como RSS, e divulgassem a interface via TypeChat, acho que isso poderia avançar bastante nessa direção.

    • É bem provável que a OpenAI crie seu próprio assistente. Basta ver o “Building a kind of JARVIS @ OреոΑӏ” do Karpathy, e a Microsoft obviamente também deve estar trabalhando para integrar ou reinterpretar a Cortana usando os LLMs da OpenAI.
      Só que o valor da capacidade de executar ações de fato é muito maior do que o de um LLM baseado em voz. Pegando a Alexa como exemplo, é preciso um sistema que controle casas inteligentes de forma previsível e depurável. Caso contrário, as pessoas se irritam.
      Eu claramente acho que é possível, mas sistemas atuais como Alexa, Siri e a menos usada Cortana usam várias hooks e APIs com regras e software acumulados ao longo de anos sobre modelos menos poderosos. Para fazer funcionar, é preciso melhorar mantendo a qualidade atual e, ao mesmo tempo, substituir partes importantes do sistema, então isso leva tempo.
      Além disso, esses assistentes na prática não ganham dinheiro e, em geral, dão prejuízo. Eles só têm valor para grandes empresas que conseguem ganhar dinheiro de outras formas, como celulares e compras, ou impulsionar outros negócios, então há pouco incentivo para uma startup fazer isso.
      Trabalhei no passado tanto na Cortana quanto na Alexa, e também pensei bastante em criar uma nova versão do zero com base nos avanços dos LLMs. A tecnologia, no geral, era intuitiva, e havia ideias de novos casos de uso que agora se tornaram possíveis, mas não encontrei um modelo de negócios que funcionasse. Por isso, hoje estou fazendo algo completamente diferente.
    • Quando descobri pela primeira vez o que era o ChatGPT, meu pensamento foi: “ah, então era isso que a Siri deveria ter sido desde o começo”.
    • Depois de usar o ChatGPT e o Bing, conversar com a Alexa chega a ser ridículo. É realmente frustrante ver hardware de boa qualidade ficar travado por anos por causa de software péssimo.
    • A Microsoft está fazendo isso no Windows 11 para substituir a Cortana.
    • Estou realmente ansioso por algo que possa ser usado para controlar o Home Assistant.
      Mas usar uma API baseada em nuvem para isso me deixa inseguro demais; quero algo que rode em um servidor dentro de casa. Ao mesmo tempo, o reconhecimento de voz e o tempo de resposta precisam ser muito rápidos, a ponto de não dar nenhuma sensação de espera.
      Já vi algumas tentativas DIY de assistentes pessoais, mas sempre havia um atraso considerável, e acho que isso ficaria irritante rapidamente com uso frequente.

  • Há uma parte dizendo que é fácil receber uma resposta como { "name": "grande latte" }.
    Mas, se o tipo é Item = { name: string; ... size?: string; }, não entendo bem como isso ajudaria a evitar name: "grande latte".
    A resposta de exemplo inclui "size": 16 e diz que isso é “muito bom”, mas na verdade nem retorna o tipo solicitado. Talvez seja um erro de digitação no exemplo; se for, a ideia em si parece legal.

    • Obrigado por apontar isso. Uma iteração anterior do post usava outro schema em que size estava especificado por engano como number. O schema foi alterado, mas o prompt não foi executado de novo, e agora isso deve estar corrigido.
    • Acho esse exemplo, no geral, bem fraco. O problema vai além de um simples erro de digitação.
      Para começo de conversa, provavelmente você nem quer um campo de string name. Nada impede que você receba valores como { name: “the brown one”, size: “the espresso cup”, … }, e isso é tão ruim quanto analisar a string original.
      Provavelmente você vai querer um grande tipo union de strings representando os valores conhecidos para cada campo. Assim, dá para fazer o LLM tentar se encaixar em um deles.
      Mas também me pergunto por que isso deveria estar amarrado à sintaxe de tipos. Algo como Zod, que permite construir esse tipo de union com dados em tempo de execução, parece mais adequado.
      Também são necessárias restrições como a quantidade ter de ser um inteiro positivo e não uma fração. Claro que dá para validar o valor JSON depois, mas aí o usuário verá dois tipos de erro: um emitido pelo LLM em linguagem humana fluente e outro estranhamente técnico, como “o valor da quantidade é grande demais”.
      A sintaxe de tipos parece o lugar errado para expressar esse tipo de coisa.
    • Parece simplesmente um bug na documentação. Na reta final da preparação do anúncio, devem ter mudado de número de onças para tamanhos padrão e esquecido de ajustar o valor de saída.
      Só com o código fornecido, o sistema não tem como mapear “grande” para 16, e 16 também não parece ser usado em nenhum outro lugar.
    • Como o parágrafo seguinte trata de “o que acontece se você ignorar o tipo”, talvez a intenção fosse essa.

  • Parece uma abordagem em que o LLM é executado repetidamente até emitir algo que passe na verificação de tipos, e então a mensagem de erro é usada para alimentar o prompt novamente.
    É uma ideia simpática e parece que funcionaria, mas com modelos grandes e prompts de entrada longos o custo pode ficar alto. Não parece ser a solução para todos os cenários.

    • Pelo menos na OpenAI, não seria melhor usar internamente o novo recurso de chamadas de função?
    • Não sei exatamente como o TypeChat funciona, mas o Guidance [1] também é um projeto parecido e consegue impor o formato integrando-se de fato à amostragem de tokens.
      [1]: https://github.com/microsoft/guidance
    • Acho que a maioria dos produtos vai se preocupar primeiro com adequação produto-mercado e depois tentar reduzir custos.
      Também há uma suposição bastante razoável de que, como o mercado está exigindo saídas estruturadas, os modelos também vão melhorar nessa direção.

  • Nesta semana criei e publiquei algo muito parecido com isso para Laravel PHP, mas com escopo menor: https://github.com/adrenallen/ai-agents-laravel
    Acho que engenheiros deveriam conseguir colocar no ar novos “bots” facilmente com um determinado LLM. Há muito trabalho tedioso em transformar funções em um formato que o ChatGPT consiga entender, processar as respostas e depois fazer o parsing de novo
    Usando um sistema assim, dá para se concentrar em escrever código PHP real e adicionar alguns comentários claros; então o bot pode usar esse código diretamente como uma ferramenta em qualquer tarefa
    Essa abordagem também torna o compartilhamento de código muito mais fácil. Quando alguém escreve uma função, você pode importá-la para um novo bot e usá-la imediatamente. O legal é que ela elimina a “camada de conversão para o LLM usar e entender”, e aumenta bastante a velocidade de desenvolvimento
    Ainda não é perfeito, mas acho que, para aproveitarmos melhor o código uns dos outros, tudo acabará indo nessa direção. Pensando em como usamos gerenciadores de pacotes na programação hoje, eu gostaria que houvesse um gerenciador de pacotes para ferramentas específicas de IA. Algo como instalar uma biblioteca de “buscar previsão do tempo”, adicioná-la ao meu bot e ele agora conseguir buscar a previsão do tempo

    • Dei uma estrela porque estou trabalhando em uma abordagem parecida, mas com escopo um pouco mais amplo. Algumas ideias são realmente muito elegantes

  • Espera, isso faz validação em runtime de objetos em relação a definições de tipos do TypeScript? Se pudesse ser distribuído como uma biblioteca ou recurso independente, poderia mudar completamente o jogo para validação de payloads de resposta de API em codebases TypeScript

  • É bem surpreendente que não estejam usando guidance [0] aqui
    Como ele pode sugerir o preenchimento de campos obrigatórios, poderia reduzir a necessidade de validação[1] e, no fim, talvez economizar tempo de GPU também
    Deve haver algum motivo, mas eu realmente gostaria de saber qual é
    À parte: eu estava justamente construindo algo assim, e parece que a Microsoft apareceu de repente e comeu o meu almoço
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...