Banco de provas do tokenizador

Um terço do banco em triplas não separa o final absurdo do final possível. Esta página investiga se a culpa é do modelo — e responde que não é. Nada aqui altera o instrumento; é bancada de teste.

Esta página não muda nada no teste. O instrumento em /leitura continua usando o bloom-560m, e as páginas de explicação continuam válidas. O que está aqui é o registro de um experimento metodológico e do seu resultado negativo.

1. O problema, num item só

A frase-base b01 é “Com muita sede, o menino encheu o copo de ___”, com três finais: água (esperado), suco (possível) e cimento (absurdo).

O modelo deu 25,8 bits para “suco” e 26,8 para “cimento”. Um bit de diferença entre um líquido plausível e um material de construção. Qualquer pessoa separaria os dois por um abismo.

Por que isso aconteceu

palavra e pedaçoschancebits
 su1 em 6.52212,67
co1 em 5,82,54
.1 em 1.54410,59
suco.25,8
 c1 em 2.17411,09
imento1 em 415,37
.1 em 1.32010,37
cimento.26,8

Tudo se decidiu no primeiro pedaço. O modelo achou  c mais provável que  su — porque “c” abre centenas de palavras (copo, café, cerveja, chá, caldo) e “su” abre pouquíssimas.

No instante em que escolhe o primeiro fragmento, o modelo ainda não sabe se a palavra será “cerveja” ou “cimento”. Entra barato. E depois de “ c”, o pedaço “imento” custa só 5,37, porque a essa altura já é quase obrigatório.

O absurdo nunca é cobrado. E “suco”, que faz sentido, paga caro apenas pelo jeito como é soletrado em fragmentos. O modelo não está julgando sentido — está julgando ortografia.

2. A hipótese que eu levantei

Se o vilão é a tokenização, então um modelo que trate “suco” como uma peça única resolveria o problema. Essa hipótese tem duas partes testáveis, e testei as duas.

Vale distinguir de outra coisa. Oh & Schuler mostram que modelo maior ajusta pior o tempo de leitura humano. Isso é sobre tamanho. A hipótese aqui é sobre cobertura de vocabulário do português — eixo diferente. Por isso o modelo comparado foi escolhido do mesmo porte, para não confundir os dois efeitos.

3. Teste A — como cada tokenizador quebra as palavras

Nove tokenizadores sobre as 56 palavras-alvo do banco. Quanto menos pedaços, mais adequado ao português. Os tokens especiais foram excluídos da contagem, senão alguns modelos apareceriam artificialmente piores.

tokenizadorpedaços por palavrapalavras inteiras
bloom-560m ← o que está em uso1,4634 de 56
o200k_base — GPT-4o / GPT-51,5530 de 56
xlm-roberta-base1,7923 de 56
Qwen1.5-0.5B2,208 de 56
cl100k_base — GPT-42,275 de 56
gpt2 — o BPE de 20192,552 de 56
gpt-neo-125M2,552 de 56
opt-125m2,552 de 56
TinyLlama-1.1B3,460 de 56

Primeira surpresa: o bloom-560m ganha, e por pouco. Ele trata 34 das 56 palavras-alvo como peça única; o o200k_base, o tokenizador do GPT-4o e do GPT-5, trata 30 e fica logo atrás. Os dois brigam de igual.

Mais abaixo, a diferença é de geração. O cl100k_base, do GPT-4, já quebra “água” em  água. E o BPE do gpt2, de 2019, chega a partir a mesma palavra em quatro pedaços, um deles um acento perdido. Não confunda os três: “o tokenizador da OpenAI” mudou muito entre 2019 e hoje, e só o mais recente compete com o bloom.

E as três palavras de b01, em cada um

tokenizadoráguasucocimento
bloom-560m  água  suco  cimento
xlm-roberta-base água suco cimento
Qwen1.5-0.5B  água  suco  cimento
o200k_base GPT-4o/5  água  suco  cimento
cl100k_base GPT-4  água  suco  cimento
gpt2 2019  ��gua  suco  cimento
TinyLlama-1.1B água suco cimento

Os nove, sem exceção, quebram “suco” em su + co. Inclusive o o200k_base, que é o estado da arte e trata “água” e “cimento” inteiros. Trocar de tokenizador não conserta b01.

E tem uma reviravolta: o melhor tokenizador moderno piora este item.

O o200k_base trata  cimento como peça única — ou seja, o absurdo passa a custar um preço só, sem o segundo pedaço barato que ao menos somava alguma coisa. E continua quebrando  suco, que segue pagando o preço alto do começo raro.

A assimetria que causa o problema fica maior, não menor. É o contrário do que a hipótese previa — e por isso o teste valeu a pena.

O motivo é mais fundo que a tokenização: suco é uma palavra brasileira. Portugal diz sumo, o espanhol diz jugo. Já cimento existe quase igual em português, espanhol e italiano. Num modelo multilíngue, a palavra do Brasil é a rara.

Uma restrição prática, mesmo que o o200k vencesse. Tokenizador sozinho não calcula surpresa — para isso é preciso o modelo que gera as probabilidades. Os modelos da OpenAI não rodam localmente: só por API paga. Adotá-los faria o instrumento deixar de ser gratuito e deixar de funcionar sem internet, que são duas das três coisas que o distinguem do rastreador ocular de laboratório. Vale como régua de comparação, não como substituto.

4. Teste B — e se trocar o modelo inteiro?

Tokenização é só um indicador. O que importa mesmo é a ordenação: o final absurdo custa mais bits que o possível? Rodei as 20 triplas inteiras no Qwen1.5-0.5B — mesmo porte do bloom, para não misturar o efeito de tamanho.

