RAG que funciona de verdad: patrones de 12 sistemas en producción

Fragmentación, reordenación, búsqueda híbrida y evaluación: los patrones que permiten lanzar RAG fiable en producción una y otra vez.

Qué es RAG y dónde falla

La generación aumentada por recuperación (RAG) responde preguntas a partir de tus propios documentos. En lugar de depender de lo que un modelo de lenguaje memorizó, el sistema busca en tu contenido, añade al prompt los fragmentos más relevantes y pide al modelo que responda a partir de ellos, idealmente citándolos.

Cuando un asistente RAG da una respuesta errónea o vaga, el modelo rara vez es la causa. Normalmente el fragmento correcto nunca se recuperó, se partió por la mitad al trocear o quedó enterrado bajo texto menos relevante. Por eso, el trabajo que hace fiable un RAG es sobre todo ingeniería de búsqueda.

El flujo

Ingesta: recoger documentos de fuentes como un CMS, un centro de ayuda, PDF o tickets, con sus permisos.
Troceado: dividirlos en fragmentos que tengan sentido por sí solos.
Embeddings e índice: guardar vectores y palabras clave con metadatos.
Recuperación: buscar con la pregunta del usuario, filtrando por lo que ese usuario puede ver.
Re-ranking: reordenar los mejores resultados con un modelo más preciso.
Generación: responder solo a partir de los fragmentos recuperados y citarlos.
Evaluación: medir de forma continua la calidad de la recuperación y de las respuestas.

Un troceado que conserva el sentido

Los fragmentos de tamaño fijo que cortan tablas y encabezados son la causa más común de malas respuestas. Divide según la estructura del documento: secciones, encabezados, elementos de lista y filas de tabla. Unos cientos de tokens por fragmento con un pequeño solapamiento funcionan bien para la mayoría de los textos.

Guarda metadatos con cada fragmento: título del documento, encabezado de la sección, URL, fecha, producto o versión, idioma y permisos de acceso. Anteponer el título y el encabezado al texto del fragmento antes de calcular el embedding suele mejorar mucho la recuperación, porque un párrafo aislado rara vez dice de qué trata.

Búsqueda híbrida y re-ranking

La búsqueda vectorial entiende el significado pero falla con términos exactos: códigos de producto, mensajes de error, nombres y números. La búsqueda por palabras clave (BM25) es justo al revés. Ejecuta ambas y combina los resultados, por ejemplo con reciprocal rank fusion, y tendrás lo mejor de cada una.

Después, reordena. Recupera rápidamente entre 20 y 50 candidatos y deja que un re-ranker cross-encoder puntúe cada uno frente a la pregunta. Pasar al modelo solo los cinco a ocho mejores fragmentos reduce coste, latencia y confusión.

Permisos y actualización

Aplica los permisos en la recuperación con filtros de metadatos, nunca pidiendo al modelo que oculte cosas. Si un usuario no debe ver un documento, ese documento no debe llegar al prompt.

Mantén el índice al día con actualizaciones incrementales: reindexa un documento cuando cambie y borra sus fragmentos cuando se elimine. Los fragmentos obsoletos producen respuestas seguras pero desactualizadas, las más difíciles de detectar.

Prompts para respuestas fundamentadas

Indica al modelo que responda solo con los fragmentos proporcionados, que los cite por su ID y que diga claramente cuando la respuesta no está en las fuentes. Trata el texto recuperado como datos, no como instrucciones: los documentos pueden contener texto que intente dirigir al modelo, así que el prompt del sistema debe indicar que se ignoren las instrucciones que aparezcan en las fuentes.

La evaluación es el producto

Antes del lanzamiento, reúne entre 50 y 200 preguntas reales con los documentos que deberían responderlas. Mide la recuperación (¿estaba el documento correcto entre los primeros resultados?) por separado de la calidad de la respuesta (¿era correcta, completa y respaldada por las fuentes?). La evaluación automática con un modelo ayuda a escala, pero revísala a mano de vez en cuando.

Ejecuta este conjunto en cada cambio de troceado, embeddings, prompts o modelos. Sin él, cada mejora es una suposición.

Un stack práctico

Para la mayoría de equipos empezamos simple: PostgreSQL con pgvector (u OpenSearch cuando hace falta una búsqueda por palabras clave potente), un modelo de embeddings y un re-ranker de un proveedor importante, la ingesta en colas en segundo plano y una pequeña pantalla de administración que muestra qué fuentes usó cada respuesta. Las bases de datos vectoriales dedicadas como Qdrant o Weaviate tienen sentido a mayor escala. La arquitectura importa menos que el troceado, los filtros y la evaluación que la rodean.