Embeddings en español: qué funciona de verdad

Cuarta entrega del bloque de modelos, y la única de toda la serie dedicada a un idioma concreto. Casi toda la literatura sobre RAG está escrita para el inglés y se traslada al español dando por hecho que las conclusiones se conservan. No siempre se conservan, y el sitio donde más se pierde es la recuperación.

Recordemos el mecanismo, porque la explicación depende de él. Un modelo de embeddings coloca cada texto en un espacio de cientos o miles de dimensiones, de forma que los textos con significado parecido queden cerca. La búsqueda consiste en colocar la pregunta en ese mismo espacio y devolver lo que tenga alrededor. Todo depende, por tanto, de que la geometría del espacio refleje bien las relaciones de significado en el idioma de tus textos.

Qué significa que un modelo «entiende» español

Conviene distinguir tres cosas que se confunden con frecuencia.

Un modelo puede haber visto español durante el entrenamiento sin que el español fuera una prioridad: es lo que ocurre con casi cualquier modelo entrenado sobre texto web, donde el español aparece de forma incidental en una proporción pequeña. El modelo produce vectores razonables para texto español porque ha visto suficiente, no porque se haya optimizado para ello.

Un modelo multilingüe es otra cosa: se entrena deliberadamente con un reparto de idiomas y con objetivos que premian que un texto y su traducción queden cerca en el espacio. Esa propiedad —el alineamiento entre idiomas— no aparece sola por haber visto varios idiomas; hay que entrenarla.

Y un modelo entrenado en español desde el principio, con corpus mayoritariamente hispano, es una tercera categoría, mucho menos poblada y con menos opciones actuales de calidad competitiva que las dos anteriores.

En la práctica, para un RAG en español la elección real está entre los dos primeros grupos, y la conclusión operativa es que las variantes multilingües explícitas de las familias que vimos en las dos entregas anteriores —los modelos multilingües de BGE y E5, las familias de Cohere y Jina, las variantes correspondientes de Voyage— son el punto de partida sensato, y los modelos entrenados sólo en inglés no deberían estar siquiera en la lista de candidatos.

Por qué un modelo inglés degrada la recuperación en español

La degradación no es un fallo visible sino una pérdida de resolución, y viene de tres sitios.

La tokenización. Un tokenizador entrenado sobre texto mayoritariamente inglés parte las palabras españolas en más piezas: la morfología rica del español —conjugaciones, diminutivos, concordancias, enclíticos— produce formas que el vocabulario del modelo no tiene como unidad. «Establecimiento» puede convertirse en cuatro o cinco fragmentos que el modelo tiene que recomponer. Eso consume ventana de contexto y, sobre todo, obliga al modelo a trabajar con unidades que representan peor el significado.

La geometría del espacio. Con menos español visto, las distinciones finas se aplanan. El modelo distingue bien «contrato» de «factura», que son conceptos muy separados, y distingue mucho peor «prórroga tácita» de «renovación automática» o «baja voluntaria» de «excedencia», que es exactamente el tipo de matiz del que dependen las preguntas difíciles. El resultado es un sistema que acierta en las consultas fáciles y falla en las que justificaban montarlo.

Los acentos y la variación ortográfica. Un modelo poco expuesto al español trata «articulo», «artículo» y «artículó» con menos consistencia de la deseable, y los usuarios reales escriben sin tildes con mucha frecuencia.

El efecto conjunto es un recall más bajo con la misma configuración. Y como el sistema sigue devolviendo diez fragmentos plausibles para cada pregunta, no hay ninguna señal de alarma: hay que medirlo para verlo.

El corpus mezclado: el caso que casi nadie mide

Es una situación extraordinariamente común en empresas españolas: la documentación técnica está en inglés —manuales de proveedor, documentación de producto, artículos internos escritos por equipos internacionales— y los usuarios preguntan en español. O al revés: procedimientos internos en español consultados por una plantilla que pregunta en varios idiomas.

Aquí no basta con que el modelo maneje los dos idiomas por separado. Hace falta la propiedad de alineamiento entre idiomas: que la pregunta «¿cómo se reinicia el servicio de facturación?» quede cerca del fragmento inglés que explica exactamente eso. Un modelo puede ser bueno en español, bueno en inglés y mediocre alineando ambos, y ese caso concreto es el que rompe los corpus mezclados.

Hay cuatro estrategias, en orden creciente de coste.

