El texto en nepalí "pesaba" tres veces más que el inglés: el arreglo del tokenizador no logró solucionarlo del todo

Por qué los modelos de lenguaje desperdician tokens con el nepalí

Un equipo de investigadores averiguó por qué modelos de lenguaje como Llama-3 y Qwen3 manejan el texto en nepalí de forma tan derrochadora, e intentaron solucionarlo. Resultó que el problema no está en el vocabulario del modelo, sino en el primer paso, el más imperceptible, del procesamiento de texto: la división previa en fragmentos que ocurre antes de que el tokenizador empiece siquiera a ensamblar tokens.

De dónde viene el sobreconsumo de tokens

Los tokenizadores del tipo GPT-2, sobre los que están construidos Llama-3 y Qwen3, cortan el texto con una expresión regular antes de la tokenización principal. Esta expresión solo considera "palabra" a una secuencia de letras Unicode. El problema es que el nepalí usa la escritura devanagari, donde las vocales no se representan con letras independientes, sino con signos especiales colocados encima o debajo de la letra base, los llamados signos combinantes. En Unicode, estos signos formalmente no se consideran "letras", así que la expresión regular corta la palabra nepalí literalmente en cada signo vocálico.

El resultado: donde un hablante de inglés gasta un token, el mismo texto en nepalí requiere en los mismos modelos entre 2 y 3 veces más tokens para transmitir la misma cantidad de significado. Los investigadores midieron esto en el corpus paralelo FLORES-200 (las mismas oraciones en distintos idiomas): el tokenizador de Qwen3 gasta notablemente más tokens en una oración en nepalí que en su traducción al inglés, y el tokenizador que usan Phi-4, OLMo-2 y Granite-4.1 es todavía peor.

Para los usuarios, esto no es una métrica abstracta. Más tokens para el mismo significado implica una consulta más cara, una respuesta más lenta y menos contenido útil cabiendo en la ventana de contexto del modelo.

Por qué el "afinamiento" habitual del vocabulario no ayuda

El método estándar para enseñar a un modelo ya entrenado a manejar mejor un idioma nuevo es la llamada extensión de vocabulario basada en fusiones (merge-based vocabulary extension): se añaden al vocabulario nuevos tokens fusionados que el modelo termina de aprender con texto del idioma nuevo. El problema es que la división por expresión regular ocurre antes de cualquier fusión, y si una palabra ya fue cortada en pedazos por sus signos vocálicos, ninguna cantidad de fusiones nuevas podrá volver a unir fragmentos separados por ese corte. Los investigadores demuestran que este enfoque tiene un "techo" matemático de ahorro, que depende únicamente de la expresión regular, no del tamaño del vocabulario.

Lo comprobaron con lanzamientos reales: encontraron diez extensiones de vocabulario publicadas anteriormente para seis escrituras distintas (en Llama-3, Llama-3.1, Qwen2.5 y Qwen3), y las diez chocaron con su respectivo techo, exprimiendo al menos un 98% del ahorro posible. Es decir, los desarrolladores de estos modelos ya habían hecho todo lo que se podía hacer con el método estándar: seguir insistiendo solo con el vocabulario no tiene sentido.

Los investigadores también probaron un atajo: registrar cadenas en nepalí como "tokens añadidos" que no pasan en absoluto por la expresión regular. Esto efectivamente rompe el techo, pero arruina la segmentación por límites de palabra: una quinta parte de esos tokens empieza a coincidir justo en medio de una palabra, lo que daña el sentido de la división.

Qué logró la "reparación" de la expresión regular

Los investigadores reescribieron la expresión regular para que los signos vocálicos devanagari se consideraran parte de la palabra y no caracteres separados. Una propiedad importante de su corrección: demostraron matemáticamente que, para cualquier texto sin signos combinantes ni caracteres devanagari (es decir, para el inglés y el código), la tokenización se mantiene absolutamente idéntica a la anterior; ningún token cambia.

Con la nueva expresión regular y 32.000 pares de fusión nuevos, el texto en nepalí pasó a requerir casi la misma cantidad de tokens que el inglés: un 54% menos de tokens que con la extensión de vocabulario estándar.

Pero al afinar de verdad los modelos Llama-3.2-1B y Qwen3-0.6B con una mezcla de textos en nepalí e inglés, el resultado fue inesperado: el tokenizador original, el "sin corregir", mostró con el mismo presupuesto una mejor calidad de predicción del nepalí (medida en bits por byte) que tanto la versión corregida como la versión con extensión estándar. Esta era la hipótesis principal de los investigadores, y no se confirmó.

Con igual número de pasos de entrenamiento (en lugar de bytes), el tokenizador corregido resultó mejor en Qwen, pero peor en Llama, es decir, la ganancia fue inconsistente entre modelos. Aumentar la tasa de aprendizaje en Qwen mejoró los resultados de las tres variantes, pero no cambió su orden relativo.

Qué significa esto en la práctica

Para los ingenieros que afinan modelos abiertos para idiomas con signos combinantes (no solo el nepalí, sino también, por ejemplo, el tailandés, el árabe o el bengalí), la conclusión es doble. Por un lado, el ahorro de tokens es real y está confirmado matemáticamente: el tokenizador corregido gasta de forma comprobada un 54% menos de tokens en el mismo texto en nepalí, sin afectar al inglés ni al código. Por otro lado, menos tokens no significa automáticamente un mejor modelo: los propios investigadores demuestran que en sus pruebas el tokenizador viejo, el "sin corregir", sigue ganando en calidad con el mismo presupuesto de cómputo.

Queda una pregunta abierta que los investigadores no comprobaron, y lo reconocen con honestidad: si el ahorro de tokens se traduce en la práctica en una ganancia de velocidad y costo de generación de texto, incluso con una calidad algo menor. El código, los tokenizadores entrenados y el plan de análisis están disponibles en acceso abierto en GitHub y Hugging Face.