LLM no mata LLM… o sí

La generación de texto supone un gran impacto en la sociedad y nace la necesidad de evaluar este paradigma: ¿cómo de bueno es mi prompt? ¿Cómo sé si mi LLM ha dejado de funcionar bien? Intuitivamente, un humano es la mejor opción para responder estas preguntas.

Sin embargo, ¿qué ocurre si queremos realizar una evaluación sistemática y automática? ¿Y si estas preguntas las respondiera… otro LLM?

Introducción

La evaluación de un sistema basado en LLM es fundamental para asegurar:

1. que el sistema dará resultados de calidad una vez puesto en producción y
2. que el sistema mantendrá esa calidad a lo largo del tiempo.

En este post vamos a hablar de cómo evaluar estos sistemas mediante métricas, haciendo especial hincapié en las basadas en LLM. Estas métricas se caracterizan porque es un LLM el que evalúa las salidas de otro LLM.

En este post, primero describiremos algunas dificultades que aparecen a la hora de evaluar un LLM y qué hay que tener en consideración. Después, hablaremos de las métricas disponibles que consideramos más relevantes, así como de algunas librerías y frameworks útiles.

Finalmente, hablaremos de la aplicación de métricas basadas en LLM dentro de Paradigma.

Premisas: dificultades a la hora de evaluar

Existen una serie de factores y elementos que hacen que la evaluación de un LLM no sea una tarea trivial. Es necesario identificar estas dificultades para que una metodología de evaluación sea lo más robusta posible.

A continuación, definimos algunos de los principios que suponen dificultades cuando hablamos de evaluación:

• Subjetividad del lenguaje. Cuando hablamos de evaluar un LLM o un prompt específico, tenemos que tener clara una premisa: el lenguaje es esencialmente subjetivo. Es por ello que, en etiquetados de datasets para NLP, normalmente se requieren varios anotadores y, además, este etiquetado suele ir acompañado de métricas de agreement entre ellos. Esto es un claro indicativo de que, a pesar de establecer unos criterios consensuados a la hora de evaluar o anotar un texto, es difícil llegar a un consenso unánime.
• Conjuntos de datos. Otra dificultad bastante recurrente en un proyecto basado en IA generativa es la existencia de un conjunto etiquetado de datos. Etiquetar un conjunto de textos para poder establecer un conjunto de evaluación de nuestro sistema supone un proceso tedioso. El conjunto etiquetado puede ser, por ejemplo, un conjunto de preguntas y sus respuestas para evaluar un sistema RAG, o un conjunto de textos y JSONs con información extraída a partir de los propios textos para evaluar una tarea de extracción de información estructurada. Por lo tanto, es importante también establecer si queremos realizar una evaluación “supervisada” y elegir y construir de forma consensuada un conjunto lo más sólido posible.
• ¿Qué queremos evaluar? Es también un punto clave establecer qué criterios son los que queremos evaluar con respecto al contenido generado por un LLM. Algunos de los aspectos que se pueden evaluar son:

1. La forma del mensaje. Es decir, ¿está respondiendo el LLM de forma suficientemente educada? ¿Se están repitiendo ciertas palabras en las respuestas generadas? ¿Es el lenguaje usado por el LLM el que deseamos para esta tarea?
2. Corrección de la información. Queremos responder preguntas como: ¿está mi sistema dando respuesta con toda la información posible? ¿La información que me responde mi sistema es correcta o es inventada?
3. Otros aspectos. Existen otros aspectos a la hora de evaluar un LLM. Por ejemplo, ¿cómo de vulnerable es el LLM a prompt injections? ¿El formato de la respuesta es el que necesito?

Métricas no basadas en LLM

Dentro del NLP existen una serie de tareas que no necesitan un entendimiento “humano” del contenido generado por parte de un LLM, ya que no requieren una creatividad excesiva por parte del sistema.

A continuación, definimos algunas de las métricas empleadas para la evaluación de estos sistemas:

• Métricas de similitud literal. Son métricas que miden el solapamiento de palabras entre dos textos (por ejemplo: ROUGE o BLEU), y suelen emplearse en tareas donde la generación por parte del LLM no tiene implícitos muchos grados de libertad (como, por ejemplo, traducción automática).
• Métricas de similitud semántica. Son métricas que miden la similitud no literal entre textos, y se usan para tareas más creativas como pueden ser un sistema RAG o tareas de Q&A. Entre estas métricas se encuentran algunas en la literatura como BERTScore o métricas de similitud entre embeddings.
• Métricas clásicas de clasificación para tareas más simples, como clasificación de textos, Name Entity Recognition o extracción de información.

