Qué significa evaluar un sistema de IA

La evaluación empieza por una decisión

Antes de seleccionar casos o métricas conviene identificar qué se quiere decidir. Comparar dos alternativas, autorizar un uso limitado y ampliar la autonomía de un agente son decisiones distintas. Pueden necesitar pruebas relacionadas, pero no intercambiables.

Una comparación busca diferencias relevantes entre opciones. Una comprobación de aceptación necesita verificar condiciones mínimas. Una revisión de cambio pregunta además qué capacidades se han conservado y dónde aparecen regresiones. Confundir estos objetivos puede producir un informe preciso que no responde a la cuestión pendiente.

También debe quedar claro quién utilizará la evidencia. El equipo técnico puede necesitar localizar una causa de fallo, mientras operaciones necesita conocer cuánto trabajo de revisión permanece. La misma prueba puede aportar información a ambos, pero debe presentarla de forma que cada uno pueda decidir.

Los criterios deberían formularse antes de contemplar las salidas que se quieren aprobar. Si se redefinen después de verlas, existe el riesgo de adaptar el juicio al comportamiento disponible. Cambiar un criterio puede ser legítimo, pero el cambio debe quedar visible y tener una razón distinta de mejorar la puntuación.

Una buena evaluación no obliga a que todas las partes estén de acuerdo desde el principio. Puede revelar precisamente un desacuerdo sobre qué se considera útil. Resolverlo forma parte de definir el sistema; esconderlo detrás de una media solo pospone la decisión.

El resultado no explica todo el recorrido

Una salida aceptable puede haberse producido de una forma que la organización no permite. El sistema puede alcanzar un objetivo utilizando información indebida, omitiendo una revisión o consumiendo recursos fuera del límite acordado.

Por eso, el objeto de evaluación debe incluir las restricciones relevantes, además del resultado. No hace falta juzgar cada paso con el mismo detalle. Hace falta identificar qué condiciones no pueden perderse aunque la salida final sea correcta.

En agentes que actúan sobre herramientas, también importa distinguir lo que se afirma de lo que ha ocurrido. Anthropic separa en su explicación de evaluaciones el registro de una ejecución y el estado final que esa ejecución deja en el entorno. Esa distinción evita tomar la explicación del agente como prueba suficiente del resultado.

La información necesaria para comprobarlo debe formar parte del diseño de la prueba. Si solo se conserva el mensaje final, puede resultar imposible saber si se respetó un permiso o si una operación quedó pendiente. La evaluación no puede recuperar evidencia que nunca se registró.

Al mismo tiempo, registrar más no garantiza entender mejor. La traza necesita relacionarse con la tarea y con los criterios que se están comprobando. Una colección extensa de eventos sin identidad de operación ni interpretación puede producir volumen sin capacidad de juicio.

El resultado, el recorrido y los efectos ofrecen perspectivas complementarias. La evaluación debe decidir cuál necesita observar para cada compromiso del sistema y evitar que una dimensión favorable oculte un incumplimiento en otra.

Los casos representan una parte del mundo

Una colección de pruebas delimita lo que se ha observado. Su valor depende de la relación con el uso previsto, no únicamente de cuántos ejemplos contiene.

Los casos frecuentes ayudan a entender el comportamiento habitual. Los casos límite muestran qué ocurre cerca de una frontera. Las situaciones adversas permiten examinar restricciones que no aparecen en una entrada bien preparada. Ningún grupo sustituye automáticamente a los demás.

La selección debe conservar las diferencias que importan al trabajo. Si hay documentos de calidad desigual, solicitudes ambiguas o fuentes contradictorias, evaluar solo entradas limpias deja sin examinar parte del servicio. Tampoco sería representativo medir únicamente situaciones extremas y presentar su resultado como comportamiento cotidiano.

Conviene distinguir entre una muestra orientada a estimar el funcionamiento habitual y una colección diseñada para descubrir fallos. Ambas son útiles, pero responden a preguntas distintas. Un conjunto deliberadamente difícil no permite inferir por sí solo la frecuencia de esos problemas en producción.

Los casos necesitan resultados esperados o criterios de aceptación suficientemente claros. Algunas tareas admiten varias soluciones válidas. En ellas, comparar con una única frase de referencia puede penalizar respuestas correctas que utilizan otra formulación.

La cobertura siempre tiene límites. Un informe debería explicar qué clases de entrada, herramientas y condiciones se incluyeron, y cuáles siguen sin probarse. Esa delimitación convierte los resultados en evidencia utilizable y evita que «ha pasado las pruebas» se interprete como una garantía general.

Quien evalúa también necesita evaluación

Algunas condiciones se pueden comprobar directamente: un campo obligatorio existe, un cálculo cumple una regla o un estado esperado aparece en el sistema. Otras requieren juicio sobre claridad, pertinencia o calidad de una propuesta.

El mecanismo de evaluación debe responder a la naturaleza del criterio. Una comprobación automática precisa puede ser mejor que una opinión general para verificar una restricción concreta. Una comparación literal puede ser insuficiente para valorar una explicación que admite varias respuestas correctas.

Utilizar otro modelo como evaluador puede ayudar con criterios abiertos, pero incorpora un componente cuyo comportamiento también debe examinarse. Una instrucción detallada y una puntuación numérica no convierten su juicio en una medida objetiva.

