Técnica para detectar automaticamente tokens under-trained em grandes modelos de linguagem

• Os LLMs separam a criação do tokenizador do treinamento do modelo, o que faz com que certos tokens, como _SolidGoldMagikarp, possam produzir comportamentos inesperados
• O centro do problema são os under-trained tokens, que existem no vocabulário do tokenizador mas quase nunca ou nunca aparecem durante o treinamento, e que muitas vezes são chamados de glitch tokens
• O estudo propõe um método para encontrar esses tokens automaticamente, combinando análise do tokenizador, métricas baseadas nos pesos de embedding do modelo e técnicas de prompting
• Esses tokens podem desperdiçar a capacidade de vocabulário de tokenizadores de tamanho fixo e afetar o comprimento de entrada e saída, o custo de inferência, além de alucinações ou saídas corrompidas
• Em ambientes com uso de ferramentas e agentes que buscam e processam dados externos, detectar e depurar tokens under-trained está diretamente ligado à segurança e à robustez dos modelos em produção

---

Desalinhamento entre tokenizador e treinamento do modelo

• A maior parte dos componentes de um LLM é aprendida de forma não supervisionada em grandes volumes de dados, mas o tokenizador normalmente é treinado separadamente, com algoritmos distintos e um conjunto de dados menor
• O GPT-2 estabeleceu muitas das bases atuais da modelagem de linguagem com Transformers, e sua estrutura de tokenização baseada em byte-pair encoding (BPE) também foi amplamente adotada
• A tokenização BPE converte o texto de entrada em uma sequência de tokens de subpalavras e faz fusões repetidas de dois tokens adjacentes segundo regras fixas de merge
• As regras de merge são aprendidas por um algoritmo guloso em um conjunto de dados menor, que precisa ser representativo em relação aos dados usados no treinamento do LLM

Como surgem os glitch tokens

• Quando o tokenizador e o treinamento do modelo são separados, alguns tokens podem acabar em um estado em que quase nunca ou nunca aparecem durante o treinamento do modelo
• Quando esses tokens aparecem na entrada, podem provocar comportamentos inesperados, como alucinações ou saídas corrompidas
• O estudo distingue esses tokens como under-trained tokens ou untrained tokens
  • untrained é usado apenas quando há indícios claros de que um token específico não apareceu nos dados de treinamento do modelo
  • De forma geral, eles também são chamados de glitch tokens
• Um caso representativo citado é o token _SolidGoldMagikarp

Limites dos métodos atuais de tokenização e alternativas

• Pesquisas recentes também abordaram a remoção da tokenização e a migração para entrada em bytes brutos, mas essa escolha normalmente traz um alto custo de velocidade de inferência
• Esse custo de velocidade pode ser compensado com arquiteturas especiais nas camadas iniciais e finais, ou com computação variável nas camadas intermediárias
• Essas abordagens ainda não foram amplamente adotadas, e a maioria dos modelos modernos continua dependendo de tokenização por subpalavras
• A principal alternativa ao BPE é o método Unigram, mas, apesar de haver estudos indicando vantagens sobre o BPE, ele em geral não é muito utilizado

Problemas práticos dos tokens under-trained

• Tokens under-trained ocupam capacidade de vocabulário em tokenizadores de tamanho fixo que poderia ser usada por tokens mais frequentes
  • Isso pode fazer com que se perca a chance de reduzir o comprimento médio de entrada e saída e o custo de inferência
• Quando esses tokens são incluídos nos dados de entrada de forma intencional ou acidental, podem gerar saídas indesejadas do modelo e quebrar aplicações downstream
• Com o aumento do uso de ferramentas em LLMs e de agentes que buscam e processam dados externos, a robustez contra entradas inesperadas ou maliciosas se torna ainda mais importante
• Quando o modelo é empurrado para fora da distribuição de treinamento, esses tokens também podem ser explorados para contornar guardrails

Abordagem de detecção automática e ferramenta pública

• Já existiam trabalhos tentando encontrar esses tokens por meio de análise do modelo e do tokenizador, mas ainda faltava um método automatizado confiável que funcionasse de forma consistente em diferentes modelos
• O estudo combina três métodos para identificar tokens problemáticos
  • análise do tokenizador
  • métricas baseadas nos pesos de embedding do modelo
  • técnicas de prompting
• Esses métodos foram aplicados a vários modelos com pesos abertos populares e lançados recentemente, e o trabalho também explora brevemente como estendê-los a modelos fechados
• Também foram disponibilizados uma ferramenta geral de análise compatível com modelos do Hugging Face e resultados detalhados por modelo
  • cohere-ai/magikarp

