Infraestrutura para pesquisa de RSI: execução e avaliação de agentes que se aprimoram

Um agente de pesquisa altera uma ferramenta de busca no próprio código. Ele resolve uma tarefa em que antes falhava. Agora consegue resolver outras tarefas? A versão melhorada consegue encontrar outra mudança útil? Investigar isso exige editar programas, executar experimentos e comparar resultados repetidamente. O Beeuni fornece um computador onde os agentes podem fazer esse trabalho com seu código, suas ferramentas e seus scripts de avaliação.

A automelhoria recursiva, ou RSI, investiga se um sistema pode melhorar a si mesmo, inclusive na forma de produzir novas melhorias. Em experimentos com agentes, isso pode significar mudar código, instruções ou ferramentas, testar a alteração e usar uma versão bem-sucedida na tentativa seguinte. Um experimento com uma ferramenta de busca nos permite explicar de forma concreta como o Beeuni ajuda em todo esse processo.

Forneça o código e uma pergunta específica ao Beeuni

Conecte o repositório que contém seu agente e os testes. Informe ao Beeuni como instalá-lo, qual comando executa a avaliação e que parte ele pode alterar. Uma boa primeira pergunta é específica: a ferramenta de busca consegue retornar a função relevante sem enviar o arquivo inteiro ao modelo?

A pergunta de pesquisa determina o que o agente pode editar. Você pode estudar se instruções diferentes melhoram o planejamento, se uma nova busca reduz leituras desnecessárias ou se outra forma de usar a memória ajuda nas tarefas seguintes. Mantenha esses experimentos distinguíveis. Alterar os pesos do modelo é outra configuração de pesquisa, com método de treinamento e requisitos de computação próprios.

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

O Beeuni pode ler a implementação, executar os comandos de instalação e rodar seus testes no terminal. Se faltar uma dependência ou um teste falhar, o agente pode examinar o erro e investigar a causa. Você pode acompanhar o trabalho na sessão e abrir os arquivos gerados.

Teste a ferramenta original antes de experimentar a substituta

Primeiro, peça ao Beeuni para executar o agente sem alterações. Salve quais tarefas passaram, quais falharam e os erros. Se sua ferramenta de testes registrar uso do modelo, chamadas de ferramentas ou duração, inclua esses dados. Agora você tem resultados concretos para comparar com a versão alterada.

Depois, deixe o agente alterar a ferramenta de busca e executar o mesmo comando novamente. Mantenha o modelo, a lista de tarefas e os limites. Peça uma explicação para cada resultado que mudou, com o log correspondente. Vale investigar uma redução no consumo de tokens, assim como uma tarefa que passou a falhar porque o resultado resumido da busca deixou de fora código importante.

Esses são arquivos que você pede ao agente para produzir com seus scripts. O Beeuni não fornece o benchmark de pesquisa nem decide o que conta como melhoria. Você traz as tarefas e o código de pontuação; o agente ajuda a executá-los e a investigar os resultados.

Use as falhas para escolher a próxima mudança

Suponha que a nova ferramenta funcione bem com arquivos pequenos, mas falhe quando uma função chama outra auxiliar em um arquivo diferente. Peça ao Beeuni para examinar essa tarefa, encontrar o contexto que falta e propor uma mudança específica. Você pode adicionar nomes de funções relacionadas ao resultado da busca, em vez de voltar a retornar todos os arquivos completos.

Revise a alteração e o relatório antes de aceitá-los. Depois, teste em outras tarefas. Resolver o exemplo que motivou a mudança diz menos do que resolver tarefas às quais o agente não adaptou o código. Mantenha os testes de pontuação final fora dos arquivos que o agente pode editar.

A mesma abordagem serve para um agente que usa o navegador. Forneça ao Beeuni um aplicativo de teste e uma tarefa, como encontrar um pedido e atualizar a observação de entrega. Ele pode operar o navegador, verificar o resultado e salvar evidências de uma falha. Restaure os dados do aplicativo antes de comparar outra versão, para que ambas comecem com o mesmo pedido.

Organize experimentos repetidos com seu próprio programa

Nos experimentos repetidos, o controlador é o programa que organiza as rodadas. Ele escolhe uma versão do agente, solicita uma mudança, inicia os testes e decide o que tentar depois. O candidato é a versão alterada do agente que está sendo testada naquela rodada. Seu controlador pode usar a API ou o SDK TypeScript para iniciar e consultar sessões do Beeuni. As regras de seleção ficam no seu código de pesquisa.

