Tokenização

O que é tokenização?

Tokenização (tokenization) é o processo de converter texto bruto em uma sequência de símbolos discretos chamados tokens (tokens). Tokens são as unidades que um modelo de linguagem (language model, LM) de fato lê e prevê. Um tokenizador (tokenizer) define:

  • Como o texto é dividido (por exemplo, em palavras, subpalavras, bytes)
  • Como cada parte é mapeada para um ID inteiro em um vocabulário (vocabulary)
  • Como reconstruir texto a partir de IDs de tokens (destokenização (detokenization))

Em modelos de linguagem grandes (large language models, LLMs) modernos, construídos sobre a Arquitetura Transformer, a tokenização não é apenas uma etapa de pré-processamento (preprocessing) — ela molda fortemente:

  • A qualidade do modelo (quais padrões são fáceis/difíceis de aprender)
  • Custo e latência (latency) (quantos tokens são processados por solicitação)
  • Utilização de contexto (context utilization) (quanto conteúdo cabe em uma janela fixa de tokens; veja Janelas de Contexto)
  • Robustez (robustness) entre idiomas e domínios (código, matemática, emojis, escritas não latinas)

Tokens, IDs de tokens e vocabulário

Um tokenizador normalmente produz:

  1. Strings de tokens (partes legíveis por humanos como "hello", "Ġworld", "ing" ou marcadores de byte)
  2. IDs de tokens (token IDs) (inteiros como 15496, 995, …)

O vocabulário é o mapeamento entre strings de tokens e IDs. Seu tamanho (frequentemente 30k–200k tokens) é uma escolha central de projeto.

Por que não usar apenas caracteres ou palavras?

  • Tokenização em nível de palavra (word-level tokenization) cria um vocabulário enorme e falha com palavras raras/novas (fora do vocabulário (out-of-vocabulary, OOV)).
  • Tokenização em nível de caractere (character-level tokenization) evita OOV, mas torna as sequências muito longas (mais computação e menor eficiência para modelagem de dependências de longo alcance).
  • Tokenização em subpalavras (subword tokenization) é um meio-termo: palavras comuns viram tokens únicos; palavras raras viram múltiplas partes de subpalavras.

A maioria dos modelos de linguagem grandes hoje usa tokenização em subpalavras (muitas vezes consciente de bytes (byte-aware)) porque equilibra cobertura, comprimento de sequência e tamanho do vocabulário.

Uma intuição prática rápida: a contagem de tokens determina o custo

A maioria das APIs hospedadas de modelos de linguagem grandes cobra e limita o uso em tokens, não em caracteres ou palavras. Heurísticas aproximadas (inglês):

  • 1 token ≈ 3–4 caracteres de texto em inglês (bem aproximado)
  • 1 token ≈ 0,75 palavra em média (varia bastante)

Mas as contagens de tokens variam drasticamente por:

  • Idioma (por exemplo, o chinês pode ser eficiente em tokens ou não, dependendo do tokenizador)
  • Formatação (espaços em branco, pontuação, JSON)
  • Domínio (código-fonte, símbolos matemáticos)
  • Vocabulário escolhido do tokenizador

Como o custo computacional do Transformer é aproximadamente proporcional ao comprimento da sequência (sequence length), menos tokens geralmente significa:

  • Menor custo
  • Menor latência
  • Mais conteúdo na mesma janela de contexto

Algoritmos comuns de tokenização

Tokenizadores diferem principalmente em como constroem um vocabulário e segmentam o texto.

Codificação por Pares de Bytes (Byte-Pair Encoding, BPE)

A codificação por pares de bytes começa a partir de um alfabeto base (caracteres ou bytes) e mescla iterativamente os pares adjacentes mais frequentes em novos tokens. Ao longo de muitas mesclagens, aprende subpalavras comuns.

Propriedades:

  • Produz uma segmentação determinística dadas regras de mesclagem (merge rules)
  • Tende a criar tokens para padrões frequentes (por exemplo, "ing", "http", "://")

Muitos tokenizadores modernos de modelos de linguagem grandes são variantes de codificação por pares de bytes, frequentemente codificação por pares de bytes em nível de byte (byte-level BPE) (veja abaixo).

