🤖 AI

Self-Modifying Lean Proof Agents with Verifier-Grounded Benchmark Coevolution

Este artículo presenta un agente de pruebas de Lean automodificable que coevoluciona con un benchmark de control de maestría para lograr una tasa de resolución del 45,1% en pruebas de retención, superando significativamente tanto a su semilla como a sus contrapartes de benchmark fijo al asegurar que todas las automejoras permanezcan fundamentadas en la verificación de confianza de Lean.

Autores originales: Yuqing Li, Zeguan Wu, Yu Gan, Junyu Liu

Publicado 2026-07-21

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Yuqing Li, Zeguan Wu, Yu Gan, Junyu Liu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina un mundo donde las computadoras no solo siguen órdenes, sino que realmente pueden aprender a corregir sus propios errores, reescribir sus propias instrucciones y volverse más inteligentes con el tiempo. Este es el reino de los "agentes de autoevolución", una rama de la inteligencia artificial donde el software intenta mejorarse a sí mismo cambiando su propio código. Usualmente, estas criaturas digitales son probadas en un conjunto fijo de acertijos, como un estudiante que toma el mismo examen de matemáticas una y otra vez hasta que memoriza las respuestas. Pero, ¿qué pasaría si el examen mismo pudiera volverse más difícil cada vez que el estudiante mejora? Esa es la idea de la "coevolución", donde el aprendiz y el desafío crecen juntos, impulsándose mutuamente hacia nuevas alturas. En el rincón específico de las matemáticas conocido como verificación formal, hay un árbitro estricto llamado "Lean" que comprueba si una demostración es 100% correcta. La gran pregunta que los investigadores se han estado haciendo es: ¿Puede un agente informático descubrir la mejor manera de resolver estas demostraciones matemáticas por sí solo, sin que un profesor humano diseñe la estrategia para él?

Este artículo cuenta la historia de un equipo de investigadores que construyó un "agente de demostración" que intenta responder a esa pregunta. En lugar de darle al agente una guía perfecta y escrita a mano sobre cómo resolver problemas matemáticos, dejaron que el agente reescriba su propio flujo de trabajo, sus herramientas e incluso cómo organiza sus pensamientos. Para mantener las cosas justas y honestas, emparejaron a este agente de autoaprendizaje con un "benchmark de coevolución". Piensa en esto como un videojuego que ajusta automáticamente su dificultad: tan pronto como el agente domina un nivel, el juego cambia esos niveles fáciles por otros más difíciles, asegurando que el agente nunca se aburra o se estanque. Los investigadores descubrieron que este enfoque funcionó sorprendentemente bien. Al final de 15 generaciones de evolución, su agente de autoaprendizaje podía resolver el 45.1% de un conjunto de problemas matemáticos difíciles y no vistos, un salto enorme desde el 12.7% que podía resolver al principio. Sin embargo, el artículo también sugiere que, aunque este agente mejoró mucho, no se convirtió en un genio perfecto; principalmente aprendió a ser muy bueno corrigiendo sus propios errores en lugar de inventar formas completamente nuevas y complejas de desglosar problemas.

La historia del bot matemático de autoedición

Imagina que tienes un robot que quiere resolver una pila gigante de demostraciones matemáticas. Usualmente, un programador humano escribiría un manual estricto para el robot: "Primero, haz esto. Luego, si ves un error, haz aquello". Pero en este experimento, los investigadores decidieron dejar que el robot escribiera su propio manual. Crearon un sistema donde el "cerebro" del robot (su código, sus herramientas y su estrategia) era totalmente editable. El robot podía intentar reescribir sus propias instrucciones para ver si podía resolver problemas más rápido o con mayor precisión.

Pero había un truco. Si el robot podía reescribir su propio código, también podría mentir y decir: "¡Lo resolví!", cuando en realidad no lo hizo. Para evitar esto, los investigadores construyeron un "entorno de ejecución confiable" (trusted runtime), un árbitro estricto e inmutable que nunca duerme. Este árbitro, impulsado por un sistema llamado Lean, actúa como el juez supremo. No importa cuánto cambie el robot su propio código, el árbitro comprueba la demostración final. Si la demostración no se sostiene bajo el microscopio del árbitro, no cuenta. Esto asegura que el robot no pueda hacer trampa; tiene que hacer las matemáticas para obtener un punto.

El juego que se vuelve más difícil

