Data

24 jul, 2026

O que um LLM realmente lê? A resposta começa na tokenização.

Publicidade

Uma vez, em um podcast, me perguntaram o que é tokenização. Achei curioso porque, apesar da enorme popularização dos LLMs, percebo que esse ainda é um dos conceitos menos compreendidos. E, no entanto, trata-se de um dos componentes mais importantes de toda a arquitetura de um LLM.

Quando falamos sobre Inteligência Artificial generativa, quase toda a atenção costuma se concentrar nos Transformers, nos bilhões de parâmetros, nas GPUs ou nas técnicas de treinamento. Mas existe uma etapa anterior à própria rede neural que determina como toda a informação será apresentada ao modelo: o tokenizer.

Essa distinção é fundamental. Um modelo de linguagem não recebe palavras, frases ou ideias como entrada. O que chega ao modelo é apenas uma sequência de identificadores inteiros. Antes que qualquer mecanismo de atenção, embedding ou inferência entre em funcionamento, o texto precisa ser convertido em unidades discretas chamadas tokens. O algoritmo responsável por essa conversão é o tokenizer.

Em outras palavras, um LLM nunca “lê” um texto da forma como nós fazemos. Cada token é representado inicialmente por um identificador numérico pertencente a um vocabulário previamente construído. Esse identificador é então utilizado para recuperar um vetor na matriz de embeddings aprendida durante o treinamento, produzindo a representação vetorial que será processada pelas camadas do Transformer.

Essa observação leva a uma consequência importante. O modelo não opera diretamente sobre palavras ou conceitos da maneira como um ser humano os percebe. Sua unidade básica de processamento é o token. As representações semânticas que emergem durante o treinamento são aprendidas a partir de regularidades estatísticas entre sequências desses tokens. Portanto, a forma como um texto é tokenizado influencia diretamente quais padrões estatísticos poderão ser aprendidos. O tokenizer não determina sozinho o conhecimento do modelo, mas define as unidades fundamentais sobre as quais todo esse aprendizado será construído.

Outro aspecto pouco conhecido é que o tokenizer normalmente é construído antes do treinamento do próprio LLM. Primeiro analisa-se todo o corpus de treinamento para descobrir quais fragmentos aparecem com maior frequência e construir um vocabulário eficiente. Somente depois os bilhões de parâmetros do Transformer começam a ser ajustados. Em outras palavras, quando o treinamento do modelo se inicia, a forma como a linguagem será fragmentada já está completamente definida.

A necessidade de tokenização surgiu muito antes dos LLMs. Nos primeiros sistemas de Processamento de Linguagem Natural (NLP), nas décadas de 1960 e 1970, a estratégia era extremamente simples: dividir o texto pelos espaços em branco. A frase “Hoje está chovendo”, por exemplo, era separada em três palavras independentes.

Essa abordagem funcionava para tarefas relativamente simples, mas rapidamente revelou limitações.

A primeira era o problema das palavras desconhecidas (out-of-vocabulary). Como o vocabulário era fixo, qualquer palavra inexistente durante o treinamento era substituída por um marcador especial, normalmente chamado UNK (Unknown). Assim, nomes próprios, neologismos, marcas comerciais ou termos recém-criados simplesmente perdiam sua identidade. Para o modelo, “ChatGPT”, “XGBoost” ou qualquer palavra inédita tornavam-se exatamente o mesmo símbolo.

Outro problema era o crescimento explosivo do vocabulário. Em idiomas morfologicamente ricos, como o português, uma única raiz pode gerar dezenas de flexões diferentes. Tratar cada forma verbal ou nominal como uma palavra distinta fazia o vocabulário crescer rapidamente, aumentando memória, custo computacional e dificuldade de treinamento.

Uma alternativa seria abandonar completamente as palavras e utilizar caracteres individuais. Nesse caso, “casa” seria representada pelos quatro caracteres “c”, “a”, “s” e “a”. Essa estratégia praticamente elimina o problema das palavras desconhecidas, mas cria outro: as sequências tornam-se muito maiores.

Esse detalhe é particularmente importante porque, na arquitetura Transformer clássica utilizada como base da maioria dos LLMs modernos, o custo do mecanismo de self-attention cresce aproximadamente com o quadrado do comprimento da sequência. Embora existam otimizações recentes, como FlashAttention, MQA e GQA, sequências maiores continuam exigindo mais memória, maior tempo de processamento e maior custo computacional.

A solução que acabou predominando foi um compromisso entre esses extremos: a tokenização por subpalavras (subword tokenization). Em vez de considerar apenas palavras inteiras ou apenas caracteres, o algoritmo aprende automaticamente quais fragmentos aparecem com maior frequência no corpus de treinamento. Palavras muito comuns permanecem inteiras como um único token, enquanto palavras raras ou inéditas são decompostas em fragmentos menores que também apresentam significado estatístico.