Segmentos de Palavra (WordPiece)

Segmentos de palavra (WordPiece) (popularizado pelo BERT) é similar em espírito à codificação por pares de bytes, mas usa um critério baseado em verossimilhança para mesclagens ou inclusão de tokens. Com frequência marca subpalavras de continuação (por exemplo, ##ing).

Propriedades:

  • Forte presença histórica em modelos codificadores (encoder models)
  • Tokenização determinística dado um vocabulário fixo

Modelo de Linguagem Unigram (Unigram Language Model) (Unigram / SentencePiece)

A tokenização modelo de linguagem Unigram (Unigram Language Model) (frequentemente implementada via SentencePiece) começa com um conjunto grande de candidatos a subpalavras e o poda usando um objetivo probabilístico. A tokenização pode ser vista como a escolha do melhor caminho em um reticulado (lattice) de segmentações possíveis.

Propriedades:

  • Frequentemente produz boas segmentações para texto multilíngue
  • Pode ser mais flexível do que mesclagens puramente gulosas (mesclagens gulosas (greedy merges))

Tokenização em nível de byte (byte-level tokenization) (e por que bytes importam)

Um grande problema prático é a cobertura Unicode (Unicode coverage). Se um tokenizador começa a partir de caracteres, ele precisa lidar com um espaço enorme de símbolos possíveis e com questões de normalização. Abordagens em nível de byte evitam “caracteres desconhecidos” ao operar sobre bytes brutos (0–255) e então aprender mesclagens.

Benefícios:

  • Sem OOV em princípio: qualquer texto pode ser representado como bytes
  • Mais robusto a símbolos estranhos, escritas mistas e texto arbitrário com aspecto “binário”

Custo:

  • Alguns textos podem virar mais tokens do que com um tokenizador de caracteres/subpalavras bem ajustado, dependendo das mesclagens e do vocabulário.

Normalização e pré-tokenização: a metade oculta da tokenização

Antes da segmentação em subpalavras, tokenizadores frequentemente realizam:

Normalização (normalization)

Exemplos:

  • Normalização Unicode (NFC/NFKC)
  • Conversão para minúsculas (lowercasing) (menos comum em modelos de linguagem grandes modernos)
  • Substituição de certas formas de espaço em branco
  • Tratamento consistente de caracteres acentuados

A normalização afeta se duas strings visualmente semelhantes viram a mesma sequência de tokens.

Pré-tokenização (pre-tokenization)

Esta etapa divide o texto em blocos usando regras (por exemplo, em espaços em branco ou pontuação) antes de aplicar codificação por pares de bytes/modelo de linguagem Unigram dentro dos blocos.

Por exemplo, alguns tokenizadores tratam espaços iniciais de forma especial, porque espaços carregam sinais fortes de fronteira de palavras em inglês. Você pode ver tokens representando “espaço + palavra” como uma única unidade.

Exemplos trabalhados (conceituais)

Considere a palavra:

  • "unbelievable"

Um tokenizador de subpalavras pode produzir:

  • ["un", "believ", "able"]
  • ou ["un", "believable"]
  • ou ["unbelievable"] (se for frequente o bastante)

Uma palavra rara ou inventada:

  • "hyperquantizationify"

pode virar:

  • ["hyper", "quant", "ization", "ify"]
  • ou uma cadeia mais longa de fragmentos

Ideia-chave: strings frequentes se comprimem em menos tokens.

Exemplo: por que formatação muda a contagem de tokens

Estas duas strings podem ser tokenizadas de modo diferente:

  • "hello world"
  • "hello world" (múltiplos espaços)

Dependendo do tokenizador, espaços extras podem adicionar tokens (ou mudar fronteiras de tokens), o que pode aumentar o custo e alterar o comportamento do modelo (por exemplo, em blocos de código ou prompts sensíveis a alinhamento (alignment-sensitive prompts)).

Exemplo prático usando tokenizadores do Hugging Face (Python)

Modelos diferentes têm tokenizadores diferentes; contagens de tokens não são intercambiáveis.

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("gpt2")  # example tokenizer
text = "Tokenization affects cost and quality."

enc = tok(text, add_special_tokens=False)
print("Token IDs:", enc["input_ids"])
print("Num tokens:", len(enc["input_ids"]))
print("Tokens:", [tok.decode([i]) for i in enc["input_ids"]])

Notas:

  • decode([i]) por token é útil para inspeção, mas pode parecer estranho (marcadores de espaço, escapes de byte).
  • Modelos orientados a chat frequentemente adicionam tokens especiais (special tokens) para papéis e separadores; a contagem de tokens pode aumentar ao usar modelos de chat (chat templates).

Projeto de vocabulário: o que entra no conjunto de tokens?

Projetar um vocabulário de tokenizador é um equilíbrio entre:

1) Tamanho do vocabulário vs. comprimento da sequência

  • Vocabulário maior

    • Prós: menos tokens por frase (melhor compressão), potencialmente melhor para strings específicas de domínio (por exemplo, palavras-chave de código)
    • Contras: matriz de incorporações (embedding matrix) e projeção de saída maiores; mais parâmetros e memória; potencialmente otimização mais difícil para tokens raros

  • Vocabulário menor

    • Prós: menos parâmetros “presos” em incorporações/softmax; mais força estatística compartilhada entre subpalavras
    • Contras: sequências mais longas → mais computação e maior custo; pode prejudicar a qualidade em contextos longos