Métricas basadas en LLM

A la hora de evaluar un LLM o un prompt es muy probable que queramos realizar una evaluación semántica de ellos, es decir, queremos que las respuestas expresen un determinado contenido semántico, aunque no lo haga siempre con las mismas palabras en el mismo orden. Por ello, la mejor manera de realizar esta evaluación es mediante supervisión humana.

Sin embargo, a la hora de desarrollar y mantener un sistema basado en LLM, es necesario realizar un proceso automático de evaluación y esto, mediante supervisión humana, es algo imposible.

Pero, ¿y si pedimos a un LLM el ejercicio de entender y evaluar un contenido como si fuese un humano? Nacen de esta manera las métricas basadas en LLM, donde un LLM responde si un texto cumple con ciertas exigencias especificadas en un prompt.

Las métricas basadas en LLM pueden usarse para evaluar distintas tareas o tipos de sistemas (RAG, Q&A, generación de código, etc.) y pueden ser métricas supervisadas, es decir, requerir un ground-truth para comparar con el texto generado, o no supervisadas.

A continuación, describimos algunas de las métricas basadas en LLM más usadas y que más interesantes nos han parecido:

• Faithfulness. Es una métrica supervisada y especialmente orientada en tareas de RAG. Se representa como un valor numérico entre 0 y 1 y responde a la pregunta: “¿cómo de coherente es la respuesta generada según el contexto proporcionado?”.
• Answer Relevancy. Es una métrica no supervisada y orientada a sistemas Q&A. Mide cómo de relevante es una respuesta dada una pregunta. Para calcularse, se le pide a un LLM que genere preguntas sintéticas según la respuesta generada y se mide la similitud entre los embeddings de la pregunta original y las sintéticas. De esta manera, se pretende ver cómo de “reconstruible” es la pregunta en base a la respuesta generada.
• Answer Correctness. Es una métrica supervisada usada para sistemas RAG. Se basa, por un lado, en calcular una adaptación de la métrica f-score usando como True Positives las afirmaciones de la respuesta generada que aparecen en la respuesta ground-truth, como False Positives las afirmaciones de la respuesta generada que no aparecen en la respuesta real y False Negatives las afirmaciones de la respuesta real que no aparecen en la generada. Además, también se calcula una similitud coseno entre respuesta generada y respuesta esperada. La métrica final es una media ponderada entre este f-score y la similitud de embeddings mencionada.

• Aspect Critique. Se trata de una métrica de propósito general y no supervisada, y evalúa cómo de correcta es la respuesta en cuanto a algunos aspectos como “nocividad”, “malicia”…
• Context Relevancy. Se trata de una métrica no supervisada que evalúa los contextos proporcionados en un prompt y mide, con un valor entre 0 y 1, cómo de relevante es la información del contexto para responder a una pregunta. Un contexto evaluado con valor 1 correspondería a información relevante para responder.
• Context Recall. Es una métrica supervisada usada para tareas RAG. A partir de una respuesta ground truth, mide si se puede atribuir cada oración del ground truth al contexto proporcionado en el prompt. El valor final es la proporción de oraciones de la respuesta ground truth que, efectivamente, puede generarse a partir del contexto.

Librerías y frameworks

Ante la creciente importancia de las métricas basadas en LLM, aparecen nuevos desarrollos de paquetes y frameworks que dan soporte a la evaluación de LLM. Entre estas nuevas herramientas, destacamos las siguientes:

• RAGAs. Se trata de una librería enfocada en la evaluación de sistemas RAG que implementa varias de las métricas descritas previamente.
• DeepEval. Se trata de un framework especializado en enfocar la evaluación de LLM como test unitarios. Tiene integrado un gran número de métricas, así como librerías y la previamente mencionada RAGAs.
• LangSmith. Es un framework que integra multitud de funcionalidades para gestionar el ciclo de vida de un sistema basado en LLM: trazabilidad, versionado de prompts, registro de métricas, etc. Pertenece a LangChain, por lo que la integración es casi total.
• Langfuse. Es un framework open-source similar a LangSmith pero con menos funcionalidades. Nuestro compañero José María Hernández de la Cruz realizó un webinar hablando de este framework y realizando una demo de su uso.

Ejemplo real: Benchmark

