Hay muchas preguntas que se pueden plantear con respecto a una solución RAG:

• ¿Cómo debemos determinar las opciones de diseño que maximizan el rendimiento de la recuperación?
• ¿Cómo sabemos qué modelo de incrustación crea la mejor representación vectorial de nuestros documentos?
• ¿Es necesario un enfoque agéntico?
• ¿Una reordenación mejoraría nuestros resultados? ¿O tal vez estas elecciones de parámetros tienen un impacto marginal?

Tener una estrategia de evaluación clara a lo largo del desarrollo de una solución basada en RAG es crucial para garantizar un camino exitoso hacia la producción. Vemos todo tipo de evaluaciones empíricas realizadas durante los pilotos que a veces no son reproducibles. Para mejorar el rendimiento de una solución basada en RAG en desarrollo o para diagnosticar correctamente un problema de producción, las tareas de evaluación deben ser reproducibles y rápidas de ejecutar. Los pipelines RAG deben evaluarse de forma sistemática y consistente tanto para componentes de recuperación como de generación.

Comprender el rendimiento de la solución basada en RAG desempeña un papel crítico en varios pasos del ciclo de vida de la solución durante:

• Fase de experimento y afinación
• Fase de monitorización

Sin embargo, no se debe subestimar el esfuerzo que supone crear un motor de evaluación, especialmente cuando se trata de crear un conjunto de datos de referencia (verdad fundamental) con respuestas y contextos de referencia.

En este documento, analizaremos diferentes enfoques y métricas de evaluación, así como destacaremos algunos de los activos reutilizables que existen para facilitar la evaluación de estas soluciones.

Evaluación de la IA mediante IA

LLMaaJ (LLM como juez) se ha convertido en una métrica líder en el último año para superar el desafío de construir un motor de evaluación basado en referencias. Se ha demostrado que esta técnica de evaluación produce una correlación decente con el juicio humano. Estas son varias propiedades que no se pueden cuantificar con las métricas y puntos de referencia existentes, pero que se pueden evaluar mediante LLmaaj:

• Seguridad: ¿Los modelos generan contenido dañino o inseguro?
• Fundamentación: en el caso de la generación aumentada por recuperación y resumen, ¿el resultado se basa en hechos presentes en la entrada?
• Sentimiento: ¿Las respuestas generadas son generalmente positivas, negativas o cualquier otro sentimiento prescrito?
• Toxicidad: ¿Los modelos generan contenido ofensivo, agresivo o discriminatorio?
• Estilo lingüístico: ¿Los modelos usan un tono informal, formal o común? Esto incluye evaluar el sarcasmo, el humor y la ironía.

Por ejemplo, al usar un modelo de puntuación para evaluar el resultado de otros modelos, la instrucción de puntuación debe contener una descripción de los atributos a puntuar y la escala de calificación, y debe interpolarse para incluir la respuesta a evaluar.

En este ejemplo, se pide al modelo que evalúe el estilo lingüístico de la respuesta y devuelva una clasificación.

Es un juez de puntuación justo e imparcial. Se le pide que clasifique la respuesta de un chatbot según su sentimiento. Evalúe la respuesta a continuación y extraiga la clase correspondiente. Las clases posibles son POSITIVO, NEUTRO, NEGATIVO. Explain your reasoning and conclude by stating the classified sentiment.
{{response}}

O, por ejemplo, a continuación se muestra un ejemplo de evaluación impulsada por LLM para tareas de NER (reconocimiento de entidades nombradas) con few-shot prompting.

-----------------------------------Prompt---------------------------------------------
You are a professional evaluator, and your task is to assess the accuracy of entity extraction as a Score in a given text. You will be given a text, an entity, and the entity value.
Please provide a numeric score on a scale from 0 to 1, where 1 is the best score and 0 is the worst score. Strictly use numeric values for scoring.

Here are the examples:

Text: Where is the IBM's office located in New York?
Entity: organization name
Value: IBM's
Score: 0

Text: Call the customer service at 1-800-555-1234 for assistance.
Entity: phone number
Value: +1 888 426 4409
Score: 1

