Evaluación de resultados

Explore más de lo que RAG Cookbook tiene para ofrecer para obtener un insight más profundo de las soluciones de RAG actuales

Un espacio principal recoloreado que utiliza como base el espacio principal watsonx para atención al cliente.
Descripción general

Hay muchas preguntas que uno puede tener con respecto a una solución de RAG:

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

Contar con una estrategia de evaluación clara a lo largo del desarrollo de una solución basada en RAG es fundamental para garantizar el éxito en la fase de 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 de RAG deben evaluarse de manera sistemática y coherente tanto para los componentes de recuperación como para los 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 experimentación y ajuste
  • Fase de monitoreo

No obstante, el esfuerzo por construir un motor de evaluación no debe subestimarse especialmente cuando se trata de crear un conjunto de datos dorado (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.

Enfoques

IA que evalúa la 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 crear un motor de evaluación basado en referencias. Se demostró que esta técnica de evaluación produce una correlación decente con el juicio humano. Aquí hay varias propiedades que no pueden cuantificarse con métricas y puntos de referencia existentes, pero pueden evaluarse mediante LLMaaJ:

  • Seguridad: ¿los modelos generan contenido dañino o inseguro?
  • Solidez: en el caso del resumen y la generación aumentada por recuperación, ¿el resultado generado se basa en hechos presentes en el contexto de entrada?
  • Sentimiento: ¿las respuestas generadas son generalmente positivas, negativas o cualquier otro sentimiento prescrito?
  • Toxicidad: ¿los modelos generan contenido ofensivo, agresivo o discriminatorio?
  • Estilo de lenguaje: ¿los modelos hablan con una voz informal, formal o común? Esto incluye evaluar el sarcasmo, el humor y la ironía.

Por ejemplo, cuando se utiliza un modelo de puntuación para evaluar los resultados 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 que se va a evaluar.

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

Usted es un juez de puntuación imparcial y sin sesgo. 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. Explique su razonamiento y concluya expresando el sentimiento clasificado.
{{response}}

 

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

-----------------------------------Indicación-------- ----------------------------------------
Usted es un evaluador profesional y su tarea es valorar la precisión de la extracción de entidades como puntuación en un texto dado. Se le dará un texto, una entidad y el valor de la entidad.
Proporcione una puntuación numérica en una escala de 0 a 1, donde 1 es la mejor y 0 es la peor. Utilice estrictamente valores numéricos para la puntuación.

Estos son los ejemplos:

Texto: ¿Dónde se encuentra la oficina de IBM en Nueva York?
Entidad: nombre de la organización
Valor:
Puntuación de IBM: 0

Texto: Llame al servicio de atención al cliente al 1-800-555-1234 para obtener ayuda.
Entidad: número de teléfono
Valor: +1 888 426 4409
Puntuación: 1

Texto: watsonx tiene tres componentes: watsonx.ai, watsonx.data y watsonx.governance.
Entidad: nombre del producto
Valor: Puntuación de
Google: 0.33

Texto: La conferencia está programada para el 15 de agosto de 2024.
Entidad: fecha
Valor: 15 de agosto de 2024
Puntuación: 1

Texto: Mis colegas John y Alice se unirán a la reunión.
Entidad: nombre de la persona
Valor: Alice
Puntuación: 1

-----------------------------------Resultado---- -----------------------------------------Puntuación: 0.67
------ -------------------------------------------------- ------------------------------
Métricas

La complejidad de los sistemas de RAG está significativamente influenciada por la naturaleza enigmática de los modelos de lenguaje grandes (LLM), así como por los componentes intrincados e interconectados dentro del pipeline de RAG. A medida que la tecnología continúa avanzando 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 gran cantidad de puntos de referencia y herramientas de evaluación específicamente para los sistemas de 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 ilustra 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 de RAG, cada uno con sus fortalezas y aplicaciones únicas. Esta tabla, que no es exhaustiva, sirve para proporcionar una visión general sucinta del panorama actual de la evaluación de RAG.

Una tabla parcial de medidas y esquemas de evaluación para soluciones de RAG.

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

En términos del componente de recuperación, los desafíos surgen principalmente debido a la naturaleza extensa y dinámica de los repositorios de conocimientos 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 proporcionar una evaluación integral. En cambio, 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 requiere el desarrollo y la implementación de métricas de evaluación integrales que puedan proporcionar una valoración holística y matizada del rendimiento del sistema.

A su vez, la evaluación del sistema de RAG en su conjunto requiere un examen exhaustivo del impacto del componente de recuperación en el proceso de generación, así como una evaluación de la eficacia general del sistema para lograr sus metas y objetivos previstos.

La tríada RAG es una infraestructura para evaluar la confiabilidad y precisión contextual de las respuestas de los modelos de lenguaje grandes (LLM). Consta de tres evaluaciones: relevancia del contexto, solidez y relevancia de la respuesta. Estas evaluaciones tienen como objetivo identificar las alucinaciones de respuesta de un LLM verificando la relevancia del contexto, la confiabilidad de la respuesta al contexto y la alineación de la respuesta con las consultas de los usuarios.

Ilustración del marco de la tríada RAG para evaluar el rendimiento de las soluciones de RAG.

La evaluación de RAG se puede lograr con 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 métricas de recuperación a continuació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 basadas en el rango que se utilizan para los sistemas de recomendación son adecuadas para la RAG.

MRR (rango recíproco medio)

El 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 menor rendimiento de búsqueda, 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 escenarios de búsqueda.
Contras: una limitación es que no penaliza la recuperación por asignar un rango bajo a otras verdades fundamentales. No es adecuado para evaluar toda la lista de resultados recuperados, centrándose solo en el primer elemento relevante.

NDCG (ganancia acumulativa descontada normalizada)

métricas de calidad de clasificación que evalúan qué tan bien se ordena una lista de elementos en comparación con una clasificación ideal, donde todos los elementos relevantes se posicionan 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 perfectamente clasificada de elementos hasta la posición k. DCG mide la relevancia total de los elementos de una lista.

varía de 0 a 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 promedio)

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

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

