El formulario se ha enviado correctamente.
Encontrará más información en su buzón.
ContrátanosSeleccionar idioma
ConócenosServiciosTecnologíasCartera
Tu aplicación de LLM puede generar miles de respuestas por hora. Con ese volumen, la revisión manual deja de ser el principal método de control de calidad. Métricas como BLEU y ROUGE miden la similitud superficial del texto, pero no permiten saber si una respuesta utiliza los datos correctos o si es adecuada para el producto. Y a medida que el sistema crece, los puntos ciegos crecen con él.
El método de evaluación «LLM como juez» Resuelve esta carencia haciendo que un modelo de lenguaje evalúe a otro según los criterios que tú definas. Los equipos obtienen una indicación sobre la que pueden actuar en grandes conjuntos de resultados sin necesidad de que un revisor humano supervise cada solicitud. El enfoque funciona, pero solo con la configuración adecuada. Una rúbrica deficiente, una solicitud sesgada o un modelo que se autoevalúa pueden hacer que las puntuaciones parezcan útiles, mientras que los mismos problemas de calidad permanecen ocultos.
Aquí voy a tratar qué es un «LLM como juez», cómo funciona, qué hace que sus puntuaciones sean útiles o engañosas, y en qué casos el método suele fallar. También analizaremos la configuración que necesitan los equipos antes de poder confiar en esas puntuaciones en un producto de IA real.
Si ya estás familiarizado con el Explicación sobre el «LLM como juez», puedes leer esta sección por encima. Si no es así, aquí tienes una sencilla Definición de «LLM como juez». «LLM-as-a-judge» es un método de evaluación en el que un modelo de lenguaje revisa los resultados de otro modelo comparándolos con una rúbrica establecida por el equipo. Este enfoque también puede aplicarse a los resultados de un sistema de IA más amplio o de un agente.
El evaluador suele ver la solicitud del usuario, la respuesta del modelo y la rúbrica que explica qué aspectos hay que comprobar. Dependiendo de la tarea, puede revisar el resultado de varias formas:
La rúbrica es lo que hace que la evaluación resulte útil. Sin ella, el evaluador tiene que adivinar qué es lo que cuenta como bien. Con una rúbrica, el equipo puede indicar al modelo cuáles son los indicadores de calidad que importan para su flujo de trabajo.
Algunos criterios habituales son la precisión, la pertinencia, la fiabilidad, la seguridad, la claridad y la utilidad. En un sistema RAG, el evaluador podría comprobar si la respuesta está respaldada por la fuente recuperada. En el caso de la atención al cliente, podría comprobar si la respuesta se ajusta a la política y responde realmente a la pregunta del cliente. En los flujos de trabajo de contenido, podría analizar el tono, la claridad y si el borrador se adapta al canal.
¿Por qué las empresas utilizan la L?Método de evaluación «LM como juez»? Los sistemas de IA evolucionan más rápido de lo que permite la revisión manual. Al principio, basta con revisar los resultados a mano. Se comprueban algunas respuestas, se dan comentarios y se corrigen los errores evidentes. Pero a medida que el sistema empieza a gestionar cientos de preguntas sobre numerosos temas, la revisión manual ya no da abasto.
La revisión humana sigue siendo la mejor forma de detectar matices, evaluar el riesgo empresarial y gestionar casos atípicos. El reto radica en la cobertura. Los revisores pueden ajustar una rúbrica, comprobar resultados delicados e investigar los fallos, pero no pueden revisar todas las respuestas tras cada actualización.
Los indicadores tradicionales como BLEU, ROUGE y las comprobaciones de coincidencia exacta también son útiles, pero solo en el caso de comprobaciones estrictas, como respuestas exactas, esquemas, formatos y etiquetas conocidas. No tienen en cuenta aspectos como el significado, la pertinencia, la adecuación a las políticas y la calidad general de la tarea.
Los evaluadores de LLM pueden revisar grandes conjuntos de pruebas y valorar aspectos que las métricas fijas no tienen en cuenta, como la relevancia, la veracidad, el tono, la seguridad y el cumplimiento de las instrucciones. Los equipos los utilizan para pruebas de regresión, comprobaciones previas al lanzamiento, comparaciones de modelos y supervisión de la calidad tras el lanzamiento.
La mayoría de las empresas no se basan únicamente en un único método. Una buena configuración combina comprobaciones deterministas para normas estrictas, modelos de lenguaje grande (LLM) para evaluaciones abiertas y personas para la calibración y las decisiones de alto riesgo.
| Método | Lo mejor para | Límites | Puesto en el área de producción |
| Revisión humana | Resultados de alto riesgo, matices empresariales, casos extremos y decisiones en las que el contexto es más importante que una puntuación | Demasiado lento para repetirse tras cada modificación de la indicación, actualización del modelo, cambio en la recuperación o actualización de la política | Calibra las rúbricas, revisa los casos controvertidos, investiga los fallos y aprueba los flujos de trabajo de gran impacto |
| Métricas tradicionales y comprobaciones fijas | Pruebas con respuestas predeterminadas, validación de esquemas, campos obligatorios, reglas de formato, etiquetas de coincidencia exacta y comprobaciones estrictas de aprobado/suspenso | Falta de significado, apoyo de la fuente, adecuación a la política, tono y respuestas que pueden ser correctas de más de una forma | Actúan como controles estrictos que deben superarse en todo momento |
| Jueces del LLM | Respuestas de formato libre, controles de calidad RAG, comparación de modelos, cumplimiento de instrucciones, tono, seguridad y relevancia | Puede premiar la prolijidad, seguir una rúbrica poco rigurosa o pasar por alto los riesgos cuando las instrucciones del jurado son imprecisas | Proporcionar a los equipos una indicación rápida de la calidad en conjuntos de pruebas de gran tamaño y derivar los resultados poco fiables para su revisión por parte de personas. |
Bueno, veamos Cómo funciona un modelo de lenguaje grande (LLM) en el papel de juez en un proceso de evaluación de productos. A primera vista, el procedimiento parece sencillo. Un modelo redacta una respuesta y otro la evalúa utilizando una rúbrica. El evaluador revisa la tarea, la respuesta y la rúbrica, y a continuación ofrece un resultado estructurado que el equipo puede utilizar.
Aquí tienes un ejemplo básico Diagrama del proceso de evaluación de un modelo de aprendizaje automático (LLM) como juez:
Para que resulte más fácil de entender, imagina una empresa que está probando un asistente de IA para la atención al cliente. En la práctica, el proceso funciona de la siguiente manera:
El sistema recibe la solicitud original. En nuestro ejemplo, un cliente quiere saber por qué su última factura es más elevada tras cambiar de plan. En otros productos, la tarea podría consistir en una pregunta estándar, una consulta RAG o una instrucción para un agente de IA.
La IA principal genera tres posibles respuestas a la pregunta del cliente. Una respuesta es breve y directa. Otra explica la lógica de facturación con más detalle. La tercera utiliza un tono más cordial y coloquial.
El sistema combina la pregunta del cliente, las tres opciones de respuesta y una rúbrica de evaluación estricta. Dado que este asistente utiliza el método RAG, también incluye la política de facturación para que el juez pueda verificar los hechos.
El evaluador revisa cada respuesta según la rúbrica. Comprueba si la respuesta explica correctamente la factura, utiliza la fuente adecuada, evita las conjeturas y se ajusta al tono de la marca. A continuación, el evaluador proporciona un resultado estructurado, a menudo en formato JSON, con una puntuación y una breve explicación de dicha puntuación.
El sistema selecciona la respuesta con la puntuación más alta para enviarla al cliente. Además, guarda en una base de datos las puntuaciones de los evaluadores, su razonamiento, la versión de la pregunta y el contexto de origen. Este registro permite al equipo hacer un seguimiento de cómo varía la calidad de las respuestas cuando actualizan el sistema.
Las respuestas con puntuación baja, los empates y los casos de alto riesgo se remiten a revisores humanos. Un revisor puede darse cuenta de que una respuesta es educada, pero no explica el motivo real del cambio de precio. Los comentarios de los revisores humanos ayudan a mejorar la rúbrica y a subsanar cualquier punto ciego que se le haya pasado por alto al evaluador.
El sistema recibe la solicitud original. En nuestro ejemplo, un cliente quiere saber por qué su última factura es más elevada tras cambiar de plan. En otros productos, la tarea podría consistir en una pregunta estándar, una consulta RAG o una instrucción para un agente de IA.
La IA principal genera tres posibles respuestas a la pregunta del cliente. Una respuesta es breve y directa. Otra explica la lógica de facturación con más detalle. La tercera utiliza un tono más cordial y coloquial.
El sistema combina la pregunta del cliente, las tres opciones de respuesta y una rúbrica de evaluación estricta. Dado que este asistente utiliza el método RAG, también incluye la política de facturación para que el juez pueda verificar los hechos.
El evaluador revisa cada respuesta según la rúbrica. Comprueba si la respuesta explica correctamente la factura, utiliza la fuente adecuada, evita las conjeturas y se ajusta al tono de la marca. A continuación, el evaluador proporciona un resultado estructurado, a menudo en formato JSON, con una puntuación y una breve explicación de dicha puntuación.
El sistema selecciona la respuesta con la puntuación más alta para enviarla al cliente. Además, guarda en una base de datos las puntuaciones de los evaluadores, su razonamiento, la versión de la pregunta y el contexto de origen. Este registro permite al equipo hacer un seguimiento de cómo varía la calidad de las respuestas cuando actualizan el sistema.
Las respuestas con puntuación baja, los empates y los casos de alto riesgo se remiten a revisores humanos. Un revisor puede darse cuenta de que una respuesta es educada, pero no explica el motivo real del cambio de precio. Los comentarios de los revisores humanos ayudan a mejorar la rúbrica y a subsanar cualquier punto ciego que se le haya pasado por alto al evaluador.
A menudo revisamos nuestro propio trabajo. Lo releemos, detectamos los puntos débiles y lo mejoramos. Entonces, ¿por qué iba a ser diferente en el caso de un modelo?
Podría parecer razonable que un modelo revisara su propio texto y lo calificara. Pero, en realidad, cuando un modelo revisa su propio texto, puede confundir una redacción fluida con la verdadera calidad. Es lo que se conoce como «sesgo de autoevaluación positiva». El modelo puede pasar por alto una lógica débil, frases repetidas o finales poco convincentes porque encajan en los mismos patrones que utilizó para redactar la respuesta. Como resultado, su propio resultado puede parecer mejor de lo que realmente es.
Por ejemplo, Sergei Molchanov, director de la unidad de negocio de Innowise, se topó con este problema mientras desarrollaba un motor de contenido automatizado para las publicaciones en X. Cada mañana, el sistema le enviaba tres variantes de publicación a través de Telegram. Él elegía una, a veces la editaba y la publicaba manualmente. La pregunta era sencilla: ¿qué borrador era realmente el mejor?
Al principio, Sergei pidió al modelo generador que puntuara sus propios borradores utilizando una rúbrica. Pero esto no le proporcionó una indicación útil. Las puntuaciones se mantuvieron muy próximas entre sí, en el rango de 36 a 40. Un borrador claramente más débil obtuvo una puntuación solo ligeramente inferior a la del favorito, por lo que la evaluación hacía que la elección pareciera más fácil de lo que era en realidad.
El resultado cambió cuando Sergei separó las funciones. Un modelo redactaba las publicaciones, mientras que otro modelo, a modo de evaluador, las puntuaba utilizando una rúbrica de nueve criterios. A partir de entonces, borradores similares empezaron a recibir puntuaciones más variadas, como 26, 32 y 39. El evaluador independiente detectó problemas que el generador había disimulado: palabras de matización como podría y probablemente, metáforas repetidas de entradas anteriores y frases de cierre vacías como el tiempo lo dirá.
Las distintas tareas de evaluación requieren configuraciones diferentes. Algunos equipos comparan las respuestas con una referencia conocida, mientras que otros evalúan respuestas en las que podría ser válida más de una versión. Por eso, los flujos de trabajo de producción suelen utilizar varias tTipos de modelos de lenguaje grande (LLM) que actúan como jueces sistemas.
Los jueces comparadores comparan el resultado de una IA con una respuesta de referencia verificada, también conocida como «verdad fundamental». Comprueban si la respuesta se ajusta a los hechos, sigue la lógica correcta o produce el resultado esperado.
Este enfoque funciona mejor cuando hay una respuesta clara. Por ejemplo, un bot de asistencia técnica podría tener que indicar la norma de garantía exacta, o un asistente de programación podría tener que utilizar un algoritmo específico. Las pruebas de rendimiento también suelen tener un único resultado correcto que comprobar.
El inconveniente es que los jueces comparativos no son muy flexibles. Pueden resultar demasiado estrictos en tareas en las que hay más de una respuesta correcta, sobre todo cuando la redacción, el tono o el contexto son importantes.
Muchas tareas de IA no tienen una única respuesta correcta. Por ejemplo, una respuesta a un cliente, un resumen o una publicación generada pueden ser válidos cada uno a su manera. En estos casos, el evaluador utiliza una rúbrica en lugar de una respuesta de referencia para evaluar el resultado.
Los criterios de evaluación abiertos son adecuados para evaluar el tono, la claridad, la exhaustividad, la utilidad y la calidad del contenido. El evaluador analiza si la respuesta se ajusta a la tarea, aborda los puntos clave y se adapta al uso previsto.
La rúbrica cobra especial importancia en este caso. Si las instrucciones se limitan a decir “valora la calidad de la respuesta”, el evaluador tiene demasiada libertad para hacer conjeturas. Sin embargo, si la rúbrica indica “comprueba si la respuesta incluye todos los pasos solicitados y evita afirmaciones sin fundamento”, la puntuación resulta más útil.
Los evaluadores comparativos examinan varios resultados correspondientes a una misma tarea y seleccionan el mejor. A veces, esto implica comparar dos respuestas una al lado de la otra, o clasificar varias opciones para determinar cuál es la mejor.
Sergei utilizó esta configuración en su motor de contenidos. El redactor elaboró tres versiones de una publicación X para el mismo encargo. El evaluador utilizó la misma rúbrica para revisarlas y ayudó a identificar el borrador más sólido.
Este tipo de evaluación resulta útil para pruebas rápidas, la selección de modelos y los flujos de trabajo de contenido en los que el equipo debe elegir entre diferentes versiones. Sin embargo, el orden o la longitud de las respuestas pueden seguir afectando a los resultados, por lo que los equipos suelen aleatorizar las opciones y comparar las decisiones de los evaluadores con una revisión humana.
Por eso Metodología de evaluación de «LLM como juez» resulta útil para la evaluación del RAG. Permite al equipo comprobar cada parte del proceso por separado, en lugar de limitarse a examinar el resultado final e intentar adivinar qué ha fallado. Esta revisión paso a paso se conoce a menudo como la «tríada del RAG».
Esta distinción hace que la depuración sea menos ambigua. Un problema de recuperación significa que el sistema no ha devuelto el material adecuado. Un problema de fundamentación significa que el material adecuado estaba ahí, pero el modelo no se ha ajustado a él. Si la respuesta solo es relevante a nivel superficial, el equipo debe revisar cómo el modelo transforma el contexto en una respuesta.
Los jueces del LLM también ayudan en el entrenamiento del modelo. Su función en este caso es crear una señal de preferencia, una indicación de entrenamiento que indique al bucle qué respuesta debe ocupar un puesto más alto en la clasificación y por qué.
En aprendizaje por refuerzo a partir de la retroalimentación humana, o RLHF, esta señal suele partir de las personas. Los evaluadores comparan dos respuestas modelo y seleccionan la mejor. Estas elecciones se convierten en datos de preferencia para un modelo de recompensa, lo que posteriormente ayuda al ciclo de entrenamiento a dar prioridad a respuestas similares.
El cuello de botella es el volumen. A medida que aumenta el conjunto de muestras, los revisores no pueden comprobar todos los pares al mismo ritmo. Un modelo de lenguaje grande (LLM) ayuda a clasificar primero los resultados, de modo que las personas puedan centrarse en los casos dudosos o en aquellos ejemplos en los que una preferencia errónea podría perjudicar al modelo.
Optimización relativa de políticas en grupo, o GRPO, trabaja con un grupo de respuestas. El modelo genera varias respuestas a la misma indicación, y el ciclo de entrenamiento necesita una señal de recompensa para cada respuesta de ese grupo. El GRPO no siempre necesita un juez LLM. En el caso de las matemáticas o la programación, una regla o un verificador pueden proporcionar la recompensa. Para tareas que no tienen una respuesta fija, un evaluador puntúa las respuestas según una rúbrica. Esto resulta útil cuando la calidad depende del cumplimiento de las políticas y del seguimiento de las instrucciones.
Existe un riesgo similar al de la evaluación de productos: una vez que las puntuaciones de los evaluadores se incorporan al entrenamiento, el modelo empieza a aprender de las preferencias de los evaluadores. Si el evaluador premia la verbosidad, el modelo puede aprender a ser verboso. Si pasa por alto atajos poco seguros, el modelo puede repetirlos. Las recompensas basadas en los evaluadores deben calibrarse antes de que influyan en el entrenamiento.
En las tareas de razonamiento, la puntuación basada en la respuesta final puede pasar por alto errores graves. Un modelo podría obtener el resultado correcto tras dar un paso erróneo. En programación o matemáticas, ese error oculto es importante, ya que ese mismo paso podría fallar en una tarea más difícil.
Modelos de recompensa por procesos, o PRM, evalúan el razonamiento a medida que el modelo avanza hacia la respuesta final. Un evaluador a nivel de proceso comprueba cada paso y señala dónde falla la lógica.
Una vez que las puntuaciones de los evaluadores se incorporan al entrenamiento, empiezan a moldear el comportamiento del modelo. Los equipos deben poner a prueba a los evaluadores, mantener a las personas en las muestras de alto riesgo y actualizar la rúbrica cuando el modelo empiece a adquirir hábitos erróneos.
Ahora que ya hemos visto cómo se configuran estos sistemas y cómo se comportan en un proceso de evaluación real, hablemos de las ventajas concretas. ¿Por qué deberías molestarte en configurar un evaluador de LLM en tu proyecto y qué beneficios obtienes de ello?
Los equipos humanos de control de calidad tienen un límite en cuanto al número de registros de chat o generaciones que pueden revisar al día. Un sistema de evaluación basado en un modelo de lenguaje grande (LLM) ayuda a revisar muestras mucho más amplias, incluido el tráfico de producción, cuya comprobación manual resultaría demasiado costosa. Esto ofrece a los equipos una mayor probabilidad de detectar problemas de calidad que se pasan por alto en las revisiones manuales a pequeña escala.
La evaluación basada en jueces suele tardar solo unos segundos. Los equipos pueden incorporarla a las comprobaciones de CI/CD o utilizarla como filtro antes de que un mensaje llegue al usuario. Los desarrolladores ven qué ha cambiado tras un pequeño ajuste en el mensaje sin tener que esperar días a que una persona lo revise.
Las métricas de software tradicionales se basan en coincidencias exactas de palabras clave o en la coincidencia de caracteres. Por ejemplo, si un modelo dice “El cliente está satisfecho” en lugar de “El usuario está contento”,” Un guion de evaluación estricto podría considerarla incorrecta. Un evaluador basado en un modelo de lenguaje grande (LLM) puede reconocer que el significado es lo suficientemente cercano y comprobar si la respuesta cumple con la rúbrica. Esto es importante en lo que respecta al tono y la estructura, ámbitos en los que las expresiones regulares apenas aportan información útil.
La anotación humana puede resultar costosa, sobre todo en el caso de tareas complejas de razonamiento o programación que requieren revisores expertos. Las revisiones mediante la API de los modelos de lenguaje grande (LLM) suelen tener un coste mucho menor por muestra.
En un proyecto reciente, un sistema automatizado de atención al cliente por correo electrónico generó tres borradores de respuesta corteses por un coste aproximado de $0.05 en tokens de API. Recurrir a un evaluador para revisar los tres borradores según nuestra guía de marca y elegir el mejor supuso un coste de aproximadamente $0.01. Esa fase de revisión costó alrededor de un céntimo.
Los revisores humanos se cansan. Por ejemplo, un etiquetador puede calificar un texto de forma diferente a última hora del viernes que a primera hora del lunes. Los evaluadores de los modelos de lenguaje grande (LLM) tienen sus propios sesgos técnicos, como la preferencia por textos más largos, pero no se cansan. Con unos ajustes fijos y una rúbrica probada, aplican los mismos criterios de forma más coherente que un equipo humano que tiene que procesar una larga cola de trabajo.
Cuando se modifica lo que evalúa el sistema, a menudo no es necesario reescribir cientos de líneas de código Python. En muchos casos, basta con actualizar los criterios de evaluación y volver a realizar la prueba. Por ejemplo, un criterio que comprueba la exactitud de los datos puede adaptarse para evaluar la empatía y el tono de la marca.
"No debes considerar a un juez de LLM como un mero verificador de calidad tipo «caja negra». Funciona mejor cuando tu equipo sigue una rúbrica clara, lleva un registro de cada puntuación y compara sus decisiones con las revisiones realizadas por personas. De lo contrario, solo obtendrás cifras, en lugar de información real sobre la calidad.."
Jefe de Peritaje Técnico IA
El concepto de «LLM como juez» Es útil, pero tiene sus defectos. Si se permite que una IA califique a otra, se introducen nuevos puntos ciegos en el proceso de evaluación. Sin una supervisión minuciosa, el sistema podría otorgar puntuaciones con seguridad a respuestas poco sólidas.
Estas son las principales dificultades a las que presto atención a la hora de configurar un juez automatizado.
Cuando un juez compara varios borradores a la vez, es posible que se decante por la primera o la última opción que vea. A veces, el orden en que aparece un borrador es más importante que su calidad. Para evitarlo, mezcla el orden de los borradores antes de enviárselos al juez.
Los modelos de lenguaje grande (LLM) suelen preferir respuestas más largas. Un evaluador podría otorgar una puntuación más alta a una respuesta larga y prolija en lugar de a una breve y clara, aunque la respuesta más breve resulte más útil. Para evitarlo, la rúbrica debería indicar al evaluador que penalice la prolijidad innecesaria.
Es posible que un modelo evaluador prefiera las respuestas redactadas por su propia familia de modelos. Por ejemplo, si se utiliza GPT-5.5 como modelo evaluador, es posible que otorgue una puntuación más alta a las respuestas de GPT-5.5 que a las de Claude Sonnet 5 o Gemini. Al modelo evaluador suele gustarle la redacción y la estructura que le resultan familiares, incluso si otra respuesta es mejor. Para conseguir resultados más justos, los equipos suelen utilizar varios modelos evaluadores y comparar sus puntuaciones.
Incluso un pequeño cambio en la rúbrica puede afectar a las puntuaciones finales. Por ejemplo, cambiar la instrucción de “Califica la utilidad” a “Evalúa lo útil que es esto” podría reducir la nota media de aprobado de 80% a 60%. El evaluador es sensible a la forma en que se redactan las reglas, por lo que las instrucciones deben tener diferentes versiones y ser revisadas por personas.
Si utilizas una API alojada, como GPT-5.5 o Claude Sonnet 5, como criterio de evaluación, es posible que el proveedor actualice el modelo sin previo aviso. Cuando esto ocurre, tus puntuaciones de referencia pueden cambiar de la noche a la mañana. Una respuesta que antes obtenía una puntuación de 4 sobre 5 podría obtener ahora un 3, lo que dificulta la comparación con resultados anteriores.
Si sigues entrenando un modelo generador utilizando la retroalimentación del mismo evaluador del LLM, el generador podría aprender a burlar el sistema. En lugar de mejorar las respuestas para los usuarios, se fija en las palabras y los formatos que prefiere el evaluador. Incluso podría imitar el tono que obtiene puntuaciones más altas. Las puntuaciones suben, pero la calidad real del producto puede disminuir.
Incorporar un modelo de lenguaje grande (LLM) a tu flujo de trabajo es sencillo, pero conseguir que sus puntuaciones sean lo suficientemente fiables como para tomar decisiones sobre la publicación supone un mayor reto. Si solo utilizas una indicación básica y le pides al modelo que califique este texto, los resultados suelen ser inconsistentes.
Mientras configuraba estos flujos de trabajo, he recopilado los más populares Técnicas de «LLM como juez» que contribuyen a mantener la estabilidad de los modelos de evaluación en tareas de evaluación reales.
Es importante estructurar los resultados de la evaluación desde el principio. En lugar de utilizar comentarios de formato libre, haz que el modelo devuelva puntuaciones para cada criterio, una breve explicación y una nota final en un formato que tu proceso de trabajo pueda leer fácilmente.
Por ejemplo, evita que el modelo genere respuestas libres del tipo “Este texto está bastante bien, le doy un 8 sobre 10”. Estas respuestas son difíciles de procesar mediante código. En su lugar, haz que el modelo utilice un esquema JSON estricto con resultados estructurados, o utiliza la llamada a herramientas y Métricas de «LLM como juez».
Las instrucciones poco claras dan lugar a puntuaciones poco claras. Por ejemplo, si le pides a un jurado que valore la “creatividad” del 1 al 5, el modelo se limitará a adivinar. En su lugar, utiliza criterios específicos que reduzcan el margen de interpretación.
Por ejemplo, a la hora de evaluar artículos o publicaciones escritas, evito las puntuaciones generales de calidad. En su lugar, divido la rúbrica en aspectos más concretos, como estos:
Es importante estructurar los resultados de la evaluación desde el principio. En lugar de utilizar comentarios de formato libre, haz que el modelo devuelva puntuaciones para cada criterio, una breve explicación y una nota final en un formato que tu proceso de trabajo pueda leer fácilmente.
Por ejemplo, evita que el modelo genere respuestas libres del tipo “Este texto está bastante bien, le doy un 8 sobre 10”. Estas respuestas son difíciles de procesar mediante código. En su lugar, haz que el modelo utilice un esquema JSON estricto con resultados estructurados, o utiliza la llamada a herramientas y Métricas de «LLM como juez».
Mantén separados el generador y el evaluador. Este es uno de los controles fundamentales en una configuración de «LLM como evaluador», ya que el modelo que ha redactado la respuesta puede pasar por alto sus propios patrones o sobrevalorar expresiones que le resultan familiares. Por ejemplo, si utilizas GPT-5.5 para generar texto, utiliza Claude Sonnet 5 como evaluador, o al revés. También puedes utilizar un modelo de peso abierto más pequeño y ajustado, como una variante especializada de Llama 4 Maverick o Llama 4 Scout, para la evaluación. Este enfoque puede ayudar a reducir los costes y a minimizar el sesgo de auto-mejora.
Como ya hemos comentado en la sección sobre riesgos, los modelos pueden presentar un sesgo de posición. Para evitarlo, aleatoriza el orden de las respuestas en cada comparación. Al evaluar pares o múltiples resultados, un modelo podría elegir la primera respuesta simplemente por su posición. Baraja las opciones antes de evaluarlas y, a continuación, asocia la respuesta elegida al modelo o a la indicación original en tu código. En pruebas importantes, prueba a intercambiar el orden y toma nota de cualquier caso en el que el ganador cambie tras el cambio.
Para reducir el sesgo sistémico, asegúrate de que el evaluador no vea ningún metadato de generación. El evaluador no debe saber qué modelo ha generado el texto ni qué prompt se ha utilizado. Facilita al evaluador únicamente el resultado sin procesar y la rúbrica de evaluación.
La redacción y la evaluación requieren ajustes diferentes del modelo. Al generar texto, utiliza una temperatura más alta, entre 0,7 y 0,9, para fomentar la variedad y una fluidez natural. Para la evaluación, ajusta la temperatura a un valor bajo, normalmente a 0, para que el modelo otorgue puntuaciones más consistentes para una misma entrada.
Pero ten en cuenta que una temperatura de 0 hace que las comprobaciones repetidas sean más estables solo cuando la entrada se mantiene igual. No soluciona la sensibilidad de las indicaciones, los cambios en la rúbrica ni el sesgo de posición. Si reescribes la rúbrica o cambias el orden de las respuestas, la puntuación puede seguir variando.
Cuando OpenAI, Anthropic o Google actualicen los puntos finales de sus modelos, es posible que tu evaluador se vuelva más indulgente o más estricto. Para detectar esto, crea un pequeño conjunto de datos de referencia compuesto por entre 50 y 100 respuestas históricas que ya hayan sido calificadas y aprobadas por personas. Ejecuta tu evaluador LLM con este conjunto de datos una vez a la semana. Si las puntuaciones suben o bajan de repente, es posible que el modelo se haya desviado y que tengas que ajustar tus indicaciones o fijar tu API a una versión estática.
Un evaluador automatizado es un asistente, no un sustituto de la supervisión humana. Realiza un seguimiento del índice de concordancia entre el evaluador del modelo de lenguaje grande (LLM) y tu equipo humano de control de calidad. Si utilizas una concordancia de entre 85% y 90% como objetivo interno, considérala más bien un indicador de estado que una norma universal. Si esa concordancia disminuye, es posible que los requisitos de tu producto hayan cambiado y sea el momento de actualizar la rúbrica.
Conocer los riesgos de los evaluadores de modelos de lenguaje grande (LLM) solo resulta útil si el sistema cuenta con controles para detectarlos. Por ejemplo, un evaluador podría decantarse por la primera respuesta que vea o otorgar puntuaciones más altas a las respuestas más largas. A veces, una actualización del modelo puede modificar las puntuaciones aunque tu producto no haya cambiado en absoluto.
A continuación se detallan las prácticas que utilizo con mayor frecuencia para reducir los sesgos y detectar datos de evaluación poco fiables.
Al comparar los resultados, asegúrate de que el jurado no sepa qué borrador procede de cada prompt o modelo. Mezcla siempre las opciones antes de enviárselas al jurado. Si el jurado elige la “Opción A”, tu código debería asociar discretamente esa elección a la variante real del modelo.
Esta norma también se aplica a los metadatos. La indicación de evaluación solo debe incluir el texto sin formato y la rúbrica, no el nombre del modelo ni los detalles de la generación. Si el evaluador ve detalles como el tamaño del modelo, el recuento de tokens o el tiempo de procesamiento, podría utilizarlos como atajos para valorar la calidad.
En el caso de los indicadores de producción importantes, es posible que un único modelo de evaluación no sea suficiente. Por ejemplo, un modelo de evaluación basado en GPT podría tener preferencias diferentes a las de Claude o a las de un modelo Llama ajustado.
Para las evaluaciones críticas, prefiero enviar el mismo resultado a varios modelos evaluadores y comparar sus puntuaciones. Puedes calcular la media de las puntuaciones o utilizar el voto mayoritario, pero asegúrate de que los evaluadores sean independientes. Si los evaluadores son demasiado similares, el panel podría parecer más fiable de lo que realmente es. Presta mucha atención a los desacuerdos. Si dos evaluadores otorgan una puntuación de 5 sobre 5 y otro da un 1 sobre 5, envía ese caso a una persona para que lo revise. Las grandes diferencias suelen indicar que la rúbrica deja demasiado margen para la interpretación.
Un sistema de evaluación automático debería ajustarse a la forma en que el personal cualificado utiliza la rúbrica. Para comprobarlo, selecciona una muestra aleatoria de registros evaluados con el código 5% y pide a tu equipo interno que los califique de forma ciega utilizando la misma rúbrica.
A continuación, compara los resultados. Algunos equipos utilizan el coeficiente kappa de Cohen, mientras que otros se limitan a fijarse en el porcentaje de concordancia. Si tu objetivo es una concordancia del 85% y la puntuación del evaluador queda por debajo de ese valor, el problema suele ser que la rúbrica ya no es lo suficientemente clara o que los requisitos de tu producto han cambiado.
Algunos flujos de trabajo requieren una comprobación adicional: la memoria. Esto es importante para los motores de contenido, los generadores de informes diarios y otros sistemas que producen resultados similares a lo largo del tiempo.
Un resultado aislado puede parecer correcto por sí solo. Pero si el generador utiliza la misma analogía tres días seguidos, los usuarios se darán cuenta. Una revisión puntual por parte de un revisor podría pasar esto por alto.
En estos casos, le proporciono al juez un resumen de los días anteriores. Cuando revisa los borradores de hoy, la indicación incluye un índice vectorial continuo o un breve resumen de los resultados aprobados de los últimos 7 a 14 días. Esto permite al juez detectar metáforas repetidas, ganchos reutilizados, palabras de relleno y frases finales débiles que pasarían desapercibidas en una revisión de un solo documento.
¿En qué ámbitos utilizan los equipos de ingeniería este enfoque? Durante el último año, he visto cómo los evaluadores de modelos de lenguaje grande (LLM) han pasado de utilizar pequeños scripts de evaluación a flujos de trabajo de IA en producción.
Veamos cuáles son los principales ámbitos en los que, en mi opinión, se utilizan hoy en día.
Como se ha mencionado anteriormente, los sistemas RAG constituyen un claro caso de uso para los evaluadores automatizados. Los equipos utilizan estos evaluadores para comprobar que el sistema de recuperación encuentra el contexto correcto y que la respuesta final se basa en los documentos de origen. Esto ayuda a detectar afirmaciones sin fundamento antes de que se conviertan en «alucinaciones».
Con los motores de contenido automatizados, rara vez es buena idea publicar el primer borrador generado por un modelo. En su lugar, los procesos automatizados crean varias versiones y recurren a un evaluador para compararlas con una rúbrica. El evaluador selecciona el borrador más sólido y señala las expresiones genéricas antes de su publicación.
Los bots de asistencia pueden causar problemas si se salen del guion. Los equipos recurren a evaluadores para que revisen grandes volúmenes de registros de chat una vez finalizada la conversación. El evaluador comprueba si el bot ha respondido a la pregunta del usuario y ha seguido las normas de la empresa, incluidas las políticas de reembolso, los pasos de escalación y las promesas sobre las funcionalidades.
Las listas de palabras prohibidas y los filtros de expresiones regulares tradicionales son fáciles de eludir. Un sistema de evaluación basado en un modelo de lenguaje grande (LLM) tiene en cuenta el significado y el contexto, lo que ayuda a los equipos de moderación a detectar contenidos nocivos que no utilizan palabras prohibidas evidentes. Puede revisar tanto las peticiones de los usuarios como las respuestas del modelo para comprobar que se ajustan a la política.
A medida que los agentes de IA empiezan a realizar acciones mediante herramientas y API, no basta con evaluar el texto final. En estos flujos de trabajo, los evaluadores revisan todo el proceso. Comprueban el uso de las herramientas, el avance de la tarea y si el agente la ha completado sin quedarse atascado.
No debes elegir un modelo de evaluación basándote únicamente en su puntuación en las pruebas de rendimiento. El mejor modelo depende de la tarea para la que lo necesites. Por ejemplo, un modelo que sea eficaz a la hora de puntuar rápidamente los registros de asistencia técnica podría no ser lo suficientemente potente como para gestionar datos de preferencias durante el entrenamiento. Un modelo de primer nivel podría ser ideal para evaluaciones de alto riesgo, pero su uso cada noche con miles de resultados podría resultar demasiado costoso.
Por eso, lo primero que suelo tener en cuenta son cuatro aspectos: qué debe evaluar el juez, cuánto contexto necesita, con qué rapidez debe obtenerse la puntuación y qué ocurre si la puntuación es errónea.
Las tareas de generación y evaluación suelen requerir diferentes configuraciones y potencias de los modelos.
La generación de texto es una tarea creativa. Para ello, normalmente se necesita un modelo potente, como GPT-5.5, Claude Sonnet 5 o Claude Opus 4.8, configurado con un valor de «temperatura» más alto para que el texto suene más natural.
La evaluación es una tarea que requiere gran concentración, pero la calidad suele ser lo primero. Para los controles de lanzamiento, los datos de preferencias, las comprobaciones RAG o los resultados de alto riesgo, los equipos suelen utilizar el modelo de evaluación más potente que pueden permitirse. Los modelos más rápidos pueden servir para comprobaciones por lotes de bajo riesgo tras su calibración con muestras revisadas por personas.
A la hora de elegir un modelo de evaluación, hay que partir del coste que supone una puntuación incorrecta. En muchas configuraciones de modelos de lenguaje grande (LLM) con evaluación, la calidad de la evaluación es más importante que la velocidad o el coste por token, sobre todo cuando las puntuaciones influyen en las decisiones de lanzamiento, los datos de entrenamiento o los mecanismos de control dirigidos a los usuarios.
No deberías tener que analizar texto sin formato para averiguar qué puntuación ha otorgado el juez. A la hora de elegir un modelo de juez, es fundamental que siga un esquema estricto. Puedes utilizar «Structured Outputs» de OpenAI, «Tool Use» de Anthropic o un marco de código abierto como Outlines. En todos los casos, el modelo debería devolver una respuesta JSON limpia. Si un modelo es barato y rápido, pero a menudo incumple el formato JSON, resulta difícil de utilizar en un proceso automatizado de evaluación.
No siempre es necesario elegir un solo modelo. Para tareas importantes, suelo optar por un enfoque de conjunto. En lugar de confiar en un único modelo caro, envío la misma evaluación a varios modelos de evaluación de distintos proveedores, como OpenAI, Anthropic y una opción de código abierto.
Después, puedes comparar sus puntuaciones, calcular la media o recurrir a una votación por mayoría. Esto ayuda a reducir el sesgo de cualquier juez en particular. Sin embargo, los jueces deben ser lo suficientemente diferentes entre sí. Si todos cometen los mismos errores, calcular la media o votar solo servirá para repetir el mismo sesgo. Por eso también busco desacuerdos entre los jueces y envío los casos poco claros a una persona para que los revise.
El uso de LLM como «juez» sigue siendo una forma novedosa de evaluar modelos. Muchos equipos ya utilizan «jueces» para la puntuación, la comparación y las comprobaciones RAG, pero su configuración sigue requiriendo mucho trabajo manual. El siguiente paso es hacer que los sistemas de evaluación sean más fiables. Deberían indicar cuándo una puntuación es incierta, utilizar herramientas para verificar los resultados y ofrecer un mejor rendimiento en ámbitos específicos.
Estas son las áreas a las que presto más atención.
En estos momentos, los jueces de LLM pueden mostrarse demasiado seguros de sí mismos. Si un juez recibe una indicación poco clara, es posible que, aun así, asigne una puntuación definitiva en lugar de indicar que el caso es incierto.
Espero que cada vez más sistemas de puntuación empiecen a mostrar los niveles de confianza junto con la puntuación. En lugar de limitarse a decir pase o fallar, el juez podría dictar algo así como Puntuación: 4, Confianza: 65%. Si el nivel de confianza es demasiado bajo, el sistema puede derivar el caso a un revisor humano.
Los modelos de uso general, como GPT-5.5 o Claude Sonnet 5, funcionan bien para tareas como correos electrónicos, resúmenes y revisiones básicas de código. Sin embargo, para evaluaciones médicas o jurídicas complejas, necesitamos un mayor control sobre el ámbito en cuestión.
Por eso espero que surjan modelos de jueces más especializados. Algunos podrían optimizarse para tareas específicas, como revisar respuestas médicas o comprobar contratos legales. Estos modelos no sustituirán a los expertos, pero pueden ayudar gestionando los casos rutinarios y derivando los más complejos a las personas.
Un herramienta para la evaluación de los modelos de lenguaje grandes (LLM) en su función de juez Es probable que se incorpore a más procesos de evaluación. Los jueces no deberían basarse únicamente en lo que saben de forma interna cuando pueden contrastar las tareas con fuentes externas.
Por ejemplo, si un generador escribe un guion Python, el juez puede ejecutarlo en un entorno de pruebas para detectar posibles errores. Si el generador afirma algo sobre un acontecimiento reciente, el juez puede recurrir a una búsqueda o a una fuente de datos fiable para verificarlo. La idea es contrastar el resultado con pruebas objetivas, en lugar de evaluar el texto de forma aislada.
Cuando los equipos utilizan las puntuaciones de los evaluadores en los ciclos de entrenamiento, los modelos generativos pueden llegar a aprender a complacer al evaluador en lugar de ofrecer mejores respuestas a los usuarios. Se trata de una forma de «manipulación de recompensas».
Por ejemplo, el generador podría deducir que al evaluador le gustan las listas con viñetas o un lenguaje muy cortés. También podría empezar a repetir frases de relleno que suelen obtener buenas puntuaciones. Los futuros sistemas de evaluación necesitarán mejores formas de detectar esto, para que las puntuaciones reflejen la calidad real de las respuestas.
Muchos equipos siguen considerando la evaluación como un proceso independiente que se ejecuta tras una actualización del modelo o de las instrucciones. Creo que esto cambiará a medida que los sistemas de IA se vayan integrando cada vez más en la producción. El siguiente paso es incorporar la evaluación al proceso de entrega. Antes del lanzamiento, los evaluadores pueden ayudar a detectar regresiones en los conjuntos de prueba. Tras el lanzamiento, pueden supervisar los resultados muestreados y derivar los casos de riesgo al personal correspondiente.
Si has leído hasta aquí, es probable que estés pensando en un problema de evaluación de tu sistema de IA. Quizá la revisión manual sea demasiado lenta. Quizá tus puntuaciones indiquen que la calidad ha cambiado, pero no expliquen qué es lo que realmente ha fallado.
Por eso es importante la configuración. No debe ser el mismo modelo el que elabore las preguntas y las califique. Se necesita una rúbrica clara, un método estructurado para registrar los resultados y una revisión periódica por parte de personas para mantener el sistema calibrado.
El verdadero riesgo es que una respuesta fluida pueda, aun así, no cumplir con la tarea. Un modelo puede parecer seguro de sí mismo, pero pasar por alto el contexto original o ignorar una parte fundamental de la solicitud del usuario. Una capa de evaluación bien diseñada te ayuda a detectar esa laguna antes de que lo hagan tus usuarios.
En Innowise, ayudamos a los equipos a crear capas de evaluación para Productos LLM, Agentes de IA, y sistemas de IA para empresas. Si tu producto de IA necesita controles de calidad más rigurosos, hablemos.
El «LLM-as-a-judge» es un método de evaluación en el que un modelo de lenguaje (el «juez») evalúa, puntúa y justifica los textos generados por otros sistemas de IA. Sustituye a las costosas revisiones humanas al automatizar a gran escala los controles de calidad en cuanto a precisión, relevancia, tono o seguridad.
Los evaluadores de modelos de lenguaje grande (LLM) suelen ofrecer resultados precisos en muchas tareas de evaluación, pero su rendimiento depende de la tarea, el modelo, la rúbrica y la calibración del sistema. Los equipos deben comparar las puntuaciones de los evaluadores con muestras revisadas por personas y estar atentos a posibles sesgos, a la sensibilidad a las indicaciones y a la deriva.
Los jueces de LLM aceleran y amplían el flujo de trabajo de evaluación sin sustituir por completo a las personas. La supervisión humana sigue siendo necesaria en casos delicados, para crear conjuntos de datos de entrenamiento y para establecer criterios de calificación.
Cuando un alumno corrige su propio trabajo, tiende a sobrevalorarse. A menudo pasa por alto sus propios errores y problemas de redacción, lo que da lugar a puntuaciones demasiado altas y poco útiles.
La tríada RAG es un marco de evaluación diseñado para sistemas de generación aumentada por recuperación. Mide el rendimiento en tres aspectos específicos: relevancia del contexto, fundamentación y relevancia de la respuesta final.
En los ciclos de aprendizaje por refuerzo, los jueces de LLM generan rápidamente señales de preferencia automatizadas y puntuaciones paso a paso. Esto permite que los modelos de recompensa optimicen la alineación del sistema mucho más rápido que las evaluaciones manuales realizadas por personas.
Los principales riesgos se derivan de los sesgos inherentes al modelo, entre los que se incluyen la tendencia a dar preferencia a las respuestas más largas (sesgo de verbosidad), a las respuestas que aparecen en primer lugar (sesgo de posición) y a mostrar una gran sensibilidad ante cambios mínimos en la redacción de las indicaciones.
Los equipos pueden minimizar el sesgo separando los modelos de generación y de evaluación, aleatorizando el orden de las respuestas en entornos comparativos, ocultando los metadatos de los modelos y validando las puntuaciones automáticas comparándolas con valores de referencia revisados por personas.
