Buenas prácticas de evaluación

Los resultados de la IA generativa pueden variar. A veces, un modelo produce salidas diferentes a partir de la misma entrada. Por eso, los métodos tradicionales de prueba de software son insuficientes para las arquitecturas de IA. Las evaluaciones (evals) te permiten poner a prueba tu sistema de IA a pesar de esta variabilidad.

Esta guía ofrece pautas generales para diseñar evaluaciones. Para empezar a usar la API de Evals, consulta la guía sobre cómo evaluar el rendimiento de los modelos.

¿Qué son las evaluaciones?

Las evaluaciones son pruebas estructuradas que miden el rendimiento de un modelo. Ayudan a garantizar la exactitud, el rendimiento y la confiabilidad a pesar del carácter no determinista de los sistemas de IA. También son una de las pocas formas de mejorar el rendimiento de una aplicación basada en LLM (mediante el ajuste fino).

Tipos de evaluaciones

El término “evals” puede referirse a lo siguiente:

• Pruebas de referencia de la industria para comparar modelos de forma aislada, como MMLU y las que aparecen en la tabla de clasificación de Hugging Face
• Puntuaciones numéricas estándar, como ROUGE y BERTScore, que puedes usar al diseñar evaluaciones para tu caso de uso
• Pruebas específicas que implementas para medir el rendimiento de tu aplicación basada en LLM

Esta guía se centra en el tercer tipo: el diseño de tus propias evaluaciones.

Cómo interpretar las evaluaciones

Es habitual que las puntuaciones de las evaluaciones estén entre 0 y 1. Una evaluación va más allá de la puntuación. Combina las métricas con el criterio humano para asegurarte de responder las preguntas pertinentes.

Diseña tu proceso de evaluación

Un flujo de trabajo de evaluación tiene varios componentes importantes:

1. Define el objetivo de la evaluación. ¿Cuáles son los criterios de éxito de la evaluación?
2. Reúne el conjunto de datos. ¿Qué datos te ayudarán a evaluar los resultados en función de tu objetivo? Considera datos de evaluación sintéticos, específicos del dominio, adquiridos o seleccionados por personas, así como datos de producción y datos históricos.
3. Define las métricas de evaluación. ¿Cómo comprobarás que se cumplen los criterios de éxito?
4. Ejecuta las evaluaciones y compara los resultados. Haz ajustes sucesivos para mejorar el rendimiento del modelo en tu tarea o sistema.
5. Evalúa de forma continua. Configura la evaluación continua (CE) para ejecutar las evaluaciones con cada cambio, monitorea tu aplicación para detectar nuevos casos de comportamiento no determinista y amplía el conjunto de evaluación con el tiempo.

Veamos algunos ejemplos.

Ejemplo: resumen de transcripciones

Para poner a prueba la capacidad de tu aplicación basada en LLM para resumir transcripciones, podrías diseñar la evaluación así:

1. Define el objetivo de la evaluación
   El modelo debería producir resúmenes comparables a los de referencia en pertinencia y exactitud.
2. Reúne el conjunto de datos
   Combina datos de producción (obtenidos de los comentarios de los usuarios sobre los resúmenes generados) con conjuntos de datos creados por especialistas del área (escritores) para determinar qué constituye un “buen” resumen.
3. Define las métricas de evaluación
   En un conjunto de 1000 pares de transcripciones y resúmenes de referencia reservado para la evaluación, la implementación debería alcanzar una puntuación ROUGE-L de al menos 0,40 y una puntuación de coherencia de al menos el 80 % con G-Eval.
4. Ejecuta las evaluaciones y compara los resultados
   Usa la API de Evals para crear y ejecutar evaluaciones en el panel de OpenAI.
5. Evalúa de forma continua
   Configura la evaluación continua (CE) para ejecutar las evaluaciones con cada cambio, monitorea tu aplicación para detectar nuevos casos de comportamiento no determinista y amplía el conjunto de evaluación con el tiempo.

Ejemplo: preguntas y respuestas sobre documentos

