De Cero a un Sistema RAG en Producción: Errores, Soluciones y Métricas Reales
3/26/2026
Implementar un sistema RAG (Retrieval-Augmented Generation) en producción es uno de esos proyectos que parecen simples en teoría pero revelan su complejidad en la práctica. En este artículo comparto mi experiencia construyendo un sistema RAG completo, desde la indexación de documentos hasta la generación de respuestas inteligentes.
¿Qué es un Sistema RAG?
RAG combina dos elementos clave:
- Retrieval: Búsqueda semántica de información relevante en una base de conocimiento
- Generation: Uso de un LLM para generar respuestas basadas en esa información
En lugar de que el LLM invente respuestas, le proporcionas contexto real de tus propios documentos.
Mi Stack Tecnológico
Después de evaluar múltiples opciones, mi stack final fue:
Base de Datos Vectorial: Qdrant
Por qué Qdrant:
- Rápido y eficiente (búsquedas <10ms en 400+ docs)
- Fácil de self-hostear (Docker)
- Excelente soporte para filtros y metadata
- Snapshots nativos para backups
Embeddings: sentence-transformers
Empecé con OpenAI embeddings pero migré a modelos locales. Ventajas: sin costes por request, sin límites de rate, privacidad total (datos no salen del servidor), y cuantización int8 para 4x menos espacio.
OCR: pytesseract + pdf2image
Para documentos escaneados (tickets, facturas). Lección aprendida: El 70% del valor está en un buen preprocesamiento OCR.
Los 3 Errores Que Cometí
1. No Validar Calidad de Embeddings
El error: Asumí que todos los embeddings eran buenos. Indexé PDFs corruptos, imágenes sin OCR, y archivos HTML como si fueran texto plano.
La solución: Validar antes de indexar. Rechazar textos menores a 50 caracteres y detectar caracteres mal codificados.
2. Chunks Demasiado Grandes
El error: Chunks de 2000 tokens generaban contexto demasiado amplio y respuestas genéricas.
La solución: Reducir a 500-800 tokens con overlap. Resultado: 3x mejor precisión en respuestas.
3. Ignorar Metadata
El error: Solo indexar texto, sin metadata como fecha, tipo de documento, proveedor.
La solución: Añadir metadata estructurada (filename, fecha, tipo, proveedor, importe). Resultado: Filtros precisos y mejor contexto para el LLM.
Arquitectura Final
Usuario → Query → Embedding (local) → Qdrant búsqueda vectorial (top 5) → Filtros metadata → LLM (Claude) + contexto → Respuesta
Métricas Reales
Después de 3 meses en producción:
- Documentos indexados: 397 (PDFs, DOCX, XLSX, imágenes OCR)
- Tiempo de indexación: ~3 min para 280 documentos
- Tiempo de búsqueda: <10ms (P95)
- Precisión: ~92% de respuestas correctas vs búsqueda manual
- Coste: $0 (todo self-hosted)
Lecciones Clave
1. El preprocesamiento es el 80% del trabajo
Invertí más tiempo limpiando PDFs corruptos, aplicando OCR, y extrayendo metadata que configurando Qdrant.
2. Embeddings locales > embeddings cloud
Para uso privado (facturas, documentos personales), la privacidad y coste cero compensan la ligera pérdida de calidad.
3. Backups automatizados son esenciales
Snapshot diario de Qdrant + backup a S3 con Restic. Nunca confíes en un solo punto de fallo.
Conclusión
Construir un sistema RAG es más desafiante de lo que parece, pero tremendamente útil. La clave está en:
- Empezar simple (Qdrant + embeddings locales)
- Iterar basándote en métricas reales
- Priorizar preprocesamiento de calidad
- Automatizar backups desde día 1
¿Estás construyendo tu propio sistema RAG? Me encantaría saber qué stack estás usando y qué problemas has encontrado.