Aplicar Autoresearch a una idea de investigación antigua

• El sistema Autoresearch tiene una estructura de bucle de optimización con restricciones en la que un agente LLM modifica repetidamente train.py para mejorar el rendimiento, realizando un ciclo automático desde la formulación de hipótesis hasta la evaluación
• Los experimentos se ejecutan en un entorno sandbox basado en contenedores, lo que bloquea el acceso a la red y la ejecución de código arbitrario
• Usando el dataset Ukiyo-eVG, se aprovecharon para el entrenamiento unas 11,000 imágenes de grabados japoneses en madera junto con información de anotaciones, y se logró un rendimiento de Mean Rank 34.30 y R@5 de aproximadamente 53% con un modelo basado en CLIP
• Las mejoras principales provinieron de relajar el parámetro temperature (-113 Mean Rank) y del ajuste de hiperparámetros (-30 Mean Rank), registrando una mejora de rendimiento del 54% mediante 13 commits en 42 experimentos en un día
• El agente LLM resulta efectivo en espacios de exploración claramente definidos, pero después de la etapa de cambios estructurales la inestabilidad aumenta, mostrando límites para una investigación completamente autónoma

---

Idea principal

• Autoresearch es una estructura de bucle de optimización con restricciones centrada en un agente LLM, donde el agente modifica train.py para mejorar repetidamente las métricas de evaluación
  • El agente lee las instrucciones de program.md y usa scratchpad.md como memoria de trabajo para registrar el proceso experimental
• La exploración se compone de varias fases, comenzando con ajuste de hiperparámetros, luego pequeños cambios estructurales y, más adelante, expandiéndose a una exploración libre con restricciones mínimas
• Todo el bucle está diseñado como un ciclo de formular hipótesis → modificar código → entrenar → evaluar → hacer commit o revertir → repetir
• Cada experimento está limitado a completarse en unos 5 minutos para fomentar iteraciones rápidas y evitar el sobreajuste
• El agente puede modificar libremente train.py dentro del límite de tiempo

• Sandboxing

  • Para evitar el riesgo de ejecución de código arbitrario, el bucle de entrenamiento se ejecuta en un entorno de contenedores y se bloquea el acceso a la red
  • run.sh administra todo el flujo experimental, y Claude Code solo puede modificar train.py y program.md
  • La ejecución directa de Python, la instalación con pip, el acceso a la red y git push, entre otros, están todos restringidos
  • La implementación relacionada está publicada en un repositorio de GitHub

Dataset

• Como no fue posible acceder al dataset médico de rayos X usado en la investigación original, se utilizó en su lugar el dataset Ukiyo-eVG
  • Incluye unas 11,000 imágenes de grabados japoneses en madera y anotaciones de texto y bounding boxes
  • Las bounding boxes se convierten en mapas de calor gaussianos y se agregan a la entrada del modelo, aplicando un método similar al mecanismo de atención experta del artículo original de eCLIP
• Los mapas de calor ayudan al modelo a enfocarse en regiones específicas

Configuración experimental con Claude Code

• Claude Code actualizó el código de la investigación existente a un entorno moderno de Python y escribió la carga del nuevo dataset y el scaffolding del bucle experimental
• También configuró las particiones de validación cruzada, la lógica de evaluación y las ideas iniciales en program.md
• Se utilizó Mean Rank como métrica de evaluación, y en el informe final también se incluyó Recall@K
  • Mean Rank se usó para una evaluación intuitiva, aunque se menciona que Median Rank habría sido más apropiado al ser menos sensible a valores atípicos
• Configuración del modelo: el backbone de CLIP consiste en ViT-Small (22M) + DistilBERT (66M) + HeatmapProcessor, para un total de aproximadamente 90M parámetros
  • Entrenamiento: 800 pasos (aprox. 3 minutos por experimento, en una RTX 4090)
  • Evaluación: medición de Mean Rank y Recall@K en un conjunto de prueba de 1,000 imágenes
  • Rendimiento base: Val Mean Rank 344.68, img→txt R@1 17.2%, txt→img R@1 16.5%

Resultados experimentales

