Utilice las máquinas para calificar las máquinas.
Incluyendo un nuevo método novedoso para juzgar las respuestas con una puntuación cualitativa y una explicación detallada.
La Generación Aumentada de Investigación, o RAG, es fácilmente el caso de uso más común para los Modelos de Lenguaje Grande (LLM) que han surgido este año. Si bien el resumen y la generación de texto suelen ser el foco de los usuarios individuales, las empresas se han dado cuenta de que necesitan la capacidad de utilizar sus datos para aprovechar esta tecnología. Si reflexiono sobre cómo sigo usando los LLM, la generación de texto ocupa un lugar destacado en la lista. Quiero hacerle preguntas a Bard y que busque en la web; Quiero que Claude reescriba correos electrónicos o publicaciones de blog para mejorar mi contenido. Pero el uso más interesante que he encontrado es canalizar mis propios datos al LLM. Quiero buscar en mis notas, correos electrónicos, calendario y mensajes de Slack y que Llama funcione como otro yo (pero un yo que pueda recordar detalles de cosas que sucedieron antes de hoy).
Esta no es una publicación sobre cómo construir un RAG (ya hay muchos de esos por ahí… y estoy trabajando en esa publicación para otro día). Lo que exploraremos hoy es cómo evaluar los sistemas RAG.
Establezcamos el nivel antes de meternos en la maleza. Cuando hablamos de un RAG, nos referimos a dos partes del sistema.
La fuente del conocimiento.
Una fuente de conocimiento puede ser una base de datos vectorial, un motor de búsqueda, algunos archivos de texto cargados en la memoria, datos SQL o cualquier cosa donde se almacenen nuestros datos.
El Máster en Derecho
Una vez que tenemos nuestros datos, los canalizamos al LLM. Esto se hace a través de la ventana contextual. Entonces, en última instancia, buscamos, obtenemos algo de texto, lo que encontramos en un mensaje y pasamos nuestra pregunta al LLM. Luego, el modelo toma todo lo que hay en esa ventana contextual y proporciona una respuesta.
¿Por qué esto importa?
Cuando hablamos de evaluar un sistema RAG, tenemos que saber qué evaluaremos antes de definir cómo evaluarlo. Ahora podemos ver que es necesario examinar dos piezas. La recuperación inicial de datos es la parte más crítica aquí. Los LLM, en general, son excelentes para resumir/responder preguntas con datos proporcionados en el contexto. Lo que podría faltar es la propia función de búsqueda.
Estas fuentes de conocimiento tienen algunas limitaciones inherentes. Por ejemplo, cuando se utilizan bases de datos vectoriales para almacenar archivos de texto grandes, hay que “fragmentar” los datos que ingresan. ¿Qué significa esto? Digamos que tiene un documento de 100 páginas, pero la base de datos solo puede guardar una página a la vez. Una vez que carga sus documentos y va a buscar, la base de datos solo puede examinar una página a la vez (vale, esto es un poco reduccionista, pero tengan paciencia; está lo suficientemente cerca para el trabajo gubernamental). Cuando encontramos datos que coinciden con nuestra búsqueda, existe una posibilidad real de que la respuesta completa a nuestra pregunta no se encuentre en esa única página. ¡Demasiado! ¡Solo recuperamos una página! Este es un buen ejemplo de por qué es necesario examinar esta parte del sistema antes de preocuparse por el resultado del LLM.
Evaluación de la búsqueda inicial
Ésta no será la respuesta que la mayoría de los tecnólogos quieren escuchar. Se requerirá cierto nivel de evaluación humana para evaluar los resultados de su fuente de conocimiento.
¿Por qué? Bueno, si una empresa utiliza sus datos y son privados, será difícil automatizar las pruebas para verificar que los resultados de la búsqueda sean totalmente precisos. No te preocupes, no tiene por qué ser 100% manual; Podemos automatizar partes del mismo. Profundicemos un poco más.
Hay dos implementaciones que veo para esta validación y evaluación inicial.
La primera opción es tener un conjunto de preguntas comunes y esperadas para el conjunto de datos y hacer que un equipo humano de control de calidad verifique los resultados de la búsqueda. Por ejemplo, si su equipo tiene la tarea de crear un robot de preguntas y respuestas de servicio al cliente para un banco, algunas preguntas comunes podrían ser: “¿Cuál es el monto mínimo que debo mantener en mi cuenta?”, “¿Cómo realizo un pago en ¿mi préstamo?’, ‘¿A qué hora abre mi sucursal?’. Es ideal si su control de calidad puede proporcionar tanto las preguntas como las respuestas esperadas en algo así como un archivo CSV que se pueda leer mediante programación; luego, podemos usar algunas de nuestras pruebas automatizadas que cubriremos un poco más adelante en esta publicación.
Si el tiempo o los recursos no están disponibles para esto, el segundo método consiste en que un equipo de control de calidad busque y revise en tiempo real. Esta es una opción para las primeras pruebas de concepto y prototipos, pero tenga cuidado, no se adaptará a las cargas de trabajo de producción reales.
Evaluación de las respuestas del LLM
Una vez que tengamos un nivel de confianza en que los datos de nuestra fuente de conocimiento son confiables, debemos asegurarnos de que las respuestas finales sean precisas. Los sistemas RAG son excelentes para reducir la posibilidad de alucinaciones, y esto se puede ampliar modificando el mensaje subyacente. Sin embargo, puede omitir información, malinterpretar los datos que se le suministran o intentar incorporar conocimientos a priori de su capacitación.
Evaluar este paso es similar a evaluar la búsqueda anterior. Si los equipos de control de calidad pueden proporcionar preguntas y respuestas esperadas, podemos intentar evaluar las respuestas mediante programación.
Veamos ahora algunas de esas opciones.
Es esencial recordar que los LLM y RAG se encuentran en una etapa muy temprana de su ciclo de madurez. Solo ha pasado un año desde que debutó ChatGPT y cada día trae más avances, modelos, marcos e investigaciones en este campo. Dicho esto, un puñado de métricas se están convirtiendo en la forma estándar de medir el rendimiento de estos sistemas.
No cubriremos formas de evaluar el LLM básico. Hay cosas como ARC, MMLU, HellaSwag, etc., que apuntan al modelo de lenguaje subyacente. No es necesario que ejecute estas medidas usted mismo; puedes consultar sitios como
https://llm-leaderboard.streamlit.app/ y https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard
para ver cómo les va a los diferentes modelos. Sólo nos interesa medir los resultados que obtenemos de los sistemas RAG.
Eso nos lleva a mirar algoritmos como ROUGE, BLEU, BLUERT y METEOR. Echemos un vistazo más de cerca a cada uno. También incluiré un pequeño fragmento de código sobre cómo llamar a cada métrica y cómo se ve la puntuación de salida. Importo el marco de evaluación para comenzar e incluyo la referencia y la respuesta que quiero calificar.
!pip install evaluate --quiet
!pip install rouge_score --quiet
!pip install importlib-metadata --quiet
!pip install datasets==2.10.1 --quiet
!pip install git+https://github.com/google-research/bleurt.git --quiet
!pip install sacrebleu --quiet
!pip --no-cache-dir install bert_score==0.3.9 --quiet
!pip install sacremoses --quiet
!pip install jiwer==2.5.1 --quiet
!pip install Cython import evaluate
# If you have a translation and reference corpus:
predictions = ["In Dungeons & Dragons, the metallic dragons come in brass, bronze, copper, gold, and silver varieties. Each has scales in hues matching their name - brass dragons have brassy scales, bronze have bronze scales, etc. The metallic dragons are generally more benign than the chromatic dragons in D&D lore."]
references =["""The five basic chromatic dragons (red, blue, green, black, and white) and metallic dragons (copper, brass, silver, gold, and bronze) appeared in the fifth edition Monster Manual (2014) in wyrmling, young, adult, and ancient. Gem dragons and other new-to-fifth-edition dragons appeared in Fizban's Treasury of Dragons (2021)"""]
COLORETE (Estudio suplente orientado al recuerdo para la evaluación de Gisting)
ROUGE es un conjunto de métricas para evaluar el resumen automático y los resultados de la traducción automática. Se basa en el recuento de n-gramas superpuestos entre la salida del sistema y los resúmenes de referencia.
#predictions (list): list of predictions to score. Each prediction should be a string with tokens separated by spaces.
#references (list or list[list]): list of reference for each prediction or a list of several references per prediction. Each reference should be a string with tokens separated by spaces.
#rouge_types (list): A list of rouge types to calculate. Defaults to ['rouge1', 'rouge2', 'rougeL', 'rougeLsum'].
#Valid rouge types:
##"rouge1": unigram (1-gram) based scoring
##"rouge2": bigram (2-gram) based scoring
##"rougeL": Longest common subsequence based scoring.
##"rougeLSum": splits text using "\n"
#use_aggregator (boolean): If True, returns aggregates. Defaults to True.
#use_stemmer (boolean): If True, uses Porter stemmer to strip word suffixes. Defaults to False.rouge = evaluate.load('rouge')
results = rouge.compute(predictions=predictions, references=references, use_aggregator=False)
print(results)
{
'rouge1': [0.3636363636363636],
'rouge2': [0.06185567010309278],
'rougeL': [0.22222222222222224],
'rougeLsum': [0.22222222222222224]
}
AZUL (Suplente de Evaluación Bilingüe)
BLEU es una métrica para la evaluación automática de resultados de traducción automática. Se basa en la precisión de n-gramas de la traducción candidata frente a un conjunto de traducciones de referencia.
#predictions (list of strs): Translations to score.
#references (list of lists of strs): references for each translation.
#max_order (int): Maximum n-gram order to use when computing BLEU score. Defaults to 4.
#smooth (boolean): Whether or not to apply Lin et al. 2004 smoothing. Defaults to False.#bleu (float): bleu score
#precisions (list of floats): geometric mean of n-gram precisions,
#brevity_penalty (float): brevity penalty,
#length_ratio (float): ratio of lengths,
#translation_length (int): translation_length,
#reference_length (int): reference_length
bleu = evaluate.load(“bleu”)
results = bleu.compute(predictions=predictions, references=references,max_order=4)
print(results)
{
'bleu': 0.07342349837092484,
'precisions': [0.4262295081967213, 0.11666666666666667, 0.03389830508474576, 0.017241379310344827],
'brevity_penalty': 1.0,
'length_ratio': 20.333333333333332,
'translation_length': 61,
'reference_length': 3
}
BLEURT (Regresión BLEU con Transformers)
BLEURT es una métrica de evaluación para la Generación del Lenguaje Natural (NLG). Se basa en BERT, que permite a BLEURT aprender las relaciones estadísticas entre palabras y frases e identificar patrones en la salida de NLG.
Se ha demostrado que BLEURT supera a otras métricas de evaluación de NLG, como BLEU y ROUGE, en una variedad de tareas, incluida la traducción automática, el resumen y la respuesta a preguntas.
#output is always a number between 0 and (approximately 1).
#This value indicates how similar the generated text is to the reference texts, with values closer to 1 representing more similar texts.bleurt = evaluate.load("bleurt", module_type="metric")
results = bleurt.compute(predictions=predictions, references=references)
print(results)
{
'scores': [0.6028875708580017]
}
METEORITO (Métrica para evaluación de traducción con ordenamiento explícito)
METEOR es una métrica de evaluación automática para resultados de traducción automática. También tiene características que no se encuentran en otras métricas, como derivación, coincidencia de sinónimos y coincidencia estándar de palabras exactas. La métrica fue diseñada para solucionar algunos de los problemas encontrados en la métrica BLEU más popular y también producir una buena correlación con el juicio humano a nivel de oración o segmento.
#predictions: a list of predictions to score. Each prediction should be a string with tokens separated by spaces.
#references: a list of references (in the case of one reference per prediction), or a list of lists of references (in the case of multiple references per prediction. Each reference should be a string with tokens separated by spaces.
#alpha: Parameter for controlling relative weights of precision and recall. The default value is 0.9.
#beta: Parameter for controlling shape of penalty as a function of fragmentation. The default value is 3.
#gamma: The relative weight assigned to fragmentation penalty. The default is 0.5.#outputs 0-1 - .317 is acceptable score
meteor = evaluate.load('meteor')
results = meteor.compute(predictions=predictions, references=references)
print(results)
{
'meteor': 0.19316493313521543
}
Aunque tengo su atención, quiero presentarles una nueva idea. Si bien esos cuatro algoritmos le brindarán una puntuación cuantificable que permitirá a su equipo de control de calidad determinar rápidamente si una respuesta o resumen es similar, existen algunas deficiencias.
Primero, las oraciones de referencia y el resultado pueden ser lo suficientemente similares como para responder la pregunta de los usuarios, pero aun así pueden recibir una puntuación baja. Es esencial ejecutar un conjunto conocido de preguntas y respuestas para establecer una buena línea de base y comparar las respuestas futuras con esta línea de base.
En segundo lugar, no te dice por qué sufre la puntuación. ¿Será porque hay una penalización por repetir palabras? ¿Será porque faltan algunas palabras? ¿El resumen omitió por completo una parte esencial de la respuesta? No hay manera de saberlo.
Por último, el hecho de que una respuesta reciba una puntuación baja no significa necesariamente que un humano considere la respuesta como insuficiente o incorrecta. La línea de base puede ser útil aquí para establecer cómo pueden ser las puntuaciones aceptables, pero es importante tener cierto escepticismo al utilizarlas para juzgar las respuestas del RAG.
LLM calificando LLM
BLEURT nos ha presentado la idea de que podemos utilizar los LLM de alguna manera para evaluar las respuestas de un sistema RAG. ¿Qué pasa si aprovechamos esto directamente nosotros mismos? Le indicamos a un LLM que dé una puntuación cualitativa a nuestra respuesta y proporcione tanto los motivos con viñetas como una explicación narrativa de la puntuación que asignó. Esto nos da lo mejor de ambos mundos. Podemos extraer una puntuación numérica para informar a los usuarios y al control de calidad en un informe; También podemos proporcionar más detalles sobre por qué una respuesta obtuvo una mala puntuación.
Aquí hay una plantilla de mensaje de muestra que se puede usar para ClaudeV2. Pasamos instrucciones sobre cómo queremos que el modelo califique nuestra respuesta, pasamos los datos de referencia y pasamos la respuesta que recibimos de nuestro sistema RAG.
prompt_data = """
Human:
You are to rate a summarization on the scale of 0-10, with 0 being completely incorrect and 10 being a perfect summzarization of the given text.
Explain why you give your score.
Give a bullet point list of major differences between the reference and the summary.
I will supply a reference text by denoting REF: and the summarization to compare against with SUMMARY:.REF:
The five basic chromatic dragons (red, blue, green, black, and white)
and metallic dragons (copper, brass, silver, gold, and bronze)
appeared in the fifth edition Monster Manual (2014) in wyrmling, young, adult, and ancient.
Gem dragons and other new-to-fifth-edition dragons appeared in Fizban's Treasury of Dragons (2021)
SUMMARY:
In Dungeons & Dragons, the metallic dragons come in brass, bronze, copper, gold, and silver varieties.
Each has scales in hues matching their name - brass dragons have brassy scales, bronze have bronze scales, etc.
The metallic dragons are generally more benign than the chromatic dragons in D&D lore.
Assistant:"""
Score: 5/10Explanation:
The summary captures some accurate high-level information about metallic dragons in D&D, such as listing the main types and noting their more benign nature compared to chromatic dragons. However, it leaves out a lot of key details from the reference text:
- Does not mention the chromatic dragons (red, blue, green, black, white) that were described.
- Does not mention the different age categories (wyrmling, young, adult, ancient).
- Does not mention the Monster Manual or Fizban's Treasury of Dragons sourcebooks.
- Only focuses on metallic dragons, while the reference text had information about both metallic and chromatic dragons.
Major differences:
- No mention of chromatic dragons
- No mention of dragon age categories
- No mention of Monster Manual or Fizban's Treasury of Dragons
- Only discusses metallic dragons, not full scope of reference text
- Does not convey the introduction timeline of dragons across 5th edition books
Ahí estamos. Si los equipos pueden proporcionar las respuestas esperadas, podemos volver a introducir las respuestas de RAG en un LLM para calificarlas. Los beneficios son que no tenemos que depender del conocimiento a priori del LLM, ya que todavía estamos canalizando los datos relevantes. Podemos utilizar un LLM diferente al utilizado en el sistema RAG, lo que significa que incluso podemos pedir a varios modelos que califiquen nuestro resultado para garantizar que tengamos una evaluación equilibrada.
Este método también nos da una excelente explicación de lo que estaba mal. En este ejemplo, tenía una pregunta sobre qué tipos de dragones existían en el universo DND. El juez LLM identificó correctamente que no mencionaba dragones cromáticos. Sin embargo, también afectó la respuesta por no incluir las edades de los dragones, el Manual de monstruos DND o la aventura de expansión. Esas omisiones no fueron importantes para la pregunta que hice, pero esto permite que los equipos de control de calidad decidan por sí mismos una vez.
Los sistemas basados en RAG y los marcos utilizados para crearlos avanzan todos los días. También seguirán avanzando nuevas formas y mecanismos para calificarlos. Incluso existen herramientas de gigantes como LangChain que pueden ayudar en esta tarea, como LangSmith .
Mientras esperamos más avances, usar una combinación de algunos datos de validación manual y la biblioteca de métricas de HuggingFace o los propios LLM nos brinda una excelente manera de comenzar a confiar en estos sistemas.
Recuerde, una vez que tenga confianza y esté listo para implementar su nuevo RAG en producción, ¡la evaluación de las respuestas no se detiene! Como parte de los esfuerzos rutinarios de monitoreo y auditoría, debe continuar almacenando preguntas y respuestas y planificar un esfuerzo humano para calificar y marcar las respuestas proporcionadas a los usuarios finales. Eso, sin embargo, es tema para otro día.