Evaluar una aplicación basada en un gran modelo de lenguaje (LLM) consiste en probarla de forma sistemática, antes y después de cada modificación. La guía detalla cómo elegir los métodos de puntuación, diseñar un juez LLM fiable y luego evaluar los sistemas RAG y los agentes a lo largo del ciclo de publicación.
Leer algunas respuestas y encontrarlas satisfactorias no es suficiente. Una modificación del prompt, un cambio de modelo o de la búsqueda documental puede romper un comportamiento sin que nos demos cuenta, y luego resulta difícil determinar qué cambio es el responsable. Evaluar equivale a constituir casos de prueba, a puntuar cada respuesta según criterios escritos y luego comparar las puntuaciones antes y después de cada cambio, siguiendo el modelo de las pruebas de no regresión del código clásico.
Las respuestas de un LLM varían de una ejecución a otra, y la noción de «buena respuesta» depende del contexto. Una prueba unitaria verifica una igualdad, mientras que «Puede devolver zapatos en un plazo de 30 días» y «Se aceptan devoluciones durante un mes tras la entrega» son ambas correctas. La guía distingue la evaluación, que mide una calidad relativa según criterios difusos, de las pruebas, que validan una puesta en producción mediante controles binarios, como un JSON válido o la ausencia de una fórmula prohibida. Bloquear un despliegue por una puntuación de fidelidad de 0,7 equivaldría, según el autor, a debatir cada semana sobre un umbral arbitrario.
Tres formas de puntuar una respuesta
Un evaluador recibe un caso de prueba, compuesto por una entrada, una respuesta y a veces un contexto o una referencia, y luego devuelve un veredicto o un número. Los evaluadores de código aplican reglas deterministas, para verificar el formato, la longitud o la presencia de ciertas cadenas. Los evaluadores basados en una referencia comparan la respuesta con una respuesta conocida. Las métricas de superposición como BLEU y ROUGE, por ejemplo, no reconocen una paráfrasis correcta. El juez LLM, finalmente, es un modelo encargado de aplicar una rejilla de criterios a la respuesta de otro modelo, útil para el tono, el anclaje en las fuentes o la utilidad.
La guía recomienda empezar por el código en todas partes donde una regla sea suficiente, ya que estos evaluadores no cuestan nada y dan siempre el mismo resultado. Se describen tres configuraciones de juez: puntual, donde atribuye una etiqueta o una nota a una respuesta aislada; por pares, donde elige la mejor de dos respuestas, método común para comparar dos prompts o dos modelos; y guiada por referencia, cuando dispone de una respuesta de referencia.
Hacer fiable al juez
Una rejilla de criterios bien redactada decide la calidad del juez. La guía la describe en cuatro partes: la definición del criterio, los datos que el juez puede utilizar, el procedimiento a seguir y un formato de salida estricto, preferiblemente en JSON. El razonamiento debe preceder al veredicto, y la temperatura se fija a 0 para reducir el ruido de muestreo, sin eliminarlo. Para los criterios sensibles, la guía sugiere un número impar de ejecuciones y retener el veredicto mayoritario.
El método QAG (generación de preguntas-respuestas) pide al juez que responda a preguntas cerradas por sí o por no, calculándose luego el resultado mediante código. La fidelidad de una respuesta de cuatro afirmaciones de las cuales tres están respaldadas vale así 0,75. Para los criterios subjetivos, el método G-Eval calcula una media ponderada por las probabilidades de las notas posibles, de modo que un modelo repartido 60/40 entre 4 y 5 obtiene 4,4. Se documentan sesgos en trabajos de investigación sobre el juicio de las salidas de LLM: sesgo de posición, sesgo de verbosidad y sesgo de autopreferencia para los modelos de la misma familia. La guía propone invertir el orden de las respuestas, probar casos de longitud comparable y usar un juez procedente de otra familia de modelos.
La calibración sigue siendo la etapa más importante. La guía aconseja etiquetar uno mismo de 30 a 50 respuestas, y luego comparar estas etiquetas con las del juez mediante el kappa de Cohen, que corrige el acuerdo debido al azar. Una puntuación de 0 corresponde a un acuerdo al nivel del azar, y 1 a un acuerdo perfecto. Más allá de aproximadamente 0,6, el acuerdo se considera generalmente sustancial.
RAG, agentes y ciclo de publicación
Un sistema RAG (generación aumentada por recuperación) combina dos componentes que pueden fallar por separado: el motor de búsqueda, que recupera el contexto, y el generador, que redacta la respuesta. La guía propone medir la precisión del contexto, su recuperación, la fidelidad de la respuesta a los documentos recuperados y su pertinencia respecto a la pregunta. Una fidelidad alta asociada a una recuperación baja señala, por ejemplo, una búsqueda insuficiente.
Para los agentes, la guía empieza por la realización de la tarea, luego examina la exactitud de la herramienta elegida, la de sus argumentos y la trayectoria seguida, sin llamadas redundantes ni bucles. Las evaluaciones fuera de línea se hacen antes de la puesta en producción, sobre un conjunto de 25 a 50 casos versionados, con criterios de publicación fijados de antemano. Las evaluaciones en línea se realizan sobre una muestra del tráfico real. Cada fallo observado en producción puede luego convertirse en un caso de prueba de referencia.