Pros: considera tanto la precisión como la recuperación, proporcionando una evaluación equilibrada del rendimiento de 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 sencillo de interpretar como otras métricas, lo que requiere más contexto para comprender los resultados por completo.

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 confiables y se basen en el contexto proporcionado; fundamental para aplicaciones en las que la exactitud de los datos es primordial.
Contras: a menudo requiere el juicio humano para evaluar, lo que lo hace laborioso y subjetivo. Es posible que no capture completamente imprecisiones parciales o alucinaciones sutiles.

Robustez (insensibilidad)

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

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

Pros: garantiza que el modelo funcione de manera confiable en diversas condiciones de entrada; aplicabilidad en el mundo real: importante para aplicaciones prácticas en las que los datos de entrada pueden no tener el formato correcto. Contras: requiere pruebas exhaustivas en muchas variaciones, lo que puede llevar mucho tiempo; definición de variaciones: un desafío para definir y medir todas las posibles perturbaciones de entrada.

ROUGE (Suplente orientado a la retirada para la evaluación de Gisting)

Mide la calidad de la generación de texto comparando la superposición de n-gramas, secuencias de palabras y pares de palabras entre el texto generado por una 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.
Contras: se centra en la superposición de n-gramas, que puede no capturar la calidad o fluidez semántica. Puede verse influido por la longitud del texto generado, lo que puede penalizar resultados más cortos o concisos.

BLEU (suplente de evaluación bilingüe)

Mide la calidad del texto traducido por máquina comparándolo con una o más traducciones de referencia. Evalúa la precisión de los n-gramas en el 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 un punto de 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 por inexactitud parcial: es posible que no capture completamente las inexactitudes parciales o las diferencias sutiles en el significado.

Métricas de costos

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 utiliza principalmente para la fase de generación.

Costo de las llamadas de LLM

Ejemplo: costo de las llamadas a la API de OpenAI

Costos de infraestructura

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

Costo de operación

Costos de mantenimiento, soporte, monitoreo, registro, medidas de seguridad, etc.

Comprender los resultados de la evaluación

 

Gráfico de cuatro cuadrantes que muestra las acciones de corrección para ajustar los modelos de RAG en función de las puntuaciones de generación y recuperación.

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

  1. Revisar y ajustar la estrategia de fragmentación (por ejemplo, el tamaño de los fragmentos y la superposición) para equilibrar mejor el contexto y la relevancia.
  2. Limpiar y preprocesar los datos para eliminar el ruido y la información irrelevante.
  3. Agregar 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. Hacer que el LLM reformule la consulta y lo reintente, ya que es posible que preguntas similares para humanos no parezcan similares en el espacio de incorporación.
  6. Ajustar las incorporaciones con LlamaIndex para una mayor precisión.

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

  1. Ajuste el modelo de lenguaje: personalice el modelo para su dominio ajustándolo en conjuntos de datos relevantes para mejorar su precisión y comprensión contextual.
  2. Perfeccione la ingeniería rápida: experimente con la estructura y la redacción de las instrucciones para guiar el modelo hacia resultados más precisos.
  3. Utilice diferentes estrategias de decodificación: ajuste las técnicas de decodificación como la búsqueda de haz, el muestreo top-k o el muestreo de núcleo (top-p) para mejorar la calidad de las respuestas generadas.
  4. Controle la longitud de la generación: establezca restricciones en la longitud de la respuesta para garantizar que los resultados sean concisos y precisos.
  5. Incorpore ciclos de feedback: implemente un sistema que identifique y corrija las respuestas subóptimas, lo que permite la mejora continua.
  6. Aproveche el diálogo de varios turnos: 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 las métricas de recuperación como las de generación muestren un rendimiento inferior al esperado, sería prudente revisar y reconsiderar las etapas 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 enfatiza la importancia de una evaluación integral y matizada del sistema de RAG, tomando en cuenta la interacción entre los componentes de recuperación y generación y la efectividad general del sistema en el logro de sus metas y objetivos previstos.

Explore más

Obtenga los últimos patrones tecnológicos, arquitecturas de soluciones y publicaciones de arquitectura de IBM.

  1. Ir al IBM Architecture Center
Colaboradores

Vicky Kuo, Amna Jamal, Luke Major, Chris Kirby

Actualizado: 15 de noviembre de 2024