Enseñan a los LLM a ver cada letra, y escribir las palabras al revés les resulta más fácil

La frase «LMU München» tiene 11 caracteres, contando el espacio. El modelo de lenguaje en el que se basa ChatGPT la recibe como tres fragmentos: «LM», «U» y «München». Las letras sueltas de «München» no las ve de forma directa. Esta particularidad está detrás de toda una clase de errores extraños: contar las letras de una palabra, hacer correcciones carácter a carácter o escribir al revés. Según TechXplore, los investigadores han demostrado que, si se ajusta el modelo para que vea cada letra, le resulta más fácil invertir una palabra.

Por qué el modelo no ve las letras

Antes de procesar el texto, un LLM lo divide en tokens: palabras completas o fragmentos de ellas. Este paso se llama tokenización en subpalabras. Se hace por eficiencia: la secuencia resulta más corta y, por tanto, más barata de calcular. Las palabras frecuentes se convierten en un solo token; las raras se componen de varios.

Ese ahorro tiene un coste. Para el modelo, el token «München» sigue siendo un identificador indivisible. Para invertir la palabra necesita saber de qué letras se compone, y eso no puede averiguarlo de forma directa. El conocimiento ortográfico debe reconstruirlo de manera indirecta, a partir de textos de entrenamiento en los que a veces se deletrean las palabras. El resultado es poco fiable. En consecuencia, los modelos tienen una comprensión limitada a nivel de carácter, algo que el material original señala de forma explícita.

Qué significa «ver cada letra»

El fragmento disponible de la publicación no describe el diseño de la mejora. Tampoco menciona los tamaños de los modelos, la precisión ni los benchmarks, así que aquí no habrá cifras concretas de mejora. El principio general se deduce del titular: el modelo accede a los caracteres individuales, y no solo a fragmentos ya preparados.

En la industria, para esto se suelen usar modelos de caracteres o de bytes, o bien se añade un nivel de caracteres sobre los tokens. Pero este enfoque también tiene un coste: las secuencias se alargan, y el coste de la atención en los transformers crece más rápido que la longitud de la entrada. Por eso la cuestión no es si el acceso a los caracteres ayuda. Ayuda. La cuestión es cuánto cómputo habrá que pagar a cambio.

Breve resumen de lo que se sabe a partir del material:

• Ejemplo de división: «LMU München» se convierte en 3 tokens («LM», «U», «München») con 11 caracteres.
• Mecanismo del problema: la tokenización en subpalabras oculta al modelo las letras individuales.
• Tarea de prueba: escritura inversa de palabras.
• Resultado: los modelos que ven cada letra la resuelven con más facilidad.
• No se revela en el texto disponible: arquitectura, tamaños de los modelos, métricas numéricas.

Qué deben hacer los desarrolladores

Mientras estos modelos no se conviertan en estándar, conviene no confiar a ciegas en un LLM las operaciones con caracteres en los productos. La verificación de códigos y números, los anagramas, la transliteración, la comparación carácter a carácter o la corrección de erratas en nombres: todo esto es más fiable hacerlo con código convencional. En estos escenarios, el modelo debe actuar como orquestador que pasa la tarea a una herramienta, no como ejecutor.

Hay que tener especial cuidado con los idiomas de morfología rica. Los tokenizadores de alemán y ruso suelen fragmentar más que los de inglés, y los errores de caracteres aparecen allí con más frecuencia. Si elige un modelo para este tipo de trabajo, pruébelo con sus propios datos: invierta una decena de sus cadenas reales y compruebe qué resulta.

Sobre el estudio en sí, conviene esperar al texto completo con las cifras. La dirección parece razonable, pero la pregunta principal sigue abierta: si la ganancia en precisión a nivel de carácter bastará para justificar el aumento del coste computacional.