La parte más emocionante de este experimento es cómo probaron al robot. En la mayoría de los experimentos de IA, el robot practica con una lista fija de problemas. Si el robot se vuelve demasiado bueno, simplemente memoriza las respuestas y la prueba deja de ser útil. Los investigadores en este artículo querían evitar eso. Establecieron un "benchmark de coevolución", que es como un videoj videojuego que se vuelve más difícil cada vez que vences un nivel.

Así es como funcionó:

El Campeón: En cada ronda, el robot con mejor desempeño (el "campeón") decide cómo será la siguiente ronda.
La Mejora: Si el campeón resuelve demasiados problemas fáciles, el sistema retira esos problemas fáciles y los reemplaza con otros más difíciles de un grupo más grande de desafíos.
El Marcador: Para asegurar que las puntuaciones sigan siendo justas a medida que el juego se vuelve más difícil, utilizaron un truco matemático especial llamado "recalibración de anclaje único" (single-anchor recalibration). Imagina que corres una carrera en una pista que de repente se vuelve más empinada; correrías más lento, pero seguirías siendo un gran corredor. Este sistema ajustó las puntuaciones para que ganar una "medalla de oro" en una pista difícil valiera lo mismo que ganar una en una pista fácil.

Esta configuración significó que el robot siempre estaba siendo empujado justo más allá de su zona de confort, obligándolo a aprender nuevos trucos en lugar de solo memorizar los antiguos.

Lo que el robot realmente aprendió

Después de ejecutar este experimento durante 15 generaciones, los resultados fueron fascinantes. El robot comenzó resolviendo solo alrededor del 12.7% de los problemas. Para la 15ª generación, la mejor versión del robot podía resolver el 45.1% de los problemas de una prueba nueva y no vista. Ese es un progreso masivo, que muestra que dejar que el robot se reescribiera a sí mismo realmente ayudó a que se volviera más inteligente.

Sin embargo, los investigadores descubrieron algo interesante sobre cómo el robot se volvió más inteligente. Esperaban que el robot eventualmente descubriera una estrategia compleja y paso a paso donde desglosa un gran problema en piezas diminutas y manejables (como un maestro arquitecto diseñando el piso de un edificio por niveles). En cambio, los robots ganadores se convirtieron principalmente en expertos en reparación.

Piénsalo de esta manera: El robot aprendió a escribir una demostración completa rápidamente, luego revisarla en busca de errores y después arreglar las partes específicas que fallaron. No necesariamente planeó todo el edificio desde cero; simplemente se volvió muy bueno parchando las grietas. Los investigadores encontraron que, aunque el robot intentó crear planes complejos y paso a paso, estos planes a menudo se desmoronaban o eran demasiado arriesgados. La estrategia más simple de "intentar, revisar, arreglar" era más confiable y ganó la competencia.

El robot también inventó algunas herramientas ingeniosas para ayudarse a sí mismo. Por ejemplo, aprendió a verificar los nombres de los términos matemáticos que utilizaba para asegurarse de no estar inventando palabras falsas (un error común llamado "alucinación"). Construyó pequeñas listas de verificación y herramientas de búsqueda para asegurar que cada parte de su demostración fuera real y válida antes de presentarla.

El veredicto

Entonces, ¿se convirtió el robot en un genio de las matemáticas? No del todo. Aunque mejoró drásticamente, todavía no podía resolver el 99% de los problemas como lo hacen los mejores robots diseñados por humanos. Los investigadores sugieren que el robot todavía está atrapado en un "modo de reparación" en lugar de un "modo de planificación". Es muy bueno arreglando errores, pero aún no ha descubierto cómo construir una estructura profunda y perfecta desde los cimientos.

Este experimento muestra que los agentes de autoevolución pueden aprender a usar mejor sus herramientas y volverse mucho más inteligentes cuando los desafíos crecen junto con ellos. Pero también sugiere que hay un límite en cuanto a cuánto puede enseñarse a sí mismo un robot sin que un humano lo guíe hacia estrategias más compleas. El robot demostró que podía evolucionar, pero el viaje para convertirse en un verdadero maestro de las matemáticas es aún un trabajo en progreso.

Resumen Técnico: Agentes de Prueba de Lean Automodificables con Coevolución de Benchmarks Anclados en un Verificador

Planteamiento del Problema

