1. La evaluación es el pastel, ya no la guinda.
La evaluación siempre ha sido importante en el desarrollo de ML, sea LLM o no. Pero yo diría que es muy importante en el desarrollo de un LLM por dos razones:
a) El importancia relativa de evaluación aumenta porque hay menores grados de libertad en la creación de aplicaciones LLM, lo que hace que el tiempo dedicado al trabajo no evaluado disminuya. En el desarrollo de LLM, basándose en modelos fundamentales como GPT de OpenAI o los modelos Claude de Anthropic, hay menos controles disponibles para modificar en la capa de aplicación. Y estas perillas son mucho más rápidas de ajustar (advertencia: más rápido de ajustar, no necesariamente más rápido de hacerlo bien). Por ejemplo, se puede decir que cambiar el mensaje es mucho más rápido de implementar que escribir una nueva característica hecha a mano para un árbol de decisión impulsado por gradiente. Por lo tanto, hay menos trabajo no evaluado por hacer, lo que hace que aumente la proporción de tiempo dedicado a la evaluación.
segundo) el importancia absoluta de eval aumenta porque hay mayores grados de libertad en la salida de la IA generativa, lo que hace que eval sea una tarea más compleja. A diferencia de las tareas de clasificación o ranking, las tareas de IA generativa (por ejemplo, escribir un ensayo sobre X, hacer una imagen de Y, generar una trayectoria para un vehículo autónomo) pueden tener un número infinito de resultados aceptables. Por tanto, la medición es un proceso de proyección de un espacio de altas dimensiones hacia dimensiones inferiores. Por ejemplo, para una tarea de LLM, se puede medir: “¿El texto resultante es real?”, “¿El resultado contiene contenido dañino?”, “¿El lenguaje es conciso?”, “¿Empieza con ‘ciertamente!’ ¿demasiado a menudo?”, etc. Si la precisión y la recuperación en una tarea de clasificación binaria son mediciones sin pérdidas de esas salidas binarias (que miden lo que ve), las métricas de ejemplo que enumeré anteriormente para una tarea de LLM son mediciones con pérdida del texto de salida ( medir una representación de baja dimensión de lo que ves). Y eso es mucho más difícil de hacer bien.
Este cambio de paradigma tiene implicaciones prácticas en el tamaño y la contratación del equipo cuando se dota de personal a un proyecto en la aplicación LLM.
2. Compare la diferencia.
Este es el escenario soñado: subimos a una métrica objetivo y seguimos mejorándola.
¿La realidad?
¡Apenas puedes dibujar más de 2 puntos consecutivos en el gráfico!
Quizás estos te suenen familiares:
Después del primer lanzamiento, adquirimos un conjunto de datos mucho más grande, por lo que el nuevo número de métrica ya no es una comparación de manzana con manzana con el número anterior. Y no podemos volver a ejecutar el modelo anterior en el nuevo conjunto de datos; tal vez otras partes del sistema se hayan actualizado y no podamos verificar el compromiso anterior para reproducir el modelo anterior; tal vez la métrica de evaluación sea un LLM como juez y el conjunto de datos sea enorme, por lo que cada ejecución de evaluación es prohibitivamente costosa, etc.
Después del segundo lanzamiento, decidimos cambiar el esquema de salida. Por ejemplo, anteriormente, le indicamos al modelo que generara una respuesta de sí o no; ahora le indicamos al modelo que genere sí / no / tal vez / no lo sé. Por lo tanto, el conjunto de verdades fundamentales previamente cuidadosamente seleccionado ya no es válido.
Después del tercer lanzamiento, decidimos dividir las convocatorias LLM individuales en una combinación de dos convocatorias y necesitamos evaluar el subcomponente. Necesitamos nuevos conjuntos de datos para la evaluación del subcomponente.
….
La cuestión es que el ciclo de desarrollo en la era de los LLM suele ser demasiado rápido para realizar un seguimiento longitudinal de la misma métrica.
Entonces ¿cuál es la solución?
Mide el delta.
En otras palabras, haz las paces con tener solo dos puntos consecutivos en ese gráfico. La idea es asegurarse de que cada versión del modelo sea mejor que la versión anterior (hasta donde usted sepa en ese momento), aunque es bastante difícil saber cuál es su rendimiento en términos absolutos.
Supongamos que tengo un tutor de idiomas basado en un LLM que primero clasifica la entrada como inglés o español y luego ofrece consejos gramaticales. Una métrica simple puede ser la precisión de la etiqueta “inglés/español”. Ahora, digamos que hice algunos cambios en el mensaje y quiero saber si el nuevo mensaje mejora la precisión. En lugar de etiquetar manualmente un gran conjunto de datos y calcular la precisión en él, otra forma es centrarse simplemente en los puntos de datos donde las indicaciones antiguas y nuevas producen etiquetas diferentes. De esta manera no podré conocer la precisión absoluta de ninguno de los modelos, pero sabré qué modelo tiene mayor precisión.
Debo aclarar que no estoy diciendo que comparar lo absoluto no tenga méritos. Sólo digo que debemos ser conscientes del costo de hacerlo, y comparar el delta (aunque no sea un sustituto completo) puede ser una forma mucho más rentable de obtener una conclusión direccional. Una de las razones más fundamentales de este cambio de paradigma es que si estás construyendo tu modelo de ML desde cero, a menudo tienes que seleccionar un gran conjunto de entrenamiento de todos modos, por lo que el conjunto de datos de evaluación a menudo puede ser un subproducto de eso. Este no es el caso del aprendizaje de tiro cero y de pocos tiros en modelos previamente entrenados (como los LLM).
Como segundo ejemplo, quizás tenga una métrica basada en LLM: usamos un LLM separado para juzgar si la explicación producida en mi tutor de idiomas de LLM es lo suficientemente clara. Uno podría preguntarse: “Dado que la evaluación ahora está automatizada, ¿la evaluación comparativa del delta sigue siendo más barata que la evaluación comparativa del absoluto?” Sí. Debido a que la métrica es más complicada ahora, puede seguir mejorándola (por ejemplo, diseñar rápidamente la métrica basada en LLM). Por un lado, todavía necesitamos evaluar la evaluación; La evaluación comparativa de los deltas le indica si la nueva versión métrica es mejor. Por otro lado, a medida que evoluciona la métrica basada en LLM, no tenemos que preocuparnos por completar los resultados de referencia de todas las versiones antiguas del tutor de idiomas LLM con la nueva versión de métrica basada en LLM, si solo nos enfocamos en comparar dos versiones adyacentes. de los modelos de tutores de idiomas LLM.
La evaluación comparativa de los deltas puede ser un mecanismo eficaz de iteración rápida de bucle interno, al tiempo que se ahorra la forma más costosa de comparar el seguimiento absoluto o longitudinal para las iteraciones de cadencia más baja del bucle externo.
3. Adoptar el triaje humano como parte integral de la evaluación.
Como se mencionó anteriormente, el sueño de evaluar cuidadosamente un conjunto dorado de una vez por todas para que pueda usarse como un punto de referencia imperecedero puede ser inalcanzable. La clasificación será una parte integral y continua del proceso de desarrollo, ya sea que se trate del resultado del LLM directamente o de los jueces del LLM u otros tipos de métricas más complejas. Deberíamos seguir haciendo que eval sea lo más escalable posible; El punto aquí es que, a pesar de eso, no debemos esperar la eliminación del triaje humano. Cuanto antes aceptemos esto, antes podremos realizar las inversiones adecuadas en herramientas.
Como tal, independientemente de las herramientas de evaluación que utilicemos, internas o no, debería haber una interfaz sencilla para la clasificación humana. Una interfaz simple puede verse como la siguiente. Combinado con el punto anterior sobre la evaluación comparativa de la diferencia, tiene un panel de lado a lado y puede hojear fácilmente los resultados. También debería permitirle registrar fácilmente sus notas clasificadas de modo que puedan reciclarse como etiquetas doradas para futuras evaluaciones comparativas (y, por lo tanto, reducir la carga de clasificación futura).
Idealmente, una versión más avanzada sería una prueba a ciegas, en la que el evaluador desconoce qué lado es cuál. Hemos confirmado repetidamente con datos que cuando no realizan pruebas a ciegas, los desarrolladores, incluso con las mejores intenciones, tienen sesgos subconscientes que favorecen la versión que desarrollaron.