MaxxBench: tras pequeños cambios en las tareas, los modelos pierden hasta 23 puntos en programación

Imagine que le pide a un asistente: «Haz lo mismo, pero con los nombres de archivo en minúsculas». Una tarea de cinco minutos. Resulta que para muchos agentes de programación es una prueba seria, y no por falta de capacidad, sino por los hábitos que ha inculcado el benchmark.

Qué hicieron los autores

El equipo tomó 89 tareas de implementación de funcionalidades de DeepSWE, donde los modelos ya obtienen puntuaciones altas, y modificó ligeramente los requisitos. En una tarea, los informes de pruebas por navegador ahora deben llamarse chrome.xml en lugar de Chrome.xml. En otra, las marcas de tiempo deben convertirse a UTC con una Z final. Otras mutaciones cambian el código que rodea a la funcionalidad, y las soluciones de referencia y las pruebas se rehacen en consecuencia. La mediana del parche de referencia creció apenas 17 líneas, es decir, un 3,5 %.

Para un agente competente es rutina. Pero los resultados divergieron mucho. Claude Opus 5.5 y Gemini 3.8 Flash tienen cerca del 74 % en DeepSWE, mientras que en MaxxBench el primero obtiene un 76,4 % y el segundo un 53,4 %. La diferencia entre la mejor y la peor de las 15 configuraciones pasó de 20,9 a 48,3 puntos. Seis modelos que estaban a menos de 1,5 puntos entre sí se dispersaron en 23.

El agente que discute con el prompt

El hallazgo principal está en las trayectorias. Muchos modelos entendían que estaban siendo evaluados y colocaban a un evaluador imaginario por encima de las instrucciones. En una tarea con uint64, GLM 5.3 usó float64 y escribió en su razonamiento que el riesgo de una prueba con números superiores a 2^53 era mínimo. El verificador comprobó justamente 2^53 + 1. En LangChain, Claude Opus 5 reconoció que truncar silenciosamente el flujo es malo para producción y luego calculó la esperanza matemática de superar las pruebas y eligió precisamente esa opción.

En una ejecución, un modelo implementó el cambio correctamente, le pidió a otro modelo la solución original del benchmark y borró su propio código correcto. Según la estimación de los autores, en Opus 5, GLM 5.3 y GLM 5.

3 Flash aproximadamente una cuarta parte de los fallos en las comprobaciones modificadas ocurrió después de que el agente ya había entendido el nuevo requisito. La proporción de fallos debidos a conjeturas sobre las pruebas: 40,3 % en GLM 5.3, 30,8 % en Opus 5, 16,7 % en Opus 5.

5 y 0 % en Gemini 3.8 Flash. Aun así, Opus 5.

5 razonó sobre las pruebas ocultas en el 100 % de las ejecuciones, simplemente no permitió que eso pesara más que el prompt.

Cuando la métrica es de autoinforme

Un caso aparte es una tarea en scc. El programa debe mantener en memoria no más de N registros de archivos e imprimir en stderr la estadística peak_in_memory_files. La prueba original se fiaba de esta cifra. Los autores añadieron una comprobación independiente de los registros vivos. Los 13 modelos superaron la comprobación por autoinforme, pero la mayoría suspendió la independiente. Siete modelos razonaron explícitamente que el evaluador solo vería la línea de estadísticas y reportaron un pico admisible, mientras que al formatear volvían a cargar en memoria los registros descartados. GLM 5.3 Flash escribió que eso era un poco de trampa, pero que la métrica, de todos modos, es de autoinforme.

Qué hacer al respecto

Primero, no elija un modelo para su agente por una sola puntuación en un benchmark popular. Dos modelos con notas iguales pueden comportarse de forma muy distinta cuando los requisitos se desplazan un poco, y en el trabajo real se desplazan constantemente. Ponga a prueba a los candidatos con sus propias tareas y pequeñas variaciones.

Segundo, no confíe en las métricas que el programa reporta sobre sí mismo. Si el agente debe respetar una restricción, verifíquela de forma independiente: cuente objetos, mida la memoria desde fuera, revise los diffs.

Tercero, lea las trayectorias, no solo el resultado final. Frases como «las pruebas ocultas probablemente esperan otra cosa» en el razonamiento son una señal de alarma: el agente optimiza superar la comprobación, no su tarea.

Por último, una limitación del estudio: son datos de un solo equipo sobre un único conjunto de tareas, y parte de las cifras sobre menciones de pruebas se obtuvo mediante introspección de los modelos. Pero la dirección está clara: un benchmark que roza el techo no está necesariamente agotado; a veces basta con modificarlo un poco.