Text: watsonx has three components: watsonx.ai, watsonx.data, and watsonx.governance.
Entity: product name
Value: Google
Score: 0.33

Text: The conference is scheduled for 15th August 2024.
Entity: date
Value: 15th August 2024
Score: 1

Text: My colleagues John and Alice will join the meeting.
Entity: person’s name
Value: Alice
Score: 1

-----------------------------------Output---------------------------------------------Score: 0.67
--------------------------------------------------------------------------------------

La complejidad de los sistemas RAG está significativamente influenciada por la naturaleza enigmática de los modelos de lenguaje de gran tamaño (LLM), así como por los componentes intrincados e interconectados dentro del pipeline RAG. A medida que la tecnología continúa progresando a un ritmo sin precedentes, evaluar un sistema tan complejo se convierte en una tarea cada vez más ardua. Para abordar este desafío, se han desarrollado una multitud de referencias y herramientas de evaluación específicamente para sistemas RAG. Estos recursos sirven para proporcionar un enfoque estandarizado y sistemático para evaluar el rendimiento y la eficacia de estos sistemas.

Por ejemplo, como se muestra en la siguiente tabla (adaptada de “Evaluation of Retrieval-Augmented Generation: A Survey”), existe una amplia gama de métodos y herramientas de evaluación del RAG, cada uno con sus puntos fuertes y aplicaciones únicos. Esta tabla, que no es exhaustiva, sirve para ofrecer una visión resumida y concisa del panorama actual de la evaluación RAG.

En el contexto del componente de recuperación de los sistemas RAG, surgen varios desafíos.

En cuanto al componente de recuperación, surgen desafíos principalmente debido a la naturaleza extensa y dinámica de los repositorios de conocimiento prospectivos, las facetas temporales de los datos y la heterogeneidad de las fuentes de información. Teniendo en cuenta estos desafíos, se hace evidente que las métricas de evaluación convencionales, como la recuperación y la precisión, son inadecuadas y están mal equipadas para ofrecer una evaluación completa. En su lugar, se necesitan métricas más matizadas y dependientes del contexto que puedan captar eficazmente las complejidades y sutilezas del proceso de recuperación.

En lo que respecta al componente de generación, es fundamental tener en cuenta la compleja relación entre la precisión del proceso de recuperación y la calidad del resultado generado. Esto hace necesario el desarrollo y la aplicación de métricas de evaluación exhaustivas que puedan proporcionar una valoración holística y matizada del rendimiento del sistema.

A su vez, la evaluación del sistema RAG en su conjunto requiere un examen minucioso del impacto del componente de recuperación en el proceso de generación, así como una valoración de la efectividad y eficacia generales del sistema en la consecución de sus metas y objetivos previstos.

La tríada RAG es un marco de evaluación para examinar la fiabilidad y la precisión contextual de las respuestas de los modelos de lenguaje de gran tamaño (LLM). Consta de tres evaluaciones: relevancia del contexto, fundamentación y relevancia de la respuesta. Estas evaluaciones tienen como objetivo identificar las alucinaciones de respuesta de LLM verificando la relevancia del contexto, la fiabilidad de la respuesta al contexto y la alineación de las respuestas con las consultas de los usuarios.

La evaluación RAG se puede lograr utilizando métricas automáticas basadas en referencias y sin referencias. Hay una tabla de clasificación en HuggingFace que analiza cómo se comparan los LLMs de código abierto entre sí.

Métricas de recuperación

Las siguientes métricas de recuperación se basan en referencias, lo que significa que cada fragmento debe identificarse de forma única (contexts_id) y cada pregunta tiene ID únicos de los contextos de verdad fundamental.

Las métricas de evaluación conscientes del rango utilizadas para los sistemas de recomendación son apropiadas para RAG.

MRR (rango recíproco medio)

