Tokenizers: lo que pasa antes de que exista un solo número

1. Entrenar un tokenizer nuevo a partir de uno viejo

Entrenar un tokenizer no es entrenar un modelo — no hay descenso de gradiente ni aleatoriedad. Es un proceso estadístico y determinístico: mirar un corpus entero y decidir qué subpalabras merecen ser un token propio. Mismo corpus, mismo algoritmo, mismo resultado siempre.

AutoTokenizer.train_new_from_iterator() reentrena el vocabulario de un tokenizer existente sobre un corpus nuevo, conservando su algoritmo y tokens especiales. El ejemplo del original — reentrenar el tokenizer de GPT-2 (pensado para inglés) sobre código Python — muestra por qué esto importa: el tokenizer original parte _ y las palabras con guión bajo de forma rara porque nunca vio código en su entrenamiento. Uno reentrenado sobre CodeSearchNet aprende tokens propios como uno para "indentación de 4 espacios" o uno para las triples comillas de un docstring — 27 tokens contra 36 para la misma función, con una representación que refleja la estructura real del lenguaje.

2. Los poderes ocultos de un tokenizer rápido

La salida de un tokenizer no es un diccionario simple — es un BatchEncoding, y si el tokenizer es "rápido" (respaldado por Rust, vía la librería tokenizers), trae consigo un offset mapping: para cada token, recuerda exactamente qué tramo del texto original lo generó.

encoding = tokenizer("My name is Sylvain", return_offsets_mapping=True)
encoding.tokens()           # ['[CLS]', 'My', 'name', 'is', 'S', '##yl', '##va', '##in', '[SEP]']
encoding.word_ids()         # [None, 0, 1, 2, 3, 3, 3, 3, None] — a qué palabra pertenece cada token
encoding["offset_mapping"]  # [(0,0), (0,2), (3,7), (8,10), (11,12), (12,14), ...]

Esto no es un detalle de performance — es lo que hace posible reconstruir, sin reglas hechas a mano para cada tipo de tokenizer, qué tramo exacto del texto original corresponde a una entidad detectada por un modelo de NER: agrupás los tokens consecutivos de la misma entidad y tomás el offset desde el primero hasta el último. La misma técnica es la base de cómo un pipeline de question-answering recupera la respuesta exacta dentro del contexto, carácter por carácter.

El ida y vuelta: encode → decode

Lo que usaste en todos los capítulos anteriores sin mirarlo: tokenizer(texto) hace tokenizar + convertir a ids + agregar tokens especiales, y decode deshace los tres pasos. Con GPT-2 se ven además los símbolos que aparecen en cada tokenizer BPE a nivel de byte:

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("gpt2")
texto = "Hola mundo, tokenizers"

ids = tok(texto)["input_ids"]              # [39, 5708, 27943, 11, 11241, 11341]
tok.convert_ids_to_tokens(ids)             # ['H', 'ola', 'Ġmundo', ',', 'Ġtoken', 'izers']
tok.decode(ids)                            # 'Hola mundo, tokenizers'  ← el texto original, exacto
tok.decode(ids[2:3])                       # ' mundo'  ← con el espacio adelante

Ese Ġ no es un carácter del texto: es cómo GPT-2 representa el espacio. Un tokenizer a nivel de byte trabaja sobre los 256 bytes posibles, y varios de ellos (el espacio, los saltos de línea, los bytes de control) no se pueden imprimir ni guardar cómodamente en un archivo JSON de vocabulario — así que GPT-2 los mapea a caracteres Unicode visibles; al byte 32 (el espacio) le toca Ġ (U+0120 = 256 + 32). Y el espacio se pega al token siguiente, no al anterior: Ġmundo es "espacio + mundo". Por eso " mundo" y "mundo" son tokens distintos con ids distintos, y por eso decode puede reconstruir el texto exacto sin adivinar dónde iban los espacios — la reversibilidad de la que habla la sección siguiente. BERT hace lo inverso con ## (marca "continúa la palabra anterior", sin espacio), y SentencePiece usa ▁ para lo mismo que Ġ.

Los ids son específicos de cada tokenizer: el 5708 de arriba es "ola" en GPT-2 y otra cosa cualquiera en Llama. El modelo aprendió sus embeddings contra su tokenizer; pasarle ids de otro no da error, da basura. Y decode reconstruye texto de ids, no de tokens: si querés unir una lista de tokens a mano, convert_tokens_to_string es el que sabe qué hacer con Ġ y ##.

3. El pipeline completo: normalización → pre-tokenización → modelo

Antes de partir en subpalabras, todo tokenizer pasa el texto por dos pasos previos:

Cada familia de tokenizer pre-tokeniza distinto: BERT corta en espacios y puntuación; GPT-2 corta igual pero conserva los espacios como parte del token siguiente (el símbolo Ġ que ya viste en capítulos anteriores); T5 (basado en SentencePiece) solo corta en espacios, reemplazándolos por ▁, sin tocar la puntuación.

