De acertar una respuesta a completar una tarea: cómo evolucionó la evaluación de la IA

La pregunta histórica: ¿qué significa evaluar una capacidad de IA?

Evaluar una capacidad de inteligencia artificial significa convertir una pregunta amplia —por ejemplo, si un sistema comprende instrucciones o puede ayudar a resolver problemas— en una prueba con tareas, condiciones y una regla para juzgar los resultados. La puntuación que se obtiene no mide la capacidad en abstracto: resume el desempeño bajo esas condiciones concretas.

Una respuesta correcta a una pregunta, una solución que supera pruebas de software y una operación que deja una aplicación en el estado solicitado son evidencias diferentes. No se pueden tratar como unidades intercambiables. Cada una hace visibles ciertos aciertos y fallos, y deja otros fuera. Por eso, la historia de la evaluación puede leerse, en parte, como un cambio en lo que cuenta como unidad evaluada: primero, respuestas a ejemplos delimitados; después, conjuntos más variados de tareas; y, en algunos benchmarks recientes, secuencias de acciones ejecutadas en entornos.

Esta secuencia sirve como marco interpretativo, no como una cronología exhaustiva ni como una escalera inevitable hacia una medida mejor. Los trabajos seleccionados representan enfoques distintos. Un benchmark de respuestas puede ser adecuado para una pregunta acotada; uno interactivo puede aportar evidencia más directa sobre ejecución, pero también añade dependencias del entorno y del protocolo.

Primera etapa: tareas delimitadas y respuestas puntuables

En una evaluación basada en conjuntos de datos, cada ejemplo plantea una entrada y establece qué salida se considera correcta o qué criterio debe aplicarse. En comprensión del lenguaje, la entrada puede ser una oración o un par de oraciones; la salida, una etiqueta, una valoración o una respuesta. El resultado agregado permite comparar sistemas que participaron en la misma tarea y bajo un protocolo común.

Este diseño tiene ventajas prácticas. Los ejemplos pueden repetirse, los resultados pueden calcularse de forma consistente y los investigadores pueden comparar métodos sin pedirles que operen una aplicación completa. Si la pregunta es si un modelo distingue una relación semántica concreta, una tarea de clasificación bien definida puede proporcionar evidencia útil.

Pero la unidad evaluada es estrecha. Obtener una etiqueta correcta no demuestra que el sistema pueda planificar una serie de pasos, utilizar herramientas, reaccionar ante un cambio inesperado o completar una tarea en una interfaz. Tampoco una puntuación agregada explica por sí sola dónde se concentra el error. La cobertura de los datos, la forma de plantear las preguntas y la métrica escogida delimitan lo que se puede inferir.

La inferencia prudente es condicional: el sistema alcanzó cierto resultado en esas tareas, con esos datos y esa regla de puntuación. Para sostener afirmaciones más amplias sobre competencia general, robustez o utilidad en una situación real, hacen falta pruebas adicionales.

Ampliar el campo de prueba: GLUE y BIG-bench

GLUE, presentado en 2018, reúne varias tareas de comprensión del lenguaje natural en un benchmark multitarea y una plataforma de análisis. Su diseño desplaza el foco de una única prueba a un conjunto de problemas relacionados: permite observar si un sistema obtiene resultados en distintas tareas y ofrece un modo de resumir parte de ese desempeño. La diversidad de tareas hace más difícil reducir la evaluación a una sola habilidad, aunque no elimina las limitaciones de cada tarea ni convierte el resultado agregado en una medida universal.

BIG-bench amplió todavía más la variedad de pruebas reunidas. En lugar de centrarse en una familia relativamente acotada de problemas lingüísticos, planteó una colección amplia de tareas aportadas por distintos colaboradores, con objetivos y formas de evaluación variados. El trabajo examina cómo se desempeñan modelos de lenguaje en esa colección y cómo cambian los resultados al variar la escala de los modelos.

El cambio importante no consiste solo en sumar ejemplos. Una colección heterogénea puede poner a prueba capacidades y comportamientos diferentes, y revelar que un sistema fuerte en una tarea no necesariamente lo es en otra. A la vez, esa variedad complica la comparación: las tareas pueden tener formatos, métricas y niveles de dificultad distintos. Una cifra agregada facilita una lectura panorámica, pero puede ocultar diferencias importantes entre componentes.

