Entrenando tu propio juez de LLM: desde PandaLM y JudgeLM hasta Prometheus

Una vez que un modelo de lenguaje puede redactar ensayos, responder tickets de soporte y resumir contratos, la pregunta “¿es esta salida de calidad?” deja de tener una respuesta sencilla. La revisión humana es el estándar de oro, pero es lenta y costosa; las métricas tradicionales de superposición apenas permiten evaluar la calidad actualmente, y hacer que un modelo propietario califique las salidas solo funciona bien cuando tus criterios se asemejan a lo que ese modelo ya conoce. Esta guía explica la investigación sobre jueces de LLMs afinados, modelos abiertos entrenados específicamente para calificar y criticar otros modelos, y finaliza con una receta concreta que puedes seguir para crear un evaluador para tu propio dominio.

Por qué evaluar los LLMs modernos es tan difícil

Dos características de los modelos base actuales dificultan su evaluación. La primera es el alcance: se espera que un único modelo pueda codificar, traducir, razonar, seguir reglas de formato, mantenerse seguro y ser amigable, y cada uno de estos comportamientos merece una medición propia. La segunda es la apertura: para casi cualquier prompt existe un amplio abanico de respuestas aceptables que difieren en redacción, estructura, longitud y énfasis, por lo que no se puede simplemente verificar si la salida coincide con una cadena esperada. Medir bien aunque sea una sola capacidad ya constituye un problema de investigación, y un modelo en producción cuenta con docenas de ellas.

La señal más fiable sigue proviniendo de las personas que leen los resultados y los califican. El problema es que los juicios humanos son imprecisos, costosos y lentos de recopilar, lo cual choca con el ritmo del desarrollo de los modelos. Un equipo que vuelve a entrenar o reenvía solicitudes a un modelo varias veces por semana no puede esperar a una nueva campaña de anotación después de cada cambio. Una cierta cantidad de evaluación humana sigue siendo indispensable, pero debe complementarse con algo que sea escalable.

Esa necesidad dio origen a LLM-as-a-Judge, presentado en el artículo Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena: se le proporciona una potente modelo propietario para que evalúe la salida de otro modelo. Este enfoque está ahora presente en todas las investigaciones, pero tiene un punto ciego. Los productos específicos de un dominio suelen valorar criterios detallados, como si un resumen médico mantiene la información sobre las dosis o si una respuesta legal cita la cláusula correcta, y un modelo de uso general puede no ser capaz de juzgar esto de manera fiable. En esa situación, el siguiente paso lógico es entrenar a un evaluador especializado, y comprender cómo hacerlo bien es el objetivo del resto de este artículo.

La caja de herramientas de evaluación: humanos, métricas y evaluadores basados en modelos

En la práctica, los equipos combinan la evaluación humana con métricas automáticas. Los humanos ofrecen una valoración definitiva de la calidad; las métricas automáticas aportan velocidad. Dado que las puntuaciones automáticas son solo una aproximación de lo que piensan las personas, se siguen verificando mediante revisiones periódicas realizadas por humanos, pero entre esas revisiones se pueden comparar muchas más variantes del modelo de las que los humanos podrían analizar.

La evaluación automática de los LLM modernos se divide principalmente en dos categorías. La primera es la evaluación al estilo de pruebas de referencia basada en la probabilidad o perplejidad, que abarca la mayoría de las pruebas tradicionales de procesamiento del lenguaje natural como MMLU y BIG-bench. Estas se asemejan más o menos a exámenes de opción múltiple que miden lo que sabe el modelo. Son útiles, pero dicen poco sobre cuán bien un modelo es capaz de escribir una respuesta larga y estilísticamente adecuada a una pregunta abierta.

Para resultados largos y abiertos, en realidad solo existen dos opciones: que seres humanos evalúen las respuestas o que un modelo capaz lo haga. Dados los costos de la primera opción, la evaluación basada en modelos se ha convertido en la práctica habitual. No necesita una respuesta de referencia, es fácil de implementar y puede manejar una amplia variedad de tareas. Las secciones siguientes analizan cada elemento de esta herramienta por turnos, comenzando por el aspecto humano, ya que todo lo demás se mide en comparación con él.

La evaluación humana es la verdad de referencia, aunque no sea perfecta

Las personas pueden darse cuenta de lo que realmente importa en una respuesta: si es adecuadamente breve, creativa, tiene el tono adecuado o es sensible culturalmente. Por eso la revisión humana sigue siendo el punto de referencia. Los annotadores pueden provenir de muchos lugares. Puedes recabar votos mediante la colaboración masiva como lo hace Chatbot Arena, contratar un equipo dedicado o, como hizo el proyecto Alpaca, dejar que los propios desarrolladores del modelo evalúen las respuestas. Tratar a los humanos como la fuente de verdad no implica que sus etiquetas sean impecables. En la práctica, con frecuencia son inconsistentes, difíciles de elaborar y están sujetas a sesgos.

Acordo y calibración

Incluso las tareas que parecen sencillas a menudo generan un nivel sorprendentemente bajo de acuerdo entre los anotadores. Se puede cuantificar con una simple tasa de coincidencia o con estadísticas corregidas por azar, como el kappa de Cohen (para dos evaluadores), el kappa de Fleiss (para varios evaluadores) o el alfa de Krippendorff (flexible con etiquetas faltantes y diferentes tipos de escala). La corrección por azar es importante: si el 80 por ciento de las respuestas son “buenas”, dos evaluadores que califican todo como “bueno” estarán de acuerdo la mayor parte del tiempo sin aprender nada.

Cuando el grado de acuerdo es bajo, la solución es la calibración, es decir, enseñar a los anotadores a realizar la tarea de la misma manera. Un ciclo típico consiste en una sesión de revisión en la que los evaluadores examinan los elementos sobre los que no estuvieron de acuerdo, discuten los casos y llegan a una interpretación conjunta. Los resultados de esas discusiones se vuelven a incluir en las pautas de la tarea para que el siguiente grupo parta de una base más clara.

Pautas de redacción que realmente se utilizan

Las pautas constituyen el contrato escrito para una tarea de anotación. Como mínimo, deben indicar qué se está evaluando, es decir, los criterios, y cómo debe aplicarse cada uno de ellos. Las buenas pautas combinan instrucciones en prosa con ejemplos prácticos de etiquetas correctas e incorrectas, y los annotadores las consultan durante todo el trabajo en lugar de leerlas solo una vez. Estas pautas logran que las etiquetas sean más consistentes y acortan significativamente el tiempo de adaptación de los nuevos evaluadores. Una prueba útil: si un annotador necesita conocimientos que no figuran en el documento para etiquetar un elemento correctamente, entonces el documento está incompleto.

Las pautas también deben considerarse como documentos en constante evolución. Por ejemplo, el equipo de InstructGPT describió cómo revisó repetidamente sus instrucciones para el etiquetado a lo largo del proyecto, a medida que evolucionaban sus comentarios, los campos de metadatos y su comprensión del objetivo, corrigiendo las secciones que resultaban confusas o contradictorias. Esa experiencia es típica: las tareas que parecen obvias suelen ocultar mucha subjetividad, y esta solo sale a la luz cuando un grupo de personas intenta ponerse de acuerdo sobre cientos de ejemplos reales.

Monitoreo del acuerdo a lo largo del tiempo

La inversión significativa se realiza al principio: se definen los criterios, se calibran los evaluadores y se realizan iteraciones hasta que el acuerdo sea aceptable. Solo entonces las puntuaciones humanas se convierten en una medida fiable de la calidad del modelo. Sin embargo, el trabajo no termina ahí. El acuerdo puede deteriorarse por razones cotidianas: se unen nuevos evaluadores, los experimentados van desviándose gradualmente de las reglas escritas o incluso cambian las propias pautas. Seguir de cerca el acuerdo entre los evaluadores, por ejemplo asignando una fracción de los elementos a varios evaluadores, es la única forma de detectar esto antes de que corrompa silenciosamente tus datos de evaluación.

Métricas basadas en referencias y por qué dejaron de funcionar

