Tokenização III: SentencePiece, byte-level e o impacto da contagem

1

Conceito

“Quantos tokens tem este texto?” não tem resposta até nomearmos o tokenizer. Token não é unidade linguística estável; é uma entrada no vocabulário fixo de um modelo sob certa normalização e codificação. O mesmo parágrafo ocupa comprimentos diferentes em dois modelos, mesmo quando ambos usam subwords e produzem texto decodificado visualmente idêntico.

Muitos pipelines primeiro separam whitespace ou pontuação e depois aprendem subwords dentro dessas partes. Isso introduz premissas específicas da língua. SentencePiece foi criado para treinar sobre frases brutas, representando whitespace com símbolo explícito e oferecendo tokenização e detokenização autocontidas. Ele suporta famílias como BPE e Unigram; SentencePiece é uma toolkit e uma abordagem de representação, não um algoritmo único de segmentação.

O modelo Unigram começa com um vocabulário candidato e atribui probabilidades às peças. Uma string pode admitir várias segmentações. O treinamento remove peças iterativamente buscando um vocabulário que dê alta likelihood ao corpus; a codificação escolhe a melhor segmentação ou amostra alternativas para regularização. Isso contrasta com merges gulosos ordenados associados ao BPE, embora implementações reais acrescentem detalhes.

Abordagens byte-level resolvem cobertura de outro modo. O texto vira bytes, e o vocabulário-base representa qualquer valor de byte. Sequências frequentes são combinadas em tokens maiores. Scripts raros, emoji, texto corrompido ou dados arbitrários não exigem um caractere desconhecido genérico, pois podem cair para bytes. Cobertura não garante eficiência: um fragmento inglês frequente pode ser um token, enquanto um grapheme incomum se expande em vários.

Normalização altera contagens antes da segmentação. Strings equivalentes em Unicode podem ter code points diferentes. Lowercase, normalização de compatibilidade, limpeza de espaços ou tratamento de acentos podem fundir distinções necessárias à tarefa. Tokens especiais adicionam outra camada: começo e fim de sequência, separadores de papéis, delimitadores de tools ou chat templates consomem contexto mesmo ausentes do texto visível.

Por isso, regras de conversão comuns são estimativas, não contratos. Uma heurística criada com prosa inglesa pode falhar em flexões do português, texto CJK, código, tabelas, números longos, URLs ou emoji. Até frases inglesas com igual número de caracteres segmentam diferente quando uma contém peças frequentes. A única contagem confiável vem do tokenizer e do template exatos da versão implantada.

Contagens têm consequências de engenharia. O limite de contexto inclui entrada e geração e pode incluir formatação escondida adicionada pela API. Mais posições elevam o trabalho de prefill; tokens gerados acrescentam etapas sequenciais de decode. Serviços costumam cobrar tokens, mas preços e definições variam no tempo; não existe taxa universal que deva ser fixada na aula. Meça a requisição montada, não apenas a caixa de texto.

Compare tokenizers em corpora representativos por língua e domínio. Relate distribuições, não uma anedota: mediana e cauda do comprimento, frequência de fallback e fragmentação de termos importantes. Verifique reversibilidade e segurança dos tokens especiais. A conclusão é firme: tokens são embalagens específicas do modelo. SentencePiece, BPE, Unigram e bytes trocam tamanho de vocabulário, cobertura, comprimento e viés; nenhum fornece uma unidade natural neutra entre idiomas.

Versione o arquivo do tokenizer junto com o checkpoint. Reutilizar apenas o nome do algoritmo não basta: uma lista de merges, vocabulário ou normalizer diferente muda IDs e invalida as linhas de embedding aprendidas.