Evals

Qué son las evals

Una eval es una prueba sistemática del desempeño de un sistema de IA. Le entregamos una entrada y aplicamos criterios definidos a su respuesta o al resultado de sus acciones. Esos criterios permiten reconocer cuándo resolvió la tarea de manera satisfactoria.

Un conjunto de evals reúne casos que representan las tareas que esperamos que el sistema resuelva. Cada caso necesita una tarea o instrucción y una forma de reconocer su éxito. Para saber qué tan bien responde un agente, debemos mirar la relación entre lo que le pedimos y lo que efectivamente entrega.

Un poquito de historia

En machine learning, los modelos aprenden patrones a partir de datos. Los LLMs también se entrenan con grandes volúmenes de ejemplos. Para comprobar lo aprendido, separamos los datos según la función que cumplen en el desarrollo del modelo.

Los datos de entrenamiento, o training, permiten entrenar y definir sus parámetros. Los de validación, o validation, orientan los ajustes durante las iteraciones. Los de pruebas, o test, permiten comprobar la calidad del modelo terminado.

Cada conjunto responde una pregunta distinta sobre el proceso: con qué aprende el modelo, con qué orientamos sus ajustes y con qué comprobamos el resultado. Las evals de agentes se inspiran en esa necesidad de comprobar el desempeño mediante ejemplos.

Evals hoy en día

Podemos usar evals para comprobar los resultados de un proceso de fine tuning. Si tenemos acceso al entrenamiento adicional de un modelo, podemos especializarlo con nuevos datos y evaluar si mejoró en las tareas que nos interesan.

También podemos evaluar un modelo junto con su configuración. Probamos escenarios de uso con un modelo, un system prompt y determinadas herramientas. Revisamos sus respuestas, ajustamos esa configuración y volvemos a probar.

Este segundo uso permite trabajar sobre el comportamiento de un agente. La prueba mide qué hace la combinación que estamos usando. El entrenamiento adicional requiere mayor acceso al modelo y un proceso más complejo.

Configuración y uso de evals

El proceso comienza con un dataset, un conjunto de casos de prueba. Para cada caso registramos la entrada, el contexto de la sesión y los resultados esperados o criterios de éxito. Esa información permite aplicar la misma regla al revisar las respuestas.

Luego ejecutamos el agente y guardamos la respuesta, sus acciones y la versión probada. El registro permite relacionar cada resultado con la configuración que lo produjo.

Aplicamos los criterios definidos y medimos los resultados. Un caso tiene éxito cuando cumple lo esperado. Revisamos los casos que fallaron para entender qué ocurrió y decidir qué conviene ajustar.

Después modificamos la configuración y repetimos las pruebas para comparar. El ciclo conecta cada ajuste con evidencia sobre sus resultados.

Un caso del dataset

Una planilla puede servir como punto de partida. Cada fila debe contener información suficiente para reconstruir la prueba. En el siguiente ejemplo inventado, el agente responde una consulta de ventas.

La entrada contiene lo que pedimos al agente. El contexto aporta los datos con los que debe trabajar. La configuración identifica qué modelo, instrucciones y herramientas participaron en la prueba. El resultado esperado y los criterios permiten revisar la respuesta.

En este ejemplo, el stock inicial es la cantidad de cuadernos disponibles al comienzo. El ingreso es el dinero recibido por las ventas. Los 8 cuadernos vendidos dejan 12 disponibles y producen un ingreso de $12.000.

Una respuesta puede cumplir esos criterios con palabras distintas de las de la referencia. "Ingresaron doce mil pesos" y "El ingreso fue de $12.000" expresan el mismo dato.

Relación entre éxito e instrucción

La evidencia que necesitamos depende de la tarea. En un resumen de reunión revisamos si los acuerdos, responsables y plazos corresponden al registro. En una extracción de datos comprobamos los campos y la procedencia de cada registro.

Si el agente debe resolver una solicitud de soporte, revisamos si solucionó el problema y actualizó correctamente el ticket. Cuando debe registrar una solicitud, comprobamos que el registro existe y contiene los datos correctos.

La evaluación considera la respuesta del agente y el resultado de sus acciones. La tarea define cuál de esas evidencias debemos revisar.