Las generaciones anteriores de modelos de lenguaje solían evaluarse con métricas como ROUGE para la resumen y BLEU para la traducción. Ambas se basan en referencias: comparan la salida del modelo con una respuesta de referencia, principalmente contando los n-gramas superpuestos, y recompensan las salidas que comparten más palabras y frases con dicha referencia.

A medida que mejoraron los modelos, estas métricas perdieron su relevancia. Estudios de las salidas de los LLM han demostrado que tales métricas correlacionan débilmente con las preferencias humanas, hasta el punto de que ninguna de las métricas clásicas analizadas logró reflejar bien el juicio humano. Sobreviven principalmente porque su cálculo es prácticamente gratuito. Si ya se dispone de respuestas de referencia, siguen siendo útiles como una verificación rápida, por ejemplo para detectar una regresión en la que un resumidor comienza de repente a generar texto vacío o fuera de tema.

La razón fundamental de su fracaso es estructural. Una métrica basada en referencias es, en esencia, un sistema avanzado de coincidencia difusa frente a un único objetivo. Los modelos modernos son abiertos: una misma instrucción permite muchas respuestas igualmente buenas que pueden compartir pocos n-gramas con la referencia. Una puntuación que recompensa la similitud con una respuesta específica no puede representar toda la gama de respuestas válidas, por lo que penaliza las paráfrasis perfectamente buenas y puede recompensar textos fluidos que, por casualidad, reutilizan el vocabulario de la referencia aunque estén equivocados.

Jueces basados en LLM con instrucciones

Las debilidades de las métricas de superposición llevaron al campo hacia una evaluación más flexible basada en modelos. La forma más popular es LLM-as-a-Judge: se pide a un modelo potente que actúe como evaluador de los resultados de otro modelo. Los estudios realizados con MT-Bench y Chatbot Arena demostraron que esto se correlaciona bien con las preferencias humanas, requiere poco más que una instrucción bien redactada para implementarse, maneja naturalmente resultados abiertos y puede aplicarse a muchos criterios diferentes. Dichos estudios lo presentaron como una aproximación escalable y explicable de las preferencias humanas, cuya recolección sería costosa de otro modo.

En el resto de este artículo, “LLM-as-a-Judge” se refiere específicamente a la utilización de un modelo propietario ya existente, como GPT-4o o Gemini 1.5, mediante prompts, mientras que “juez afinado” se refiere a un modelo que se entrena uno mismo para fines de evaluación. Para obtener más información general sobre los jueces basados en prompts, lecturas útiles incluyen una guía práctica para crear jueces que impulsen decisiones empresariales, un análisis de la eficacia de los evaluadores basados en LLM y una revisión de las investigaciones relacionadas con LLM-as-a-Judge. Si ya está utilizando un juez basado en prompts en producción, los aspectos operativos se tratan en nuestra guía para gestionar LLM-as-a-Judge como un sistema de producción dinámico.

Evaluación por pares y puntual

Existen dos formas principales de solicitar un veredicto a un juez:

• Pareado: el juez ve una pregunta junto con dos respuestas candidatas y elige la mejor (a menudo con una opción de empate).
• Puntual: el juez ve una pregunta y una sola respuesta, y asigna una calificación, generalmente en una escala de Likert del 1 al 5.

La evaluación puntual también se conoce como valoración directa o calificación de respuesta única. En cualquiera de estos casos se puede utilizar una respuesta de referencia al incluir en la pregunta del juez una respuesta ya verificada, de modo que este pueda compararla en lugar de basarse únicamente en su propio conocimiento. Un ejemplo público ampliamente utilizado de un juez asistido por preguntas es AlpacaEval, una tabla de clasificación que emplea LLM-as-a-Judge para predecir las preferencias humanas entre las salidas de los modelos y publica todas sus preguntas de evaluación, incluidas las versiones anteriores.

Elegir un método de puntuación

No todas las soluciones sin configuración son óptimas; la elección adecuada depende de la aplicación. Los juicios por pares suelen ser más estables, ya que comparar dos cosas es más fácil que situar una cosa en una escala absoluta. El precio a pagar es el sesgo de posición, la tendencia a favorecer la respuesta que aparece primero (o segundo), además de una escalabilidad más limitada: los resultados por pares solo indican cómo se clasifican las salidas entre sí, y comparar muchos sistemas requiere numerosos pares. La calificación puntual es más versátil, ya que cada salida recibe su propia puntuación que puede almacenarse, promediarse y compararse posteriormente. También resulta más difícil para el evaluador, ya que debe basar la puntuación únicamente en su percepción interna de calidad. Proporcionar una respuesta de referencia es una forma común de hacer que la calificación puntual sea más fiable.

También es importante la naturaleza del criterio. Las propiedades objetivas como la veracidad o la fidelidad al documento de origen suelen ser binarias: la respuesta es fiel o no lo es. Preguntar cuál de las dos respuestas es “más fiel” está mal definido. Los criterios subjetivos, como la utilidad, el tono o la preferencia general, son donde brillan los juicios relativos, ya que a las personas y a los modelos les resulta más fácil y reproducible hacer comparaciones que asignar calificaciones absolutas. Un valor por defecto razonable es una puntuación puntual, a menudo binaria, para las verificaciones objetivas y una comparación entre pares para la calidad subjetiva.

Los sesgos que hereda todo juez

Sea cual sea el tipo de juez que utilice, ya sea impulsado o afinado, varios sesgos sistemáticos aparecen una y otra vez, y la mayoría de las técnicas de afinamiento mencionadas más adelante en este artículo existen para contrarrestarlos. Es útil conocerlos por su nombre antes de seguir leyendo:

• Prejuicio de posición: en el modo por pares, el evaluador favorece al primer o segundo candidato independientemente del contenido.
• Prejuicio de verbosidad o longitud: las respuestas más largas y elaboradas obtienen calificaciones más altas, incluso cuando el texto adicional no aporta nada.
• Prejuicio de auto-mejora: un evaluador prefiere los resultados escritos por sí mismo o por modelos de la misma familia.
• Prejuicio de conocimiento: el evaluador no puede determinar la corrección en temas que no conoce bien, y podría recompensar respuestas seguras pero erróneas.
• Prejuicio de formato: el evaluador solo funciona cuando la instrucción es idéntica a aquella para la cual fue creado o ajustado.

Ninguno de estos factores puede eliminarse por completo, pero cada uno puede medirse. Cambiar el orden de los candidatos, rellenar una respuesta con información irrelevante o calificar el mismo contenido bajo dos plantillas diferentes son experimentos sencillos que revelan hasta qué punto un juez en particular se deja influir por factores que no deberían importar. Realizarlos una vez al adoptar un juez, y nuevamente después de cualquier cambio en su plantilla o modelo, es uno de los hábitos más valiosos en el trabajo de evaluación.

Dónde fallan los jueces basados en prompts

LLM-as-a-Judge es eficaz y está ampliamente adoptado, pero depender de un modelo propietario conlleva desventajas reales:

• El modelo es una caja negra, y enviar datos de evaluación a un tercero puede generar preocupaciones en materia de seguridad y privacidad.

Usted no controla el control de versiones. El proveedor puede actualizar el modelo subyacente, y sus números de evaluación pueden cambiar o fallar sin que usted haga nada al respecto.

Cada juicio es una llamada a la API, por lo que evaluar grandes volúmenes de resultados resulta costoso.

Estos modelos rinden mejor en tareas de evaluación similares a las utilizadas durante su entrenamiento, como predecir preferencias humanas generales, y menos bien en criterios especializados.

Los asistentes de uso general no están especializados en la crítica, y tienden a ser cautelosos, evitando dar calificaciones altas u opiniones contundentes.

Casi todos estos problemas surgen de depender de un modelo que no se puede inspeccionar ni modificar. Esto plantea la pregunta obvia de si es posible entrenar su propio evaluador. La investigación resumida a continuación indica que sí: un evaluador afinado puede ofrecer retroalimentación específica para el dominio, detallada y más crítica, siempre y cuando se invierta en los datos que lo sustentan.

Metaevaluación: medir al propio juez

