- Byte Latent Transformer (BLT) é uma arquitetura de LLM em nível de byte que treina com bytes brutos sem tokenização de vocabulário fixo, mas ainda assim alcança desempenho comparável ao de LLMs baseados em tokenização em grande escala
- O ponto central é agrupar bytes em patches de tamanho dinâmico, em vez de tokens fixos, e alocar mais computação e capacidade do modelo em posições onde a entropia do próximo byte é mais alta
- A Meta conduziu um estudo de escalabilidade com FLOPs controlados até 8B de parâmetros e 4T de bytes de treinamento, verificando a escalabilidade de modelos em nível de byte
- Quanto mais previsíveis os dados, mais patches longos são escolhidos para aumentar a eficiência de treino e inferência, e melhorias qualitativas também aparecem em raciocínio e generalização de cauda longa
- Com custo de inferência fixo, a abordagem BLT, que amplia conjuntamente o tamanho dos patches e do modelo, apresenta melhor escalabilidade do que modelos baseados em tokenização
A estrutura de LLM em nível de byte proposta pelo BLT
- Byte Latent Transformer (BLT) é uma arquitetura de LLM em nível de byte que usa bytes brutos como unidade de entrada no lugar da tokenização baseada em vocabulário fixo
- Em configurações de grande escala, alcança desempenho comparável ao de LLMs baseados em tokenização, além de mostrar melhorias significativas em eficiência de inferência e robustez
Patches dinâmicos se tornam a unidade de computação
- O BLT codifica bytes em patches de tamanho dinâmico e usa esses patches como principal unidade de computação
- A divisão em patches é feita dinamicamente com base na entropia do próximo byte
- Em pontos onde a complexidade dos dados aumenta, mais computação e capacidade do modelo são alocadas
- Quando os dados são previsíveis, patches mais longos são escolhidos para reduzir a computação
Experimentos de escalabilidade com FLOPs controlados
- A Meta realizou um estudo de escalabilidade com FLOPs controlados voltado para modelos em nível de byte
- A escala dos experimentos chegou a 8B de parâmetros e 4T de bytes de treinamento
- Os resultados mostram que modelos treinados com bytes brutos, sem vocabulário fixo, também podem escalar
Resultados de eficiência e generalização
- O método de selecionar dinamicamente patches longos melhora tanto a eficiência de treinamento quanto a eficiência de inferência
- Nos resultados qualitativos, surgem melhorias em raciocínio e generalização de cauda longa
- Com custo de inferência fixo, o BLT apresenta melhor escalabilidade do que modelos baseados em tokenização
- É usada uma abordagem que aumenta simultaneamente o tamanho dos patches e do modelo
Material
- Download the Paper: baixar o artigo Byte Latent Transformer
1 comentários
Opiniões no Hacker News
Artigo: https://scontent-sjc3-1.xx.fbcdn.net/v/t39.2365-6/470135129_...
Eu trabalhava em uma startup que fazia classificação com um modelo CNN baseado em caracteres no verão em que o BERT saiu
A equipe pensava bastante em representações alternativas e, embora outros membros preferissem vetores de palavras, eu não gostava muito. Nos documentos com que lidávamos apareciam com frequência palavras que não estavam no dicionário, essas palavras eram importantes, e descartá-las parecia que levaria ao fracasso
Como nós também estávamos construindo um “modelo de base”, não era um problema apenas as palavras ficarem fora do vocabulário no modelo final, mas também ficarem fora do vocabulário na etapa do modelo de base, em que o custo de treinamento era maior
A classificação com o modelo baseado em caracteres funcionava bastante bem, mas havia uma percepção de que armazenar o “dicionário” dentro da rede neural não era uma boa forma de usar redes neurais, então havia muita expectativa em torno de tokens
Por outro lado, eu estava convencido de que abordagens como Word2Vec não tinham futuro, a ponto de já ter saído de um projeto anterior que treinava uma RNN para escrever resumos falsos de relatos de caso do PubMed a fim de criar um modelo de base para compreensão de texto
Quando surgiu a codificação por pares de bytes (byte-pair encoding), lembro de ter dito em uma reunião que era o primeiro método de tokenização, entre os que havíamos analisado, que eu conseguia apoiar
Ainda assim, sinceramente, continuo achando que seria bom poder trabalhar no nível de caracteres
Tokens são um paliativo. Em geral funcionam bem, mas, quando não funcionam, isso fica bem evidente
[1] https://arxiv.org/abs/2103.06874
No mundo real, pessoas criam e usam todos os dias palavras que não estão no dicionário para se comunicar. Por exemplo, “notify” está no dicionário, mas “notifier”, no sentido de “meio de notificar alguém”, não está; e um código que envia notificações por e-mail vira um “email notifier”. Depois vêm notificadores por mensagem de texto, chamada de voz, retorno de call center, e assim por diante
Toda indústria e organização tem jargões, palavras personalizadas fora do dicionário e abreviações pouco distintivas
Se não consegue lidar com a comunicação real e só consegue produzir respostas dentro do vocabulário higienizadas em estilo de laboratório, não sei como a saída de machine learning poderia ser útil
Tomara que isso dê certo. Tokenizadores precisam desaparecer
É interessante que seja uma estrutura hierárquica, mas com apenas dois níveis. Empilhar mais níveis parece uma direção natural para trabalhos futuros
Como referência, deixei este comentário também em outro post relacionado[1], e o autor respondeu assim
“Sou um dos autores :), acho uma ótima direção para investigar! Mas, além de aumentar bastante o trabalho para fazer tudo de uma vez, é preciso ter cuidado em como distribuir o orçamento de FLOPs por toda a hierarquia. Com dois níveis, dá para tornar um nível (codificador local/de bytes) eficiente em FLOPs e o outro nível (codificador global/de patches) intensivo em FLOPs. Também seria preciso encontrar formas de agrupar patches em unidades maiores. Ainda assim, há muitas direções a seguir a partir daqui!”
[1] https://news.ycombinator.com/item?id=42413430
Para criar os patches, eles usam um modelo pequeno para prever a probabilidade do próximo caractere da string de entrada
Se a string de entrada for “Lazy dog jumped over a fence.”, o modelo prevê a probabilidade de cada caractere
Por exemplo, ele pode ter 100% de certeza de que o próximo caractere é “a”, ou pode estimar “a” em 10%, “b” em 10%, e assim por diante
Em seguida, agrupa as estimativas de caracteres. Quantos caracteres? O suficiente para que a incerteza total de cada grupo, isto é, a entropia, fique parecida
Isso vira um patch, ou “token”
Eles usam apenas a entropia do próximo byte e verificam se ela ultrapassa um limiar (restrição global) ou se é maior que a entropia do byte imediatamente anterior por outro limiar (restrição aproximadamente monotônica)
Por isso, como mostra o Apêndice E, sequências longas e repetitivas podem levar a patches patologicamente longos
O que realmente me deixa curioso é o pequeno modelo CNN em nível de bytes que usa contexto de 2 bytes da Figura 3(f), mas ele não é mencionado em nenhuma outra parte do artigo
Post relacionado recente:
Meta FAIR compartilha novas pesquisas, modelos e datasets - https://news.ycombinator.com/item?id=42412360 - dezembro de 2024, 61 comentários
Isso significa que a única coisa que ensina o modelo, ou seja, a loss, é apenas a previsão de probabilidades no espaço de um único byte?
Se não entendi errado, isso por si só é suficiente, o que parece bastante promissor
Pelo que entendi, essa abordagem não elimina apenas a tokenização, mas também a amostragem?
A amostragem pode ser um problema nos LLMs, mas também permite usos interessantes, como impor uma gramática para que o modelo sempre produza JSON válido, ajustar a temperatura para obter distribuições mais diversas ou usar amostragem XTC
Qual seria o equivalente disso no BLT?
Só consigo pensar em passar bytes permitidos/proibidos como entrada adicional para o decodificador e repetir a decodificação até obter uma saída válida, mas talvez exista uma abordagem mais simples e óbvia
Assim como em modelos baseados em BPE, basta calcular o softmax apenas sobre os bytes permitidos na camada de saída e amostrar dali
Isso significa que a AI também poderia ser pré-treinada em binários?
Achamos que o ponto final é a AI escrever código por nós, mas talvez ela possa assumir de uma forma muito mais simples
É interessante ver o quanto abordagens linguísticas e baseadas na experiência saíram de moda
Humanos, embora consigam, normalmente não leem caractere por caractere. Temos radicais e também entendemos flexões. A tokenização não reproduz essa experiência, e isso fica especialmente claro ao observar os tokens que aparecem no vocabulário dos LLMs; o mesmo vale para codificações por caracteres ou bytes
Humanos têm várias formas de analisar palavras. Podemos entender uma frase inteira de uma vez, ler por sintagmas, ler palavra por palavra ou decodificar uma palavra nova som por som, caractere por caractere
Muito poucos artigos afirmam explicitamente que determinado método é bom porque reproduz a forma como humanos realizam uma tarefa ou percebem o mundo
À medida que a dependência de LLMs aumentar, acho que vamos querer alinhar os modelos mais de perto à nossa experiência. Assim, os erros cometidos pelos modelos também serão mais compreensíveis
A frase “ao contrário da tokenização, o BLT não tem um vocabulário fixo para patches”, se entendi corretamente, significa que o vocabulário de patches não é conhecido antes do treinamento
Depois que o treinamento estabelece o vocabulário de patches, imagino que a inferência use o mesmo vocabulário fixo. Caso contrário, não sei como poderia funcionar
Certo?