Arquitectura de Sistemas RAG: Componentes y Flujo de Datos

Concepto clave

La arquitectura de Retrieval Augmented Generation (RAG) combina la recuperación de información con la generación de texto, creando sistemas que pueden acceder a bases de conocimiento externas para producir respuestas precisas y contextualizadas. Imagina un bibliotecario experto que, en lugar de memorizar todos los libros, tiene acceso instantáneo a un catálogo perfectamente organizado y sabe exactamente qué páginas consultar cuando le haces una pregunta.

En el corazón de esta arquitectura están las bases de datos vectoriales, que almacenan representaciones numéricas (vectores) de documentos, permitiendo búsquedas semánticas en lugar de coincidencias exactas de palabras. Esto es crucial porque los humanos no siempre formulamos preguntas usando las mismas palabras que aparecen en los documentos relevantes.

"RAG transforma modelos de lenguaje de meros parrots (repetición de patrones entrenados) en research assistants (asistentes que consultan fuentes verificables)."

Cómo funciona en la práctica

El flujo de datos en un sistema RAG sigue un proceso de cuatro etapas bien definido:

1. Ingesta y procesamiento: Los documentos de origen (PDFs, páginas web, bases de datos) se dividen en fragmentos manejables (chunks) y se convierten en vectores usando modelos de embeddings como Sentence-BERT o OpenAI embeddings.
2. Almacenamiento vectorial: Estos vectores se indexan en una base de datos vectorial (Chroma, Pinecone o pgvector) junto con el texto original y metadatos relevantes.
3. Recuperación semántica: Cuando un usuario hace una consulta, esta se convierte en un vector y se buscan los fragmentos más similares usando métricas como similitud coseno o distancia euclidiana.
4. Generación aumentada: Los fragmentos recuperados se inyectan como contexto en el prompt del modelo de lenguaje, que genera una respuesta fundamentada en esa información específica.

Ejemplo con datos concretos

Supongamos que tenemos documentos sobre regulaciones financieras:

Consulta del usuario: "¿Cuándo debo reportar una transacción grande?" → Vector: [0.24, -0.43, 0.66, ...] → Recupera ambos fragmentos por alta similitud semántica.

Caso de estudio

Sistema de soporte técnico para una empresa de software:

Una empresa con 50,000 documentos de conocimiento (manuales, tickets resueltos, FAQs) implementó RAG usando Chroma como base vectorial. El proceso:

1. Documentación técnica se dividió en chunks de 500 tokens con superposición del 10% para mantener contexto.
2. Se usó el modelo "all-MiniLM-L6-v2" para generar embeddings de 384 dimensiones.
3. Chroma almacenó los vectores con metadatos: {tipo_doc: "manual", producto: "ERPv2", versión: "3.1"}.
4. Cuando un agente escribe "El cliente no puede generar reporte fiscal", el sistema recupera 3 chunks relevantes sobre permisos de usuario y configuración de impuestos.
5. GPT-4 genera una respuesta específica citando los manuales exactos, reduciendo el tiempo de resolución de 15 a 2 minutos.

Métrica clave: Precisión de recuperación mejoró del 45% (búsqueda por palabras clave) al 89% (búsqueda vectorial).

Errores comunes

• Chunks mal dimensionados: Fragmentos demasiado grandes pierden especificidad; demasiado pequeños pierden contexto. Solución: Experimentar con tamaños entre 200-1000 tokens y ajustar según el dominio.
• Embeddings inapropiados: Usar un modelo genérico para dominio especializado (ej: legal o médico). Solución: Fine-tune embeddings en tu dataset o usar modelos especializados como ClinicalBERT para medicina.
• Falta de metadatos: Almacenar solo vectores y texto, sin información sobre fuente, fecha o confiabilidad. Solución: Incluir metadatos estructurados que permitan filtrado durante la recuperación.
• Prompt engineering deficiente: Simplemente concatenar chunks recuperados sin estructura clara. Solución: Diseñar templates que expliciten el rol del contexto: "Basándote EXCLUSIVAMENTE en los siguientes documentos..."
• Ignorar el costo de inferencia: Recuperar demasiados chunks (ej: 10) cuando 3-5 son suficientes, aumentando costos de LLM innecesariamente. Solución: Implementar reranking o ajustar umbrales de similitud.

Checklist de dominio

1. Puedo explicar la diferencia entre búsqueda por palabras clave y búsqueda semántica vectorial
2. Sé cómo elegir tamaño de chunk y estrategia de overlapping para mi tipo de documentos
3. Puedo configurar una base vectorial (Chroma/Pinecone/pgvector) con índices apropiados para mi volumen de datos
4. Entiendo cómo los metadatos mejoran la recuperación mediante filtrado híbrido
5. Sé evaluar la calidad de recuperación usando métricas como MRR@k o Recall@k
6. Puedo diseñar un pipeline completo de ingesta que maneje actualizaciones incrementales
7. Reconozco cuándo un problema requiere RAG vs. fine-tuning del modelo base

Diseña el pipeline de ingesta para documentos técnicos

Como ingeniero de datos en una empresa fintech, debes diseñar el pipeline de ingesta inicial para 10,000 páginas de documentación regulatoria. Sigue estos pasos:

1. Análisis de documentos: Examina una muestra de 50 documentos e identifica:
   • Estructuras comunes (secciones, tablas, referencias cruzadas)
   • Longitud promedio de párrafos significativos
   • Metadatos disponibles (fecha, organismo emisor, jurisdicción)
2. Estrategia de chunking: Propón dos estrategias diferentes:
   • Por secciones naturales (identificadas por headers HTML o marcadores PDF)
   • Por tokens fijos con overlapping
   Justifica cuál elegirías y con qué parámetros.
3. Selección de embeddings: Investiga 3 modelos de embeddings disponibles (ej: OpenAI text-embedding-3-small, Cohere embed, modelos open-source) y crea una tabla comparativa con:

   Modelo	Dimensión	Costo/1M tokens	Ventajas para texto regulatorio
   Ejemplo1	1536	$0.13	Alto rendimiento en inglés

4. Esquema de metadatos: Diseña un esquema JSON para los metadatos que acompañarán cada chunk vectorizado. Incluye al menos 5 campos con tipos de datos.
5. Plan de pruebas: Describe cómo validarás que la recuperación funciona correctamente con 3 consultas de ejemplo realistas.

• Considera que las regulaciones frecuentemente citan artículos específicos por número; preserva estas referencias en los chunks.
• El overlapping entre chunks puede ayudar cuando las respuestas requieren contexto de secciones adyacentes.
• Los metadatos de fecha son críticos en dominios regulatorios donde las leyes cambian frecuentemente.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.