Antes de entrenar a un juez, decida cómo sabrá si es eficaz. La respuesta es un conjunto de datos de evaluación etiquetados por humanos en los que confíe plenamente, ya que se convertirán en la medida de referencia para cada juez que cree. La metaevaluación, es decir, evaluar al evaluador, implica entonces ejecutar al juez con esos datos y comparar sus veredictos con los de las personas.

Si el juez genera un resultado binario, como una elección entre dos opciones o una calificación de aprobado/rechazado, puede utilizar métricas de clasificación habituales como la precisión, exactitud, recuerdo y la curva ROC. Dado que son fáciles de interpretar, muchos especialistas sostienen que la puntuación binaria es el diseño más práctico para los jueces basados en LLM en general.

Para calificaciones no binarias, como una escala de Likert del 1 al 5, se mide qué tan bien las calificaciones de los jueces correlacionan con las calificaciones humanas. Como punto de referencia, el estudio de G-Eval indicó que un evaluador basado en GPT-4 alcanzó una correlación de Spearman de 0.514 con los humanos en una prueba de resumen, lo que en ese momento superó con creces a los métodos anteriores. La correlación de rangos de Spearman es probablemente la opción más común, pero también se utilizan el tau de Kendall, la correlación de Pearson y el kappa de Cohen como medidas de acuerdo. Estas son más difíciles de analizar que las métricas de clasificación, por lo que es necesario conocer las particularidades de cualquiera de ellas que se utilice. Pearson mide el acuerdo lineal y es sensible a los valores atípicos; Spearman y Kendall solo se preocupan por el orden, de modo que un juez que sea consistentemente un punto demasiado generoso aún puede obtener una calificación perfecta en ellas.

Hábitos prácticos de metaevaluación

Algunos hábitos hacen que la metaevaluación sea mucho más informativa. Informe sobre el grado de acuerdo por criterio en lugar de con un único número combinado, ya que un evaluador puede ser excelente para detectar errores factuales pero deficiente al calificar el tono, y un promedio oculta eso. Analice la confusión entre puntuaciones adyacentes por separado de las discrepancias significativas: un evaluador que da una puntuación de 4 cuando los humanos dan 5 representa un problema muy distinto al de uno que da una puntuación de 1. Compare el grado de acuerdo entre evaluadores y humanos con el acuerdo entre humanos sobre los mismos elementos; si dos annotadores entrenados solo coinciden en el 70 por ciento de los casos, un evaluador que coincide con ellos en el 68 por ciento está prácticamente en su límite máximo, y buscar más es inútil. Finalmente, mantenga el conjunto de metaevaluación estrictamente separado de todo lo utilizado para redactar instrucciones o entrenar al evaluador, de lo contrario las cifras lo subestimarán.

La primera generación de evaluadores afinados

Al principio, casi todos utilizaban modelos propietarios para la evaluación al estilo de un jurado, y había una buena razón para ello. A menos que se le proporcione al jurado una respuesta de referencia, el modelo debe ser capaz de resolver la tarea por sí mismo para poder distinguir entre una buena respuesta y una mala. Durante mucho tiempo, los modelos abiertos estuvieron por detrás de los cerrados, por lo que estos últimos eran simplemente mejores para calificar. Eso cambió cuando aparecieron modelos base abiertos más potentes como LLaMA y LLaMA-2, y los investigadores comenzaron a ajustarlos para convertirlos en evaluadores especializados. Los artículos a continuación recorren esa primera ola.

Un jurado Vicuna ajustado en el artículo de MT-Bench

El mismo artículo que presentó a LLM-as-a-Judge también incluyó uno de los primeros experimentos con un juez afinado. La mayor parte de ese trabajo se centra en utilizar plantillas genéricas para estimular modelos propietarios y predecir las preferencias humanas, pero un breve apéndice analiza el entrenamiento de un modelo abierto para la misma tarea, y su conclusión fue que Vicuna-13B afinado parecía ser una alternativa abierta y económica a los juzgadores cerrados.

Las motivaciones que se enumeran siguen siendo las razones principales para considerar un juzgador personalizado hoy en día:

• Evaluar a través de una API de pago se vuelve costoso a gran escala.
• Un modelo propietario no ofrece ni control ni transparencia.
• Los modelos abiertos se vuelven cada vez más capaces, por lo que la brecha está disminuyendo.

Si un juzgador abierto afinado pudiera igualar la calidad de los modelos propietarios, los tres problemas desaparecerían.

El experimento utilizó Vicuna-13B, un derivado de LLaMA. Desde el principio fue un evaluador deficiente: presentaba una alta tasa de errores, a menudo no seguía el formato o las instrucciones de evaluación y mostraba un fuerte sesgo por posición. El ajuste fino cambió significativamente esa situación. El modelo se entrenó con 20 mil votos humanos de una sola ronda provenientes de Chatbot Arena, donde se comparaban las respuestas de una amplia gama de modelos; la tarea se simplificó a una clasificación de tres opciones: la primera respuesta ganaba, perdía o empataba. Después del entrenamiento, el sesgo por posición disminuyó drásticamente y la concordancia con los votos humanos mejoró notablemente, aunque el modelo ajustado aún no alcanzó el nivel de GPT-4.

Enmarcar la tarea como una clasificación de tres vías es una simplificación razonable. Elimina la necesidad de calibrar las puntuaciones numéricas, se ajusta directamente a la forma en que se recogen los votos en Arena y hace que sea sencillo calcular la precisión comparándola con los votos humanos de referencia. La desventaja es que el juez no proporciona explicaciones, por lo que cuando está en desacuerdo con las personas, se aprende poco sobre el motivo.

Toda la exploración ocupa aproximadamente una página, pero los resultados fueron lo suficientemente alentadores como para iniciar un trabajo en evaluadores abiertos.

PandaLM: un juez para elegir entre puntos de control del modelo

Un uso frecuente de un juez es la selección de modelos: dado varios modelos candidatos, ¿cuál es el mejor? Esto se vuelve difícil cuando todos los candidatos son sólidos y solo difieren ligeramente. Los humanos pueden tomar esa decisión, pero lentamente; por eso, un juez que detecte de manera fiable pequeñas diferencias en calidad es valioso.

PandaLM fue diseñado precisamente para esto. Su objetivo va más allá de verificar si una respuesta es correcta; también evalúa cualidades subjetivas como la concisión relativa, la claridad, la exhaustividad, la formalidad y el cumplimiento de las instrucciones. La aplicación principal es el ajuste de hiperparámetros. Se entrenan varias variantes de un modelo con diferentes configuraciones, se permite que PandaLM compare sus resultados y se mantiene la configuración ganadora. En los experimentos descritos en el artículo, cada modelo ajustado de esta manera tuvo un mejor rendimiento que con las configuraciones predeterminadas, lo cual demuestra que un evaluador puede influir directamente en las decisiones de entrenamiento en lugar de limitarse a generar informes.

El conjunto de entrenamiento contiene más de 300K ejemplos. Cada entrada es una tupla de (instruction, input, response1, response2) y cada objetivo es una tupla de (resultado de evaluación, razonamiento de la evaluación). Cada ejemplo cuenta con una respuesta de referencia, y el resultado indica cuál es la mejor respuesta o declara un empate. El equipo ajustó con precisión los modelos LLaMA de varios tamaños utilizando predicción simple del siguiente token con pérdida de entropía cruzada, en un estilo secuencia a secuencia, sin una cabeza de clasificación separada. En otras palabras, el veredicto y la explicación son simplemente texto que el modelo aprende a generar.

Cuando se compara PandaLM con otros evaluadores, incluidos GPT-3.5 y GPT-4, sus preferencias siguen tendencias similares: clasifican a los modelos evaluados en un orden consistente. En enfrentamientos directos con jueces propietarios, la versión de 7B de PandaLM es competitiva y la versión de 70B supera a GPT-4 en las evaluaciones del estudio, lo que sugiere que la capacidad de juicio, al igual que la mayoría de las capacidades, mejora con el tamaño del modelo.

