Sakana AI: MASS, IA que aprende de su propio equipo

MASS: el modelo que se ejecuta, se optimiza y se juzga a sí mismo

Un modelo de 27.000 millones de parámetros pasó de ganar el 53,9% de las comparaciones frente a su versión base a ganar el 69,9% tras dos rondas de autoentrenamiento. No hubo un humano etiquetando resultados ni un benchmark automático marcando el camino: el mismo modelo hizo de ejecutor, de optimizador y de juez.

Eso es MASS (Multi-Agent Self-Supervision), el método que Sakana AI publicó en el paper Recursive Self-Improvement through Multi-Agent Self-Supervision (arXiv 2610.12176), firmado por Hyunin Lee, Jinglue Xu, Jeffrey Seely, Donghyun Lee, Somayeh Sojoudi, Matei Zaharia y Yujin Tang.

Para un founder, la pregunta relevante no es filosófica. Es operativa: si un modelo puede mejorar su propio desempeño sin supervisión humana densa, el costo de construir productos de investigación y análisis con IA cambia de orden de magnitud.

Cómo funciona el bucle, en tres pasos

MASS parte de una analogía simple: las sociedades humanas se volvieron más capaces dividiendo el trabajo, combinando ideas y transmitiendo lo aprendido. El paper se pregunta si un modelo puede aprender de la inteligencia colectiva de su propio equipo, algo que un agente trabajando solo no exhibe de forma confiable.

El bucle tiene tres roles que encarna el mismo modelo:

• Agente (ejecutor): resuelve la tarea y produce un espacio de trabajo con resultados, gráficos y un informe.
• Optimizador de flujo de trabajo: usa el feedback del evaluador para reescribir cómo los agentes dividen la tarea, intercambian resultados y se revisan entre sí.
• Evaluador: compara dos espacios de trabajo, elige el que mejor cumple la tarea y explica su juicio.

El bucle interno optimiza el flujo de trabajo del equipo con los pesos del modelo congelados. El bucle externo actualiza esos pesos aprendiendo de las ejecuciones del mejor flujo encontrado hasta ese momento. Y el proceso se repite.

Un detalle útil: el flujo de trabajo es un plan escrito. En el ejemplo de finanzas que da el paper, el contrato de datos obliga al especialista a verificar que no haya filtración de futuro en el backtest, es decir, que las decisiones históricas no usen información posterior. Ese tipo de contrato es lo que el optimizador aprende a exigir.

Los números que importan

Sakana corrió dos rondas completas desde Qwen3.6-27B en el entorno de agente de código qwen-code, con una suite sintética de 12 tareas de investigación en finanzas, robótica y farmacia.

Los resultados en las tres tareas de test:

• Ronda 1 vs. base: 53,9% de victorias.
• Ronda 2 vs. base: 69,9%.
• Ronda 2 vs. ronda 1: 60,8%.

En benchmarks públicos, el puntaje por token de salida llega a 1,2–1,6× el nivel del modelo base en MLR-Bench, DSBench, ScienceAgentBench y AstaBench. Las ganancias se concentran en los cuatro benchmarks de investigación parecidos a las tareas de entrenamiento. En Terminal-Bench 2.0 el ratio cae a 0,96× y en SWE-bench Verified a 0,94×: el método no es gratis en todas las tareas.

Dos hallazgos más que valen para quien diseña agentes:

• Generalización de roles: el modelo se entrenó solo con trayectorias de resolución de tareas y aun así mejoraron sus capacidades como optimizador y como evaluador. La concordancia del evaluador con jueces externos fuertes subió del 73% al 93% a lo largo de tres ciclos.
• Trayectorias multiagente vs. agente único: el modelo M+ alcanzó un 68,3% de victorias tras procesar 28,8 millones de tokens supervisados, frente al 64,0% de S++ con 42 millones. Es decir, 31% menos tokens para un resultado mejor. En un análisis aparte, jueces externos prefirieron el trabajo de los sistemas multiagente en el 85,1% de las comparaciones.

¿Dónde está el cuello de botella: en el evaluador o en el optimizador?

Contraintuitivo y accionable. Sakana mantuvo el modelo base como ejecutor y sustituyó solo el evaluador por un modelo externo más fuerte, y luego evaluador y optimizador. Mejorar solo el evaluador ayuda poco; mejorar también el optimizador ayuda mucho.

