Tokenization I: caracteres, palavras e subpalavras

01 · Conceito

Conceito

Pegue a palavra inglesa unbelievability e faça uma pergunta de projetista: quantas unidades o modelo deveria gastar com ela? Três respostas já foram tentadas em produção, e vale trabalhar as consequências de cada uma antes de qualquer terminologia chegar.

Soletre um caractere por vez e ela custa quinze unidades. O vocabulário necessário é minúsculo, algumas centenas de entradas cobrem quase todo texto em escrita latina, e nenhuma palavra fica irrepresentável. Mas agora toda frase se estica por cinco ou seis vezes mais posições e, como a track 4 vai mostrar, o trabalho de um transformer cresce com as posições e não com os caracteres. Você deixou o modelo barato de armazenar e caro de rodar.

Guarde-a como uma palavra inteira e ela custa uma unidade — desde que alguém a tenha colocado no vocabulário. Se não colocou, o modelo recebe um símbolo desconhecido e a distinção entre unbelievability e incomprehensibility é destruída na porta de entrada. Nomes, flexões, jargão de domínio, erros de digitação e palavras inventadas terça-feira passada caem todos no mesmo buraco. Nenhuma lista finita de palavras fecha sobre texto aberto, e aumentá-la tem um preço próprio ao qual chegaremos.

Divida-a como un, believ, abil, ity e ela custa quatro unidades, com pedaços reutilizáveis em milhares de outras palavras. Isso é tokenization por subpalavras, e é o que essencialmente todo modelo moderno faz, o Qwen3.8-27B incluído. Strings frequentes ficam inteiras; as raras são compostas. Os pedaços são aprendidos de um corpus por um algoritmo, e a lição 1.3 acompanha um desses algoritmos merge a merge.

A variante do Qwen desce mais um degrau. Seu tokenizer aplica normalização NFC e um pré-tokenizador ByteLevel antes do BPE. A base derivada de bytes soletra todo byte UTF-8 produzido por uma string Unicode válida, então escritas desconhecidas e emoji não precisam colapsar num token desconhecido. Isso não é uma rota de fallback — a configuração BPE publicada diz byte_fallback: false e não declara token desconhecido — nem faz a API pública de texto aceitar binário arbitrário. A cobertura de texto Unicode normalizado é ampla; a eficiência não, pois strings incomuns podem se expandir em cadeias longas de pedaços derivados de bytes.

Note que nenhuma dessas divisões é um fato sobre a língua. Até palavra é ambíguo. Dá-lhe é uma palavra ou duas? A pontuação gruda? O chinês não coloca espaço nenhum entre palavras. O alemão solda alegremente quatro conceitos num composto só. Ainda assim, um tokenizer precisa devolver uma resposta determinística para toda string Unicode válida, inclusive strings que seus projetistas jamais imaginaram, então as fronteiras que ele traça são estatísticas, não linguísticas. Uma divisão pode parecer absurda para uma pessoa e ainda assim ser a escolha certa de engenharia.

Agora o número no arquivo de configuração, que é onde esta lição justifica seu lugar. O Qwen3.8-27B declara 248.320 linhas de vocabulário. O erro óbvio é ler isso como o modelo conhece 248.320 palavras, e o erro mais sofisticado — o que pega quem já sabe melhor — é ler como o tokenizer pode emitir 248.320 tokens distintos. Nenhum dos dois é garantido por esse campo. O que vocab_size governa é um shape de tensor: o número de linhas da matriz de embeddings e o número de colunas da projeção de saída que produz os logits.

Os artefatos do tokenizer tornam a diferença mensurável. O modelo BPE contém 248.044 entradas, e 33 tokens adicionados ocupam ids até 248.076, totalizando 248.077 ids mapeados. A configuração do modelo define $\text{vocab\_size}=248{,}320$, então os tensores de embedding e saída reservam 243 linhas adicionais. O shape é divisível por 512 — $248{,}320 = 512 \times 485$ —, algo conveniente para sharding, mas os artefatos publicados não informam por que esse tamanho exato foi escolhido, que sinal de treino as linhas não mapeadas receberam nem como todo servidor trata seus logits. A configuração de geração fixada não declara uma lista genérica de suppress_tokens. Inspecione o runtime real antes de afirmar mascaramento.

O tamanho do vocabulário não é de graça, e o custo é fácil de subestimar. Cada linha é um vetor de 5120 números e, neste modelo, o embedding de entrada e a projeção de saída são matrizes separadas em vez de uma compartilhada, então cada linha adicional custa armazenamento duas vezes. A lição 1.5 faz a contabilidade completa e o total é surpreendente. A tensão de projeto é, portanto, genuína: mais entradas de vocabulário significam sequências mais curtas e attention mais barata, mas uma tabela maior para armazenar, carregar e multiplicar a cada passo de decodificação. Não existe resposta universalmente correta, só um ponto numa curva escolhido para um conjunto específico de idiomas, hardware e cargas de trabalho.

Como o tokenizer é fixado quando o treino começa, ele faz parte do contrato do modelo e não é uma conveniência de pré-processamento. A matriz de embeddings tem uma linha por entrada do vocabulário, e essas linhas aprenderam seus valores sob um mapeamento específico de texto para ids. Troque o tokenizer depois e todo id aponta para uma linha que aprendeu outra coisa. É por isso que você não pode misturar os pesos de um modelo com o tokenizer de outro, por mais parecidos que os dois pareçam.

Quando você inspeciona qualquer tokenizer, quatro perguntas resolvem a maior parte do que importa. Ele consegue representar o texto válido que sua interface aceita? Quantas linhas de tensor há, e quantos ids os artefatos do tokenizer mapeiam? Quantos tokens o texto típico dos seus idiomas exige? E os idiomas e domínios com que você se importa são fragmentados de forma justa em relação aos que não são? Essas perguntas mostram por que tokenization não é mero pré-processamento. Ela fixa o alfabeto disponível ao modelo e define o preço de toda sequência que esse modelo vai processar na vida.