PandaLM también rinde bien en dominios especializados. El estudio lo aplica a respuestas a preguntas del LSAT y a conjuntos de datos para responder preguntas biomédicas, donde el modelo más grande tiene un rendimiento especialmente bueno. Dado que está entrenado específicamente con datos de evaluación, puede aplicarse a tareas de juicio en dominios específicos que se acercan a su distribución de entrenamiento, y no solo a evaluaciones generales de chat.

JudgeLM: qué realmente hace que un juez afinado sea bueno

La mayoría de los jueces afinados en las primeras etapas dijeron poco sobre por qué trabajaban. JudgeLM se propuso estudiar sistemáticamente los factores, entre ellos:

• cuántos datos de entrenamiento se utilizan y cuán buenos y diversos son;
• el tamaño y la calidad del modelo base;
• cómo el sesgo afecta las decisiones del juez;
• si el juez puede aplicarse a otros formatos, como chats de varias turnos, evaluación con una sola respuesta, clasificación por pares e entradas multimodales.

Un juez afinado puede quedar rezagado con respecto a uno propietario por muchas razones: un modelo base débil, datos ruidosos, sesgo sistemático, etc. El valor de JudgeLM radica en demostrar que estos problemas pueden abordarse directamente.

El ingrediente más importante es un conjunto de datos grande, de alta calidad, detallado y diverso. El equipo de JudgeLM afirmó explícitamente que su conjunto de datos era el más diverso y de mejor calidad disponible en ese momento. Se basa en 105 mil instrucciones iniciales extraídas de fuentes públicas como ShareGPT, además de una versión de los datos Alpaca con respuestas generadas por GPT-4.

Para cada instrucción inicial, se generan respuestas con varios modelos, entre ellos Alpaca, Vicuna y LLaMA, las cuales se combinan con la respuesta original del conjunto de datos de referencia. De este modo, cada instrucción cuenta con múltiples respuestas candidatas además de una referencia. Luego se seleccionan al azar pares de respuestas, y GPT-4 califica cada par y explica su razonamiento. En esencia, GPT-4 actúa como maestro: JudgeLM aprende a reproducir sus juicios.

Los modelos de calificación GPT-4 vienen en dos variantes: con y sin respuesta de referencia. Se asemejan mucho a los prompts estándar para jueces públicos, con una diferencia importante: especifican criterios de evaluación bastante detallados. Esto impulsa a GPT-4 hacia evaluaciones más precisas, y el ajuste fino basado en esas evaluaciones transfiere esa misma precisión a JudgeLM.

JudgeLM fue entrenado con 7B, 13B y 33B de parámetros, en conjuntos de datos que van desde 3.5K hasta 100K de ejemplos, utilizando ajuste por instrucciones con ajuste fino supervisado (SFT). La entrada contiene una instrucción, dos respuestas candidatas y una respuesta de referencia. El modelo emite una puntuación separada para cada respuesta seguida de una justificación. Convertir eso en un veredicto entre dos respuestas es sencillo: gana la respuesta con mayor puntuación, y en caso de empate, se considera un empate. Un buen efecto secundario de este diseño es que un solo modelo sirve tanto como evaluador como comparador.

Reducir los sesgos fue un objetivo central. JudgeLM aborda tres tipos de ellos:

1. Sesgo de posición: preferir una respuesta debido a su ubicación en el prompt en lugar de a lo que dice.
2. Sesgo de conocimiento: el modelo base carece del conocimiento adquirido mediante entrenamiento previo necesario para evaluar correctamente la respuesta.
3. Sesgo de formato: el evaluador solo funciona bien cuando el prompt coincide con el formato exacto utilizado durante el ajuste fino.

Cada uno tiene un remedio bastante directo. El sesgo de formato disminuye cuando el juez ve varios formatos de prompt durante el entrenamiento. El sesgo de conocimiento disminuye cuando se le proporciona al juez una respuesta de referencia, de modo que no necesita conocer los hechos por sí mismo. El sesgo de posición se aborda mediante el cambio de posición: se evalúa cada par en ambos ordenes, tanto al crear los datos de entrenamiento como en el momento de la inferencia. Si el veredicto cambia al invertir el orden, generalmente se considera que el par es un empate. Intercambiar posiciones durante el entrenamiento enseña al modelo a prestar atención al contenido en lugar de a la ubicación, y hacerlo durante la inferencia limita cualquier sesgo que quede. Utilizadas juntas, estas técnicas reducen sustancialmente el sesgo de JudgeLM.

Cabe tener en cuenta el costo que implica cambiar de posición durante la inferencia: esto duplica la cantidad de llamadas a Judge para la evaluación por pares. En las grandes evaluaciones offline esto suele ser aceptable; sin embargo, en usos online sensibles a la latencia podría no serlo.

Sobre su propio conjunto de evaluación, JudgeLM supera a PandaLM y GPT-3.5, tanto con como sin respuestas de referencia. Esa comparación favorece a JudgeLM, ya que fue entrenado con datos de una distribución casi idéntica, pero también rinde bien en el conjunto de evaluación de PandaLM. Cabe señalar que gran parte del rendimiento reportado por JudgeLM se debe a la concordancia con GPT-4, el mismo modelo que generó sus etiquetas de entrenamiento, y no a la concordancia con humanos. En general, los modelos tienen un rendimiento sólido, mejoran a medida que crecen en tamaño y son más resistentes al cambio de posición que las alternativas.

Esto indica una limitación general de los jueces destilados. Cuando un modelo estudiante se entrena con las decisiones de un instructor, la precisión de este actúa como un techo suave, y sus puntos ciegos y sesgos se transmiten junto con sus fortalezas. Un alto grado de acuerdo con GPT-4 indica que la destilación funcionó; no indica si el juez está de acuerdo con tus usuarios. Solo un conjunto de pruebas etiquetado por humanos puede responder a esa segunda pregunta.

Auto-J: basado en consultas reales de usuarios

Auto-J, del artículo “Generative Judge for Evaluating Alignment”, es otro evaluador afinado, centrado en la calificación específica de escenarios en entornos realistas. Sus características distintivas son:

• Permite tanto la comparación entre pares como la puntuación de respuestas individuales.
• Pone énfasis en críticas en lenguaje natural bien estructuradas y de alta calidad.

Sus consultas de entrenamiento provienen de personas reales, por lo que los datos reflejan la variedad de preguntas que realmente recibe un modelo.

El resultado es un juez que es flexible, interpretable y práctico.

Los datos de Auto-J comienzan definiendo escenarios, cada uno con su propia definición y criterios de evaluación. El estudio se basa en 58 escenarios agrupados en ocho categorías más amplias. Para cada escenario, se recopilan consultas reales de usuarios, se generan respuestas y GPT-4 produce los juicios. GPT-4 se guía por criterios escritos a mano específicos para cada escenario, y las salidas se procesan posteriormente con filtros heurísticos y normalización de formato para reducir el ruido. Cada escenario aporta hasta 100 ejemplos, lo que da un total de aproximadamente 3,500.

Auto-J se ha afinado a partir de LLaMA-2-13B-Chat utilizando este conjunto de datos de formato mixto. Una decisión de diseño interesante es que los criterios de evaluación no se incluyen en la entrada. La lógica detrás de esto es que el modelo debería absorber dichos criterios de forma implícita a partir de los datos, lo que lo haría más general. Trabajos posteriores, como Prometheus, llegaron a una conclusión opuesta y determinaron que es importante introducir rúbricas y otro material de referencia en el proceso de evaluación. Para contrarrestar los sesgos, Auto-J utiliza un método simple de aumento: cada par de ejemplos se duplica intercambiando las dos respuestas, y las etiquetas “Respuesta 1” y “Respuesta 2” en la evaluación se cambian en consecuencia.

El conjunto de pruebas Auto-J está estructurado al igual que su conjunto de entrenamiento, con la diferencia de que cada etiqueta proviene de annotadores humanos. Frente a una variedad de otros modelos, Auto-J supera a casi todos excepto al GPT-4. Esto confirma que un evaluador especializado entrenado con datos adecuados al dominio puede igualar, e incluso superar, a los evaluadores propietarios en su entorno de aplicación. Sin embargo, su grado absoluto de acuerdo con los humanos en este conjunto de datos sigue siendo bajo, lo que recuerda que la calidad general de los evaluadores tiene mucho margen para mejorar.

