Executando Autoresearch em uma ideia de pesquisa antiga

• O sistema Autoresearch tem a estrutura de um loop de otimização com restrições em que um agente LLM modifica repetidamente o train.py para melhorar o desempenho, realizando um ciclo automático desde a formulação de hipóteses até a avaliação
• Os experimentos são executados em um ambiente sandbox baseado em contêineres, bloqueando acesso à rede e execução arbitrária de código
• Usando o dataset Ukiyo-eVG, o treinamento aproveitou cerca de 11 mil imagens de xilogravuras japonesas e suas anotações, alcançando Mean Rank 34.30 e R@5 de cerca de 53% com um modelo baseado em CLIP
• As principais melhorias vieram do afrouxamento do parâmetro temperature (-113 de Mean Rank) e do ajuste de hiperparâmetros (-30 de Mean Rank), registrando uma melhora de 54% no desempenho com 13 commits em 42 experimentos ao longo de um dia
• O agente LLM é eficaz em espaços de busca claramente definidos, mas, após a etapa de mudanças estruturais, a instabilidade aumenta, revelando limites para uma pesquisa totalmente autônoma

---

Ideia central

• Autoresearch é uma estrutura de loop de otimização com restrições centrada em um agente LLM, em que o agente modifica o train.py para melhorar repetidamente as métricas de avaliação
  • O agente lê as instruções em program.md e usa scratchpad.md como bloco de notas de trabalho para registrar o processo experimental
• A busca é composta por várias fases, começando com ajuste de hiperparâmetros, passando por pequenas mudanças estruturais e depois se expandindo para uma exploração livre com o mínimo de restrições
• O loop completo foi projetado como um ciclo de formulação de hipótese → modificação de código → treinamento → avaliação → commit ou rollback → repetição
• Cada experimento é limitado a cerca de 5 minutos para incentivar iteração rápida e evitar overfitting
• O agente pode modificar livremente o train.py dentro do limite de tempo

• Sandbox

  • Para evitar o risco de execução arbitrária de código, o loop de treinamento roda em um ambiente de contêiner com acesso à rede bloqueado
  • O run.sh gerencia todo o fluxo experimental, e o Claude Code só pode modificar train.py e program.md
  • Execução direta de Python, instalação via pip, acesso à rede, git push etc. são todos restringidos
  • A implementação relacionada está disponível publicamente no repositório GitHub

Dataset

• Como não foi possível acessar o dataset médico de raios X usado na pesquisa original, foi adotado um novo dataset: o Ukiyo-eVG
  • Inclui cerca de 11 mil imagens de xilogravuras japonesas e anotações de frases com bounding boxes
  • As bounding boxes foram convertidas em mapas de calor gaussianos e adicionadas à entrada do modelo, aplicando uma abordagem semelhante ao mecanismo de atenção especializada do artigo original do eCLIP
• Os mapas de calor ajudam o modelo a se concentrar em regiões específicas

Configuração experimental com Claude Code

• O Claude Code atualizou o código da pesquisa existente para um ambiente Python moderno e escreveu o carregamento do novo dataset e o scaffolding do loop experimental
• Também configurou divisões de validação cruzada, a lógica de avaliação e as ideias iniciais em program.md
• A métrica de avaliação usada foi Mean Rank, e o relatório final também incluiu Recall@K
  • O texto observa que Mean Rank foi usado por ser intuitivo, mas que Median Rank provavelmente teria sido mais apropriado por ser menos sensível a outliers
• Configuração do modelo: backbone CLIP com ViT-Small (22M) + DistilBERT (66M) + HeatmapProcessor, totalizando cerca de 90M de parâmetros
  • Treinamento: 800 steps (cerca de 3 minutos por experimento, em uma RTX 4090)
  • Avaliação: medição de Mean Rank e Recall@K em um conjunto de teste de 1.000 imagens
  • Desempenho de referência: Val Mean Rank 344.68, img→txt R@1 17.2%, txt→img R@1 16.5%

Resultados experimentais

• Ao longo de um dia, foram realizados 42 experimentos no total, com 13 commits e 29 rollbacks
  • O Mean Rank caiu de 344.68 para 157.43, uma redução de 54%