resultado nas 20 triplasbloom-560mQwen1.5-0.5B
limpas (margem ≥ 3 bits) 1311
apertadas (margem < 3 bits) 43
invertidas (o absurdo custa menos) 36

O Qwen dobrou o número de inversões. Trocar o modelo não melhora: piora. O bloom-560m permanece a melhor escolha disponível, e por margem confortável.

Mas há um achado útil no meio do fracasso

Cruzando os dois modelos, os itens problemáticos se dividem em dois tipos, e a diferença entre eles é acionável:

frase-basebloomQwendiagnóstico
b01  água / suco / cimento +1,0+2,1o item
b05  martelo / cabo / queijo −0,7−7,2o item
b19  caneta / folha / colher −5,3−9,2o item
b14  livro / caderno / cobertor −2,1+3,9o modelo
b06  bolo / pavê / sabão +0,7−3,0o modelo
b11  espelho / aparelho / sapato +0,9+4,2o modelo
b15  manta / toalha / tesoura +2,4+4,2o modelo

Três itens falham nos dois modelos — b01, b05 e b19. Quando dois modelos independentes concordam que o final absurdo não é absurdo, o problema provavelmente é do item, não da máquina. E de fato:

Os outros quatro trocam de lado conforme o modelo. Nesses, a máquina é que está indecisa — e nenhum modelo vai resolver por nós.

5. O que este experimento fecha

1. O bloom-560m fica. É o melhor tokenizador de português entre os nove testados — à frente do o200k_base do GPT-5, e por pouco — e o que produz menos inversões. A troca de modelo está testada e descartada.

2. Três itens precisam ser reescritos — b01, b05 e b19 — porque falham independentemente do modelo.

3. O resto só se resolve com gente. Nenhum modelo disponível separa de forma confiável o final possível do absurdo em português. A norma humana deixou de ser uma opção entre várias: passou a ser o único caminho restante.

O que isto não compromete. A inclinação usa todas as palavras ao longo de toda a faixa de bits e não depende de as três condições estarem ordenadas. Ela continua de pé. Quem sofre com isto é a medida categórica de custo da incongruência, que fica diluída em cerca de um terço dos itens.

Resultado negativo também é resultado. Ter testado a alternativa óbvia e mostrado que ela não funciona é material de seção de métodos — e evita que a banca sugira exatamente isto.

6. Desfecho — os três itens foram reescritos

Em 28/08/2026, os três itens que falhavam nos dois modelos foram trocados e medidos de novo. O banco inteiro foi regerado; os 17 itens não tocados saíram idênticos, o que confirma que o modelo é determinístico e que nada mais se mexeu.

itemantesagoramargem
b01 água / suco / cimento água / suco / cascalho 1,0 → 9,8
b05 martelo / cabo / queijo martelo / punho / novelo −0,7 → 10,5
b19 caneta / folha / colher caneta / folha / enxada −5,3 → 4,6

O banco passou de 13 para 16 triplas limpas em 20. As inversões caíram de três para uma; as margens apertadas, de quatro para três.

O que cada conserto ensinou

b01 — trocar “cimento” por “cascalho” resolveu sozinho: “suco” continua nos mesmos 25,8 bits. O problema nunca foi o final possível, e sim o absurdo ser a palavra-alvo mais frequente de todo o banco (raridade 20,1).

b05 — tirar o verbo que entregava a resposta baixou também o esperado, de 23,2 para 20,7 bits. Com “martelou” no meio da frase, até a palavra certa saía cara. O frame novo é “Na oficina, o homem bateu no prego com o…” — e não abre com “Para”, que já era a abertura de três frases.

b19 falhou na primeira tentativa, e o fracasso confirmou o mecanismo.

“Colher” foi substituída por “peneira”, que saiu a 20,3 bits — pior que a palavra que vinha substituir. Motivo:  peneira, e  pen é um começo barato, porque abre pena, pensar, pendurar, pente.

É exatamente o  c de “cimento”, pego pela segunda vez — agora numa palavra escolhida depois de o mecanismo já ser conhecido. O problema não era um item azarado: é sistemático.

A escolha final saiu de medir catorze candidatas. A regra que se impôs: as catorze foram escolhidas por serem absurdas de verdade no contexto antes de qualquer medição. Medir serviu para descartar as que o modelo não enxerga — não para promover palavra fraca que pontuasse alto. “Melancia” pontuou 37,4 e foi descartada mesmo assim, por colidir com o vocabulário do conjunto 2.

O que continua em aberto

Sobra uma inversão: b14 — livro / caderno / cobertor, margem −2,1. Nesse item o modelo acha “caderno” mais surpreendente que “cobertor”, o que nenhuma pessoa diria. E três margens apertadas: b06, b11 e b15.

Estes quatro não se resolvem trocando palavra. Nos três consertados havia um defeito identificável — palavra frequente demais, verbo entregando a resposta, absurdo que não era absurdo. Nos que sobraram, o material está correto e quem discorda é o modelo. Só a norma humana decide.

Como reproduzir

entropy-node/probe-tokenizadores.mjs  ·  entropy-node/testa-modelo.mjs <modelo>  ·  entropy-node/mostra-conta.mjs  ·  entropy-node/testa-alvos.mjs  ·  entropy-node/confere-troca.mjs  ·  pacote gpt-tokenizer para os encodings da OpenAI

Medido em 27/08/2026, nove tokenizadores e dois modelos completos, sobre as mesmas 20 triplas do banco em uso.