Módulo 7: RAG y Semantic Search
7. Ejercicio Integrador: Diagnosticar Problemas de RAG
Descripción del ejercicio
Este es el ejercicio integrador del Módulo 7. Aquí diagnosticas 5 problemas comunes en sistemas RAG y propones soluciones específicas.
Problema 1: Respuestas genéricas
Contexto:
Sistema RAG para documentación de API. Usuarios reportan respuestas genéricas que no responden la pregunta específica.
Ejemplo:
User: "¿Cómo autenticar requests con JWT?"
Sistema (RAG):
"Nuestra API requiere autenticación para proteger tus datos.
Puedes autenticar usando varios métodos disponibles."
→ Respuesta genérica (NO dice cómo usar JWT)
Diagnóstico: ¿Cuál es el problema?
Ver solución
Problema: Retrieval failure (búsqueda retorna chunks generales, no específicos sobre JWT)
Posibles causas:
- Chunk con JWT está embedado pobremente
- Query embedding no captura "JWT" como keyword importante
- Top-K muy bajo (ej: top-3, no alcanza a incluir chunk relevante)
Soluciones:
Solución 1: Hybrid search (keyword + semantic)
Keyword search: "JWT" debe aparecer literalmente
Semantic search: "autenticación" conceptualmente
Fusión: RRF → Garantiza que "JWT" esté en resultados
Solución 2: Aumentar top-K
top-K actual: 3
top-K nuevo: 10
→ Mayor chance de incluir chunk relevante
Solución 3: Query expansion
Query original: "JWT"
Expandida: "JWT OR JSON Web Token OR token authentication"
→ Mayor recall
Problema 2: Latencia inaceptable
Contexto:
Sistema RAG para soporte en vivo. Latencia promedio: 8 segundos. Usuarios abandonan antes de ver respuesta.
Breakdown de latencia:
- Query embedding: 150ms
- kNN search: 50ms
- Reranking (Cohere): 300ms
- LLM generation (GPT-4): 7500ms
Total: 8000ms
Diagnóstico: ¿Cómo reducir latencia?
Ver solución
Problema: LLM generation es 94% de la latencia (7.5s de 8s)
Soluciones:
Solución 1: Cambiar a modelo más rápido
GPT-4 Turbo → GPT-3.5 Turbo
Latencia: 7500ms → 1500ms
Ahorro: 6 segundos ✅
Nueva latencia total: 2000ms (aceptable)
Solución 2: Streaming
Usuario ve respuesta mientras genera:
- Percepción de latencia: ~1 segundo
- Latencia real: igual (8s)
- Pero UX mejorada
Solución 3: Cache de queries frecuentes
Top-20 preguntas (30% de queries):
→ Respuestas pre-generadas
→ Latencia: 0ms para esas queries
70% restante:
→ Latencia: 8s (pero promedio baja a ~5.6s)
Solución 4: Eliminar reranking (si es aceptable)
Reranking: 300ms
Si precision sigue siendo alta sin reranking:
→ Nueva latencia: 7700ms (ahorro menor, pero algo)
Problema 3: Hallucinations en respuestas
Contexto:
Sistema RAG para información médica. A veces LLM "inventa" dosis de medicamentos NO presentes en contexto.
Ejemplo:
Contexto retornado:
"El medicamento X se usa para tratar Y. Consulte con su médico."
Query: "¿Cuál es la dosis de X?"
LLM: "La dosis recomendada es 500mg dos veces al día."
→ INVENTADO (contexto NO menciona dosis) ❌
Diagnóstico: ¿Cómo prevenir esto?
Ver solución
Problema: LLM alucina cuando contexto es insuficiente
Soluciones:
Solución 1: Prompt engineering estricto
System prompt:
"Eres un asistente médico. REGLA CRÍTICA:
- Si el contexto NO contiene la respuesta explícita,
di EXACTAMENTE: 'No tengo información suficiente para responder esto.'
- NUNCA inventes dosis, diagnósticos, o tratamientos.
- Cita SIEMPRE la fuente exacta."
Solución 2: Citation forcing
"Responde en formato:
'Según [documento], página [X]: [respuesta]'
Si NO puedes citar fuente, NO respondas."
Solución 3: Verificación post-generación
1. LLM genera respuesta
2. Sistema extrae "hechos" de la respuesta:
- "500mg" (dosis)
- "dos veces al día" (frecuencia)
3. Sistema verifica si esos hechos están en contexto
→ "500mg" NO está en contexto ❌
4. Sistema rechaza respuesta:
"Respuesta bloqueada: contiene información no verificada"
Solución 4: Temperatura = 0
LLM con temperature=0.1 (muy bajo):
→ Respuestas más determinísticas
→ Menos creatividad = menos hallucinations
Problema 4: Costo fuera de control
Contexto:
Sistema RAG con 500K queries/mes. Costo actual: $11,000/mes. Presupuesto: $3000/mes.
Breakdown de costo:
- Embeddings (query): 500K × $0.000004 = $2/mes
- LLM (GPT-4): 500K × $0.022 = $11,000/mes
- Vector DB (Pinecone): $70/mes
Total: $11,072/mes (3.7x sobre presupuesto)
Diagnóstico: ¿Cómo reducir costo a $3000/mes?
Ver solución
Problema: LLM es 99% del costo ($11K de $11K)
Soluciones:
Solución 1: Cambiar a GPT-3.5 Turbo
GPT-4: $0.022/query
GPT-3.5: $0.0011/query (20x más barato)
Nuevo costo LLM: 500K × $0.0011 = $550/mes
Total: $622/mes ✅ (dentro de presupuesto)
Solución 2: Cache agresivo (50% de queries repetidas)
Cache hits: 250K queries → Costo $0
Cache misses: 250K queries → Costo $5,500
Nuevo total: $5,572/mes
→ Aún sobre presupuesto, combinar con GPT-3.5:
250K × $0.0011 = $275/mes ✅
Solución 3: Modelo self-hosted (Llama 3)
Setup: GPU server ($500/mes)
Inference: $0/query (self-hosted)
Nuevo costo: $500/mes (solo server) + $72 (Pinecone) = $572/mes ✅
Solución 4: Tier pricing (queries críticas vs no críticas)
Queries críticas (10%): GPT-4 → 50K × $0.022 = $1,100/mes
Queries no críticas (90%): GPT-3.5 → 450K × $0.0011 = $495/mes
Total: $1,667/mes ✅
Problema 5: Contexto insuficiente
Contexto:
Sistema RAG para análisis legal. Query: "¿Qué dicen los artículos 12, 15, y 23 combinados sobre este caso?"
Problema:
Top-5 chunks solo incluyen artículo 12 y 15. Artículo 23 NO está en contexto.
Resultado:
LLM: "Según artículos 12 y 15... (no menciona artículo 23)"
→ Respuesta incompleta ❌
Diagnóstico: ¿Cómo garantizar que todos los artículos relevantes estén en contexto?
Ver solución
Problema: Top-K insuficiente o búsqueda no captura todos los artículos mencionados
Soluciones:
Solución 1: Query decomposition
Query original: "artículos 12, 15, y 23"
→ Detectar múltiples entidades
Ejecutar 3 búsquedas:
1. "artículo 12" → Top-3
2. "artículo 15" → Top-3
3. "artículo 23" → Top-3
Combinar: 9 chunks totales (sin duplicados)
→ Garantiza que todos estén en contexto ✅
Solución 2: Metadata filtering
Buscar con filtro:
metadata.article_number IN [12, 15, 23]
→ Solo retorna chunks de esos artículos específicos
Solución 3: Aumentar top-K
top-K actual: 5
top-K nuevo: 20
→ Mayor chance de incluir artículo 23
Solución 4: Hybrid search (keyword + semantic)
Keyword: "artículo 23" (literal)
Semantic: Concepto relacionado
Fusión → Garantiza que "23" aparezca exactamente
Resumen del ejercicio
Lo que hiciste:
- ✅ Diagnosticaste 5 problemas comunes en RAG
- ✅ Identificaste causas raíz (retrieval, latencia, hallucinations, costo, contexto)
- ✅ Propusiste soluciones específicas (hybrid search, cache, prompt engineering, etc.)
Intuición consolidada:
"Los problemas de RAG casi siempre se reducen a 5 categorías: retrieval failure, latencia, hallucinations, costo, o contexto insuficiente. Diagnosticar correctamente es el primer paso; las soluciones son conocidas y aplicables."
Conclusión del Módulo 7
Felicidades por completar Módulo 7: RAG y Semantic Search. 🎉
Lo que lograste:
- ✅ Entiendes el problema que RAG resuelve (hallucinations, desactualización)
- ✅ Conoces la arquitectura de RAG (vector DB, embeddings, LLM)
- ✅ Analizas flujo completo (retrieval → augmentation → generation)
- ✅ Comparas RAG vs fine-tuning (cuándo usar cada uno)
- ✅ Identificas limitaciones de RAG (y cómo mitigarlas)
Intuición clave del módulo:
RAG conecta semantic search con LLMs para eliminar hallucinations y mantener conocimiento actualizado. Es la aplicación práctica de todo lo aprendido: vectores, similaridad, ANN, y ranking. RAG no es perfecto, pero con diseño cuidadoso (hybrid search, reranking, prompt engineering), es la solución más robusta para sistemas de Q&A en producción.
Próximo módulo: Módulo 8: Proyecto Final — Diseñar un sistema RAG completo end-to-end.