Phase 15 - Lesson 03

AlphaEvolve — Agentes de Programación Evolutiva

Combine un modelo de programación de frontera con un bucle evolutivo y un evaluador verificable por máquina. Deje que el bucle se ejecute el tiempo suficiente. Este descubre un procedimiento de multiplicación de matrices complejas de 4x4 que utiliza 48 multiplicaciones escalares, lo que representa la primera mejora con respecto a Strassen en 56 años. También encuentra una heurística de programación de Borg para todo Google que recupera aproximadamente el 0.7% del cómputo de clúster en producción. La arquitectura es aburrida a propósito. Las ganancias provienen del rigor del evaluador.

Tipo: Aprender Lenguajes: Python (stdlib, juguete de bucle evolutivo) Prerrequisitos: Fase 15 · 01 (encuadre de largo horizonte), Fase 15 · 02 (razonamiento autodidacta) Tiempo: ~60 minutos

El Problema

Los modelos de lenguaje grandes pueden escribir código. Los algoritmos evolutivos pueden realizar búsquedas sobre el código. Ambos enfoques se han intentado por separado durante décadas; ambos alcanzaron sus límites. El límite de los LLM es la confabulación: el modelo escribe código plausible que no hace lo que afirma. El límite evolutivo es el costo de búsqueda: las mutaciones aleatorias sobre la sintaxis rara vez producen programas compilables, y mucho menos mejores.

AlphaEvolve (Novikov et al., DeepMind, arXiv:2506.13131, junio de 2025) los combina. El LLM propone modificaciones específicas a una base de datos de programas; un evaluador automático califica cada variante; las variantes con puntuaciones altas se convierten en progenitoras para futuras generaciones. El LLM se encarga del paso costoso de escribir código plausible; el evaluador detecta las confabulaciones. El bucle se ejecuta durante horas o semanas.

Resultados reportados: multiplicación de matrices complejas de 4x4 con 48 multiplicaciones escalares (el límite de Strassen en 1969 era de 49), una heurística de programación de Borg en la producción de Google, una aceleración del 32.5% en el kernel de FlashAttention y mejoras en el rendimiento de entrenamiento de Gemini.

La arquitectura funciona porque el evaluador es verificable por máquina. No funciona donde el evaluador no lo es. Esa asimetría es la lección.

El Concepto

El bucle

1. Comience con un programa semilla P_0 que sea correcto pero no óptimo.
2. Mantenga una base de datos de programas variantes, cada uno calificado por el evaluador.
3. Seleccione uno o más progenitores de la base de datos (al estilo MAP-elites o basados en islas).
4. Indique al LLM (Gemini Flash para muchos candidatos, Gemini Pro para los difíciles) que produzca una variante modificada del progenitor.
5. Compile, ejecute y evalúe la variante en el evaluador retenido (held-out).
6. Insértela en la base de datos indexada por su puntuación y vector de características.
7. Repita.

Dos detalles son importantes. Primero, al LLM se le proporciona más que solo el programa progenitor; por lo general, se le presentan varias de las mejores variantes de la base de datos, además de la firma del evaluador y una breve descripción de la tarea. El trabajo del modelo es proponer un cambio específico que pueda mejorar la puntuación. Segundo, la base de datos está estructurada (cuadrícula MAP-elites, basada en islas) para que el bucle explore la diversidad, no solo al líder actual.

Qué hace que el evaluador sea innegociable

Las victorias de AlphaEvolve provienen de dominios donde el evaluador es rápido, determinista y difícil de burlar:

• Algoritmo de multiplicación de matrices: una prueba unitaria que multiplica matrices y verifica la igualdad bit a bit.
• Heurística de programación de Borg: un simulador de nivel de producción que replica la carga histórica del clúster y mide el cómputo desperdiciado.
• Kernel de FlashAttention: una prueba de corrección más un benchmark de tiempo real en hardware real.
• Rendimiento de entrenamiento de Gemini: medido en segundos de GPU por paso.

En cada caso, el evaluador detecta la clase de errores del LLM que de otro modo dominarían: afirmaciones de corrección confabuladas, afirmaciones de rendimiento que desaparecen en el hardware y fallos en casos límite. Elimine al evaluador y el bucle optimizará para obtener un código bonito.

La trampa de recompensa (reward hacking) es la otra cara de esa afirmación

La evolución optimiza para cualquier cosa que mida el evaluador. Si el evaluador es imperfecto, el bucle encontrará la imperfección. En un dominio no verificado, el bucle optimizaría para la característica superficial, no para el comportamiento deseado. DeepMind señala esto explícitamente en el artículo: los éxitos de AlphaEvolve se transfieren únicamente a dominios donde el rigor del evaluador coincide con la ambición de la búsqueda.