Para poner a prueba la capacidad de tu aplicación basada en LLM para responder preguntas sobre documentos, podrías diseñar la evaluación así:

1. Define el objetivo de la evaluación
   El modelo debería dar respuestas precisas, recuperar el contexto que necesite para razonar sobre los prompts del usuario y responder de manera que satisfaga la necesidad del usuario.
2. Reúne el conjunto de datos
   Combina datos de producción (obtenidos al medir la satisfacción de los usuarios con las respuestas a sus preguntas), respuestas correctas codificadas de antemano para preguntas creadas por especialistas del área y datos históricos de los registros.
3. Define las métricas de evaluación
   Una exhaustividad de recuperación del contexto de al menos 0,85, una precisión del contexto superior a 0,7 y al menos un 70 % de respuestas con valoración positiva.
4. Ejecuta las evaluaciones y compara los resultados
   Usa la API de Evals para crear y ejecutar evaluaciones en el panel de OpenAI.
5. Evalúa de forma continua
   Configura la evaluación continua (CE) para ejecutar las evaluaciones con cada cambio, monitorea tu aplicación para detectar nuevos casos de comportamiento no determinista y amplía el conjunto de evaluación con el tiempo.

Identifica dónde necesitas evaluaciones

La complejidad del sistema aumenta a medida que pasas de arquitecturas básicas a otras más elaboradas. Estos son cuatro patrones de arquitectura comunes:

• Interacciones de un solo turno con el modelo
• Flujos de trabajo
• Un solo agente
• Varios agentes

Revisa cada arquitectura para identificar en qué puntos de tu sistema puede surgir un comportamiento no determinista. Ahí es donde conviene implementar evaluaciones.

Interacciones de un solo turno con el modelo

En este tipo de arquitectura, el usuario proporciona datos de entrada al modelo. El modelo los procesa junto con los prompts que haya proporcionado el desarrollador y genera la salida correspondiente.

Ejemplo

Imagina una tienda en línea. El prompt del sistema le indica al modelo que clasifique la pregunta del cliente en una de las siguientes categorías:

• order_status
• return_policy
• technical_issue
• cancel_order
• other

Para que la experiencia del usuario sea uniforme y eficiente, el modelo debería devolver únicamente la etiqueta que corresponda a la intención del usuario. Supongamos que el cliente pregunta “¿Cuál es el estado de mi pedido?”.

Arquitecturas de flujos de trabajo

Para resolver problemas más complejos, probablemente pasarás de una interacción de un solo turno con el modelo a un flujo de trabajo de varios pasos que encadena varias llamadas al modelo. Los flujos de trabajo no introducen nuevas fuentes de comportamiento no determinista, pero implican varias interacciones con el modelo que puedes evaluar por separado.

Ejemplo

Retomemos el ejemplo del cliente que pregunta por el estado de su pedido. Una arquitectura de flujo de trabajo clasifica la solicitud del cliente y la dirige a un proceso que consta de estos pasos:

1. Extraer el ID del pedido
2. Consultar los detalles del pedido
3. Pasarle los detalles del pedido a un modelo para que genere la respuesta final

Cada paso del flujo de trabajo tiene su propio prompt del sistema. El modelo debe seguir esos prompts y presentar todos los datos recuperados en una respuesta fácil de entender.

Arquitecturas de un solo agente

A diferencia de los flujos de trabajo, los agentes resuelven problemas no estructurados que exigen flexibilidad al tomar decisiones. Un agente cuenta con instrucciones y un conjunto de herramientas. Decide sobre la marcha cuál usar, lo que introduce una nueva fuente de comportamiento no determinista.

Ejemplo

Adaptemos el ejemplo de atención al cliente para usar un solo agente. El agente tiene acceso a tres herramientas distintas:

• Herramienta de consulta de pedidos
• Herramienta de restablecimiento de contraseñas
• Herramienta de preguntas frecuentes sobre productos

Cuando el cliente pregunta por el estado de su pedido, el agente decide en ese momento si llama a una herramienta o le responde al cliente. Por ejemplo, si el cliente pregunta “¿Cuál es el estado de mi pedido?”, el agente ahora puede responderle pidiéndole el ID del pedido. Esto hace que la interacción sea más natural.