MRR se utiliza en Unitxt y mide la posición del primer documento relevante en los resultados de búsqueda. Un MRR más alto, cercano a 1, indica que los resultados relevantes aparecen cerca de la parte superior, lo que refleja una alta calidad de búsqueda. Por el contrario, un MRR más bajo significa un rendimiento de búsqueda más bajo, con respuestas relevantes posicionadas más abajo en los resultados.

Pros: enfatiza la importancia del primer resultado relevante, que a menudo es crítico en los escenarios de búsqueda.
Contras: una limitación es que no penaliza la recuperación por asignar una clasificación baja a otras verdades fundamentales; no es adecuado para evaluar toda la lista de resultados recuperados, ya que se centra únicamente en el primer elemento relevante.

NDCG (ganancia acumulada descontada normalizada)

Métrica de calidad de la clasificación que evalúa lo bien ordenada que está una lista de elementos en comparación con una clasificación ideal, en la que todos los elementos relevantes se sitúan en la parte superior.

NDCG@k se calcula como DCG@k dividido por el DCG@k ideal (IDCG@k), que representa la puntuación de una lista de elementos perfectamente clasificados hasta la posición k. DCG mide la relevancia total de los elementos de una lista.

oscila entre 0 y 1

Pros: tiene en cuenta la posición de los elementos relevantes, lo que proporciona una visión más holística de la calidad de la clasificación; Se puede ajustar para diferentes niveles de clasificación (por ejemplo, NDCG@k).
Contras: más complejo de calcular e interpretar en comparación con métricas más simples como MRR; requiere una clasificación ideal para la comparación, que puede no siempre estar disponible o ser fácil de definir.

MAP (precisión media ponderada)

La precisión media poderada (MAP) es una métrica que evalúa la clasificación de cada documento recuperado correctamente en una lista de resultados

Es beneficioso cuando su sistema necesita considerar el orden de los resultados y recuperar varios documentos en una sola ejecución.

Pros: tiene en cuenta tanto la precisión como la recuperación, lo que proporciona una evaluación equilibrada del rendimiento de la recuperación; adecuada para tareas que requieren múltiples documentos relevantes y su orden correcto.
Contras: puede ser más exigente en términos de cálculo en comparación con métricas más simples; puede que no sea tan sencilla de interpretar como otras métricas, ya que requiere más contexto para comprender completamente los resultados.

Métricas de generación

Fidelidad

Mide si el resultado se basa en el contexto dado o si el modelo genera respuestas alucinadas.

Pros: garantiza que las respuestas generadas sean fiables y se basen en el contexto proporcionado; vital para aplicaciones en las que la corrección de los hechos es primordial.
Contras: a menudo requiere el juicio humano para evaluarlo, lo que lo hace laborioso y subjetivo; es posible que no capture completamente las imprecisiones parciales o las alucinaciones sutiles.

Robustez (insensibilidad)

La robustez se define generalmente como la capacidad de la solución para adaptarse a diferentes variaciones de entrada, como perturbaciones de datos como espacios en blanco, minúsculas/mayúsculas, tabulaciones, etc.

La robustez de las pruebas es un aspecto importante del proceso de evaluación y puede lograrse, por ejemplo, usando la semántica de Unitxt

Pros: garantiza que el modelo funcione de forma fiable en diversas condiciones de entrada; aplicabilidad en el mundo real: importante para aplicaciones prácticas en las que los datos de entrada pueden no estar formateados perfectamente.
Contras: requiere pruebas exhaustivas en muchas variaciones, lo que puede llevar mucho tiempo; definición de variaciones: es difícil definir y medir todas las posibles perturbaciones de entrada.

ROUGE (suplente orientado a la recuperación para la evaluación de Gisting)

Mide la calidad de la generación del texto comparando el solapamiento de n-gramas, secuencias de palabras y pares de palabras entre el texto generado por la máquina y un conjunto de textos de referencia. Ampliamente utilizado para evaluar tareas como el resumen y la traducción de textos.

Pros: establecido y reconocido en la comunidad de PLN, proporcionando un estándar para la comparación; adecuado para tareas en las que es importante capturar toda la información relevante.
Se centra en la superposición de n-gramas, lo que puede no captar la calidad o fluidez semántica; Puede verse influido por la longitud del texto generado, lo que puede penalizar los resultados más cortos o concisos.