• En un día se realizaron 42 experimentos en total, de los cuales 13 terminaron en commit y 29 en reversión
  • Mean Rank bajó de 344.68 a 157.43, una reducción del 54%
• Al entrenar finalmente con todo el dataset, la puntuación de prueba resultó más alta que la de validación
  • Esto sugiere que los experimentos cortos de 800 pasos estaban en una situación de underfitting
• Rendimiento final en prueba: Mean Rank 34.30, img→txt R@5 53.0%, txt→img R@5 51.4%

Puntos clave de mejora

• Corrección del temperature clamp (-113 Mean Rank)

  • El parámetro temperature entrenable en el código estaba fijado en 2, y el agente lo relajó, mejorando sustancialmente el rendimiento
  • Fue el mayor efecto individual de toda la mejora

• Optuna++ (-30 Mean Rank)

  • Las mejoras posteriores provinieron principalmente del ajuste de hiperparámetros
  • Aumentar la dimensión de proyección y reajustar la tasa de aprendizaje aportó una mejora adicional de 30 puntos
  • El agente realizó más rápido y de forma más sistemática tareas repetitivas y tediosas que normalmente haría una persona

• Zona de rendimientos decrecientes

  • A partir de la fase 4 (cambios estructurales), la tasa de éxito de las hipótesis del LLM cayó con fuerza
  • La mayoría de los intentos de cambiar el mecanismo de atención o probar ideas audaces (moonshot) fracasaron
  • En la parte final de la exploración hubo muchos intentos aleatorios

• La importancia del sandbox

  • Claude Code a veces olvidaba sus permisos e intentaba llamadas bash incorrectas, o interrumpía el bucle mientras esperaba el entrenamiento, mostrando comportamientos inestables
  • Todavía hay límites para una ejecución completamente autónoma

Observaciones finales

• Durante todo el proceso, el 90% inicial avanzó sin problemas, mientras que el 10% final requirió mucha intervención
• Los agentes LLM pueden realizar investigación de ML de manera efectiva dentro de un espacio de exploración claramente definido
• El bucle de commit y reversión de Autoresearch resulta útil como estrategia de exploración estructurada
• Sin embargo, al expandirse hacia territorios desconocidos, el bucle de optimización se vuelve inestable
• Es posible que la restricción de permitir solo un cambio por experimento haya sido demasiado estricta para la exploración de ideas a gran escala
  • Como posibles mejoras futuras, se plantean agregar una etapa de planificación o introducir subagentes (subagents)
• Tras finalizar los experimentos, la colaboración con Claude Code concluyó con el regreso a la rutina diaria

Agradecimientos

• Dataset Ukiyo-eVG: incluye unas 11K imágenes de grabados japoneses en madera y anotaciones de texto y bounding boxes
• Autoresearch: basado en la idea original de Andrej Karpathy

[GN⁺]

Comentarios en Hacker News

• Si el enlace principal va lento, sugieren probar la versión de archive.is

• A menudo uso LLM para explorar investigaciones existentes o pensar problemas de otra manera El 90% de los resultados no aplica a mi dominio, pero el 10% restante sí me ha servido bastante Pero tener un agente que realmente pruebe todo lo que recomienda sale demasiado caro ($$$) En la lista de recomendaciones suelen aparecer muchas librerías de nicho sin mantenimiento Por otro lado, los “consultores expertos” de la empresa también suelen hacer propuestas igual de absurdas, así que casi preferiría que un agente tratara con ellos en mi lugar

  • El valor del agente está en que puede repetir experimentos automáticamente mientras el usuario descansa Pero solo tiene sentido cuando una prueba individual es rápida. En mi trabajo, una sola prueba toma medio día, así que es difícil dejarlo corriendo toda la noche
  • Tengo curiosidad por saber en qué dominio trabajas
  • Siento que los LLM son útiles para frases cortas que da flojera recordar o en partes donde no importa si se equivocan Cuando veo gente configurando cosas como servidores MCP o AGENTS.md, me parece una prueba de que al final los LLM no funcionan como se anuncian Si se afinan bien para un flujo de trabajo específico, pueden ser excelentes, pero dudo que eso pueda escalar Si no hay un financiamiento enorme sosteniendo el entrenamiento y la infraestructura, ¿podrá convertirse en un modelo de negocio sostenible?
  • El costo podría ser el problema. Yo uso Claude Code de forma ligera, y hasta en el plan Max casi no se me acaban los tokens