Arquitecturas de varios agentes

A medida que agregas herramientas y tareas a una arquitectura de un solo agente, al modelo puede resultarle difícil seguir las instrucciones o elegir la herramienta correcta. Las arquitecturas de varios agentes ayudan a resolver este problema al distribuir el trabajo entre agentes especializados en distintas áreas. La clasificación de las solicitudes y su transferencia entre agentes introducen una nueva fuente de comportamiento no determinista.

Ejemplo

Si dividimos las funciones del agente del ejemplo anterior entre varios agentes, tendremos cuatro agentes distintos:

1. Agente de clasificación
2. Agente de pedidos
3. Agente de gestión de cuentas
4. Agente de ventas

Cuando el cliente pregunta por el estado de su pedido, el agente de clasificación puede transferir la conversación al agente de pedidos para que consulte el pedido. Si el cliente cambia de tema y pregunta por un producto, el agente de pedidos debería devolver la solicitud al agente de clasificación, que a su vez la transfiere al agente de ventas para obtener información sobre el producto.

Crea y combina distintos tipos de evaluadores

Al diseñar tus propias evaluaciones, puedes elegir entre varios tipos de evaluadores. Para decidir cuál usar, piensa en la función que quieres que cumpla.

Evaluaciones basadas en métricas

Las evaluaciones cuantitativas generan una puntuación numérica que puedes usar para filtrar y ordenar los resultados. Ofrecen puntos de referencia útiles para las pruebas de regresión automatizadas.

• Ejemplos: coincidencia exacta, coincidencia de cadenas, puntuación ROUGE/BLEU, exactitud de las llamadas a funciones y evaluaciones ejecutables (se ejecutan para comprobar la funcionalidad o el comportamiento, como en text2sql)
• Dificultades: es posible que no se ajusten a un caso de uso concreto o que pasen por alto ciertos matices

Evaluaciones humanas

Las evaluaciones basadas en el criterio humano ofrecen la mayor calidad, pero son lentas y costosas.

• Ejemplos: revisa rápidamente las salidas del sistema para hacerte una idea de si han mejorado o empeorado. También puedes crear una prueba aleatorizada y a ciegas en la que empleados, contratistas o agencias externas de etiquetado juzguen la calidad de las salidas del sistema (por ejemplo, al ordenar un pequeño conjunto de salidas posibles por calidad o calificar cada una del 1 al 5)
• Dificultades: desacuerdos entre especialistas, costo elevado y lentitud
• Recomendaciones:
  • Realiza varias rondas de revisión humana detallada para afinar la guía de puntuación
  • Aplica el principio de “mostrar con ejemplos” e incluye muestras de distintos niveles de puntuación (por ejemplo, 1, 3 y 8 sobre 10)
  • Además de la puntuación numérica, incluye un umbral que determine si el resultado aprueba o no
  • Una forma de combinar las valoraciones de varias personas es someterlas a votación para llegar a un consenso

LLM como juez y calificadores basados en modelos

Usar modelos para juzgar las salidas cuesta menos y permite evaluar a mayor escala que la evaluación humana. Cuando necesites un LLM capaz de juzgar con rigor, empieza con gpt-6-astra. Antes de optimizar el costo o la latencia, comprueba que sus valoraciones concuerden con las etiquetas asignadas por personas.

• Ejemplos:
  • Comparación por pares: presenta dos respuestas al modelo juez y pídele que determine cuál es mejor según criterios específicos
  • Calificación de una sola respuesta: el modelo juez evalúa una respuesta de forma aislada y le asigna una puntuación o valoración según métricas de calidad predefinidas
  • Calificación con una respuesta de referencia: proporciona al modelo juez una respuesta de referencia o “respuesta ideal” para que la use como punto de comparación al evaluar la respuesta recibida
