Skip to content

English · Español

00 — Por qué la tokenización es el primer compromiso

🇪🇸 Un tokenizer convierte texto en una secuencia de IDs enteros — el alfabeto sobre el que el modelo opera. Cada elección (caracteres, palabras, sub-palabras, bytes) tiene un coste: cobertura, longitud de secuencia, manejo de errores. La elección filtra todo lo demás del proyecto.

Qué es un tokenizer

Un tokenizer es una biyección determinista (o casi-biyección) entre cadenas y secuencias finitas de IDs enteros. El ID es lo que el modelo realmente ve. El vocabulario \(V\) del modelo es el tamaño del espacio de tokens.

Pseudo-formalmente:

encode : str → list[int]
decode : list[int] → str

con la propiedad decode(encode(s)) ≈ s (exacta para BPE byte-level; a veces con pérdidas para tokenizers que normalizan caracteres).

Dos consecuencias no obvias:

  1. El tamaño del vocabulario \(V\) controla el tamaño del modelo. La matriz de embedding es (V, d) y la proyección de salida es (d, V). Para \(d = 768\) y \(V = 50{,}000\): 38M de parámetros solo por el embedding. Duplicar \(V\) añade otros 38M. La elección de \(V\) es una decisión de arquitectura del modelo, tomada aquí, antes de que exista ningún modelo.

  2. La distribución de longitud de tokens controla el coste por longitud de secuencia. Un tokenizer a nivel de carácter convierte works en 5 tokens; uno a nivel de palabra en 1; uno de subpalabra en 1 o 2 según la frecuencia de entrenamiento. La attention del transformer es \(O(L^2)\) en longitud de secuencia, así que una tokenización 5× más larga es un coste de cómputo 25× mayor. La elección es una decisión de tiempo de ejecución.

El tokenizer es el primer compromiso del proyecto. No puede ser re-decidido más adelante sin reentrenarlo todo.

Las tres opciones (y la que construiremos)

Hay tres familias de tokenizers en uso moderno:

Familia A — nivel de carácter

"I work" → ['I', ' ', 'w', 'o', 'r', 'k'] → [73, 32, 119, 111, 114, 107].

  • Pro: trivial. Nunca out-of-vocab.
  • Con: la longitud de secuencia es 5–10× más larga que con otros métodos. El coste cuadrático de attention crece 25–100×. Prohibitivo en cómputo.
  • Donde se usa: modelos de lenguaje muy pequeños a nivel de carácter, ByT5 (Google, 2021) — pero no en el linaje mainstream de LLM.

Familia B — nivel de palabra

"I worked" → ['I', ' ', 'worked'] → [12, 0, 487].

  • Pro: secuencias cortas. Los tokens llevan significado semántico.
  • Con: el problema de out-of-vocabulary es fatal. Si escribes mal wroked → ['I', ' ', '<unk>']. El modelo no puede ni ver la entrada mal escrita. Para corrección gramatical (la tarea del agente de la Fase 32), es un no-arranque — el agente debe ver los errores ortográficos para corregirlos.
  • Donde se usa: PLN (NLP) clásico pre-2017. Mayormente retirado.

Familia C — subpalabra / BPE

"he works" → ['he', ' work', 's'] → [58, 109, 23].

  • Pro: equilibra ambas. Las secuencias se mantienen cortas (cercanas al nivel palabra para formas frecuentes). Nunca out-of-vocab si se implementa a nivel byte. El sufijo -s y la raíz work son tokens separados — el modelo puede aprender que el token -s, en esta posición, marca 3ª persona del singular. Esa es exactamente la estructura que necesita nuestro agente tutor de gramática de la Fase 32.
  • Con: más código, más decisiones de diseño.
  • Donde se usa: todos los LLM modernos. GPT-⅔/4, Llama, Claude, Mistral, etc.

