Tokenizadores y chat templates

1Qué es tokenizar: del texto a los ids

Tokenizar es partir una cadena en un número finito de unidades y asignar a cada una un entero. Formalmente es un mapa determinista de texto a una secuencia de ids, cada uno dentro del vocabulario de tamaño $V$:

Los modelos modernos (Qwen, Llama, GPT) usan byte-level BPE. La clave está en byte-level: antes de mirar caracteres, el texto se codifica en UTF-8, es decir en una secuencia de bytes, y el alfabeto base del tokenizador son los 256 bytes posibles. Como cualquier texto imaginable — un emoji, un ideograma, un símbolo matemático, un idioma que el modelo nunca vio — se reduce a esos 256 bytes, nunca hay OOV (out-of-vocabulary): en el peor caso una palabra rara se rompe en muchos bytes sueltos, pero siempre es representable. No existe el token "desconocido" que descarta información.

2BPE: tokenizar como segmentar

BPE (Byte-Pair Encoding) aprende un vocabulario por frecuencia. Se parte del alfabeto de 256 bytes y, sobre un corpus grande, se busca el par de símbolos adyacentes más frecuente y se fusiona en un nuevo símbolo. La regla de merge es simplemente:

Ese par ganador se añade al vocabulario como un token nuevo y se registra la fusión. El proceso se repite — recontando frecuencias tras cada fusión — hasta alcanzar el tamaño de vocabulario objetivo (por ejemplo $V \approx 150\,000$ en Qwen3). El resultado es una tabla de merges ordenada: fragmentos frecuentes como ▁the o ción acaban siendo un solo token, mientras lo raro queda en piezas pequeñas.

En inferencia el tokenizador no reaprende nada: aplica esa tabla de merges de forma determinista, pero no fusiona de izquierda a derecha, sino por prioridad (rango de merge): en cada paso busca, entre todos los pares adyacentes presentes, el que tiene el menor rango en la tabla (el que se aprendió antes, de mayor prioridad) y lo fusiona sin importar su posición en la cadena; repite hasta que no quede ningún par aplicable. Por eso tokenizar es, en la práctica, un problema de segmentación: dado el texto, ¿cuál es la partición en unidades del vocabulario que la tabla de merges produce? La segmentación es única y reproducible, lo que garantiza que el mismo string siempre dé los mismos ids.

"tokenización" → bytes UTF-8 → [ merges BPE ] → ▁token | ización  (2 tokens)
"漢字"          → bytes UTF-8 → [ merges BPE ] → 漢 | 字  (o varios bytes: nunca OOV)

3Fertilidad y presupuesto de contexto

La fertilidad mide cuántos tokens consume el tokenizador por palabra de texto:

Un tokenizador entrenado sobre todo en inglés suele tener fertilidad cercana a $1.3$ en inglés, pero puede dispararse a $2$–$3$ en otros idiomas, en código o en texto con muchos símbolos, porque las secuencias de bytes menos frecuentes no se fusionaron en tokens grandes. Esto tiene consecuencias directas y medibles:

• Ventana de contexto: la longitud se cuenta en tokens, no en palabras. Con fertilidad $2.5$, un documento de 4000 palabras ocupa 10 000 tokens y puede no caber donde un texto en inglés equivalente sí cabría.
• Costo y latencia: más tokens por el mismo contenido significa más cómputo por secuencia, tanto al entrenar como al servir en producción.
• Presupuesto del dataset: antes de fine-tunear conviene medir la fertilidad real de tu corpus objetivo para estimar cuánto contexto vas a necesitar y cuántos ejemplos caben por batch.

4Tokens especiales: la estructura invisible

Además de los tokens de texto, el vocabulario reserva unos pocos tokens especiales que no representan contenido sino estructura. Son parte del vocabulario (tienen su id) pero el usuario nunca los escribe: los inserta el tokenizador o la plantilla.

