Los LLMs no leen lo que tú crees que leen

El malentendido fundamental

Hay una imagen mental que casi todo el mundo tiene sobre los modelos de lenguaje: reciben texto, lo leen y responden. Como si el proceso fuera análogo a la lectura humana.

No funciona así.

Antes de que un LLM procese una sola letra, el texto pasa por una etapa de transformación que fragmenta el lenguaje en unidades que no son palabras, no son sílabas, no son caracteres. Son tokens: fragmentos estadísticos determinados por la frecuencia de aparición en el corpus de entrenamiento. Y Mayra lleva tiempo señalando que esa capa es la que explica buena parte de lo que pasa después.

"Los modelos no procesan palabras: procesan fragmentos estadísticos de texto que muchas veces no coinciden con conceptos humanos. Entender eso cambia por completo cómo trabajas con ellos."

La forma en que ese proceso ocurre tiene consecuencias directas sobre lo que el modelo hace bien y dónde aparecen sus particularidades.

Cómo se decide lo que el modelo “ve”

El método más extendido de tokenización en LLMs es Byte Pair Encoding (BPE), un algoritmo desarrollado originalmente para compresión de datos y adaptado después para procesamiento de lenguaje natural.

Empieza con el vocabulario más básico posible: en los modelos modernos, los 256 valores de byte posibles (lo que se conoce como Byte-level BPE). Luego, de forma iterativa, identifica los pares de símbolos adyacentes más frecuentes en el corpus y los fusiona en un nuevo token. Repite ese proceso miles de veces hasta alcanzar el tamaño de vocabulario deseado, típicamente entre 30.000 y 100.000 tokens.

El resultado: las palabras comunes en inglés (“the”, “is”, “are”) suelen ser un solo token, las palabras menos frecuentes se dividen en subpalabras (“tokenization” puede ser [“token”, “ization”]), y las palabras raras o técnicas se fragmentan hasta el nivel de caracteres individuales.

GPT-4 usa un vocabulario de 100.277 tokens. Llama 3 uno de 128.000. La elección no es trivial: afecta la eficiencia del modelo, su coste de inferencia y su rendimiento en distintos idiomas.

Por qué los modelos se equivocan donde menos lo esperas

Cuando entiendes la tokenización, dejan de sorprenderte ciertos comportamientos de los LLMs.

El primero es la aritmética. Los modelos suelen tener dificultades con cálculos de muchos dígitos. La razón no es que no “entiendan” matemáticas: en GPT-4, los números se pre-segmentan en grupos de hasta tres dígitos por una regex previa al BPE, así que 9857 acaba siendo [“985”, “7”], y operar sobre esas representaciones fragmentadas es fundamentalmente distinto a operar sobre dígitos individuales.

El segundo es el rendimiento en idiomas no latinos. El inglés está sobrerrepresentado en los corpus de entrenamiento y, por tanto, tiene una tokenización eficiente. El español, el francés o el alemán se tokenizan de forma menos compacta. El árabe, el chino o el japonés mucho menos aún. Eso tiene dos consecuencias prácticas: los modelos consumen más tokens para procesar la misma cantidad de información en estos idiomas, lo que significa mayor coste y menor contexto efectivo.

El tercero son los conteos y deletreos. Preguntar a un LLM cuántas veces aparece la letra “r” en “strawberry” es un problema clásicamente difícil. La palabra se tokeniza como [“st”, “raw”, “berry”] (lo puedes comprobar en el tokenizer oficial de OpenAI), y el modelo opera sobre tokens, no sobre caracteres. Para contar letras, necesita “deshacer” la tokenización, una operación que no es natural en su arquitectura.

"Cuando ves a un modelo equivocarse en algo aparentemente trivial, casi nunca es un problema de inteligencia. Es la arquitectura mostrando lo que realmente está haciendo por debajo."

El coste que pocas veces se calcula bien

Cada token tiene un coste. No solo económico (las APIs de LLMs cobran por token) sino computacional: más tokens en el contexto significan más cómputo de atención, mayor latencia y más consumo de memoria.

Por eso el diseño de prompts no es solo una cuestión de claridad comunicativa. Es una decisión de ingeniería con impacto directo en el coste de operación. Un prompt verboso de 800 tokens donde uno compacto usaría 200 multiplica el coste de inferencia por cuatro en esa operación. A escala de millones de llamadas, la diferencia es enorme.

"Diseñar un prompt no es solo escribir bien. Es tomar decisiones de coste, de latencia y de arquitectura. Cada token que escribes lo estás pagando, una vez por petición y otra vez por escala."

La optimización de prompts para reducir token count sin perder efectividad ya tiene nombre propio: prompt compression. Técnicas como LLMLingua comprimen automáticamente prompts largos eliminando tokens redundantes sin degradar el rendimiento del modelo.

Cuando razonar tiene un precio explícito

Los modelos de la familia o1 de OpenAI llevaron al producto un concepto que existía desde 2022 con chain-of-thought, pero con dos diferencias clave: el modelo aprende a razonar de forma autónoma mediante reinforcement learning, sin necesidad de que el usuario lo pida, y esos tokens internos —los reasoning tokens— se facturan y se contabilizan como parte del contexto, aunque no son visibles en la respuesta.

Eso convierte el razonamiento en una variable controlable. Se puede configurar cuántos reasoning_tokens permite el modelo, balanceando calidad de respuesta contra coste y latencia. Para tareas simples, pocos. Para problemas complejos de matemáticas o código, muchos.

La implicación arquitectónica es importante: el modelo ya no tiene un único modo de operación. Tiene un espectro de capacidad cognitiva que se calibra según los recursos que se le asignan. Eso cambia cómo hay que pensar el diseño de sistemas que usan estos modelos en producción.

Para cerrar

Entender la tokenización no es un detalle técnico para especialistas. Es la base para comprender por qué estos sistemas se comportan como se comportan, y para diseñar mejor sobre ellos.

"La diferencia entre usar IA y construir productos con IA está en saber qué pasa entre el prompt y la respuesta. Quien solo ve la superficie está limitado a lo que la superficie permite."

La mayoría de demos de IA enseñan la superficie: el prompt entra, la respuesta sale. En IOX lo vemos en personas como Mayra: no le interesa la capa que se ve, sino la que decide cómo funciona todo lo demás. Esa diferencia, en un sector donde casi todo el mundo se queda en la superficie, es la que acaba importando.