Guía Teórica Completa: RAG (Retrieval-Augmented Generation)
1. Fundamentos de RAG
1.1 ¿Qué es RAG y Por Qué Existe?
El Problema Fundamental de los LLMs:
Los LLMs tienen tres limitaciones críticas que RAG resuelve.
La primera es el conocimiento estático. Un modelo entrenado en 2024 no sabe qué pasó en 2025. Su conocimiento está «congelado» en el momento del entrenamiento. Para un banco, esto significa que el modelo no conoce las nuevas tasas de interés, productos lanzados recientemente, o cambios regulatorios.
La segunda son las alucinaciones. Cuando un LLM no sabe algo, puede inventar información que suena plausible pero es falsa. En contextos empresariales como finanzas, legal o salud, esto es inaceptable.
La tercera es la falta de conocimiento privado. El modelo no conoce los documentos internos de tu empresa: políticas, procedimientos, bases de conocimiento, información de clientes.
La Solución RAG:
RAG combina la capacidad de razonamiento y generación de los LLMs con la precisión de la búsqueda en documentos específicos. En lugar de confiar solo en lo que el modelo «recuerda», le proporcionamos información relevante en el momento de la consulta.
La analogía más clara es pensar en un estudiante respondiendo un examen. Sin RAG es como un examen a libro cerrado donde el estudiante responde de memoria, puede confundir detalles, y si no sabe, inventa. Con RAG es como un examen a libro abierto donde el estudiante puede consultar sus apuntes, las respuestas están fundamentadas en fuentes, y si no encuentra la información, puede decirlo.
1.2 Arquitectura General de RAG
Un sistema RAG tiene tres fases principales que operan en dos momentos diferentes.
Fase Offline (preparación previa):
La Indexación ocurre antes de cualquier consulta. Procesas tus documentos, los divides en chunks, generas embeddings, y los almacenas en una base de datos vectorial. Este proceso puede tomar horas o días dependiendo del volumen, pero solo se hace una vez (con actualizaciones periódicas).
Fase Online (en tiempo real):
El Retrieval sucede cuando llega una consulta del usuario. La consulta se convierte en embedding, se buscan los chunks más similares en la base vectorial, y se recuperan los K documentos más relevantes. Esto toma milisegundos.
La Generation ocurre después del retrieval. Los documentos recuperados se insertan en el prompt junto con la consulta original, el LLM genera una respuesta basada en ese contexto, y opcionalmente se citan las fuentes.
El Flujo Completo:
Usuario: "¿Cuál es el proceso para solicitar un refinanciamiento?"
↓
[1. EMBEDDING]
Consulta → Vector [0.12, -0.34, 0.56, ...]
↓
[2. RETRIEVAL]
Buscar en BD vectorial → Top 5 chunks relevantes
↓
[3. AUGMENTATION]
Construir prompt: Sistema + Contexto + Consulta
↓
[4. GENERATION]
LLM genera respuesta basada en contexto
↓
Respuesta: "Según el Manual de Productos (v2024), el proceso de
refinanciamiento requiere: 1) Solicitud formal...
[Fuente: manual_productos.pdf, pág 45]"1.3 Componentes del Sistema
Documentos Fuente:
Son la base de conocimiento de tu sistema. Pueden ser PDFs de manuales y políticas, documentos Word de procedimientos, páginas web de tu intranet, bases de datos estructuradas, emails y tickets históricos, o transcripciones de llamadas.
Modelo de Embeddings:
Convierte texto en vectores numéricos que capturan significado semántico. Es el puente entre el lenguaje humano y la matemática de similitud.
Base de Datos Vectorial:
Almacena los embeddings y permite búsqueda eficiente de similitud. Ejemplos incluyen Pinecone, Weaviate, Chroma, Qdrant, y pgvector.
LLM Generador:
El modelo que produce la respuesta final. Puede ser propietario como GPT-4 o Claude, u open source como Mistral o LLaMA.
Orquestador:
El código que conecta todo: recibe consultas, coordina retrieval, construye prompts, llama al LLM, y formatea respuestas. Frameworks como LangChain, LlamaIndex, o Haystack facilitan esto.
2. Embeddings: El Corazón de RAG
2.1 ¿Qué son los Embeddings?
La Intuición:
Un embedding es una representación numérica de texto que captura su significado. Convierte palabras, oraciones, o documentos en vectores de números (típicamente 384 a 4096 dimensiones).
La magia está en que textos con significados similares tienen embeddings cercanos en el espacio vectorial, mientras que textos con significados diferentes están lejos.
Ejemplo Conceptual:
Imagina un espacio 3D simplificado donde cada punto es un concepto:
Los conceptos financieros están agrupados cerca, mientras que conceptos no relacionados están lejos. Cuando buscas «opciones para reestructurar mi deuda», el embedding estará cerca de «refinanciamiento» y «crédito», no cerca de «mascota».
2.2 Cómo Funcionan los Modelos de Embeddings
Arquitectura:
Los modelos de embeddings modernos son Transformers (similar a los LLMs) pero entrenados específicamente para crear representaciones semánticas. En lugar de predecir el siguiente token, están entrenados para que textos similares tengan embeddings cercanos.
El Proceso:
El texto de entrada pasa por el tokenizador que lo convierte en tokens. Luego pasa por el Transformer que procesa los tokens con attention. Finalmente hay un pooling que combina todos los tokens en un solo vector. El resultado es un vector de dimensión fija, por ejemplo [0.12, -0.34, 0.56, …, 0.78] con 768 dimensiones.
Métodos de Pooling:
El CLS pooling usa el token especial [CLS] como representación de toda la secuencia. El Mean pooling promedia los embeddings de todos los tokens, siendo generalmente el más efectivo. El Max pooling toma el máximo por dimensión.
2.3 Modelos de Embeddings Populares
Para Inglés:
El modelo text-embedding-3-small de OpenAI tiene 1536 dimensiones, es muy bueno y económico, y es ideal para producción con presupuesto.
El modelo text-embedding-3-large de OpenAI tiene 3072 dimensiones, es el mejor de OpenAI, y es ideal para máxima calidad sin restricción de costo.
Para Multilingüe/Español:
El modelo multilingual-e5-large tiene 1024 dimensiones y es el mejor open source multilingüe, excelente para español.
El modelo paraphrase-multilingual-MiniLM-L12-v2 tiene 384 dimensiones, es rápido y ligero, y es bueno para recursos limitados.
El modelo BGE-M3 tiene 1024 dimensiones, es muy reciente y potente, y soporta múltiples idiomas con alta calidad.
Consideraciones para Español:
Los modelos multilingües funcionan bien pero no óptimamente para español. Si tu caso de uso es 100% español, considera fine-tunear un modelo de embeddings con datos de tu dominio. La diferencia puede ser significativa en dominios especializados como finanzas o legal.
2.4 Similitud entre Embeddings
Métricas de Distancia:
La similitud coseno mide el ángulo entre vectores, ignorando magnitud. Va de -1 (opuestos) a 1 (idénticos). Es la más usada en RAG porque funciona bien con embeddings normalizados.
La distancia euclidiana mide la distancia «recta» entre puntos. Puede ser afectada por la magnitud de los vectores. Se usa menos en RAG pero es válida.
El producto punto es similar a coseno pero considera magnitud. Útil cuando la «importancia» del documento importa.
Ejemplo de Similitud Coseno:
Query: "¿Cómo solicitar un préstamo personal?"
Embedding query: [0.8, 0.2, 0.5]
Doc A: "Requisitos para crédito personal"
Embedding A: [0.75, 0.25, 0.55]
Similitud con query: 0.98 (muy alto)
Doc B: "Horarios de atención de agencias"
Embedding B: [0.1, 0.9, 0.3]
Similitud con query: 0.42 (bajo)
Doc C: "Política de vacaciones del personal"
Embedding C: [0.3, 0.4, 0.1]
Similitud con query: 0.51 (medio - ¡falso positivo por "personal"!)Este ejemplo muestra un problema común: la palabra «personal» aparece en contextos diferentes (préstamo personal vs. personal de la empresa). Embeddings de calidad minimizan esto, pero no lo eliminan completamente.
3. Bases de Datos Vectoriales
3.1 ¿Por Qué Necesitamos BDs Vectoriales?
El Problema de Escala:
Si tienes 1 millón de documentos y quieres encontrar los más similares a una consulta, una búsqueda «bruta» calcularía 1 millón de similitudes. Esto es O(n), demasiado lento para tiempo real.
Las bases de datos vectoriales usan estructuras de datos especiales que permiten búsqueda aproximada en tiempo O(log n) o mejor, sacrificando un poco de precisión por mucha velocidad.
3.2 Algoritmos de Indexación
HNSW (Hierarchical Navigable Small World):
Es el algoritmo más popular actualmente. Construye un grafo multicapa donde cada nodo está conectado a vecinos cercanos. La búsqueda «navega» por el grafo, saltando entre capas de menor a mayor resolución.
Las ventajas son búsqueda muy rápida (milisegundos para millones de vectores), buen recall (encuentra los verdaderos vecinos cercanos), y funciona bien en memoria. Las desventajas son que usa más memoria que otros métodos y la construcción del índice puede ser lenta.
IVF (Inverted File Index):
Divide el espacio vectorial en clusters (usando K-means). Al buscar, primero identifica los clusters más cercanos y luego busca dentro de esos clusters.
Las ventajas son menor uso de memoria, bueno para datasets muy grandes, y permite filtrado eficiente. Las desventajas son que puede perder precisión si la consulta está entre clusters y requiere entrenamiento previo de clusters.
Flat (Búsqueda Exacta):
Compara contra todos los vectores. Es preciso al 100% pero lento para grandes volúmenes. Es útil para datasets pequeños (menos de 100K) o cuando la precisión es crítica.
3.3 Comparativa de Bases de Datos Vectoriales
Pinecone es un servicio cloud completamente gestionado, muy fácil de usar. Es ideal para equipos sin DevOps, cuando quieres empezar rápido, o para producción sin preocuparte de infraestructura. El precio es por uso (vectores + queries).
Weaviate es open source con opción cloud. Tiene búsqueda híbrida nativa (vectorial + keyword), GraphQL API, y módulos para diferentes modelos de embeddings. Es ideal cuando necesitas búsqueda híbrida, si prefieres open source con soporte comercial, o para casos de uso complejos.
Chroma es open source, muy simple. Está embebido (corre en tu proceso), es perfecto para prototipos y desarrollo, y tiene integración nativa con LangChain. Es ideal para empezar y prototipar, proyectos pequeños-medianos, o desarrollo local.
Qdrant es open source con opción cloud. Tiene buen rendimiento, filtrado avanzado, y escrito en Rust para eficiencia. Es ideal cuando necesitas filtrado complejo, buen balance rendimiento/features, o proyectos medianos-grandes.
pgvector es una extensión de PostgreSQL. Usa tu base de datos existente, sin infraestructura adicional, SQL estándar para queries. Es ideal si ya usas PostgreSQL, para equipos que conocen SQL, o cuando quieres minimizar complejidad.
Recomendación Práctica:
Para prototipos usa Chroma (simple, local, gratis). Para producción pequeña-mediana usa Qdrant Cloud o Pinecone. Para producción grande con equipo DevOps usa Qdrant o Weaviate self-hosted. Si ya tienes PostgreSQL usa pgvector.
3.4 Metadatos y Filtrado
La Importancia de los Metadatos:
Los embeddings capturan similitud semántica, pero a veces necesitas filtrar por atributos específicos: fecha, departamento, tipo de documento, nivel de confidencialidad.
Ejemplo Práctico:
Consulta: "Política de vacaciones"
Sin filtro: Puede traer documentos de cualquier año
Con filtro: año >= 2024 AND departamento = "RRHH"Tipos de Filtrado:
El pre-filtrado aplica filtros ANTES de la búsqueda vectorial. Es más preciso pero puede ser lento si el filtro es muy selectivo.
El post-filtrado hace búsqueda vectorial, luego filtra resultados. Es más rápido pero puede retornar menos de K resultados si muchos son filtrados.
Metadatos Útiles para RAG en Cobranzas:
Para metadatos de documento: tipo (manual, política, FAQ, script), fecha de última actualización, departamento, versión, y nivel de confidencialidad.
Para metadatos de contenido: categoría (pago, reclamo, negociación, evasión), producto (tarjeta, préstamo, hipotecario), y segmento de cliente.
4. Estrategias de Chunking
4.1 ¿Por Qué Chunking?
El Problema:
Los documentos originales son demasiado largos para los embeddings (que funcionan mejor con textos cortos) y para el contexto del LLM (que tiene límite de tokens). Necesitamos dividirlos en pedazos manejables.
El Dilema del Tamaño:
Chunks muy pequeños (100 tokens) capturan ideas muy específicas pero pierden contexto. Una oración aislada puede ser ambigua. Chunks muy grandes (2000 tokens) mantienen contexto pero diluyen la especificidad. El embedding promedia conceptos diversos, dificultando encontrar información específica.
El tamaño óptimo depende del tipo de contenido, tipo de consultas esperadas, y modelo de embeddings.
4.2 Estrategias de Chunking
Chunking por Tamaño Fijo:
Divide el texto en chunks de N caracteres o tokens. Es simple y predecible pero puede cortar oraciones y párrafos a la mitad. El tamaño típico es 500-1000 caracteres con overlap de 50-100.
Chunking por Oraciones:
Divide respetando límites de oraciones. Cada chunk es un número fijo de oraciones. Mantiene coherencia gramatical pero las oraciones varían mucho en longitud.
Chunking por Párrafos:
Usa párrafos como unidades naturales. Respeta la estructura del autor pero los párrafos pueden ser muy cortos o muy largos.
Chunking Recursivo:
Intenta dividir por párrafos primero, si el párrafo es muy largo divide por oraciones, si la oración es muy larga divide por tamaño. Balancea estructura y tamaño siendo el más usado en práctica.
Chunking Semántico:
Usa embeddings para detectar cambios de tema y divide cuando el tema cambia significativamente. Es más inteligente pero más lento y complejo.
Chunking por Estructura:
Para documentos estructurados (HTML, Markdown, PDFs con formato), divide por secciones, headers, capítulos. Respeta la estructura intencional del documento.
4.3 El Parámetro de Overlap
¿Qué es el Overlap?
Es la cantidad de texto que se repite entre chunks consecutivos. Si tienes chunks de 500 caracteres con overlap de 100, el chunk 2 empieza 400 caracteres después del inicio del chunk 1.
¿Por Qué Usar Overlap?
Sin overlap, información importante puede quedar «cortada» entre dos chunks. Con overlap, hay redundancia que aumenta la probabilidad de recuperar información completa.
Ejemplo Visual:
Documento: "El cliente puede solicitar refinanciamiento después de 6 meses
de haber adquirido el crédito. Los requisitos incluyen..."
Sin overlap:
Chunk 1: "El cliente puede solicitar refinanciamiento después de"
Chunk 2: "6 meses de haber adquirido el crédito. Los requisitos..."
→ Consulta "¿cuántos meses para refinanciar?" podría no encontrar respuesta clara
Con overlap (50 chars):
Chunk 1: "El cliente puede solicitar refinanciamiento después de 6 meses"
Chunk 2: "refinanciamiento después de 6 meses de haber adquirido el crédito. Los requisitos..."
→ Ambos chunks contienen la información completaValores Típicos de Overlap:
El overlap típico es 10-20% del tamaño del chunk. Para chunks de 500 caracteres, overlap de 50-100. Demasiado overlap aumenta el tamaño de la base de datos y puede introducir ruido.
4.4 Chunking Avanzado: Hierarchical y Parent-Child
El Problema del Contexto:
Chunks pequeños son buenos para retrieval (específicos) pero malos para generation (poco contexto). Chunks grandes son malos para retrieval (diluidos) pero buenos para generation (contexto completo).
Solución: Indexar Pequeño, Recuperar Grande
El enfoque Parent-Child indexa chunks pequeños para búsqueda precisa, pero al recuperar devuelve el chunk «padre» más grande que contiene el contexto.
Documento Original (Parent Level 0)
├── Sección 1 (Parent Level 1)
│ ├── Párrafo 1.1 (Child - indexado)
│ ├── Párrafo 1.2 (Child - indexado)
│ └── Párrafo 1.3 (Child - indexado)
├── Sección 2 (Parent Level 1)
│ └── ...
Búsqueda: Encuentra "Párrafo 1.2" como más relevante
Retorna: Toda la "Sección 1" para dar contexto al LLMImplementación Típica:
Se crean dos índices: uno de chunks pequeños (256 tokens) para retrieval y otro de chunks grandes (1024 tokens) para contexto. Se almacena el mapeo child→parent. Al recuperar, se busca en el índice pequeño y se retorna el parent correspondiente.
4.5 Preprocesamiento de Documentos
Limpieza de Texto:
La limpieza básica incluye remover headers/footers repetitivos, eliminar caracteres especiales innecesarios, normalizar espacios en blanco, y corregir encoding.
Para PDFs específicamente hay que manejar texto extraído con OCR (puede tener errores), reconstruir tablas que se extraen mal, identificar y manejar imágenes con texto, y mantener orden de lectura correcto (columnas).
Enriquecimiento:
El enriquecimiento de metadatos implica extraer fecha, autor, versión del documento, clasificar tipo de documento automáticamente, e identificar secciones y estructura.
El enriquecimiento de contenido incluye expandir acrónimos específicos del dominio, añadir contexto a tablas y figuras, y generar resúmenes de secciones.
Ejemplo de Preprocesamiento para Cobranzas:
Para el texto original «Según el Art. 5 del Regl. de Cobranzas, el deudor tiene 30 días…», después de la expansión de acrónimos queda «Según el Artículo 5 del Reglamento de Cobranzas, el deudor tiene 30 días…», y con metadatos añadidos: «{tipo: ‘normativa’, fuente: ‘reglamento_cobranzas_v2024’, seccion: ‘plazos’}».
5. El Pipeline de Retrieval
5.1 Retrieval Básico: Búsqueda Vectorial
El Flujo:
La query del usuario entra al sistema, se convierte a embedding usando el mismo modelo usado para indexar (¡importante!), se buscan los K vectores más cercanos en la BD, y se retornan los chunks correspondientes.
Parámetro K (Top-K):
K es el número de documentos a recuperar. Un K muy bajo puede perder información relevante. Un K muy alto introduce ruido y consume contexto del LLM.
Valores típicos son K entre 3 y 10 para la mayoría de casos. Se recomienda experimentar con tu dataset específico. Considera el tamaño del contexto disponible del LLM.
5.2 Búsqueda Híbrida: Vectorial + Keyword
¿Por Qué Híbrido?
La búsqueda vectorial es excelente para similitud semántica («¿cómo pago mi deuda?» encuentra «opciones de cancelación de obligaciones») pero puede fallar con términos específicos, códigos, nombres propios, o números.
La búsqueda por keywords (BM25, TF-IDF) es excelente para coincidencias exactas («código de error E-4521» encuentra documentos con ese código exacto) pero falla con sinónimos y parafraseo.
La Combinación:
La búsqueda híbrida ejecuta ambos tipos de búsqueda y combina los resultados. Hay diferentes estrategias de fusión.
Reciprocal Rank Fusion (RRF):
Es el método más común para combinar rankings de diferentes fuentes.
Score_RRF = Σ 1/(k + rank_i)
Donde:
- k es una constante (típicamente 60)
- rank_i es la posición en cada lista de resultados
Ejemplo:
Doc A: rank 1 en vectorial, rank 5 en keyword
Score_A = 1/(60+1) + 1/(60+5) = 0.0164 + 0.0154 = 0.0318
Doc B: rank 3 en vectorial, rank 1 en keyword
Score_B = 1/(60+3) + 1/(60+1) = 0.0159 + 0.0164 = 0.0323
Doc B gana por mejor balance entre ambos métodos5.3 Reranking: Segunda Pasada de Relevancia
El Concepto:
El retrieval inicial (vectorial o híbrido) es rápido pero aproximado. Un reranker es un modelo más sofisticado que re-evalúa y reordena los candidatos.
El Flujo:
Query → Retrieval (Top 20 candidatos) → Reranker → Top 5 finales → LLMModelos de Reranking:
Los Cross-Encoders procesan query y documento juntos, capturando interacciones sutiles. Son más precisos pero más lentos, ideales para reranking de pocos candidatos. Ejemplos incluyen ms-marco-MiniLM-L-6-v2 y bge-reranker-large.
Los LLM-based Rerankers usan un LLM para juzgar relevancia. Son muy precisos pero costosos en latencia y dinero. Útiles cuando la precisión es crítica.
¿Cuándo Usar Reranking?
Úsalo cuando la precisión es crítica y puedes tolerar latencia adicional (50-200ms). Es especialmente útil cuando el retrieval inicial trae muchos falsos positivos, cuando las consultas son complejas o ambiguas, o en dominios especializados donde los embeddings genéricos fallan.
5.4 Query Transformation
El Problema:
Las queries de usuarios reales son a menudo ambiguas, incompletas, mal redactadas, o usan vocabulario diferente al de los documentos.
Técnicas de Transformación:
La expansión de query agrega términos relacionados para ampliar la búsqueda. Por ejemplo, «vacaciones» se convierte en «vacaciones OR licencia OR descanso OR días libres».
La reformulación con LLM usa un LLM para reescribir la query de forma más clara. «como pago» se convierte en «¿Cuáles son los métodos disponibles para realizar el pago de mi deuda?».
El HyDE (Hypothetical Document Embeddings) genera un documento hipotético que respondería la query, luego busca documentos similares a ese hipotético. Es muy efectivo pero añade latencia.
Multi-Query Retrieval:
Genera múltiples variantes de la query original, ejecuta retrieval para cada variante, y combina los resultados (union o fusion).
Query original: "refinanciamiento"
Variantes generadas:
1. "¿Cómo solicitar refinanciamiento de deuda?"
2. "Requisitos para reestructurar crédito"
3. "Opciones de renegociación de préstamo"
Retrieval: Buscar con las 3 variantes
Resultado: Unión de documentos únicos encontrados6. La Fase de Generation
6.1 Construcción del Prompt
Estructura Típica:
Un prompt de RAG tiene componentes bien definidos:
[SYSTEM]
Eres un asistente experto en {dominio}. Responde basándote
ÚNICAMENTE en el contexto proporcionado. Si la información
no está en el contexto, indica que no tienes esa información.
[CONTEXTO]
Documento 1: {chunk_1}
---
Documento 2: {chunk_2}
---
Documento 3: {chunk_3}
[INSTRUCCIONES ADICIONALES]
- Cita las fuentes cuando sea relevante
- Sé conciso y directo
- Si hay información contradictoria, menciónalo
[QUERY]
{pregunta_del_usuario}Mejores Prácticas:
Sobre el contexto, ordena los documentos por relevancia (más relevante primero o último, según el modelo). Incluye metadatos útiles como fuente, fecha, y sección. Usa separadores claros entre documentos.
Sobre las instrucciones, sé explícito sobre qué hacer si no hay información suficiente. Indica el formato de respuesta deseado. Especifica si debe citar fuentes y cómo.
Sobre la longitud, deja espacio suficiente para la respuesta. No llenes todo el contexto disponible, el modelo necesita «pensar». Un balance típico es 60-70% contexto y 30-40% para respuesta.
6.2 Manejo de Contexto Insuficiente
El Problema:
A veces los documentos recuperados no contienen la información necesaria. El LLM puede alucinar una respuesta si no se le instruye correctamente.
Estrategias:
La instrucción explícita indica claramente «Si no encuentras la información en el contexto, responde: ‘No tengo información sobre ese tema en mi base de conocimiento'».
La verificación de relevancia antes de generar evalúa si los documentos recuperados son realmente relevantes. Si el score de similitud es bajo, advierte al usuario.
El fallback gracioso ofrece alternativas cuando no puedes responder directamente: «No encontré información específica sobre X, pero puedo informarte sobre Y que está relacionado, o puedes contactar a Z para más detalles.»
6.3 Citación de Fuentes
¿Por Qué Citar?
Las citas proporcionan verificabilidad para que el usuario pueda confirmar la información. Dan transparencia mostrando de dónde viene la respuesta. Generan confianza porque las respuestas fundamentadas son más creíbles. Ofrecen trazabilidad para identificar documentos desactualizados o incorrectos.
Formatos de Citación:
La citación inline incluye las referencias en el texto: «El plazo máximo es 30 días [Manual de Cobranzas, §5.2]…»
La citación al final lista las fuentes después de la respuesta: «Fuentes consultadas: 1) Manual de Cobranzas v2024, 2) Política de Refinanciamiento…»
La citación con fragmentos incluye el texto exacto del documento: «Según el documento: ‘…el deudor podrá solicitar refinanciamiento…’ (Reglamento, Art. 12)»
Implementación:
Incluye identificadores en el contexto para cada documento. Instruye al LLM a referenciar usando esos identificadores. Mapea los identificadores a URLs o rutas de documento en el post-procesamiento.
6.4 Streaming y Latencia
Componentes de Latencia:
La latencia de embedding es el tiempo de convertir query a vector, típicamente 10-50ms. La latencia de retrieval es el tiempo de búsqueda en la BD vectorial, típicamente 10-100ms. La latencia de reranking, si se usa, es típicamente 50-200ms. La latencia de generation es el tiempo del LLM, que puede ser 500ms a varios segundos.
Optimizaciones:
El streaming inicia la respuesta mientras el LLM genera. El usuario ve texto aparecer en lugar de esperar. Mejora la percepción de velocidad significativamente.
El caching almacena respuestas para queries frecuentes. Almacena embeddings de queries comunes. Cachea chunks frecuentemente recuperados.
La paralelización ejecuta retrieval de múltiples fuentes en paralelo. Pre-computa embeddings de queries predecibles.
7. Evaluación de Sistemas RAG
7.1 El Desafío de Evaluar RAG
RAG tiene múltiples componentes que pueden fallar independientemente. Una mala respuesta puede ser causada por retrieval que no encontró los documentos correctos (problema de retrieval), documentos correctos pero LLM que interpretó mal (problema de generation), documentos desactualizados o incorrectos (problema de datos), o query ambigua que confundió al sistema (problema de input).
Necesitamos métricas que diagnostiquen cada componente.
7.2 Métricas de Retrieval
Recall@K:
Mide qué proporción de documentos relevantes fueron recuperados en los top K.
Recall@K = (Documentos relevantes en top K) / (Total documentos relevantes)
Ejemplo:
- Hay 5 documentos relevantes para la query
- Recuperamos top 10, de los cuales 4 son relevantes
- Recall@10 = 4/5 = 0.8 (80%)Un recall alto significa que no nos perdemos información importante. Es la métrica más crítica, porque si el retrieval no encuentra el documento, el LLM no puede usarlo.
Precision@K:
Mide qué proporción de los documentos recuperados son relevantes.
Precision@K = (Documentos relevantes en top K) / K
Ejemplo:
- Recuperamos top 10, de los cuales 4 son relevantes
- Precision@10 = 4/10 = 0.4 (40%)Precisión alta significa menos ruido para el LLM. Es importante pero secundaria a recall, ya que el LLM puede ignorar información irrelevante.
MRR (Mean Reciprocal Rank):
Mide qué tan arriba aparece el primer documento relevante.
RR = 1 / (posición del primer documento relevante)
MRR = promedio de RR sobre todas las queries
Ejemplo:
Query 1: primer relevante en posición 1 → RR = 1/1 = 1.0
Query 2: primer relevante en posición 3 → RR = 1/3 = 0.33
Query 3: primer relevante en posición 2 → RR = 1/2 = 0.5
MRR = (1.0 + 0.33 + 0.5) / 3 = 0.61MRR alto significa que la información más importante aparece primero.
nDCG (Normalized Discounted Cumulative Gain):
Considera no solo si un documento es relevante, sino qué tan relevante (gradaciones). Penaliza documentos relevantes que aparecen en posiciones bajas. Es más sofisticada que Precision/Recall.
7.3 Métricas de Generation
Faithfulness (Fidelidad):
Mide si la respuesta es consistente con el contexto proporcionado. ¿El LLM inventó información o se basó en los documentos?
Ejemplo:
Contexto: "El plazo máximo es 30 días"
Respuesta: "El plazo máximo es 30 días calendario"
Faithfulness: BAJO (añadió "calendario" que no está en el contexto)Answer Relevance:
Mide si la respuesta realmente responde la pregunta.
Query: "¿Cuál es el plazo para pagar?"
Respuesta: "Los pagos se pueden hacer por transferencia o en agencia"
Relevance: BAJO (responde sobre métodos, no plazos)Context Relevance:
Mide si los documentos recuperados son relevantes para la pregunta. Ayuda a diagnosticar si el problema está en retrieval o generation.
7.4 Frameworks de Evaluación
RAGAS (RAG Assessment):
Es el framework más popular para evaluar RAG. Calcula métricas automáticamente usando LLMs como evaluadores. Incluye Faithfulness, Answer Relevance, Context Relevance, y Answer Correctness.
Las ventajas son que es automático, escalable, y no requiere ground truth para todas las métricas. Las limitaciones son que depende de la calidad del LLM evaluador y puede ser costoso para evaluaciones grandes.
Métricas de RAGAS:
Faithfulness: ¿Las afirmaciones de la respuesta están soportadas por el contexto?
- Extrae afirmaciones de la respuesta
- Verifica cada una contra el contexto
- Score = (afirmaciones soportadas) / (total afirmaciones)
Answer Relevance: ¿La respuesta es pertinente a la pregunta?
- Genera preguntas que la respuesta contestaría
- Compara similitud con la pregunta original
- Score = similitud promedio
Context Precision: ¿El contexto recuperado es relevante?
- Evalúa cada chunk por su relevancia
- Penaliza chunks irrelevantes en posiciones altas
Context Recall: ¿Se recuperó toda la información necesaria?
- Compara respuesta de referencia con contexto
- Verifica que el contexto contenga la información necesariaTruLens:
Similar a RAGAS pero con interfaz de dashboard. Monitoreo en tiempo real de aplicaciones RAG. Incluye trazabilidad de cada componente.
7.5 Evaluación Humana
¿Por Qué Evaluación Humana?
Las métricas automáticas son aproximaciones. Para decisiones importantes como lanzar a producción, comparar arquitecturas muy diferentes, o evaluar dominios muy especializados, la evaluación humana sigue siendo gold standard.
Diseño de Evaluación Humana:
Las dimensiones típicas a evaluar son Correctness (¿la información es correcta?), Completeness (¿responde completamente?), Helpfulness (¿es útil para el usuario?), y Harmlessness (¿evita daño?).
El formato puede ser escala Likert (1-5), comparación A/B, o ranking de múltiples respuestas.
Para anotadores, define guías claras con ejemplos, usa múltiples anotadores y mide acuerdo, y balancea expertise del dominio vs. perspectiva de usuario.
7.6 Benchmarking y Mejora Continua
Crear un Golden Dataset:
Un golden dataset es un conjunto de preguntas con respuestas correctas conocidas. Debe incluir variedad de tipos de pregunta (factual, comparativa, procedural), casos fáciles y difíciles, y queries reales de usuarios.
El tamaño típico es de 100-500 pares query-respuesta para empezar.
Proceso de Mejora:
El primer paso es la evaluación inicial de baseline midiendo métricas actuales con golden dataset. Luego viene la identificación de problemas analizando queries con peor desempeño y categorizando tipos de errores (retrieval, generation, datos). Después está el desarrollo de hipótesis planteando cambios: ¿mejor chunking? ¿diferentes embeddings? ¿reranking? Sigue la experimentación probando cambios uno a la vez y midiendo impacto en métricas. Finalmente la validación evalúa no solo métricas automáticas sino también con usuarios reales.
Monitoreo en Producción:
Después del lanzamiento hay que loggear queries, documentos recuperados, y respuestas. Se debe implementar feedback del usuario (thumbs up/down). Hay que detectar drift con alertas cuando las métricas degradan. Y revisar manualmente una muestra de interacciones periódicamente.
8. Patrones Avanzados de RAG
8.1 RAG Iterativo (Self-RAG)
El Concepto:
En lugar de una sola pasada de retrieval→generation, el sistema puede hacer múltiples iteraciones refinando la búsqueda basándose en lo que encontró.
Query: "Compara las tasas de refinanciamiento de 2023 vs 2024"
Iteración 1:
- Retrieval: busca "tasas refinanciamiento"
- Encuentra: tasas de 2024
- LLM detecta: falta información de 2023
Iteración 2:
- Retrieval: busca "tasas refinanciamiento 2023"
- Encuentra: tasas de 2023
- LLM: ahora puede comparar ambos8.2 RAG con Agentes
El Concepto:
Un agente LLM decide dinámicamente qué herramientas usar, incluyendo diferentes fuentes de retrieval.
Query: "¿Cuánto debo y cuáles son mis opciones?"
Agente decide:
1. Consultar BD de clientes (herramienta API) → Saldo: S/. 5,000
2. Buscar en FAQ de opciones de pago (RAG) → Opciones encontradas
3. Verificar políticas vigentes (RAG diferente) → Promoción activa
4. Sintetizar respuesta personalizada8.3 RAG Multimodal
El Concepto:
No solo texto, sino también imágenes, tablas, diagramas.
Aplicaciones en Banca:
Pueden procesarse estados de cuenta que son PDFs con tablas complejas, cheques e imágenes de documentos, o diagramas de procesos.
Implementación:
Modelos de vision-language extraen información de imágenes. Tablas se convierten a representaciones estructuradas. El retrieval puede ser sobre embeddings de imágenes también.
8.4 GraphRAG
El Concepto:
Además del índice vectorial, mantiene un grafo de conocimiento con relaciones entre entidades.
Grafo de Conocimiento:
[Cliente A] --tiene_deuda--> [Crédito X]
[Crédito X] --tipo--> [Hipotecario]
[Crédito X] --tasa--> [8.5%]
[Hipotecario] --permite--> [Refinanciamiento]Ventajas:
Captura relaciones explícitas que los embeddings pueden perder. Permite razonamiento multi-salto: «Si el cliente tiene crédito hipotecario, y los hipotecarios permiten refinanciamiento, entonces puede refinanciar». Mejor para preguntas de tipo «¿cómo se relaciona X con Y?».
9. Resumen: Checklist para Implementar RAG
Antes de Empezar
Define claramente el caso de uso y las preguntas que el sistema debe responder. Identifica las fuentes de documentos y evalúa su calidad. Estima el volumen de documentos y queries esperadas. Decide si necesitas búsqueda híbrida, reranking, u otras features avanzadas.
Implementación
Para datos preprocesa y limpia documentos exhaustivamente. Experimenta con diferentes estrategias de chunking. Enriquece con metadatos útiles.
Para embeddings elige un modelo apropiado para tu idioma y dominio. Considera fine-tuning si el dominio es muy especializado.
Para retrieval empieza simple (vectorial puro), añade complejidad si es necesario. Implementa búsqueda híbrida si tienes términos específicos importantes. Considera reranking para mayor precisión.
Para generation diseña prompts claros con instrucciones explícitas. Implementa manejo de contexto insuficiente. Añade citación de fuentes.
Evaluación
Crea un golden dataset desde el inicio. Mide métricas de retrieval Y generation por separado. Implementa evaluación humana para decisiones importantes. Configura monitoreo para producción.
Iteración
Analiza errores sistemáticamente para identificar el componente problemático. Experimenta con cambios de uno en uno. Mantén un registro de experimentos y resultados.
10. Puntos Clave para tus Capacitaciones
Para Ejecutivos:
RAG permite crear asistentes que responden con la información actualizada de la empresa, reduciendo alucinaciones y aumentando confianza. El ROI viene de menor tiempo buscando información, respuestas consistentes y verificables, y reducción de errores por información desactualizada.
Para Equipos Técnicos:
El éxito de RAG depende más de la calidad de datos y chunking que del modelo de embeddings o LLM elegido. Empiecen simple, midan exhaustivamente, y añadan complejidad solo cuando sea necesario.
Para Usuarios de Negocio:
RAG no es magia; su calidad depende de la calidad de los documentos fuente. Mantengan la documentación actualizada y bien estructurada. El sistema puede citar fuentes, verificarlas es responsabilidad del usuario.
