O ratchet loop: quando o agente faz a pesquisa e você define o que é bom

Existe uma mudança de perspectiva que acontece quando você para de pensar em "usar um agente para executar uma tarefa" e começa a pensar em "deixar um agente melhorar um sistema de forma contínua". São dois usos muito diferentes do mesmo recurso.

O Auto-Research, o projeto que o Karpathy lançou e que viralizou rapidamente, capturou essa mudança de forma clara. O projeto original era para treinar modelos de linguagem: um agente rodava experimentos de treinamento, avaliava se o resultado melhorou, mantinha o que melhorou e descartava o que não melhorou, e repetia indefinidamente. Mas o padrão não tem nada de específico para treinamento de modelos.

O mecanismo do ratchet

O que torna o loop funcionar é uma propriedade específica: o sistema só avança, nunca regride.

Cada experimento propõe uma modificação. O agente implementa, avalia o resultado com a métrica definida, e toma uma decisão binária: mantém se melhorou, reverte via git se não melhorou. O histórico de experimentos acumula num arquivo de log, e o agente-pesquisador lê esse histórico antes de propor o próximo experimento.

O resultado é que o agente raciocina sobre o que já tentou. Depois de esgotar variações numéricas que não produziram ganho, ele começa a testar mudanças categóricas. É assim que as descobertas mais significativas aparecem: não pela primeira ou segunda tentativa, mas depois de o sistema explorar o espaço mais óbvio e começar a tentar coisas mais diferentes.

Isso é diferente de busca aleatória. A LLM-pesquisadora tem contexto de tudo que foi tentado e o que aconteceu com cada tentativa. Ela faz hipóteses informadas pelo histórico.

A estrutura de três arquivos

O que torna o padrão utilizável é a separação explícita de responsabilidades:

program.md é o que o humano escreve e mantém. Define os objetivos, as restrições, o que o agente pode e não pode fazer, o formato de log, e o critério de qualidade. É a agenda de pesquisa.

O arquivo de implementação é o que o agente modifica. É o sandbox onde as mudanças acontecem. O agente não pode tocar program.md nem o script de avaliação. Só pode mexer no que está dentro dos limites definidos.

O arquivo de avaliação define a métrica. Tem que ser determinístico e automático. Sem isso, não há como comparar experimentos de forma objetiva.

A separação é importante porque define onde o julgamento humano é necessário e onde pode ser delegado. O humano define o que é "melhor". O agente decide como tentar alcançar melhor dentro das restrições.

O que o programa.md exige

Existe uma linha num guia de uso do Auto-Research que captura algo importante: "Escrever um bom program.md requer ter feito a pesquisa você mesmo. Você precisa saber quais direções valem a pena tentar, o que 'melhor' significa para o seu problema e quando ganhos incrementais chegaram ao limite."

Isso é contraintuitivo para quem pensa no loop como uma forma de não precisar entender o problema. Na verdade, para o loop funcionar bem, você precisa entender o problema bem o suficiente para definir a métrica certa, as restrições certas, e as direções de exploração corretas.

O agente executa a pesquisa. O humano é o orientador que sabe o que é válido investigar.

Onde esse padrão se aplica

O padrão funciona para qualquer sistema que satisfaz três condições: tem parâmetros que podem ser variados, tem uma métrica que pode ser medida automaticamente, e pode rodar um experimento dentro de um tempo razoável.

Para sistemas de processamento de documentos, os parâmetros podem ser os prompts de extração, os thresholds de confiança, os modelos utilizados. A métrica pode ser a precisão de extração medida contra um conjunto de exemplos anotados. Um loop que roda overnight e acorda com dez configurações testadas e a melhor selecionada é tecnicamente viável hoje.

Num contexto como o Athena, onde a qualidade das queries geradas depende de como o contexto de schema é apresentado ao modelo, um loop de auto-otimização que testa variações de estrutura de contexto contra um conjunto de perguntas e queries esperadas poderia encontrar a configuração ótima sem intervenção manual a cada vez que o schema do cliente muda.

O que o Auto-Research demonstra é que a distância entre "o sistema funciona razoavelmente" e "o sistema está otimizado" pode ser percorrida por um agente se você souber definir o critério de chegada.

Qual sistema que você opera hoje tem parâmetros que nunca foram sistematicamente otimizados porque fazer isso seria muito trabalhoso para fazer à mão?