Cero. Esa es esencialmente la superposición entre cómo se entrena a los LLMs para “hablar” idiomas indios y cómo millones de personas realmente los escriben en un smartphone.
Desde hace años, los grandes laboratorios se han estado felicitando por su soporte “multilingüe”. Señalan benchmarks donde un modelo puede traducir hindi o tamil formal con alta precisión. Pero hay una brecha enorme entre un libro de texto y un chat de WhatsApp. En el mundo real, los hablantes bilingües utilizan code-mixing romanizado (RCM)—mezclando idiomas locales con inglés usando el alfabeto romano. Es la forma dominante de comunicación en estas comunidades, pero sigue siendo un punto ciego para casi todos los modelos principales.
El Indi-RomCoM benchmark finalmente pone un número a este fallo. Evalúa cómo los LLMs manejan instrucciones de code-mixing indio-inglesa romanizada, y los resultados son una ducha fría para cualquiera que crea que la “IA global” ya está aquí. Los modelos luchan porque se entrenan en conjuntos de datos limpios y formales. Pueden manejar una solicitud formal en devanagari, pero en el momento en que cambias a la versión romanizada, fonética e hibridada que usan los humanos reales, la lógica se desmorona.
¿Por qué seguimos fingiendo que un modelo es “global” cuando no puede analizar un mensaje de texto básico de Delhi? Es una acusación directa del pipeline de entrenamiento actual. Hemos pasado tanto tiempo optimizando el “estándar de oro” del idioma que olvidamos que la gente realmente habla en fragmentos e híbridos.
El problema parece ser más que una simple falta de datos; parece un fallo estructural en cómo estos modelos “ven” el texto. (Sospecho que los tokenizers son los principales culpables). La mayoría de los tokenizers están optimizados para inglés o scripts formales. Cuando se encuentran con code-mixing indio romanizado, no ven palabras; ven una secuencia caótica de fragmentos. Es como intentar aprender un idioma de un libro de texto formal y luego caer en medio de un mercado callejero abarrotado: conoces la gramática, pero no entiendes ni una palabra de lo que la gente realmente dice.
El modelo está esencialmente adivinando el significado basándose en la proximidad a tokens en inglés, en lugar de entender realmente la mezcla lingüística. O tal vez sea simplemente un problema masivo de escasez de datos—ver más abajo. La fricción aquí es real: hacer scraping y limpiar datos de RCM es una pesadilla porque no hay una ortografía estandarizada. Una persona escribe “namaste” y otra “namastay,” y el modelo tiene que tratarlos como entidades distintas a menos que el tokenizer sea lo suficientemente inteligente para ver la raíz fonética.
Esto crea un sistema de utilidad de IA por niveles. Si eres un empleado corporativo escribiendo correos formales en un script nativo, la IA es genial. Si eres un desarrollador o un usuario casual en Mumbai escribiendo en un híbrido romanizado, la IA es un lastre. Este no es un caso marginal; es la interfaz principal para cientos de millones de personas.
Hemos visto este patrón antes con idiomas de bajos recursos, donde el “soporte” en realidad significa “hicimos scraping de unas pocas páginas de Wikipedia y esperamos lo mejor.” El enfoque apático hacia el RCM sugiere que los laboratorios están más interesados en la imagen del multilingüismo que en la utilidad real. Quieren marcar una casilla en una presentación, no resolver realmente la fricción de la comunicación en el mundo real.
Es un fallo de imaginación por parte de los grandes laboratorios.
Si la industria no hace un giro desde la “traducción formal” hacia el “uso real,” estos modelos seguirán siendo juguetes para la élite y notas al pie para el resto del mundo. Necesitamos tokenizers que reconozcan los patrones fonéticos de los idiomas indios romanizados y conjuntos de entrenamiento que prioricen la realidad desordenada e híbrida del code-mixing.
Para el primer trimestre del próximo año, veremos el primer lanzamiento de un modelo importante que liste explícitamente el “Indio Romanizado” como un objetivo de entrenamiento primario en lugar de un efecto secundario del web-scraping. Hasta entonces, estos benchmarks sirven como un recordatorio necesario de que “multilingüe” a menudo es solo un término de marketing para “puede traducir un párrafo de Wikipedia.”