Críticos, verificadores y generadores de datos sintéticos

Paralelamente a estos jueces, una línea de investigación estrechamente relacionada entrenó modelos para verificar, criticar o dar retroalimentación sobre los resultados de otro modelo. Al igual que los jueces, estos modelos califican las respuestas y explican su razonamiento. La diferencia es que los críticos y verificadores también actúan en función del veredicto: revisan la respuesta o inician un nuevo intento cuando la original no cumple con los requisitos.

SelFee es un buen ejemplo: es un modelo basado en LLaMA entrenado con generaciones de ChatGPT, las retroalimentaciones de ChatGPT sobre ellas y generaciones revisadas. Al recibir una respuesta, SelFee escribe una retroalimentación y luego reescribe la respuesta basándose en ella, pudiendo seguir iterando hasta que el resultado supere un umbral de calidad. Eso lo convierte en un verificador, ya que verifica su propia salida, y en un crítico, ya que escribe retroalimentación y realiza revisiones.

Se han propuesto muchos otros métodos de crítica, incluyendo la autocorrección, PEER y modelos de auto-crítica. La misma infraestructura puede generar y filtrar datos de entrenamiento sintéticos para el SFT o el ajuste de preferencias, como en RLAIF y Constitutional AI.

Vistos desde la distancia, todos estos sistemas —jueces estimulados, jueces afinados, pipelines de datos sintéticos, críticos y verificadores— hacen esencialmente lo mismo: generar una puntuación y una explicación. Lo que difiere es cómo se utiliza la puntuación, ya sea para informar sobre la calidad del modelo o para decidir qué muestras ingresarán en un conjunto de entrenamiento. Trabajos recientes sobre verificadores generativos y modelos de recompensa basados en crítica sostienen que al menos algunas de estas funciones pueden unificarse en un único modelo que se encargue de todas las tareas de puntuación.

La familia Prometheus: jueces afinados que compiten con GPT-4

Los evaluadores afinados solo se popularizaron con Prometheus, un modelo creado para una evaluación detallada y específica de cada dominio. Su metodología no es radicalmente nueva; el gran cambio radica en un punto de partida mucho más sólido en LLaMA-2 y en un conjunto de datos cuidadosamente diseñado. Dado que igualaba en calidad de evaluación a muchos sistemas propietarios, se difundió rápidamente y dio lugar a varias variantes posteriores.

Prometheus: las rúbricas como entrada de primera clase

Es sencillo utilizar un evaluador propietario: basta con describir los criterios y dejar que el modelo haga su trabajo. Los problemas son los ya mencionados, como la versionación sin control y el costo, además del hecho de que estos modelos suelen evaluarse según criterios genéricos como la preferencia humana general y pueden tener dificultades con criterios personalizados. Prometheus aborda esto mediante un evaluador afinado que, una vez entrenado para un dominio específico, puede igualar o superar a los sistemas propietarios.

La idea clave es que Prometheus utiliza una rúbrica de puntuación personalizada como parte de sus datos de entrada, lo que le permite adaptarse a nuevos dominios y criterios sin necesidad de reentrenamiento. Fue entrenado con Feedback Collection, un conjunto de datos sintéticos creado con GPT-4 que abarca diversas tareas de evaluación. Cada ejemplo contiene los mismos componentes:

• Instrucción: el texto proporcionado al modelo que se está evaluando.
• Respuesta: la respuesta de dicho modelo, que es lo que se califica.
• Rúbrica: criterios personalizados que describen cómo debe evaluarse la respuesta.
• Respuesta de referencia: un ejemplo de respuesta que obtendría la puntuación más alta.
• Razón: una explicación de por qué la respuesta recibe esa puntuación.
• Puntuación: una calificación de 1 a 5 según la escala de Likert.

Una rúbrica consta de dos partes: una declaración general del criterio y una descripción de lo que significa cada puntaje del 1 al 5. Utilizar esta información permite al modelo calificar con un alto nivel de detalle e aplicar esquemas de puntuación que no haya visto anteriormente. El trabajo de Prometheus fue uno de los primeros en demostrar cuánto beneficia a un evaluador afinado contar con material de referencia rico como entrada, y en particular con respuestas de referencia.

La generación comienza con 50 rúbricas escritas por humanos y se lleva a cabo en tres etapas:

1. GPT-4, tras ver ejemplos de las rúbricas manuscritas, las expande a 1,000 rúbricas.
2. Para cada rúbrica, GPT-4 escribe 20 instrucciones, lo que da un total de 20,000 instrucciones.
3. Para cada instrucción, GPT-4 genera una respuesta, luego retroalimentación sobre ella y finalmente un puntaje, en ese orden.

Dos trucos de equilibrio hacen que los datos sean más útiles. Primero, GPT-4 genera cinco ejemplos de entrenamiento por instrucción, uno para cada puntuación del 1 al 5, de modo que la distribución de las puntuaciones sea uniforme y el evaluador no aprenda a otorgar calificaciones altas de forma automática. Segundo, esos ejemplos se mantienen con longitudes similares para que el evaluador no adquiera un sesgo a favor de las respuestas más extensas, es decir, la costumbre de valorar más las respuestas largas independientemente de su contenido.

Prometheus se ha afinado a partir de LLaMA-2-13B-Chat utilizando los conjuntos de evaluación Feedback Collection, MT-Bench y Vicuna Bench. Gracias a que todo el material de referencia se incluye en la instrucción, el modelo aprende mediante SFT a redactar primero su feedback y solo después generar la puntuación. Este orden es intencional y refleja el afinamiento basado en el razonamiento en cadena: la crítica escrita se convierte en el contexto del cual se vale el modelo al elegir un número, en lugar de ser una justificación añadida posteriormente. El equipo de Prometheus también destaca la importancia de insertar un token separador especial, [RESULT], entre el feedback y la puntuación; esto evita que las generaciones se deterioren durante la inferencia y tiene la ventaja práctica de facilitar enormemente el análisis de las puntuaciones.

Prometheus fue comparado con GPT-3.5, GPT-4 y varios modelos base abiertos en múltiples conjuntos de datos, midiendo tanto la concordancia con las calificaciones humanas como la utilidad de sus retroalimentaciones. Sus puntuaciones alcanzaron una correlación de Pearson de 0.897 con los evaluadores humanos, a la par que GPT-4 y muy por delante de GPT-3.5. Por lo tanto, un modelo afinado con datos de evaluación de alta calidad para un dominio específico puede alcanzar, o incluso superar, el nivel de concordancia con los humanos de modelos propietarios mucho más grandes.

También son válidos los comentarios. En el 58,67% de las comparaciones, los revisores humanos prefirieron los comentarios de Prometheus frente a los de GPT-4, y en casi el 80% frente a los de GPT-3.5. Al preguntárseles por qué, los revisores señalaron que Prometheus es más crítico y más específico. El artículo lo resume diciendo que GPT-4 tiende a mantenerse neutral y abstracto, mientras que Prometheus se pronuncia claramente sobre si la respuesta es buena. Ese es el beneficio de la especialización: Prometheus no es un asistente general entrenado para ser complaciente, sino un modelo cuya única función es la crítica.

Prometheus 2: un modelo para puntuación puntual y por parejas

Prometheus 2 continúa la línea con otro evaluador abierto y detallado que acepta criterios personalizados. Aborda dos debilidades del original: la concordancia con las puntuaciones humanas aún podía mejorarse, y, lo que es más importante, el primer Prometheus solo podía realizar evaluaciones directas. Era posible obtener un ranking comparando dos puntuaciones punto por punto, pero ni Prometheus ni la mayoría de los evaluadores abiertos anteriores podían comparar nativamente dos respuestas. Prometheus 2 combina ambos modos en un único modelo que sigue de cerca a los humanos y a GPT-4 en cada caso.

Los ejemplos por pares en Prometheus 2 difieren de los de evaluación directa en tres aspectos:

• El material de referencia no contiene respuesta de referencia.
• Solo incluye una descripción del criterio de evaluación.
• Los comentarios están redactados de manera diferente.

En el modo por pares, la retroalimentación debe comparar las dos respuestas, señalar en qué difieren y utilizar esas diferencias para justificar la elección de una. La mayoría de los conjuntos de datos y modelos por pares anteriores se basaban en criterios genéricos y a menudo proporcionaban un veredicto simple sin ninguna explicación comparativa.

Para entrenar esta habilidad por pares, Prometheus 2 introduce la Colección de Preferencias, derivada de la Colección de Retroalimentación. Dado que esta última contiene cinco respuestas por instrucción, una para cada puntuación, se pueden formar todas las combinaciones posibles: diez parejas por instrucción. La etiqueta de cada pareja se obtiene directamente al comparar las dos puntuaciones de Likert.

Dado que la retroalimentación explicativa, al estilo de cadena de pensamiento, es fundamental en el enfoque Prometheus, las etiquetas por sí solas no eran suficientes. Se pidió a GPT-4 que escribiera nueva retroalimentación para cada pareja, centrándose en lo que tienen en común las dos respuestas y en dónde difieren.

Existen varias formas de obtener un único juez que maneje ambos modos de puntuación:

• Uso de prompts: emplear un modelo listo para usar con un prompt diferente para cada modo.
• Entrenamiento en formato único: entrenar un modelo por cada modo y utilizar el que mejor se adapte.
• Entrenamiento conjunto: entrenar un único modelo con una combinación de ambos tipos de datos.

Solo el entrenamiento conjunto permite obtener un modelo especializado que cubra ambos modos; el uso de prompts depende de modelos genéricos, mientras que el entrenamiento en formato único deja dos modelos. Otra opción es entrenar los dos modelos de formato único y luego combinarlos mediante fusión de modelos, como lo hace Prometheus 2. Se entrenan dos evaluadores por separado, uno para la recolección de feedback y otro para la recolección de preferencias, y sus pesos se combinan mediante una fusión lineal sencilla, generando un modelo capaz de puntuar de ambas maneras.

El resultado notable es que el modelo fusionado supera tanto al modelo entrenado conjuntamente como a los modelos de formato individual. Se probaron varios métodos de fusión, incluyendo la aritmética de tareas, TIES y DARE. Los métodos más sofisticados a veces son útiles; por ejemplo, con Mixtral 8x7B como base, DARE funcionó mejor. Sin embargo, la fusión lineal simple con un coeficiente de 0,5, que consiste simplemente en promediar los pesos de los dos modelos, rinde bien en la mayoría de las configuraciones y es fácil de implementar. Una explicación intuitiva de por qué funciona es que las dos sesiones de entrenamiento parten del mismo modelo base y aprenden habilidades relacionadas, por lo que sus pesos permanecen en una región compatible donde el promedio combina las capacidades en lugar de destruirlas.

Prometheus 2 se basó en Mistral-7B y Mixtral 8x7B: copias separadas se ajustan con precisión en cada conjunto de datos y luego se fusionan mediante diversos algoritmos. Los modelos resultantes superan a todos los demás evaluadores abiertos en un conjunto de pruebas de evaluación directa y comparativas entre pares. Su correlación de Pearson con los evaluadores propietarios mejora en 0,2 en todos los conjuntos de datos, y en las pruebas de clasificación por pares reducen aproximadamente la mitad de la brecha con respecto a GPT-4.

Las ganancias parecen menores en el modo por pares, pero la comparación allí incluye modelos de recompensa junto con evaluadores abiertos. Los modelos de recompensa, los calificadores utilizados en el aprendizaje por refuerzo a partir de retroalimentación humana (RLHF), se entrenan únicamente para la preferencia por pares, no generan retroalimentación escrita y son muy precisos en comparaciones por pares. Prometheus 2 también muestra una mejor consistencia entre modos que otros evaluadores: la respuesta que prefiere en una comparación por pares suele recibir también la puntuación más alta en la evaluación directa. Esa propiedad es importante en la práctica, porque resulta difícil confiar en un juez cuyas dos formas de evaluación difieren.

Prometheus-Vision: evaluación de modelos visión-lenguaje

Hasta ahora, todo se ha referido a modelos de texto puro. Los modelos visión-lenguaje (VLM), que aceptan imágenes además de texto, se han vuelto comunes tanto en versiones propietarias como GPT-4V y Gemini, como en versiones abiertas como LLaVA y las variantes visuales de Llama 3.2. Aparte de esta modalidad de entrada adicional, se entrenan y estructuran de manera muy similar a los LLMs de texto.

Un VLM genera texto a partir de una imagen junto con una instrucción, y su evaluación añade una dimensión más. Es necesario verificar dos cosas:

1. Si la respuesta sigue la instrucción, al igual que ocurre con cualquier LLM.
2. Si la respuesta se basa en lo que realmente muestra la imagen.

Una solución alternativa es convertir la imagen en texto, por ejemplo con un modelo de subtítulos o de imagen a texto, y pasar esa descripción a un evaluador de texto como GPT-4 o Prometheus. Sin embargo, los pipelines de varias etapas como este agravan los errores: todo lo que se pase por alto en la descripción no puede ser evaluado por el evaluador. Utilizar un VLM como evaluador es un enfoque más directo.

Prometheus-Vision es un evaluador de VLM de código abierto. Los VLM propietarios como GPT-4V ya se habían utilizado como evaluadores para otros VLM, pero Prometheus-Vision fue el primer VLM de código abierto capaz de calificar según criterios detallados definidos por el usuario. Además de la transparencia y el control que ofrece un modelo abierto, sus puntuaciones se correlacionan bien tanto con las evaluaciones humanas como con las de los evaluadores propietarios, y puede detectar diferencias sutiles, como distinguir una obra de arte genuina de su parodia.

Cuando se publicó el trabajo, no existía ningún conjunto de datos con retroalimentación, críticas o preferencias para entrenar un evaluador de VLM de alto nivel, por lo que el equipo creó uno. La Colección de Percepción sigue el diseño de la Colección de Retroalimentación, y cada instancia consta de cinco partes de entrada:

• Imagen: la foto que el usuario proporciona al VLM.
• Instrucción: la instrucción textual del usuario.
• Respuesta: la respuesta textual del VLM a la imagen e instrucción.
• Rúbrica: guía detallada para la puntuación, que incluye una descripción del criterio y de cada puntaje en la escala del 1 al 5.
• Respuesta de referencia: una respuesta que obtendría una puntuación de 5, generada con GPT-4V.

Los resultados son una justificación escrita y un puntaje del 1 al 5.

La construcción imita el conjunto de datos de texto. El proceso toma muestras de 5K imágenes de los conjuntos de datos MS-COCO y MMMU, escribe a mano 50 rúbricas iniciales, utiliza GPT-4 para ampliarlas a 15K rúbricas, genera 30K instrucciones con respuestas de referencia correspondientes y, finalmente, agrega cinco respuestas por instrucción, una por cada calificación, cada una con retroalimentación. En comparación con la Recolección de Retroalimentación, hay muchas más rúbricas (15K frente a 1K), pero muchísimas menos instrucciones por rúbrica (dos frente a 20).

No se puede utilizar aquí un modelo base solo de texto; el entrenamiento debe comenzar a partir de un VLM preentrenado. Prometheus-Vision utiliza las versiones 7B y 13B de LLaVA-1.5. La metodología es el mismo ajuste fino basado en cadena de pensamiento que antes: el SFT enseña al modelo a escribir comentarios y luego asignar una puntuación. En cada ejemplo de entrenamiento, las dos partes están separadas por la frase fija Así que la puntuación general es, que desempeña el mismo papel que el token [RESULT] en el modelo de texto. Con rúbricas y respuestas de referencia en la entrada, el resultado es un modelo ajustado para una evaluación personalizada y detallada.

