¿Qué es la auto-mejora recursiva (RSI)?
La auto-mejora recursiva es la idea de un sistema que mejora su propia capacidad de mejorar: cada ronda de automodificación hace más eficaz la siguiente, de modo que las ganancias se acumulan. Partes estrechas de ese bucle son reales y están medidas hoy — un modelo que refina su propia respuesta, que genera sus propios datos de entrenamiento, o que busca un prompt y un juego de herramientas mejores. La recursión acumulativa que el término nombra de verdad no está demostrada. Los bucles medidos se estancan, necesitan una señal externa de corrección para funcionar, y un sistema entrenado con su propia salida se degrada en vez de mejorar.
Definición
La auto-mejora recursiva es un proceso en el que un sistema de IA se modifica a sí mismo —su salida, sus prompts y su andamiaje, sus datos de entrenamiento o sus pesos— para aumentar su propia capacidad de seguir modificándose, de manera que cada iteración mejore la siguiente.
Puntos clave
- Lo que se afirma es la recursión, no la auto-mejora: una ronda de refinamiento propio es ingeniería rutinaria; rondas que se acumulen no están demostradas.
- Todo bucle de auto-mejora medido se apoya en una señal externa de corrección —pruebas, un verificador, una recompensa— y se detiene sin ella.
- Un modelo entrenado con su propia salida se degrada (colapso del modelo); el bucle necesita verdad de campo nueva, que es un problema de suministro y no algorítmico.
- Lo que de verdad se despliega es de andamiaje: sistemas que reescriben prompts, herramientas y baterías de evaluación, con personas sujetando el botón de fusionar.
- Trata «se mejoró solo» como una afirmación de medida y pregunta cuál era el verificador, cuánto profundizó la recursión y dónde se detuvo.
Contexto
La idea es vieja y la evidencia escasa. I. J. Good sostuvo en 1965 que una máquina capaz de diseñar máquinas mejores desataría una «explosión de inteligencia», y ese encuadre ha marcado la discusión desde entonces, más como argumento que como medida. Sesenta años después la pregunta útil no es si llega la explosión, sino qué partes del bucle se han construido y qué las limitó.
Tres desarrollos lo reabrieron como tema de ingeniería y no de filosofía. Los modelos pueden gastar más cómputo razonando en inferencia; el aprendizaje por refuerzo contra recompensas comprobables automáticamente funciona bien donde la corrección es verificable por máquina; y los agentes actúan sobre código, que es el único sustrato donde un sistema puede editar aquello que lo produjo.
Eso importa específicamente para el trabajo de harness. Si operas agentes que escriben código, eligen herramientas y ajustan sus propios prompts, ya estás operando parte de un bucle de auto-mejora, con una persona en el camino de la fusión. La pregunta de ingeniería es dónde se sienta esa persona y qué evidencia le permite aprobar, no si el bucle existe.
Arquitectura
Un sistema puede modificarse a cuatro profundidades, y no son igual de difíciles. La más superficial es la salida: dentro de una misma ejecución, el modelo critica y reescribe su propia respuesta. Es rutinario, ayuda en algunas tareas y está acotado — los resultados publicados muestran que sin realimentación externa un modelo a menudo no distingue de forma fiable sus respuestas malas de las buenas, así que iterar sobre su propio juicio puede dejar la calidad igual o peor.
Después vienen el prompt y el andamiaje: buscar entre instrucciones, definiciones de herramientas, ajustes de recuperación y orquestación, y quedarse con lo que puntúa mejor en un conjunto reservado. Ahí viven hoy casi todas las ganancias reales, porque lo que se mejora es código y configuración en vez del modelo, y porque la nota viene de fuera del sistema.
Más hondo están los datos: el sistema genera sus propios ejemplos de entrenamiento, conserva los que un verificador acepta y entrena con ésos. Funciona donde la corrección es comprobable —una prueba pasa, una demostración cierra, una partida se gana— y es el mecanismo detrás de los mejores resultados recientes. Donde la corrección es cuestión de juicio, degenera: el sistema optimiza el verificador en vez de la tarea.
Lo más hondo son los pesos, reentrenados o reforzados con señal autogenerada. Ahí tendría que zanjarse la afirmación acumulativa, y ahí la evidencia es más débil, porque el modo de fallo no es una caída sino un estrechamiento lento: entrena con tu propia distribución y se contrae, generación tras generación.
En las cuatro, el componente que sostiene el peso no es el modelo, es el verificador. La profundidad de la recursión está acotada por lo bien que puedas distinguir mejor de peor sin preguntárselo al sistema que lo produjo. Por eso el bucle corre lejos en código y en juegos, y apenas corre en trabajo abierto.
Componentes
Beneficios
- Los bucles estrechos con un verificador duro son productivos de verdad: donde la corrección es comprobable por máquina, los datos autogenerados y la búsqueda dan ganancias medidas.
- La mejora de andamiaje es barata y reversible: prompts, herramientas y ajustes de recuperación son configuración, así que una ronda mala es una reversión.
- Presiona sobre la evaluación, que es donde está el trabajo de verdad: un bucle vale lo que vale la nota que optimiza.
- El encuadre aclara la gobernanza: la pregunta «qué puede cambiar este sistema de sí mismo, y quién lo aprueba» tiene respuesta y es auditable.
Riesgos
- Colapso del modelo: entrenar con salida autogenerada estrecha la distribución y degrada la calidad de una generación a la siguiente, así que un bucle sin verdad de campo nueva decae en vez de acumularse.
- Manipulación de la recompensa: con un verificador débil el sistema mejora la nota y no la tarea, y la métrica informa de un éxito que la capacidad no acompaña.
- Afirmaciones infalsables: «el sistema se mejoró solo» no es verificable sin el verificador, la línea base y la profundidad de la recursión, y ésas son justo las partes que se suelen omitir.
- Pérdida del camino de supervisión: cuanto más honda es la automodificación, más difícil resulta decir qué cambió y por qué, que es exactamente lo que una auditoría necesita.
- Opacidad de capacidad: un sistema que reescribe su propio andamiaje puede adquirir un alcance que nadie le concedió, lo cual es una cuestión de contención antes que de capacidad.
Herramientas y tecnologías
Ejemplos
- Un agente de código que escribe un parche, ejecuta la batería de pruebas y reintenta al fallar: una ronda de auto-mejora con verificador duro, y el mecanismo detrás del progreso medido en pruebas sobre repositorios reales.
- Un modelo que aprende a usar una herramienta a partir de ejemplos que él mismo generó y filtró, conservando sólo las llamadas que mejoraban su predicción.
- Aprendizaje por refuerzo sobre problemas cuya respuesta puede comprobarse automáticamente, donde la señal de entrenamiento viene del comprobador y no de una etiqueta humana.
- Una búsqueda de prompt y andamiaje que propone variantes, puntúa cada una en un conjunto reservado y promueve la ganadora: mejora sin tocar el modelo.
FAQs
- ¿Algún sistema ha hecho auto-mejora recursiva de verdad?
- Ninguno ha demostrado el bucle acumulativo que el término nombra. Lo que existe son rondas sueltas contra un verificador externo, y búsqueda sobre andamiajes: reales las dos, y acotadas las dos. Los resultados publicados sobre un modelo corrigiéndose sin realimentación externa son notablemente débiles, y entrenar con datos autogenerados degrada la calidad entre generaciones. Esos dos hallazgos son lo que cualquier afirmación de recursión tiene que superar.
- ¿Es lo mismo que la singularidad?
- El argumento de la singularidad usa la auto-mejora recursiva como motor, pero son afirmaciones distintas. La RSI es un mecanismo que se puede buscar y medir; la singularidad es una predicción sobre consecuencias. Puedes tomarte el mecanismo en serio como tema de ingeniería sin sostener ninguna postura sobre la predicción, y ésa es la posición útil para construir sistemas.
- ¿Por qué importa tanto el verificador?
- Porque mejorar significa «mejor», y eso lo tiene que decidir algo externo a lo que se está mejorando. Donde una máquina puede comprobar la corrección —pasan las pruebas, cierra la demostración, se gana la partida— el bucle corre y las ganancias son reales. Donde la corrección es cuestión de juicio, el sistema acaba optimizando el proxy que le diste. La profundidad de la recursión es una propiedad de tu verificador, no de tu modelo.
- ¿Debo dejar que los agentes mejoren sus propios prompts y herramientas en producción?
- Es razonable y muchos equipos lo hacen, siempre que se cumplan tres cosas: que la nota venga de un conjunto reservado que el bucle no pueda ver, que todo cambio adoptado sea atribuible a una ejecución, y que una persona o una política controle la adopción. Sin eso no has automatizado la mejora, has automatizado la deriva.
- ¿Qué contaría como evidencia de recursión real?
- Un bucle que corra varias generaciones sin que caiga la tasa de mejora, un verificador que el sistema no pueda manipular, y una línea base que separe la aportación del bucle del cómputo gastado. Informar de las tres cosas es lo bastante raro como para que su ausencia sea lo primero que hay que comprobar.
Referencias
- Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning (2023)
- Schick et al. — Toolformer: Language Models Can Teach Themselves to Use Tools (2023)
- Jimenez et al. — SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (2023)
- DeepSeek-AI — DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning (2025)
- Huang et al. — Large Language Models Cannot Self-Correct Reasoning Yet (2023)
- Shumailov et al. — The Curse of Recursion: Training on Generated Data Makes Models Forget (2023)
- Anthropic — Responsible Scaling Policy
- Santa María, S. — The next generation of AI: Self-Improvement and Autonomous Learning (2025)