Cuando un sistema RAG da una respuesta errónea, el modelo de lenguaje suele llevarse la culpa. Según mi experiencia, la mayoría de los fallos ocurren antes: el fragmento correcto nunca se recuperó porque se dividió en el sitio equivocado, se vectorizó con un modelo que maneja mal tu idioma o quedó por debajo de un fragmento que solo sonaba parecido. Esta guía se centra en esa capa de recuperación —embeddings y chunking— y en las decisiones prácticas que más mueven la calidad de las respuestas.

Los embeddings en un párrafo

Un modelo de embeddings convierte un texto en un vector de modo que los textos con significado parecido quedan cerca. Los modelos de embeddings actuales son codificadores transformer entrenados con objetivos contrastivos sobre enormes conjuntos de pares de textos relacionados: preguntas y respuestas, títulos y cuerpos, traducciones (Reimers y Gurevych, Sentence-BERT). En el momento de la consulta, vectorizas la pregunta del usuario y buscas los vectores de fragmentos más cercanos en una base de datos vectorial.

En la práctica importan dos consecuencias:

  1. La noción de "parecido" del modelo viene de sus datos de entrenamiento. El lenguaje de un dominio concreto (legal, médico, contable) y los idiomas menos representados pueden tratarse peor que el inglés general.
  2. Las preguntas y las respuestas no se formulan igual. Los buenos modelos de recuperación están entrenados para búsqueda asimétrica (consulta corta → fragmento largo), y muchos esperan un prefijo como query: y passage:; lee la ficha del modelo.

Elegir un modelo de embeddings

El benchmark MTEB compara modelos de embeddings en muchas tareas e idiomas. La conclusión clave del artículo original sigue vigente: ningún modelo domina en todas las tareas (Muennighoff et al., 2022). Usa MTEB para hacer una lista corta y decide con tus propios datos.

Criterios:

Criterio Por qué importa
Puntuaciones de recuperación en tus idiomas Los datos de empresa mezclan con frecuencia español, inglés y otros idiomas
Longitud máxima de entrada Determina el tamaño máximo del fragmento (512 frente a 8.192 tokens)
Dimensiones y soporte Matryoshka Memoria y velocidad; los vectores truncables ahorran almacenamiento (Kusupati et al., 2022)
Alojamiento API (OpenAI, Cohere, Voyage, Google) frente a pesos abiertos que puedes alojar tú
Coste y rendimiento Volver a vectorizar un corpus grande ocurre más a menudo de lo que esperas
Licencia Las licencias de los modelos de pesos abiertos varían

Entre los modelos multilingües abiertos que merece la pena probar están BGE-M3, que admite recuperación densa, dispersa y multivector en un solo modelo (Chen et al., 2024), y la familia multilingüe E5 (Wang et al., 2024). Las APIs comerciales de los grandes proveedores también manejan bien el español. Alojar el modelo tú mismo importa cuando los documentos no pueden salir de tu infraestructura; consulta LLM self-hosted y privacidad en aplicaciones LLM.

Evalúa con tus propios datos: lleva un día

Construye un pequeño conjunto de evaluación de recuperación:

  1. Recoge de 100 a 200 preguntas reales (de tickets de soporte, logs de búsqueda, empleados).
  2. Para cada una, marca el fragmento o fragmentos que contienen la respuesta.
  3. Vectoriza tu corpus con 2–4 modelos candidatos.
  4. Mide el recall@k (¿está el fragmento correcto entre los 5/10/20 primeros?) y el MRR (¿en qué posición aparece?).
def recall_at_k(results: dict[str, list[str]], gold: dict[str, set[str]], k: int) -> float:
    hits = sum(1 for q, ids in results.items() if gold[q] & set(ids[:k]))
    return hits / len(results)

for model in ["bge-m3", "multilingual-e5-large", "api-model-x"]:
    results = run_retrieval(model, questions, top_k=20)
    print(model, {k: round(recall_at_k(results, gold, k), 3) for k in (5, 10, 20)})

