Tokenização I: caracteres, palavras e subwords

1

Conceito

Redes neurais operam com números, portanto o texto precisa atravessar uma fronteira antes que um modelo de linguagem consiga processá-lo. Tokenização é a regra que divide o texto em unidades e mapeia cada unidade para um ID inteiro. O modelo não recebe diretamente a frase original. Ele recebe algo parecido com uma lista de IDs, e uma tabela de embedding converte cada ID em um vetor.

Essa divisão é uma escolha de projeto, não um fato natural da língua. Até a ideia de “palavra” é ambígua. Uma contração deve ser uma unidade ou duas? A pontuação fica anexada? O chinês normalmente não coloca espaços entre todas as palavras. O alemão combina vários conceitos em palavras compostas longas. Código-fonte, emoji, URLs e erros de digitação criam outros casos especiais. Um tokenizer precisa dar uma resposta determinística a qualquer entrada, inclusive textos que seus autores nunca imaginaram.

A abordagem mais simples é a tokenização por caracteres. Cada caractere recebe um ID; assim, “gato” vira quatro unidades. O vocabulário permanece pequeno, e uma palavra inédita não apresenta problema porque seus caracteres já são conhecidos. O custo aparece no comprimento da sequência. O modelo precisa transportar informação por muito mais posições, e as unidades semânticas úteis não vêm prontas. Unicode também complica a aparente simplicidade: o que parece um único símbolo na tela pode conter vários code points.

No outro extremo, a tokenização por palavras atribui um ID a cada palavra conhecida. A prosa comum fica compacta, e cada unidade costuma ter um sentido intuitivo. Porém, o vocabulário explode. Nomes, flexões, termos especializados, erros e neologismos produzem casos fora do vocabulário. Substituir todos por um único token desconhecido elimina justamente as distinções de que o modelo pode precisar. Nenhuma lista finita de palavras cobre texto aberto.

Por isso, a maioria dos LLMs modernos usa tokenização por subwords. Strings frequentes podem permanecer como tokens inteiros, enquanto strings raras são montadas com peças reutilizáveis. Um tokenizer pode representar “andando” como “and” mais “ando”, mas preservar uma palavra muito frequente como unidade única. Um sobrenome incomum talvez vire vários fragmentos. As peças exatas são aprendidas ou construídas a partir de um corpus, geralmente com famílias de algoritmos como byte-pair encoding, WordPiece, Unigram ou variantes baseadas em bytes.

Subwords oferecem um compromisso de engenharia. O vocabulário pode ser grande o bastante para comprimir padrões frequentes e pequeno o suficiente para armazenamento e treinamento eficientes. Quase qualquer texto pode ser representado por peças menores de fallback. O compromisso não é perfeito, pois as fronteiras são estatísticas, não linguísticas. Uma divisão pode parecer estranha para uma pessoa. Palavras relacionadas podem ser fragmentadas de formas distintas. O espaço em branco pode fazer parte do token seguinte. Uma letra maiúscula pode mudar toda a sequência.

A tokenização ocorre antes do Transformer. O tokenizer costuma permanecer fixo durante o treinamento, e a matriz de embedding tem uma linha para cada item do vocabulário. Trocar o tokenizer depois mudaria o significado dos IDs e invalidaria essas linhas aprendidas, a menos que o modelo fosse adaptado. O tokenizer faz parte do contrato do modelo; não é uma função cosmética de entrada.

As consequências são práticas. Janelas de contexto são medidas em tokens, e serviços costumam contabilizar uso da mesma forma. Dois textos com a mesma quantidade de caracteres podem ocupar números diferentes de posições. Um idioma pouco representado no corpus usado pelo tokenizer pode ser quebrado em mais peças do que o inglês, reduzindo quanto texto cabe na janela e aumentando o compute por frase. Código, números e formatação incomum também podem gerar sequências ineficientes.

As fronteiras entre tokens influenciam o comportamento. Aritmética fica mais difícil quando números são divididos sem consistência. Um prompt injection pode explorar Unicode incomum ou sequências particulares. O modelo talvez aprenda representações fortes para tokens inteiros frequentes e uma composição mais fraca para fragmentos raros. Isso não quer dizer que tokens carreguem significados fixos de dicionário: o sentido emerge do uso de seus embeddings dentro do contexto.

Ao inspecionar um tokenizer, faça quatro perguntas: ele representa qualquer entrada? Qual é o tamanho do vocabulário? Quantos tokens o texto típico exige? Idiomas e domínios importantes são fragmentados de modo equilibrado? Essas perguntas mostram por que tokenização não é mero pré-processamento. Ela define o alfabeto disponível ao modelo e o preço de cada sequência processada.