• No treinamento final com o dataset completo, a pontuação de teste foi maior que a de validação
  • Isso sugere que os experimentos curtos de 800 steps estavam em estado de underfitting
• Desempenho final no teste: Mean Rank 34.30, img→txt R@5 53.0%, txt→img R@5 51.4%

Principais pontos de melhoria

• Correção do temperature clamp (-113 de Mean Rank)

  • O parâmetro temperature treinável no código estava fixado em 2, e o agente o afrouxou, melhorando bastante o desempenho
  • Foi o maior efeito individual de toda a melhoria

• Optuna++ (-30 de Mean Rank)

  • As melhorias seguintes vieram principalmente de ajuste de hiperparâmetros
  • O aumento da dimensão de projeção e o reajuste da taxa de aprendizado trouxeram uma melhoria adicional de 30 pontos
  • O agente executou de forma mais rápida e sistemática um trabalho tedioso que humanos costumam repetir

• Região de retornos decrescentes

  • A partir da fase 4 (mudanças estruturais), a taxa de sucesso das hipóteses do LLM caiu drasticamente
  • Mudanças no mecanismo de atenção ou tentativas de ideias ousadas (moonshot) falharam na maioria dos casos
  • Na parte final da busca, houve muitas tentativas aleatórias

• A importância do sandbox

  • O Claude Code às vezes esquecia as permissões e tentava chamadas bash incorretas, ou interrompia o loop enquanto aguardava o treinamento, mostrando comportamento instável
  • Ainda há limites para uma execução totalmente autônoma

Observações finais

• Ao longo de todo o processo, os 90% iniciais correram bem, mas os 10% finais exigiram muita intervenção
• O agente LLM consegue conduzir pesquisa em ML de forma eficaz dentro de um espaço de busca claramente definido
• O loop de commit e rollback do Autoresearch é útil como estratégia de exploração estruturada
• No entanto, ao se expandir para território desconhecido, o loop de otimização se torna instável
• É possível que a restrição de permitir apenas uma mudança por experimento tenha sido rígida demais para a exploração de ideias em larga escala
  • No futuro, adicionar uma etapa de planejamento ou introduzir subagentes (subagents) é apresentado como possível caminho de melhoria
• Após o fim dos experimentos, a colaboração com Claude Code terminou com um retorno à rotina cotidiana

Agradecimentos

• Dataset Ukiyo-eVG: inclui cerca de 11 mil imagens de xilogravuras japonesas e anotações de frases com bounding boxes
• Autoresearch: baseado na ideia original de Andrej Karpathy

[GN⁺]

Comentários do Hacker News

• Se o link principal estiver lento, sugerem tentar a versão archive.is

• Eu frequentemente uso LLMs para explorar pesquisas existentes ou pensar em problemas de outra forma
  90% dos resultados não se encaixam no meu domínio, mas os 10% restantes foram bem úteis
  Mas ter um agente que realmente tente tudo o que o LLM recomenda custa caro demais ($$$)
  A lista de recomendações frequentemente inclui muitas bibliotecas de nicho sem manutenção
  Por outro lado, os “consultores especialistas” da empresa também costumam fazer sugestões absurdas parecidas, então eu preferiria que o agente lidasse com eles no meu lugar

  • O valor do agente está em repetir experimentos automaticamente enquanto o usuário descansa
    Mas isso só faz sentido quando cada teste é rápido. No meu trabalho, um teste leva meio dia, então é difícil deixar rodando durante a noite
  • Fiquei curioso sobre em que domínio você trabalha
  • Acho LLM útil para frases curtas que dá preguiça de lembrar ou para partes em que errar não faz diferença
    Quando vejo gente configurando coisas como servidores MCP ou AGENTS.md, isso me parece prova de que o LLM não funciona como anunciado
    Se for bem ajustado para um fluxo de trabalho específico, pode ser excelente, mas tenho dúvidas se isso consegue escalar
    Será que isso pode virar um modelo de negócios sustentável sem uma montanha de dinheiro bancando treinamento e infraestrutura?
  • O custo pode ser o problema. Eu uso Claude Code de forma leve, e mesmo no plano Max quase não esgoto os tokens