El estudio Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena examinó limitaciones como los sesgos de posición y de extensión de las respuestas en los evaluadores estudiados. No demuestra que todo juez actual falle del mismo modo; sí aporta una razón documentada para comprobar cómo juzga en el contexto concreto.

La revisión humana tampoco es infalible. Dos personas pueden interpretar de forma distinta una rúbrica o disponer de información desigual. Conviene hacer visibles esos desacuerdos, aclarar criterios y conservar ejemplos que expliquen las decisiones difíciles.

El evaluador forma parte del instrumento de medida. Si cambia, puede cambiar la puntuación aunque el sistema evaluado no haya mejorado. Por eso, su versión y sus criterios deben acompañar a los resultados, especialmente cuando se comparan entregas sucesivas.

Comparar cambios exige conservar una referencia

Una mejora debe poder relacionarse con una diferencia concreta. Si cambian simultáneamente el modelo, las instrucciones, las fuentes y los casos de prueba, será difícil saber qué explica el resultado observado.

No siempre es posible aislar cada variable, pero sí documentar qué ha cambiado. Esa información permite distinguir una comparación controlada de una evaluación de una nueva solución completa. Ambas pueden ser válidas si se interpreta correctamente su alcance.

La repetición también importa cuando el sistema produce resultados variables. Un único acierto demuestra que una tarea se resolvió en esa ejecución. No establece con qué consistencia se resolverá ni cómo se distribuyen los fallos.

El número de repeticiones debe responder a la decisión y al coste de equivocarse. No existe una cantidad universal que convierta cualquier prueba en suficiente. La evidencia puede ser adecuada para continuar una exploración y seguir siendo insuficiente para ampliar una operación de consecuencias importantes.

Conviene conservar casos que el sistema ya resolvía y comprobarlos después de cada cambio relevante. Si la nueva versión mejora un grupo y empeora otro, la decisión necesita ver ambas cosas. Un promedio agregado puede ocultar precisamente la regresión que más importa al servicio.

También hay que evitar que la referencia se convierta en el único objetivo. Ajustar continuamente contra los mismos ejemplos puede mejorar esa colección sin demostrar una mejora equivalente en situaciones nuevas. Reservar casos para una comprobación posterior y renovar la cobertura ayuda a mantener una relación más honesta entre prueba y uso.

Los resultados necesitan un criterio de aceptación

Un informe de evaluación puede describir el comportamiento sin decidir si resulta aceptable. Esa decisión requiere relacionar los hallazgos con el uso previsto y con las consecuencias de los errores.

Algunos criterios admiten compensaciones. Una mejora de calidad puede justificar cierta demora adicional. Otros representan límites que no deberían disolverse en una puntuación media. Un buen resultado en redacción no compensa una acción que excede los permisos acordados.

Por eso, conviene separar las condiciones de paso de las dimensiones que se comparan gradualmente. El equipo puede analizar coste, tiempo y utilidad sin convertir una restricción obligatoria en un peso pequeño dentro de una suma.

La evidencia también puede justificar un alcance menor que el inicialmente previsto. Un sistema puede resultar útil para preparar trabajo y no estar listo para ejecutarlo sin revisión. Aceptar ese uso limitado es una decisión diferente de declarar un fracaso o aprobar autonomía completa.

Es importante que las excepciones no desaparezcan del informe. Si algunos casos requieren revisión manual, ese trabajo forma parte de las condiciones del servicio. La evaluación debe mostrarlo para que la organización pueda decidir si dispone de capacidad para asumirlo.

El umbral de aceptación pertenece al diseño del uso. Debe poder explicarse por su relación con el trabajo y mantenerse visible cuando cambian las condiciones. Copiar el porcentaje de otra aplicación no aporta esa justificación.

Operar aporta evidencia que el ensayo no contiene

Las pruebas previas permiten observar condiciones seleccionadas. La operación introduce otras combinaciones, usos y cambios. Por eso, la evaluación de un sistema no termina en una aprobación inicial.

El seguimiento del servicio puede revelar nuevas clases de entrada, demoras inesperadas o tareas que los usuarios interpretan de otro modo. Esa información sirve para revisar tanto el sistema como la colección de pruebas. No todos los problemas nuevos se resuelven cambiando el modelo.

También es necesario distinguir el seguimiento de una evaluación controlada. Una alerta informa de una condición observada; no siempre explica su causa. Una queja identifica una experiencia relevante; no permite por sí sola estimar su frecuencia. Cada señal necesita situarse dentro de la evidencia disponible.

Los incidentes y las correcciones pueden convertirse en casos de regresión, siempre que se preserven las condiciones relevantes y se proteja la información que corresponda. El objetivo es conservar lo aprendido sin convertir datos de operación en material de prueba indiscriminado.

La organización necesita un registro de decisiones, además de resultados. Qué se autorizó, con qué límites y sobre qué versión de las pruebas. Esa trazabilidad permite revisar una aprobación cuando cambian el sistema o su entorno.

Evaluar bien no elimina la incertidumbre. La hace más concreta: permite saber qué se ha demostrado, dónde siguen existiendo dudas y qué decisión resulta razonable con la evidencia actual. Esa es una base más útil para operar que una puntuación sin contexto.