Las diferencias de 10–20 puntos de recall@10 entre modelos con datos de empresa reales y no ingleses son habituales, muchas más de lo que sugieren las medias de los rankings. Este conjunto pasa también a formar parte de tus evals de LLM de extremo a extremo.

Chunking: donde se gana o se pierde la mayor parte de la calidad

El chunking decide qué es una "unidad de recuperación". Si los fragmentos son demasiado grandes, mezclan temas, diluyen el embedding y desperdician contexto. Si son demasiado pequeños, pierden el contexto necesario para entenderlos ("La comisión es del 2%": ¿qué comisión?).

Estrategias

  • Tamaño fijo con solapamiento. Divide cada N tokens con un 10–20% de solapamiento. Una base sencilla que ignora la estructura.
  • Recursivo / consciente de la estructura. Divide por encabezados, después por párrafos y después por frases, hasta que los fragmentos quepan en el límite. La mejor opción por defecto para la mayoría de los documentos de empresa.
  • Específico por tipo de documento. Contratos por cláusula, FAQ por pregunta, código por función, tablas por grupos de filas repitiendo los encabezados, correos por mensaje.
  • Chunking semántico. Divide donde cae la similitud de embeddings entre frases contiguas. A veces ayuda en prosa sin estructura; más cómputo y ganancias irregulares.

Los tamaños iniciales típicos son de 200 a 800 tokens. Mide; no supongas.

Conserva el contexto en cada fragmento

Un fragmento debería entenderse leído por sí solo. Técnicas baratas:

  • Antepón el título del documento y la ruta de secciones: Política de reembolsos > Planes anuales > Reembolsos parciales.
  • Guarda metadatos (tipo de documento, fecha, producto, idioma, nivel de acceso) para filtrar.
  • Mantén las tablas intactas o conviértelas en frases "columna: valor" por fila.

Contextual retrieval

La técnica de contextual retrieval de Anthropic usa un LLM para escribir un contexto breve y específico de cada fragmento ("Este fragmento pertenece al informe del segundo trimestre de 2026 de ACME y trata los ingresos del segmento UE...") que se antepone antes de vectorizar e indexar con BM25. En sus experimentos, los embeddings contextuales más BM25 contextual redujeron las recuperaciones fallidas un 49%, y un 67% combinados con reranking. Con prompt caching, el coste de generar estos contextos para todo un corpus es moderado.

Late chunking y enfoques multivector

Alternativas a generar contexto por fragmento: el late chunking vectoriza el documento completo con un modelo de contexto largo y agrupa los embeddings de tokens por fragmento, de modo que cada vector "conoce" su entorno (Günther et al., 2024). Los modelos multivector como ColBERT conservan un vector por token y comparan a nivel fino, con un mayor coste de almacenamiento (Khattab y Zaharia, 2020).

Búsqueda híbrida y reranking

Los embeddings captan el significado, pero son más débiles con identificadores exactos: números de artículo, SKUs, códigos de error, nombres. Combínalos con búsqueda por palabras clave (BM25) y fusiona las clasificaciones. Después aplica un reranker cross-encoder a los 30–100 primeros candidatos: los rerankers leen juntos la consulta y el fragmento y puntúan la relevancia con mucha más precisión que la similitud vectorial, con un coste mayor por par. Híbrido + rerank es la configuración que despliego por defecto; los detalles de implementación están en RAG para empresas y, para PostgreSQL, en comparativa de bases de datos vectoriales.