[GN⁺]

Opiniões no Hacker News

• Gostei do vídeo do Computerphile de um ano atrás sobre tokens com glitch: https://www.youtube.com/watch?v=WO2X3oZEJOA

  • De algum modo, esse vídeo parece mais interessante do que o preprint do artigo

• Em vez de procurar apenas tokens subtreinados, como tokens são, na prática, a primeira camada da rede neural, também deveríamos procurar desequilíbrios nos dados de treinamento em todos os pesos de todas as outras camadas
  Ao encontrar esses pesos, talvez seja melhor remover aqueles por onde quase não passam dados, o que poderia tornar o modelo menor ou ajudar na generalização

  • Acho que a destilação de modelos faz isso. SparseGPT foi um grande exemplo e, se me lembro bem, removeu 50% dos parâmetros sem grande perda de precisão
    Vi também um artigo recente que citava o SparseGPT e chegava a uma esparsidade de cerca de 70% a 80%, o que foi bem impressionante
  • “Remover pesos por onde quase não passam dados” não é a ideia de uma rede neural esparsa?
  • Modelos regularizados já podem ser comprimidos ou mesclados

• É meio difícil acreditar que um modelo de uma empresa canadense tivesse tokens subtreinados relacionados a hóquei, mesmo que fossem em alemão
  Brincadeiras à parte, é um conteúdo bem legal, e espero entender melhor o impacto da tokenização nos modelos. Chama atenção, em especial, a descoberta de que muitos dos primeiros modelos open source tinham problemas com retornos de carro; dependendo da origem dos dados, retornos de carro podem aparecer com certa frequência

• Existem métodos de diagnóstico de treinamento baseados em teoria de matrizes aleatórias, que usam a densidade espectral da matriz de correlação dos pesos
  Eles ajustam a densidade espectral de cada camada a uma lei de potência truncada e consideram que ela foi treinada corretamente quando o expoente alfa da lei de potência é um pouco maior que 2
  https://jmlr.org/beta/papers/v22/20-410.html

• A solução não seria simplesmente treinar o tokenizador com o mesmo corpus do LLM? Não entendo muito bem por que a reutilização de tokenizadores é tão comum. Alguém sabe?

  • Além do que outras pessoas disseram, mesmo que seja possível treinar o tokenizador exatamente com o mesmo conjunto de dados de treinamento, isso não elimina todos esses problemas
    Em métodos BPE, um token pode se fundir com outro e criar tokens muito raros. Se há tokens X e Y, e quase todo X é seguido por Y, o processo de BPE cria um novo token XY, mas não remove o token X original, deixando X subtreinado
    Para resolver isso, parece que seria necessário um algoritmo de fusão mais sofisticado do que uma fusão gulosa
  • Vejo dois motivos para reutilizar tokenizadores
    Primeiro, quando se quer continuar o pré-treinamento de um modelo em vez de começar do zero. Dito isso, talvez algumas pessoas não saibam que, mesmo treinando com um novo tokenizador, é relativamente fácil reutilizar os pesos do modelo. Escrevi um texto sobre esse método: https://umarbutler.com/how-to-reuse-model-weights-when-train...
    Segundo, pela conveniência para o usuário final. Tokenizar um corpus muito grande e dividi-lo em chunks pode levar bastante tempo; se for possível processá-lo uma vez com o tokenizador do GPT-2 e depois treinar vários modelos com os mesmos dados, é bom não precisar tokenizar tudo de novo
  • Pelo resumo, essa técnica parece útil quando não se tem acesso ao corpus. Por exemplo, quando é possível baixar pesos open source, mas o corpus é privado
    Caso contrário, imagino que bastaria calcular um histograma de tokens a partir de uma amostra estatística do corpus
  • Em geral, a ideia inicial é usar o mesmo corpus para o tokenizador e o LLM, mas, depois de treinar o tokenizador, ao testar o LLM, descobre-se que uma parte do corpus é lixo inútil
    Sem querer desmerecer o SolidGoldMagikarp pelo esforço no subreddit counting, mas essas partes acabam excluídas do treinamento posterior. Só que, a essa altura, o tokenizador já virou parte da API; trocar por uma nova versão quebraria outras coisas, e os tokens desnecessários acabam ficando no vocabulário
  • É possível, mas, se o corpus for muito grande, é difícil na prática

• O título do artigo é realmente excelente

  • O título completo é “Fishing for Magikarp: Automatically Detecting Under-trained Tokens in Large Language Models”