• A frase “o agente se comportou como um algoritmo de otimização de hiperparâmetros” chamou atenção
  O ponto central é um único arquivo de prompt de sistema chamado program.md, numa estrutura que repete “melhorar train.py → executar treino → avaliar → registrar resultados”
  O resto é apenas um modelo de ML qualquer

• Dar código em funcionamento para um LLM e repetir correção de bugs, medição de desempenho e avaliação de cobertura de testes é a abordagem padrão da nossa equipe
  Gostei da sensação de obter novas perspectivas ao usar um modelo diferente a cada iteração

  • Fiquei curioso se isso poderia ser aplicado ao treinamento de LLMs locais especializados em uma linguagem ou framework específicos

• Fiquei me perguntando por que “Autoresearch” virou tanto assunto
  Sempre achei que o gargalo em AI/ML fosse qualidade de dados ou recursos computacionais, então não sei se isso melhora esse ponto

  • Na verdade, esse tipo de tentativa existe há bastante tempo. A área de AutoML é um exemplo, mas na prática não deu muito certo
    Houve abordagens como otimização bayesiana ou Gaussian Process, mas no fim a busca aleatória funcionava melhor
    A diferença é que um LLM consegue olhar a literatura e fazer raciocínio de senso comum
    Não é perfeito, mas pode acabar sendo melhor do que os métodos anteriores
  • A diferença é que isso pode ir além de ajuste simples de hiperparâmetros e fazer mudanças estruturais não paramétricas
    Não é uma ideia totalmente nova, mas parece haver esperança de que seja menos brute-force
  • Existem técnicas anteriores como “Swarm optimization”, mas a diferença é que o LLM pode aprender pesquisas passadas e focar nos eixos importantes
    Ou seja, o LLM pode aproveitar pesquisas que alguém já fez
  • Não concordo com a ideia de que “dados ou computação são o gargalo”
    O cerne de ML é encontrar um mapeamento de função melhor para a mesma entrada X
    Isso não se resolve simplesmente aumentando computação
  • No fim, Autoresearch é uma forma de delegar o próprio pensamento ao LLM

• No fim das contas, funcionou. O LLM encontrou bugs e também fez otimizações

  • Mas, na prática, a maior parte das melhorias veio de correção de bugs + ajuste com Optuna
    Isso dá para fazer rapidinho até com Claude Code
    O verdadeiro valor do Autoresearch parece estar na exploração de arquitetura
    Fiquei curioso se alguém já usou isso em modelagem exploratória

• Olhando o log de commits (link do GitHub), a maior parte era ajuste de hiperparâmetros
  Nesse nível, parece desperdício de custo em tokens ($$$)

  • Se adicionassem ao Autoresearch uma etapa de estimativa e ordenação de custos para um humano revisar antes de executar, talvez ficasse eficiente
    Daria para melhorar isso usando adaptadores LoRa para fornecer feedback de custo
  • Na verdade, isso também dá para fazer com ferramentas open source como Optuna ou skopt, mesmo sem GPU

• No artigo original, usaram dados médicos de raio X, mas como não havia acesso, trocaram por Ukiyo-eVG (11 mil xilogravuras japonesas)
  Pareceu uma troca estranha. Há muitos dados médicos de imagem gratuitos também no Cancer Imaging Archive

  • Faz sentido. Mas eu não me sentia confortável em entregar dados médicos para o agente, e também queria experimentar transferência de domínio

• Eu queria que alguém fizesse esse tipo de experimento, então foi bom ver alguém realmente fazendo
  A parte “fiquei tão cansado de esperar o treino terminar que encerrei a conversa” foi engraçada
  Obrigado por compartilhar os resultados

  • Obrigado, gostei de ler

• Isto parece mais tentativa e erro estruturada do que pesquisa automatizada
  No fim, o ponto central é a qualidade da métrica de avaliação. Se ela for fraca, você só otimiza mais rápido na direção errada

  • Projetar uma boa função de fitness continua sendo difícil, como sempre foi
  • Há também a opinião de que isso, no fim, é exatamente o método científico