De gerar planos a decidir o próximo passo: como o AutoResearch fecha o ciclo de pesquisa sem inventar sucesso

O AutoResearch conecta descoberta de problemas, geração de planos, experimentos em enxame e validação independente em um processo de pesquisa capaz de avançar continuamente. Em uma tarefa de correção do Django, elevou o resultado dos testes oficiais de nova funcionalidade de 2/7 para 7/7, mantendo aprovados todos os 203/203 testes de regressão. Em três experimentos do Kaggle, também distinguiu entre atingir a meta, chegar perto dela e alcançar um platô, usando essas evidências para continuar, mudar de direção ou parar.

O AutoResearch é um sistema automatizado de pesquisa. Ele observa continuamente artigos, projetos de código aberto, discussões da comunidade e anomalias técnicas, identifica problemas que merecem investigação, organiza vários modelos para transformar ideias em experimentos e deixa os resultados externos decidirem o próximo passo.

O processo enfrenta uma falha mais difícil de perceber do que inventar fatos: o código existe e os testes locais realmente passam, mas o sistema confunde “esta parte está correta” com “o problema inteiro foi resolvido”.

Figura 1 | Todos os testes locais em verde provam apenas que as verificações cobertas passaram. A avaliação independente revela lacunas críticas que ainda não estavam cobertas.

Em uma tarefa real de correção do Django, o GPT-5.6 passou em 716 testes de migration e 39 testes do optimizer, mas obteve 0/7 nos testes oficiais de nova funcionalidade. O AutoResearch também não resolveu o problema completo na primeira rodada: os testes locais estavam verdes, enquanto o resultado oficial era apenas 2/7. A diferença surgiu depois dessa falha. O sistema continuou reformulando o problema com base nos resultados externos e avançou por 2/7, 4/7 e 7/7 até que tanto os testes de nova funcionalidade quanto os de regressão fossem aprovados.

1. Quatro ações formam o ciclo principal de pesquisa

Figura 2 | Encontrar um problema, forjar uma ideia verificável, executar o experimento e deixar a evidência decidir. Essas quatro ações formam o ciclo principal do AutoResearch.

O ciclo principal do AutoResearch contém quatro ações consecutivas:

1. Descobrir um problema: extrair de informações abertas novos fenômenos, resultados ou contradições não resolvidas que possam ser rastreados.
2. Formar uma ideia verificável: reescrever o sinal como uma hipótese de pesquisa com critérios de sucesso, limites de recursos e condições de falha.
3. Organizar experimentos em enxame: distribuir planejamento, implementação, execução e revisão entre papéis que colaboram.
4. Deixar a evidência decidir: resultados externos determinam se o sistema deve iterar, mudar de direção ou parar.

Uma falha não encerra automaticamente o fluxo. Ela se torna entrada para a rodada seguinte e leva o sistema a restringir os limites do problema ou alterar o caminho experimental.

2. Encontrar um problema que mereça pesquisa antes de tentar respondê-lo

O AutoResearch acompanha arXiv, Hugging Face Daily Papers, OpenReview e GitHub Trending, além de Reddit, Hacker News, blogs de pesquisa, mídia tecnológica em chinês e Twitter/X. Esses canais diferem muito em formato de dados, significado da popularidade e densidade de informação. Depois da coleta, os itens precisam ser normalizados, filtrados por qualidade e deduplicados dentro do lote e entre dias.

Um modelo de primeira etapa decide rapidamente se cada informação contém uma observação que possa se transformar em tema de pesquisa. Os candidatos preservados passam a modelos mais capazes para uma nova seleção baseada em novidade, viabilidade técnica, recursos necessários e método de avaliação. Quando há candidatos suficientes, o sistema os ordena novamente e seleciona as sementes de pesquisa que devem entrar primeiro no Idea Forge.

Esse funil comprime um fluxo aberto de informações em um pequeno conjunto de candidatos que justificam recursos experimentais. Cada problema mantém uma fonte explícita, permitindo que planos posteriores sejam conferidos com a observação original.

3. Idea Forge transforma sinais em planos experimentais

Uma semente de pesquisa é apenas um fenômeno ou problema do mundo externo. O Idea Forge também seleciona uma linha de pesquisa existente da base de conhecimento e combina as duas partes para criar planos candidatos. As linhas atuais incluem fusão multimodal, gerenciamento de tokens visuais, raciocínio de modelos grandes e computação em tempo de teste (test-time compute), e memória de agentes.

Gemini, GPT e Claude propõem e revisam as ideias candidatas de forma independente. Seus históricos de treinamento e preferências de julgamento são diferentes: alguns reagem mais à novidade, outros se concentram na viabilidade técnica e outros detectam primeiro lacunas de recursos ou avaliação. Antes da execução, um plano candidato precisa passar por quatro verificações:

• Revisão cruzada: três modelos julgam de forma independente, e uma ideia precisa de pelo menos dois votos para continuar.
• Verificação de atualidade: modelos antigos, anos desatualizados e formulações técnicas obsoletas são excluídos.
• Verificação de consenso de conhecimento: o plano precisa realmente usar a linha de conhecimento selecionada, sem apenas unir termos populares de forma mecânica.
• Plano em etapas: a primeira etapa usa um piloto de baixo custo capaz de decidir rapidamente a direção; as etapas seguintes ampliam o experimento, adicionam ablações e completam a avaliação.

A votação por maioria serve para expor pontos cegos cedo. O plano final ainda precisa ser reduzido a uma hipótese mensurável, um orçamento explícito e experimentos capazes de decidir sucesso ou falha.

4. Do plano ao experimento: como o enxame colabora

Figura 3 | Depois da revisão cruzada e do planejamento, uma semente entra em um fluxo colaborativo de planejamento, implementação, execução, revisão e avaliação externa.

Durante a execução, o AutoResearch divide o trabalho em unidades consecutivas. Um papel de coordenação mantém o estado global; um papel de planejamento reescreve o objetivo como um desenho experimental falseável; um papel de implementação escreve o código; um papel de execução o roda e organiza os resultados; e revisores procuram omissões a partir de perspectivas diferentes.

Tarefas simples podem usar menos papéis, enquanto tarefas complexas podem adicionar um Subcoder, um Monitor ou um validador independente. Os nomes dos papéis não determinam o resultado. O importante é que planejamento, implementação, execução e revisão deixem de ocupar uma única resposta do modelo.

Planos, código, registros experimentais e observações de revisão permanecem em um espaço de trabalho persistente. O ciclo continua processando unidades incompletas até que métricas externas e condições de parada permitam o encerramento. Resultados podem refutar o plano, e revisores podem errar. A recomendação de término emitida por um papel não pode fechar o fluxo. Resultados reproduzíveis e critérios de sucesso independentes decidem se o trabalho continua e quando deve parar.

5. Validação do sistema I: levar um objetivo de pesquisa a um resultado verificável

O AutoResearch usou um protocolo experimental semelhante em três problemas do Kaggle: começar com um piloto de baixo custo para validar a direção e desenhar o experimento principal a partir do resultado. Cada etapa tem critério de sucesso, revisão de código, registro de execução e decisão de parada. Os três problemas usam respectivamente acurácia, raiz do erro quadrático médio logarítmico (RMSLE) e F1 como métricas principais, seguindo a direção definida pela competição oficial do Kaggle [1][2][3].

Figura 4 | O mesmo protocolo produz três desfechos: Titanic atinge a meta, House Prices se aproxima dela e Disaster Tweets chega a um platô. Cada gráfico tem escala vertical independente e não deve ser comparado numericamente entre tarefas.

5.1 Titanic: um controle rigoroso isola o valor da engenharia de atributos

A primeira etapa usou nove atributos básicos para estabelecer uma linha de base. A acurácia do Gradient Boosting em validação cruzada de cinco partes foi 0.8272. A segunda etapa adicionou Title, FamilySize, IsAlone, faixas de idade e faixas de tarifa, entre outros atributos.

Control e Treatment usaram a mesma semente aleatória, as mesmas divisões de dados e o mesmo modelo. Control preservou os atributos básicos; Treatment adicionou o conjunto ampliado. Control reproduziu completamente o resultado da primeira etapa, enquanto Treatment atingiu 0.8428 e ultrapassou a meta de 0.8300. A principal diferença entre as condições foi o conjunto de atributos, portanto o resultado sustenta que a engenharia de atributos produziu a melhoria desta rodada.

5.2 House Prices: identificar as mudanças responsáveis pela maior parte do ganho

A meta era reduzir o RMSLE da validação cruzada de cinco partes para menos de 0.1200. O sistema primeiro estabeleceu uma linha de base Ridge em uma amostra pequena e depois alterou apenas o alvo de previsão, aplicando log1p aos preços. O RMSLE caiu de 0.2008 para 0.1566. A adição de poucos atributos derivados produziu 0.1563, mostrando que acumular mais atributos tinha pouco valor.

No experimento completo, a família de modelos mudou de um modelo linear para LightGBM e reduziu o resultado a 0.1258. Atributos ampliados e interações chegaram finalmente a 0.1251. A meta não foi alcançada, mas os experimentos localizaram as fontes dominantes do ganho: a transformação do alvo e a mudança da família de modelos responderam por quase toda a melhoria, enquanto os atributos adicionais tiveram efeito marginal. O sistema parou de ampliar mecanicamente o espaço de ajuste.

5.3 Disaster Tweets: um platô aciona a parada

A meta era atingir F1 de 0.8350. O sistema começou com TF-IDF e regressão logística, estabelecendo uma linha de base lexical de 0.7680, e depois testou SBERT, ajuste fino do DistilBERT e ensembles por votação suave. O melhor resultado foi 0.8049.

