Karpathy lança Autoresearch open source, 100 testes de IA

Introdução

Andrej Karpathy publicou o Autoresearch, um projeto de código aberto que permite rodar centenas de experimentos de IA, de forma autônoma, em uma única GPU durante a noite. A proposta é objetiva, transformar a pesquisa em um loop contínuo, no qual um agente altera o código, treina por 5 minutos, avalia se houve ganho e mantém apenas o que melhora a métrica val_bpb. Em relatos públicos, houve sessões com 100+ experimentos noturnos e reduções consistentes na perda de validação.

A importância prática é imediata. Em vez de equipes iterarem manualmente em hiperparâmetros, arquiteturas e truques de otimização, a própria máquina conduz a exploração, respeitando um orçamento fixo de tempo e usando um único arquivo central de treino. Isso democratiza a experimentação em LLMs, barateia o custo de tentativa e erro e formaliza o método científico no código.

O artigo explica como o Autoresearch funciona, o que os primeiros resultados mostram, onde estão os ganhos reais, como configurar um ambiente mínimo e quais armadilhas evitar ao ampliar esse padrão para outras áreas, como visão computacional, marketing e até robótica. As referências incluem o texto original do VentureBeat, o repositório do GitHub e discussões técnicas da comunidade.

Como o Autoresearch transforma a rotina de pesquisa

A mecânica central é simples e poderosa. O agente recebe um setup de treinamento pequeno porém real, baseado em uma versão single GPU do nanochat, e trabalha em ciclos de 5 minutos, tempo de relógio, sem contar a inicialização. Ao final de cada ciclo, a métrica val_bpb decide se as alterações no arquivo de treino, o único arquivo que o agente modifica, ficam ou são revertidas. Esse design padroniza a comparação entre experimentos e força o agente a encontrar o melhor modelo possível dentro do tempo disponível.

Três arquivos estruturam o fluxo. prepare.py, com constantes, preparo de dados e utilitários de runtime. train.py, o alvo das edições, que contém modelo GPT completo, otimizadores e laço de treino. program.md, onde a pessoa escreve as instruções em linguagem natural para guiar o agente. Essa separação reduz a complexidade e mantém os diffs revisáveis.

Do ponto de vista de produtividade, essa abordagem muda o papel do pesquisador, de executor de experimentos para designer do programa de pesquisa. O ganho não está só em velocidade. Está na disciplina de decisões replicáveis, na padronização do tempo de treino por experimento e na curadoria de um histórico que preserva os deltas vencedores, algo difícil de manter em ciclos manuais e dispersos.

![Andrej Karpathy em palestra]

O que os resultados iniciais mostram

Os relatos publicados reúnem números concretos. Em uma sessão noturna com 126 experimentos, a perda de validação caiu de 0,9979 para 0,9697, com destaques como weight decay seletivo e escalonamento de inicialização, além de ganhos por ajustes em janela de contexto e frequência RoPE. Em outra maratona de dois dias, o agente processou aproximadamente 700 mudanças autônomas, identificou cerca de 20 melhorias aditivas que transferiram para modelos maiores e reduziu o tempo para o patamar de GPT-2 de 2,02 horas para 1,80 hora, um ganho de 11 por cento no leaderboard.

O VentureBeat reportou ainda que o post inicial viralizou e catalisou experimentação ampla. O ponto mais relevante para quem constrói produto, a técnica não se restringe a NLP. A lógica do loop, hipótese, modificação, avaliação e retenção pode migrar para outras disciplinas onde exista uma métrica estável e ciclos rápidos, como otimização de criativos, testes de landing pages e robótica em simulação.

Vale a ressalva sobre comparabilidade externa. Como o orçamento é fixo em 5 minutos por experimento e roda no seu hardware, os números de uma pessoa não comparam diretamente com os de outra. Em compensação, internamente os resultados ficam padronizados e o agente tende a convergir para o melhor arranjo que o seu ambiente suporta naquele tempo.

![Curva de progresso de experimentos]

Arquitetura mínima, setup e primeiros passos

O arranque é direto, um único GPU NVIDIA, Python 3.10 ou superior e o gerenciador uv. O fluxo recomendado é sincronizar dependências, baixar dados e treinar o tokenizer, rodar um treino único de 5 minutos para validar o ambiente e então liberar o agente, apontando para o program.md. O agente deve operar sem permissões perigosas, a ideia é agir localmente nesse repositório.

Para GPUs menores que uma H100 ou para executar em máquinas mais limitadas, há recomendações explícitas. Usar datasets de menor entropia, como TinyStories, reduzir o vocabulário e o comprimento de sequência, diminuir a profundidade do transformer e ajustar o número de tokens de avaliação. Essas escolhas preservam a comparabilidade interna do loop, mesmo com recursos modestos. A comunidade tem publicado forks para Windows e ports para Apple Silicon com MLX, sinalizando que o padrão se adapta bem a diferentes plataformas.

Em termos de instrumentação, o val_bpb é vocabulário independente e facilita medir arquitetura versus hiperparâmetros com justiça. A métrica precisa ser estável e alinhada à sua meta. Se o objetivo for tempo para alcançar um baseline específico, como o patamar de GPT-2 no leaderboard, defina um alvo e meça progresso relativo, como no caso dos 11 por cento de ganho citados acima.