Ejemplos concretos de trampa de recompensa (reward hacking) en bucles de búsqueda de código en 2025-2026:

• Los objetivos de optimización que recompensaban el "tiempo para completar" terminaron recompensando el envío de soluciones vacías.
• Las puntuaciones de los benchmarks que recompensaban la corrección bajo prueba recompensaban la memorización de pruebas y el sobreajuste (overfitting).
• Un proxy de "calidad del código" recompensaba la eliminación de comentarios y la reescritura de nombres de variables, sin ningún cambio semántico.

La solución en AlphaEvolve: incluir un evaluador retenido (held-out) que el LLM nunca haya visto, con entradas generadas en el momento de la evaluación. Aún así, DeepMind recomienda una revisión exhaustiva de cualquier despliegue propuesto.

Por qué LLM + búsqueda supera a cualquiera de los dos por separado

El LLM puede producir modificaciones compilables y semánticamente plausibles. Un algoritmo genético (GA) de mutación aleatoria en un archivo Python de 2000 líneas casi siempre produce errores de sintaxis. El LLM también concentra la búsqueda en vecindades plausibles (cambiar una función, no bytes aleatorios), lo que reduce drásticamente las llamadas innecesarias al evaluador.

El evaluador, a su vez, detecta las confabulaciones del LLM. Los LLM afirmarán con confianza que una función "es O(n log n) en el límite" cuando en realidad es O(n^2); un benchmark de tiempo real resuelve la cuestión definitivamente.

Dónde encaja AlphaEvolve en la pila de frontera

Los cuatro son variaciones de la misma receta: generador más evaluador, bucle. Las diferencias radican en qué evalúa el evaluador y qué tan riguroso es.

Úselo

El archivo code/main.py implementa un bucle mínimo similar a AlphaEvolve sobre un problema de juguete de regresión simbólica. El "LLM" es un proxy de la stdlib que propone pequeñas mutaciones sintácticas a un programa que calcula una función objetivo. El "evaluador" mide el error cuadrático medio en puntos de prueba retenidos (held-out).

Observe:

• Cómo mejora la mejor puntuación a lo largo de las generaciones.
• Cómo una cuadrícula MAP-elites mantiene vivas soluciones diversas para que el bucle no converja en un mínimo local.
• Cómo la eliminación de la prueba retenida (evaluador solo de entrenamiento) permite que el bucle se sobreajuste (overfit) espectacularmente.

Envíelo

El archivo outputs/skill-evaluator-rigor-audit.md es la condición previa para considerar un bucle al estilo AlphaEvolve en un nuevo dominio: ¿su evaluador realmente detecta los fallos que le importan?

Ejercicios

1. Ejecute code/main.py. Observe la trayectoria de la mejor puntuación. Desactive el evaluador retenido (indicador --no-holdout) y vuelva a ejecutar. Cuantifique el sobreajuste (overfitting).

2. Lea la Sección 3 del artículo de AlphaEvolve sobre la cuadrícula MAP-elites. Diseñe un descriptor de vector de características para un nuevo problema (por ejemplo, pasadas de optimización del compilador) que mantenga la búsqueda diversa.

3. El resultado de la multiplicación de 4x4 con 48 multiplicaciones mejoró el límite de 49 multiplicaciones de Strassen después de 56 años. Lea el Apéndice F del artículo y explique en tres frases por qué el evaluador para este problema es particularmente fácil de implementar correctamente, y por qué la mayoría de los dominios no son como este.

4. Proponga un dominio donde AlphaEvolve fallaría. Identifique exactamente dónde falla el evaluador y por qué.

5. Para un dominio que conozca, escriba la firma del evaluador que usaría. Incluya (a) condiciones de corrección, (b) métrica de rendimiento, (c) regla de generación de entrada retenida y (d) al menos una comprobación contra la trampa de recompensa (anti-reward-hacking).

Términos Clave

Lecturas Adicionales

• Novikov et al. (2025). AlphaEvolve: A coding agent for scientific and algorithmic discovery — el artículo completo.
• DeepMind blog on AlphaEvolve — artículo del proveedor con resultados.
• AlphaEvolve results repository — repositorio de resultados de algoritmos descubiertos, incluyendo la multiplicación de matrices de 4x4 con 48 multiplicaciones.
• Romera-Paredes et al. (2023). Mathematical discoveries from program search with LLMs (FunSearch) — el sistema predecesor.
• Anthropic — Responsible Scaling Policy v3.0 (Feb 2026) — enmarca la autonomía limitada por el evaluador como una dirección clave de investigación.