En ambos casos, la evaluación sigue siendo principalmente una prueba de respuestas a tareas definidas de antemano. Tener muchas tareas no equivale a observar un agente trabajando en un entorno abierto. La amplitud mejora la cobertura dentro de la colección; no garantiza que esta represente todos los usos posibles ni que mida ejecución prolongada.

Cambiar la unidad: resolver una incidencia en un repositorio

SWE-bench desplaza la unidad de evaluación hacia una tarea de ingeniería de software: resolver incidencias de repositorios reales de GitHub. En vez de juzgar únicamente una respuesta textual a una pregunta, el sistema debe trabajar con el contexto de un proyecto y producir cambios en el código que respondan al problema planteado.

La evaluación puede comprobar el parche mediante pruebas del proyecto, incluidas pruebas relacionadas con el fallo descrito y pruebas que deberían seguir pasando. Así se obtiene evidencia sobre algo más concreto que una explicación convincente: si el cambio propuesto funciona según las comprobaciones disponibles en el entorno del benchmark. El evaluador puede determinar si el resultado supera esas pruebas; eso no equivale a certificar que el parche sea la única solución correcta, que esté bien diseñado en todos sus aspectos o que sea seguro para cualquier despliegue.

El sistema evaluado tampoco es necesariamente solo el modelo en aislamiento. Según la configuración, el resultado puede depender de cómo se le presenta el repositorio, de las herramientas disponibles para inspeccionar o editar archivos, de los intentos permitidos y del procedimiento para ejecutar las pruebas. Para comparar puntuaciones es importante saber qué componentes están incluidos y si el protocolo se mantuvo constante.

La evaluación sigue siendo una colección definida de incidencias y condiciones de ejecución. Por tanto, superar una incidencia acredita éxito según ese caso y sus verificaciones, no capacidad para resolver cualquier problema de software. Una prueba de repositorio acerca la tarea a una actividad profesional concreta, pero no abarca automáticamente requisitos de producto, colaboración, mantenimiento a largo plazo o consecuencias de un cambio en producción.

Incorporar interacción y estado: tareas en entornos informáticos

OSWorld evalúa agentes multimodales en tareas abiertas dentro de entornos informáticos reales simulados. En lugar de limitarse a producir una respuesta sobre una aplicación, un agente puede tener que observar la interfaz y actuar con controles como el teclado o el ratón para alcanzar un estado solicitado. La evaluación se orienta a tareas realizadas en el entorno, no solo a la calidad lingüística de una descripción.

Este cambio permite observar dimensiones que una prueba de respuestas no registra directamente: si las acciones se ejecutan, si una secuencia alcanza el resultado previsto y si el estado final satisface una condición de evaluación. También hace más visible la relación entre percepción, decisión y acción. Un sistema puede describir correctamente qué debería hacer y, sin embargo, no conseguir realizarlo; en un entorno interactivo, esa diferencia puede formar parte del resultado.

La ejecución aporta una señal más cercana a la tarea operativa, pero no elimina la necesidad de decidir qué cuenta como éxito. El entorno, las aplicaciones, el estado inicial, las instrucciones, las herramientas y el verificador forman parte de las condiciones de la prueba. Si la evaluación compara estados mediante reglas automatizadas, esas reglas pueden comprobar aspectos específicos del resultado; no necesariamente juzgan cada detalle de calidad, seguridad o conveniencia de la trayectoria seguida.

También hay que distinguir el agente del entorno. Una puntuación obtenida al permitir determinadas herramientas y controles no describe automáticamente lo que el modelo haría sin ellos, con una interfaz diferente o ante condiciones no contempladas. El resultado corresponde al sistema y al protocolo evaluados, no a una capacidad aislada de todos esos componentes.

Qué cambia con un entorno ejecutable y qué permanece

El paso de respuestas puntuadas a tareas ejecutables amplía la evidencia observable. Puede mostrar si el sistema produce un cambio en un repositorio o en una aplicación, no solo si redacta una solución plausible. Esa es una diferencia relevante para afirmaciones sobre capacidad de acción. Sin embargo, no transforma automáticamente un benchmark en una medida completa de utilidad, autonomía o fiabilidad.

