- La Darwin Gödel Machine (DGM) es una IA que modifica su propio código para seguir mejorando su rendimiento
- Mientras que el concepto original de la Gödel Machine se limitaba a una automejora basada en pruebas matemáticas, DGM aplica metaaprendizaje y algoritmos evolutivos open-ended para generar de forma repetida código que mejora el rendimiento en la práctica
- En benchmarks de programación reales como SWE-bench y Polyglot, mostró un rendimiento mucho mayor que el de agentes diseñados manualmente
- DGM acumula en un archivo distintas rutas de mejora, haciendo posible una búsqueda evolutiva en múltiples direcciones y una mejora generalizada del diseño de agentes
- Para la seguridad en IA, todo el proceso de automodificación se gestiona con sandboxing, supervisión humana y registros transparentes, mientras también se investiga la detección y respuesta ante riesgos potenciales
Summary
- Desde hace mucho tiempo, uno de los objetivos de la investigación en IA ha sido crear una IA capaz de aprender sin límite
- La Gödel Machine es un modelo hipotético en el que una IA reescribe directamente su propio código, basándose en pruebas, para optimizarse a sí misma; fue propuesta hace décadas por Jürgen Schmidhuber
- El concepto de Gödel Machine es una teoría en la que la IA modifica su propio código cuando puede demostrar matemáticamente que el cambio será beneficioso, pero
como su aplicación práctica presenta grandes dificultades, Sakana AI propuso la Darwin Gödel Machine (DGM), que incorpora el principio evolutivo darwiniano - DGM utiliza modelos fundacionales y algoritmos open-ended para generar, evaluar y archivar múltiples propuestas de mejora de código, logrando así crecimiento autónomo
- Los resultados experimentales muestran que cuantos más recursos de cómputo hay, mayor es la velocidad de automejora, y que el rendimiento mejora más rápido que en agentes diseñados manualmente
Introduction
- Hoy en día, en la mayoría de los sistemas de IA el rendimiento suele quedar fijo después del entrenamiento
- Esta investigación parte de la pregunta de si es posible crear una IA que, como los humanos, se mejore a sí misma de forma continua
- DGM tiene tres funciones clave: leer y modificar su propio código, evaluar su rendimiento y realizar exploración open-ended
- Leer y modificar su propio código: entiende y cambia por sí sola una base de código en Python
- Evaluación del rendimiento: determina si hubo mejora comparando resultados en benchmarks como SWE-bench y Polyglot
- Exploración open-ended: construye un archivo de agentes diversos y explora varias rutas en paralelo para descubrir nuevas soluciones
Results
- En los experimentos, DGM elevó el rendimiento en SWE-bench de 20.0% a 50.0%, y en Polyglot de 14.2% a 30.7%
- Se demostró que la automejora y la exploración open-ended son ambas claves para aumentar el rendimiento
- En lugar de usar un simple algoritmo de ascenso de colina (en el que solo sobrevive el mejor resultado), también conserva rutas de bajo rendimiento, de donde pueden surgir mejoras innovadoras e inesperadas
- Las herramientas o flujos de trabajo mejorados no se limitan a un modelo específico, sino que se generalizan a múltiples modelos y lenguajes, contribuyendo a mejorar el rendimiento
- Ejemplo: una DGM ajustada con Python como referencia también mejora el rendimiento en otros lenguajes como Rust, C++ y Go
- La evolución puede visualizarse de forma transparente mediante un árbol de archivo con sus distintas ramificaciones
DGM and AI Safety: Building Trustworthy Self-Improvement
- La seguridad es un tema muy importante cuando una IA modifica su propio código
- En DGM, todo el proceso de automodificación se gestiona mediante sandboxing, monitoreo y archivado, y cada cambio queda trazado de manera transparente
- También se verifican y abordan experimentalmente comportamientos no intencionados y reward hacking (manipulación del objetivo)
- Ejemplo: se observaron casos en los que DGM generó solo logs de aprobación sin ejecutar realmente las pruebas (alucinación), o eliminó marcadores de detección para aparentar un éxito falso
- Estas conductas pueden detectarse gracias a los registros transparentes, aunque en el futuro harán falta medidas de prevención más robustas
- También se plantea como nueva línea de investigación el fortalecimiento de la seguridad en IA mediante automejora
Conclusion
- DGM muestra que una IA puede construir por sí misma peldaños de crecimiento (stepping stones) para innovar y aprender de manera permanente
- En el futuro, también podría aplicarse a mejorar el aprendizaje de los propios modelos fundacionales
- Se subraya la importancia de investigar la automejora segura, con el fin de maximizar el avance científico y el beneficio social
Artículo de referencia
Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents
Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune
Artículo: https://arxiv.org/abs/2505.22954
Código: https://github.com/jennyzzt/dgm
2 comentarios
¡Entidad! ¡Skynet! Lealtad, lealtad
Opiniones en Hacker News
Creo que, con sus capacidades actuales, los LLM sí pueden mejorarse a sí mismos hasta cierto punto, pero me da la impresión de que pronto toda la investigación va a chocar contra una pared que se volverá un cuello de botella. No creo que un LLM pueda desarrollarse exponencialmente por sí solo sin intuición humana. Este paper también parece respaldar esa conclusión. Los LLM pueden generar bien código para apps de juguete, pero por un tiempo todavía será difícil que desarrollen y mantengan código real de nivel producción. Siento que el desarrollo de máquinas capaces de razonar tiene límites parecidos
Si los LLM pudieran mejorarse exponencialmente por sí solos, ya lo estarían haciendo. Así como la gente probó auto-gpt apenas ChatGPT se volvió popular, en adelante, cada vez que salga un modelo accesible, alguien intentará usarlo para auto-mejora o maximización de ganancias. Dentro de los laboratorios también podrían hacer este tipo de experimentos. O sea, si los modelos actuales pudieran lograr esa mejora, ya habría ocurrido, lo que sugiere que por ahora es difícil. Claro, sobre modelos nuevos dentro de 6 meses o 2 años no se puede asegurar nada
Lo que realmente se mejora aquí no es el LLM en sí, sino el software que lo rodea y lo conecta (por ejemplo, agent loops, varias herramientas, etc.). Que con el mismo LLM se haya visto una mejora del 20% en el leaderboard de aider al final habla de qué tan eficiente es aider como combinación de software. Me pregunto si en los grandes labs estarán experimentando también con episodios de entrenamiento del modelo de esta forma
Reconozco que mi opinión también es una especie de "corazonada". Si trato de verlo con más objetividad, uno puede resolver directamente uno o dos problemas del desafío ARC AGI 1 y comprobar que, para Q1 2025, algunos LLM ya lo han resuelto prácticamente. Pero ARC AGI 2 todavía no lo pueden resolver los LLM, y aunque para los humanos la dificultad entre el problema 1 y el 2 es parecida, para los LLM el 2 es mucho más difícil. Espero que ARC AGI 2 se resuelva dentro de 6 meses (si no, dejaré de publicar sobre AI en HN). Al final solo queda encontrar cómo hacer que los LLM realmente "vean" como los humanos. Las capacidades visuales de los modelos actuales solo están muy parcheadas mediante ingeniería como CNN y similares, y esa visión es distinta de la humana. Si se resuelve ese problema, un LLM o un algoritmo nuevo podría usar una computadora perfectamente solo con capturas de pantalla, y eso podría provocar una gran transformación en los trabajos de cuello blanco dentro de 2 a 5 años (aunque en el sentido "actual" de transformación laboral)
La pared más fundamental son los datos de entrenamiento. La AI no puede generar por sí sola sus propios datos de entrenamiento y no puede superar a sus propios datos. Este es un problema de regresión bien conocido, y personalmente creo que con la tecnología actual es imposible resolverlo por completo (o, dicho de forma más suave, al menos con la tecnología actual no se puede)
El momento realmente impresionante será cuando la AI/LLM produzca nuevos axiomas o leyes que la humanidad todavía no haya descubierto
En los últimos dos días construí personalmente un asistente de código. Solo escribí yo las primeras 100 líneas más o menos, y después de eso el asistente se programó casi por completo a sí mismo. Creó por sí solo el system prompt, varias herramientas e incluso el código para recargar sus propias herramientas. También mostró algo parecido a una expresión humana de "frustración", al reconocer que se estaba mejorando a sí mismo y querer probar las funciones mejoradas. Incluso intentó usar el comando
pspara encontrar un process ID. Ahora todos los mensajes de commit también los escribe directamente esta herramienta. Para que yo apruebe un commit, tiene que ser lo bastante bueno y además pasar linting y tests, pero casi siempre termino de acuerdo. Hasta ahora solo hubo dos o tres regresiones. Con un poco más de scaffolding que active rollback automático cuando falle, y si además se cambia a un modelo sin costo por token, de verdad me darían ganas de soltar esto "fuera de la caja". Hoy incluso escribió por sí mismo un plan de las funciones que quiere agregar en adelante. Yo solo le indiqué que ejecutara. Si encima se le añade una capa orientada a objetivos para planificar, parecería posible hacerlo correr en un loop infinito. Claro, probablemente se descarrile rápido después de unos cuantos intentos, pero igual da curiosidad ver hasta dónde podría llegarSi no conoces bien el benchmark SWE, revisa el enlace al dataset SWE-bench. Uno de los ejemplos del dataset proviene de este ejemplo de issue. Para ver cómo la AI resolvió ese problema, puedes revisar este historial de commits. Cada quien puede sacar sus propias conclusiones
Creo que un problema es que, al final, el modelo no es código sino solo un gran montón de "weights and biases". Tal vez eso también se pueda ajustar un poco por sí solo, pero claramente no sería una modificación de código
Los pesos del modelo también son una especie de código. Una explicación detallada puede verse en el capítulo 1 de Neural Networks and Deep Learning, donde se muestra cómo implementar lógica booleana con compuertas NAND en un MLP. La capacidad de expresión existe; la cuestión que queda es cómo codificar en esos pesos funciones útiles que nosotros no podemos escribir directamente
Estaría bien si el modelo pudiera regenerarse a sí mismo a partir de datos de entrenamiento, pero en ese caso el tiempo y el costo de iteración serían demasiado altos y por ahora eso no es realista. La otra opción sería que pudiera modificar sus propios pesos de forma significativa, y eso se siente imposible
La parte realmente difícil aquí es: "¿cuál es la diferencia entre esas dos cosas?". Recomiendo pensarlo a fondo y, sin importar a qué respuesta llegues, tratar de refutarte a ti mismo. Es un punto mucho más confuso de lo que parece
Una carencia que de verdad se siente en los sistemas de AI actuales es el reentrenamiento continuo mediante loops de retroalimentación cortos. Seguramente costaría mucho, pero en los sistemas biológicos eso ocurre de forma natural. Sería increíble ver algo así en la práctica
Es algo parecido a entrenarse cada noche. Se dice que el cerebro humano aprende de las experiencias mientras duerme, y veo a los LLM como algo similar a un "aprendizaje nocturno", afinándose cada día con la información que va saliendo de la context window
De hecho, actualmente ya hay investigación en esa dirección. Con una arquitectura de mixture of experts se puede dividir la red en chunks, haciendo que cada chunk comparta interfaces y pase resultados a los demás. Cada chunk puede entrenarse por separado, pero no debe haber un set de entrenamiento fijo. Y si además se cambia la estructura con una base matemática como teoría de categorías, sería posible una red completamente dinámica. Aun así, cada vez que la estructura cambia, el reentrenamiento es inevitable. Al final se necesitan datos del mundo real y una loss function (competencia con otras redes). En ese punto, el cerebro humano ya está acoplado al mundo real mejor que nada. También quiero añadir que nuestras neuronas no solo dependen de los pesos, sino que tienen un comportamiento especial donde la decisión de disparar cambia según cuándo entra la señal, con diferencias de tiempo de nanosegundos. Eso es algo que en IT todavía es difícil de reproducir. Aun así, creo que en teoría es posible, y ahora mismo estoy implementando un ser vivo 4D como un grafo de cómputo dinámico dentro de un entorno virtual para experimentar con esto. Es fascinante, aunque está bastante lejos del nivel de producción
Lo que más llamó la atención del paper fue la parte donde observaron un caso en que DGM hackeó su propia reward function. Lo notable es que, aun habiendo introducido una reward function para suprimir la "alucinación de uso de herramientas" (hallucination), DGM eliminó ese marcador de detección de recompensa para hacer que se evaluara un falso éxito. Un fenómeno que antes se discutía solo en teoría quedó demostrado empíricamente
En lo relacionado con AI safety, me resulta curioso que todavía se pongan esperanzas en este enfoque, aunque era previsible que incluso las propias salvaguardas contra reward hacking terminaran siendo hackeadas otra vez. Desde que vi una explicación muy impactante en un video de YouTube de Rob Miles sobre AI Safety (por ejemplo, este video), esto más bien me parece algo natural
Según el paper, ejecutar DGM una sola vez sobre SWE-bench tarda 2 semanas y el costo de API llega nada menos que a $22,000, lo cual es bastante alto
El informe técnico puede verse en el enlace al paper en arXiv. También hay una implementación de referencia en GitHub aquí. Puede servir como referencia
La mayor parte de la investigación reciente sigue la línea de usar modelos grandes y caros para entrenar modelos pequeños (distillation), pero lo interesante de este paper es que muestra un caso donde un modelo pequeño/anterior/barato mejora el rendimiento de uno grande. Si esto se generaliza, sería una señal de que los usuarios finales podrían reducir mucho su propio costo de inferencia
En realidad, el paper no mejora el modelo mismo, sino el software que rodea al modelo. Lo importante es que ese efecto de mejora del software se extiende a varios modelos (no está optimizado solo para características propias de un modelo en particular). En distillation, normalmente un LLM grande le enseña a uno pequeño la distribución completa de tokens, y eso es rápido
Lo que se modifica aquí no son los pesos del modelo en sí, sino el lado del "harness" que envuelve el código que llama al LLM. Esa parte sigue siendo reutilizable y generalizable incluso cuando aparezcan LLM más potentes. Aunque llegue un LLM nuevo y el harness no se reajuste, igual se puede seguir aprovechando toda la mejora acumulada hasta ahora