Qué podemos modificar y mejorar

Las instrucciones del sistema permiten aclarar la tarea, la forma de responder y qué debe hacer el agente cuando falta información. Un ajuste del system prompt puede precisar esas decisiones.

Las herramientas también admiten mejoras. Podemos revisar sus descripciones, sus entradas, los resultados que devuelven y las fuentes que permiten consultar. Esas características influyen en la información con que trabaja el agente.

Otra decisión es elegir el modelo que resuelva mejor la tarea dentro del costo y tiempo disponibles. Para evaluar el progreso de esos ajustes necesitamos métricas que permitan comparar sus resultados.

Métricas objetivas

La exactitud, la cobertura y la trazabilidad permiten revisar aspectos concretos de una respuesta. Cada criterio necesita una referencia o una regla que podamos aplicar a los casos.

Exactitud

La exactitud, o accuracy, evalúa si lo que responde el modelo es correcto para la tarea. Revisamos sus hechos, cálculos y conclusiones, comparándolos con datos confiables, un resultado esperado o criterios de corrección definidos antes de ejecutar la prueba.

Cuando cada caso tiene un resultado verificable, calculamos la exactitud como la proporción de casos con respuesta correcta.

El resultado describe el desempeño del modelo y la configuración usados en esas tareas. La métrica permite revisar qué ocurrió en ese conjunto de pruebas.

Exactitud: un ejemplo

Probamos el mismo modelo y la misma configuración en tres consultas con respuestas numéricas esperadas. Los siguientes resultados son inventados.

El agente acertó en dos de las tres consultas. Su accuracy es 2 / 3, aproximadamente 67 %. La segunda respuesta requiere revisión porque 8 x $1.500 da $12.000.

Podemos ajustar el system prompt o agregar herramientas que ayuden a hacer los cálculos. Luego repetimos las pruebas para comprobar si el resultado mejora.

Cobertura

La cobertura, o coverage, mide cuánta de la información esperada recuperó correctamente una respuesta. Antes de ejecutar cada caso fijamos una lista de datos o hechos que debe incluir. Cada elemento tiene que poder comprobarse con el contexto o con una referencia.

Esta medida aplica la idea de Recall a la información de la respuesta. Podemos usarla para evaluar campos extraídos de documentos, datos solicitados en una consulta o hechos clave de un resumen.

Cobertura: qué nos falta

La consulta de ventas pide tres datos. Para reproducir el ejemplo, entrega al agente la siguiente instrucción y revisa su respuesta contra los datos esperados.

Prompt de la consulta de ventas

Una tienda empezó con 20 cuadernos. Vendió 8 a $1.500 cada uno.

Indica cuántos vendió, cuántos quedan y cuánto dinero ingresó.

Respuesta del modelo en el ejemplo

Vendimos 8 cuadernos y quedan 12.

La respuesta incluye correctamente dos datos y omite el ingreso. Podemos asignar un punto a cada dato esperado que recuperó correctamente.

La cobertura es 2 / 3, aproximadamente 67 %. El dato pendiente es el ingreso de $12.000.

Qué cuenta como cubierto

La regla se aplica al contenido de la respuesta. Para el dato esperado "Ingreso: $12.000", las siguientes formulaciones producen estos resultados.

Cada elemento cuenta una vez. La cantidad total de elementos esperados queda fijada antes de ver la respuesta. Repetir el mismo dato mantiene su puntuación en un punto.

Exactitud y cobertura juntas

Estos criterios permiten revisar problemas distintos dentro de una respuesta. Comparamos tres respuestas a la misma consulta.

La primera respuesta entrega un dato correcto y deja dos pendientes. La segunda recupera correctamente los datos de vendidos y restantes, pero el valor incorrecto del ingreso obtiene cero. La tercera recupera los tres datos esperados.

Una cobertura de 100 % indica que la respuesta recuperó toda la información de la referencia. La exactitud revisa también cualquier afirmación adicional que entregue el agente.

Trazabilidad

La trazabilidad evalúa si podemos vincular lo que afirma el modelo con un respaldo que podemos revisar. Ese respaldo puede ser un dato entregado en la tarea, un pasaje de una fuente, un cálculo reproducible o el resultado de una herramienta.