• Dificultades: sesgo de posición (influencia del orden de las respuestas) y sesgo de extensión (preferencia por las respuestas más largas)
• Recomendaciones:
  • Para obtener resultados más confiables, usa comparaciones por pares o calificaciones de aprobado o reprobado
  • Si puedes, usa el modelo más capaz para calificar. Empieza con gpt-6-astra y luego comprueba si un modelo de razonamiento especializado obtiene mejores resultados con tu rúbrica o conjunto de respuestas de referencia
  • Controla la longitud de las respuestas, ya que los LLM tienden a preferir las más largas
  • Incorpora el razonamiento y la cadena de pensamiento, ya que razonar antes de asignar una puntuación mejora el rendimiento de la evaluación
  • Amplía la escala de las evaluaciones cuando el LLM juez sea más rápido, cueste menos y sus valoraciones coincidan sistemáticamente con las anotaciones humanas
  • Estructura las preguntas de modo que puedas calificarlas automáticamente sin alterar la tarea. Un enfoque habitual es reformularlas como preguntas de opción múltiple
  • Asegúrate de que las rúbricas de evaluación sean claras y detalladas

Ninguna estrategia es perfecta. La calidad de las evaluaciones con un LLM como juez depende del contexto del problema. Por otro lado, recurrir a especialistas para asignar etiquetas de referencia es costoso y lleva tiempo.

Ten en cuenta los casos límite

Las evaluaciones deben cubrir los escenarios principales en los que cada arquitectura funciona según lo previsto. En la práctica, los sistemas de IA también se enfrentan con frecuencia a casos límite que ponen a prueba su rendimiento. Evaluar estos casos es importante para garantizar la confiabilidad y ofrecer una buena experiencia de usuario.

Estos casos límite suelen agruparse en varias categorías:

Variabilidad de las entradas

Como los usuarios proporcionan las entradas al modelo, el sistema debe ser lo bastante flexible para admitir distintas formas de interacción, entre ellas:

• Entradas en idiomas distintos del inglés o en varios idiomas
• Formatos distintos del texto simple (por ejemplo, XML, JSON, Markdown o CSV)
• Distintas modalidades de entrada (por ejemplo, imágenes)

Tus evaluaciones de seguimiento de instrucciones y corrección funcional deben contemplar las entradas que los usuarios podrían probar.

Complejidad del contexto

Muchas aplicaciones basadas en LLM fallan porque interpretan mal el contexto de la solicitud. Ese contexto puede provenir del usuario o incluir información irrelevante del historial de la conversación.

Algunos ejemplos son:

• Varias preguntas o intenciones en una sola solicitud
• Errores de escritura y de ortografía
• Solicitudes breves con muy poco contexto (por ejemplo, si el usuario solo dice “devoluciones”)
• Contextos extensos o conversaciones prolongadas
• Llamadas a herramientas que devuelven datos con nombres de propiedades ambiguos (por ejemplo, "on: 123", donde “on” indica el número de pedido)
• Varias llamadas a herramientas, que a veces dan lugar al uso de argumentos incorrectos
• Varias transferencias entre agentes, que a veces generan ciclos de transferencias

Personalización y adaptación

La IA mejora la experiencia del usuario al adaptarse a las solicitudes de cada persona, pero esa flexibilidad introduce muchos casos límite. Define con claridad las evaluaciones para los casos de uso que quieres admitir o bloquear de forma específica:

• Intentos de jailbreak para que el modelo haga algo distinto de lo previsto
• Solicitudes de formato (por ejemplo, dar formato JSON a la respuesta o usar viñetas)
• Casos en los que los prompts del usuario contradicen los prompts del sistema

Usa las evaluaciones para mejorar el rendimiento

Una vez que tus evaluaciones midan el rendimiento de forma consistente, empieza a usar los datos que generan para mejorar el rendimiento de tu aplicación.

Otros recursos

Para encontrar más ideas, visita el OpenAI Cookbook, que incluye ejemplos de código y enlaces a recursos de terceros, o consulta más información sobre nuestras herramientas de evaluación:

• Evaluación del rendimiento de los modelos
• Cómo evaluar una tarea de resumen
• Ajuste fino
• Calificadores
• Referencia de la API de Evals