RAG multi-idioma: técnicas y buenas prácticas para recuperación entre distintos idiomas

La mayoría de los sistemas RAG se construyen y se prueban en un solo idioma, y se rompen en silencio en el momento en que un usuario hace una pregunta en un idioma distinto al de los documentos — o los documentos mismos son una mezcla de inglés, español, portugués y lo que sea que una organización haya acumulado a lo largo de los años. Para empresas y organismos de gobierno, esto no es un caso extremo. Es el escenario por defecto.

El RAG multi-idioma agrega una capa de complejidad sobre el RAG estándar: el idioma de la consulta, el idioma de los documentos y el idioma de la respuesta pueden ser todos distintos, y cada etapa del pipeline necesita tenerlo en cuenta.

Por qué esto rompe un RAG ingenuo

Un setup típico de RAG embebe documentos y consultas con el mismo modelo, y después hace una búsqueda por vecinos más cercanos. Eso funciona bien cuando todo está en un solo idioma. Pero:

• Los modelos de embeddings monolingües agrupan el texto por idioma antes que por significado, así que una consulta en español apenas recupera documentos relevantes en inglés aunque el contenido coincida.
• Las estrategias de chunking ajustadas para inglés (con conteos de tokens fijos) se comportan distinto en idiomas con otra densidad de tokenización — el chino o el japonés concentran mucho más significado por token que el inglés o el español.
• La recuperación dispersa (BM25) depende de tokenizadores y stemmers específicos de cada idioma, así que un único índice disperso ajustado para un idioma rinde mal en los demás.

Técnicas comunes

1. Modelos de embeddings cross-lingual. Modelos como multilingual E5, LaBSE, los embeddings multilingües de Cohere, o la familia text-embedding-3 de OpenAI están entrenados para que oraciones semánticamente equivalentes en distintos idiomas queden cerca en el espacio vectorial. Esta es la base: permite embeber una consulta en español y recuperar documentos en inglés sin traducir nada primero.

2. Recuperar y después traducir, no traducir y después recuperar. Es tentador traducir todo automáticamente a un idioma pivote antes de indexar. En la práctica esto agrega latencia, costo y errores inducidos por la traducción en el momento de indexar — para cada documento, sin importar si alguna vez es consultado. Generalmente es mejor mantener los documentos en su idioma original, recuperar de forma cross-lingual con un modelo de embeddings multilingüe, y traducir solo los pasajes finales que se van a mostrar o a pasarle al LLM.

3. Búsqueda híbrida con índices dispersos por idioma. La recuperación densa por sí sola puede perder términos exactos — nombres de producto, referencias legales, códigos de error. Mantener un índice BM25 o SPLADE por idioma detectado, y combinar sus resultados con la recuperación densa, recupera precisión a nivel de palabra clave sin perder el recall cross-lingual.

4. Chunking sensible al idioma. El tamaño del chunk debería definirse en relación a qué tan densa es la información en cada idioma, no como un conteo de tokens fijo aplicado a todo. Los idiomas CJK (chino, japonés, coreano) generalmente necesitan chunks más chicos (en tokens) que los idiomas de escritura latina para contener una cantidad comparable de contenido.

5. Reranking multilingüe. Después de la recuperación, un cross-encoder de reranking entrenado con pares multilingües (por ejemplo, BGE-reranker-v2-m3, Cohere rerank-multilingual) reordena los candidatos por relevancia sin importar el idioma. Este paso suele dar el mayor salto de calidad con el menor esfuerzo de ingeniería.

6. Filtrado y boosting por metadata de idioma. Etiquetar cada chunk con su idioma detectado permite filtrar, priorizar o excluir por idioma cuando importa — por ejemplo, preferir la versión en idioma original de un documento legal por sobre una copia traducida, aunque ambas estén en el índice.

Buenas prácticas

• Detectar el idioma temprano, y mantenerlo como metadata en todos lados — en el documento, en el chunk y en la consulta. Es la señal más barata que existe, y la mayoría de las decisiones del pipeline mencionadas arriba dependen de ella.
• No forzar la traducción de todo el corpus. Traducir solo lo que está por mostrarse a un usuario o pasarse al LLM, y cachear esas traducciones — no todo el índice.
• Evaluar por idioma, no solo en conjunto. Un sistema que se ve sólido en general puede estar fallando en silencio para un par de idiomas específico. Benchmarks como MIRACL y MKQA están construidos exactamente para esto y vale la pena correrlos como test de regresión.
• Normalizar el texto de forma consistente — normalización Unicode (NFC), manejo consistente de tildes y acentos, y capitalización sensible al locale evitan pérdidas sutiles de recuperación que son difíciles de debuggear después.
• Preservar las citas en el idioma original. Para casos de uso legales, de gobierno o de compliance, mostrar una cita traducida en lugar del texto fuente puede debilitar la confianza en la respuesta — mantener el texto original disponible junto a cualquier traducción.
• Prestar atención a los desajustes de tokenizador entre el modelo de embeddings y el de reranking. Mezclar modelos entrenados con tokenizadores distintos puede degradar el rendimiento multilingüe en silencio, de una forma fácil de pasar por alto si solo se prueba en inglés.

Uniendo todo

En el momento de indexar, los documentos se etiquetan por idioma, se chunkean en consecuencia, se embeben con un modelo multilingüe y se guardan con su idioma como metadata:

En el momento de la consulta, la consulta se embebe tal cual — sin traducirla primero — y se compara de forma cross-lingual contra el mismo vector store, combinada con búsqueda híbrida por idioma, se reordena con reranking, y recién ahí se le entrega al LLM para que responda en el idioma en el que se hizo la consulta:

Ninguna de estas técnicas es exótica por sí sola. La diferencia entre un sistema RAG multi-idioma que funciona y uno que rinde mal en silencio para la mitad de sus usuarios generalmente se reduce a si el idioma se trató como una señal de primera clase en todo el pipeline, o se agregó después como un parche.

Si estás corriendo RAG en producción hoy: ¿realmente sabés cómo se desempeña en cada idioma en el que tus usuarios hacen consultas, o solo lo sabés para el idioma en el que lo probaste?