Implementamos BPE byte-level — la variante donde el alfabeto base son los 256 posibles valores de byte (no caracteres Unicode). Esto hace al tokenizer:

  1. Libre de OOV. Cualquier cadena de bytes es tokenizable.
  2. Robusto frente a Unicode. No le importa la normalización NFC/NFD, marcas BOM, codificaciones raras.
  3. Bilingüe sin ceremonia. El español mañana (8 bytes en UTF-8) y el inglés tomorrow (8 bytes) se tokenizan lado a lado en un vocabulario compartido. No hace falta etiqueta de idioma.
  4. A prueba de errores ortográficos. Bytes basura adversariales o accidentales aún se tokenizan.

El coste: el alfabeto base son bytes, no caracteres. Así que mañana empieza como 8 byte-singletons (la ñ son 2 bytes: 0xC3 0xB1). Después de entrenar BPE sobre un corpus con español, los bytes de ñ se fusionan en un símbolo — y luego quizá añ, aña, mañana mismo si es lo suficientemente frecuente.

Para nuestro corpus de gramática verbal en inglés con traducciones españolas emparejadas (según §A13), byte-level es la única elección correcta: es la única familia que maneja la señal bilingüe de forma nativa sin mecanismos extra.

Por qué BPE específicamente (y no otros esquemas de subpalabra)

La familia de subpalabra tiene varias variantes:

  • BPE (Sennrich et al., 2016). Merge codicioso por frecuencia. Simple, determinista, rápido.
  • WordPiece (Schuster & Nakajima, 2012). Como BPE pero fusiona para maximizar verosimilitud bajo un modelo unigram. Usado por BERT.
  • Unigram (Kudo, 2018). Entrena un modelo de lenguaje unigram, poda tokens de baja probabilidad. Usado por SentencePiece / T5.

Los tres alcanzan calidad similar en benchmarks. Elegimos BPE porque:

  1. El algoritmo es el más simple de los tres. Borja puede implementarlo desde cero en ~150 líneas de Python.
  2. Es lo que usa GPT-2 (y tomamos prestada la variante byte-level de GPT-2). Conecta directamente con código LLM open-source moderno en la Fase 24.
  3. Es determinista. Sin entrenamiento EM, sin ambigüedad. Reproducible a partir de una semilla.

WordPiece y Unigram son solo de encuesta en theory 02; no los implementamos.

En qué se filtra la elección

  • Corpus de la Fase 12: el corpus son los datos sobre los que entrena BPE. Su diseño (20 verbos × 5 tiempos × 3 personas + pares en español) determina qué merges ganan.
  • Embeddings de la Fase 13: la matriz de embedding es (V, d) donde V se fija aquí.
  • Attention de la Fase 15: la longitud de la secuencia de entrada depende de la granularidad de tokenización. Una frase de 6 palabras se vuelve ~6–10 tokens; el coste de attention es entonces ~36–100 productos internos.
  • Entrenamiento de la Fase 18: la pérdida (loss) de entropía cruzada es sobre \(V\) clases; un \(V\) pequeño es barato por paso.
  • Inferencia de la Fase 22: la generación muestrea un token a la vez; tokens más largos (p. ej., works como un token) significan menos muestras por carácter de salida.
  • Agente tutor de gramática de la Fase 32: el agente recibirá la frase mal escrita o mal conjugada de un aprendiz; BPE byte-level garantiza que siempre se tokenice.

Cada fase desde la 11 en adelante depende de esta. Elige bien.

Una comprobación semántica rápida (la verificación post-entrenamiento)

Después de entrenar BPE sobre nuestro corpus de verbos en inglés con pares en español, los merges principales deberían ser interpretables como subcadenas significativas morfológica o distribucionalmente. Victorias esperadas (el DoD del laboratorio las comprueba):

  • work, play, walk, listen — raíces verbales frecuentes con su espacio inicial.
  • -s (tras raíces) — marcador de 3ª persona singular del presente.
  • -ed — marcador de pasado simple regular.
  • will — marcador de futuro simple.
  • to — marcador de futuro going to y marcador de infinitivo.
  • he, she, I, you, it — pronombres.
  • Para el lado español: trab, come, ar, er, ió, ará — raíces y terminaciones de conjugación española.
  • \n, ., , — separadores.