SentencePiece merece mención aparte: trata el texto como una secuencia cruda de caracteres Unicode, incluyendo los espacios en el conjunto de símbolos — por eso ni siquiera necesita un paso de pre-tokenización separado, algo clave para idiomas como japonés o chino, donde el espacio no separa palabras. Como bonus, su tokenización es reversible: decodificar es solo concatenar tokens y cambiar ▁ por espacio, sin la pérdida de información que sufre un tokenizer que colapsa espacios repetidos.

La Pre-tokenización con Expresiones Regulares en LLMs Modernos

En modelos modernos (GPT-4, Llama-3, Qwen), la pre-tokenización no es un simple split por espacios: se gobierna mediante una expresión regular compilada en Rust para aislar categorías sintácticas antes de que opere BPE.

La expresión regular canónica de GPT-4 y Llama-3 ilustra esta segmentación:

(?i:'s|'t|'re|'ve|'m|'ll|'d)|[^
\p{L}\p{N}]?\p{L}+|\p{N}{1,3}| ?[^\s\p{L}\p{N}]+[
]*|\s*[
]+|\s+(?!\S)|\s+

¿Por qué esta complejidad?

• Aislamiento de Contracciones: Separa 's, 've, 'll para que no se fundan con pronombres o sustantivos.
• Preservación de Aritmética ($\mathrm{p}\left\{\mathrm{N}\right\}\{1,3\}$): En tokenizers antiguos (GPT-2), números como 123456 se partían arbitrariamente en 123 y 456, mientras que 1234 se partía en 12 y 34. Esta representación fracturaba el aprendizaje de operaciones aritméticas en el LLM. Las expresiones modernas obligan a particiones de dígitos consistentes (máximo 1 a 3 dígitos por token).
• Espacios en Blanco y Sangrías: Captura bloques de espacios de código (indentaciones de 2 o 4 espacios) en tokens individuales, optimizando la longitud de contexto en programación.

4. Los tres algoritmos: BPE, WordPiece, Unigram

Los tres resuelven el mismo problema — optimizar el vocabulario de subpalabras $\mathcal{V}$ — pero bajo principios algorítmicos y matemáticos radicalmente distintos:

1. Byte Pair Encoding (BPE): Construcción Frecuencial Greedy

BPE es un algoritmo constructivo ascendente (bottom-up). Dado un corpus tokenizado $\mathcal{D}=\{(w,f_w)\}$ donde cada palabra $w$ tiene una frecuencia $f_w$:

1. Se inicializa el vocabulario ${\mathcal{V}}_0$ con todos los bytes básicos ($256$ símbolos) o caracteres individuales más los tokens de control.
2. En cada iteración, se contabiliza la frecuencia agregada de todos los pares contiguos $(u,v)$:
   $\text{freq}(u,v)=\sum _{w\in \mathcal{D}}{f}_w\cdot {\text{count}}_{(u,v)}(w)$
3. Se selecciona el par con máxima frecuencia: $(u^{*},v^{*})=\arg \underset{(u,v)}{\max }\text{freq}(u,v)$.
4. Se añade el nuevo símbolo compuesto $u^{*}{v}^{*}$ al vocabulario: $\mathcal{V}\leftarrow \mathcal{V}\cup \left\{u^{*}{v}^{*}\right\}$.
5. Se reemplazan todas las apariciones de $(u^{*},v^{*})$ en $\mathcal{D}$ y se registra la regla de fusión (merge rule) en la tabla ordenada.

Para tokenizar en inferencia, BPE toma una palabra nueva y aplica secuencialmente las reglas de fusión aprendidas en estricto orden cronológico.

2. WordPiece: Fusión por Información Mutua

Utilizado por BERT, WordPiece difiere de BPE en la función objetivo de selección de fusiones. En lugar de maximizar la frecuencia absoluta pura, WordPiece evalúa el incremento en la verosimilitud (likelihood) del corpus bajo un modelo de lenguaje unigram, lo cual equivale a maximizar la Información Mutua Puntual (PMI) entre los tokens candidatos:

Esta métrica penaliza la fusión de componentes individuales que ya son sumamente frecuentes de forma aislada (ej. partículas gramaticales o morfemas comunes), priorizando pares cuya correlación conjunta supera drásticamente su probabilidad marginal independiente.

3. Unigram Language Model (Kudo, 2018): Poda Probabilística Descendente

A diferencia de BPE y WordPiece, Unigram es un algoritmo top-down basado en optimización probabilística:

1. Vocabulario Inicial Sobredimensionado: Comienza con un vocabulario enorme ${\mathcal{V}}_0$ (ej. todos los caracteres más las 100.000 subcadenas más frecuentes del corpus).
2. Estimación de Parámetros (EM): Mediante el algoritmo de Esperanza-Maximización (Expectation-Maximization), estima la probabilidad unigram de cada subpalabra $P(t)$ sujeta a ${\sum }_{t\in \mathcal{V}}P(t)=1$.
3. Cálculo del Impacto de Poda: Para cada token $t\in \mathcal{V}$, calcula cuánto se degradaría la pérdida de entropía cruzada del corpus si $t$ fuera eliminado del vocabulario ($\mathrm{\Delta }{\mathcal{L}}_t$).
4. Poda Iterativa: Elimina el 10%–20% de los tokens con menor $\mathrm{\Delta }{\mathcal{L}}_t$ (protegiendo siempre los caracteres base para evitar [UNK]). Se repite hasta alcanzar el tamaño meta $|\mathcal{V}|$.

Durante la inferencia, una palabra puede segmentarse de múltiples maneras válidas. Unigram resuelve la ambigüedad aplicando el algoritmo de Viterbi para encontrar la segmentación $T^{*}=(t_1,\dots ,t_m)$ que maximiza la probabilidad conjunta:

Vale la pena seguir un ejemplo concreto de BPE, porque el mecanismo es simple una vez que lo ves una vez. Corpus de juguete: hug(×10), pug(×5), pun(×12), bun(×4), hugs(×5). Se arranca con cada palabra partida en caracteres:

h u g (×10)   p u g (×5)   p u n (×12)   b u n (×4)   h u g s (×5)

El par más frecuente en todo el corpus es ("u","g") — aparece 20 veces (en hug, pug y hugs). Esa es la primera fusión: "ug" entra al vocabulario, y se reemplaza en todas partes. El siguiente par más frecuente pasa a ser ("u","n") (16 veces) → se funde en "un". Después ("h","ug") (15 veces) → "hug". Y así, fusión por fusión, hasta llegar al tamaño de vocabulario que se pidió. Tokenizar una palabra nueva es aplicar esas mismas reglas de fusión, en el mismo orden en que se aprendieron.

Los números, para tenerlos como referencia:

Por qué esto te importa directamente: el costo de una request y el espacio que ocupa un documento en la ventana de contexto se miden en tokens, y cuántos tokens necesita un texto depende de qué tan bien lo cubre el vocabulario. Un tokenizer de 32k entrenado sobre inglés tiene tokens enteros para "the" y "because", pero parte "interpretante" en cuatro o cinco pedazos; uno de 128k o 256k entrenado sobre un corpus multilingüe tiene lugar para subpalabras frecuentes del español, del japonés o del código. El mismo párrafo en español puede costar entre 1,5× y 2× más tokens con un tokenizer anglocéntrico que con uno multilingüe — es la diferencia entre que un documento entre o no en la ventana, y entre pagar el doble o no por la misma respuesta. Meta reportó, al pasar de Llama 2 a Llama 3, que el vocabulario nuevo necesitaba del orden de 15 % menos tokens para el mismo texto. El costo del vocabulario grande está en otro lado: la matriz de embeddings y el head de salida crecen linealmente con él (256k × hidden size es una fracción visible de un modelo chico), y el softmax final sobre todo el vocabulario en cada paso de decode también.

WordPiece cambia solo el criterio de qué fusionar: en vez del par más frecuente a secas, prioriza pares donde cada parte individual es poco frecuente por sí sola — evita fusionar algo como "un" + "##able" aunque el par sea común, porque ambos fragmentos ya son comunes por separado y probablemente sirven mejor sueltos.

Unigram invierte el proceso: arranca de un vocabulario enorme (todas las subcadenas posibles, o el resultado de correr BPE hasta un vocabulario grande) y en cada paso elimina el porcentaje de tokens que, sacados, menos empeoran una función de pérdida calculada sobre todo el corpus. Nunca elimina caracteres sueltos, para poder tokenizar cualquier palabra sin caer en desconocido.

5. Armar un tokenizer, bloque por bloque

La librería tokenizers expone cada etapa del pipeline como una pieza intercambiable: normalizers, pre_tokenizers, models (BPE/WordPiece/Unigram), trainers, post_processors y decoders. Armar un tokenizer propio es elegir una de cada una y entrenarlo:

from tokenizers import Tokenizer, models, normalizers, pre_tokenizers, trainers

tokenizer = Tokenizer(models.WordPiece(unk_token="[UNK]"))
tokenizer.normalizer = normalizers.Sequence([normalizers.NFD(), normalizers.Lowercase()])
tokenizer.pre_tokenizer = pre_tokenizers.Whitespace()

trainer = trainers.WordPieceTrainer(vocab_size=25000, special_tokens=["[UNK]", "[CLS]", "[SEP]"])
tokenizer.train_from_iterator(get_training_corpus(), trainer=trainer)