Prometheus-Vision muestra una mejor correlación con las puntuaciones humanas que GPT-3.5-Turbo y que el Prometheus exclusivamente de texto, pero GPT-4 y GPT-4V coinciden más estrechamente con los resultados humanos en general. Su rendimiento más débil se observa en VisIT-Bench, que contiene muchas imágenes con mucho texto. Allí, GPT-4 rinde bien, incluso mejor que GPT-4V, ya que recibe como entrada el texto extraído de la imagen, mientras que Prometheus-Vision tiene dificultades para leerlo. En los demás tests de rendimiento, Prometheus-Vision está más o menos a la par con GPT-4 y GPT-4V, y en varios casos muestra una correlación más fuerte con los resultados humanos que cualquiera de ellos.

Los revisores humanos calificaron sus respuestas como más o menos tan buenas como las de GPT-4 y GPT-4V. El equipo también analizó los sesgos comunes en los evaluadores, como el sesgo de longitud —la preferencia por respuestas más extensas— y el sesgo de auto-mejora —la preferencia por los propios resultados generados—. No encontraron signos evidentes de ninguno de ellos, aunque señalaron que aislar un único sesgo experimentalmente es realmente difícil.

Otras direcciones en la evaluación afinada

Prometheus no es el único enfoque. Varios otros proyectos han entrenado modelos de lenguaje para fines de evaluación, cada uno aportando una idea distinta. El breve recorrido que sigue abarca los más relevantes si estás diseñando tu propio sistema de evaluación.

Modelos de lenguaje con recompensa automática

Los modelos de auto-recompensa tienen como objetivo automatizar la alineación con la ayuda de un evaluador interno. En lugar de entrenar un modelo de recompensa separado basado en las preferencias humanas, el modelo que se va a alinear es entrenado para juzgar sus propias salidas utilizando prompts del estilo LLM-as-a-Judge, y esos juicios se convierten en la recompensa. Al aplicarlo a LLaMA-2, el método generó retroalimentación útil y mejoró al modelo subyacente. Conceptualmente se asemeja a Prometheus en el sentido de que el modelo aprende a actuar como juez, pero la salida del juez se vuelve a utilizar directamente como señal de entrenamiento para el mismo modelo.

LLM-as-a-Meta-Judge

Una limitación de los modelos de auto-recompensa es que nada mejora la habilidad de juicio en sí; el modelo se vuelve mejor para responder, pero sus evaluaciones siguen siendo tan buenas como al principio. Los modelos de meta-recompensa añaden un tercer rol: además de actuar como actor y juez, el modelo también funciona como un meta-juez que evalúa sus propios juicios, lo cual genera datos de entrenamiento para mejorar tanto al juez como a la política. Ambas capacidades mejoran conjuntamente a lo largo de las iteraciones de entrenamiento.

Evaluadores autodidactas

Los evaluadores autodidactas eliminan por completo las etiquetas de preferencia humana del proceso. Recopilar datos de preferencias humanas es costoso y se vuelven obsoletos a medida que mejoran los modelos, por lo que este enfoque genera datos de evaluación sintéticos de forma iterativa. A partir de un conjunto de instrucciones, un LLM produce pares de resultados contrastantes, uno intencionadamente peor que el otro, y se entrena a un evaluador para que los valore al escribir explicaciones y veredictos. Al repetir este proceso con un evaluador mejorado, se obtienen datos de entrenamiento cada vez más precisos en cada ronda. Sin ningún dato etiquetado por humanos, se informó que los evaluadores resultantes superaron tanto a GPT-4 utilizado como evaluador como a los modelos de recompensa entrenados con preferencias humanas en términos de precisión en la puntuación.

La advertencia obvia es la circularidad. Un juez que utiliza sus propios datos de entrenamiento puede desviarse hacia lo que ya considera correcto, y sin una verificación externa esa desviación queda invisible. Incluso si se emplea un ciclo de autoaprendizaje, un pequeño conjunto etiquetado por humanos sigue siendo la única forma de confirmar que cada ronda realmente mejora en lugar de simplemente volverse más confiado.

FLAMe: autoevaluadores fundamentales

Los modelos Large Authorater fundamentales (FLAMe) adoptan un enfoque opuesto con los datos: se entrenan con una gran cantidad de juicios humanos, más de 5 millones en total a lo largo de más de 100 tareas de evaluación de calidad. En comparación con otros evaluadores, los modelos FLAMe generalizan mejor a tareas de evaluación no vistas, muestran menos sesgo y sirven como puntos de partida sólidos para un perfeccionamiento adicional hacia evaluadores especializados. Se ha reportado que superan de manera consistente a los evaluadores basados en GPT-4 y variantes de Claude, así como a aquellos perfeccionados con datos sintéticos de GPT-4.

El compromiso en la generalización

Un estudio empírico sobre jueces afinados, cuyo título deja claro que concluye que “los modelos de jueces afinados son clasificadores específicos para tareas”, analizó en profundidad la relación de equilibrio con los jueces propietarios. Su conclusión es que los jueces afinados son excelentes dentro de su dominio, superando a veces a GPT-4 en conjuntos de pruebas extraídos de su distribución de entrenamiento, pero quedan por detrás de GPT-4 en generalización, equidad, evaluación específica por aspectos y escalabilidad. Eso no es sorprendente: un juez entrenado en una distribución aprende esa distribución; si se le pregunta sobre algo distinto, actúa como un clasificador de alcance limitado. La implicación práctica es mantener a un juez afinado en la tarea para la que fue entrenado y volver a validarlo con etiquetas humanas cada vez que los datos de entrada comiencen a desviarse.

Optimización de la preferencia por juicios directos

La optimización de preferencias mediante juicio directo aplica dicha optimización a los evaluadores en lugar de solo al SFT. Se recopilan pares de preferencias para tres casos de uso: evaluación individual, comparación entre pares y clasificación binaria. Los dos primeros corresponden a los enfoques habituales de puntuación puntual y comparativa entre pares; el tercero plantea la evaluación como una pregunta de sí o no, como determinar si una propiedad específica se cumple en la respuesta. También se añade una tarea auxiliar: dado una instrucción y un resultado de evaluación, el modelo debe inferir qué respuesta se estaba evaluando. Para cada caso de uso, un juicio bueno y uno malo forman un par de preferencias, y el evaluador se entrena con ellos mediante la optimización directa de preferencias (DPO). La ventaja radica en que el juez aprende no solo a imitar los juicios buenos, sino también a preferirlos sobre aquellos malos que parezcan plausibles.

¿Qué determina las calificaciones de un juez?

Una pregunta válida sobre cualquier evaluador de LLM es si realmente aplica los criterios que se le proporcionan, o simplemente premia los textos que se asemejan a sus datos de entrenamiento. Los análisis de evaluadores de LLM en varios sistemas de puntuación revelaron que las instrucciones detalladas para la puntuación en el prompt solo mejoran ligeramente sus juicios, y que la puntuación basada en la perplejidad, que evalúa una respuesta según cuán probable sea para el modelo encontrarla, a veces coincide mejor con los juicios humanos que las instrucciones del prompt, especialmente en lo que respecta a la calidad textual.

Esto parece contradecir el hallazgo de Prometheus de que el material de referencia es sumamente importante. Los dos resultados son más fáciles de reconciliar una vez que se comprende qué se estaba midiendo. Los análisis orientados a la perplejidad se centran principalmente en la calidad general de las respuestas desde la perspectiva de las preferencias humanas. La mayoría de los LLMs se entrenan intensamente con datos de preferencias, por lo que es natural que asignen una alta probabilidad a las respuestas que a la gente le gustan. Prometheus, en cambio, tiene como objetivo una amplia variedad de criterios personalizados que van más allá de las preferencias genéricas, y para estos, las rúbricas explícitas aportan información que el modelo no puede inferir únicamente de la fluidez. Si sus criterios se acercan a “¿qué respuesta prefieren más las personas?”, la rúbrica puede añadir poco; si son específicos de su área, resulta esencial.

Una guía paso a paso para crear su propio evaluador

Teniendo en cuenta el panorama de la investigación, resulta útil condensarlo en un proceso. El trabajo de Prometheus ya esboza un marco, y la versión que sigue lo adapta ligeramente para incorporar lo que enseñan los otros artículos.

Paso 1: definir con precisión los criterios de evaluación