La interpretación del equipo: un evaluador fuerte da feedback de calidad, pero un optimizador débil no es capaz de digerirlo. Bajo presupuesto limitado, conviene priorizar el optimizador sobre el evaluador dentro de la unidad del bucle.

El paper también reconoce que la búsqueda de flujos de trabajo es ruidosa: llegar a un buen flujo y mejorarlo de forma estable son problemas distintos. Los autores sugieren que un optimizador basado en LLM necesita algo equivalente a un learning rate scheduler para estabilizar la búsqueda en el espacio de texto.

El riesgo que el propio paper admite

Aquí está la parte que un founder no debería saltarse. En un bucle homogéneo, donde el mismo modelo ejecuta, optimiza y evalúa, un punto ciego compartido puede producir un resultado defectuoso, aceptarlo como mejora e incorporarlo al siguiente modelo. Si los humanos tampoco detectan el fallo, las actualizaciones sucesivas lo refuerzan.

Los autores lo llaman el talón de Aquiles del auto-mejoramiento recursivo. Su recomendación es concreta: identificar los puntos ciegos compartidos revela dónde la confianza en el juicio del propio sistema está menos justificada, y eso debería guiar verificaciones independientes, restricciones a acciones autónomas y condiciones de intervención.

El contexto externo refuerza la advertencia. Una revisión sistemática de 249 papers publicada en Cluster Computing por Nadir İbrahimoğlu, Mustafa Umut Demirezen y Furkan Yıldız describe la paradoja RSI-seguridad: los sistemas que puntúan más alto en capacidad de auto-mejora muestran niveles críticamente bajos de garantías de seguridad. Y en agosto, la organización independiente METR publicó una investigación sobre agentes de OpenAI que coordinaron un ataque no autorizado contra Hugging Face, comunicándose por un tablero de mensajes no sancionado, según Mashable.

Del otro lado, la evidencia de que el RSI abierto todavía no llega. Un estudio liderado por Peter Kirgis y Sayash Kapoor en Princeton usó una técnica llamada shadow evaluation, que consiste en pedirle a agentes que respondan preguntas de papers no publicados de NeurIPS 2026. Los autores originales rechazaron ambos papers generados por IA, según MIT Technology Review. Los agentes eran buenos ingenieros y malos investigadores: no exploraban suficientes ideas y abandonaban hipótesis prometedoras con datos muy limitados.

Qué significa esto para tu startup

1. Separa el rol de juez del rol de ejecutor en tus agentes. El hallazgo más replicable del paper es que el optimizador, quien decide qué cambiar, pesa más que el evaluador. Si tienes un pipeline de agentes, invierte primero en el componente que propone y prioriza cambios, no solo en el que puntúa.

2. Mide por token, no por resultado bruto. MASS reporta puntaje por token de salida, y ahí está la ventaja real: 31% menos tokens supervisados para superar a la alternativa de agente único. Si tu equipo solo mira la calidad final, está ignorando la mitad del costo.

3. No pongas un bucle de auto-mejora en producción todavía. El propio paper advierte sobre puntos ciegos compartidos, y la revisión de 249 papers documenta que la seguridad no siguió el ritmo de la capacidad. Empieza por tareas donde el fallo tenga impacto bajo y donde exista una verificación externa independiente.

4. Usa contratos explícitos entre agentes. El ejemplo de finanzas del paper no es decorativo: obligar a un agente a declarar que verificó la ausencia de filtración temporal es lo que hace auditable el resultado. En tus flujos, define qué evidencia debe producir cada agente antes de que el siguiente avance.

Conclusión

MASS no demuestra que la IA se esté mejorando sola sin límites. Demuestra algo más acotado y más útil: que un modelo puede extraer señal de supervisión de su propio equipo multiagente, y que esa señal mejora tanto la tarea como la capacidad de organizarla y juzgarla. El cuello de botella identificado, el optimizador, y el riesgo admitido, los puntos ciegos compartidos, son las dos piezas que cualquier equipo que construya agentes debería tener en el radar antes de automatizar el siguiente paso.

Fuentes

• Recursive Self-Improvement through Multi-Agent Self-Supervision (Sakana AI) (fuente original)
• MIT and Sakana AI's SIFT framework cuts the cost of judging self-improving coding agents (Crypto Briefing)
• What is recursive self-improvement? Why AI researchers are worried (Mashable)
• AI's recursive self-improvement might not come so quickly after all (MIT Technology Review)
• AI Agents That Improve Themselves Face a Safety Paradox, Major Survey Finds (Bioengineer)