• Modelo multilingüe con alineamiento probado. La primera opción y, si funciona, la única necesaria. Pero hay que probarla con pares reales de tu corpus, no darla por buena.
• Traducir la consulta. Traducir automáticamente la pregunta al idioma del corpus antes de buscar. Barato, eficaz y con dos inconvenientes: añade una llamada al modelo en el camino crítico, y traduce mal precisamente la jerga interna que más importa.
• Indexar dos veces. Guardar el fragmento en su idioma original y una traducción, ambos indexados. Duplica el almacenamiento y el coste de indexación, y a cambio permite buscar en cualquiera de los dos idiomas sin depender del alineamiento del modelo. Es la opción más robusta cuando el corpus es estable y no demasiado grande.
• Índices separados por idioma con fusión. Buscar en paralelo y fusionar los rankings con la fusión recíproca de rangos que vimos en la entrega 15. Da control fino y complica la operativa.

Sea cual sea la elección, hay una medida barata que siempre conviene: guardar el idioma de cada fragmento como metadato en la ingesta. Permite filtrar, diagnosticar y cambiar de estrategia después sin reindexar.

Jerga y variantes regionales

El español no es un idioma uniforme, y un modelo entrenado sobre texto web hispano ha visto sobre todo español latinoamericano, que es mayoritario en volumen. Para un corpus corporativo español eso importa en dos frentes.

El primero es el léxico administrativo y jurídico: «autónomo», «nómina», «finiquito», «IVA», «excedencia», «convenio colectivo», «RETA», «modelo 303». Son términos con significado preciso en un contexto normativo concreto que un modelo generalista trata como palabras corrientes. La búsqueda híbrida de la entrega 15 es aquí la solución de primera línea: BM25 recupera «modelo 303» de forma exacta mientras el vector aporta la parte semántica.

El segundo es la jerga interna de cada organización: nombres de sistemas, siglas de departamento, apodos de procesos. Ningún modelo los conoce, ninguno los conocerá, y no hay más remedio que darle contexto al fragmento en la indexación o resolver la sigla en la consulta con un glosario propio. Es trabajo manual y aburrido, y es de lo que más mejora un sistema real.

Montar una evaluación propia en español

Los rankings públicos cubren el español de forma desigual: hay tareas en español dentro de las suites multilingües, pero suelen ser traducciones de conjuntos ingleses o corpus generalistas que se parecen poco a la documentación corporativa. Confiar en ellos para decidir es aceptar que otro elija por ti con datos que no son los tuyos.

Montar la evaluación propia es más barato de lo que parece. El procedimiento mínimo cabe en una tarde.

1. Reúne entre cincuenta y cien preguntas reales. De tickets de soporte, del buscador interno, de una lista pedida a las personas que van a usar el sistema. Reales, con sus faltas de ortografía y sus tildes ausentes, no reformuladas por ti.
2. Marca a mano el fragmento correcto. Para cada pregunta, cuál es el fragmento —o los fragmentos— que contienen la respuesta. Es la parte laboriosa y es la que da valor a todo lo demás.
3. Incluye deliberadamente los casos difíciles. Preguntas con sinónimos que no aparecen en el documento, preguntas con jerga interna, preguntas cuya respuesta está en un documento en inglés si tu corpus es mixto, y preguntas que no tienen respuesta en el corpus, para comprobar que el sistema no inventa.
4. Mide recall@k con cada modelo candidato. Es decir: en qué proporción de preguntas el fragmento correcto aparece entre los k primeros resultados. Con tres o cuatro candidatos y este conjunto, la comparación tarda minutos y es infinitamente más informativa que cualquier tabla pública.

Ese conjunto es el germen del golden dataset del que hablaremos en la entrega 40, y sirve para mucho más que elegir modelo: para validar cambios de troceado, para detectar regresiones y para decidir si el reranking compensa.

Límites

Dos avisos. El primero: elegir bien el modelo para español evita una degradación estructural, pero no compensa un troceado malo ni unos metadatos inexistentes. El orden de las mejoras sigue siendo el mismo que en el resto de la serie, y el modelo va después.

El segundo: cincuenta preguntas no son una evaluación estadísticamente robusta. Sirven para distinguir diferencias grandes, que son las que importan al elegir entre candidatos, y no para afinar entre dos modelos que van parejos. Cuando dos finalistas empatan en tu conjunto, decide por los otros criterios —coste, contexto, portabilidad— y no por un punto de diferencia que probablemente sea ruido.

Qué viene ahora

Cerrado el asunto de los embeddings, la siguiente entrega cambia de pieza y se ocupa del modelo generador: qué criterios importan de verdad al elegir quién redacta la respuesta, por qué la capacidad más relevante para un RAG apenas aparece en los rankings, cómo se prueba cada criterio y por qué en un sistema bien construido un modelo pequeño suele bastar.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.