Mejora automática recursiva en agentes de IA: lo que realmente muestran los experimentos
Un análisis detallado de las Máquinas de Gödel, STOP, el Agente de Gödel, SICA, la Máquina de Gödel de Darwin, SEAL y los Hiperagentes, así como de cómo determinar si un agente automodificable realmente mejora.
Fuentes: Can Artificial Intelligence Design a Better Artificial Intelligence?
Hoy en día es algo habitual pedir a un agente de programación que corrija un error en tu aplicación: abre archivos, edita unas pocas líneas y ejecuta el conjunto de pruebas. Si se cambia la instrucción a “mejorar el software que se utiliza para realizar este trabajo”, el objetivo pasa a ser el propio agente: cómo localiza los archivos, qué herramientas utiliza, cómo se recupera de un intento fallido y si la versión resultante puede generar una nueva mejora. Esa última pregunta es precisamente de lo que trata la auto-mejora recursiva (RSI). Este artículo distingue entre la automodificación y la verdadera auto-mejora, analiza los principales experimentos y sus resultados, y ofrece un conjunto de preguntas además de un pequeño diseño experimental para que puedas juzgar por ti mismo tales afirmaciones.
Automodificación, auto-mejora y recursión
Al pedirle a un modelo que verifique su respuesta, se puede obtener una contestación mejor, pero eso no hace que el modelo sea más capaz en la tarea siguiente. Solo ese resultado concreto cambió. Para razonar claramente sobre el RSI, es necesario distinguir tres niveles:
- Automodificación: alguna parte del sistema cambia.
- Auto-mejora: ese cambio genera un beneficio medible.
- Auto-mejora recursiva: la nueva capacidad refuerza precisamente el mecanismo que produce las mejoras posteriores.
Un caso concreto ayuda a entenderlo. Si un agente mejora en la búsqueda de archivos, termina las tareas con más facilidad; eso es auto-mejora. Si esa misma mejoría en la búsqueda también le permite comprender su propio código y, por lo tanto, mejorar al editarlo, el beneficio vuelve a integrarse en el proceso de mejora; ese es el aspecto recursivo.
También es importante a qué se refiere “el propio sistema”. Un sistema de IA desplegado rara vez es solo un modelo de lenguaje. El modelo se encuentra dentro de herramientas, memoria, instrucciones operativas y código de orquestación, y ese sistema circundante puede cambiar significativamente mientras los pesos permanecen fijos. La evolución en esa capa externa sigue siendo evolución, pero cualquier afirmación sobre auto-mejora debe indicar qué capa ha cambiado: los pesos, el código del agente, las instrucciones, las herramientas o el procedimiento de mejora en sí.
La Máquina de Gödel: demuestre los beneficios antes de cambiar
La Máquina de Gödel, propuesta por Jürgen Schmidhuber, es el marco matemático clásico. El sistema puede reescribir cualquier parte de su propio software, incluido el componente que busca pruebas, pero solo después de haber demostrado que esa reescritura aumenta la utilidad esperada según sus objetivos y suposiciones definidos.
Esa garantía es más limitada de lo que parece. No promete que cada cambio sea útil en el mundo real bajo cualquier condición; solo es válida con respecto a los axiomas elegidos, el modelo del entorno y la definición de utilidad. Encontrar una prueba formal de que una modificación determinada es beneficiosa también puede ser computacionalmente muy difícil.
Por lo tanto, la mayoría de los experimentos actuales siguen un enfoque empírico: en lugar de demostrar de antemano que un cambio es bueno, ejecutan el sistema modificado y miden su rendimiento. Eso es mucho más práctico, pero traslada la carga a la evaluación. La pregunta lógica que surge es si lo que se está midiendo realmente corresponde al tipo de crecimiento que nos interesa.
PARA: usar un mejorador sobre sí mismo
El Optimizador Autodidacta (STOP) parte de un “mejorador”, un programa que llama a un modelo de lenguaje para proponer y evaluar mejoras en otros programas. Luego, ese mejorador se aplica a su propio código fuente, y la versión actualizada se utiliza en la ronda siguiente para generar más mejoras.
El hallazgo notable es que el bucle no se comporta de la misma manera en diferentes modelos. Con GPT-4, el rendimiento promedio aumentó con las iteraciones; mientras que con GPT-3.5 y Mixtral disminuyó. Dado que el modelo de lenguaje subyacente nunca cambia, los autores dejan claro que su trabajo no constituye un RSI completo.
La lección para los profesionales es sencilla: iterar un proceso no garantiza progreso. Un método de mejora deficiente aplicado a sí mismo puede reforzar fácilmente sus propios errores en cada paso.
Gödel Agent: reescribiendo la propia lógica del agente
Gödel Agent permite que un modelo de lenguaje modifique la propia lógica de razonamiento y el código de comportamiento del agente en tiempo de ejecución. Se evalúa en comprensión lectora, matemáticas y respuesta a preguntas basadas en conocimientos, con optimización realizada en un conjunto de validación y el agente resultante medido en un conjunto de prueba separado, lo cual es la forma adecuada de evitar ajustes dirigidos específicamente al examen.
Los números principales requieren una lectura cuidadosa porque las variantes se ejecutan bajo condiciones diferentes. En MGSM, Meta Agent Search reporta una precisión del 53.4%, mientras que la variante restringida basada en Gödel alcanza el 64.2%, lo cual representa una comparación directa. La variante sin restricciones y sin Gödel llega al 90.6%, pero opera bajo diferentes limitaciones y no debería presentarse como el siguiente paso en la misma comparación.
Lo que destaca técnicamente no es tanto la puntuación como la elección de diseño: el método que utiliza el agente para resolver problemas se ha convertido en sí mismo en un software que puede ser buscado y modificado.
SICA: un agente de programación que edita su propia base de código
Un Agente de Programación AutoMejorador (SICA) concreta la cuestión. El agente modifica su propio código, y cada nueva versión se evalúa en función de cuán bien resuelve las tareas, cuánto tiempo lleva y cuál es su costo.
En 50 tareas seleccionadas al azar, manteniéndolas constantes de SWE-bench Verified, el rendimiento aumentó del 17% en la primera iteración a un pico del 53% en la iteración 14, y la iteración final alcanzó el 51%. En otras palabras, la mejora no fue monotónica. Los autores estiman que las 15 iteraciones costaron aproximadamente 7,000 dólares en uso de API.
Dos detalles atenúan la importancia del titular. Primero, los autores señalan que un límite de cinco minutos por tarea podría haber reducido la puntuación inicial, y gran parte de las mejoras iniciales se debieron a herramientas más rápidas para editar archivos que permitían al agente completar más trabajo dentro de ese mismo límite. Segundo, las mejoras descubiertas por el agente parecen ser tareas habituales de uso de herramientas: operaciones de edición precisas en lugar de reescribir archivos completos, y la búsqueda de funciones y clases mediante el análisis del árbol sintáctico (AST) del código en lugar de una búsqueda en texto plano.
Nada de esto hace que el resultado sea trivial, pero pasar del 17 % al 53 % no significa que la inteligencia general del sistema se haya triplicado. Lo que se midió fue el rendimiento en un conjunto específico de tareas, bajo un límite de tiempo determinado, y gran parte de las mejoras corresponde exactamente a lo que un ingeniero humano agregaría a la caja de herramientas de un agente de programación.
Máquina Darwin Gödel: un archivo en lugar de una sola línea
La Máquina Darwin Gödel (DGM) abandona la idea de una única cadena de versiones. Mantiene un archivo de variantes de agentes y permite que surjan nuevas ramas a partir de cualquiera de ellas. Una variante que obtiene una puntuación más baja hoy en día aún puede ser la progenitora de un cambio posterior y más útil, lo cual representa el elemento evolutivo y abierto en su nombre.
Según el artículo de la versión 3, las mejoras reportadas incluyen un aumento del 20% al 50% en la evaluación del subconjunto SWE-bench y del 14,2% al 30,7% en el benchmark completo Polyglot. El estudio también realiza experimentos de transferencia con otros modelos y benchmarks que no se utilizaron durante el desarrollo. Estos sugieren que algunas de las mejoras son generalizables más allá de las tareas de desarrollo, aunque no logran demostrar una mejora amplia en todos los dominios. Al igual que con el resto de los trabajos a nivel de agente, los modelos base permanecen inmutables; solo el software del agente que los rodea evoluciona.
El costo también forma parte del panorama. Los autores estiman que una ejecución de DGM en SWE-bench cuesta alrededor de 22,000 dólares, frente a unos 10,000 dólares por cada ejecución de la versión base. Por lo tanto, las pruebas que aíslan la contribución de cada componente individual no responden por completo si DGM seguiría siendo superior con un presupuesto igual.
La conclusión más aplicable se refiere a la estrategia de búsqueda: descartar todas las versiones que parecen representar una regresión puede bloquear el camino hacia un sistema mejor, ya que los diseños eficaces a veces pasan por etapas intermedias menos sólidas.
Cuando cambian los pesos o el mejorador
Los experimentos con códigos de agente no representan todo el campo. SEAL (Modelos de Lenguaje Autoadaptativos) estudia un modelo que genera sus propios datos de ajuste fino y directivas de actualización, incluyendo instrucciones sobre cómo debe realizarse la adaptación. El entrenamiento con esas directivas autogeneradas provoca cambios duraderos en los pesos del modelo, por lo que la investigación sobre la auto-mejora claramente no se limita al desarrollo de estructuras para agentes. Sin embargo, el hecho de que los pesos cambien por sí solo no indica ganancias ilimitadas o aceleradas.
Hyperagents aborda una limitación diferente. Combina al agente de tareas con el metaagente que lo edita en un único programa editable, de modo que el mecanismo encargado de generar mejoras futuras puede ser modificado también. Los autores indican que algunas de estas mejoras a nivel meta se transfieren entre dominios de tareas y se acumulan a lo largo de las ejecuciones. En conjunto, estos estudios desplazan el debate de “¿puede una IA editar su propio código?” a “¿hasta qué punto puede mejorar el proceso mediante el cual se desarrolla?”
Cuatro preguntas para cualquier afirmación de “mejoró”
Cuando la curva de auto-mejora asciende, vale la pena preguntarse qué es exactamente lo que aumentó.
Mejor en qué aspecto?
Puede aumentar la precisión, pero al mismo tiempo lo hacen el costo y la latencia. Un equilibrio aceptable para un objetivo de investigación puede ser inaceptable en un producto, por lo que es necesario analizar todas las métricas, no solo la más destacada.
¿Mejor en qué tareas?
Las mejoras en tareas que se utilizan repetidamente para elegir la próxima versión son pruebas menos sólidas que las mejoras en una prueba final no modificada durante el desarrollo. Cada vez que la puntuación de una prueba influye en otra decisión de selección, el proceso tiende a adaptarse a esa prueba.
¿Cuál versión es mejor?
Un archivo que conserva el mejor resultado mostrará una línea de “mejor hasta ahora” en ascenso, incluso si la mayoría de los nuevos candidatos son peores. Revise la distribución de los candidatos, no solo el valor máximo.
¿Está mejorando en su capacidad de mejora?
Resolver más tareas puede indicar una mejor capacidad de auto-mejora, pero se trata de métricas diferentes. Un experimento más riguroso verifica si una nueva versión genera versiones sucesoras mejores que las de su predecesor, con el mismo presupuesto.
Estas preguntas no tienen como objetivo negar el progreso. Sirven para definirlo con suficiente precisión como para poder reconocerlo.
Un experimento de auto-mejora que puedes llevar a cabo
Un punto de partida realista para un desarrollador individual o un equipo pequeño no es abrir todo el sistema a la automodificación, sino elegir una herramienta de desarrollo específica y restringirla estrictamente. Tomemos como ejemplo una herramienta de generación de pruebas para un código en Java:
- Arregla lo que no se puede cambiar: la herramienta no debe modificar el código de la aplicación ni las pruebas de evaluación.
- Define lo que sí se puede cambiar: solo su propia estrategia de escaneo de archivos, sus instrucciones y su flujo de trabajo para generar pruebas.
Considérelo como un diseño de experimento, no como una promesa de resultados. Utilizar modelos abiertos o cuotas gratuitas puede reducir los costos operativos, pero ejecuciones más económicas no demuestran que los cambios sean útiles. Busque primero un beneficio claramente medible y amplíe el alcance solo una vez que lo haya obtenido. La misma disciplina de evaluación se aplica a cualquier agente que implemente; nuestra guía sobre bucles de agencia limitados en TypeScript aborda el aspecto relacionado con el tiempo de ejecución para mantener dichos bucles bajo control.
Los agentes mejorados no representan una explosión de inteligencia
¿Puede entonces la IA diseñar una IA mejor? En los experimentos anteriores, sí, en un sentido específico: los sistemas de IA ayudaron a crear agentes más capaces, y varios aplicaron ese proceso a su propio software. Lo que no muestran es una cadena de mejoras que se acelere con cada iteración, se generalice a distintos dominios y funcione de forma independiente de las decisiones de diseño humanas. Descartar este trabajo como “solo ingeniería de prompts” pasa por alto los resultados reales; llamarlo el inicio de una explosión de inteligencia los exagera.
Puntos clave
- Siempre pregúntese qué capa cambió: pesos, código del agente, prompts, herramientas o el propio mecanismo de mejora.
- Las garantías formales como las de la Máquina de Gödel solo son válidas en relación con sus suposiciones; los enfoques empíricos intercambian pruebas por evaluaciones, por lo que la calidad de dichas evaluaciones lo determina todo.
El problema real no es permitir que una IA modifique su propio código, sino demostrar de manera fiable que dicha modificación representa un verdadero progreso y llevar ese progreso a la siguiente ronda de mejoras.
Lecturas relacionadas
- Qué predicen en realidad las leyes de escalamiento de LLM y hacia dónde se dirige el progreso — Aprenda cómo se aplican y utilizan las leyes de escalamiento de tipo ley de potencias en los LLM, por qué Chinchilla modificó los presupuestos de entrenamiento y por qué los modelos de razonamiento abren un nuevo enfoque para escalar el procesamiento.
- Verificar qué hacen los agentes de IA: permisos, puertas de aprobación y niveles de riesgo — Entienda por qué los agentes autónomos necesitan una mentalidad de verificación, y cómo el principio de mínimo privilegio, la aprobación humana y la autonomía basada en riesgos ayudan a contener sus errores.