Casos reais, ecos da comunidade e extensões

A comunidade rapidamente replicou e estendeu o padrão, com relatos de 100+ experimentos em execuções noturnas e integrações com ferramentas de automação de agentes. Surgiram ports para MLX no macOS, adaptações para GPUs antigas e propostas de colaboração entre múltiplos agentes com compartilhamento de descobertas, evitando que cada um redescubra becos sem saída em paralelo. Esses relatos ajudam a mapear o que transfere bem entre setups e onde ajustes são necessários.

Discussões no GitHub detalham deltas que funcionaram, como weight decay em embeddings e value embeddings, ajustes finos na escala de inicialização e estratégias de warmdown, ao lado de passos que regrediram métricas, como tying de pesos e configurações agressivas de MQA. Essa transparência acelera o que o agente aprende no seu ambiente, porque inspira hipóteses iniciais mais promissoras.

No noticiário, o VentureBeat contextualizou o impacto e trouxe números de escala, tanto em experimentos por noite quanto em maratonas de dois dias, reforçando que o loop não é apenas produtividade. É uma mudança de papel, do humano como experimentador para designer do sistema e curador das regras do jogo. Essa leitura dialoga com a direção mais ampla de pesquisa autônoma e cooperação de agentes.

![GPU Nvidia H100 em bancada de teste]

Aplicações práticas além de LLMs

O padrão do Autoresearch se generaliza. Sempre que houver um ciclo rápido de teste, uma métrica objetiva e um espaço de busca que possa ser expresso em código, o agente pode iterar sozinho. Em visão computacional, o alvo poderia ser mAP ou F1 em um conjunto de validação. Em robótica simulada, a recompensa média por episódio. Em marketing, taxa de resposta positiva a emails ou CTR de criativos, com o agente gerando variações controladas e mantendo apenas as que sobem a métrica. O VentureBeat compilou exemplos de como esse raciocínio já começou a vazar para essas áreas.

Há uma oportunidade interessante em orquestrar múltiplos agentes que compartilham seus achados, formando um sistema distribuído de pesquisa. Começos desse tipo já surgiram, com gossip de descobertas e consolidação de deltas. Para quem opera com frota heterogênea, de laptops a H100, dá para explorar como restrições de hardware induzem caminhos de otimização diferentes e, por vezes, mais criativos.

Riscos, limites e como evitá-los

Todo loop autônomo precisa de cercas. O risco mais citado é o overfitting de validação, especialmente quando muitos experimentos tocam a mesma partição de dados e começam a explorar idiossincrasias do conjunto. A comunidade levantou essa preocupação e discute estratégias como rotacionar seeds, variar subconjuntos de validação ou introduzir checks periódicos em benchmarks externos. Outro risco é inflar ganhos com métricas que não traduzem utilidade real, por isso é importante conectar val_bpb, ou o alvo equivalente, a objetivos de produto.

Outro limite é a comparabilidade entre pessoas. Com tempo fixo por experimento e hardware diferente, não há uma referência universal. O que importa é a trajetória interna de melhoria, que é padronizada pelo orçamento de 5 minutos. Disso decorre um cuidado, não confundir leaderboard local com ranking absoluto entre laboratórios. O próprio README ressalta que essa padronização serve ao progresso local, e que ports para outras plataformas existem, porém com trade offs.

Também vale reforçar boas práticas de segurança. Rodar o agente com permissões mínimas, confinado ao repositório. Registrar as diffs em PRs revisáveis. Manter histórico de experimentos, para evitar regressões e para que humanos entendam o porquê das mudanças vencedoras. Esse material vira o capital de pesquisa, que pode abastecer modelos maiores posteriormente.

Guia rápido para experimentar hoje

• Alvo e métrica. Defina claramente o objetivo, por exemplo reduzir val_bpb em N pontos dentro de 48 horas, e explicite isso no program.md.
• Orçamento e plataforma. Comece com 5 minutos por experimento, padrão do Autoresearch, e uma única GPU. Se os recursos forem modestos, reduza vocabulário, contexto e profundidade, e escolha datasets de menor entropia.
• Sementes e validação. Rotacione seeds e, se possível, varie subconjuntos de validação para mitigar overfitting do loop. Acompanhe curvas de progresso, como a exibida no repositório.
• Histórico e transferência. Quando um conjunto de deltas vence consistentemente, teste a transferência para um modelo maior, como foi feito ao empilhar cerca de 20 melhorias que baixaram o tempo para o patamar GPT-2 em 11 por cento.

Conclusão

A ideia central do Autoresearch é elegante porque alinha método científico, automação e custo. Um agente que manipula apenas um arquivo, treina por tempo fixo, mede com uma métrica estável e mantém somente o que melhora o alvo, entrega uma cadência de 100+ tentativas por noite que poucas equipes alcançam manualmente. Os relatos de redução de val_bpb e aceleração no tempo para alcançar marcos conhecidos evidenciam o valor.

O próximo passo é ampliar com responsabilidade, com métricas que importam e controles de overfitting. Quem dominar o design dos programas de pesquisa, e não apenas a execução de experimentos, tende a construir vantagens duradouras. O momento é propício para começar pequeno, capturar ganhos rápidos e transformar o loop autônomo em disciplina de produto.