Em seguida, aumentou o número de parâmetros de 66M para 125M e mudou para RoBERTa-base, cujo melhor valor foi 0.8005 e não superou o DistilBERT. Depois de 21 experimentos, o melhor resultado continuava em 0.8049. O modelo maior não trouxe ganho, então o sistema parou de adicionar experimentos na mesma rota e reduziu o próximo passo a três opções: obter dados úteis, adicionar recursos de treinamento ou mudar a abordagem de modelagem.

6. Validação do sistema II: avançar de uma correção local para uma solução completa

A segunda avaliação usa django__django-16820 do SWE-bench Lite. O SWE-bench aplica um patch gerado pelo modelo a um repositório real e executa os testes do repositório para determinar se o problema foi resolvido [4]. Essa tarefa surgiu da descontinuação de Meta.index_together no Django e exige que migration optimizer e autodetector funcionem em conjunto com RenameIndex, AddIndex, RemoveIndex e chaves estrangeiras cíclicas. A discussão upstream do Django também registra a relação entre essas operações de índice e a otimização complexa de migrations [5].

Figura 5 | O GPT-5.6 terminou depois que os testes locais passaram e os testes oficiais de nova funcionalidade deram 0/7. O AutoResearch reformulou o problema após os resultados 2/7 e 4/7, até chegar a 7/7 e manter aprovados os 203/203 testes de regressão. As duas condições tiveram tempos e acesso a feedback diferentes; a comparação trata do processo depois da falha.

O GPT-5.6 encontrou uma lacuna real: CreateModel.reduce() não tinha lógica de folding para RenameIndex(old_fields=...). Seu patch passou em 39 testes do optimizer, 716 testes de migration e nos 203 testes oficiais de regressão, mas obteve 0/7 nos testes oficiais de nova funcionalidade. Ele resolveu o subproblema de RenameIndex, sem cobrir AddIndex, RemoveIndex, o autodetector ou chaves estrangeiras cíclicas.

O AutoResearch também se concentrou em RenameIndex na primeira rodada. A revisão de código encontrou a ausência de um no-match guard. Depois da correção, passaram 41 testes do optimizer, 11 testes de integração de squashmigrations e 719 testes de migration. O primeiro resultado oficial foi 2/7.

Os resultados externos ampliaram a perspectiva de uma única ramificação de reduce() para a coordenação entre optimizer e autodetector. A segunda versão chegou a 4/7. A rodada seguinte continuou rastreando como o estado dos índices entra no fluxo de migration, sofre folding e converge. O resultado final atingiu 7/7 nos testes oficiais de nova funcionalidade e preservou 203/203 nos testes de regressão.

7. O AutoResearch automatiza decisões de pesquisa

As duas avaliações mostram que a capacidade central do AutoResearch se concentra em cinco partes:

1. Transformar um problema de pesquisa em um objeto executável: uma ideia precisa resultar em piloto, critérios de sucesso, orçamento de recursos, plano de ablação e entregáveis.
2. Colocar modelos diferentes em posições adequadas: modelos leves filtram muitos candidatos, modelos mais capazes fazem julgamentos profundos e várias famílias de modelos propõem e revisam ideias de forma independente.
3. Fazer o resultado de cada etapa determinar a ação seguinte: atingir a meta, chegar perto dela e obter um resultado negativo deixam evidências e acionam respectivamente expansão, ajuste ou parada.
4. Entregar a autoridade de conclusão a métricas independentes: consenso interno e testes locais em verde não substituem um critério completo de sucesso definido com antecedência.
5. Permitir que o sistema pare: quando uma direção chega a um platô ou o retorno sobre o esforço cai, o sistema fecha a rota atual e preserva o estado e as conclusões necessários para reiniciá-la.

Os modelos propõem, implementam e questionam. A evidência decide o que acontece depois.

8. Sucesso é uma cadeia de evidências sem interrupções

Modelos grandes já são bons em gerar rapidamente respostas candidatas. O AutoResearch desenha o ciclo completo depois de uma resposta: como um problema vira experimento, quem revisa o resultado, como a falha reescreve o próximo passo, quais evidências justificam continuar e em quais condições o sistema para.

Esse método pode ser chamado de engenharia de ciclos (Loop Engineering). O projeto abrange mais do que papéis e prompts: inclui como o estado é preservado, como a evidência circula e como os julgamentos são verificados. Os papéis podem errar. O ciclo precisa expor esses erros e impedir que um “sucesso” sem evidência encerre o fluxo.

9. Referências

1. Kaggle. (2012). Titanic - Machine Learning from Disaster. Kaggle Getting Started Competition.
2. Kaggle. House Prices - Advanced Regression Techniques. Kaggle Getting Started Competition.
3. Kaggle. Natural Language Processing with Disaster Tweets. Kaggle Getting Started Competition.
4. Jimenez, C. E., Yang, J., Wettig, A., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. The Twelfth International Conference on Learning Representations.
5. Django Software Foundation. (2023). Fixed #34529, Refs #34525: Reduced index operations with Meta.indexes / index_together when optimizing migrations. django/django Pull Request #16820.