Consideraciones para español y textos multilingües

  • Idiomas mezclados. Los datos de empresa mezclan a menudo español con inglés, y en algunas regiones con catalán, gallego, euskera o portugués, a veces dentro de un mismo documento. Usa modelos multilingües y prueba consultas entre idiomas (pregunta en español, respuesta en un documento en inglés).
  • Morfología. La flexión del español afecta a la búsqueda por palabras clave ingenua: "contrato", "contratos", "contractual", "contratamos". Usa un analizador adecuado para español o apóyate más en el componente denso; prueba BM25 con y sin stemming.
  • Tildes y variantes. Normaliza las tildes y la "ñ" de forma coherente en la indexación y en la consulta (los usuarios a menudo escriben sin tildes), y ten en cuenta las variantes regionales de vocabulario: "ordenador" frente a "computadora", "móvil" frente a "celular".
  • Documentos escaneados. La calidad del OCR varía, sobre todo con tablas y caracteres acentuados; un OCR deficiente destruye la recuperación. Consulta procesamiento de documentos con LLM.

Prácticas operativas

  • Versiona los embeddings. Guarda el nombre y la versión del modelo con cada vector. Mezclar vectores de modelos distintos en un mismo índice rompe la búsqueda en silencio.
  • Conserva el texto en bruto. Volverás a vectorizar cuando cambies de modelo; planifícalo como una migración en segundo plano con un periodo de doble lectura.
  • Actualizaciones incrementales. Vuelve a vectorizar solo los documentos modificados; detecta los cambios por hash del contenido.
  • Respeta el control de acceso en la recuperación. Filtra por los permisos del usuario en la consulta, nunca solo en el prompt; consulta seguridad de agentes de IA.
  • Monitoriza la recuperación en producción. Registra los IDs y las puntuaciones de los fragmentos recuperados por respuesta para poder rastrear las malas respuestas hasta la recuperación; consulta observabilidad de LLM.

Una configuración de partida

Para una base de conocimiento de empresa típica en español:

  1. Chunking consciente de la estructura, de 300 a 600 tokens, con el título y la ruta de secciones antepuestos.
  2. Un modelo de embeddings multilingüe elegido por recall@10 sobre 150 preguntas reales.
  3. Búsqueda híbrida: densa + BM25, fusionadas con RRF, 50 primeros candidatos.
  4. Reranking cross-encoder hasta quedarte con los 5–8 mejores fragmentos.
  5. Contextual retrieval si el recall@10 sigue por debajo del 85–90% aproximadamente.

Después itera con tu conjunto de evaluación, cambiando una cosa cada vez.

Preguntas frecuentes

¿Más dimensiones de embedding, mejores resultados? No necesariamente. La calidad del modelo importa más que el número de dimensiones; los modelos Matryoshka suelen conservar la mayor parte de la calidad con la mitad de dimensiones.

¿Deberíamos hacer fine-tuning de un modelo de embeddings? Plantéatelo después de haber probado la búsqueda híbrida, el reranking y un mejor chunking, y solo si tienes miles de pares consulta-fragmento etiquetados. Consulta fine-tuning vs RAG vs prompting.

¿Podemos usar modelos de contexto largo y saltarnos la recuperación? Con corpus pequeños, a veces. Para cualquier cosa mayor o que cambie con frecuencia, la recuperación sigue siendo más barata, más rápida y más fácil de controlar; consulta context engineering.

¿Con qué frecuencia deberíamos volver a vectorizar? Cuando cambia el contenido (de forma incremental) y cuando cambias de modelo (por completo). Por lo demás, los embeddings no caducan.

Fuentes

  1. Muennighoff et al. (2022). MTEB: Massive Text Embedding Benchmark; MTEB leaderboard.
  2. Reimers, N., Gurevych, I. (2019). Sentence-BERT.
  3. Chen et al. (2024). BGE M3-Embedding; Wang et al. (2024). Multilingual E5 Text Embeddings.
  4. Kusupati et al. (2022). Matryoshka Representation Learning.
  5. Anthropic (2024). Introducing Contextual Retrieval.
  6. Günther et al. (2024). Late Chunking; Khattab, O., Zaharia, M. (2020). ColBERT.