Sobre la idea de utilizar IA para evaluar la IA, también conocida como “LLM-as-a-Judge”, mi reacción fue:
“Está bien, oficialmente hemos perdido la cabeza”.
Vivimos en un mundo donde incluso el papel higiénico se comercializa como “impulsado por IA”. Supuse que se trataba simplemente de otra tendencia impulsada por las exageraciones en nuestro caótico y vertiginoso panorama de la IA.
Pero una vez que analicé lo que realmente significa LLM como juez, me di cuenta de que estaba equivocado. Déjame explicarte.
Hay una imagen que todo científico de datos e ingeniero de aprendizaje automático debe tener en cuenta y que captura todo el espectro de complejidad del modelo, tamaño del conjunto de entrenamiento y nivel de rendimiento esperado:
Si la tarea es sencilla, tener un pequeño conjunto de entrenamiento no suele ser un problema. En algunos casos extremos, incluso puedes resolverlo con un enfoque simple basado en reglas. Incluso cuando la tarea se vuelve más compleja, a menudo puedes alcanzar un alto rendimiento siempre que tengas un conjunto de entrenamiento amplio y diverso.
El verdadero problema comienza cuando la tarea es compleja y no se tiene acceso a un conjunto de capacitación integral. En ese momento, no existe una receta limpia. Necesita expertos en el dominio, recopilación manual de datos y procedimientos de evaluación cuidadosos y, en las peores situaciones, podría enfrentar meses o incluso años de trabajo solo para crear etiquetas confiables.
… esto fue antes de los modelos de lenguajes grandes (LLM).
El paradigma del LLM como juez
La promesa de los LLM es simple: obtienes algo cercano a la experiencia de “nivel de doctorado” en muchos campos a los que puedes llegar a través de una única llamada API. Podemos (y probablemente deberíamos) discutir sobre cuán “inteligentes” son realmente estos sistemas. Cada vez hay más pruebas de que un LLM se comporta más como un comparador de patrones y un recuperador de información extremadamente potente que como un agente verdaderamente inteligente. [you should absolutely watch this].
Sin embargo, una cosa es difícil de negar. Cuando la tarea es compleja, difícil de formalizar y no se cuenta con un conjunto de datos listo para usar, los LLM pueden resultar increíblemente útiles. En estas situaciones, le brindan razonamiento de alto nivel y conocimiento del dominio a pedido, mucho antes de que pueda recopilar y etiquetar suficientes datos para entrenar un modelo tradicional.
Así que volvamos a nuestro cuadrado rojo del “gran problema”. Imagine que tiene un problema difícil y sólo una primera versión muy aproximada de un modelo. Tal vez fue entrenado en un pequeño conjunto de datos, o tal vez sea un modelo preexistente que no ha ajustado en absoluto (por ejemplo, BERT o cualquier otro modelo de integración).
En situaciones como esta, puede utilizar un LLM para evaluar el rendimiento de este modelo V0. El LLM se convierte en el evaluador (o juez) de su prototipo inicial, brindándole retroalimentación inmediata sin requerir un gran conjunto de datos etiquetados ni el gran esfuerzo que mencionamos anteriormente.
Esto tendría muchas aplicaciones beneficiosas posteriores:
Evaluar el estado del V0 y su rendimiento Construir un conjunto de entrenamiento para mejorar el modelo existente Monitorear la etapa del modelo existente o la versión ajustada (siguiendo el punto 2).
¡Así que construyamos esto!
LLM como juez en producción
Ahora hay un silogismo falso: como no es necesario capacitar a un LLM y su uso es intuitivo en la interfaz de usuario ChatGPT/Anthropic/Gemini, entonces debe ser fácil construir un sistema LLM. Ese no es el caso.
Si su objetivo no es una simple función plug-and-play, entonces necesita un esfuerzo activo para asegurarse de que su LLM sea confiable, preciso y lo más libre de alucinaciones posible, diseñándolo para que falle elegantemente cuando falle (no si, sino cuándo).
Estos son los temas principales que cubriremos para construir un sistema LLM como juez listo para producción.
Diseño del sistema
Definiremos el rol del LLM, cómo debe comportarse y qué perspectiva o “persona” debe utilizar durante la evaluación. Ejemplos de pocas tomas
Le daremos al LLM ejemplos concretos que muestran exactamente cómo debe verse la evaluación para diferentes casos de prueba. Desencadenando la cadena de pensamiento
Le pediremos al LLM que produzca notas, razonamiento intermedio y un nivel de confianza para desencadenar una forma más confiable de cadena de pensamiento. Esto anima al modelo a “pensar” realmente. Evaluación de lotes
Para reducir el costo y la latencia, enviaremos múltiples entradas a la vez y reutilizaremos el mismo mensaje en un lote de ejemplos. Formato de salida
Usaremos Pydantic para aplicar un esquema de salida estructurado y proporcionar ese esquema directamente al LLM, lo que hace que la integración sea más limpia y segura para la producción.
¡Vamos a sumergirnos en el código! 🚀
Código
El código completo se puede encontrar en la siguiente página de GitHub. [here]. Voy a repasar las partes principales en el siguiente párrafo.
1. Configuración
Comencemos con algunas tareas domésticas.
El trabajo sucio del código se realiza con OpenAI y se empaqueta con llm_judge. Por esta razón lo único que necesitas para importar es el siguiente bloque:
Nota: Necesitará la clave API de OpenAI.
Todo el código de nivel de producción se maneja en el backend (gracias más tarde). Sigamos adelante.
2. Nuestro caso de uso
Digamos que tenemos un modelo de clasificación de sentimientos que queremos evaluar. El modelo toma opiniones de los clientes y predice: Positivo, Negativo o Neutral.
Aquí hay datos de muestra que nuestro modelo clasificó:
Para cada predicción, queremos saber:
– ¿Es correcta esta salida?
– ¿Qué tan seguros estamos de ese juicio?
– ¿Por qué es correcto o incorrecto?
– ¿Cómo calificaríamos la calidad?
Aquí es donde entra en juego LLM-as-a-Judge. Observe que ground_truth en realidad no está en nuestro conjunto de datos del mundo real; Es por eso que utilizamos LLM en primer lugar. 🙃
La única razón por la que lo ve aquí es para mostrar las clasificaciones en las que nuestro modelo original tiene un rendimiento inferior (índice 2 e índice 3).
Tenga en cuenta que en este caso, pretendemos tener un modelo más débil con algunos errores. En un caso real, esto sucede cuando se utiliza un modelo pequeño o se adapta un modelo de aprendizaje profundo no ajustado.
3. Definición de roles
Al igual que con cualquier ingeniería rápida, debemos definir claramente:
1. ¿Quién es el juez? El LLM actuará como tal, por lo que debemos definir su experiencia y antecedentes.
2. ¿Qué están evaluando? La tarea específica que queremos que evalúe el LLM.
3. ¿Qué criterios deberían utilizar? Qué tiene que hacer el LLM para determinar si un resultado es bueno o malo.
Así es como definimos esto:
Algunas notas de receta: Utilice indicaciones claras. Proporcione lo que desea que haga el LLM (no lo que desea que no haga). Sea muy específico en el procedimiento de evaluación.
4. Reaccionar paradigma
El patrón ReAct (Razonamiento + Actuación) está integrado en nuestro marco. Cada sentencia incluye:
1. Puntuación (0-100): Evaluación cuantitativa de la calidad
2. Veredicto: juicio binario o categórico
3. Confianza: Qué tan seguro está el juez
4. Razonamiento: explicación en cadena de pensamientos
5. Notas: Observaciones adicionales
Esto permite:
– Transparencia: Puedes ver por qué el juez tomó cada decisión.
– Depuración: identificar patrones en errores
– Human-in-the-loop: Dirigir juicios de baja confianza a los humanos
– Control de calidad: realice un seguimiento del desempeño de los jueces a lo largo del tiempo.
5. Ejemplos de pocas tomas
Ahora, proporcionemos algunos ejemplos más para asegurarnos de que el LLM tenga algún contexto sobre cómo evaluar casos del mundo real:
Pondremos estos ejemplos junto con el mensaje para que el LLM aprenda cómo realizar la tarea según los ejemplos que le demos.
Algunas notas de recetas: Cubren diferentes escenarios: correcto, incorrecto y parcialmente correcto. Muestre la calibración de la puntuación (100 para casos perfectos, 20-30 para errores claros, 60 para casos discutibles). Explique detalladamente el razonamiento. Haga referencia a palabras/frases específicas de la entrada
6. Definición de juez LLM
Todo está empaquetado en el siguiente bloque de código:
Así. 10 líneas de código. Usemos esto:
7. ¡Corramos!
Así es como se ejecuta toda la llamada API de LLM Judge:
Entonces podemos ver inmediatamente que el juez del LLM está juzgando correctamente el desempeño del “modelo” implementado. En particular, identifica que los dos últimos resultados del modelo son incorrectos, que es lo que esperábamos.
Si bien esto es bueno para mostrar que todo está funcionando, en un entorno de producción no podemos simplemente “imprimir” la salida en la consola: debemos almacenarla y asegurarnos de que el formato esté estandarizado. Así es como lo hacemos:
Y así es como se ve.
Tenga en cuenta que también estamos “en lotes”, lo que significa que enviamos varias entradas a la vez. Esto ahorra costos y tiempo.
8. Bonificación
Ahora, aquí está el truco. Supongamos que tiene una tarea completamente diferente que evaluar. Supongamos que desea evaluar la respuesta del chatbot de su modelo. Todo el código se puede refactorizar usando unas pocas líneas:
Como dos “jueces” diferentes cambian solo según las indicaciones que le brindamos al LLM, las modificaciones entre dos evaluaciones diferentes son extremadamente sencillas.
Conclusiones
LLM-as-a-Judge es una idea simple con mucho poder práctico. Cuando su modelo es aproximado, su tarea es compleja y no tiene un conjunto de datos etiquetado, un LLM puede ayudarlo a evaluar resultados, comprender errores e iterar más rápido.
Esto es lo que construimos:
Un rol y personalidad claros para el juez. Algunos ejemplos para guiar su comportamiento. Razonamiento en cadena de pensamiento para la transparencia. Evaluación de lotes para ahorrar tiempo y costos. Salida estructurada con Pydantic para uso en producción.
El resultado es un motor de evaluación flexible que se puede reutilizar en todas las tareas con sólo cambios menores. No reemplaza la evaluación humana, pero proporciona un sólido punto de partida mucho antes de que se puedan recopilar los datos necesarios.
Antes de salir
Gracias de nuevo por tu tiempo. Significa mucho ❤️
Mi nombre es Piero Paialunga y soy este chico:
Soy originario de Italia, tengo un doctorado. de la Universidad de Cincinnati y trabaja como científico de datos en The Trade Desk en la ciudad de Nueva York. Escribo sobre IA, aprendizaje automático y la evolución del papel de los científicos de datos tanto aquí en TDS como en LinkedIn. Si te gustó el artículo y quieres saber más sobre el aprendizaje automático y seguir mis estudios, puedes:
R. Sígueme en Linkedin, donde publico todas mis historias.
B. Sígueme en GitHub, donde podrás ver todo mi código.
C. Si tienes dudas puedes enviarme un correo electrónico a piero.paialunga@hotmail