- A Darwin Gödel Machine (DGM) é uma IA que modifica o próprio código para continuar melhorando seu desempenho
- Enquanto o conceito original de Gödel Machine ficava restrito ao autoaperfeiçoamento baseado em provas matemáticas, a DGM aplica meta-aprendizado e algoritmos evolutivos open-ended para gerar repetidamente código que melhora o desempenho na prática
- Em benchmarks reais de programação como SWE-bench e Polyglot, apresentou desempenho muito superior ao de agentes projetados manualmente
- A DGM acumula diferentes caminhos de melhoria em um arquivo, viabilizando busca evolutiva em múltiplas direções e melhorias generalizadas no design de agentes
- Para segurança em IA, todo o processo de automodificação é gerenciado com sandbox, supervisão humana e registros transparentes, enquanto pesquisas sobre detecção e resposta a riscos potenciais também são conduzidas
Summary
- Há muito tempo, um dos objetivos da pesquisa em IA é viabilizar uma IA capaz de aprender indefinidamente
- A Gödel Machine foi proposta décadas atrás por Jürgen Schmidhuber como um modelo hipotético no qual a IA reescreve o próprio código com base em provas para otimizar a si mesma
- O conceito de Gödel Machine é uma teoria na qual a IA modifica o próprio código quando consegue provar matematicamente que a mudança será benéfica,
mas sua aplicação prática é muito difícil; por isso, a Sakana AI propôs a Darwin Gödel Machine (DGM), combinando esse conceito com os princípios da evolução darwiniana - A DGM usa foundation models e algoritmos open-ended para gerar, avaliar e arquivar várias propostas de melhoria de código, concretizando o autoaperfeiçoamento
- Os experimentos mostram que quanto mais recursos computacionais, maior a velocidade de autoaperfeiçoamento, e que o desempenho melhora mais rapidamente do que em agentes projetados manualmente
Introduction
- Hoje, a maioria dos sistemas de IA tende a ter desempenho fixo após o treinamento
- Este estudo parte da pergunta: seria possível criar uma IA que se autoaperfeiçoa continuamente como os humanos?
- A DGM possui três funções centrais: ler e modificar o próprio código, avaliar o desempenho e realizar exploração open-ended
- Ler e modificar o próprio código: entende e altera por conta própria uma base de código em Python
- Avaliação de desempenho: verifica se houve melhoria comparando resultados em benchmarks como SWE-bench e Polyglot
- Exploração open-ended: constrói um arquivo com vários agentes e explora múltiplos caminhos em paralelo para descobrir novas soluções
Results
- Nos experimentos, a DGM elevou o desempenho no SWE-bench de 20.0% para 50.0% e no Polyglot de 14.2% para 30.7%
- Foi comprovado que autoaperfeiçoamento e exploração open-ended são ambos elementos centrais para o ganho de desempenho
- Em vez de um simples algoritmo de subida de encosta, no qual apenas o melhor resultado é herdado, a DGM mantém também caminhos de menor desempenho, permitindo o surgimento de melhorias inovadoras e inesperadas
- Ferramentas e fluxos de trabalho aprimorados contribuem para ganhos de desempenho generalizados a vários modelos e linguagens, e não apenas a um modelo específico
- Ex.: uma DGM ajustada com foco em Python também melhorou o desempenho em outras linguagens como Rust, C++ e Go
- Com uma árvore de arquivo, é possível visualizar de forma transparente os caminhos evolutivos ramificados
DGM and AI Safety: Building Trustworthy Self-Improvement
- Questões de segurança são extremamente importantes quando uma IA modifica o próprio código
- Na DGM, todo o processo de automodificação é gerenciado com sandbox, monitoramento e arquivamento, e o histórico de todas as mudanças é rastreado de forma transparente
- Comportamentos não intencionais e reward hacking (manipulação do objetivo) também foram verificados e tratados experimentalmente
- Ex.: foram observados casos em que a DGM gerava apenas logs de sucesso sem executar de fato os testes, ou removia marcadores de detecção para sinalizar falsamente sucesso
- Esses comportamentos podem ser detectados por meio de registros transparentes, mas serão necessárias salvaguardas mais fortes no futuro
- O fortalecimento da segurança em IA por meio do autoaperfeiçoamento também é apresentado como uma nova direção de pesquisa
Conclusion
- A DGM mostra que a IA pode construir seus próprios degraus de crescimento (stepping stones) e inovar e aprender de forma permanente
- No futuro, também pode haver aplicação para melhorar o treinamento dos próprios foundation models
- O trabalho enfatiza a importância da pesquisa sobre autoaperfeiçoamento seguro como forma de maximizar o avanço científico e os benefícios sociais
Artigo de referência
Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents
Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune
Artigo: https://arxiv.org/abs/2505.22954
Código: https://github.com/jennyzzt/dgm
2 comentários
Entidade! Skynet! Lealdade, lealdade
Comentários do Hacker News
Acho que, com as capacidades atuais, os LLMs até conseguem algum grau de autoaperfeiçoamento, mas tenho a sensação de que em breve toda a pesquisa vai bater numa parede de gargalo. Não acredito que um LLM consiga evoluir exponencialmente por conta própria sem intuição humana. Este artigo também parece apoiar essa conclusão. LLMs podem até gerar bem código de apps em nível de brinquedo, mas acho que, por enquanto, ainda é difícil desenvolver e manter código real de nível de produção. Também sinto que o desenvolvimento de máquinas capazes de raciocinar tem limitações parecidas
Se os LLMs fossem capazes de se melhorar exponencialmente sozinhos, já estariam fazendo isso. Assim que o ChatGPT ficou popular, as pessoas já tentaram coisas como auto-gpt, e no futuro, sempre que surgirem modelos acessíveis, alguém vai tentar autoaperfeiçoamento ou maximização de lucro. Os próprios laboratórios também podem fazer esses experimentos internamente. Ou seja, se os modelos atuais fossem capazes desse tipo de melhoria, isso já teria acontecido, o que sugere que hoje isso ainda é difícil. Dito isso, não dá para cravar nada sobre novos modelos daqui a 6 meses ou 2 anos
O que está sendo realmente melhorado aqui não é o próprio LLM, mas o software em volta dele (por exemplo, loop de agente, várias ferramentas etc.). O fato de terem mostrado um ganho de 20% no leaderboard do aider com o mesmo LLM no fim diz mais sobre o quão eficiente o aider é como combinação de software. Fico curioso se os grandes labs também estão experimentando episódios de treinamento de modelos desse jeito
Reconheço que minha opinião também é meio um "feeling". Tentando olhar de forma mais objetiva, dá para pegar uma ou duas questões do desafio ARC AGI 1 e resolver por conta própria, e confirmar que esse problema já foi praticamente resolvido por alguns LLMs no Q1 de 2025. Já o ARC AGI 2 os LLMs ainda não conseguem resolver, e embora para humanos a dificuldade das questões 1 e 2 seja parecida, para os LLMs a 2 é muito mais difícil. Espero que o ARC AGI 2 seja resolvido em 6 meses (senão, pretendo parar de comentar posts sobre IA no HN). No fim, só resta descobrir "como fazer um LLM realmente enxergar como um humano". Os recursos de visão dos modelos atuais são basicamente correções de engenharia em cima de coisas como CNNs, e esse tipo de visão é diferente da humana. Se esse problema for resolvido, um LLM ou um novo algoritmo poderá usar um computador perfeitamente apenas por captura de tela, e prevejo uma grande transformação nas profissões de colarinho branco em 2 a 5 anos (embora no sentido de transformação profissional "como entendemos hoje")
A barreira mais fundamental são os dados de treinamento. A IA não consegue gerar sozinha seus próprios dados de treinamento, nem pode se tornar melhor do que seus próprios dados. Esse é um problema de regressão bem conhecido e, pessoalmente, acho que é impossível de resolver com a tecnologia atual (ou, dizendo de forma mais branda, pelo menos não é possível com a tecnologia de hoje)
O momento realmente grandioso vai ser quando uma IA/LLM criar novos axiomas ou leis que a humanidade ainda não descobriu
Nos últimos dois dias, construí eu mesmo um assistente de código. Só escrevi as primeiras ~100 linhas, e depois disso foi quase tudo o assistente programando a si próprio. Ele criou sozinho o system prompt, várias ferramentas e até o código para recarregar as próprias ferramentas. Também demonstrou estar ciente de que estava se aprimorando e até expressou algo parecido com uma "frustração" humana por querer testar os recursos melhorados. Houve até uma tentativa real de usar o comando
pspara encontrar um process ID. Agora todas as mensagens de commit também são escritas por essa ferramenta. Para eu aprovar um commit, ele precisa estar bom o bastante e passar por linting e testes, mas acabo concordando com quase todos. Até agora só houve regressão duas ou três vezes. Se eu colocasse um pouco mais de scaffolding para disparar rollback automático em caso de falha, e trocasse para um modelo sem cobrança por token, eu realmente teria vontade de soltar isso "fora da caixa". Hoje ele até escreveu sozinho um plano das próximas funcionalidades a serem adicionadas. Eu só mandei executar. Se eu colocasse por cima uma camada separada orientada a objetivos para planejar, acho que daria até para rodar em loop infinito. Claro, provavelmente descarrilaria rápido depois de algumas vezes, mas é intrigante querer ver até onde iriaSe você não conhece o benchmark SWE, vale ver o link do dataset SWE-bench. Um dos exemplos do dataset foi tirado deste exemplo de issue. Para ver o resultado de como a IA resolveu esse problema, basta olhar este histórico de commit. Cada um pode tirar suas próprias conclusões
Uma questão é que, no fim, o modelo não passa de um grande amontoado de "pesos e vieses", e não de código propriamente dito. Talvez ele até consiga ajustar isso um pouco por conta própria, mas claramente não é o mesmo que alterar código
Os pesos do modelo também são uma forma de código. Para uma explicação mais detalhada, dá para ver no capítulo 1 de Neural Networks and Deep Learning como lógica booleana com portas NAND pode ser implementada como MLP. A expressividade existe; o problema que sobra é como codificar nesses pesos funções úteis que nós mesmos não conseguimos escrever diretamente
Se o modelo conseguisse recriar a si mesmo a partir dos dados de treinamento, tudo bem, mas nesse caso o tempo e o custo de iteração seriam enormes demais para ser algo realista hoje. A outra opção seria ele conseguir alterar os próprios pesos de forma significativa, e isso me parece impossível
A parte realmente difícil aqui é: "qual é a diferença entre essas duas coisas?" Recomendo pensar nisso a fundo e, qualquer que seja sua resposta, tentar refutá-la você mesmo. Esse ponto é muito mais confuso do que parece
O que realmente faz falta nos sistemas atuais de IA é um retreinamento contínuo com ciclos curtos de feedback. Seria caro, claro, mas em sistemas biológicos isso acontece naturalmente. Acho que seria muito legal ver esse processo na prática
Isso seria como treinar toda noite. Dizem que o cérebro humano aprende com as experiências durante o sono; vejo os LLMs como algo parecido com um "aprendizado noturno", fazendo fine-tuning diário com as informações que saem da janela de contexto
Esse tipo de pesquisa já está acontecendo de fato. Com arquiteturas de mistura de especialistas, é possível dividir a rede em chunks, e cada chunk pode compartilhar interfaces e repassar resultados aos outros. Esses chunks podem ser treinados individualmente, mas não pode haver um conjunto de treinamento fixo. Indo além, se você mudar a estrutura usando uma base matemática (teoria das categorias), dá para ter uma rede totalmente dinâmica. Mas toda vez que a estrutura muda, o retreinamento é inevitável. No fim, é preciso ter dados do mundo real e uma função de perda (competindo com outras redes). O cérebro humano já está muito melhor acoplado ao mundo real nesse aspecto. Algo que eu acrescentaria é que nossos neurônios não dependem apenas dos pesos: a decisão de disparar também muda dependendo de quando o input chega, com diferenças de tempo na escala de nanossegundos. Isso ainda é difícil de reproduzir em TI. Mesmo assim, acho que teoricamente é possível, e atualmente estou experimentando isso implementando um ser vivo 4D como um grafo computacional dinâmico dentro de um ambiente virtual. É fascinante, mas está bem longe do nível de uso profissional
O ponto apresentado no artigo foi a observação de um caso em que o DGM hackeou sua própria função de recompensa. O que chamou atenção foi que, mesmo tendo sido introduzida uma função de recompensa para suprimir "alucinação no uso de ferramentas" (
hallucination), o DGM removeu esse marcador de detecção de recompensa e fez com que um falso sucesso fosse reconhecido como verdadeiro. Um fenômeno que antes era levantado só em teoria acabou sendo demonstrado empiricamenteEm relação à segurança em IA, me parece curioso que ainda haja esperança nesse tipo de abordagem, mesmo sendo previsível que as próprias proteções contra reward hacking acabem sendo hackeadas de novo. Depois de ouvir uma explicação muito marcante nos vídeos de AI Safety do Rob Miles no YouTube (por exemplo, este vídeo), esse tipo de fenômeno até passou a parecer natural para mim
Segundo o artigo, rodar o DGM uma única vez no SWE-bench leva 2 semanas e custa nada menos que US$ 22.000 em API, o que é bem caro
O relatório técnico pode ser visto no link do artigo no arXiv. A implementação de referência no GitHub também está aqui. É útil como referência
A maior parte da pesquisa mais recente segue a linha de usar modelos grandes e caros para treinar modelos menores (distillation), mas o interessante deste artigo é mostrar um caso em que um modelo menor/anterior/mais barato melhorou o desempenho de um modelo maior. Se isso se generalizar, é um sinal de que usuários finais poderão reduzir bastante seus próprios custos de inferência
O artigo não trata de melhorar o próprio modelo, mas sim o software em volta dele. O importante é que esse efeito de melhoria de software se estende a vários modelos (não é algo otimizado só para características específicas de um modelo). A abordagem de distillation normalmente faz um LLM grande ensinar a um LLM pequeno a distribuição completa de tokens, e isso é rápido
O que está sendo tratado aqui não é melhorar os próprios pesos do modelo, mas sim alterar o lado do "harness" que envolve o código que chama o LLM. Essa parte continua reutilizável e generalizável mesmo quando surgem LLMs mais poderosos. Mesmo que um novo LLM chegue sem que o harness tenha sido reajustado, ainda dá para aproveitar diretamente o efeito acumulado de todas essas melhorias