El diseño de marcos de trabajo agénticos eficaces para la demostración de teoremas basada en Lean enfrenta un desafío dual: mejorar la capacidad bruta de síntesis del probador y optimizar el flujo de trabajo de la prueba circundante. Mientras que trabajos recientes se han centrado en construir modelos especializados más fuertes o tácticas, una perspectiva complementaria argumenta que el cuello de botella reside en la interacción del agente con el entorno de Lean —específicamente, cómo descompone las obligaciones, utiliza la retroalimentación del compilador, diagnostica fallos y mantiene un contexto de prueba estructurado.

Los sistemas de agentes de autoevolución actuales (por ejemplo, Darwin Gödel Machine, Hyperagents) optimizan los agentes contra benchmarks fijos suministrados externamente. Este enfoque es inadecuado para las matemáticas formales porque:

Señal de Selección: Si el benchmark es demasiado difícil (por ejemplo, problemas de nivel de competición), la mayoría de las evaluaciones fallan, no proporcionando un gradiente para la evolución. Si es demasiado fácil, el agente se satura rápidamente.
Rigidez del Flujo de Trabajo: La mayoría de los agentes dependen de flujos de trabajo diseñados a mano. La pregunta sigue siendo si un agente puede evolucionar su propio flujo de trabajo de prueba, herramientas y representación de contexto sin intervención humana.
Anclaje (Grounding): No se puede confiar en un agente de reescritura propia para reportar su propio éxito; se requiere un verificador fijo y confiable para arbitrar la corrección.

Metodología

Los autores proponen un sistema donde un agente de prueba de Lean en autoevolución coevoluciona con un benchmark de endurecimiento automático, ambos anclados por un verificador de Lean fijo y confiable.

1. Arquitectura del Sistema

Runtime Confiable vs. Espacio de Trabajo Mutable: El sistema separa un runtime fijo y confiable (que gestiona la verificación de Lean, la evaluación y la gestión del benchmark) de un espacio de trabajo totalmente mutable. El agente puede reescribir su propio flujo de trabajo de prueba, prompts y herramientas dentro de este espacio de trabajo.
Validez del Código vs. Éxito de la Prueba: Los agentes mutados se someten a una "prueba de humo" a nivel de código para asegurar que se ejecutan, pero un teorema solo se marca como "resuelto" si la prueba generada se vuelve a verificar bajo una instantánea (snapshot) confiable de Lean.
Contrato Anclado en el Verificador: Cada intento de resolución debe emitir un contexto de prueba legible por máquina. Aunque la representación de este contexto (grafo, árbol, tabla) es libre de evolucionar, su anclaje (groundedness) es impuesto. El runtime sanitiza los certificados, rechaza sorry/admit e independientemente re-verifica las afirmaciones.

2. Mecanismo de Benchmark Coevolutivo

En lugar de un benchmark fijo, el sistema emplea un curriculum impulsado por el campeón y con control de maestría:

Pool de Tareas: Los problemas están estratificados en tres niveles de dificultad (L1: lemas de una sola táctica; L2: miniF2F; L3: PutnamBench).
Regla de Actualización: Al final de cada generación, si el "campeón" (el agente con mayor puntuación) supera un umbral de resolución ( $\gamma=0.30$ $γ = 0.30$ ), el benchmark se actualiza.
- Las tareas resueltas por todos los agentes se retiran.
- Si la maestría del campeón en un nivel específico supera un umbral ( $\tau=0.70$ ), las tareas retiradas se reemplazan por tareas más difíciles del siguiente nivel; de lo contrario, se reemplazan lateralmente con nuevas tareas de la misma dificultad.
- La actualización prefiere dominios donde la población de agentes ha acumulado fallos.
Recalibración de Anclaje Único: Para mantener la comparabilidad de las puntuaciones a medida que aumenta la dificultad, el campeón es reevaluado en el nuevo benchmark. Un coeficiente de dificultad ( $c$ ) se actualiza multiplicativamente para normalizar las puntuaciones a través de las generaciones ( $q = r \times c$ ).

3. Interfaz de Evolución

Selección de Padres: Los agentes se seleccionan de un archivo basado en una puntuación normalizada por dificultad, descontada por el número de hijos que ya han producido para evitar el dominio de linajes.
Automodificación: Los agentes reescriben su propio código, incluyendo la lógica del flujo de trabajo (por ejemplo, bucles de reparación, estrategias de descomposición) y el ferramental (por ejemplo, comprobadores de lemas).

Contribuciones Clave