Em modelos de linguagem Transformer, o custo de execução é dominado por camadas de atenção/perceptron multicamadas (multi-layer perceptron, MLP) e cresce com o comprimento da sequência, enquanto o tamanho do vocabulário afeta principalmente as camadas de incorporação de entrada/saída e os logits finais. Ainda assim, vocabulários muito grandes podem aumentar memória e computação na camada de saída.

2) Cobertura de domínio (linguagem natural vs. código vs. matemática)

Tokenizadores treinados em texto da web podem não representar código de forma eficiente. Por exemplo:

  • Se "function_name" se divide em muitas partes, prompts de código ficam mais longos e o modelo precisa aprender padrões ao longo de mais etapas.
  • Modelos especializados em código frequentemente usam tokenizadores treinados em corpora ricos em código (veja Modelos de Código).

Texto matemático e científico pode sofrer de forma similar ("\alpha", "∑", comandos LaTeX), influenciando tanto custo quanto correção.

3) Considerações multilíngues

Idiomas diferem em morfologia e escrita:

  • Idiomas aglutinantes (agglutinative) (por exemplo, turco) podem produzir formas de palavras longas que se fragmentam em muitos tokens.
  • Idiomas CJK (chinês/japonês/coreano) podem tokenizar de forma eficiente se caracteres/palavras comuns estiverem no vocabulário — mas o resultado depende fortemente dos dados de treinamento e do algoritmo.

Um tokenizador ajustado para inglês pode ser mais caro e de menor qualidade para outros idiomas porque produz sequências mais longas e unidades de subpalavras menos significativas.

4) Tokens especiais e tokens de controle

Modelos de linguagem grandes frequentemente reservam IDs para finalidades especiais:

  • Início/fim de texto
  • Preenchimento (para processamento em lote)
  • “Desconhecido” (menos comum em tokenizadores em nível de byte)
  • Formatação de chat (separadores de sistema/usuário/assistente)
  • Marcadores de chamada de ferramenta/função (relevante para Modelos de Linguagem Grandes que Usam Ferramentas)

Tokens especiais fazem parte do “projeto de vocabulário” porque definem interfaces entre texto e o comportamento do modelo.

Como a tokenização afeta a qualidade do modelo

A tokenização influencia a qualidade por vários mecanismos.

1) Eficiência estatística e composicionalidade (compositionality)

A tokenização em subpalavras incentiva o modelo a aprender partes reutilizáveis:

  • "play", "playing", "played" compartilham subpartes
  • Isso pode melhorar a generalização para formas de palavras não vistas

Mas a tokenização também pode dividir de formas pouco intuitivas, prejudicando a composicionalidade, especialmente para strings raras ou texto não inglês.