Essa abordagem reduz drasticamente a ocorrência de palavras desconhecidas, mantém o vocabulário relativamente compacto, permite representar termos inéditos por meio da combinação de fragmentos conhecidos e melhora significativamente a capacidade de generalização dos modelos.

Não por acaso, a imensa maioria dos LLMs atualmente em produção utiliza alguma forma de tokenização baseada em subpalavras.

Entre os algoritmos mais conhecidos está o Byte Pair Encoding (BPE). Curiosamente, ele nasceu na área de compressão de dados muito antes dos LLMs. Adaptado para NLP, inicia tratando cada caractere como uma unidade independente e passa a combinar iterativamente os pares mais frequentes até formar um vocabulário eficiente.

O WordPiece, desenvolvido pelo Google para o BERT, segue uma filosofia semelhante, mas utiliza um critério probabilístico diferente para decidir quais fragmentos devem compor o vocabulário.

Posteriormente, o Google Research desenvolveu o SentencePiece, cuja principal inovação foi eliminar a dependência da separação por espaços durante o treinamento. Em vez de assumir previamente onde começam e terminam as palavras, ele aprende essas fronteiras diretamente a partir do texto bruto, característica particularmente útil para idiomas como japonês, chinês e coreano.

Dentro do próprio SentencePiece existe ainda o algoritmo Unigram Language Model, que parte de um vocabulário inicial muito grande e elimina iterativamente os fragmentos menos úteis para maximizar a probabilidade estatística do corpus. Em idiomas com rica morfologia essa abordagem frequentemente produz segmentações mais eficientes.

A OpenAI utiliza tokenizadores implementados na biblioteca tiktoken, baseados em variantes altamente otimizadas da família BPE. Codificações recentes, como cl100k_base e o200k_base, ampliaram significativamente o vocabulário e reduziram a quantidade média de tokens necessária para representar textos, códigos-fonte e múltiplos idiomas, aumentando o aproveitamento da janela de contexto e reduzindo custos de inferência.

A Anthropic não divulga detalhes completos do tokenizer utilizado pelos modelos Claude. Sabe-se apenas que emprega um tokenizer proprietário compatível com Unicode, cuja implementação permanece fechada, como diversos outros componentes internos da plataforma.

Um aspecto frequentemente ignorado é que não existe correspondência fixa entre palavras e tokens. Uma palavra pode corresponder a um único token, a dois, três ou vários deles, dependendo exclusivamente do tokenizer utilizado. Da mesma forma, um token pode representar uma palavra inteira, parte de uma palavra, um espaço em branco, um operador de programação ou uma sequência recorrente de caracteres.

Isso explica por que diferentes modelos contabilizam quantidades distintas de tokens para exatamente o mesmo texto.

Também explica por que limites de contexto, como 128 mil, 200 mil ou um milhão de tokens, nunca podem ser convertidos diretamente em número de palavras. Em português, uma palavra costuma corresponder, em média, a cerca de 1,3 a 1,5 token, embora essa relação varie bastante conforme o domínio. Códigos-fonte, JSON, XML, SQL, fórmulas matemáticas e sequências numéricas frequentemente apresentam distribuições de tokens muito diferentes da linguagem natural.

Essa questão possui implicações práticas importantes. Praticamente todas as APIs comerciais cobram pelo número de tokens processados. Assim, um tokenizer mais eficiente reduz custos de inferência, armazenamento em cache, transmissão de contexto e melhora o aproveitamento da janela disponível.

A tokenização também influencia diretamente sistemas de RAG. Como muitos pipelines realizam o chunking utilizando o tokenizer do próprio modelo, mudanças no tokenizer podem alterar a forma como documentos são particionados, indexados, transformados em embeddings e posteriormente recuperados durante a busca semântica.

Costuma-se dizer que os grandes modelos de linguagem aprendem “a linguagem”. Essa afirmação é apenas parcialmente correta. Antes que qualquer parâmetro seja ajustado, a linguagem já foi fragmentada segundo regras definidas pelo tokenizer. Em certo sentido, ele funciona como uma lente através da qual o modelo enxerga o texto. Dois modelos treinados sobre os mesmos dados, utilizando arquiteturas semelhantes, mas tokenizadores diferentes, recebem sequências distintas, aprendem distribuições estatísticas diferentes e constroem representações internas diferentes.

Talvez seja justamente por isso que a tokenização receba tão pouca atenção nas discussões sobre IA. Ela não aparece nas demonstrações, não produz respostas impressionantes nem costuma ser mencionada nas apresentações de marketing. No entanto, influencia diretamente custo, velocidade, consumo de memória, eficiência econômica, aproveitamento da janela de contexto e, em certa medida, a própria qualidade das representações que o modelo consegue aprender. Antes mesmo do primeiro cálculo de atenção, o tokenizer já definiu quais serão os “átomos” da linguagem sobre os quais todo o aprendizado estatístico será construído. É um dos componentes mais discretos da arquitetura dos LLMs, mas também um dos mais decisivos.