Si entrenamos BPE y los merges principales son sinsentido, algo va mal con el corpus, el entrenamiento o ambos. La verificación "los merges principales son interpretables" es un elemento DoD de la fase, no una intuición.

Por qué no usar simplemente tiktoken

tiktoken es la biblioteca BPE open-source de OpenAI — rápida, correcta, popular. ¿Por qué no pip install tiktoken y saltarse la Fase 11?

Tres razones:

  1. Regla dura 4 del §0 de CLAUDE.md (construir antes de abstraer). Todo el currículo es "construye, luego lee el código de otros". Saltarse la construcción salta el aprendizaje.
  2. Personalización. tiktoken viene con vocabularios de GPT-2/4. Nuestro corpus no es prosa inglesa; es una matriz gramatical deliberadamente pequeña con pares en español. Entrenar nuestro propio vocabulario produce merges que casan con nuestros datos. El patrón a nivel de morfema (-s, -ed) es improbable que sea un merge principal en el vocabulario de GPT; lo será en el nuestro.
  3. Transparencia. Cuando algo va mal con cómo el modelo maneja una entrada específica, necesitas entrar en el tokenizer. Las llamadas a biblioteca caja-negra ocultan bugs.

En la Fase 24 leemos el código fuente de tiktoken como parte de la sub-fase "comparación de frameworks". Nuestra versión hecha a mano es la referencia con la que comparamos.

La tokenización es una frontera de robustez

El agente tutor de gramática de la Fase 32 recibe la frase de un aprendiz — posiblemente mal escrita (wroked), posiblemente mal conjugada (he goed), posiblemente bilingüe (Yo work mañana). Cada token que procesa fue producido por este tokenizer. Tres consideraciones de robustez:

  1. Ningún crash del tokenizer. Una secuencia de bytes malformada debe tokenizarse, no lanzar excepción. BPE byte-level lo garantiza.
  2. Confusables Unicode. 0 (dígito cero) vs O (letra O mayúscula) vs griego Ο (omicron). Se ven idénticos, se renderizan idénticos, pero se tokenizan distinto. El agente de gramática debe razonar sobre identidad visual vs identidad de token. No resolvemos esto; lo exponemos.
  3. Ambigüedad NFC/NFD. mañana puede almacenarse de dos formas: NFC (4 codepoints, uno de ellos ñ precompuesto) o NFD (5 codepoints, n + tilde combinante). Ambos se renderizan idénticos; se tokenizan distinto a nivel byte. La teoría 03 lo aborda explícitamente.

Estos vuelven a aparecer en la Fase 32. Por ahora, BPE byte-level es la elección correcta porque no deja ningún comportamiento sorprendente a nivel de tokenizer — todas las sorpresas están en el modelo mismo.

Recapitulación en un párrafo

Un tokenizer mapea cadenas a secuencias de IDs enteros y de vuelta. La elección restringe cada fase posterior: el tamaño del vocabulario fija el tamaño de la matriz de embedding, la granularidad del token fija la longitud de la secuencia y por tanto el cómputo de attention. Tres familias: carácter (demasiado largo), palabra (OOV fatal), subpalabra (Ricitos de Oro). Entre las subpalabras, BPE byte-level es lo que usan GPT-2 y los LLM modernos porque es simple, determinista, libre de OOV, robusto frente a Unicode, y maneja nuestro corpus bilingüe inglés-español de verbos sin mecanismo extra. Lo construimos desde cero; la Fase 24 compara con tiktoken.

Lo que esta página de teoría NO cubre

  • El algoritmo BPE en sí. Eso es theory 02.
  • Mecánica detallada de bytes / Unicode. Theory 03.
  • Regularización de subpalabra (dropout aleatorio de sub-tokens durante el entrenamiento para hacer a los modelos robustos frente a tokenizaciones alternativas). Preocupación de Fase 18+.
  • Estrategias de crecimiento del vocabulario (empezar pequeño y crecer, o fijar en tiempo de entrenamiento). Fijamos en tiempo de entrenamiento; los esquemas de vocabulario creciente son solo de investigación.

Siguiente: theory/01-character-word-subword.md.