RAG desde cero: del documento a una respuesta verificada
Un pipeline RAG de producción desde ingestion, normalización, chunking y embeddings hasta retrieval, reranking, generación grounded, citas y evaluación.
Contenido del artículo
Qué resuelve RAG
Retrieval-Augmented Generation añade fragmentos de conocimiento externo a una consulta. Esto permite trabajar con documentos privados, datos recientes y fuentes que no estaban presentes durante el entrenamiento del modelo.
RAG no actualiza los parámetros del LLM. El conocimiento permanece en un almacén externo, por lo que puede versionarse, eliminarse, limitarse por permisos de acceso y citarse.
Ingestion y normalización
PDF, HTML, correos y tablas contienen ruido: menús, duplicados, encabezados y pies, caracteres ocultos y orden de lectura incorrecto. Si la ingestion pierde estructura, retrieval no podrá reconstruirla después.
Cada fragmento debe conservar document_id, versión, fuente, fecha, idioma, permisos de acceso y posición en el original. Los metadatos son necesarios para filtrar, citar y eliminar registros obsoletos.
Chunking y representación
Los chunks demasiado pequeños pierden contexto; los demasiado grandes mezclan temas y consumen espacio valioso de la ventana de contexto. Conviene dividir por límites semánticos como títulos, párrafos, cláusulas de políticas o funciones de código.
Tras la normalización, los chunks se convierten en embeddings. La búsqueda vectorial encuentra similitud semántica, pero para nombres, códigos y términos exactos conviene combinarla con keyword search y filtros de metadatos.
Retrieval, reranking y grounding
El retriever inicial devuelve candidatos con rapidez, mientras que un reranker determina con mayor precisión qué fragmentos responden realmente a la consulta. El modelo debe recibir un conjunto compacto de las evidencias más fuertes.
El modelo debe responder basándose en las fuentes entregadas e indicar explícitamente cuando faltan evidencias. Las citas se construyen con valores source_id reales y el sistema verifica que cada identificador estuviera presente en el contexto.
Evaluación de RAG
Retrieval y generación deben evaluarse por separado. Si no se encontró el documento correcto, el problema no es el modelo. Si se encontró la evidencia pero la respuesta añade afirmaciones sin soporte, el problema está en grounding o en la política de generación.
Un conjunto de evaluación debe contener preguntas reales, fuentes esperadas, respuestas correctas y casos negativos en los que el sistema deba abstenerse. Las métricas incluyen retrieval recall, precision, groundedness y precisión de citas.
Arquitectura mínima de RAG en producción
Un RAG básico consta de ingestion, normalización, chunking, embeddings, índice, retrieval y generación de respuestas. En producción se añaden ACL, versionado de documentos, filtros de metadatos, reranking, registro de consultas y un mecanismo para eliminar fragmentos obsoletos. Sin estas capas, un prototipo se convierte rápidamente en una colección de vectores sin control.
Cada chunk debe conservar provenance: documento, versión, página o sección, momento de indexación y permisos de acceso. Así la respuesta puede explicarse, verificarse y retirarse cuando cambia la fuente. Un vector sin procedencia es casi inútil para un sistema fiable.
Evaluar retrieval por separado de la generación
Cuando una respuesta es incorrecta, primero hay que determinar si el modelo recibió las evidencias necesarias. Evalúa retrieval con recall, precision, hit rate, MRR o nDCG sobre consultas con fragmentos relevantes conocidos. Evalúa la generación por separado: uso de las fuentes, ausencia de contradicciones y corrección de las citas.
Esta separación reduce el tiempo de diagnóstico. Si un chunk relevante no se recuperó, cambiar el prompt no ayudará; mejora chunking, embeddings, query rewriting o reranking. Si la evidencia está disponible pero se ignora, revisa el ensamblado del contexto, las instrucciones o el modelo.
Causas habituales de fallo en RAG
Los problemas más comunes son chunks demasiado grandes o pequeños, falta de filtros de metadatos, duplicados, mezcla de versiones, consultas débiles y demasiados fragmentos recuperados. Más contexto no garantiza una mejor respuesta: los pasajes irrelevantes reducen la señal y crean contradicciones.
Empieza con un pequeño eval dataset, mide retrieval antes de conectar el LLM y registra cada etapa. Tras el lanzamiento, recopila consultas fallidas, clasifica sus causas y actualiza el índice o el pipeline basándote en hechos, no en unas pocas demos.
Aceptación end-to-end para el primer RAG
Trata el primer RAG como un pipeline medible: ingestion, parsing, chunking, embedding, indexing, retrieval, reranking, generación y validación de citas. Cada etapa necesita identificadores y traces propios para localizar dónde se perdió el documento correcto. El evaluation dataset debe contener consultas reales, fuentes esperadas y criterios de completitud. Si la evidencia es insuficiente, la respuesta debe abstenerse o pedir aclaraciones en lugar de compensar un retrieval débil con una generación segura de sí misma.
La base de producción incluye filtros de acceso durante retrieval, un índice versionado, reindexado idempotente y rollback. Las métricas deben cubrir recall@k, precisión de citas, groundedness, latencia p95 y coste por respuesta satisfactoria. Después de cualquier cambio en embeddings, chunking o prompts, vuelve a ejecutar el mismo conjunto de regresión.
- Separa los errores de retrieval de los errores de respuesta.
- Conserva los source IDs en la respuesta final.
- Usa un proceso de reindexado controlado.
Ejemplos prácticos
Paquete de evidencia
El retriever devuelve source_id, document_version, fragmento, score y política de acceso. La respuesta solo puede citar fragmentos incluidos en ese paquete.
FAQ
¿Todo sistema RAG necesita una base de datos vectorial?
No. Para un corpus pequeño pueden bastar PostgreSQL, un motor de búsqueda o incluso keyword search controlado.
¿Por qué RAG inventa citas?
Ocurre cuando el modelo genera referencias como texto libre. Los identificadores de fuente deben entregarse de forma estructurada y validarse después de la generación.
¿Cuándo debe actualizarse el índice?
Ante eventos de cambio en las fuentes o según un SLA definido. Cada versión del documento debe poder rastrearse.