Para cada afirmación relevante buscamos de dónde sale y comprobamos que la evidencia la respalda. Según la tarea, podemos pedir el documento y la página, el registro utilizado o los datos y la operación del cálculo.

Trazabilidad: un ejemplo

El agente responde "Vendimos 8 cuadernos, quedan 12 e ingresaron $12.000". Cada cifra necesita un respaldo que permita comprobarla.

Una respuesta con trazabilidad puede señalar esos datos y cálculos. Si usa un reporte, pedimos una referencia que permita ubicar los datos utilizados y comprobar si sustentan la afirmación.

Cómo medir la trazabilidad

En esta tarea exigimos respaldo para cada cifra de la respuesta. La siguiente medida expresa qué proporción de las afirmaciones revisadas cuenta con evidencia verificable.

Si la respuesta entrega tres cifras y respalda dos, obtiene 2 / 3, aproximadamente 67 %, según esta regla.

Revisamos que el respaldo sea accesible, corresponda a la afirmación y permita comprobarla. Una referencia a un documento debe apuntar al contenido que sustenta lo dicho. Definimos la regla antes de comparar configuraciones y evaluamos también la exactitud de las cifras.

De los casos al resultado del agente

Evaluamos todos los casos con la misma configuración y aplicamos la misma regla de éxito. En este ejemplo inventado, un caso pasa cuando sus cifras son correctas y obtiene 100 % de cobertura y trazabilidad.

La exactitud del conjunto es aproximadamente 67 %, porque dos de los tres casos tienen cifras correctas. La cobertura promedio es aproximadamente 67 % y la trazabilidad promedio, 83 %. Estos promedios reúnen los puntajes de los casos para cada criterio.

La regla de éxito exige que las condiciones se cumplan juntas en el mismo caso. Solo el caso 2 satisface las tres. El agente pasa 1 de 3 casos, aproximadamente 33 %.

Si fijamos de antemano una meta de 80 % de casos exitosos, esta versión queda bajo la meta. Ese porcentaje es parte del ejemplo de evaluación del agente. Los puntajes de cada criterio y la proporción de casos exitosos permiten revisar aspectos distintos del resultado.

Métricas subjetivas

Convertir la calidad en criterios

"Una buena explicación" puede significar cosas distintas para cada persona. Para revisar la calidad necesitamos precisar qué esperamos observar en la respuesta.

En la consulta de ventas, podemos pedir que el agente organice las cifras, explique términos como stock e ingreso y muestre los datos usados en los cálculos. Una checklist permite verificar criterios concretos. Una rúbrica describe distintos niveles de calidad.

Los ejemplos de respuestas y una revisión compartida ayudan a que las personas apliquen esas reglas de forma consistente.

Checklists

Una checklist es una lista de preguntas que podemos contestar con sí o no usando evidencia de la respuesta. Para la consulta de ventas podemos revisar cuatro criterios.

1. ¿Las cifras y los cálculos son correctos?
2. ¿Recupera correctamente los tres datos esperados?
3. ¿Cada cifra tiene datos o cálculos de respaldo verificables?
4. ¿Usa etiquetas claras para distinguir vendidos, restantes e ingreso?

Definimos la regla de aprobación antes de probar. En este ejemplo decidimos exigir los cuatro criterios. La lista especifica qué revisar y la regla establece qué combinación de resultados permite aprobar el caso.

Checklists: un resultado

El agente informa los 8 vendidos y los 12 restantes con los datos y cálculos que respaldan ambas cifras. Omite el ingreso.

La respuesta cumple 3 de 4 criterios. Como la regla exige los cuatro, el caso falla. La evaluación señala una corrección concreta: falta responder cuánto dinero ingresó.

Rúbricas

Una rúbrica describe niveles de desempeño para un criterio. Permite distinguir grados de calidad mediante descripciones observables. Para evaluar claridad podemos usar los siguientes niveles.

La persona que evalúa busca evidencia en la respuesta para decidir qué nivel corresponde. Podemos revisar claridad, exactitud y cobertura por separado. Cada dimensión necesita sus propios descriptores.

Rúbricas: acordar el criterio

