Los agentes de frontera completaron el 30 por ciento de un flujo de trabajo de investigación. Ese es el número.

Stanford tiene un nuevo benchmark llamado Terminal-Bench-Science 0.1, y el resultado principal es bastante menos emocionante de lo que suele ser el marketing en torno a los agentes. El benchmark puso 70 flujos de trabajo de investigación escritos por expertos frente a agentes de frontera. El mejor completó el 30 por ciento de ellos.

El treinta por ciento es el número que hay que retener. No se lee ni como un fracaso ni como un triunfo. Es una medición honesta de dónde se encuentra la tecnología, publicada por personas que escribieron las tareas a mano.

Qué evalúa realmente el benchmark

Las tareas son flujos de trabajo científicos, escritos por expertos en el dominio, y los agentes se ejecutan en una terminal. Esa elección importa. Una terminal es un entorno de trabajo donde una tarea es real: hay que instalar la dependencia, escribir el archivo, ejecutar el análisis y comprobar la salida. No hay crédito parcial por describir el enfoque correcto. El comando funciona o no funciona.

Los flujos de trabajo provienen de la práctica investigadora, que es un objetivo mucho más desordenado que una tarea de programación con una suite de pruebas ordenada. Un benchmark de programación suele tener una respuesta correcta definida, por lo que puede puntuarse automáticamente. El trabajo de investigación a menudo no la tiene, y por eso construir un benchmark como este requirió que expertos escribieran las tareas en lugar de extraerlas de un repositorio.

Por qué el 30 por ciento es el enfoque correcto

Los benchmarks tienden a interpretarse como aprobado o suspenso. Un modelo que obtiene 90 en un benchmark de programación se considera casi resuelto. Un modelo que completa el 30 por ciento de los flujos de trabajo de investigación puede, con el mismo espíritu, interpretarse como que falla la mayoría de las veces.

Esa lectura pasa por alto para qué sirve el número. Completar el treinta por ciento en tareas escritas a mano por expertos significa que los agentes pueden encargarse del tercio rutinario del trabajo de investigación: configurar entornos, ejecutar pipelines establecidos, limpiar datos, producir salidas estándar. El otro 70 por ciento es donde la tarea requiere un criterio que el flujo de trabajo no especificaba, o donde un paso se rompe de una manera que necesita que un humano decida qué hacer a continuación.

Esa es una división útil. Le dice a un laboratorio dónde apuntar un agente hoy, y le dice a quien construye herramientas dónde está la brecha.

La terminal es la parte interesante

Ejecutar agentes en una terminal es una elección deliberada para probarlos donde ocurre el trabajo. El software de investigación es en gran medida software de línea de comandos. Un modelo que solo puede manejar una ventana de chat no ayuda a un laboratorio. Un modelo que puede sentarse en un shell, leer la documentación, instalar una cadena de herramientas y recuperarse cuando falla una compilación es una categoría distinta de utilidad.

También es donde los modos de fallo son más visibles. Una terminal no oculta un error. Cuando un comando devuelve un mensaje ambiguo o un script se completa a medias, el agente tiene que decidir si reintentar, cambiar de enfoque o detenerse. Ese punto de decisión es donde se pierde la mayor parte del 70 por ciento, y es exactamente el tipo de cosa que un benchmark de programación con una suite de pruebas limpia nunca sacará a la superficie.

En qué se diferencia de los benchmarks de programación

La comparación obvia es con los benchmarks de programación, que se han convertido en la forma estándar de publicitar el progreso de los agentes. Un benchmark de programación suele incluir un repositorio y una suite de pruebas, por lo que la respuesta correcta está definida y la puntuación es automática. Eso lo hace barato de ejecutar y fácil de comparar, y es por eso que esos números dominan la conversación.

Los flujos de trabajo de investigación se resisten a ese tratamiento. A menudo no hay una única salida correcta, y la calidad de un resultado depende del criterio sobre qué medir y cómo. Por eso las tareas aquí fueron escritas por expertos en lugar de extraerse de un repositorio, y por eso el benchmark informa la finalización en lugar de una tasa de aprobación en pruebas.

La contrapartida es cobertura por realismo. Un benchmark de programación puede ejecutarse miles de veces al día y producir un número ajustado. Un benchmark de flujos de trabajo es más lento y ruidoso, pero evalúa el entorno donde ocurre en realidad una gran parte del trabajo técnico. Ambos son útiles, y solo uno de ellos estaba ampliamente disponible antes.

Por qué el número se mide de esta manera

La finalización es una métrica contundente, y los autores la eligieron a propósito. Un flujo de trabajo termina o no termina, y ese es un hecho que un observador externo puede verificar sin juzgar la calidad del resultado. La elegancia no se puntúa. No se discute sobre la corrección. El agente o produjo la salida que el flujo de trabajo requería o se detuvo en algún punto antes de terminar.

Esa contundencia es el punto. Los benchmarks que intentan puntuar la calidad en tareas de investigación abiertas tienden a reducirse al gusto del autor del benchmark. Al puntuar la finalización, este cambia matices por reproducibilidad. Dos laboratorios que ejecutan el mismo flujo de trabajo obtienen la misma respuesta, y eso es lo que hace que un número valga la pena citar.

El coste es que no puede distinguir un agente que casi terminó de uno que falló de inmediato. Ambos cuentan como fallos. Es una limitación, y una versión futura podría abordarla, pero un número burdo en el que todos están de acuerdo supera a uno fino en el que nadie confía.

Qué dice el resultado sobre el trabajo científico

El benchmark es una respuesta silenciosa a una afirmación ruidosa: que los agentes pronto harán investigación. Lo que muestra es que los agentes pueden ejecutar investigación, es decir, pueden llevar a cabo un procedimiento que un humano ya ha elaborado, en una proporción creciente de pasos rutinarios. Todavía no pueden hacer la parte en la que el procedimiento es desconocido y alguien tiene que inventarlo.

Esa brecha no es un pequeño detalle de ingeniería. El trabajo rutinario ocupa una gran parte del tiempo de un científico, y automatizarlo ahorra dinero y horas reales. Tampoco es la parte que produce descubrimientos. La distinción importa para cualquiera que pronostique lo que la IA hará con la ciencia en los próximos años.

Cómo leer benchmarks como este

Dos advertencias se aplican a cualquier benchmark nuevo. La primera es el número de versión. Este es 0.1, lo que significa que el conjunto de tareas cambiará a medida que los autores aprendan qué tareas están bien planteadas y cuáles son ambiguas. Las puntuaciones de versiones diferentes no son directamente comparables.

La segunda es que un benchmark mide los flujos de trabajo que eligieron sus autores. Setenta tareas extraídas de dominios científicos son una muestra, no un censo. La cifra del 30 por ciento es una buena señal de la forma general de la capacidad de los agentes en el trabajo de investigación. No es un número preciso que sobreviva a la próxima revisión.

Qué hay que observar

El progreso que hay que observar no es que suba el porcentaje principal. Es qué tareas empiezan a aprobarse. Si los agentes comienzan a superar flujos de trabajo que requieren recuperación de varios pasos, eso es un avance real. Si la ganancia proviene solo de tareas más fáciles de configuración y limpieza de datos, el techo es más bajo de lo que sugiere el titular.

Un benchmark que informa honestamente un número bajo es más útil que uno que informa un número alto que la gente no puede reproducir. Este está haciendo lo primero, y el campo necesita más de eso.