Cómo crear RAG fiable: análisis de siete puntos de fallo y marcos de evaluación

Generación aumentada por recuperación (RAG) es fundamental para la arquitectura de inteligencia artificial moderna, ya que sirve como un marco esencial para la creación de agentes conscientes del contexto.

Pero pasar de un prototipo básico a un sistema listo para producción implica superar obstáculos significativos en la recuperación de datos, la consolidación del contexto y la síntesis de respuestas.

Este artículo ofrece un análisis en profundidad de siete puntos de fallo típicos de RAG y las métricas de evaluación con ejemplos de codificación prácticos.

La anatomía de los fallos de RAG – 7 puntos de fallo (FP)

Según los investigadores Barnett y sus colaboradores, los sistemas de Generación aumentada por recuperación (RAG) encuentran siete puntos de fallo (FP) específicos a lo largo de la canalización.

El diagrama a continuación ilustra estas etapas:

Figura A. Procesos de indexación y consulta necesarios para crear un sistema RAG. El proceso de indexación se realiza en el momento del desarrollo y las consultas en tiempo de ejecución. Los puntos de fallo identificados en este estudio se muestran en cuadros rojos (fuente)

Exploraremos los FP organizados según la secuencia de la canalización, siguiendo la progresión desde la esquina superior izquierda hasta la inferior derecha mostrada en la Figura A.

FP1. Contenido faltante

El contenido falta cuando se plantea al sistema una pregunta que no puede responder porque la información pertinente no existe desde el principio en el almacén vectorial disponible.

El fallo ocurre cuando un modelo de lenguaje grande proporciona una respuesta que suena plausible pero es incorrecta en lugar de decir no lo sé.

FP2. Perdido en la clasificación

Esta es una situación en la que un documento correcto existe en el almacén vectorial, pero el recuperador no logra clasificarlo lo suficientemente alto como para incluirlo en los documentos top-k que se proporcionan a un modelo de lenguaje grande como contexto.

En consecuencia, la información correcta nunca llega al modelo de lenguaje grande.

FP3. No en contexto (Limitaciones de la estrategia de consolidación)

Esta es una situación en la que un documento correcto existe y se recupera del almacén vectorial, pero se excluye durante el proceso de consolidación.

Esto ocurre cuando demasiados documentos se devuelven y el sistema debe filtrarlos para que quepan dentro de la ventana de contexto de un modelo de lenguaje grande, los límites de tokens o los límites de frecuencia de solicitudes.

FP4. No extraído

Esta es una situación en la que un modelo de lenguaje grande no logra identificar la información correcta en el contexto, incluso aunque la información correcta estuviera en el almacén vectorial y se recuperara y consolidara con éxito.

Esto ocurre cuando el contexto es demasiado ruidoso o contiene información contradictoria que confunde al modelo de lenguaje grande.

FP5. Formato incorrecto

Esta es una situación en la que el almacenamiento, la recuperación, la consolidación y la interpretación del modelo de lenguaje grande se manejan con éxito, pero el modelo de lenguaje grande no sigue las instrucciones de formato específicas proporcionadas en la solicitud, como una tabla, una lista con viñetas o un esquema JSON.

FP6. Especificidad incorrecta

La salida del modelo de lenguaje grande está técnicamente presente, pero es demasiado general o demasiado compleja en comparación con las necesidades del usuario.

Por ejemplo, un modelo de lenguaje grande genera respuestas simples a una consulta del usuario con un objetivo profesional complejo.

FP7. Respuestas incompletas

Esta es una situación en la que un modelo de lenguaje grande genera una salida que no es necesariamente incorrecta, pero que omite información esencial que estaba disponible en el contexto.

Por ejemplo, cuando un usuario hace una pregunta compleja como “¿Cuáles son los puntos clave en los documentos A, B y C?”, el modelo de lenguaje grande solo aborda una o dos de las fuentes.

Cómo los FP comprometen el rendimiento de la canalización RAG

Cada uno de estos FP afecta el rendimiento de las canalizaciones RAG:

Fallas de integridad y confianza de los datos

Cuando falta información o es incorrecta, el sistema ya no es una fuente confiable de información. Los FP principales incluyen:

• FP1 (Contenido faltante): La respuesta no está en el documento desde el principio.
• FP4 (No extraído): El modelo de lenguaje grande decide ignorar la respuesta correcta en el documento.
• FP7 (Incompleto): El modelo de lenguaje grande proporciona medias verdades, omitiendo información importante.

Cuellos de botella de recuperación y eficiencia