2) Raciocínio de longo alcance e pressão de contexto

Transformers operam com um número limitado de tokens (veja Janelas de Contexto). Se a tokenização produz mais tokens para o mesmo conteúdo, então:

  • Você coloca menos informação no contexto
  • O modelo pode perder detalhes importantes anteriores
  • Prompts aumentados por recuperação (retrieval-augmented prompts) e documentos longos ficam mais caros

Isso interage com técnicas de elaboração de prompts e raciocínio (veja Técnicas de Cadeia de Pensamento e Raciocínio): mais “pensamento” consome tokens e compete com espaço para evidências.

3) Confiabilidade em formatos estruturados (JSON, YAML, código)

Modelos frequentemente se comportam melhor quando padrões estruturais comuns são tokenizados de forma consistente:

  • Aspas, chaves, vírgulas
  • Indentação e quebras de linha em código
  • Chaves repetidas em JSON

Se um tokenizador fragmenta isso de modo estranho, o modelo pode precisar de mais capacidade para aprender sintaxe — às vezes aparecendo como mais erros de formatação.

4) Tokens raros e qualidade das incorporações

Tokens que aparecem raramente no pré-treinamento recebem incorporações mal treinadas. Se seu domínio usa tokens raros com frequência (por exemplo, termos biomédicos), a qualidade pode cair.

Essa é uma razão pela qual a adaptação de domínio via Ajuste Fino pode ajudar, mas observe: o ajuste fino não consegue mudar a segmentação básica do tokenizador. Se seu tokenizador fragmenta termos-chave de forma ruim, você ainda pode estar lutando contra a maré.

Como a tokenização afeta custo, latência e vazão

A contagem de tokens é o principal fator

Para inferência (inference) de modelos de linguagem grandes somente decodificador (decoder-only), a computação escala aproximadamente com:

  • Tokens do prompt (prompt tokens) (processados uma vez)
  • Tokens gerados (generated tokens) (processados de forma autorregressiva (autoregressively); cada novo token atende a tokens anteriores)

Então, um tokenizador que produz menos tokens por mensagem pode reduzir:

  • Cobrança (billing) (tokens de entrada + tokens de saída)
  • Latência (menos etapas)
  • Pressão de memória (o cache KV (KV cache) cresce com o comprimento da sequência)

Isso se conecta diretamente a Pré-treinamento e Leis de Escala, porque tanto os orçamentos de computação de treinamento quanto os de inferência são altamente sensíveis ao comprimento da sequência.

O tamanho do vocabulário afeta pegada de memória e computação de logits

Um vocabulário maior aumenta:

  • Tamanho da tabela de incorporações (V × d)
  • Projeção de saída (output projection) e softmax (softmax) sobre V classes

No entanto, comparado ao custo de atenção/MLP em sequências longas, isso pode ser secundário em muitas implantações. A maior alavanca de custo na prática quase sempre é: quantos tokens você processa.

Armadilhas e casos extremos de tokenização

1) “Espaços em branco são significativos”

Muitos tokenizadores tratam " hello" e "hello" de forma diferente. Isso importa para:

  • Formatação de prompts
  • Exemplos de poucos exemplos (few-shot) (espaços extras podem mudar fronteiras de tokens)
  • Código sensível a indentação

2) Unicode e caracteres visualmente confundíveis

Formas Unicode diferentes podem tokenizar de maneira diferente, a menos que sejam normalizadas. Para aplicações sensíveis a segurança e a segurança operacional, tenha cuidado com:

  • Caracteres confundíveis (o “a” latino vs o “а” cirílico)
  • Caracteres de largura zero
  • Espaços inseparáveis

3) Strings adversariais e inflação de tokens

Como o custo escala com a contagem de tokens, uma entrada que explode em muitos tokens pode:

  • Aumentar latência/custo inesperadamente
  • Fazer prompts ultrapassarem limites de contexto

Tokenizadores em nível de byte evitam caracteres desconhecidos, mas podem produzir sequências longas para certos padrões.

4) Incompatibilidade entre tokenizadores de modelos diferentes