Los marcadores de turno como <|im_start|> y <|im_end|> (convención ChatML) son los que permiten al modelo distinguir quién habla: system, user o assistant. El rol se escribe como texto justo después del <|im_start|>. Estos tokens se aprendieron durante el post-entrenamiento del modelo; usar otros distintos, o ninguno, es pedirle que interprete una estructura que no reconoce.

5El chat template: una función determinista

Un modelo de chat no recibe una lista de mensajes: recibe una única cadena de texto. El chat template es la función determinista que convierte los mensajes en esa cadena, antes de tokenizar:

En la práctica esa función render está escrita como una plantilla Jinja empaquetada junto al tokenizador (campo chat_template). Recorre la lista de mensajes e inserta los marcadores de rol y turno correspondientes. Como es determinista, el mismo messages siempre produce exactamente el mismo string — condición indispensable para que entrenamiento e inferencia coincidan.

messages = [
  {"role": "system",    "content": "Eres un asistente conciso."},
  {"role": "user",      "content": "¿Qué es la fertilidad de un tokenizador?"},
  {"role": "assistant", "content": "Es el número de tokens por palabra."}
]

ids = tokenizer.apply_chat_template(messages, add_generation_prompt=True)
# apply_chat_template = render(messages) → string → tokenizar
# produce UNA secuencia de ids con marcadores especiales, p. ej.:
# <|im_start|>system\nEres un asistente conciso.<|im_end|>
# <|im_start|>user\n¿Qué es...?<|im_end|>
# <|im_start|>assistant\n            ← header abierto por add_generation_prompt

El parámetro add_generation_prompt=True añade al final el header del turno del assistant (<|im_start|>assistant\n) pero sin contenido ni <|im_end|>: deja la cadena "abierta" justo donde el modelo debe empezar a escribir. Es lo que quieres en inferencia, para que el modelo continúe en el rol correcto. En cambio, para construir un ejemplo de entrenamiento completo (donde la respuesta del assistant ya existe) normalmente lo pones en False, porque el turno ya está cerrado.

6attention_mask, plantillas mal aplicadas y cómo inspeccionar

Al armar batches, las secuencias se rellenan con PAD hasta igualar longitudes. El attention_mask es un vector binario que marca qué posiciones son reales y cuáles relleno:

Las posiciones con padding ($a_i=0$) se ponen a $-\infty$ en los logits pre-softmax de la atención — de modo que ninguna posición real "atiende" al relleno. Es exactamente la misma idea de máscara que la causal del Módulo 0, aplicada aquí a las posiciones de relleno.

Por qué importa la plantilla correcta. Durante el fine-tuning el modelo no solo aprende qué responder, sino el formato en el que las respuestas aparecen: los marcadores de turno, los saltos de línea, dónde empieza el assistant. Si entrenas con una plantilla distinta de la que usarás en inferencia — o peor, concatenando los mensajes a mano sin marcadores — el modelo aprende una estructura que luego no se le presenta. El síntoma clásico: en producción el modelo alucina turnos, no para de generar (no emite EOS donde debía) o ignora el rol system. La causa casi nunca son los datos: es el desajuste de formato.

Cómo inspeccionar lo que realmente recibe el modelo. Nunca confíes en tu modelo mental: imprime el texto final. Llama a apply_chat_template(..., tokenize=False) para ver la cadena renderizada carácter por carácter, y luego decodifica los ids con tokenizer.decode (o token a token con convert_ids_to_tokens) para confirmar dónde caen exactamente los marcadores. Verifica el round-trip: si decode(encode(x)) reproduce tu texto (salvo los tokens especiales añadidos), la tubería está sana. Esta inspección de cinco minutos evita horas de fine-tuning tirado.

// tokenizers (Rust): cargar el tokenizer de Qwen y tokenizar
let tokenizer = Tokenizer::from_pretrained("Qwen/Qwen3-0.6B", None)?;
let enc = tokenizer.encode("Hola, mundo", true)?;   // ids del texto
let ids = enc.get_ids();                              // &[u32]
// el chat template se renderiza aparte con minijinja (plantilla Jinja)

Lecturas y recursos

✦Ejercicios

De menor a mayor complejidad. El último es el que hace un practicante de verdad.