RAG multilingüe: documentos y preguntas en distintos idiomas
Si sus documentos están en español, inglés y catalán, pero sus usuarios preguntan en cualquiera de los tres (o en los tres a la vez), necesita un sistema RAG multilingüe: uno capaz de recuperar el pasaje correcto aunque la pregunta y el documento no compartan idioma. Esto no se resuelve solo llamando a un traductor automático antes de generar la respuesta: afecta a cómo indexa, cómo busca y cómo evalúa el sistema. Repasamos las tres estrategias de recuperación entre idiomas, el papel del stemming por idioma y una checklist de control de calidad.
Qué significa exactamente «RAG multilingüe»
Bajo esa etiqueta se esconden varios problemas distintos, y conviene identificar cuál es el suyo antes de elegir solución. El primero es documentos monolingües con preguntas en varios idiomas: por ejemplo, un manual técnico solo en inglés que su equipo de soporte en España consulta en español. El segundo es documentos multilingües (un contrato en inglés, una política interna en español, un anexo en francés) sobre los que se hacen preguntas también en varios idiomas, sin que el usuario sepa de antemano en qué idioma está la respuesta. El tercero, más sutil, es decidir en qué idioma debe responder el sistema: ¿en el de la pregunta, en el del documento de origen, o siempre en uno fijo (por ejemplo, el idioma corporativo)?
Cada uno de estos escenarios exige decisiones distintas de indexación y de recuperación. Si confunde «traducir la respuesta final» con «recuperar el pasaje correcto entre idiomas», el sistema parecerá funcionar en las pruebas rápidas y fallar en producción en cuanto alguien pregunte en un idioma que no probó. Conviene repasar antes cómo funciona RAG paso a paso para ubicar en qué fase del proceso (recuperación, no generación) se juega realmente la partida multilingüe.
Las tres estrategias de recuperación entre idiomas
No existe una única forma «correcta» de hacer recuperación cruzada entre idiomas. En la práctica se combinan tres mecanismos, y los sistemas más robustos no eligen uno solo, sino que los mezclan según el caso.
Traducción en tiempo de consulta
La opción más directa: cuando llega una pregunta, se detecta su idioma y se traduce automáticamente al idioma (o idiomas) en los que están los documentos antes de lanzar la búsqueda. Es sencilla de montar y funciona razonablemente bien con buscadores de texto clásicos, porque convierte un problema multilingüe en uno monolingüe. El inconveniente es que la calidad de toda la recuperación queda atada a la calidad de esa traducción puntual: términos técnicos, siglas o nombres propios mal traducidos hacen que la búsqueda no encuentre nada, aunque el pasaje correcto exista en el documento. También añade una llamada extra y, por tanto, latencia.
Embeddings multilingües
Un modelo de embeddings multilingüe sitúa frases con el mismo significado cerca en el espacio vectorial, independientemente del idioma en que estén escritas. Así, la pregunta «¿cuántos días de vacaciones tengo?» y el pasaje «the employee is entitled to 23 working days of annual leave» pueden quedar próximos aunque no compartan ni una palabra. Esta es la base de la búsqueda semántica aplicada al caso multilingüe, y no requiere traducir nada de forma explícita. El límite aparece con jerga muy específica de un sector, nombres de producto o abreviaturas que el modelo no ha visto en suficientes idiomas durante su entrenamiento: ahí el parecido semántico se degrada y la recuperación falla de forma silenciosa.
Índices separados por idioma con enrutado
La tercera estrategia consiste en detectar el idioma de la pregunta y dirigirla al índice correspondiente (o traducir solo para decidir a qué índice ir, no para buscar). Es la que mejor aprovecha el análisis léxico específico de cada idioma, porque cada índice puede aplicar su propio stemming, sus propias listas de palabras vacías y sus propias reglas de normalización. El coste es operativo: hay que mantener varios índices, detectar bien el idioma de entrada (lo que falla con preguntas cortas o con mezcla de idiomas, habitual en Cataluña o el País Vasco) y decidir qué hacer cuando la respuesta útil está en un idioma distinto al de la pregunta.
Comparativa de estrategias de recuperación entre idiomas
| Estrategia | Cómo funciona | Ventajas | Inconvenientes |
|---|---|---|---|
| Traducción en tiempo de consulta | Se traduce la pregunta (o los documentos) antes de lanzar la búsqueda | Sencilla, compatible con cualquier buscador de texto | Depende de la calidad de la traducción, añade latencia, pierde matices técnicos |
| Embeddings multilingües | Un modelo sitúa frases equivalentes de distintos idiomas cerca en el espacio vectorial | No requiere traducir, capta similitud semántica entre idiomas | Pierde precisión con jerga muy específica o términos no vistos en el entrenamiento |
| Índices separados por idioma | Se detecta el idioma y se consulta el índice correspondiente, con stemming propio | Mayor precisión léxica dentro de cada idioma | Requiere detectar bien el idioma y mantener varios índices |
El papel del stemming y el análisis léxico por idioma
La parte menos visible, pero muy decisiva, de un RAG multilingüe es el componente de texto completo dentro de la búsqueda híbrida. El stemming reduce una palabra a su raíz (por ejemplo, «facturación», «facturar» y «facturado» a una raíz común) para que una búsqueda por palabras clave encuentre variantes gramaticales de un término. El problema es que las reglas de stemming son específicas de cada idioma: un stemmer en español no sabe qué hacer con una flexión verbal en francés, y aplicar el stemmer equivocado a un documento puede empeorar la recuperación en vez de mejorarla.
Esto tiene una consecuencia práctica directa en el diseño: si su base de conocimiento mezcla idiomas, cada chunk debe llevar una etiqueta de idioma para que el motor de búsqueda aplique el análisis léxico correcto, y no un único analizador «genérico» que en la práctica solo funciona bien para uno de los idiomas presentes. Las plataformas serias de búsqueda híbrida gestionan esto de forma automática al indexar: detectan el idioma del documento (o lo reciben como metadato) y aplican el stemming, la eliminación de palabras vacías y la expansión de sinónimos correspondientes a ese idioma, antes de combinar ese resultado con la parte semántica de la búsqueda.
Diseñar la base de conocimiento para varios idiomas
Antes de subir el primer documento, conviene fijar algunas decisiones de diseño que son mucho más baratas de tomar al principio que de corregir después:
- Etiquete el idioma de cada documento (y, si es posible, de cada chunk) como metadato explícito, no lo deje a la detección automática en tiempo de consulta.
- Decida si la respuesta debe darse siempre en el idioma de la pregunta, siempre en el idioma del documento fuente, o en un idioma corporativo fijo, y documente esa regla para que sea consistente.
- Revise el chunking idioma por idioma: el tamaño óptimo de fragmento puede variar ligeramente según la densidad de información de cada idioma.
- Mantenga glosarios de términos técnicos y nombres propios que no deben traducirse ni alterarse en la recuperación (nombres de producto, siglas legales, referencias normativas).
- Si convive documentación muy larga en un idioma con fragmentos cortos en otro, valore si en algún caso conviene meter contexto completo en el prompt en lugar de depender solo de la recuperación; lo explicamos en RAG vs modelos de contexto largo.
En Kopik, cuando se sube un documento a una base de conocimiento desde crear una base nueva, la extracción, el chunking y la indexación para búsqueda híbrida se aplican de forma automática, y la plataforma gestiona documentos en distintos idiomas dentro de la misma base sin que tenga que montar índices separados a mano. Esto es especialmente útil cuando una pyme tiene, por ejemplo, su manual de producto en español y la ficha técnica del fabricante en inglés, y quiere que ambas se consulten desde el mismo asistente.
Control de calidad: cómo comprobar que funciona de verdad
Un RAG multilingüe puede parecer que funciona durante las primeras pruebas y fallar sistemáticamente con un idioma concreto que nadie probó a fondo. La única forma de evitarlo es construir un conjunto de preguntas de prueba deliberadamente cruzado: preguntas en cada idioma soportado, apuntando a pasajes escritos en cada uno de los demás idiomas. El artículo sobre cómo evaluar un sistema RAG detalla las métricas generales de fidelidad y recuperación; para el caso multilingüe conviene añadir algunas comprobaciones específicas.
- Pruebe la misma pregunta de negocio traducida a todos los idiomas soportados y compare si recupera el mismo pasaje de referencia en todos los casos.
- Incluya en el conjunto de prueba términos técnicos, siglas y nombres propios que no se traducen bien de forma literal.
- Compruebe qué ocurre cuando una pregunta mezcla dos idiomas en la misma frase, algo habitual en entornos bilingües.
- Verifique en qué idioma responde el sistema y si coincide con la regla que fijó al diseñar la base.
- Revise periódicamente las preguntas sin respuesta satisfactoria agrupándolas por idioma: si un idioma concreto concentra la mayoría de fallos, el problema suele estar en el stemming o en la cobertura documental de ese idioma, no en el modelo de generación.
Pida ayuda a un hablante nativo
La forma más rápida de detectar fallos de recuperación multilingüe es pedir a una persona nativa de cada idioma que formule preguntas con sus propias palabras, no con traducciones literales de las preguntas de prueba originales. Los matices idiomáticos reales son los que mejor revelan si el stemming y los embeddings están capturando el significado o solo coincidencias superficiales.
Errores comunes al montar un RAG multilingüe
Algunos fallos se repiten con tanta frecuencia que merece la pena enumerarlos antes de empezar:
- Usar un único analizador de texto «genérico» para todos los idiomas, lo que degrada el stemming en todos menos en el idioma por defecto.
- Traducir documentos completos a un idioma único antes de indexarlos, perdiendo terminología legal o técnica precisa que no tiene equivalente exacto.
- No etiquetar el idioma de cada chunk y confiar en una detección automática que falla con fragmentos muy cortos.
- No fijar en qué idioma debe responder el sistema, lo que genera respuestas inconsistentes entre sesiones.
- Evaluar el sistema solo en el idioma principal de la organización y descubrir los problemas de los demás idiomas ya en producción.
Si además necesita consultar la base desde herramientas externas, por ejemplo integrando la recuperación multilingüe en una aplicación o en un asistente conectado por MCP, conviene revisar la documentación de la API y el servidor MCP para confirmar cómo se especifica el idioma de respuesta y cómo se filtran los resultados por idioma en cada consulta.
Pruebe la búsqueda híbrida multilingüe con sus propios documentos
Suba documentos en varios idiomas, deje que Kopik los indexe para búsqueda híbrida y consulte el resultado desde la web, la API o un cliente MCP.
Preguntas frecuentes
Antes de cerrar, respondemos a algunas dudas habituales sobre RAG multilingüe que suelen surgir al diseñar el sistema.
Preguntas frecuentes
¿Puedo tener documentos en varios idiomas dentro de la misma base de conocimiento?
Sí, siempre que cada documento (o idealmente cada chunk) quede etiquetado con su idioma, para que el motor de búsqueda aplique el stemming y el análisis léxico correctos a cada fragmento en lugar de usar un único analizador genérico para todos los idiomas.
¿Es mejor traducir todos los documentos a un único idioma antes de indexarlos?
No siempre. Traducir de forma masiva simplifica la indexación, pero suele perder terminología técnica o legal precisa y añade un paso de traducción que puede introducir errores. En la mayoría de los casos funciona mejor mantener cada documento en su idioma original y resolver la recuperación entre idiomas con embeddings multilingües o con traducción puntual de la consulta.
¿En qué idioma debe responder el sistema si la pregunta y el documento fuente están en idiomas distintos?
Depende del caso de uso, pero conviene fijar una regla explícita y documentarla: responder siempre en el idioma de la pregunta suele ser lo más natural para el usuario final, aunque en contextos legales o técnicos a veces interesa citar el pasaje original junto con una respuesta en el idioma preguntado.
¿Los embeddings multilingües hacen innecesaria la búsqueda por palabras clave?
No. Los embeddings capturan similitud semántica entre idiomas, pero fallan con siglas, nombres propios o términos muy específicos de un sector. Por eso la búsqueda híbrida, que combina coincidencia léxica con stemming por idioma y similitud vectorial, da mejores resultados que apoyarse solo en embeddings.
¿Cómo se prueba un RAG multilingüe antes de lanzarlo a producción?
Construyendo un conjunto de preguntas de prueba cruzado: la misma pregunta de negocio formulada en cada idioma soportado, apuntando a pasajes escritos en los demás idiomas, e incluyendo términos técnicos que no se traducen de forma literal. Revisar los fallos agrupados por idioma ayuda a localizar si el problema está en el stemming, en la cobertura documental o en el modelo de generación.
¿Qué pasa si una pregunta mezcla dos idiomas en la misma frase?
Es uno de los casos que más falla en sistemas que dependen de la detección automática del idioma para enrutar la consulta a un índice concreto. Conviene incluirlo en las pruebas de calidad y, si es frecuente en su organización, priorizar una estrategia basada en embeddings multilingües combinados con búsqueda híbrida en lugar de índices separados estrictos por idioma.
Reciba la newsletter de Kopik
Nuevas bases de conocimiento, guías sobre RAG y novedades del producto. Un correo cada una o dos semanas, baja con un clic.
Al suscribirse, acepta recibir nuestra newsletter. Nunca compartimos su dirección.