Evaluación de la generación aumentada por recuperación (RAG): todo lo que deberías saber
Introducción
Retrieval Augmented Generation (RAG) se ha convertido en un enfoque ampliamente adoptado para implementar aplicaciones de IA generativa impulsadas por Large Language Models (LLMs). Al integrar fuentes de conocimiento externas, RAG mejora la capacidad del modelo para proporcionar respuestas más precisas y contextualmente relevantes a consultas específicas. A pesar de su potencial, las respuestas generadas por RAG no siempre son completamente precisas o coherentes con el conocimiento recuperado.
En un seminario web reciente, Stefan Webb, Developer Advocate en Zilliz, exploró estrategias de evaluación para aplicaciones RAG, centrándose en métodos para evaluar el rendimiento de los LLM y abordando los desafíos y limitaciones actuales en el campo.
En este blog, recapitularemos las ideas clave de Stefan, incluida una visión general de varias arquitecturas de pipelines RAG, marcos de recuperación y evaluación, y ejemplos de sesgos y fallos en los LLM.
Arquitectura RAG
Stefan comenzó la charla presentando el concepto fundamental de búsqueda semántica, un componente crítico de las aplicaciones RAG. La búsqueda semántica aprovecha las bases de datos vectoriales, como Milvus o Zilliz, como sistemas de almacenamiento de bases de conocimiento para embeddings vectoriales. Estas bases de datos permiten búsquedas eficientes sobre datos no estructurados para recuperar contextos semánticamente similares relevantes para la consulta de un usuario. Esta capacidad constituye la columna vertebral de los sistemas RAG, asegurando que el conocimiento recuperado se alinee estrechamente con la pregunta de entrada, mejorando así la calidad de las respuestas generadas.
La Figura 1 a continuación ilustra una arquitectura RAG básica e ingenua. En esta configuración, el sistema recupera los documentos más relevantes en función de su similitud semántica con la pregunta del usuario. La información recuperada se formatea luego en un prompt estructurado, completo con instrucciones, y se pasa al LLM. El modelo utiliza este contexto para generar una respuesta bien informada.
Figura 1: RAG ingenuo
Figura 1: RAG ingenuo
Si bien el pipeline RAG básico puede recuperar documentos relevantes y generar respuestas, su rendimiento no siempre es óptimo. Algunas salidas pueden carecer de precisión o relevancia. Para abordar estos desafíos, un enfoque modular para construir el pipeline RAG permite mejoras incrementales en cada etapa.
A continuación (como se ilustra en la Figura 2) se presentan técnicas clave que pueden mejorar la eficacia del pipeline.
Figura 2: Arquitectura modular RAG
Figura 2: Arquitectura modular RAG (Fuente)
Traducción de consultas
Este paso se centra en garantizar que la consulta del usuario sea comprendida correctamente por el sistema. Traduce las consultas a un formato o representación que se alinea con el mecanismo de recuperación subyacente.
Multi-query: Divide la consulta principal en múltiples subconsultas enfocadas para recuperar información diversa pero relevante.
Step-back: Revisa pasos anteriores en el pipeline cuando se encuentran resultados insuficientes, refinando la consulta para una mejor recuperación.
RAG Fusion: Fusiona resultados de múltiples consultas para proporcionar un contexto cohesivo y completo para el LLM.
Documentos hipotéticos (HyDE): Implica generar documentos sintéticos o contextos hipotéticos que pueden ayudar a recuperar documentos semánticamente similares de la base de conocimiento, mejorando la recuperación para consultas abstractas o mal planteadas.
Enrutamiento de consultas
El enfoque de Enrutamiento de consultas dirige la consulta al mecanismo de recuperación o fuente de conocimiento más adecuado.
Enrutamiento lógico: Enruta consultas basándose en reglas predefinidas u operadores lógicos, como el filtrado por metadatos o dominio.
Enrutamiento semántico: Dirige consultas basándose en sus características semánticas a la base de datos o sistema más adecuado para manejarlas.
Construcción de consultas
La Construcción de consultas refina cómo se formulan las consultas para coincidir con la estructura de las bases de datos subyacentes.
BD relacional: Construye consultas similares a SQL para bases de datos relacionales tradicionales.
BD de grafos: Usa consultas Cypher de recorrido de grafos para explorar nodos y relaciones en bases de datos de grafos.
BD vectorial: Aprovecha embeddings para crear consultas vectorizadas para búsquedas de similitud semántica.
Indexación
La indexación mejora la organización y accesibilidad de la base de conocimiento.
Optimización de chunks: Divide documentos en chunks significativos y recuperables, preservando el contexto.
Indexación de múltiples representaciones: Crea múltiples representaciones (p. ej., semántica, sintáctica) de datos para diversas necesidades de recuperación.
Embeddings especializados: Usa embeddings específicos del dominio para mejorar la recuperación de información altamente especializada o técnica.
Indexación jerárquica: Estructura el índice jerárquicamente para búsquedas más rápidas y precisas.
Recuperación
Recupera los documentos o contextos más relevantes para una consulta dada utilizando técnicas avanzadas.
Ranking: Puntúa los documentos recuperados según su relevancia, garantizando que se prioricen las mejores coincidencias.
RAG correctivo: Ajusta el ranking basándose en comentarios o criterios adicionales para mejorar dinámicamente los resultados.
Re-recuperación: Recupera documentos iterativamente si los resultados iniciales no cumplen las expectativas de calidad, refinando el proceso hasta encontrar un resultado aceptable.
Este enfoque modular para construir un pipeline RAG ajusta cada componente de forma independiente. Al abordar desafíos específicos en cada etapa, el pipeline se vuelve más robusto, preciso y adaptable, mejorando en última instancia la calidad de los resultados generados.
Evaluación de modelos fundacionales
Ya sea que se use un enfoque RAG ingenuo o avanzado, evaluar el rendimiento de cada aplicación RAG es esencial. Esta evaluación ayuda a identificar fortalezas y debilidades, garantizando la fiabilidad y relevancia del sistema. Todos los LLM, independientemente de su sofisticación, requieren una evaluación rigurosa del rendimiento para abordar posibles limitaciones, sesgos e inexactitudes.
Evaluación del rendimiento
Pero ¿cómo medimos y evaluamos el rendimiento del modelo? Medir el rendimiento de una aplicación RAG requiere un enfoque matizado, ya que deben evaluarse diferentes aspectos del pipeline. A continuación se presentan consideraciones y métodos clave para una medición eficaz del rendimiento:
Evaluación en una tarea vs. evaluación sobre sí mismo
Evaluación de tareas: Mide el rendimiento del modelo en un conjunto predefinido de tareas, que a menudo incluyen escenarios de múltiples turnos (p. ej., MT-Bench) o multitarea (p. ej., MMLU). Cada tarea está asociada con preguntas de verdad fundamental específicas y respuestas de referencia.
Autoevaluación: Se centra en métricas internas de rendimiento, como qué tan eficazmente el modelo recupera y procesa información sin vincularlo necesariamente a un caso de uso práctico. Esto es útil para diagnosticar el rendimiento del pipeline.
Comparación de respuestas con la verdad fundamental vs. contexto
Comparación con la verdad fundamental: Evalúa qué tan estrechamente la respuesta generada coincide con una respuesta predefinida y precisa (verdad fundamental). Este enfoque funciona bien para tareas objetivas como consultas basadas en hechos.
Comparación contextual: Examina qué tan bien la respuesta se alinea con el contexto proporcionado por los documentos recuperados. Esto es particularmente importante para tareas en las que la verdad fundamental no está disponible o es subjetiva, enfatizando la coherencia y la relevancia.
Evaluación de la recuperación vs. evaluación de la salida del LLM
Evaluación de la recuperación: Se centra en la calidad de los documentos recuperados por el pipeline. Las métricas podrían incluir recall y precision entre los documentos recuperados y la consulta.
Evaluación de la salida del LLM: Examina la calidad de la salida final generada por el modelo de lenguaje, considerando factores como la consistencia factual y la relevancia para la consulta y el contexto recuperado.
Evaluación humana como el “estándar de oro”
- La evaluación humana sigue siendo el método más fiable para evaluar el rendimiento, especialmente para tareas subjetivas o complejas. Los humanos pueden evaluar aspectos matizados como la consistencia lógica, el tono y la creatividad. Sin embargo, este enfoque no escala bien debido a sus requisitos de tiempo y recursos.
Uso de LLMs para evaluar LLMs (LLM-as-a-Judge)
- Se pueden emplear LLMs más avanzados y eficientes (LLM-as-a-Judge) para evaluar las salidas de otros LLMs, particularmente cuando la verdad fundamental no está disponible. Estos modelos pueden puntuar respuestas según criterios predefinidos como la relevancia y la corrección, ofreciendo una alternativa escalable a la evaluación humana. Sin embargo, se debe tener cuidado para evitar introducir sesgos del propio modelo evaluador.
Stefan continuó la discusión abordando dos enfoques de evaluación: evaluación basada en tareas y autoevaluación. La evaluación basada en tareas suele depender de benchmarks disponibles públicamente, mientras que la autoevaluación se centra más en medidas internas o introspección, como examinar la calidad de las respuestas generadas y la relevancia de la información recuperada.
Evaluación basada en tareas: el enfoque de benchmarks
La evaluación basada en tareas se basa en utilizar benchmarks estándar disponibles públicamente que evalúan el rendimiento del modelo en una variedad de tareas. Estos benchmarks a menudo cubren diferentes dominios de conocimiento, capacidades de respuesta a preguntas y habilidades conversacionales. Algunos ejemplos incluyen:
Benchmarks basados en conocimiento: Estos benchmarks se centran en el conocimiento general y la respuesta a preguntas basadas en hechos.
MMLU: Un benchmark diverso que prueba modelos de lenguaje en múltiples dominios, incluidos matemáticas, ciencia e historia.
HellaSwag: Un benchmark diseñado para medir el razonamiento de sentido común.
ARC: Un benchmark centrado en la respuesta a preguntas con capacidades de razonamiento.
Benchmarks de seguimiento de instrucciones: Estos benchmarks evalúan la capacidad del modelo para seguir instrucciones y generar respuestas relevantes.
Flan: Una serie de tareas que evalúan las capacidades de seguimiento de instrucciones en LLMs.
Self-instruct: Evalúa la capacidad del modelo para generar y seguir instrucciones autogeneradas.
NaturalInstructions: Un benchmark a gran escala centrado en la capacidad del modelo para seguir instrucciones en lenguaje natural.
Benchmarks conversacionales: Estos benchmarks evalúan la capacidad del modelo para participar en un diálogo coherente y relevante.
CoQA: Un conjunto de datos de respuesta a preguntas conversacional que prueba modelos en diálogos de múltiples turnos.
MMDialog: Un benchmark conversacional que se centra en la calidad del diálogo en diversos escenarios.
OpenAssistant: Un benchmark de IA conversacional que evalúa la capacidad del modelo para mantener conversaciones naturales.
Si bien los benchmarks proporcionan criterios de evaluación estandarizados, a menudo no logran captar los matices de la interacción humana, como la inteligencia emocional, el flujo conversacional y la sensibilidad al contexto. Por ejemplo, una respuesta podría ser factualmente correcta según un benchmark, pero aun así quedarse corta en términos de naturalidad o empatía, elementos clave que los humanos valoran en conversaciones del mundo real. Además, los benchmarks no siempre reflejan la complejidad de las preferencias humanas, que pueden variar según el contexto, la intención del usuario y el tono emocional. Por eso la evaluación humana sigue siendo un "estándar de oro" para evaluar la IA conversacional, ya que tiene en cuenta preferencias humanas que los benchmarks a menudo pasan por alto. Sin embargo, debido al costo y a la naturaleza intensiva en recursos de la evaluación humana, pueden considerarse métodos alternativos, como la evaluación basada en introspección, como opciones más escalables.
Evaluación basada en introspección
La evaluación basada en introspección se centra en evaluar la calidad de las respuestas generadas por el modelo y su alineación con el contexto, con el objetivo de medir qué tan bien las salidas del modelo se ajustan a las expectativas establecidas por la entrada. Este tipo de evaluación puede dividirse en dos categorías principales: Evaluación basada en generación y Evaluación basada en recuperación. A continuación se muestran algunos ejemplos de métricas relevantes:
Evaluación basada en generación
Fidelidad (Fundamentación): Esta métrica mide la consistencia factual de la respuesta generada frente al contexto dado. Si el modelo genera afirmaciones que no pueden ser respaldadas por el contexto recuperado, esas afirmaciones son penalizadas. La fidelidad garantiza que la salida del modelo sea tanto consistente como fundamentada en la información proporcionada.
Relevancia de la respuesta: Esta métrica evalúa qué tan bien la respuesta aborda directamente la pregunta del usuario o el contexto dado. Una respuesta altamente relevante será tanto precisa como contextualmente apropiada, proporcionando la respuesta más útil a la consulta.
Evaluación basada en recuperación
Relevancia del contexto: Mide qué tan relevantes son los documentos o contextos recuperados para la consulta. Idealmente, el contexto recuperado debería contener solo la información necesaria para responder la pregunta. La información irrelevante o superflua puede reducir la calidad de la respuesta generada.
Recuperación del contexto: Esta métrica evalúa qué tan bien se alinea el contexto recuperado con la verdad de referencia, a menudo usando respuestas anotadas como referencia. Ayuda a evaluar si los documentos relevantes fueron recuperados en primer lugar, asegurando que el modelo tenga suficiente información para generar una respuesta significativa.
Para las métricas de Fidelidad, Relevancia de la respuesta y Relevancia del contexto, la falta de verdad de referencia presenta un desafío para la evaluación directa. Sin embargo, en ausencia de verdad de referencia, un método alternativo es emplear un LLM como juez. Un LLM sólido puede utilizarse para puntuar estos aspectos analizando la coherencia, la relevancia y la fundamentación factual de la respuesta. Al comparar las respuestas generadas con su propia comprensión del contexto y la relevancia, el modelo puede proporcionar una evaluación automatizada.
Desafíos y limitaciones de LLM como juez
Si bien usar un LLM como juez puede ser una alternativa útil para evaluar métricas cuando no hay verdad de referencia disponible, este enfoque introduce ciertos desafíos y limitaciones que deben abordarse. El propio modelo evaluador puede introducir sesgos, lo que puede afectar la calidad y la equidad de la evaluación. A continuación se presentan algunos sesgos y desafíos comunes que deben considerarse.
Sesgo de posición
El sesgo de posición se refiere a la tendencia del modelo evaluador a favorecer respuestas en función de su posición en la clasificación o del orden en que aparecen. En muchos casos, el modelo puede asumir que la primera respuesta o la mejor clasificada es más relevante o precisa, independientemente de su calidad real. Esto puede conducir a evaluaciones inexactas, especialmente en casos en los que la respuesta correcta está clasificada más abajo debido al sesgo del modelo hacia las posiciones mejor clasificadas.
Figura 3: Sesgo de posición
Figura 3: Sesgo de posición (Fuente)
Sesgo de verbosidad
El sesgo de verbosidad ocurre cuando el modelo evaluador tiende a favorecer respuestas más largas y detalladas, incluso si no son necesariamente más precisas o relevantes. En algunos casos, el modelo puede equiparar incorrectamente la verbosidad con la calidad, asignando puntuaciones más altas a respuestas más largas que contienen información innecesaria. Esto puede distorsionar el proceso de evaluación, especialmente en contextos donde son más deseables respuestas concisas y claras.
Figura 4: Sesgo de verbosidad
Figura 4: Sesgo de verbosidad (Fuente)
Juicio erróneo
Otra limitación es la posibilidad de juicios erróneos. Un LLM-as-a-Judge, como cualquier modelo, puede cometer errores al evaluar la calidad o relevancia de una respuesta. Por ejemplo, puede malinterpretar el contexto, pasar por alto detalles sutiles o no reconocer matices en la respuesta, lo que conduce a resultados de evaluación incorrectos o engañosos
Figura 5: Juicio erróneo
Figura 5: Juicio erróneo (Fuente)
Juicio erróneo con Chain-of-Thought
El razonamiento Chain-of-Thought (CoT) en la evaluación basada en LLM introduce mecanismos complejos de propagación de errores que pueden comprometer significativamente la precisión de la evaluación. Cada paso intermedio de razonamiento actúa como un posible punto de fallo, donde incluso una interpretación errónea menor o una inconsistencia lógica puede propagarse en cascada hasta convertirse en errores cada vez más sustanciales en el juicio final. Por ejemplo, si un paso temprano en la cadena de razonamiento malinterpreta un matiz contextual clave o pondera incorrectamente un aspecto particular de la respuesta, los pasos de razonamiento posteriores se construirán sobre esta base defectuosa, amplificando exponencialmente el error inicial.
Figura 6: Juicio erróneo con Chain-of-thought
Figura 6: Juicio erróneo con Chain-of-thought (Fuente)
Estos sesgos resaltan la importancia de adoptar estrategias de evaluación que aborden las limitaciones de los enfoques LLM-as-a-Judge. Una solución es utilizar modelos LLM específicamente ajustados para fines de evaluación, como GroundedAI, o Flow-Judge-v0.1. Otra estrategia es combinar las evaluaciones LLM-as-a-Judge con evaluaciones humanas siempre que sea posible. Los evaluadores humanos aportan una comprensión matizada y conciencia contextual que los modelos automatizados pueden carecer. Las auditorías periódicas y las mejoras iterativas de los modelos evaluadores también son esenciales para minimizar los sesgos y mejorar la fiabilidad.
Marcos de evaluación de código abierto
Además de las técnicas LLM-as-a-Judge, varios marcos de evaluación de código abierto se utilizan ampliamente en el mercado para evaluar aplicaciones RAG. Estos marcos proporcionan metodologías estructuradas y herramientas para evaluar eficazmente el rendimiento de recuperación y generación:
RAGAS: Un marco para evaluar sistemas RAG con métricas adaptadas a aplicaciones RAG.
DeepEval: Una herramienta flexible y robusta para evaluar sistemas RAG o de ajuste fino en múltiples métricas de evaluación.
ARES: Diseñado para la evaluación de modelos RAG, con énfasis en la relevancia del contexto, la fidelidad de la respuesta y la relevancia de la respuesta.
HuggingFace Lighteval: Proporciona herramientas ligeras y extensibles para evaluar aplicaciones RAG en múltiples backends (por ejemplo, transformers, tgi, vllm o nanotron).
Estos frameworks simplifican el proceso de evaluación y ayudan a estandarizar las métricas de rendimiento entre diferentes sistemas, fomentando la comparabilidad y la mejora.
Conclusión
La Generación Aumentada por Recuperación (RAG) es un enfoque transformador para mejorar las capacidades de los Modelos de Lenguaje Grandes (LLMs). Sin embargo, su éxito depende de una evaluación robusta y un refinamiento continuo. Como destacó Stefan en el webinar, el pipeline de RAG es complejo y abarca múltiples etapas, desde la traducción de consultas hasta la generación de la respuesta final. Los desafíos son significativos: van desde mitigar sesgos en las evaluaciones LLM-as-a-Judge hasta garantizar una recuperación precisa y generar respuestas que cumplan con las expectativas del usuario.
La conclusión clave es que no existe una solución única para la evaluación de RAG. Lograr el éxito requiere un enfoque matizado y multifacético que combine diversas técnicas de evaluación: benchmarks basados en tareas, métricas introspectivas, frameworks de evaluación de código abierto y, cuando sea factible, evaluación humana. Herramientas como RAGAS, DeepEval y ARES ofrecen un apoyo valioso, pero no son respuestas definitivas. En cambio, representan herramientas en evolución dentro del panorama en constante avance de la IA generativa.
De cara al futuro, el futuro de RAG reside en su adaptabilidad y refinamiento continuo. A medida que los sistemas de IA se vuelven más sofisticados, la capacidad de evaluar y mejorar su rendimiento será esencial para desbloquear todo su potencial. Al abordar las limitaciones actuales y adoptar métodos de evaluación innovadores, las aplicaciones RAG pueden ofrecer de forma constante información precisa, contextualmente relevante y confiable, impulsando el progreso en el campo de la IA.
Lecturas adicionales
Sigue leyendo
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.