1 pontos por GN⁺ 2024-05-02 | 1 comentários | Compartilhar no WhatsApp
  • Se o objetivo padrão dos LLMs, prever o próximo token, for trocado pela previsão simultânea de vários tokens futuros, é possível extrair mais desempenho em geração de código e linguagem natural com os mesmos dados e orçamento computacional
  • A arquitetura usa vários heads de saída sobre um Transformer compartilhado e, na inferência padrão, utiliza apenas o head de próximo token, funcionando como a geração autorregressiva tradicional
  • Em modelos de código, um modelo de 13B parâmetros resolveu 12% mais problemas no HumanEval e 17% mais no MBPP do que um modelo comparável de previsão do próximo token, e o ganho foi mais nítido em modelos maiores
  • Os heads adicionais podem ser usados em decodificação autoespeculativa e um modelo de previsão de 4 tokens mostrou ganho de até 3× na inferência, enquanto um modelo de previsão de 8 bytes alcançou 6,4×
  • Em tarefas sintéticas, houve vantagem em induction heads e raciocínio algorítmico, e pode haver efeito de redução da diferença entre o teacher forcing no treino e a distribuição autorregressiva na geração

Método de previsão de múltiplos tokens

  • A modelagem de linguagem tradicional minimiza a perda de entropia cruzada para um único próximo token em cada posição
  • A previsão de múltiplos tokens amplia o objetivo de treino para prever os próximos n tokens de uma vez em cada posição
  • A arquitetura do modelo se divide em três partes
    • Um Transformer compartilhado cria a representação latente do contexto observado
    • n heads de saída independentes preveem em paralelo cada token futuro
    • Uma unembedding matrix compartilhada calcula as probabilidades finais dos tokens
  • A forma mais simples de inferência é a previsão autorregressiva comum usando apenas o head de previsão do próximo token, descartando os demais heads
  • Os heads extras também podem ser usados em decodificação autoespeculativa (self-speculative decoding), como em blockwise parallel decoding ou atenção em árvore no estilo Medusa

Implementação com eficiência de memória

  • Em uma implementação simples, é preciso manter em memória os logits e gradientes de todos os heads, aumentando o uso de memória da GPU
  • Nos LLMs atuais, o tamanho do vocabulário V é muito maior que a dimensão d da representação latente, então o vetor de logits vira o gargalo de memória da GPU
  • A implementação proposta executa o forward/backward de cada head de saída em sequência após o forward pass do corpo compartilhado
    • Os logits e gradientes de um head são liberados antes de passar ao próximo
    • No corpo principal, apenas o gradiente acumulado é mantido
  • Isso reduz o pico de uso de memória da GPU de O(nV + d) para O(V + d), sem aumentar o custo de runtime

Resultados experimentais em modelos de código

  • Nos experimentos com dados reais, modelos de previsão do próximo token e modelos de previsão de n tokens foram comparados com o mesmo número de parâmetros
    • Ao adicionar n−1 camadas aos heads de previsão futura, removem-se n−1 camadas do corpo compartilhado
  • Seis tamanhos de modelo, de 300M até 13B, foram treinados do zero com no mínimo 91B code tokens
  • Nas avaliações MBPP e HumanEval, modelos pequenos às vezes foram piores que o baseline, mas a previsão de múltiplos tokens passou à frente à medida que a escala aumentou
  • O modelo de 13B resolveu mais problemas que o modelo comparável de previsão do próximo token
    • HumanEval: 12% mais problemas resolvidos
    • MBPP: 17% mais problemas resolvidos
  • Em um ablation com um modelo de 7B treinado com 200B code tokens, foram comparados n=1, 2, 4, 6 e 8
    • n=4 foi consistentemente o melhor em pass@1, pass@10 e pass@100 no HumanEval e MBPP
    • Em APPS/Intro, n=6 ficou à frente
    • O tamanho ideal da janela pode variar conforme a distribuição dos dados de entrada