• Me llamó la atención la expresión “el agente actuó como un algoritmo de optimización de hiperparámetros” La clave es un solo archivo de prompt de sistema llamado program.md, con una estructura que repite “mejorar train.py → ejecutar entrenamiento → evaluar → registrar resultados” Lo demás no es más que un modelo de ML cualquiera

• Darle al LLM código en funcionamiento y hacer que repita corrección de bugs, medición de rendimiento y evaluación de cobertura de pruebas es el enfoque estándar de nuestro equipo Me gustó la idea de usar un modelo distinto en cada iteración, porque da la sensación de obtener nuevas perspectivas

  • Me pregunto si este método podría aplicarse al entrenamiento de LLM locales especializados en un lenguaje o framework concreto

• Me preguntaba por qué “Autoresearch” se volvió tan comentado Siempre pensé que los cuellos de botella en AI/ML eran la calidad de los datos o los recursos de cómputo, y no sé si esto mejora eso

  • En realidad, este tipo de intentos existe desde hace tiempo. El campo de AutoML es un ejemplo, pero en la práctica no funcionó muy bien También hubo enfoques como optimización bayesiana o Gaussian Process, pero al final la búsqueda aleatoria funcionaba mejor La diferencia es que los LLM pueden leer literatura y hacer razonamientos de sentido común No son perfectos, pero podrían ser mejores que los métodos anteriores
  • La diferencia es que, más allá del ajuste simple de hiperparámetros, también permite cambios estructurales no paramétricos No es una idea completamente nueva, pero parece que esperan que sea menos brute-force
  • También existen técnicas previas como “Swarm optimization”, pero la diferencia es que los LLM pueden aprender de investigaciones pasadas y concentrarse en los ejes importantes Es decir, el LLM puede aprovechar investigaciones que alguien ya hizo
  • No estoy de acuerdo con eso de que “los datos o el cómputo son el cuello de botella” El núcleo del ML es encontrar un mapeo de funciones mejor para la misma entrada X No se resuelve solo aumentando el cómputo
  • En última instancia, Autoresearch consiste en delegar el pensamiento mismo al LLM

• En la práctica sí funcionó. El LLM encontró bugs y también optimizó

  • Pero en realidad la mayoría de las mejoras vinieron de corrección de bugs + ajuste con Optuna Eso se puede hacer rápido incluso con Claude Code El verdadero valor de Autoresearch probablemente esté en la exploración de arquitecturas Me pregunto si alguien ya lo ha usado para modelado exploratorio

• Al ver el registro de commits (enlace de GitHub), la mayoría eran ajustes de hiperparámetros Para eso, siento que el costo en tokens ($$$) no vale la pena

  • Sería eficiente añadir a Autoresearch una etapa de estimación y ordenamiento de costos para que una persona revise antes de ejecutar Podría mejorarse dando retroalimentación de costo con adaptadores LoRa
  • En realidad, esto también se puede hacer con herramientas open source como Optuna o skopt, incluso sin GPU

• En el paper original usaron datos médicos de rayos X, pero como no tenían acceso, dicen que los reemplazaron por Ukiyo-eVG (11 mil grabados japoneses en madera) Me pareció un cambio raro. También hay muchos datos gratuitos de imágenes médicas en Cancer Imaging Archive

  • Es cierto. Pero me incomodaba dejar datos médicos en manos de un agente, y también quería experimentar con transferencia de dominio

• Esperaba que alguien hiciera un experimento así, y me alegró que de verdad lo hicieran Me dio risa la parte de “me cansé de esperar a que terminara el entrenamiento y cerré la conversación” Gracias por compartir los resultados

  • Gracias, respondió que lo leyó con gusto

• Esto se parece menos a investigación automatizada y más a prueba y error estructurada Al final, lo importante es la calidad de la métrica de evaluación. Si eso es débil, solo optimizas más rápido en la dirección equivocada

  • Diseñar una buena función de fitness sigue siendo difícil, antes y ahora
  • También hay quien opina que al final eso es precisamente el método científico