Cómo construir RAG confiable: Una inmersión profunda en 7 puntos de fallo y marcos de evaluación

Generación aumentada de 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 una inmersión profunda en 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 la descomposición de RAG – 7 puntos de fallo (FP)

Según los investigadores Barnett et al., los sistemas de Generación aumentada de recuperación (RAG) encuentran siete puntos de fallo 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 cada FP organizados según la secuencia de la canalización, siguiendo la progresión de arriba a abajo mostrada en la Figura A.

FP1. Contenido faltante

El contenido faltante ocurre cuando el sistema se le hace una pregunta que no puede responder porque la información relevante no está presente en la tienda de vectores disponible en primer lugar.

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 la tienda de vectores, pero el recuperador no logra clasificarlo lo suficientemente alto como para incluirlo en los documentos superior-k que se alimentan 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 de la tienda de vectores, 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 velocidad.

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 la tienda de vectores 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 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 falta piezas clave de información que estaban disponibles 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 la información faltante o incorrecta está presente, 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 en primer lugar.
• 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, faltando piezas importantes.

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 embebido no selecciona los embebidos superior-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 el paso 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 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 Action 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 – fallando inmediatamente la compilación de CI, 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 la mayoría de las consultas de usuario importantes 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

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 insignia:

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

Las métricas insignia se clasifican en tres grupos:

• Canalización de recuperación (línea negra, sólida, Figura B): Precisión del contexto, recuperación del contexto.
• Canalización de generación (línea negra, discontinua, Figura B): Fidelidad, relevancia de la respuesta.
• Verdad fundamental (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 falta cláusulas clave. No estás seguro de si el problema está en la Búsqueda (Recuperador) o en la Lectura (Generador).
• Problema: No tienes idea del número óptimo de superior-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 recuperación 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.
• Solución: Utiliza TruLens para implementar una función de retroalimentación de fundamentación con un umbral como puntuación > 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 fallo silencioso

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 embebidos, utilizando Aproximación de proyección de manifold uniforme (UMAP) para reducir embebidos de vectores de alta dimensión a espacio 2D/3D.

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

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: Agujero de datos en la base de vectores (No se puede encontrar en los registros).
• Solución: Utiliza Arize Phoenix para generar una visualización de embebidos UMAP (UEV), un mapa 3D para la base de vectores – para superponer consultas de usuario en los fragmentos de documentos.
• Resultados esperados: Visualmente ver un cluster de consultas de usuario que aterrizan en la zona oscura donde no existen documentos, indicando que algunos documentos se olvidaron subir a la tienda de vectores.

Braintrust – La red de seguridad de regresión de la solicitud

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 dorados 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 qué casos mejoraron o empeoraron para cada uno del conjunto de datos dorados (N = 50).

Resumen

Cuando se maneja con marcos de evaluación adecuados, RAG puede ser una herramienta competitiva para proporcionar un contexto de modelo de lenguaje grande 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 del contexto / recuperación 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 verdad fundamental.