Si alguna vez le has pedido a ChatGPT 4 que cuente cuántas veces aparece la letra «r» en la palabra «strawberry», habrás descubierto algo raro: un modelo capaz de escribir un ensayo sobre Kant falla una pregunta que resolvería un niño de cinco años. Dirá «dos» cuando son tres. Y si insistes, a veces se disculpa y sigue equivocándose.
No se trata de un bug. Es una ventana a cómo funcionan realmente estos modelos por dentro. La respuesta cabe en una palabra —tokens— y en una idea: el modelo no razona sobre letras, sino sobre piezas de texto que no puede descomponer.
Si le preguntas a alguien que trabaja con IA qué es un token, probablemente te dirá que es «como una palabra». Eso es aproximadamente cierto, pero la realidad es más interesante — y entenderla cambia cómo interpretas el comportamiento de los modelos.
Entonces, ¿qué son los tokens exactamente? Los LLMs son la cara más visible del Procesamiento de Lenguaje Natural (NLP), una disciplina que lleva décadas enseñando a las máquinas a leer. El camino empezó con reglas lingüísticas escritas a mano y ha terminado en las redes neuronales que conocemos hoy.
El NLP está en el centro de tareas como el análisis de sentimiento en las RRSS, la detección de spam en el email, la traducción automática entre distintas lenguas o la clasificación de textos.
El Lenguaje como Piezas de Lego
Imagina que estás construyendo una ciudad con piezas de Lego. No usas una pieza distinta para cada edificio: tienes un catálogo limitado de piezas —rectángulos de distintos tamaños, cuadrados, triángulos— y con esas piezas montas lo que haga falta.
El lenguaje, para un modelo, funciona parecido. En vez de aprender todas las palabras posibles del español (imposible: hay demasiadas formas verbales, nombres propios, neologismos), el modelo tiene un catálogo fijo de «piezas de texto» que puede combinar.
Ese catálogo se llama vocabulario. Y cada pieza de ese catálogo es un token.
Palabras muy comunes como «casa» u «hola» suelen ser un único token: una pieza entera. Palabras menos comunes como «paralelepípedo» se montan con varias piezas: «paral», «elepíp», «edo». Y nombres propios raros, errores tipográficos o términos técnicos pueden necesitar todavía más.
Porqué Partes de Palabras y no Palabras
La separación del texto en partes más pequeñas es tan antiguo como el propio NLP. En el comienzo una de las formas más básicas de tokenizar era utilizando los espacios en blanco y los signos de puntuación. Podría parecer intuitivo quedarnos con estas palabras completas como tokens y durante un tiempo ese fue el criterio que se usó. Pero este método generaba dos grandes problemas.
Por un lado, los vocabularios crecían y crecían alcanzando tamaños gigantescos lo que hacía que el coste computacional se multiplicase rápidamente. Además, tratar cada forma verbal como una entrada distinta (correr, corro, corres, corremos…) dispara el número de términos poco frecuentes en el corpus —las llamadas palabras raras
Según datos de la RAE, en los últimos años el número de voces nuevas en nuestro idioma (nuevas entradas/artículos, no meras acepciones ni enmiendas) está en el orden de los 300-600 anuales, y esto solo son las voces aceptadas por la RAE. El hecho de que las palabras crezcan sin fin nos lleva a un problema para cualquier modelo computacional. No importa como de grande sea nuestro vocabulario, nunca tendremos un vocabulario que capture todas las palabras que podamos encontrar. Eso significa que constantemente nos encontraremos con palabras que el modelo no ha visto antes, palabras desconocidas o OOV (Out of Vocabulary). Este es un gran reto para los modelos de Machine Learning.
Cómo ve el texto un Modelo
Cuando escribes «Hola, ¿cómo estás?» en ChatGPT, el modelo no ve esa frase. No ve letras. No ve palabras. Lo que recibe es algo así:
[49864, 11, 12873, 46515, 58166, 30]
Seis números. Cada uno representa un token del catálogo. La coma es un token. El signo de interrogación es un token. «cómo» es un token, «estás» también.
Sin embargo, un mismo texto en español y en inglés produce un número de tokens muy diferente. Veamos un ejemplo usando el tokenizador de ChatGPT de los último 3 modelos hasta la fecha:
Un mismo texto, en español consume sustancialmente más tokens que en inglés. No un poquito: entre un 30% y un 50% más en muchos casos. ¿Por qué? Porque los modelos se entrenaron con mucho más texto en inglés, así que su vocabulario está optimizado para ese idioma. En español, palabras enteras como «comunican» o «transformando» se parten en piezas pequeñas.
No se trata de un fallo: la realidad es que cada familia de modelos usa un tokenizer distinto, con un vocabulario distinto. Esta es la evolución reciente:
| Generación | Tokenizer | Vocabulario |
|---|---|---|
| GPT-3 | r50k_base |
~50.000 tokens |
| GPT-3.5 y GPT-4 | cl100k_base |
~100.000 tokens |
| GPT-4o, o1, o3 | o200k_base |
~200.000 tokens |
| GPT-5 | o200k_harmony |
~200.000 tokens |
Cada salto resuelve problemas distintos, y mirarlos en conjunto revela las prioridades de OpenAI en cada momento:
- De GPT-3 a GPT-4 (
r50k→cl100k): el foco estaba en el código y la conversación. Se mejoró el tratamiento de espacios e indentación (clave para Python), los números se agruparon en piezas de hasta tres dígitos, más parecidas a cómo los leemos los humanos, lo que ayudó a la aritmética. Se añadieron tokens especiales para marcar quién habla en una conversación. - De GPT-4 a GPT-4o / GPT-5 (
cl100k→o200k): el foco cambió al multilingüismo. El vocabulario se duplicó y se incorporaron muchas más palabras enteras de idiomas distintos del inglés. Español, francés, alemán, chino y árabe dejaron de pagar la «tasa de diseño anglocéntrico» de los tokenizers anteriores.
El efecto práctico es que la misma frase en español puede dar, por ejemplo, 41 tokens con GPT-4 y 35 con GPT-5. No porque el texto haya cambiado: porque el vocabulario es mejor.
Porqué el español paga peaje: la web en inglés, los corpus aún más
Hay una pregunta que seguramente te estás haciendo a estas alturas y que no hemos respondido todavía: ¿por qué arrastramos este sesgo? La respuesta está en el texto con el que se entrena a los modelos.
Intuitivamente uno pensaría que los modelos reflejan la distribución de idiomas de internet. Pero los datos revelan algo más incómodo:
| Fuente | Contenido en inglés |
|---|---|
| Sitios web (estimación W3Techs sobre top 10M) | ~55% |
| Common Crawl (texto bruto de la web) | ~44% |
| Datos de entrenamiento de GPT-3 | ~92,65% |
| Datos de entrenamiento de LLaMA 2 | ~89,70% |
La web ya está sesgada hacia el inglés, pero los equipos que construyen los corpus de entrenamiento amplifican ese sesgo a través de sus decisiones de filtrado porque los filtros de calidad (longitud mínima, dominios confiables, baja repetición) eliminan proporcionalmente más texto en idiomas diferentes al inglés, incluso cuando el texto original era válido. El resultado: los modelos viven en una burbuja anglófona bastante más estrecha que la realidad de internet.
Esto no es un accidente técnico. Es una decisión de diseño con consecuencias medibles: peor rendimiento en benchmarks en español, peor comprensión de matices culturales, peor eficiencia en tokenización. Y explica por qué la mejora de o200k_base para el español fue tan celebrada: fue una corrección parcial de un sesgo acumulado hasta la fecha con un impacto muy real en los costes de usar este modelo en español.
Pero el coste de usar un LLM en español no es un dato estable. Un proyecto que hace dos años era un 50% más caro en español que en inglés, hoy está un 25-30% más caro, y en dos años probablemente la brecha sea del 10-15%. Para equipos que planifican inversiones a medio plazo, esto cambia los cálculos de ROI: lo que hoy parece caro en español es esperable que sea significativamente más barato con la próxima generación de modelos.
Lo que te llevas — y lo que viene
Si solo te llevas una idea de este artículo, que sea esta: el modelo no lee tu texto, lee tokens. No ve letras, no ve palabras como hacemos los humanos; ve piezas de un catálogo finito con el que tiene que trabajar y que no puede descomponer. Esa sola frase explica por qué falla contando erres, por qué tu proyecto en español cuesta más que el mismo proyecto en inglés, y por qué cada nueva generación de modelos trae un tokenizer mejor.
Pero hay una segunda consecuencia de esto que merece su propio artículo, y es la que abrimos en el siguiente post: si el modelo trabaja en tokens, todo lo demás también se mide en tokens. Lo que le pides, lo que te responde, las instrucciones del sistema, los documentos que le adjuntas, el historial de la conversación… todo se traduce a la misma moneda. Y esa moneda cabe en un espacio limitado: la ventana de contexto.
En la próxima entrega veremos qué es realmente esa ventana (no es lo que la mayoría piensa), por qué el coste de una llamada a la API no se explica solo con el tamaño del prompt, y por qué —aunque un modelo anuncie «1 millón de tokens de contexto»— hay un punto a partir del cual su rendimiento empieza a degradarse aunque técnicamente «quepa todo». En otras palabras: el token no solo es la unidad de lectura del modelo; también es la unidad en la que se paga, se mide y, a veces, se olvida.
Nos vemos en el siguiente post.