La canalización RAG puede ser ineficiente cuando se pierde información clave en las etapas de recuperación y consolidación. Los FP principales incluyen:

• FP2 (Perdido en la clasificación): El modelo de embeddings no selecciona los embeddings top-k.
• FP3 (Estrategia de consolidación): El script para recortar documentos para que quepan dentro de los límites del modelo de lenguaje grande elimina las partes más importantes.

Errores de experiencia del usuario y formato

Aunque sea correcta, una salida con mala legibilidad o en un formato incorrecto puede comprometer la experiencia del usuario. Los FP principales incluyen:

• FP5 (Formato incorrecto): El modelo de lenguaje grande no sigue el formato de salida específico como JSON.
• FP6 (Especificidad incorrecta): El modelo de lenguaje grande genera una salida extensa para una pregunta sí/no simple, o viceversa (respuesta demasiado breve para una pregunta complicada).

La pila de evaluación: Marcos para mitigar los FP

Las métricas de evaluación están diseñadas para mitigar sistemáticamente estos FP.

Esta sección explora las principales métricas de evaluación RAG con casos de uso prácticos.

Principales métricas de evaluación RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – La prueba unitaria antes de la implementación

DeepEval calcula una puntuación ponderada basada en los criterios.

Un modelo de lenguaje grande como juez (por ejemplo, GPT-4o) evalúa cada criterio contra la salida del modelo de lenguaje grande:

DeepEval aprovecha G-eval, un marco de cadena de pensamiento (CoT) que adopta un enfoque de varios pasos para evaluar la salida:

1. Definir un criterio para medir (por ejemplo, “coherencia”, “fluidez” o “relevancia”).
2. Generar pasos de evaluación (utilizando un modelo de lenguaje grande evaluador).
3. Sigue los pasos de evaluación y analiza la entrada y la salida del modelo de lenguaje grande.
4. Calcula una suma ponderada esperada de la puntuación de cada criterio.

Escenario común en la práctica

• Situación: Un asistente de documentación técnica (bot) para un producto de software complejo parece funcionar cada vez que el equipo de ingenieros actualiza la base de código.
• Problema: No hay prueba cuantitativa de que el bot aún pueda responder a la consulta del usuario (solo “piensas” que funciona…).
• Solución: Integrar una función de PyTest como suite de regresión de CI/CD en GitHub Actions donde DeepEval ejecuta G-Eval y otras métricas sobre un caso de prueba:

• Resultados esperados: Si alguna puntuación de las métricas cae por debajo del umbral (0,85), PyTest genera AssertionError – haciendo que la compilación de CI falle de inmediato, evitando que la regresión silenciosa llegue a producción.

Nota del desarrollador – El caso de prueba para DeepEval
Un conjunto de objetos LLMTestCase define el caso de prueba que ejecuta DeepEval.

En la práctica, este caso de prueba debe contener las consultas más importantes de los usuarios y salidas etiquetadas con el contexto recuperado.

Estos se pueden recuperar de un archivo JSON o CSV.

RAGAS – El optimizador de la aguja en el pajar

Retrieval Augmented Generation Assessment (Ragas) se centra en evaluar RAG sin un conjunto de datos anotado por humanos generando conjuntos de prueba sintéticos.

Luego, calcula las métricas principales:

Figura B. El diagrama de la tríada de evaluación de RAGAS que conecta Pregunta, Contexto y Respuesta a través de métricas de Precisión, Exhaustividad, Fidelidad y Relevancia (Creado por Kuriko IWAI)

Las métricas principales se clasifican en tres grupos:

• Canalización de recuperación (línea negra, sólida, Figura B): Precisión del contexto, exhaustividad del contexto.
• Canalización de generación (línea negra, discontinua, Figura B): Fidelidad, relevancia de la respuesta.
• Datos de referencia (cuadro rojo, Figura B): Similitud semántica de la respuesta, corrección de la respuesta.

Escenario común en la práctica

• Situación: El sistema RAG para contratos legales omite cláusulas clave. No estás seguro de si el problema está en la Búsqueda (Recuperador) o en la Lectura (Generador).
• Problema: No conoces el valor óptimo de top-k (número de fragmentos recuperados).
• Solución: Utiliza RAGAS para crear un conjunto de prueba sintético con 100 pares de preguntas y evidencia. Luego, ejecuta la canalización RAG en el conjunto de prueba para calcular la precisión del contexto y la exhaustividad del contexto:
• Resultado esperado: Dependiendo de los resultados de las métricas, el plan de acción puede ser el siguiente:

Tabla 1. Matriz de diagnóstico de RAGAS – Asignación de puntuaciones a ajustes del sistema.

TruLens – El especialista en bucle de retroalimentación

TruLens se centra en la mecánica interna del proceso RAG en lugar de solo la salida final utilizando funciones de retroalimentación.

También utiliza una puntuación basada en un modelo de lenguaje grande que refleja qué tan bien la respuesta satisface la intención de la consulta, utilizando una escala Likert de 4 puntos (0-3), lo que la hace superior para clasificar la calidad de diferentes resultados de búsqueda.

Escenario común en la práctica

• Situación: Un bot asesor médico responde a una pregunta del usuario de manera correcta pero agrega un consejo que no está en la base de PDF verificada.
• Problema: El consejo adicional puede ser útil, pero no está fundamentado en esas fuentes.
• Solución: Utiliza TruLens para implementar una función de retroalimentación de fundamentación con un umbral como score > 0.8.

• Resultados esperados: Cuando el modelo de lenguaje grande genera una respuesta que contiene información no presente en los fragmentos recuperados, TruLens marca el registro en tu panel de control.

Arize Phoenix – El mapa de fallos

Arize Phoenix es una herramienta de observabilidad y evaluación de código abierto para evaluar salidas de modelos de lenguaje grande, incluidos sistemas RAG complejos.

Construido sobre OpenTelemetry por Arize AI, se centra en la observabilidad al tratar la evaluación de modelos de lenguaje grande como un subconjunto de MLOps.

En el contexto de la evaluación RAG, Phoenix sobresale en análisis de embeddings, utilizando Uniform Manifold Approximation and Projection (UMAP) para reducir embeddings vectoriales de alta dimensión a un espacio de dos o tres dimensiones.

Este análisis de embeddings revela matemáticamente si las consultas fallidas están agrupadas semánticamente, lo que indica una brecha en la base de datos vectorial.

Escenario común en la práctica

• Situación: Un bot de soporte al cliente funciona bien para reembolsos, pero proporciona respuestas sin sentido para reclamaciones de garantía.
• Problema: Laguna de datos en la base de datos vectorial (No se puede encontrar en los registros).
• Solución: Utiliza Arize Phoenix para generar una visualización de embeddings UMAP (UEV), un mapa 3D para la base de datos vectorial – para superponer consultas de usuario en los fragmentos de documentos.
• Resultados esperados: Se observa un grupo de consultas de usuarios en la zona oscura sin documentos, lo que indica que se olvidó cargar algunos documentos en el almacén vectorial.

Braintrust – La red de seguridad frente a regresiones del prompt

Braintrust está diseñado para ciclos de iteración de alta frecuencia utilizando comparación entre modelos.

Escenario común en la práctica

• Situación: Un equipo de ingenieros actualiza la solicitud de “Responde a la pregunta” (Caso A) a una instrucción del sistema más compleja de 500 palabras (Caso B).
• Problema: Mejorar la solicitud para el Caso B podría romper accidentalmente el Caso A.
• Solución: Utiliza Braintrust para crear un conjunto de datos de referencia con un conjunto de N ejemplos perfectos (por ejemplo, N = 50). Deja que Braintrust ejecute una comparación lado a lado (SxS) cada vez que el equipo actualiza una sola palabra en la solicitud:

• Resultado esperado: Un informe de diferencias que muestra exactamente cuáles de los N = 50 casos de referencia mejoraron o empeoraron.

Resumen

Con marcos de evaluación adecuados, RAG puede ser una herramienta competitiva para proporcionar al modelo de lenguaje grande el contexto más relevante para la consulta del usuario.

Estrategia de implementación: Asignación de métricas a puntos de fallo

Aunque no hay una solución que se adapte a todos, la Tabla 2 muestra qué métricas de evaluación aplicar para cada FP que cubrimos en este artículo:

Tabla 2. La matriz de mitigación de puntos de fallo – ¿Qué herramienta resuelve qué FP?

DeepEval y RAGAS pueden aprovechar sus métricas de fidelidad para medir fallos de integridad de datos (FP1, FP4, FP7).

TruLens aprovecha su precisión y exhaustividad del contexto para medir la relevancia del contexto para la salida – evaluando efectivamente FP2.

Arize Phoenix proporciona un rastro visual del proceso de recuperación, lo que facilita ver si el documento recuperado se perdió durante la consolidación (FP3).

Para fallos de UX, DeepEval crea métricas personalizadas para evaluar fallos de UX, mientras que Braintrust sobresale en la comparación de conjuntos de datos de referencia.