Agentes IA 9 min de lectura22 de abril de 2026

RAG en producción: arquitectura, evaluación y errores comunes

La generación aumentada por recuperación (RAG) es el patrón estándar para conectar LLMs a tu conocimiento. Cómo diseñarla, cómo evaluarla con rigor y qué errores evitar.

Diagrama abstracto de un pipeline de generación aumentada por recuperación

En resumen

RAG (Retrieval-Augmented Generation) conecta un LLM a tu base de conocimiento: recupera fragmentos relevantes y los usa como contexto para responder. Funciona bien cuando la recuperación es buena y se evalúa con métricas separadas para recuperación y generación. La mayoría de fallos de RAG son fallos de recuperación disfrazados de fallos del modelo.

¿Cómo funciona RAG?

1Indexación: divides tus documentos en fragmentos (chunks), generas embeddings y los guardas en una base vectorial.
2Recuperación: ante una pregunta, buscas los fragmentos más relevantes (por similitud vectorial, a menudo combinada con búsqueda léxica).
3Generación: pasas esos fragmentos como contexto al LLM para que responda fundamentado en ellos, idealmente citando la fuente.

La promesa es doble: respuestas actualizadas sin reentrenar el modelo y respuestas trazables a documentos concretos. Pero cada etapa puede romperse.

¿Por qué falla RAG en producción?

Fragmentación pobre: chunks demasiado grandes o que cortan ideas a la mitad degradan la recuperación.
Recuperación por solo similitud: la búsqueda vectorial pura pierde coincidencias exactas; combinarla con búsqueda léxica (híbrida) suele mejorar mucho.
Contexto irrelevante: si recuperas fragmentos ruidosos, el modelo se confunde — más contexto no es mejor contexto.
Falta de citación: sin obligar a citar fuentes, pierdes la trazabilidad que justificaba usar RAG.
Datos vectoriales mal gobernados: OWASP recoge las debilidades de vectores y embeddings como un riesgo propio de los sistemas con IA.

¿Cómo se evalúa RAG con rigor?

El error más común es evaluar «a ojo». RAG se mide separando las dos etapas, porque un buen modelo no compensa una mala recuperación:

Etapa	Qué mides	Ejemplos de métrica
Recuperación	¿Trajiste los fragmentos correctos?	Precision@k, Recall@k, MRR
Generación	¿La respuesta se basa en el contexto?	Fidelidad (faithfulness), relevancia
Extremo a extremo	¿Responde a la pregunta del usuario?	Correctitud, utilidad

Frameworks como el cookbook de OpenAI con LlamaIndex o las herramientas de evaluación de LangSmith permiten construir conjuntos de prueba y medir estas dimensiones de forma sistemática, incluso usando un LLM como evaluador (LLM-as-judge) con criterios bien definidos.

Puntos clave

La mayoría de fallos de RAG son fallos de recuperación, no del modelo.
Usa recuperación híbrida (vectorial + léxica) y una buena estrategia de chunking.
Evalúa recuperación y generación por separado, con métricas, no a ojo.
Exige citación de fuentes para conservar la trazabilidad.

¿RAG o fine-tuning?

Son complementarios. RAG aporta conocimiento actualizado y trazable sin reentrenar; el fine-tuning ajusta el estilo o el comportamiento del modelo. Para conocimiento que cambia, empieza por RAG.

¿Necesito una base de datos vectorial dedicada?

No siempre. A volúmenes moderados, extensiones vectoriales sobre tu base existente bastan. La base dedicada aporta valor a gran escala o con requisitos de latencia estrictos.

RAG suele ser una herramienta dentro de un agente con controles y trazabilidad; evaluarla bien es parte de operar IA con seriedad.