Decida antes que nada qué es lo que va a evaluar:

• Enumere los criterios específicos que son importantes para su aplicación.
• Escriba una descripción detallada de cada uno, incluyendo qué significa cada nivel de puntuación.

La sección de Recolección de retroalimentación sirve como buen modelo de cómo debería verse una rúbrica, con descripciones de los criterios, descripciones por puntuación y respuestas de referencia. Espere tener que revisar los criterios repetidamente. A medida que descubra en qué puntos las personas y los modelos difieren, refinará y ampliará la rúbrica, y cada revisión hará que tanto la evaluación humana como la basada en modelos sea más consistente.

Paso 2: recopilar etiquetas humanas de alta calidad

Antes de entrenar o incluso de utilizar a cualquier evaluador, se necesita datos de evaluación humana fiables. Son ellos los que permiten determinar si un evaluador es preciso, y deben reflejar las entradas con las que se enfrentará en el entorno real. Si los datos sirven únicamente para la metaevaluación, por ejemplo para validar un LLM como evaluador mediante instrucciones específicas, generalmente basta con un conjunto modesto de entre 100 y 1000 ejemplos. En cambio, para ajustar con precisión a un evaluador del estilo Prometheus se requiere una cantidad mucho mayor, de entre 1000 y 100000 ejemplos.

La recolección de datos humanos es difícil, y es precisamente allí donde los equipos suelen invertir insuficientemente. Si las personas no pueden ponerse de acuerdo en la tarea, no hay forma de saber si un modelo la está realizando bien, y entrenar a un evaluador con etiquetas inconsistentes desperdicia todo el esfuerzo. Todo lo mencionado en la sección de evaluación humana anterior aplica aquí: calibrar a los evaluadores, mantener pautas y seguir midiendo el grado de acuerdo.

Paso 3: complementar con datos sintéticos

Los modelos Prometheus demuestran que los datos sintéticos pueden generar evaluadores eficaces: casi todos sus datos de entrenamiento, incluidas las instrucciones, respuestas, calificaciones y retroalimentación, fueron generados por GPT-4. Los datos puramente sintéticos conllevan un riesgo, ya que exponen al modelo a una gama limitada de entradas posibles e heredan los sesgos del modelo maestro. Mezclar datos etiquetados por humanos con datos sintéticos suele dar mejores resultados que usar cualquiera de ellos por separado. Utilice el conjunto de datos etiquetados por humanos para garantizar la calidad y el conjunto sintético para alcanzar el volumen y la cobertura necesarios para el ajuste fino; además, aplique las estrategias de equilibrio descritas en la sección de Recolección de Retroalimentación, como una distribución uniforme de calificaciones y longitudes de respuestas controladas, al generar los datos sintéticos.

Paso 4: invertir en las justificaciones

Obviamente, se necesitan puntuaciones y clasificaciones precisas, pero los razonamientos también merecen la misma atención. Se sabe que el ajuste fino es un método deficiente para introducir nuevos conocimientos en un modelo; lo que hace bien es enseñar estilo y formato. Para un jurado, el formato de los comentarios es lo principal que puede controlar. Los razonamientos específicos, críticos y vinculados a la rúbrica permiten que las explicaciones del jurado sean realmente útiles, y como el modelo escribe los razonamientos antes de la puntuación, unos razonamientos mejores tienden a respaldar puntuaciones mejores. Coloque un separador fijo entre los comentarios y la puntuación para que los resultados sean fáciles de analizar.

Paso 5: agregue respuestas de referencia donde sea posible

Paso 6: entrenar y realizar una metaevaluación

Con los datos, y opcionalmente las respuestas de referencia, ya listos, entrena al juez mediante SFT estándar. El repositorio Prometheus ofrece una implementación completa de este proceso. Reserva desde el principio un conjunto de prueba con datos etiquetados por humanos y úsalo para la metaevaluación: métricas de clasificación si la salida del juez es binaria, y métricas de correlación para todo lo demás. En el caso de jueces emparejados, mide también con qué frecuencia el veredicto sigue siendo válido al cambiar su posición; un juez que cambia de opinión cuando se invierte el orden aún no está listo.

Antes de confiar en el juez, realiza algunas verificaciones adicionales:

• Evalúa con ejemplos fuera de la distribución para determinar hasta dónde se extiende su competencia.
• Compara su distribución de puntuaciones con la de los humanos para detectar una indulgencia o severidad sistemática.
• Busca directamente efectos de longitud y posición, variando la longitud de las respuestas y el orden en el mismo contenido.

Vuelva a ejecutar la metaevaluación cada vez que cambien los criterios, las entradas o el modelo base.

Cuándo no ajustar los parámetros

Un evaluador ajustado no siempre es la herramienta adecuada. Si sus criterios son genéricos, como la utilidad general, un evaluador propietario bien configurado o un evaluador abierto existente puede ser suficiente y mucho más económico de implementar. Si no puede recopilar un conjunto fiable con etiquetas humanas, no podrá validar ningún evaluador, ya sea ajustado o no; así que resuelva eso primero. Además, si la distribución de tareas cambia constantemente, la naturaleza específica de las tareas de los evaluadores ajustados implica que tendrá que volver a entrenarlos con frecuencia. Ajustar los parámetros resulta beneficioso cuando los criterios son especializados, el volumen de evaluación es alto y necesita control sobre la versión, los costos o la privacidad de los datos.

Una nota sobre costos y operaciones

Tener un “juez” solo desplaza los costos en lugar de eliminarlos. Intercambias las tarifas por llamada de la API por tiempo de GPU, alojamiento del modelo y los esfuerzos técnicos necesarios para mantener la versión del “juez” actualizada y reproducible. A cambio, obtienes una versión fija del modelo que no puede cambiar bajo tu control, datos de evaluación que nunca salen de tu infraestructura, y la capacidad de realizar millones de juicios sin ver cómo aumentan las facturas. Trata al “juez” como cualquier otro modelo de producción: fija sus pesos, registra qué versión generó qué puntuaciones y conserva el conjunto de metaevaluación para poder comparar un nuevo entrenamiento con el actual en condiciones equitativas.

Puntos clave

• Los juicios humanos siguen siendo el punto de referencia, pero solo después de que la calibración, las pautas actualizadas y el seguimiento continuo del acuerdo los hagan lo suficientemente fiables como para medir cualquier cosa en comparación con ellos.

Las métricas de superposición como ROUGE y BLEU tienen una correlación deficiente con la preferencia humana por resultados abiertos; trátelas como verificaciones básicas y no como indicadores de calidad.

Es sencillo comenzar utilizando jueces propietarios guiados por prompts, pero esto conlleva riesgos de versionado, costos adicionales, opiniones cautelosas y un rendimiento más débil en criterios especializados.

Jueces afinados como PandaLM, JudgeLM, Auto-J y la familia Prometheus demuestran que los modelos abiertos pueden igualar o superar a GPT-4 en su área de aplicación, principalmente gracias a un diseño cuidadoso de los datos: rúbricas y respuestas de referencia como entrada, retroalimentación antes de la puntuación, etiquetas equilibradas e intercambio de posiciones.

La fusión de modelos ofrece una forma sencilla de combinar habilidades puntuales y por pares en un único juez, siendo el promedio simple de pesos efectivo en la mayoría de los casos.

Los jueces afinados están específicos para una tarea determinada. Manténgalos cerca de su distribución de entrenamiento y vuelva a validarlos con etiquetas humanas reservadas cada vez que cambie algo importante.

Lecturas relacionadas

• Un evaluación de LLM sin dependencias con un juez en el que puedes confiar de veras — Crea una evaluación sencilla de un LLM a partir de registros reales, verificaciones de código y un juez basado en un único criterio, luego calibra ese juez con etiquetas humanas para que sus puntuaciones tengan sentido.
• Gestionar LLM como juez como sistema de producción vivo — Aprende cómo el ciclo de vida de cuatro etapas de Netflix —datos reales, entrenamiento ajustado con rúbricas, despliegue seguro y monitoreo continuo— mantiene preciso a un juez LLM a gran escala.