MLE-World predice el resultado de un experimento de ML sin ejecutarlo: 77,9% de acierto

Los agentes que escriben y mejoran por sí mismos código para tareas de machine learning chocan con un obstáculo caro: cada candidato hay que entrenarlo y evaluarlo de verdad. El equipo de MLE-World propone sustituir parte de esas ejecuciones por una predicción. Su world model toma el código del programa y la descripción de los datos, y devuelve lo que habría impreso la terminal: el trace del error, los logs de entrenamiento y el score de validación. En programas reservados para evaluación (held-out), coincidió con la salida real en el 77,9% de los casos. Los modelos grandes a los que se planteó la misma tarea mediante un prompt alcanzaron un 41,1%.

Una llamada en lugar de una ejecución de entrenamiento

El cuello de botella de los agentes de ML está en el ciclo de retroalimentación. En cada paso, el agente solo puede probar unas pocas variantes, porque cada una se valida entrenando un modelo, lo que cuesta minutos u horas de GPU. Como resultado, el agente o bien maneja pocos candidatos, o bien gasta el presupuesto en cómputo que, la mayoría de las veces, termina en un «no despegó».

MLE-World cambia la aritmética. La predicción cuesta una sola llamada de inference, no un entrenamiento. Por eso el test-time scaling, es decir, generar varias variantes en cada paso y elegir la mejor, pasa a ser viable precisamente para los agentes de investigación. Hasta ahora, esta técnica se topaba con el coste de verificar cada candidato.

El modelo no predice una «puntuación de calidad» abstracta, sino la salida de texto del programa. Eso incluye las ejecuciones fallidas: un error de importación, una discrepancia de dimensiones, falta de memoria. Al agente le resulta útil saber de antemano que un candidato va a fallar, para no gastar en él una ejecución real.

Se puede evaluar cuánto confiar en la predicción

Toda world model tiene un punto débil: puede equivocarse con total seguridad. Por eso el sistema incorpora un segundo componente que estima hasta qué punto es probable que la predicción sea correcta. No está ahí como adorno. La ejecución real de un candidato se hace de forma selectiva, según esta estimación de fiabilidad: cuando la confianza en la predicción es baja, el agente paga por la ejecución auténtica.

Sobre esta combinación, los autores construyeron cinco políticas de test-time scaling. Todas comparan en cada paso varios candidatos según las salidas predichas, no las reales. Una de ellas añade a la selección una bonificación por exploración, que también se apoya en la estimación de fiabilidad. Sirve de protección contra el caso en que el agente se atasca en variantes de las que el modelo simplemente está seguro.

Las cifras y lo que hay detrás

• Coincidencia de la predicción con la salida real de la terminal en programas held-out: 77,9%.
• Línea base, modelos mucho más grandes con prompt: 41,1%.
• Mejora del resultado medio observado del agente con MLE-World frente al agente sin world model: hasta 22,1%.
• El volumen de ejecución real, además, es menor que el del agente sin el modelo.
• Número de políticas de test-time scaling en el trabajo: cinco.
• Preprint: arXiv 2610.37175, página del proyecto mle-world.github.io.

El detalle clave está en la comparación con los modelos grandes. Un predictor especializado, entrenado con pares «código y datos → salida», es casi el doble de preciso que los LLM generalistas, que no han visto suficientes ejecuciones reales. El conocimiento sobre cómo se comportan los pipelines se asimila mejor a partir de logs de ejecución que del preentrenamiento general.

La cifra «hasta 22,1%» describe el mejor caso, no una garantía para cualquier tarea. Aun así, la dirección encaja bien con la economía: un inference barato sustituye a costosas horas de GPU.

Si construyes agentes para AutoML o programación, el enfoque tiene una aplicación directa. Conviene reunir pares «código, descripción de los datos y salida de la ejecución» a partir de tus propios logs, porque ese es el dataset con el que se entrena una world model. En el ciclo del agente conviene separar el filtrado barato mediante predicciones de la verificación cara con ejecución real, y fijar el umbral de confianza con el evaluador de fiabilidad. Así, el presupuesto de GPU se destina a los candidatos con predicción ambigua o con una elección realmente importante, y las variantes claramente rotas se descartan antes de ejecutarse.