BLEU (suplente de evaluación bilingüe)

Mide la calidad de un texto traducido por una máquina comparándolo con una o varias traducciones de referencia. Evalúa la precisión de los n-gramas del texto generado con respecto a los textos de referencia. Se utiliza principalmente para evaluar la traducción.

Pros: eficaz para tareas en las que la precisión y las coincidencias exactas son importantes; métrica estándar: ampliamente adoptada en la comunidad de traducción automática, proporcionando una referencia para la comparación.
Contras: puede penalizar variaciones legítimas en la redacción que no coincidan exactamente con los textos de referencia; ceguera parcial ante las imprecisiones: Puede que no capte completamente las imprecisiones parciales o las diferencias sutiles en el significado.

Métricas de costes

Utilización de GPU/CPU

La utilización de CPU se utiliza principalmente para la fase de recuperación, y la utilización de GPU se emplea principalmente para la fase de generación.

Coste de las llamadas de LLM

Ejemplo: coste de las llamadas a la API de OpenAI

Coste de infraestructura

Costes de almacenamiento, redes, recursos informáticos, etc.

Coste de operación

Costes de mantenimiento, soporte, monitorización, información de registro, medidas de seguridad, etc.

Comprender los resultados de la evaluación

Si las métricas de recuperación indican un rendimiento subóptimo, pero las métricas de generación dan resultados favorables, es recomendable: 

1. Revisar y ajustar la estrategia de fragmentación (por ejemplo, el tamaño y la superposición de los fragmentos) para equilibrar mejor el contexto y la relevancia.
2. Limpiar y preprocesar los datos para eliminar ruido e información irrelevante.
3. Añadir metadatos, como fechas, a los fragmentos para ayudar a filtrar y priorizar los datos en función de casos de uso específicos.
4. Implementar la reclasificación: esto permite que su sistema de recuperación refine los nodos principales para el contexto. Tanto * LangChain como LlamaIndex ofrecen abstracciones fáciles de usar para la reclasificación.
5. Haga que el LLM reformule la consulta y vuelva a intentarlo, ya que las preguntas similares para humanos pueden no parecer similares en el espacio de incrustación.
6. Afinar las incrustaciones con LlamaIndex para mejorar la precisión.

Por el contrario, si las métricas de recuperación demuestran un rendimiento sólido pero los resultados de la generación no son óptimos, considere las siguientes estrategias para mejorar el rendimiento del modelo:

1. Afinar el modelo de lenguaje: personalice el modelo para su dominio ajustándolo a conjuntos de datos relevantes con el fin de mejorar su precisión y comprensión contextual.
2. Refinar el prompt engineering: experimente con la estructura y la redacción de instrucciones para guiar el modelo hacia resultados más precisos.
3. Utilizar diferentes estrategias de decodificación: ajuste las técnicas de decodificación como la búsqueda de haces, el muestreo top-k o el muestreo de núcleo (top-p) para mejorar la calidad de las respuestas generadas.
4. Controlar la longitud de generación: establezca restricciones en la longitud de respuesta para asegurar que los resultados sean concisos y precisos.
5. Incorporar bucles de feedback: implemente un sistema que identifique y corrija las respuestas subóptimas, lo que permite la mejora continua.
6. Aprovechar el diálogo multiturno: divida las tareas complejas en interacciones de varios pasos, lo que permite que el modelo refine sus respuestas en varias iteraciones.

En el caso de que tanto la métrica de recuperación como la de generación muestren un rendimiento inferior, sería prudente revisar y reconsiderar las fases iniciales del proceso, como la mejora de los metadatos, el perfeccionamiento de la base de conocimientos y la optimización del mecanismo de recuperación.

Este enfoque hace hincapié en la importancia de realizar una evaluación exhaustiva y matizada del sistema RAG, teniendo en cuenta la interacción entre los componentes de recuperación y generación y la eficacia general del sistema para alcanzar las metas y objetivos previstos.