Líderes de opinión
Cómo construir un RAG confiable: Un análisis profundo de 7 puntos de fallo y marcos de evaluación
Generación aumentada con recuperación (RAG) es fundamental para la arquitectura de inteligencia artificial moderna, sirviendo como un marco esencial para la construcción de agentes conscientes del contexto.
Pero pasar de un prototipo básico a un sistema listo para producción implica navegar por obstáculos significativos en la recuperación de datos, la consolidación del contexto y la síntesis de respuestas.
Este artículo proporciona un análisis profundo de los 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 falla de RAG – 7 puntos de fallo (FP)
Según los investigadores Barnett et al., los sistemas de Generación aumentada con 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 cajas rojas (fuente)
Veamos cada FP dispuesto según la secuencia de la canalización, siguiendo la progresión de arriba a abajo izquierda a derecha mostrada en 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 el vector almacenado disponible en primer lugar.
La falla ocurre cuando un LLM proporciona una respuesta que suena plausible pero es incorrecta en lugar de decir no lo sé.
FP2. Perdió los documentos mejor clasificados
Esta es una situación en la que un documento correcto existe en el vector almacenado, pero el recuperador no puede clasificarlo lo suficientemente alto como para incluirlo en los documentos superior-k alimentados a un LLM como contexto.
En consecuencia, la información correcta nunca llega al LLM.
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 vector almacenado, pero se excluye durante el proceso de consolidación.
Esto sucede cuando demasiados documentos se devuelven y el sistema debe filtrarlos para ajustarse dentro de la ventana de contexto de un LLM, los límites de tokens o los límites de velocidad.
FP4. No extraído
Esta es una situación en la que un LLM no logra identificar la información correcta en el contexto, incluso aunque la información correcta estuviera en el vector almacenado y se recuperara/consolidara con éxito.
Esto sucede cuando el contexto es demasiado ruidoso o contiene información contradictoria que confunde al LLM.
FP5. Formato incorrecto
Esta es una situación en la que el almacenamiento, la recuperación, la consolidación y la interpretación del LLM se manejan con éxito, pero el LLM no logra seguir instrucciones de formato específicas proporcionadas en la llamada, como una tabla, una lista con viñetas o un esquema JSON.
FP6. Especificidad incorrecta
La salida de un LLM está técnicamente presente, pero demasiado general o demasiado compleja en comparación con las necesidades del usuario.
Por ejemplo, un LLM genera respuestas simples a una consulta de usuario con un objetivo profesional complejo.
FP7. Respuestas incompletas
Esta es una situación en la que un LLM 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 LLM solo aborda una o dos de las fuentes.
