Usted envía un chatbot para su equipo alemán. La interfaz de usuario es alemana. Los documentos fuente son en parte alemanes y en parte ingleses. Las herramientas detrás del asistente esperan valores enum en inglés, descripciones de funciones en inglés, nombres de productos en inglés, todo en inglés.
Entonces alguien hace una pregunta perfectamente normal en alemán, el modelo elige la herramienta adecuada, pasa un argumento en alemán en lugar de en inglés, y todo se viene abajo silenciosamente.
Ya he visto versiones de esto suficientes veces como para dejar de considerarlo un problema de traducción. Es un problema de ejecución.
Mi predeterminación actual es simple: dejar que los usuarios hablen el idioma que quieran, pero que el LLM haga su trabajo de recuperación, razonamiento y herramientas en inglés siempre que la fiabilidad realmente importe. A continuación, localice la respuesta fuera de ese bucle.
Eso suena ligeramente herético al principio. También es, en mi opinión, lo más práctico que puede hacer ahora mismo.
La investigación está empezando a decir esto en voz alta
Las cifras ya no son sutiles.
En el MASSIVE-Agents benchmark, los investigadores evaluaron la llamada a funciones multilingües en 52 idiomas, 47.020 muestras y 21 modelos. La mejor puntuación media en todos los idiomas fue de sólo el 34,05%. El inglés alcanzó el 57,37%. El amárico cayó hasta el 6,81%.
Eso no es un pequeño bamboleo de calidad. Es un precipicio de fiabilidad.
Luego está Lost in Execution, que se acerca aún más al problema real de los sistemas. El documento muestra que muchos fallos en la llamada a herramientas multilingües se producen después de que el modelo ya haya comprendido la intención y seleccionado la herramienta correcta. El problema dominante era el desajuste lingüístico del valor de los parámetros. En pocas palabras, el modelo sabía lo que tenía que hacer, pero expresaba los bits ejecutables en el idioma del usuario en lugar del idioma de la interfaz, por lo que la llamada fallaba de todos modos.
Y esto no se limita a la llamada a herramientas. En ¿Piensan mejor en inglés los modelos lingüísticos multilingües?, Etxaniz y sus colegas descubrieron que la autotraducción al inglés superaba sistemáticamente a la inferencia directa no inglesa en cinco tareas. Su formulación es refrescantemente contundente: los modelos son "incapaces de aprovechar todo su potencial multilingüe cuando se les pregunta en lenguas distintas del inglés".
Así que sí, los modelos multilingües son impresionantes. Pero si su listón no es "suena bastante bien" y es en cambio "debe comportarse correctamente en producción", el inglés sigue pareciendo el idioma operativo más seguro con notable frecuencia.
Por qué la RAG se rompe en el mismo sitio
La gente suele oír este argumento y pensar primero en los agentes. Llamadas a funciones, salida estructurada, ejecución de API, ese tipo de cosas.
RAG tiene la misma debilidad, sólo que una capa antes.
Si su capa de recuperación tiene que hacer coincidir el fraseo local de un usuario con el contenido escrito en idiomas mezclados, con terminología incoherente, nombres de productos traducidos y etiquetas de taxonomía medio localizadas, crea más posibilidades de que el sistema se desvíe antes incluso de que empiece la generación. Sinceramente, de ahí vienen muchas de las quejas de "el modelo no es fiable". El modelo puede estar bien. La interfaz de contenidos no lo está.
Yo preferiría normalizar pronto.
Traducir la pregunta al inglés. Recuperar contra un corpus canónico inglés. Deje que el modelo razone sobre una capa terminológica estable. Genere un borrador de respuesta en inglés si es necesario. A continuación, traduzca o localice la respuesta final para el usuario.
Así dispondrá de un lugar en el que la nomenclatura se mantiene estable:
- un título de documento canónico
- un vocabulario de producto canónico
- un esquema de herramientas canónico
- un conjunto canónico de etiquetas de recuperación
Puede seguir soportando todos los idiomas de los usuarios en el exterior. Sólo tiene que dejar de pedir al núcleo de la ruta de ejecución que sea perfectamente multilingüe en cada paso.
Esto no es antilocalización
Todo lo contrario.
Una mala arquitectura de IA multilingüe suele perjudicar primero a los usuarios locales. Consiguen la bonita interfaz localizada, luego el sistema oculto centrado en el inglés que hay debajo se comporta de forma incoherente y les hace pagar el precio.
Una localización adecuada significa ser honesto sobre dónde debe flexionar el idioma y dónde no.
Para mí, la división tiene este aspecto:
- Localice la interfaz de usuario, los avisos, el texto de ayuda, la incorporación y las respuestas finales.
- Localizar el contenido fuente que la gente lee directamente cuando ese contenido tiene que existir en el mercado.
- Mantenga las definiciones internas de las herramientas, los identificadores canónicos, las etiquetas de recuperación y los pivotes de razonamiento en inglés si esa es la capa más estable.
- Añada un posprocesamiento explícito o una revisión humana cuando un resultado localizado tenga peso legal, normativo o contractual.
Este último punto importa más de lo que a los equipos les gusta admitir. Si el modelo está hablando con un humano, la localización es una decisión de experiencia de usuario. Si el modelo está hablando con otro sistema, la lengua es un contrato de interfaz.
No son la misma cosa.
La arquitectura en la que más confío ahora mismo
Esta es la versión por la que apostaría hoy para los productos de IA multilingüe:
- El usuario pregunta en su idioma.
- El sistema traduce o normaliza la petición al inglés.
- La recuperación, el razonamiento, la clasificación y las llamadas a las herramientas se producen contra los datos canónicos en inglés.
- La respuesta final se localiza al idioma del usuario.
- Las salidas de alto riesgo reciben un paso de validación adicional antes de abandonar el sistema.
No es filosóficamente puro. Es operativamente sano.
Lo bueno es que investigaciones recientes apuntan en la misma dirección. Lost in Execution descubrió que la pretraducción de las consultas de los usuarios reducía en general los errores de desajuste lingüístico mejor que las correcciones post-hoc, aunque seguía sin recuperar totalmente el rendimiento a nivel inglés. Eso coincide con lo que muchos constructores ya sospechan en la práctica. Si espera hasta el final para limpiar la incoherencia multilingüe, suele llegar demasiado tarde.
Y sí, hay excepciones. Si está construyendo para lenguas de escasos recursos, lenguaje específico del dominio o fraseo culturalmente dependiente, traducirlo todo al inglés puede introducir desviaciones. El documento anterior advierte explícitamente de ello. Así que no convierta esto en un dogma.
Pero como norma por defecto para copilotos de empresa, asistentes internos, GAR multilingües y agentes que utilizan herramientas, creo que la regla se mantiene sorprendentemente bien.
Lo que esto significa para Rasepi
Esta es exactamente la razón por la que me preocupo tanto por la estructura canónica del contenido.
Si su base de conocimientos tiene una capa de origen limpia, una terminología estable y una localización controlada en la parte superior, es más fácil confiar en la IA. Si cada versión lingüística deriva de forma independiente dentro de la ruta de ejecución, está pidiendo al modelo que improvise donde su sistema debería ser preciso.
Todo el enfoque de Rasepi se basa en separar limpiamente esas preocupaciones. Mantenga un núcleo canónico. Localice deliberadamente. Rastree dónde existen variantes. No pretenda que todas las capas de la pila sean igualmente multilingües sólo porque la interfaz de usuario lo sea.
Solía pensar que la mejor experiencia de IA multilingüe significaba "hacerlo todo en el idioma del usuario". Ya no pienso lo mismo. No para los sistemas que tienen que recuperar el párrafo correcto, elegir la herramienta adecuada y devolver algo en lo que se pueda confiar.
La regla práctica es simple: los usuarios deben permanecer locales, pero la ruta de ejecución del LLM debe permanecer estable. Ahora mismo, eso suele significar inglés en el centro y localización en los bordes.
Eso cambiará con el tiempo. Espero que cambie rápidamente. Pero si está haciendo envíos hoy y la fiabilidad importa más que la estética, yo dejaría que el modelo pensara en inglés y que su producto hablara el idioma del usuario.