En Paradigma Digital ya hemos trabajado con métricas basadas en LLM. En un proyecto llevado a cabo por el equipo de GENAI, se han realizado comparaciones entre distintas tecnologías para tener una referencia a la hora de desarrollar proyectos de IA generativa.

En este proyecto nos basamos en un caso de uso de un contact center, donde el dataset de evaluación consiste en un conjunto de preguntas y respuestas en español que, hipotéticamente, un trabajador de contact center realizaría con respecto a las llamadas que ha habido con los clientes seleccionados.

Entre las tecnologías comparadas, los LLM son uno de los componentes que hemos evaluado. Para ello, creamos nuestras propias métricas (basándonos en algunas de las descritas previamente) que consideramos como útiles en este caso de uso:

• Accuracy. Para calcular esta métrica, pedimos a un LLM que nos diga si una respuesta generada contiene el mismo contenido que una respuesta esperada. En este caso, cada par ‘respuesta generada’-’respuesta esperada’, tendrá como salida por parte del LLM ‘True’ o ‘False’. La métrica se calculará como el porcentaje de valores ‘True’ en el conjunto de evaluación. El prompt para preguntar al LLM por el acierto lo creamos nosotros mismos en español para que así fuese más acorde al idioma del conjunto de evaluación usado.
• Fscore, precision y recall. Para el cálculo de estas métricas nos basamos en la métrica Answer Correctness previamente descrita, donde obtenemos una serie de afirmaciones TP, FP y FN preguntando a un LLM. En este caso, realizamos un prompt (también en español) donde, además, integramos una serie de ejemplos few-shot para facilitar la tarea al LLM.

Tras el análisis de las métricas calculadas obtuvimos una serie de conclusiones:

• Observamos que evaluar un LLM con el mismo LLM puede causar un sesgo en favor de ese LLM. Esto lo vimos concretamente con GPT 3.5 Turbo, que lo empleamos para realizar una comparación de este modelo con Claude Instant. Se observaba una tendencia clara que indicaba que GPT 3.5 Turbo daba mejores respuestas, pero al evaluar de forma manual vimos que no era necesariamente cierto.
  Tras observar esto, cambiamos como modelo evaluador a GPT-4 que, además, es un modelo más inteligente, dando lugar este LLM a más resultados en favor de Claude Instant que GPT 3.5 Turbo. En la figura de a continuación, se muestra esa diferencia en la métrica denominada como accuracy, viendo cómo usando GPT 3.5 Turbo (izquierda) se favorecía de forma bastante clara a lo generado por ese mismo LLM mientras que, evaluando con GPT-4 (derecha), observamos el efecto contrario.

• Las métricas basadas en LLM no son perfectas. Pueden dar una intuición del funcionamiento de un sistema pero, al ser respuestas dadas por LLM, ya tienen un error intrínseco. Sin embargo, hay que tener en cuenta que ni tan siquiera la evaluación humana es perfecta.

Conclusiones y discusión

En este post hemos dado unas pinceladas sobre cómo evaluar un LLM, especialmente con otros LLM como evaluadores. Podemos destacar los siguientes puntos:

• El lenguaje es subjetivo y complejo. Esto provoca que, a la hora de evaluar un texto generado, sean necesarias métricas distintas a las métricas clásicas de otros problemas de IA. Se requieren métricas que “entiendan” el texto.
• Emplear LLMs para evaluar otros LLMs es una práctica novedosa que facilita la automatización de la evaluación y el ciclo de vida de aplicaciones basadas en LLM. Como práctica novedosa, existe una continua investigación y seguirá teniendo una evolución a la vez que nacerán nuevos LLM más potentes que evalúen de una forma más “real” otros LLM.
• Evaluar un LLM con ese mismo LLM puede producir un cierto sesgo en las métricas como comprobamos en nuestra experiencia. Esto es un factor a tener en cuenta a la hora de diseñar nuestro flujo de evaluación.
• Evaluar con un LLM no es algo perfecto, pero hay que tener en cuenta que ni siquiera una evaluación humana lo es. Puede ser conveniente explorar estrategias híbridas para el registro de métricas, en las que intervengan LLMs y también humanos. Esta intervención humana puede realizarse mediante, por ejemplo, sistemas de Feedback, en los que usuarios del sistema basado en LLM den su visión de la calidad del contenido generado.

Referencias

• RAGAS
• BERTScore: Evaluating Text Generation with BERT
• Langfuse
• Langsmith
• DeepEval