Cada sessão tem seu próprio ambiente de execução. Você pode testar duas implementações de uma ferramenta sem que elas sobrescrevam os mesmos arquivos ou dependências. O programa testado no computador deve começar com a revisão de código prevista. Se um script só carrega o código na inicialização, reinicie-o após uma edição para que o teste use de fato a nova implementação.

Comece com uma fila pequena de experimentos. Defina no controlador limites de tentativas, sessões simultâneas, duração e uso do modelo. Ao atingir um limite, faça com que ele interrompa o trabalho correspondente e verifique se os processos terminaram. Essas regras determinam quanto o experimento pode buscar antes de escolher uma versão.

Teste cada versão em condições comparáveis

Um agente que pudesse ler o gabarito ou alterar os testes conseguiria aumentar a pontuação sem melhorar na tarefa. Execute a pontuação final separadamente, mantenha as respostas ocultas fora dos arquivos acessíveis ao agente e impeça que ele altere o código de pontuação. O Beeuni pode executar testes de desenvolvimento e coletar saídas; seu programa de avaliação pode pontuar essas saídas separadamente. Em experimentos de navegador, restaure os dados compartilhados do aplicativo entre versões: um computador novo ainda vê os registros deixados no mesmo aplicativo externo.

Compare tarefas concluídas, erros, tempo decorrido, chamadas de ferramentas e uso do modelo quando sua ferramenta de testes registrar esses dados. Mantenha comparáveis as tarefas, as configurações do modelo e os limites de execução. Repita resultados incertos. Uma mudança pode ler menos tokens, mas perder uma função auxiliar, ou passar em mais tarefas fazendo muito mais chamadas ao modelo. O relatório deve deixar essa diferença visível.

Conte também o custo de encontrar a mudança. Registre separadamente as tentativas usadas para propor e testar versões e o custo de executar a versão escolhida. Um agente pode custar menos por tarefa e ainda ter exigido uma busca cara para ser descoberto. As duas medidas importam ao avaliar o experimento.

Guarde detalhes suficientes para explicar uma rodada que falhou

Uma tarefa que falhou e uma API de modelo indisponível precisam de tratamentos diferentes. Peça ao Beeuni para preservar erros e logs originais antes de resumi-los. Seus resultados podem distinguir respostas incorretas, dependências ausentes, falhas em requisições ao modelo e limites de tempo esgotados. Decida quais falhas justificam outra tentativa, em vez de repetir tudo silenciosamente até passar.

Salve as revisões original e alterada do código, as instruções, os comandos de inicialização, as dependências, a versão dos testes, a versão do código de pontuação e os resultados por tarefa. Registre de qual versão anterior veio cada mudança. O Beeuni pode escrever esse registro junto com a alteração e os logs, para que você examine por que uma versão foi escolhida ou descartada.

Salve as alterações e os relatórios úteis no seu repositório ou armazenamento antes de excluir o computador do experimento. Assim, você consegue relacionar um resultado ao código e ao comando que o produziram, inclusive nas tentativas descartadas.

Verifique se melhora a capacidade de encontrar a próxima melhoria

Depois de escolher uma versão, avalie-a em tarefas que não orientaram as alterações. Em seguida, use-a para buscar novas melhorias e compare essas tentativas com as do agente original. Ela encontra mudanças úteis com mais frequência, precisa de menos tentativas ou causa menos regressões com o mesmo orçamento? Resolver mais tarefas é um resultado. Melhorar o processo que produz melhorias futuras é a pergunta adicional que a pesquisa de RSI precisa investigar.

Como exemplo de pesquisa, o artigo sobre a Darwin Gödel Machine explora agentes que alteram o próprio código e testam as mudanças. Self-Refine estuda a revisão de uma resposta a partir de feedback, sem treinamento adicional. Essa distinção ajuda a definir o experimento: você está melhorando uma resposta, a forma de trabalhar do agente ou a capacidade de encontrar a próxima melhoria? O Beeuni ajuda a editar código, executar comandos e examinar resultados. Você define o método de pesquisa. Se precisar treinar um modelo, veja como executar um ajuste fino com o Beeuni.

Para experimentar a mudança na ferramenta de busca, comece com um repositório e um comando de teste que funcione. O guia do Computer explica como examinar o ambiente e a saída dos processos enquanto o Beeuni trabalha.