O Que um Tokenizador Come Torna-se o Que Ele Sabe
Dieta do Tokenizador: Uma Definição
Um tokenizador Harris treina em uma amostra de corpus. Ele executa análise distributiva nessa amostra, seleciona N segmentos que recorrrem com mais força & os escreve em um vocabulário. Após o treinamento, esses N segmentos tornam-se um alfabeto fixo que um modelo de linguagem usa para tudo: treinamento, inferência, toda entrada, toda saída.
Dieta do tokenizador = uma amostra de texto na qual um tokenizador treina.
Dieta de treinamento = um corpus no qual um modelo de linguagem é treinado.
Quando duas dietas diferem, um tokenizador aprende segmentos ajustados para texto que um modelo nunca verá. A capacidade de embedding (um slot por entrada do vocabulário) é gasta em segmentos que não geram recompensa durante o treinamento.
O Erro da ANDREA-12M
O ANDREA-12M treinou seu tokenizador Harris em um raw head de megachat-v8.txt. Essa head continha amostras de código & dados de tool-call. O currículo de treinamento, no entanto, excluiu código & tool calls; o ANDREA-12M só viu texto conversacional.
Resultado: um tokenizador aprendeu segmentos de palavras-chave Python, chaves JSON, flags de shell. Um modelo treinado em entradas de dicionário & diálogo. Apenas 36,4% dos segmentos se sobrepuseram a uma amostra ponderada pelo currículo. Os restantes 63,6% dos slots de vocabulário foram alocados a segmentos que um modelo nunca encontraria no tempo de treinamento.
Por Que Isso Importa
Cada entrada de vocabulário consome parâmetros de embedding: uma linha de uma matriz de embedding com formato V × d_model (coberto na atividade 4). Com V = 4353 & d_model = 384, cada slot de vocabulário custa 384 floats. Desperdiçar 63,6% desperdiça 63,6% de uma matriz de embedding em dados que um modelo nunca vê.
Estabeleça uma Regra de Dieta
Quão Grande Deve Ser N
Uma Varredura de Ciência do Vocabulário
ANDREA-120M realizou um experimento de ciência do vocabulário: treine tokenizadores Harris com diferentes valores de N (segmentos solicitados) no mesmo corpus de 1,25 bilhão de caracteres. Meça quantos segmentos o tokenizador realmente encontra. Plote os resultados.
| N Solicitado | Segmentos reais encontrados | Status |
|---|---|---|
| 2.048 | 2.048 | Não saturado (espaço para crescer) |
| 4.096 | 4.096 | Não saturado |
| 8.192 | 8.192 | Ponto de saturação |
| 16.384 | 13.106 | Corpus esgotado |
O Que Significa Saturação
Com N pequeno, um corpus tem muitos padrões recorrentes; um tokenizador preenche todos os slots que solicita. Com N grande, um tokenizador esgota os limites estatisticamente significativos. Um corpus de 1,25 bilhão de caracteres contém aproximadamente 13.106 segmentos distintos em forma de morfema acima de um limiar de frequência. Solicitar 16.384 resulta em 13.106; os 3.278 slots restantes são preenchidos ou deixados vazios.
Saturação: um ponto onde N solicitado = N encontrado. Além da saturação, um tokenizador não pode descobrir mais segmentos sem diluir a qualidade (reduzir limiares de frequência & aceitar ruído).
Ponto Ideal em 8192
ANDREA-120M escolheu N = 8192. Um raciocínio:
- Abaixo de 8192 (ex.: 4096): vocabulário subcaptura morfemas comuns; sequências fragmentam em mais tokens; throughput cai.
- Em 8192: cada slot de segmento mapeia para um padrão real e recorrente em um corpus.
- Acima de 8192: retornos decrescentes; 13.106 < 16.384 significa que slots são desperdiçados.
Vocabulário final do ANDREA-120M: 256 + 8192 + 1 = 8449 tokens. Compressão média: 5,91 bytes UTF-8 por token, significando que cada token substitui ~5,9 bytes de texto bruto. Essa proporção define o contexto efetivo de um modelo: em 1024 tokens × 5,91 bytes/token, o ANDREA-120M lê aproximadamente 6.050 caracteres de contexto por passagem forward.
Acima ou Abaixo da Saturação
De Onde Veio os 63,6%
Contando os Espaços Desperdiçados
O tokenizador do ANDREA-12M treinado em megachat-v8.txt bruto (4096 segmentos solicitados, encontrados). Uma equipe amostrou um subconjunto ponderado pelo currículo: um corpus ponderado pela frequência com que cada fonte foi selecionada por um bandido. Eles reexecutaram uma análise de Harris nessa amostra ponderada & perguntaram: quantos dos 4096 segmentos originais ainda aparecem?
Resultado: 36,4% de sobreposição. 1.491 de 4.096 segmentos corresponderam à ponderação do currículo. Os 2.605 segmentos restantes vieram de fontes excluídas pelo modelo.
63,6% dos slots de vocabulário foram alocados a bytes que o modelo nunca viu.
Custo de Embedding
Cada entrada de vocabulário ocupa uma linha de uma matriz de embedding com formato (V, d_model). Para ANDREA-12M:
- V = 4353 (256 + 4096 + 1)
- d_model = 384
- Parâmetros de embedding = V × d_model = 4353 × 384 = 1.671.552 parâmetros
63,6% desses parâmetros ficaram sem uso no treinamento conversacional. 1.063.107 parâmetros alocados, 0 sinal de recompensa. ANDREA-12M sobrevive porque 256 bytes base sempre cobrem qualquer caractere; mas a capacidade por parâmetro caiu acentuadamente.
Como ANDREA-120M Consertou Isso
O tokenizador do ANDREA-120M foi treinado em um firehose completo (1,25B caracteres, 21 fontes) em saturação N = 8192. Um corpus de treinamento = o mesmo firehose. Alinhamento dietético: 100%. Sobreposição resultante em amostra ponderada por chat: 36,5%. (Nota: 36,5% é sobreposição, não cobertura; o chat sozinho é um subconjunto do firehose completo, então esse número se comporta de forma diferente dos 36,4% do 12M.)
Compressão efetiva: 5,91 bytes UTF-8 por token. Matriz de embeddings do ANDREA-120M: 8449 × 768 = 6.488.832 parâmetros. Cada parâmetro ganha um sinal de recompensa porque cada segmento mapeia para texto em que o modelo realmente treina.
Cobertura Versus Sobreposição
Por que 5,91 Bytes Por Token Importa
Uma Taxa de Compressão
Bytes UTF-8 médios por token medem quanto texto bruto cada entrada do vocabulário comprime. O ANDREA-120M tem média de 5,91. Um modelo com peças mais curtas (3 bytes/token) lê menos contexto por passagem forward; um modelo com peças mais longas (8 bytes/token) lê mais, mas treina mais devagar (cada peça precisa de mais amostras para aprender bem).
Contexto Efetivo
| Quantidade | Valor |
|---|---|
| Janela de contexto de tokens | 1.024 tokens |
| Bytes médios por token | 5,91 |
| Contexto efetivo em caracteres | 1024 × 5,91 ≈ 6.050 |
Aproximadamente 6.000 caracteres UTF-8 cabem em uma passagem forward do ANDREA-120M. Uma página de prosa inglesa densa tem ~3.000-4.000 caracteres; o ANDREA lê cerca de uma página e meia por passagem.
Dieta Aperta a Compressão
Um tokenizador bem alinhado comprime melhor. Quando um tokenizador aprende segmentos que se repetem em um corpus de treinamento, mais texto cabe por token. O tokenizador mal alinhado do ANDREA-12M comprimia pior em chat (mais bytes gastos em fragmentos de fallback de byte porque segmentos de chat eram mais esparsos no vocabulário). O tokenizador alinhado com dieta do ANDREA-120M mantém uma peça em formato de chat em um caminho rápido & scripts raros em um fallback de byte.
Atividade 4 Continua
A Atividade 4 (grow_a_language_model_embeddings) cobre o que acontece com essas 8449 entradas do vocabulário: elas se tornam linhas de uma matriz de embedding com formato V × d_model, depois adicionam embeddings de posição aprendidos antes de fluírem para um primeiro bloco transformer.