Contagens e fronteiras de tokens diferem por família de modelos. Isso importa ao:

  • Estimar custo entre provedores
  • Migrar prompts entre modelos
  • Treinar um modelo aluno (student) menor com um tokenizador diferente

Escolhendo e avaliando um tokenizador na prática

Se você está treinando ou selecionando um tokenizador (comum para modelos de linguagem grandes personalizados, modelos de domínio ou agentes especializados), avalie nestes eixos:

Cobertura e robustez

  • Ele consegue codificar todo o texto que você precisa sem erros?
  • Como lida com emojis, texto acentuado e escritas mistas?

Taxa de compressão (tokens por caractere/palavra)

Calcule contagens médias de tokens em corpora representativos:

  • prompts de usuários
  • documentos recuperados
  • trechos de código
  • logs / JSON

Menor geralmente é melhor para custo e capacidade de contexto, mas não a qualquer preço — vocabulários grandes demais podem criar muitos tokens raros.

Adequação ao domínio

Inspecione segmentações de termos importantes:

  • nomes de produtos
  • termos médicos
  • endpoints de API
  • identificadores de programação

Um bom tokenizador deve evitar transformar unidades críticas em sequências longas e ruidosas.

Estabilidade para prompting estruturado

Se você depende de formatos estritos (schemas JSON, chamadas de ferramentas), teste a tokenização de:

  • chaves e aspas
  • chaves (keys) e delimitadores
  • argumentos típicos de ferramentas

Isso é especialmente importante para Modelos de Linguagem Grandes que Usam Ferramentas, onde pequenos desvios de formatação podem quebrar parsers.

Tokenização e comportamento de geração

A tokenização interage com a decodificação porque o modelo prevê o próximo token. Isso pode produzir efeitos sutis:

  • Se uma palavra comum é um token único, o modelo pode emiti-la em uma etapa.
  • Se ela é dividida em muitos tokens, o modelo precisa “se comprometer” repetidamente, aumentando as chances de divergência.

Métodos de decodificação (greedy) (ganancioso), top-p (top-p), temperatura (temperature) operam no nível de token; a granularidade dos tokens muda a forma da distribuição de probabilidade que está sendo amostrada. Veja Estratégias de Decodificação.

Dicas práticas para profissionais (prompting e sistemas)

  • Meça tokens, não chute. Use o tokenizador do modelo para estimar tamanho e custo do prompt.
  • Evite inchaço acidental de tokens em produção:
    • espaços em branco excessivos
    • chaves JSON verbosas
    • instruções boilerplate repetidas
  • Comprima o contexto recuperado (resumos, chunking) ao usar documentos longos, porque a tokenização determina o quanto cabe.
  • Tenha cuidado com entradas multilíngues. A mesma contagem de caracteres pode implicar contagens de tokens muito diferentes.
  • Ao fazer ajuste fino, lembre: você não consegue “consertar” um tokenizador ruim apenas com treinamento. Se a tokenização é o gargalo, considere um modelo base diferente ou (para treinamento do zero) um tokenizador diferente.

Resumo

Tokenização é a ponte entre texto bruto e as sequências discretas que modelos de linguagem grandes aprendem a modelar. O algoritmo do tokenizador (codificação por pares de bytes/segmentos de palavra/modelo de linguagem Unigram/em nível de byte), regras de normalização e projeto de vocabulário determinam em conjunto:

  • Qualidade: quais padrões são fáceis de aprender, quão bem o modelo lida com idiomas/domínios e quão confiavelmente ele emite texto estruturado
  • Custo e desempenho: quantos tokens são processados, o que determina latência, vazão e cobrança
  • Usabilidade: quanto de informação cabe em uma janela de contexto fixa e quão previsível é a formatação

Entender tokenização é, portanto, essencial para qualquer pessoa que esteja construindo prompts, treinando/fazendo ajuste fino de modelos, implantando sistemas com modelos de linguagem grandes ou otimizando desempenho em contextos longos dentro das restrições descritas em Janelas de Contexto e influenciadas por Pré-treinamento e Leis de Escala.