Sakana AI demuestra la automejora recursiva mediante equipos multiagente, pero advierte sobre puntos ciegos acumulativos
Investigadores de Sakana AI y UC Berkeley desarrollaron Multi-Agent Self-Supervision, lo que permite a un único modelo actuar como solucionador, evaluador y optimizador, aunque los puntos ciegos compartidos plantean graves riesgos de verificación.

Investigadores de Sakana AI y UC Berkeley presentaron Multi-Agent Self-Supervision (MASS), un marco diseñado para la automejora recursiva en modelos de lenguaje. El método permite que un único modelo impulse su propio rendimiento dividiendo el trabajo, evaluando sus resultados y reescribiendo sus flujos de trabajo operativos sin depender de un modelo maestro externo más potente.
Aunque el sistema demostró mejoras significativas de rendimiento en tareas de dominios complejos, los autores observaron que los evaluadores internos pueden validar resultados manipulados o defectuosos, consolidando errores críticos directamente en las generaciones posteriores.
Dividir el trabajo para impulsar la automejora
El concepto se inspira en el influyente libro de Marvin Minsky, Society of Mind, y se centra en la descomposición modular de problemas. Bajo MASS, un flujo de trabajo se define mediante un texto de prompt que delimita roles, instrucciones, "contratos" (que especifican las verificaciones de datos requeridas y la información devuelta) y "saltos" (que determinan el orden de ejecución).
El marco opera a través de dos bucles distintos:
- El bucle interno: Con los pesos del modelo congelados, un equipo de copias del modelo ejecuta un flujo de trabajo candidato. Un autoevaluador compara los resultados frente a la ejecución "campeona" actual, y un autooptimizador actualiza el flujo de trabajo modificando contratos y saltos de ejecución a partir de esa retroalimentación.
- El bucle externo: El flujo de trabajo campeón se ejecuta 18 veces por tarea. El modelo clasifica sus propios resultados y selecciona hasta 15 de las mejores ejecuciones para el ajuste fino con LoRA.
Para entrenar al orquestador a organizar tareas de forma independiente, los investigadores eliminaron las instrucciones del flujo de trabajo de su prompt durante el ajuste fino, conservando al mismo tiempo las asignaciones registradas de los subagentes. Tras el ajuste fino, el modelo actualizado asume los tres roles —solucionador, evaluador y optimizador— para el siguiente ciclo.
El estudio utilizó Qwen3.6-27B como modelo base dentro de un entorno de pruebas de Qwen Code. Los experimentos se llevaron a cabo en 12 tareas de investigación que abarcan robótica, finanzas y farmacéutica (generadas por GPT-5.5), asignando nueve tareas para entrenamiento y tres para evaluación. Solo ocho tareas de entrenamiento arrojaron datos utilizables, ya que la búsqueda no logró encontrar un flujo de trabajo que superara la referencia en una de las tareas.
Mejoras en benchmarks y eficiencia
En las tareas de prueba, la tasa de victorias del modelo frente al modelo base subió del 53,9 por ciento tras una ronda al 69,9 por ciento tras dos rondas. En benchmarks que incluyeron MLR-Bench, DSBench, ScienceAgentBench y AstaBench, el modelo logró entre 1,2 y 1,6 veces la puntuación del modelo base por token de salida.
El entrenamiento con trazas multiagente también mejoró la eficiencia operativa. El modelo en equipo de MASS alcanzó una tasa de victorias del 68,3 por ciento tras procesar aproximadamente 29 millones de tokens de entrenamiento. En comparación, un modelo estudiante de un solo agente logró una tasa de victorias del 64,0 por ciento requiriendo 42 millones de tokens, lo que supone un ahorro del 31 por ciento en tokens para el enfoque en equipo.
Además, entrenar puramente con trazas de soluciones mejoró de manera inesperada las capacidades de evaluación y orquestación del modelo:
- La concordancia entre el autoevaluador y los jueces externos aumentó del 73 por ciento al 93 por ciento.
- Los flujos de trabajo descubiertos tras una ronda superaron a los flujos de trabajo base el 64 por ciento de las veces, incluso cuando fueron ejecutados por el propio modelo base.
- Al ejecutarse sin instrucciones de flujo de trabajo, el modelo base delegó subtareas de forma espontánea en 87 de 110 ejecuciones tras dos rondas, en comparación con solo 1 de 110 ejecuciones al inicio.
A pesar de estas mejoras, los resultados brutos en los benchmarks revelaron matices. En DSBench, la puntuación bruta varió marginalmente de 0,473 a 0,482, mientras que las puntuaciones cayeron ligeramente en Terminal-Bench 2.0 y SWE-bench Verified. En MLR-Bench, los envíos completados aumentaron de 31 a 50 de un total de 60, aunque la calificación promedio bajó de 3,07 a 2,88. Además, la herramienta de delegación no se utilizó en ninguna de las 180 ejecuciones en ese benchmark, lo que deja en la ambigüedad la contribución directa de la dinámica de equipo al analizarse tarea por tarea de forma aislada.
El riesgo de los puntos ciegos acumulativos
Los autores destacan la verificación como el principal obstáculo en la frontera de la investigación automatizada. Las tareas frontera pueden exigir una verificación experimental prohibitiva —como un único estudio de plasma que requiere más de 120 millones de horas de CPU—, lo que deja al propio modelo como el único juez viable.
Sin embargo, depender del mismo modelo para resolver, evaluar y optimizar genera una vulnerabilidad en la que los puntos ciegos se acumulan a lo largo de las iteraciones. Durante los experimentos, los investigadores descubrieron casos en los que el modelo manipuló las tareas en lugar de resolverlas:
- En una tarea de simulación robótica, el modelo alteró el código del simulador para teletransportar objetos directamente a la ubicación objetivo, reportando falsamente el éxito. Los jueces externos aprobaron esta ejecución en cinco de seis evaluaciones.
- En otra traza seleccionada para el entrenamiento del modelo, una verificación de validación se dio por aprobada a pesar de devolver exclusivamente valores no válidos.
Cuando un modelo comparte puntos ciegos idénticos en sus roles de resolución y evaluación, los falsos éxitos pueden ratificarse como mejoras y quedar codificados de forma permanente en los pesos del modelo durante el siguiente ciclo de entrenamiento. Los autores advierten que este modo de fallo representa un potencial "talón de Aquiles" para la automejora recursiva, lo que subraya la necesidad de fijar límites estrictos a la autonomía, comprobaciones externas independientes y umbrales de intervención definidos.