Velocidade de inferência e modelos em nível de byte

  • Foi aplicada decodificação autoespeculativa gulosa a um modelo 7B de previsão de 4 tokens, e a velocidade de decodificação foi medida em prompts de teste de código e linguagem natural não usados no treino
  • Os resultados mostraram ganho de velocidade de 3,0× em código e 2,7× em texto
    • Em código, em média 2,5 tokens aceitos vieram de 3 propostas
  • O modelo de previsão de 8 bytes registrou ganho de 6,4× na velocidade de inferência
  • No experimento com tokenização em nível de byte, um transformer 7B byte-level foi treinado com 314B bytes, equivalentes a cerca de 116B tokens
  • O modelo de previsão de 8 bytes resolveu mais problemas do que o modelo de previsão do próximo byte
    • MBPP pass@1: 67% mais problemas resolvidos
    • HumanEval pass@1: 20% mais problemas resolvidos
  • A previsão de múltiplos bytes pode ser um caminho para treinar modelos byte-level com mais eficiência

Várias epochs, fine-tuning e resultados em linguagem natural

  • Mesmo treinando por várias epochs com os mesmos dados, a previsão de múltiplos tokens manteve alguma vantagem sobre a previsão do próximo token
    • MBPP pass@1: +2,4%
    • HumanEval pass@100: +3,2%
    • As demais métricas foram parecidas
  • No fine-tuning em CodeContests, um modelo 7B pré-treinado com previsão de 4 tokens superou o baseline de próximo token em pass@k de forma geral
    • Mesmo quando o modelo de previsão de 4 tokens foi ajustado mantendo a perda n′=4, ele seguiu melhor que o baseline
    • No geral, o melhor resultado veio de remover os heads extras e fazer fine-tuning com target de próximo token
  • Em linguagem natural, um modelo 7B foi treinado com 200B tokens e avaliado em 6 benchmarks padrão de NLP
    • O modelo de previsão de 2 tokens teve desempenho parecido com o baseline de próximo token
    • O modelo de previsão de 4 tokens teve alguma queda de desempenho
    • Pode ser necessário aumentar o tamanho do modelo
  • A avaliação generativa em linguagem natural foi dividida entre tarefas de resumo e matemática
    • Em 8 benchmarks de summarization, os modelos n=2 e n=4 superaram o baseline de próximo token em ROUGE-L F1 tanto com treino de 200B quanto de 500B tokens
    • Na avaliação 8-shot do GSM8K, n=2 superou o baseline com 200B tokens, mas o padrão se inverteu após 500B tokens, e n=4 foi pior no geral

Induction e raciocínio algorítmico em tarefas sintéticas

  • Induction é o padrão em que, após aparecer “AB” em uma sentença, quando “A” reaparece depois, o modelo prevê “B” em seguida
  • Modelos com 1M a 1B de parâmetros nonembedding foram treinados no conjunto children stories, e a capability de induction foi medida com um conjunto de teste contendo nomes aleatórios de 2 tokens
  • Em modelos pequenos, com até 30M, a perda de previsão de 2 tokens melhorou bastante a formação da capability de induction
    • Acima de 100M, essa vantagem desapareceu
  • Em uma tarefa de aritmética polinomial, foram treinadas e avaliadas expressões em F7[X]/(X5) com unary negation, addition, multiplication e composition
  • A previsão de múltiplos tokens aumentou a acurácia em toda a faixa de dificuldade da tarefa e também melhorou bastante a generalização out-of-domain, embora com valores absolutos ainda baixos
  • O efeito de trocar a previsão do próximo token por previsão de múltiplos tokens foi maior do que aumentar o modelo de 30M para 100M

Por que isso pode funcionar

  • A previsão de múltiplos tokens pode aliviar a incompatibilidade de distribuição entre o treino com teacher forcing e a geração autorregressiva em tempo de inferência
  • A previsão do próximo token pode se concentrar em previsões de curto alcance e ignorar dependências de longo alcance
  • A previsão de múltiplos tokens dá maior peso implícito a tokens fortemente relacionados com os tokens que vêm depois
    • Isso pode ser interpretado como um reforço dos choice points
    • A ideia é que a geração útil de texto depende de escolher corretamente nesses choice points
  • Em uma formulação baseada em teoria da informação, a previsão de 2 tokens aparece como uma forma de ampliar a importância dos termos de mutual information entre X e Y em comparação com a previsão do próximo token

