RAG explicado: qué es y cómo se evalúa su calidad
El RAG conecta un modelo con tus fuentes para reducir alucinaciones. Qué es, cómo funciona y cómo medir si su calidad es buena de verdad.

RAG (Retrieval-Augmented Generation, o generación aumentada por recuperación) es una arquitectura que conecta un modelo de lenguaje a una base de conocimiento externa: en lugar de responder solo con lo que “recuerda” de su entrenamiento, el sistema primero busca documentos relevantes y después genera la respuesta apoyándose en ellos. Es la técnica más usada para que un asistente responda sobre información específica de una empresa —sus políticas, su catálogo, su documentación— sin reentrenar el modelo.
RAG es también la mejor defensa conocida contra las alucinaciones, porque ancla las respuestas en fuentes reales. Pero tiene una trampa: un sistema RAG puede fallar de dos maneras muy distintas, y si no sabes cuál de las dos te está pasando, vas a arreglar lo que no está roto. Entender cómo evaluarlo empieza por entender que no es un componente, sino dos.
La anatomía: dos componentes que fallan distinto
Todo sistema RAG tiene dos partes, y conviene pensarlas por separado:[1]
- El recuperador (retriever). Recibe la pregunta del usuario y busca, en la base de conocimiento, los fragmentos de documento más relevantes. Su trabajo es traer la evidencia correcta.
- El generador (generator). Toma esos fragmentos y la pregunta, y redacta la respuesta final. Su trabajo es usar bien la evidencia que recibió.
La clave para evaluar RAG es esta: una respuesta mala puede venir de cualquiera de los dos, y se arreglan de forma opuesta. Si el recuperador trajo el documento equivocado, no importa qué tan bueno sea el generador: va a producir una respuesta fluida basada en información irrelevante. Si el recuperador trajo el documento correcto pero el generador lo ignoró o lo tergiversó, el problema está del otro lado. Un puntaje de calidad de extremo a extremo te dice que algo falló, no cuál de los dos.[2] Por eso la evaluación de RAG mide cada componente por separado.
Cómo se evalúa el recuperador
Acá la pregunta es: ¿trajo la evidencia correcta? Las métricas estándar vienen del mundo de la recuperación de información:[3]
- Context precision (precisión del contexto): de los fragmentos que trajo, ¿qué proporción es realmente relevante? Precisión baja significa que está metiendo ruido, lo que diluye la respuesta y hace que el generador gaste atención en información irrelevante.
- Context recall (exhaustividad del contexto): de toda la información relevante que existía, ¿cuánta logró recuperar? Recall bajo significa que se le escapó evidencia que necesitaba.
Hay métricas más finas (MRR, nDCG, que además miran si los documentos correctos quedaron bien rankeados), pero precision y recall del contexto son el punto de partida.[3:1]
Cómo se evalúa el generador
Acá la pregunta cambia: dado el contexto que recibió, ¿lo usó bien? Las dos métricas centrales:[4]
- Faithfulness (fidelidad): ¿la respuesta es consistente con el contexto recuperado, o agrega cosas que no estaban? Esta es la métrica de RAG: mide si el generador se ciñó a la evidencia o si “inventó” por encima de ella. Una respuesta puede ser correcta en el mundo real pero infiel al contexto —y eso, en un sistema que debe responder solo desde fuentes aprobadas, también es un problema.
- Answer relevancy (relevancia de la respuesta): ¿la respuesta efectivamente contesta la pregunta que se hizo, sin irse por las ramas?
Algunos frameworks combinan estas cuatro métricas —context precision, context recall, faithfulness y answer relevancy— en un puntaje único que resume la salud del pipeline.[5]
Por qué las métricas viejas no alcanzan
Si vienes del mundo del NLP clásico, podrías pensar en usar métricas como BLEU o ROUGE, que comparan la respuesta generada contra una respuesta de referencia. No alcanzan: fueron diseñadas para tareas de generación pura y miden solapamiento de palabras, no si la respuesta está fundamentada en el contexto recuperado ni si el recuperador hizo bien su trabajo.[6] Evaluar RAG requiere métricas pensadas para su arquitectura híbrida —y, en buena parte, jueces de IA (LLM-as-a-judge) que pueden valorar la fidelidad y la relevancia con el matiz que una comparación de strings no capta.[7]
Un detalle que importa en producción
Dos advertencias prácticas. La primera: la evaluación de RAG no es un evento único. En producción hay que evaluarlo de forma continua —porque la base de conocimiento cambia, los documentos se actualizan y el comportamiento puede derivar— mediante monitoreo y, cuando se puede, pruebas A/B.[3:2] La segunda: para los enterprise, los errores de RAG no son cosméticos. En un sistema que responde sobre políticas, contratos o normativa, un fallo de recuperación o de fidelidad puede significar una falla de cumplimiento, daño reputacional o exposición legal.[3:3] No es lo mismo que un chatbot se equivoque sobre el clima que sobre una cláusula contractual.
Cómo lo resuelve ArtificialQA
Medir todo esto —separando recuperador de generador, sobre casos representativos y de forma continua— es lo que distingue saber que tu RAG falla de saber por qué. ArtificialQA conecta a tu sistema —por URL o por API, sin escribir código— y lo evalúa en las dimensiones que importan: adherencia al contexto y a los documentos (la fidelidad que es el corazón de RAG), relevancia, precisión y alucinaciones. Y como calibra a sus propios jueces de IA, los puntajes de fidelidad y relevancia —que dependen de un juez— resisten el escrutinio en lugar de ser una cifra opaca.
Para un equipo que construyó un asistente sobre su propia documentación, eso significa poder responder la pregunta que de verdad importa: cuando el sistema se equivoca, ¿es que no encontró la información, o que la encontró y la usó mal? Saber la diferencia es la mitad del arreglo.
Preguntas frecuentes
¿Qué es RAG en inteligencia artificial? Es una arquitectura (Retrieval-Augmented Generation) que conecta un modelo de lenguaje a una base de conocimiento externa: el sistema busca documentos relevantes y genera la respuesta apoyándose en ellos, en lugar de responder solo desde su entrenamiento.
¿Por qué se usa RAG? Para que un asistente responda sobre información específica (políticas, catálogos, documentación de una empresa) sin reentrenar el modelo, y para reducir alucinaciones anclando las respuestas en fuentes reales.
¿Cuáles son las métricas para evaluar un sistema RAG? Del lado del recuperador: context precision y context recall (y métricas de ranking como MRR o nDCG). Del lado del generador: faithfulness (fidelidad al contexto) y answer relevancy. La fidelidad es la métrica central de RAG.
¿Por qué hay que evaluar el recuperador y el generador por separado? Porque una respuesta mala puede venir de cualquiera de los dos y se arreglan de forma opuesta: si el recuperador trajo el documento equivocado, el problema es de recuperación; si lo trajo bien pero el generador lo ignoró, el problema es de generación. Un puntaje de extremo a extremo no distingue cuál falló.
¿Sirven BLEU o ROUGE para evaluar RAG? No alcanzan. Fueron diseñadas para generación pura y miden solapamiento de palabras, no la fidelidad al contexto recuperado ni la calidad de la recuperación. RAG necesita métricas propias, a menudo basadas en jueces de IA.
Licenciado en Sistemas de la Universidad ORT Uruguay y QA Manager en QAlified, con más de 13 años de experiencia en testing funcional, automatización, performance y seguridad. Ha dictado cursos y brindado consultoría a organizaciones y fundaciones de la región. Cofundador de TestingChannelTV y miembro del Katalon Creator Program. Actualmente enfocado en inteligencia artificial aplicada al testing.