El último paso, post_processor, es el que agrega los tokens especiales en su lugar ([CLS] al inicio, [SEP] entre oraciones) y asigna los token_type_ids del Capítulo 3. Un tokenizer armado así se guarda en un único JSON y se envuelve en PreTrainedTokenizerFast para usarlo exactamente igual que cualquier tokenizer de transformers — incluido subirlo al Hub con push_to_hub().

6. Errores comunes

Ninguno de estos lanza una excepción. Se ven en salidas raras, contextos truncados o facturas más altas de lo esperado.

7. Resumen

1. Entrenar un tokenizer es estadístico y determinístico — nada que ver con entrenar un modelo.
2. tokenizer(texto) → ids → decode es un ida y vuelta exacto en BPE a nivel de byte; Ġ, ## y ▁ son las tres formas de marcar dónde iban los espacios. Los ids solo significan algo para el modelo que se entrenó con ese tokenizer.
3. Un tokenizer rápido (Rust) trae offset mapping — la pieza que hace posible NER y QA sin reglas hechas a mano por tipo de tokenizer.
4. Normalización + pre-tokenización deciden los límites; BPE, WordPiece y Unigram deciden cómo llenar el vocabulario dentro de esos límites, desde direcciones opuestas (construir vs. podar).
5. BPE a nivel de byte es el estándar de facto en LLMs decoder-only hoy — vocabulario base minúsculo, cero tokens desconocidos posibles. Los vocabularios crecieron de 32k–50k a 128k–256k, y eso se traduce directo en menos tokens (menos costo, más contexto útil) para todo lo que no sea inglés.
6. Cada etapa del pipeline es una pieza intercambiable en tokenizers — armar un tokenizer propio es elegir una de cada tipo y entrenarlo.

8. Ponete a prueba

Respondé antes de abrir cada respuesta. Si fallás una, volvé a la sección indicada.

9. Para practicar

from transformers import AutoTokenizer

texto = ("El interpretante lacaniano no es una persona sino una función: "
         "la que sostiene la cadena significante mientras el sujeto habla.")
palabra = "interpretante"

for nombre in ["gpt2", "HuggingFaceTB/SmolLM2-135M", "Qwen/Qwen2.5-0.5B", "google/gemma-4-E2B-it"]:
    tok = AutoTokenizer.from_pretrained(nombre)
    n = len(tok(texto, add_special_tokens=False)["input_ids"])
    print(f"{nombre:32s} vocab={len(tok):>7d}  tokens={n:3d}  {len(texto)/n:.1f} chars/token  {tok.tokenize(palabra)}")

pruebas = ["Hola  mundo", "Árbol y ñandú", "código\tcon tab", "emoji 🤗 raro"]
for nombre in ["gpt2", "bert-base-uncased"]:
    tok = AutoTokenizer.from_pretrained(nombre)
    for t in pruebas:
        ids = tok(t, add_special_tokens=False)["input_ids"]
        vuelta = tok.decode(ids)
        print(f"{nombre:18s} {vuelta == t!s:5}  {tok.convert_ids_to_tokens(ids)}")

from tokenizers import Tokenizer, models, pre_tokenizers, trainers

corpus = ["hug"] * 10 + ["pug"] * 5 + ["pun"] * 12 + ["bun"] * 4 + ["hugs"] * 5

tok = Tokenizer(models.BPE())
tok.pre_tokenizer = pre_tokenizers.Whitespace()
tok.train_from_iterator(corpus, trainer=trainers.BpeTrainer(vocab_size=12, show_progress=False))

tok.save("bpe-juguete.json")
import json
print(json.load(open("bpe-juguete.json"))["model"]["merges"])
print(tok.encode("bug").tokens, tok.encode("hugging").tokens)

10. Fuentes y para seguir

• Hugging Face LLM Course — Chapter 6: The 🤗 Tokenizers library — el capítulo original, con los tres algoritmos trabajados paso a paso y el tokenizer armado bloque por bloque.
• Tokenizers — documentación — la referencia de la librería en Rust: normalizers, pre-tokenizers, modelos, trainers, post-processors y decoders.
• Neural Machine Translation of Rare Words with Subword Units (Sennrich et al., 2015) — el paper que trajo BPE al NLP; el algoritmo de §4 está en su sección 3.
• Subword Regularization (Kudo, 2018) — el paper de Unigram: por qué tener varias segmentaciones posibles con probabilidad es una ventaja, no un defecto.
• SentencePiece (Kudo & Richardson, 2018) — texto crudo sin pre-tokenización, el símbolo ▁, y la reversibilidad de §3.
• The Llama 3 Herd of Models (Meta, 2024) — la sección de tokenizer explica el salto a 128k y su efecto en tokens por texto, el dato de §4.