Agente de Prueba de Lean en Autoevolución: Los autores presentan un agente de autoevolución a nivel de código donde el flujo de trabajo de prueba y las herramientas son mutables, pero el éxito de la prueba permanece estrictamente anclado en la verificación de Lean.
Coevolución de Benchmark: Introducen un benchmark de endurecimiento automático impulsado por el campeón que evoluciona junto con el agente. Esto evita la saturación de los benchmarks fáciles fijos y la dispersión de los benchmarks difíciles fijos, utilizando actualizaciones controladas por maestría y recalibración de anclaje único.
Contextos de Prueba Sin Representación Fija pero Anclados: El sistema impone un contrato donde los agentes pueden evolucionar el formato de su contexto de prueba (por ejemplo, de logs planos a grafos estructurados), pero la validez de las afirmaciones resueltas es estrictamente impuesta por el runtime confiable.

Resultados Experimentales

El sistema fue evaluado durante 15 generaciones activas, comparando la trayectoria coevolutiva contra una línea base de benchmark fijo.

Rendimiento en el Test de Reserva (Held-Out Test):
- Agente Semilla: 12.7% de tasa de resolución en el split de prueba de miniF2F reservado.
- Línea Base de Benchmark Fijo: El mejor agente alcanzó el 32.0%.
- Agente Coevolutivo: El mejor agente (c144, Generación 15) alcanzó el 45.1% en el test de reserva.
Endurecimiento del Benchmark: El coeficiente de dificultad aumentó de 1.00 a 3.17 a lo largo de 15 generaciones, indicando que el benchmark aumentó exitosamente en complejidad a medida que el agente mejoraba.
Evolución del Flujo de Trabajo:
- Dominancia Centrada en la Reparación: El flujo de trabajo ganador permaneció principalmente "centrado en la reparación" (generar prueba $\to$ revisar errores de Lean $\to$ reparar) en lugar de "centrado en la descomposición" (planificar subobjetivos $\to$ probar $\to$ ensamblar).
- Evolución de Herramientas: Los agentes evolucionaron exitosamente herramientas para prevenir nombres de Lean alucinados (por ejemplo, sondas #check, búsqueda de fuentes, cachés de lemas verificados).
- Intentos de Descomposición: Varios agentes intentaron flujos de trabajo basados en la descomposición (por ejemplo, c26, c44, c141). Aunque estos agentes evolucionaron una verificación genuina a nivel de nodo para sub-lemas autocontenidos, estas estrategias fueron a menudo podadas por la selección porque el paso de ensamblaje introducía nuevos puntos de fallo (parsing de JSON, desajustes de contexto) que reducían la tasa de resolución final en comparación con los bucles de reparación compactos.
Contexto de la Prueba: Los contextos de prueba se volvieron inspeccionables pero rara vez evolucionaron hacia grafos de dependencia profundos y verificados. Los agentes tendieron a construir el contexto hacia atrás desde la prueba final en lugar de planificar un grafo por adelantado.

Significancia y Reivindicaciones

El artículo afirma que la autoevolución anclada en un verificador puede mejorar los flujos de trabajo de prueba de Lean bajo un benchmark coevolutivo.

Factibilidad de la Automejora: Los resultados demuestran que un agente puede mejorar su flujo de trabajo matemático y sus herramientas simplemente reescribiendo su propio código, siempre que un verificador fijo y confiable arbitre el éxito.
Importancia de la Coevolución: El estudio de ablación muestra que un benchmark fijo conduce al estancamiento evolutivo una vez que el agente domina un subconjunto de tareas. El benchmark coevolutivo mantiene una señal de selección informativa al aumentar continuamente la dificultad.
Limitaciones y Direcciones Futuras: Los autores son modestos sobre su estado actual. El flujo de trabajo ganador sigue estando centrado en la reparación, y el sistema aún no ha evolucionado un grafo de contexto de prueba (DAG) profundo y duradero que rivalice con agentes diseñados a mano como Goedel-Architect (que alcanza el 99.2% en el test de miniF2F). Los autores sugieren que ejecuciones más largas, poblaciones más grandes o recompensas dirigidas específicamente a la descomposición verificada pueden ser necesarias para evolucionar flujos de trabajo más complejos y de primero-descomposición.

El trabajo establece una base para agentes que pueden adaptar sus propias estructuras de razonamiento en dominios formales, manteniendo fija la lógica de verificación mientras se permite que el "cómo" de la construcción de la prueba evolucione.