← Blog · 16 jul 2026 · IA

RAG en la práctica: cuándo sí, cuándo no y cómo medir su calidad

RAG es la respuesta por defecto a "quiero un chatbot que conozca mis documentos". Y muchas veces es la correcta. Pero también es donde más proyectos se atascan: se monta a ojo, no se mide y nadie sabe por qué a veces responde mal. Esta es la versión práctica, sin humo, de cuándo usar RAG, cómo montarlo y cómo saber si funciona. Es la continuación natural de lo que contamos en IA en producción.

1. Qué es RAG (y qué no)

RAG = recuperar primero, generar después. En cada pregunta, buscas en tus documentos los fragmentos relevantes y se los pasas al modelo como contexto, para que responda con tu información en lugar de con lo que "recuerda". No es magia ni reentrenar el modelo: es un buscador delante de un generador. Si la recuperación falla, la respuesta falla, por muy bueno que sea el modelo.

2. Cuándo SÍ y cuándo NO

Regla corta: RAG añade infraestructura (indexado, embeddings, recuperación). Si no la necesitas, es complejidad gratis.

3. Cómo se monta, pieza a pieza

• Chunking: partir los documentos en fragmentos con sentido (por secciones, no por número fijo de caracteres a ciegas). El tamaño y el solape importan más de lo que parece.
• Embeddings: convertir cada fragmento en un vector. Elige un modelo de embeddings acorde al idioma y dominio; no todos rinden igual en español.
• Almacén vectorial: pgvector sobre Postgres para la mayoría de casos; bases dedicadas (Qdrant, Pinecone) solo con millones de vectores o filtros complejos.
• Recuperación: traer los k fragmentos más cercanos. A menudo conviene híbrido: combinar búsqueda vectorial con palabra clave (BM25) para no perder coincidencias literales.
• Reranking: un reordenador que afina los candidatos antes de pasárselos al modelo. Sube mucho la calidad cuando hay ruido.
• Generación: el modelo responde solo con los fragmentos dados, citando fuente y con permiso explícito para decir "no lo sé".

4. Cómo medir su calidad (lo que casi nadie hace)

Sin medición, RAG es fe. Separa siempre dos planos:

• Calidad de recuperación: ¿están los fragmentos correctos entre los recuperados? Métricas: recall@k (¿aparece la fuente buena en el top-k?) y precision@k (¿cuánto ruido hay?).
• Calidad de generación: ¿la respuesta es fiel a esos fragmentos (sin inventar) y responde de verdad la pregunta? Métricas: fidelidad/faithfulness y relevancia.

Para medir necesitas un conjunto de evaluación: 30-100 preguntas reales con su respuesta/fuente esperada. Con eso corres la evaluación antes y después de cada cambio (otro modelo de embeddings, otro tamaño de chunk, añadir reranking) y sabes si mejoras o empeoras. Sin ese conjunto, cada ajuste es a ciegas.

5. Errores típicos que vemos

• Culpar al modelo cuando falla la recuperación. El 80% de las "alucinaciones" en RAG son fragmentos mal recuperados, no el LLM.
• Chunking a ciegas. Cortar por longitud fija parte ideas a la mitad y arruina la recuperación.
• Solo búsqueda vectorial. Pierdes coincidencias literales (códigos, nombres exactos); el híbrido lo arregla.
• No reindexar al cambiar de embeddings. Mezclar vectores de modelos distintos da resultados incoherentes.
• Cero evaluación. Sin métricas, el sistema degrada en silencio cuando cambian los datos.

Preguntas frecuentes

Recursos relacionados

• IA en producción — coste, latencia y evaluación de LLMs.
• Automatizar atención al cliente sin romper el CRM — dónde encaja un asistente RAG.
• El stack que usamos en 2026 — Postgres + pgvector como base.

Publicado: 16 de julio de 2026 · Escrito por el estudio RoviDev.