Conviene separar cuatro elementos. La tarea define qué se pide; el entorno determina dónde y bajo qué condiciones ocurre; el verificador establece qué resultados considera satisfactorios; y el sistema evaluado incluye los componentes que reciben la tarea y producen acciones. Un cambio en cualquiera de ellos puede cambiar la dificultad o el significado de la puntuación. Si se comparan resultados de protocolos distintos sin reconocer esos cambios, se puede atribuir al modelo lo que en parte corresponde a otras condiciones.

La validez del verificador merece especial atención. Una prueba automatizada puede ser reproducible y útil, pero solo evalúa lo que comprueba. Un conjunto de pruebas incompleto podría no detectar un defecto no cubierto; una comprobación del estado final podría no penalizar una trayectoria ineficiente si la eficiencia no forma parte del criterio. Estas son posibilidades generales que deben investigarse en cada benchmark, no defectos que deban atribuirse sin evidencia a una evaluación concreta.

La reproducibilidad también depende de detalles operativos: versiones de software, estado inicial, acceso a herramientas, presupuesto de tiempo o número de intentos. Una descripción de esos límites permite interpretar mejor el resultado. Cuando faltan detalles, la comparación puede ser menos informativa; en tal caso, es preferible señalar la incertidumbre en lugar de completar los huecos con suposiciones.

Cómo leer una puntuación histórica

Una puntuación histórica necesita contexto. El primer paso es identificar qué versión del benchmark y qué protocolo se usaron. Una misma etiqueta puede referirse a conjuntos de tareas, métricas o configuraciones distintas. Antes de comparar dos cifras, hay que confirmar que describen una prueba suficientemente comparable.

El segundo paso es identificar la unidad de evaluación. ¿Se puntuó una respuesta, una colección de respuestas, un parche sometido a pruebas o una tarea en una interfaz? Esa diferencia determina qué tipo de evidencia ofrece el resultado. Un porcentaje de aciertos en respuestas y una tasa de tareas completadas no son escalas equivalentes, aunque ambos se expresen como porcentajes.

Después conviene separar el resultado agregado de su desglose. En un conjunto multitarea, revisar el desempeño por tarea puede revelar fortalezas y debilidades que desaparecen en el promedio. En evaluaciones interactivas, interesa saber qué condiciones de ejecución se mantuvieron y qué estados consideró satisfactorios el verificador. Siempre que haya informes disponibles, los resultados desglosados ayudan a evitar que una cifra resumen se convierta en una afirmación más amplia de lo que permite.

Por último, una mejora entre evaluaciones no demuestra por sí sola cuánto ha avanzado una capacidad general. Si cambian a la vez el modelo, la colección de tareas, las herramientas o las reglas de puntuación, no se puede atribuir el cambio entero a una sola causa sin análisis adicional. La comparación es más sólida cuando las condiciones se mantienen o cuando las diferencias se describen con precisión.

Conclusión: elegir la evidencia según la afirmación

GLUE y BIG-bench muestran dos maneras de ampliar evaluaciones centradas en respuestas: reunir tareas relacionadas o abarcar una colección más diversa. SWE-bench y OSWorld ilustran enfoques que desplazan la prueba hacia resultados ejecutados en repositorios y entornos informáticos. No son peldaños intercambiables de una clasificación; responden a preguntas diferentes y dejan distintos tipos de evidencia.

Cuando la afirmación trata sobre respuestas a tareas lingüísticas, un conjunto de datos pertinente puede ser una prueba útil. Si se quiere saber cómo se distribuye el desempeño entre varias tareas, importa examinar una evaluación multitarea y sus resultados desglosados. Si la afirmación se refiere a modificar un proyecto o realizar acciones en una aplicación, una evaluación ejecutable puede aportar evidencia más directa sobre esos resultados operativos.

La regla final es sencilla: interpretar la puntuación al nivel de la prueba que la produjo. Una evaluación más cercana al uso puede mostrar más acerca de acciones y estados, pero no mide por sí sola todos los aspectos de un sistema útil, seguro o fiable. Para sostener esas conclusiones hacen falta protocolos transparentes y evidencia complementaria que corresponda a cada afirmación.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.