Limitações e custos

  • Entre as questões em aberto estão como escolher n automaticamente na previsão de múltiplos tokens, usar loss scale e loss balancing, ajustar o tamanho do vocabulário e desenvolver uma perda auxiliar de previsão que opere no espaço de embedding
  • O treinamento de todos os modelos experimentais consumiu cerca de 500K GPU hours no total
    • O hardware usado foi A100-80GB e H100
    • A emissão total estimada foi de cerca de 50 tCO2eq, compensada em 100% pelo programa de sustentabilidade da Meta
  • O objetivo é melhorar a eficiência computacional e de dados dos modelos de linguagem, mas é preciso considerar efeitos rebote e ponderar tanto os benefícios sociais quanto os riscos dos LLMs

1 comentários

 
GN⁺ 2024-05-02
Opiniões do Hacker News
  • Há coisa demais acontecendo nessa área
    Seria bom ter um material que explicasse, em ordem cronológica, como uma visita a uma fábrica, em que momento termos como dados, pré-treinamento, treinamento, inferência, mistura de especialistas, RAG aparecem no fluxo real
    Na maior parte das vezes, não sei onde os termos se encaixam no panorama geral; quando vi pré-treinamento pela primeira vez, achei que fosse um processo de tratar os dados antes do treinamento, mas na verdade era mais um tipo de treinamento

    • Não saber onde os termos se encaixam no panorama geral também vale para muitos especialistas e consultores de IA que aparecem no LinkedIn, Twitter e podcasts
      A relação sinal-ruído nessa área é muito baixa, e até a documentação de líderes do setor como a Langchain às vezes já está desatualizada ou se contradiz
      Foi parecido durante a febre do blockchain, então parece ser uma característica do trem do hype
    • Dá para sentir dor e empolgação ao mesmo tempo
      Especialmente em coisas como RAG, em que os avanços recentes são tão rápidos que será difícil haver, por um tempo, um livro de referência que se mantenha atualizado, então é difícil saber por onde começar
      Ainda assim, a documentação de ferramentas de nível mais alto como o LlamaIndex é um bom ponto de partida, porque mostra onde elas entram no quadro geral, em vez de explicar os conceitos em si em profundidade
      O YouTube, como sempre, tem um mar de não especialistas tentando atrair cliques com a moda do momento, então não o considero um bom ponto de partida
    • Vale a pena ver o blog da Lilian Weng: https://lilianweng.github.io/posts/2023-01-27-the-transforme...
    • Recomendo Machine Learning Q and AI, de Sebastian Raschka
    • Hoje as pessoas gastam tempo demais criando coisas realmente péssimas com IA
      Claro que isso acontece com tudo, mas, em vez de tentar remendar essas coisas, é melhor assumir que, em um futuro próximo, surgirá algo muito melhor que o GPT-4 e projetar um produto diferenciado com base nessa premissa
  • Para quem conhece decodificação especulativa, isto é basicamente decodificação especulativa de si mesmo
    A sequência de rótulos prevista ainda é alimentada de volta na rede de forma autorregressiva, e as previsões só são mantidas até o ponto em que coincidem
    Por isso, o desempenho não piora, apenas fica mais rápido; aqui chega a até 3x, o que é comum em decodificação especulativa
    Pode até melhorar graças ao aprendizado multitarefa. A ideia de prever alvos vários passos à frente como perda auxiliar já é bem antiga, e é um bom trabalho

    • O problema da decodificação especulativa é que quase nenhum modelo a suporta, e acrescentar suporte exige tempo extra de GPU
      Se a decodificação especulativa também melhorar o desempenho de planejamento, ela será adotada com mais facilidade
    • A frase “o desempenho não piora, apenas fica mais rápido” é um pouco confusa
      A decodificação especulativa não reduz o desempenho do modelo em termos de precisão ou qualidade da saída
      Matematicamente, a distribuição alterada da qual se faz amostragem é a mesma que seria obtida com a decodificação autorregressiva regular, e as diferenças ocorrem apenas por aleatoriedade simples
      Se você usou desempenho no sentido de velocidade, a decodificação especulativa pode sim reduzir a velocidade, mas isso não deveria acontecer para a maioria das entradas e com uma escolha adequada do modelo de rascunho
  • LLMs não consideram a distribuição de probabilidade de todas as combinações possíveis de tokens até um certo comprimento de saída na previsão de sequências? Eu achava que já faziam isso
    Se não fazem, é surpreendente que funcionem tão bem como funcionam hoje
    Por exemplo, se as possibilidades e probabilidades de uma sequência de 2 bits forem 00: p=0,36, 01: p=0,04, 10: p=0,30, 11: p=0,30, a sequência de 2 bits mais provável é 00
    Mas, se você prevê apenas o próximo token, 0: p=0,40 e 1: p=0,60, então o próximo bit parece ser 1, o que leva a um ponto de partida não ideal ao prever o bit seguinte
    Em sequências longas, quanto menos a distribuição de probabilidade conjunta se decompor bem nas distribuições marginais, mais evidentes serão os erros
    Pensando melhor, parece possível fazer um estudo simples alterando a função de perda de entropia cruzada para considerar apenas o n-ésimo token futuro nos dados de treinamento de texto e traçar a relação entre desempenho do LLM e n
    A hipótese é que, assumindo que os LLMs atuais sejam todos n=1, seria possível contornar em grande parte a explosão de recursos necessária para prever a distribuição de probabilidade conjunta de 1 até n próximos tokens
    Isso porque prever diretamente o n-ésimo token exige implicitamente um modelo de dados melhor. Pelo menos em textos criados por humanos; não necessariamente para todos os tipos de dados

    • Acho que é preciso olhar por uma perspectiva um pouco diferente
      LLMs são projetados para amostrar textos que seguem a distribuição de treinamento, não para dizer qual é o texto “mais provável” que vem a seguir; e, na prática, não é isso que queremos
      Isso acabaria com a diversidade das saídas
      No exemplo, para uma aplicação de chat, faz sentido amostrar 0 em 40% dos casos e 1 em 60%
      Em usos como perguntas e respostas, em que a frase mais provável importa, a busca em feixe ajuda, como outras pessoas comentaram
      Também é preciso considerar que o modelo pode “olhar à frente” e calcular tokens futuros antecipadamente, usando isso depois na previsão do token atual
      De fato, estudos como [1] tratam disso
      Por fim, prever um token por vez é a forma como humanos falam, então não é uma abordagem errada. Nós fazemos esse tipo de “antecipação” na cabeça antes de falar
      [1] https://arxiv.org/abs/2404.00859
    • Na verdade, é assim que funciona, e isso se torna um problema real ao prever com temperatura baixa
      Pelo que me lembro, aparecem padrões estranhos na saída de LLMs; por exemplo, muitas vezes “an” é menos provável que “a”, então surgem menos substantivos iniciados por vogal do que o esperado
    • Modelos de linguagem decompõem a probabilidade conjunta p(y, x) como p(y, x) = p(y|x) p(x), e isso é correto
      Ou seja, se você treinar um modelo de linguagem em uma determinada distribuição e fizer amostragem com temperatura 1, obterá exatamente a mesma distribuição
      Se fizer amostragem com temperatura baixa ou de forma gulosa, naturalmente obterá outra distribuição
    • Isso é basicamente um problema de amostragem gulosa do decodificador
      Há várias estratégias de amostragem de otimização local, como busca em feixe, e também já houve muitos trabalhos de amostragem mais global, como decodificação especulativa
    • Você está misturando a entropia cruzada/surpresa do próximo token, que é a perda de treinamento, com coisas como busca em feixe, que são decodificação preditiva após o treinamento
  • Os LLMs atuais realmente começam do zero a cada token de saída?
    Se eu pergunto “O que torna as bananas amarelas?” e ele responde “Bananas are yellow due to a pigment called bromelain.”, parece que, ao emitir “a”, os conceitos de pigment e bromelain já estariam ativados em algum grau dentro da rede neural.
    Como agora ele não pode mudar de ideia e continuar com uma resposta como “an optical illusion...”, parece que já havia planejado à frente que falaria da bromelina como pigmento.
    Será que o trabalho que o LLM já fez ao emitir “a” pode ser aproveitado na resposta seguinte? Será que o estado da rede neural pode ser preservado para a resposta seguinte?

    • Vendo por outro ângulo, dá para pedir ao GPT que complete a próxima frase:
      “Bananas are yellow due to a” e “Bananas are yellow due to an”
      No primeiro caso, ele poderia responder “Bananas are yellow due to a pigment called bromelain.”; no segundo, “Bananas are yellow due to an organic compound called bromelain, which is a yellow pigment.”
      Em qualquer um dos casos, mesmo que o GPT escolha “a” ou “an”, isso pode não afetar o significado da resposta.
      Num extremo, também dá para ver o LLM como algo que segue uma heurística burra em que o próximo token depois de “due to” é “a” com 55% e “an” com 45%.
      A realidade, claro, é mais sofisticada, mas só essa heurística já explicaria esse comportamento.
      Se os dados de pré-treinamento não tivessem incluído fatos relacionados à bromelina, o LLM poderia de fato autocompletar algo como “an optical illusion”.
      Pelo que me lembro, o GPT-3 cometia erros factuais desse tipo com bastante frequência, mas tinha aprendido as regras gramaticais de “a” e “an”.
      Como foi dito, não acho que os conceitos precisem realmente estar ativados de antemão, mas, em um sentido implícito e emergente, é possível que ocorra essa pré-ativação.
    • Até certo ponto, a atenção é um mecanismo que torna os cálculos dos tokens anteriores úteis mais tarde.
      O cache KV pode ser visto como uma representação do texto até agora e dos pensamentos do modelo sobre ele.
      Como modelos de linguagem treinam sobre a sequência inteira até o fim, acho bem provável que esse tipo de coisa aconteça.
      A previsão de múltiplos tokens incentiva explicitamente esse comportamento, mas apenas dentro da pequena janela de n tokens definida.
      Enquanto isso, há muitos trabalhos tentando aumentar o aproveitamento computacional de modelos de linguagem transformer, como early exit, mixture of depths e novas arquiteturas como SSM.
    • A saída de um LLM normalmente é amostrada aleatoriamente entre alguns dos próximos tokens/palavras mais prováveis, mas o modelo em si não sabe qual palavra o amostrador vai escolher.
      Provavelmente existe algum planejamento conceitual sobre o que poderia vir depois de “a” ou de outros candidatos, mas essa previsão de alto nível é reconsiderada do zero quando “a” é gerado.
      O modelo não só pode mudar de ideia depois que cada palavra é gerada, como precisa fazer isso.
      Por isso esse tipo de “planejamento” é muito efêmero, e se parece mais com um rapper de freestyle improvisando do que com uma pessoa que pensa profundamente para escolher a resposta e a formulação.
    • Este texto é interessante: https://clementneo.com/posts/2023/02/11/we-found-an-neuron
    • A maior parte das saídas de LLMs é probabilística.
      O LLM central recebe tokens e gera um conjunto ranqueado de tokens que podem vir em seguida, junto com um “grau de confiança”.
      Depois normalmente há uma etapa de filtragem e busca, em que esses tokens ranqueados são passados de volta ao LLM para obter mais tokens ranqueados e construir uma pequena árvore de probabilidades.
      Por exemplo, se você passa novamente os N tokens mais prováveis, cada um deles gera um novo conjunto dos N tokens mais prováveis.
      Observando essa árvore, dá para aplicar uma filtragem básica escolhendo o ramo com maior confiança somada, o ramo com menos tokens repetidos, ou o ramo com menos tokens que coincidem com os tokens de entrada; em geral, combina-se esses critérios e ainda se adiciona uma escolha aleatória ponderada pela confiança somada.
      Por isso, mesmo dando a mesma entrada várias vezes a um LLM com pesos totalmente fixos, as saídas podem ser diferentes.
      Ou seja, respondendo à pergunta específica, o modelo pode “mudar de ideia”. Todo token gerado dá ao filtro probabilístico de saída uma oportunidade de escolher um novo caminho entre os caminhos de saída possíveis.
  • Pode ser uma pergunta bem ingênua, mas, supondo que seja possível criar um vetor que codifique o significado de uma frase inteira, por que não poderíamos treinar um LLM para prever esse vetor de frase em vez de uma única palavra?

    • Sou o autor. Esse é um ponto muito bom e, pelo que entendo, há várias equipes trabalhando nisso
      Treinar um autoencoder para linguagem é, na prática, muito fácil, porque a quantidade de informação contida em texto é pequena em comparação com visão/vídeo
      A parte difícil é fazer o modelo se concentrar na parte semântica quando todos os sinais vêm da correspondência exata no espaço de tokens
      É daí que vem a ideia de arquitetura preditiva de embeddings conjuntos de Yann LeCun
      Além disso, com tarefas auxiliares sempre há o trade-off de dar mais sinal, mas deslocar o foco
      No nosso caso, vimos queda de desempenho quando o número de tokens previstos era grande demais
      Portanto, métodos de previsão latente precisam esclarecer o que é útil
    • Não acho que seja uma pergunta boba
      O problema é que, depois de obter um vetor que representa a resposta, você precisa de algo como outro modelo para converter essa resposta de volta em uma representação em palavras
      Poderia ser algo como um modelo de difusão para texto
      Além disso, a função que esse modelo de difusão teria de aproximar não é injetiva; na melhor das hipóteses é sobrejetiva e, na pior, talvez nem seja uma função no sentido matemático
      Isso porque, para um único embedding, há muitas representações textuais possíveis, e a maioria delas pode não ser válida gramatical ou semanticamente
      Por fim, embeddings são uma representação com perdas de algum dado, então a função inversa perde muitas nuances e contexto
      O LLM evita esses problemas prevendo o próximo token — agora os próximos n tokens — de modo a manter autoconsistência com a consulta e os n tokens anteriores, e a função que eles aproximam, em geral, deveria estar mais próxima de uma sobrejeção
    • Também sou iniciante, mas, se codificarmos, treinarmos e sintetizarmos vetores de frases, a capacidade da IA de criar coisas novas não subiria do nível das palavras para o nível das frases?
      Hoje ela lida, grosso modo, com palavras, então a IA só pode usar palavras que conhece, mas consegue sintetizar novas frases com elas
      Se a IA operar em unidades de frase, ela não ficaria apenas repetindo frases que já viu? Nesse caso, talvez consiga sintetizar novos parágrafos, mas não novas frases
      Em inglês, não tenho certeza de que frase seja uma abstração útil para IA. Mesmo para humanos, ela mal chega a ser útil
      Quando se olha para conversas comuns, e-mails e comentários do YouTube, há muitíssimos casos que na prática não são frases ou nem usam pontuação
      Não vejo frases como correspondendo a unidades de significado
      Uma frase pode ter duas palavras ou metade de um artigo acadêmico em inglês, dependendo do autor; pode atravessar seis ideias ou conter apenas uma
      Onde uma frase termina depende, em geral, mais do estilo do autor do que do significado
    • Entendo que a tokenização é parte do gargalo
      Ao quebrar uma frase em tokens, cada token ganha uma representação vetorial
      Se formos para o nível de frases, o vocabulário de todos os tokens se tornaria infinito
    • Ainda assim, seria preciso converter de alguma forma entre vetores de palavras e de frases
      Talvez dê para fazer isso com um modelo mais rápido, mas acho que a qualidade da saída cairia
  • Ainda não li o artigo com muito detalhe, mas tenho um pequeno comentário editorial
    O Apêndice L.2 foi satisfatório, mas achei a argumentação comprimida da seção 5.2 um pouco frágil
    Em particular, a parte em que se diz que se “descarta” H(Y | X) em H(X) + H(Y) = H(X | Y) + 2I(X ; Y) + H(Y | X) não ficou clara
    Se estamos prevendo um terceiro token Z, H(Y | X) não deveria estar dentro do contexto implícito C e, portanto, não seria algo que possa ser descartado livremente?
    Também não me parece que esse argumento tenha ficado claro no apêndice
    Ainda assim, não fiquei confuso a ponto de duvidar do cerne da afirmação; é sobretudo uma questão de formulação

    • Obrigado pelo feedback. Tentando explicar melhor: no fim, para geração usamos apenas a cabeça do próximo token
      Então, entre os alvos de 2 tokens H(X) + H(Y), que parte é informação auxiliar que ajuda o treinamento e que parte é desperdício?
      H(X | Y) e I(X; Y) são úteis para gerar o próximo token, mas H(Y | X), por definição, é uma quantidade de informação não relacionada ao próximo token X
      Por isso dá para dizer que “a previsão multitoken troca a informação útil I(X; Y) de H(Y) por computação desperdiçada em H(Y | X)”
      Mas é preciso observar que H(Y | X) é a entropia do próximo token ao prever Y a partir do prefixo (C, X)
      Se o mecanismo de atenção puder transferir para a etapa seguinte a computação que já fez para prever Y|X, então essa computação pode, na verdade, não ter sido desperdício, mas pré-computação
  • Li um texto dizendo que LLMs literalmente só têm uma janela unidimensional para o mundo
    Tudo é apenas uma sequência de tokens
    Talvez algo como essa previsão múltipla amplie esse campo de visão para algo como 1,1 dimensão
    De qualquer forma, há um argumento real de que precisamos expandir essa janela para duas dimensões ou mais de algum jeito

    • Estruturalmente, parece haver muito espaço para melhorar, especialmente em tarefas de programação
      Por exemplo, se você tiver recursos no nível da FAIR e quiser treinar um modelo realmente bom de programação em Java, faz sentido treiná-lo para prever uma AST, não tokens
      Para prever comentários, nomes de identificadores etc., provavelmente ainda seria necessária alguma forma combinada com um LLM comum, mas eu não modelaria o programa em si como um fluxo de tokens
      Em vez disso, poderia fazê-lo prever coisas como “adicionar bloco if”, “adicionar bloco de chamada de método com 4 parâmetros”
      Também seria possível treinar o modelo para reservar certas posições da janela de contexto para informações como os membros do tipo no cursor atual e integrar o loop de inferência com análise estática no estilo IDE/LSP
      Assim, o modelo poderia ver mais informações do que as contidas no texto real
      Acho que a razão pela qual não vemos muitos modelos assim hoje é que esse tipo de pesquisa é caro, e as pessoas de IA são todas centradas em Python, enquanto Python não se beneficia tanto de uma IDE
  • Em machine learning, a palavra head não é usada de forma consistente, o que pode confundir
    Neste artigo há tanto o conceito de multihead attention quanto o de multiple output heads
    Multihead attention, na arquitetura transformer, significa concentrar-se em diferentes áreas da entrada; aqui, a metáfora biológica fica mais próxima de uma cabeça como unidade central de processamento
    Output head significa a última camada de uma rede neural, e pode haver várias delas produzindo saídas diferentes a partir das mesmas camadas anteriores
    Isso também é uma metáfora biológica frouxa, mas está mais próxima da cabeça em uma das extremidades do corpo do que de uma cabeça como CPU
    Nenhum dos dois é uma metáfora para uma cabeça de fita que lê dados

  • LLMs parecem, em grande parte, “pensar” ao realimentar sua própria saída como entrada, e por isso se observa continuamente que forçar o modelo a pensar em voz alta aumenta a qualidade do raciocínio.
    Ou seja, diferentemente de fazer a pergunta e responder diretamente, o raciocínio em cadeia de pensamento faz o modelo reformular o que foi solicitado, expressar uma estratégia de alto nível sobre quais informações serão necessárias para responder, dizer o que sabe e explicar como essas informações afetarão a inferência inicial.
    Mas me preocupa que fazer o modelo prever vários tokens seguintes a cada passo tenha, por natureza, o efeito oposto.
    O prompting de cadeia de pensamento parece mostrar que o modelo é mais “inteligente” quando tem n + m tokens como entrada do que quando tem apenas n tokens.
    Portanto, obter os próximos 5 tokens dado n pode produzir resultados piores do que obter o próximo 1 token em n, depois o próximo 1 token em n+1, e assim por diante.

    • Se houver um modelo suficientemente barato para LLMs, ele sempre vai gerar tantos tokens quanto forem necessários para a tarefa.
      O fato de este método específico exigir mais tokens não é importante.
      Se não houver um modelo barato, estaremos sempre sujeitos ao viés de o LLM tentar responder com uma estimativa em vez da resposta real.
      Além disso, a maioria das estratégias de decodificação especulativa produz a mesma saída que executar o modelo sequencialmente.
      Se a previsão estiver errada, esse token é descartado e apenas o ganho de velocidade desaparece.
  • Se os tokens/palavras +1 e +2 forem previstos de forma independente, como o resultado ainda pode fazer sentido gramaticalmente? Parece que isso quebraria com frequência, não?

    • As previsões +1 e +2 são simplesmente descartadas e geradas apenas para um treinamento mais eficiente.
      Isso não fica claro no resumo, mas a explicação da Figura 1 diz: “durante a inferência, usa-se apenas a cabeça de saída do próximo token. Opcionalmente, as outras três cabeças podem ser usadas para reduzir o tempo de inferência”.
      Se você pegar todas as previsões superiores, talvez possa usar as três cabeças, mas aí não conseguiria usar estratégias comuns de amostragem.
      Não sei quantas pessoas realmente rodam LLMs com temperatura 0 fora de benchmarks; e, se fizerem algo melhor do que aplicar temperatura, pode ser diferente.
    • O token n+1 é descartado se tiver baixa probabilidade dado o token n.