Respuesta corta: qué logra Dream-RSI con el historial de búsqueda
Dream-RSI usa el historial de búsquedas pasadas de un agente como simulador para mejorar, sin experimentos nuevos, la política que decide qué explorar. En Lasso con Gemini-3.1-Pro, baja el tiempo promedio en seis datasets de 3587.1 a 2931.0 ms con 317 llamadas al agente en vez de 550 (Zheng et al., 2026, Google).
Motivación de Dream-RSI: explorar bien cuesta caro
Varios sistemas recientes usan un modelo de lenguaje como agente de descubrimiento (discovery agent): propone una solución en código, un evaluador la califica y el resultado alimenta el siguiente intento. AlphaEvolve, OpenEvolve y SimpleTES siguen ese ciclo. Los autores lo ubican dentro de la automejora recursiva (recursive self-improvement, RSI), donde un sistema usa su propia experiencia para mejorar.
Cuando la tarea es difícil, el ciclo se repite miles de veces. Ahí pesa la política de exploración (exploration policy): qué intento refinar, cuándo abrir una dirección nueva, cuántos intentos correr en paralelo y cuándo parar. Una mala política gasta llamadas al modelo en ramas que no llevan a nada.
Casi todos los sistemas usan una política diseñada a mano que no cambia durante la búsqueda. Según Zheng y sus coautores de Google, Google DeepMind, University of Maryland y University of Virginia, esa política no aprende de lo que ya se probó. Optimizarla en línea tampoco es sencillo, por dos razones. Primero, la señal llega tarde: para saber si una política es buena hay que verla dirigir muchos ciclos de propuesta y evaluación. Segundo, hay muchísimas políticas posibles, así que hay que probar muchas antes de encontrar una buena.
La salida que proponen viene del aprendizaje por refuerzo basado en modelos y de la línea de World Models y Dreamer: entrenar la política dentro de un simulador en lugar de interactuar con el mundo real. Dream-RSI cambia un detalle clave. El simulador no se aprende con una red neuronal: es el propio historial de búsqueda, que ya guarda cada decisión y su resultado.
Cómo funciona Dream-RSI: explorar, grabar y soñar
Dream-RSI agrega una capa ligera de orquestación encima del agente de descubrimiento. El agente, los modelos, el evaluador y las interfaces no cambian; lo único que se reescribe es el código de la política de exploración. El ciclo tiene tres pasos que se repiten en cada ronda.
El árbol de descubrimiento como simulador
Cada búsqueda deja un árbol de descubrimiento (discovery tree). La raíz $r$ es el espacio de trabajo inicial. Cada nodo $v$ es un intento: tiene un padre, hereda su espacio de trabajo y su contexto, y recibe un puntaje $s_v$ de un evaluador fijo. En cada ronda, la política mira el árbol y elige un lote de nodos para continuar, de la raíz o de las hojas. El lote no puede pasar de $W$ trabajadores en paralelo, y cada nodo elegido recibe un hijo nuevo.
En la exploración en línea, el agente genera de verdad cada hijo y el árbol terminado se guarda en el historial. En la repetición fuera de línea (replay), la política candidata usa exactamente la misma interfaz, pero en vez de generar un hijo, Dream-RSI revela el hijo que ya estaba grabado. Así una política distinta puede recorrer otras ramas, en otro orden, con otro paralelismo o detenerse antes, sin llamar al agente ni al evaluador. Ningún resultado fuera del árbol grabado se inventa. Los autores llaman a cada árbol un mundo de repetición (replay world), y a probar políticas ahí, soñar.
El puntaje de repetición
Cada política se repite varias veces con distintas preferencias de presupuesto $\rho$, desde muy ahorradora hasta muy exploradora. Cada repetición produce un punto calidad contra costo. La ecuación (1) del paper resume esos puntos en un número:
$$V_i^m := \underbrace{\frac{1}{B_i}\sum_{j=1}^{L_i^m}\left(\tilde a^m_{i,j}-\tilde a^m_{i,j-1}\right)\left(B_i-\tilde n^m_{i,j}\right)}_{\text{hipervolumen normalizado}} \;-\; \lambda\,\underbrace{\frac{1}{|\mathcal{R}|}\sum_{\substack{\rho\in\mathcal{R}\\ n^m_{i,\rho}>0}}\frac{k^{m,\star}_{i,\rho}}{n^m_{i,\rho}}}_{\text{penalización de paralelismo}}$$
- $V_i^m$: puntaje de la versión $m$ de la política en el mundo de repetición $i$.
- $B_i$: total de intentos evaluados en el árbol grabado (sin contar la raíz); normaliza el costo.
- $\tilde a^m_{i,j}$: calidad alcanzada, el mejor puntaje revelado dividido entre el mejor puntaje del árbol y recortado a $[0, 1]$.
- $\tilde n^m_{i,j}$: llamadas al agente que usó la repetición; los $L_i^m$ puntos son los no dominados de la frontera de Pareto, ordenados por costo.
- $k^{m,\star}_{i,\rho} / n^m_{i,\rho}$: rondas secuenciales por llamada. Si la política lanza intentos de uno en uno, vale cerca de uno; si llena los lotes en paralelo, baja.
- $\lambda$: peso de la penalización de paralelismo; $\mathcal{R}$ es el conjunto de preferencias de presupuesto.
La intuición: el primer término es el área bajo la frontera calidad contra costo, así que crece si la política llega a buenos resultados con pocas llamadas. El segundo castiga a las políticas que trabajan en serie, porque en la práctica el tiempo de reloj importa.
Mejorar la política soñando
Un agente desarrollador de políticas (policy-development agent, otro modelo de lenguaje) lee las trayectorias de repetición y sus puntajes, detecta decisiones que funcionaron y fallas recurrentes, y reescribe el código de la política. Cada versión nueva se evalúa en todos los mundos acumulados y se elige la mejor:
$$V^m = \frac{1}{t}\sum_{i=1}^{t} V_i^m, \qquad \pi_{t+1} = \pi_t^{m^\star},\quad m^\star \in \arg\max_{m\in\{0,\dots,M-1\}} V^m$$
- $V^m$: promedio del puntaje de la versión $m$ en los $t$ mundos del historial.
- $\pi_t^0$: la política que se usó en línea en la ronda $t$; siempre está entre las candidatas.
- $M$: número de versiones evaluadas por fase fuera de línea, incluida la actual.
Como la política actual compite contra sus propias revisiones, la elegida nunca queda peor que ella en el promedio de repetición. Ojo: esa garantía es sobre el simulador, no sobre la siguiente búsqueda real. La política ganadora se despliega en línea, genera un árbol nuevo y el conjunto de mundos crece.
Ejemplo visual de Dream-RSI en Lasso: menos llamadas y menos tiempo
El caso más claro es el de algoritmos. La tarea es descubrir un programa que calcule la ruta de regularización completa de Lasso más rápido, sin perder exactitud. Dream-RSI y la exploración fija (Recursive Fixed Exploration) arrancan con la misma política hecha a mano; desde la segunda ronda, solo Dream-RSI la cambia. La búsqueda usa las 17 instancias sintéticas de SimpleTES y corre 5 rondas. El programa final se mide en seis datasets externos, como RCV1 y Gisette.
El solver descubierto por Dream-RSI es más rápido en promedio con los dos modelos. La segunda gráfica muestra el costo de llegar ahí: Dream-RSI usó menos llamadas al agente de descubrimiento en ambos casos.
Resultados de Dream-RSI frente a la exploración fija
La comparación principal es contra la exploración fija, con el mismo agente, evaluador, inicialización y límite de presupuesto por ronda. El costo se mide como el número acumulado de llamadas al agente de descubrimiento.
Kernels de GPU
En cuatro tareas de KernelBench con Gemini-3.1-Pro, el puntaje es el inverso del tiempo de ejecución en una GPU NVIDIA L40S. En VGG16 y LayerNorm, Dream-RSI alcanza el desempeño final de la exploración fija con 2.43x y 1.79x menos generaciones. En ConvDiv y ConvMax, con presupuestos comparables, logra 2.09x y 1.44x más desempeño. A PACEvolve le dieron un tope de dos días de búsqueda y quedó por debajo en las cuatro tareas.
Optimización matemática
Con 10 rondas por tarea, Dream-RSI obtiene 1.145427 en el problema de suma y diferencia, frente a 1.144047 de la exploración fija y 1.143975 de SimpleTES. En empaquetamiento de círculos llega a 2.635983, el mismo valor que otros sistemas. En la desigualdad de autocorrelación (menos es mejor) obtiene 1.456375: peor que la exploración fija (1.456001) y que SimpleTES (1.453675).
Lasso en detalle
Con Gemini-3.1-Pro, Dream-RSI baja el tiempo promedio de 3587.1 a 2931.0 ms con 317 llamadas en vez de 550. Con Gemini-3.7-Flash, de 2516.7 a 2350.6 ms con 1879 llamadas en vez de 3200. Ambos solvers son más rápidos que sklearn (44180.3 ms en promedio) y glmnet (13767.5 ms). Frente a las 51,200 generaciones reportadas por SimpleTES, usan unas 162x y 27x menos llamadas, aunque con otros modelos.
Optimización de harness
Aquí el objetivo es mejorar el programa que rodea a un modelo fijo (harness). Con Claude Opus 4.8 y Claude Code, partiendo de Terminus-Kira, Dream-RSI sube el puntaje en Terminal-Bench 2.1 de 0.7247 a 0.8090. Cada harness se evalúa en las 89 tareas con dos corridas por tarea.
Análisis adicionales
En ConvDiv, repetir sobre todo el historial da 1.90 de desempeño contra 1.59 si solo se usa la ronda actual, aunque con 786 llamadas contra 430. Resumir el historial como guía en el prompt empeora a los dos métodos. La política aprendida reduce los intentos evaluados de 110 a 50 mientras mejora y vuelve a explorar cuando se estanca.
Limitaciones de Dream-RSI: qué no prueba el paper
- Mejoras que dependen de un solo dataset. Con Gemini-3.1-Pro, los autores reconocen que la mejora promedio en Lasso viene de RCV1 (de 19550.1 a 14616.0 ms) y que el solver es más lento en los otros cinco datasets.
- Sin varianza ni repeticiones. Cada configuración parece correr una vez; no hay semillas, desviaciones ni intervalos. Diferencias como 1.145427 contra 1.144047 pueden ser ruido.
- Controles incompletos. En harness no hay comparación con política fija porque otra búsqueda costaría más de 100,000 dólares, y Meta-Harness lo reprodujeron ellos mismos. Las comparaciones con SimpleTES o AlphaEvolve usan otros modelos.
- El simulador solo conoce lo ya explorado. Una política nunca recibe crédito por ramas que no se grabaron, así que la repetición favorece lo que la política anterior ya visitó. El paper no tiene sección de limitaciones que lo discuta.
Qué significa para ti Dream-RSI si construyes agentes de búsqueda
Si corres un bucle de propuesta y evaluación con modelos de lenguaje, ya sea para optimizar código, prompts o un harness, Dream-RSI te deja una idea práctica: guarda el árbol completo de intentos, con padre, contexto y puntaje de cada uno. Ese registro no es solo memoria para el siguiente prompt. Con él puedes probar fuera de línea reglas de orquestación (cuántas ramas abrir, cuánto paralelismo, cuándo parar) sin gastar una sola llamada nueva al modelo.
No necesitas un modelo de mundo aprendido. Basta con una interfaz común: la misma función de la política decide qué expandir en la búsqueda real y en la repetición. Así comparas políticas con el mismo código que después despliegas.
Tres cuidados antes de copiarlo. Primero, la repetición solo evalúa decisiones dentro de lo que ya grabaste; si la política nueva quiere explorar algo nunca visto, el simulador no lo puede calificar. Segundo, valida en línea la política elegida: la garantía de no empeorar es sobre el promedio en el simulador. Tercero, mide el costo en llamadas al modelo y en tiempo de reloj, no solo la calidad final, como hace el puntaje de la ecuación (1).
Los autores publican el código en github.com/zhengkid/Dream-RSI, y el apéndice del paper incluye los prompts completos de exploración y de mejora de la política. Si tu interés está en Lasso, el solver descubierto combina filtrado por la regla fuerte (strong rules) con poda de condiciones KKT; vale la pena leerlo antes de reemplazar a scikit-learn en tu propio pipeline.