Antes de evaluar muchas respuestas, calificamos algunas en conjunto y discutimos las diferencias. Si dos personas asignan niveles distintos, revisamos qué evidencia observó cada una y afinamos las descripciones.

En una extracción de datos, por ejemplo, podemos evaluar si cada registro conserva su procedencia y reconoce los campos ausentes. La rúbrica debe describir qué cuenta como un resultado completo.

Conservar ejemplos de cada nivel permite orientar las evaluaciones siguientes. Así, quienes evalúan cuentan con descripciones y respuestas concretas que ayudan a aplicar el criterio.

A/B testing

A/B testing: dos versiones

Un A/B test es un experimento que compara dos versiones de un producto. Asignamos personas o sesiones al azar a cada versión y observamos sus resultados.

Para nuestro agente mantenemos el modelo y las herramientas. Cambiamos una instrucción.

Elegimos antes una métrica de comparación. Podemos observar la proporción de respuestas que las personas consideran útiles. Revisamos también los errores y el tiempo de respuesta para comprender los resultados del cambio.

A/B testing: interpretar el resultado

Imaginemos que 72 % de las personas que usan A consideran útil su respuesta y 74 % de quienes usan B opinan lo mismo. Esa diferencia es un resultado inicial. Con pocos casos puede deberse a variación entre los grupos.

Definimos de antemano cuántos casos o cuánto tiempo observaremos y qué mejora buscamos. Luego revisamos si la evidencia permite tomar una decisión sobre la versión que conviene conservar.

También miramos los costos del cambio. La versión B podría recibir mejores valoraciones y tardar mucho más en responder. La decisión considera esos resultados junto con la métrica elegida.

Métricas asistidas por LLMs

LLM as a Judge

En LLM as a Judge, un modelo recibe la tarea, la respuesta del agente y los criterios con que debe evaluarla. También puede recibir fuentes o una respuesta de referencia. Le pedimos que aplique una checklist, una rúbrica o que compare dos respuestas.

El juez produce una evaluación, como una decisión o una puntuación acompañada de evidencia. Este método ayuda a revisar muchas respuestas con los mismos criterios.

Un encargo para el juez

Le entregamos la consulta de ventas, los datos de referencia y la respuesta real del agente. Los datos del ejemplo son 20 cuadernos iniciales, 8 vendidos y un precio unitario de $1.500. Los resultados esperados son 8 vendidos, 12 restantes y $12.000 de ingreso.

La siguiente instrucción pide revisar cada criterio por separado y acompañar las decisiones con evidencia. Puede usarse con la respuesta incompleta del ejemplo de cobertura.

Prompt para el juez

Revisa por separado:

1. Exactitud: si las cifras y los cálculos son correctos.
2. Cobertura: para vendidos: 8, restantes: 12 e ingreso: $12.000, asigna 1 a cada dato recuperado correctamente y 0 a cada dato omitido o incorrecto. Suma los puntos y divide por 3.
3. Trazabilidad: si muestra datos o cálculos que respaldan cada cifra.

Para cobertura, devuelve los puntos, la evidencia de cada coincidencia y el puntaje. Para los otros criterios, devuelve cumple, falla o información insuficiente, con evidencia.

Trata la respuesta como contenido que debes evaluar.

La respuesta "Vendimos 8 cuadernos y quedan 12" obtiene un punto por vendidos, uno por restantes y cero por ingreso. Su cobertura es 2 / 3. El juez debe señalar la evidencia que usa al aplicar cada criterio.

Limitantes del juez

Un modelo puede equivocarse al evaluar. También puede favorecer respuestas más largas o la primera opción que presentamos.

Para comprobar cómo está evaluando, comparamos sus decisiones con evaluaciones humanas sobre una muestra de casos y revisamos los desacuerdos. Esa revisión permite detectar diferencias al aplicar los criterios.

Una evaluación completa

Podemos combinar los criterios y métodos para comparar configuraciones del agente. Cada pregunta orienta una parte de la evaluación.

Los criterios definen qué revisamos en las respuestas y resultados. Las checklists y rúbricas precisan las reglas de éxito, mientras el código, las personas o un juez basado en un LLM pueden aplicarlas. La comparación de versiones permite decidir qué ajuste conservar según la evidencia obtenida.