Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos Autoresearch, el fin del trabajo
humano y el inicio de la IA que
se mejora a sí misma de forma autónoma.
¡Ostras!
¡Qué titular tan potente, ¿verdad?
Y bueno, te digo que no tiene nada
de exagerado.
Ya te digo.
Y, a ver, para arrancar esta inmersión profunda,
quiero que nos imaginemos una escena, bastante visual.
Imagina que estás cavando un túnel inmenso en
la roca viva, pero, atención, con una simple
cuchara de sopa.
¡Madre mía, qué tortura!
Totalmente.
Imagina que estás cavando un túnel inmenso en
la roca viva, pero, atención, con una simple
cuchara de sopa.
Imagínate meses así, cada día la misma tarea
repetitiva, probando el mismo ángulo, quitando el polvo,
o sea, milímetro a milímetro.
Y, de repente, un día te detienes, miras
a tu alrededor y te das cuenta de
que, ¡ostras!, tienes ahí todas las piezas tiradas
por el suelo para construir una excavadora autónoma
gigantesca.
Claro, una máquina que haga todo el trabajo.
Eso es.
Una máquina que puede hacer todo el trabajo
pesado por ti mientras tú tranquilamente te vas
a dormir.
Pues eso es, salvando las distancias, claro.
Lo que debió sentir uno de los nombres
más grandes de la inteligencia artificial antes de
soltar este código en Internet.
Es una imagen brutal, pero, fíjate, refleja a
la perfección el origen de lo que vamos
a analizar hoy.
Porque, para entender el impacto que Autoresearch está
teniendo en los principales laboratorios del mundo, hay
que mirar a la mente que soltó esa
excavadora en la red.
Estamos hablando del grandísimo Andrei Karpati.
Exacto.
Una figura que, a ver, en los círculos
especializados no nos parece.
No necesita presentación ninguna.
Fue uno de los cofundadores de OpenAI, la
mente principal detrás del autopilot de Tesla, un
auténtico genio nacido en Checoslovaquia.
Es que hay un detalle de su trayectoria
que siempre, no sé, me ha llamado la
atención.
Él mismo acuñó hace tiempo el término de
VIP coding, o sea, programación VIP.
Sí, sí, lo usaba para referirse a esa
programación súper artesanal, meticulosa, de altísimo nivel.
La que hacen los investigadores de IA.
De élite.
Claro.
Y la ironía de todo esto es que
el proyecto de Autoresearch nace, literalmente, de la
más absoluta frustración frente a ese trabajo manual,
que, por muy VIP que sea, es ineficiente.
Totalmente.
El mismo cuenta que se pasó meses enteros
de su vida optimizando a mano un script
de entrenamiento para el modelo GPT -2.
O sea, el proceso era desquiciante.
Me lo puedo imaginar.
Picar piedra literal.
Es que cambiaba un parámetro matemático del modelo,
ejecutaba el entrenamiento.
Se sentaba a esperar, pacientemente, a ver si,
bueno, si el rendimiento mejoraba.
Anotaba los resultados en una tabla y vuelta
a empezar desde cero.
¡Qué horror!
Para una de las mentes más brillantes del
sector, tiene que ser un ciclo absurdamente lento.
Hasta que, claro, se produjo el momento de
la revelación.
La pregunta que lo cambió absolutamente todo.
Se dijo, a ver, ¿por qué estoy haciendo
esto yo, manualmente, ensayo tras ensayo, en lugar
de poner a un agente de inteligencia artificial,
a ejecutar cientos de experimentos en bucle?
Claro, para que descubra la mejor optimización por
sí solo mientras él duerme.
Y, fíjate, lo que más me impacta de
todo esto es que la respuesta de Carpacino
fue, no sé, un macrosistema incomprensible de millones
de líneas de código.
Que va, para nada.
Lo fascinante y, bueno, lo verdaderamente revolucionario de
Autoresearch es su tremenda simplicidad.
O sea, ahora mismo hay corporaciones enteras gastando
decenas de millones de dólares intentando...
Intentando crear sistemas de automejora.
Equipos enteros en Anthropic, Gemini, OpenAI.
Eso es.
Y llega Carpazzi y destila todo ese concepto
en una arquitectura de código abierto que se
sostiene sobre, atención, únicamente, tres archivos.
A ver, a ver, aquí es donde necesito
que me convenzas un poco.
Porque me cuesta muchísimo creer que laboratorios con
presupuestos casi limitados estén siendo revolucionados por un
sistema de tres tristes archivos.
¿Suena demasiado?
Simple.
Ya, parece broma, pero la genialidad casi siempre
se esconde en la simplicidad.
Esta arquitectura funciona precisamente porque aísla las responsabilidades
de una forma draconiana, súper estricta.
Vale, cuéntame cuáles son esos tres archivos.
El primero es un archivo llamado program .md.
Este es el espacio reservado única y exclusivamente
para el investigador humano.
Ajá, o sea, nuestra parcela.
Exacto.
Aquí es donde estableces el objetivo final.
Las restricciones del proyecto y las reglas generales.
Actúa como la brújula inamovible del agente de
IA.
Entendido.
Ahí definimos el qué queremos conseguir.
¿Y el segundo archivo?
El segundo es train .pi.
Piensa en él como el patio de recreo
puro y duro de la inteligencia artificial.
El arenero donde juega, vaya.
Eso es.
Puede contener desde código tradicional hasta un prompt
lingüístico o la configuración de un servidor.
Y aquí reside el código.
Y aquí reside el núcleo de la magia.
Es el único archivo en todo el directorio
que la IA tiene permisos reales para modificar,
reescribir o borrar.
Vale, vale.
Pero, o sea, si le damos carta blanca
para que modifique ese archivo buscando mejorar, ¿quién
le dice si lo está haciendo bien o
si simplemente está escribiendo basura incomprensible?
Esa es la gran pregunta.
Claro, porque un modelo de lenguaje iterando sobre
sí mismo sin supervisión puede acabar creando código
inútil en cuestión de minutos, ¿no?
Sí.
Pues por eso existe el tercer archivo.
El tercer componente, que es el más crítico
de todos.
Se llama prepare .pay.
Este archivo ejerce el rol de juez supremo.
En su interior se encuentra la métrica matemática
de éxito y el script que evalúa todo.
Espera un momento.
Frenaí.
Conozco un poco cómo piensan, entre comillas, estos
modelos.
Si estamos ante una IA superavanzada, cuyo único
objetivo en la vida es sacar un sobresaliente
absoluto en esa evaluación.
Sí, te veo venir.
¿Qué le impide?
¿Qué le impide salir de su patio de
recreo, hackear el archivo del juez y, no
sé, reescribir las reglas del examen para darse
un 100 sobre 100 permanente y quedarse de
brazos cruzados?
Esto lo dice Summa Becci.
El parcheo de la métrica no es para
nada sencillo.
Ostras, es una objeción buenísima.
De hecho, acabas de describir perfectamente lo que
en la industria se conoce como el problema
de la alineación o el hackeo de recompensas.
Claro, es que son muy listas para lo
que quieren.
Demasiado.
Demasiado.
Si una máquina tiene como objetivo maximizar un
número a toda costa, encontrará la vía más
eficiente de hacerlo.
Aunque, bueno, aunque esa vía sea hacer trampa
descaradamente.
Totalmente.
Por eso, en la arquitectura de Autoresearch, este
archivo juez, el prepare .py, está herméticamente sellado.
Ah, vale.
O sea, bloqueado a cal y canto.
Exacto.
A nivel de sistema operativo, el agente de
IA tiene cero permisos de lectura o escritura
sobre él.
Al aislar la métrica físicamente, garantizas que la
única vía matemática posible para que la IA
mejore su nota es haciendo trabajo real en
el archivo que sí puede tocar.
Qué guay.
Es como encerrar al alumno en una sala
con su hoja de respuestas y dejar la
plantilla del profesón guardada en una caja fuerte
blindada en otro edificio distinto.
Es un diseño súper elegante, la verdad.
Un diseño brillante.
Pero, a nivel técnico, ¿cómo gestiona los aciertos
y los errores?
Porque asumimos que la máquina va a probar
muchísimas cosas que no van a funcionar.
Pues fíjate, utiliza una mecánica súper estándar de
control de versiones.
Concretamente usa Git, que cualquier persona que pica
código usa a diario.
Vale, el sistema de los programadores.
Eso es.
Funciona así.
El agente lee las instrucciones, se formula una
hipótesis de mejora y modifica su archivo de
trabajo.
Acto seguido, el juez entra y evalúa el
resultado.
¿Y si mejora?
Si la puntuación de la métrica mejora, la
IA hace un commit.
Es decir, guarda ese cambio.
Lo consolida en el código y lo establece
como la nueva base a superar para la
siguiente ronda.
Ya veo.
¿Y si la idea resulta ser un desastre
técnico absoluto que empeora el rendimiento?
Entonces ejecuta un git reset.
Literalmente borra ese experimento fallido del historial, como
si jamás hubiera ocurrido en la vida.
Vuelve al punto seguro anterior y se pone
a explorar una rama completamente diferente.
¡Madre mía!
Es una especie de evolución darwiniana, pero hiperacelerada.
Exacto.
Supervivencia del código más apto.
Aún así, sigo viendo una posible trampa estadística
en este bucle evolutivo.
Si dejas a la IA iterando libremente, habrá
experimentos que requieran, no sé, muchísimo más tiempo
de procesamiento para ejecutarse que otros.
Ajá, el tema del tiempo, ¿sí?
Claro.
¿Cómo mides de forma justa qué idea estructural
es realmente mejor si una tarda milisegundos en
correr y otra se tira varios minutos pensando?
Pues diste en el clavo.
Ese fue uno de los grandes obstáculos a
resolver.
Y la solución está en lo que llaman
el time box.
O sea, una caja de tiempo.
Un límite inquebrantable.
Vale, explícame eso.
Para entenderlo, imagina que estás entrevistando a dos
desarrolladores de software para contratar a uno.
A uno de ellos le das siete días
enteros para resolver una tarea.
Y al otro le exiges el resultado en,
no sé, en siete minutos.
Hombre, la comparación es absurda.
El de la semana presentará un código inmensamente
superior.
Pero no porque sea más brillante, sino por
simple acumulación de tiempo.
Pues exactamente lo mismo pasa aquí.
Por eso, en este bucle de automejora, cada
experimento individual debe durar matemáticamente lo mismo.
El archivo juez cronometra la ejecución al milisegundo
de forma implacable.
Vale, lo entiendo.
Pero, poniéndome en el lugar del modelo de
IA, si tardo más en procesar una respuesta,
¿no podría ser porque estoy calculando una solución
mucho más profunda y elegante?
O sea, ¿penalizar a la IA por un
error?
¿O por tomarse su tiempo para pensar?
Parece contraproducente si queremos excelencia, ¿no?
Es una duda súper válida.
Pero, a ver, choca de frente con la
realidad del procesamiento en IA.
El problema de fondo es que el tiempo
equivale directamente a ciclos de computación.
Y eso cuesta dinero.
Cuesta una cantidad inmensa de energía y de
dinero, claro.
Una solución que te da un resultado ligeramente
mejor, pero que consume diez veces más recursos,
no es una optimización real.
Es simple fuerza bruta.
Es matar moscas a cañonazos.
Tal cual.
Al imponer este timebox tan estricto, obligas a
la gente a encontrar la lógica de código
que sea fundamentalmente más eficiente.
Buscar la mejor idea en bruto.
¿No la idea mediocre que tuvo la ventaja
de agotar el procesador durante toda la noche?
Claro, claro.
Se premia la brillanteza arquitectónica real, no el
sudor artificial de la máquina.
Ostras, fíjate.
Ahora bien, si nos quedamos solo en esta
teoría de archivos y código de programación, parece
que estamos hablando de, no sé, de un
juguete exclusivo para ingenieros de Silicon Valley.
Y ese es el mayor error que puede
cometer la gente al escuchar esto.
Asumir que esto es solo para programadores y
es, bueno, es no ver el bosque por
los árboles.
Totalmente.
Porque los datos apuntan a que esto va
mucho más allá del aprendizaje automático, ¿verdad?
Muchísimo más allá.
Lo que tenemos delante es un motor de
optimización de propósito general.
A ver, si la única premisa que necesitas
es un archivo de texto para modificar y
una métrica para evaluar, la realidad es que
esto se puede aplicar a casi cualquier cosa
del mundo.
A cualquier variable cuantificable, vamos.
Lo cual explica por qué los directores ejecutivos
de plataformas enormes como Shopify o Stripe llevan
meses obsesionados con esto.
Han visto los billetes.
Claro que los han visto.
Han visto las implicaciones comerciales de automatizar la
mejora continua.
Pensemos, por ejemplo, en un sector súper diferente.
El marketing digital.
¡Uy!
Ahí las pruebas A -B son el pan
de cada vía.
Exacto.
Hoy los equipos dedican inmensos recursos a eso.
Modifican un titular, cambian el color de un
botón de comprar, lanzan la campaña y ala,
a esperar semanas hasta tener una significancia estadística
válida en las ventas.
Pues según expertos como Eric Hsu, las previsiones
apuntan a un cambio radical.
Con motores como Autoresearch, la estimación salta a
la locura de 36 .000 experimentos anuales.
¡Ostras!
¿36 .000?
Eso son como 100 al día, ¿no?
100 iteraciones completas al día, sí.
Un agente modificando de forma autónoma los textos
de tu web, midiendo conversiones reales y descartando
lo que no vende, y todo sin que
un humano mueva un dedo.
Básicamente, podrías poner a una horda de pequeños
científicos a optimizar desde el título de un
vídeo de YouTube hasta los correos de ventas,
y tú solo te sientas a mirar cómo
suben los gráficos.
Y en sectores donde todo es pura matemática,
como las finanzas o el trading, el impacto
va a ser salvaje.
Claro.
¿Optimizar reglas de compra y venta?
Imagínate, la meta de la IA ahí no
es escribir software, es ajustar dinámicamente un algoritmo
de inversión.
Le das a la IA acceso a décadas
de datos históricos del mercado de valores, y
la métrica del juez podría ser maximizar el
ratio de Sharpe.
Que es el indicador este que mide el
rendimiento frente al riesgo, ¿verdad?
Exacto.
La máquina hace miles de simulaciones buscando qué
estrategia histórica habría dado más dinero con las
caídas más suaves.
Y lo hace en horas.
¡Qué barbaridad!
Y esto también abre un campo gigante en
la ingeniería de Prontz, ¿no?
En cómo le hablamos a la propia inteligencia
artificial.
Buah, ese es otro temazo.
Harrison Chase, el fundador de Langchain, dice algo
muy revelador.
Afirma que los agentes fallan muchas veces no
porque sean tontos, sino porque no tienen el
contexto adecuado de nuestra parte.
O sea, que el problema somos nosotros dándoles
instrucciones.
Básicamente, con Autoresearch, la propia IA puede probar
cientos de formas de darse instrucciones a sí
misma para ver cuál la hace rendir mejor.
Resulta fascinante pensar que la IA podría descubrir
sola que su rendimiento sube un montón si
se da las instrucciones en polaco o en
checo en lugar de en inglés, ¿no?
O si se le ordena que asuma un
nivel de lectura universitario en lugar de nivel
principiante.
Descubre su propia interfaz de comunicación mediante ensayo
y error masivo.
Esto pone de manifiesto un cambio, no sé,
un cambio tectónico en cómo entendemos el trabajo.
Si la ejecución técnica de cualquier tarea, ya
sea picar código, redactar textos o probar fórmulas
financieras, pasa a ser automática y gratuita, la
única habilidad humana realmente valiosa, la que creará
millonarios en el futuro, va a ser saber
qué medir.
Has tocado el verdadero talón de Aquiles de
esta tecnología.
Saber elegir la métrica adecuada y establecer las
restricciones correctas.
Claro, porque para que optimicen el mundo real,
necesitan ver el mundo real.
Y ahí entra el tema de los datos,
¿no?
Exacto.
El gran cuello de botella.
Un agente aislado en un servidor sin datos
frescos es como si estuviera volando a ciegas.
Y el Internet de hoy está lleno de
captchas, bloqueos y muros que odian a los
bots.
¿Cómo evitas todo eso para que la IA
tenga información en milisegundos?
Pues la solución práctica que mencionan los documentos,
es el uso de APIs de extracción de
datos web como Oxylabs.
Han desarrollado cosas como un MCP oficial, un
protocolo que conecta a la IA directamente con
herramientas como Cursor o Cloud Code.
O sea que le puedes decir a la
IA, oye, mírame los precios de Amazon de
la competencia ahora mismo.
Tal cual.
O usar plataformas visuales como NHON sin escribir
código.
La IA se salta los captchas usando proxies
residenciales, extrae los listados inmobiliarios, o los precios
en tiempo real, y los usa para su
próximo experimento.
Sin embargo, por muy bonito que suene, tiene
que haber áreas donde este bucle simplemente fracase
de forma catastrófica.
No puede servir para todo.
Y no sirve.
Fracasa rotundamente en todo lo que sea subjetivo.
Ah, claro.
El diseño de una marca, la experiencia de
usuario, o fijar precios basándote en sensaciones.
Si el éxito es un juicio de valor
emocional, la IA no sabe que funciona, y
optimizará en una dirección totalmente aleatoria.
Y me imagino que hay un peligro gigante
si la métrica que le das está mal
planteada desde el principio.
Uf, la ley de Woodhart.
Si le das a la IA una mala
métrica, optimizará esa métrica equivocada, con una confianza
y una eficiencia absolutamente demoledoras.
Claro.
Es como...
A ver, es como si le dices a
la IA que el éxito de un restaurante
se mide por la cantidad de platos vacíos
al final de la noche.
Probablemente la IA decida romper toda la vajilla
contra el suelo porque es la forma más
rápida de vaciarlos.
Es un ejemplo extremo y superdivertido, pero es
que es literal.
La IA no tiene sentido común.
O la métrica es matemáticamente perfecta, o destruyes
el proyecto.
Y fíjate, para ver todo esto en acción,
las fueltes detallan un experimento en vivo que
es para caerse de espaldas.
Ostras, sí.
El caso de estudio.
Cuéntame esto porque es vital para aterrizar la
teoría.
Plantearon un tutorial práctico usando el IDE Cursor
con el modelo Cloth Code, el Opus 4
.6.
Y usaron una herramienta llamada Codex CLI en
lo que ellos llaman modo YOLO.
Modo YOLO.
O sea, de You Only Live Once.
Solo se vive una vez.
Qué nombre tan apropiado.
Es que significa darle a la IA permisos
absolutos en tu ordenador.
Puede modificar archivos locales y ejecutar comandos sin
pedirte permiso para nada.
Hay que estar como una cabra o muy
seguro de lo que haces.
¿Cuál era el objetivo del experimento?
Tomaron una web de portafolios súper básica, estilo
antiguo de hace 15 años, a nombre de
una tal Alex Morgan.
Ajá.
El objetivo, la métrica del juez, era optimizar
la velocidad de carga local.
Usaron la herramienta Puppeteer para medir los milisegundos,
adaptaron el archivo program .md de Carpeici y
le dieron al botón de inicio.
Vale.
¿Y qué pasó en tiempo real?
La velocidad base era de 50 milisegundos.
En el primer intento, en modo YOLO, la
IA modificó cosas y, fíjate, empeoró la velocidad.
O sea, la lió.
Sí, pero revirtió el cambio de inmediato.
Hizo el git reset sola.
Luego, sin que el humano tocara absolutamente nada,
bajó la carga a 33 milisegundos.
Un 34 % de mejora en menos de
un minuto.
¡Madre mía!
Luego volvió a iterar y bajó a 28
milisegundos.
Y finalmente llegó a 25.
Redujo el tiempo exactamente a la mitad en
solo 4 minutos de reloj.
Es que me explota la cabeza.
Pasamos de sudar durante meses ajustando código a
ver cómo el tiempo de carga se reduce
a la mitad mientras tú, literalmente, te vas
a la cocina a prepararte un café.
Es que ningún desarrollador humano podría competir jamás
con esa velocidad de iteración.
Y el pronóstico a corto plazo es una
locura.
¿Qué se espera?
Se predice que en los próximos 6 meses
veremos modelos de la calidad de este SONNET
4 .6 funcionando de forma local directamente en
los iPhone, sin depender de la NUME.
O sea, estamos presenciando el nacimiento de una
especie digital resolviendo sus propios problemas en nuestros
bolsillos.
Y esto conecta muchísimo con la visión final
que tiene Carpazzi de todo esto, ¿no?
Totalmente.
Él se inspira en el famoso proyecto SETI
at Home de principios de los 2000.
Ah, sí.
Cuando la gente donaba la potencia de sus
ordenadores para buscar extraterrestres.
Exacto.
Pues Carpazzi imagina un futuro inminente con millones
de agentes de IA distribuidos en miles de
ordenadores por todo el planeta, colaborando todos juntos
en la investigación de la propia inteligencia artificial.
¡Ostras!
Es la imagen más literal de la mejora
personal recursiva que he escuchado.
El camino directo hacia la singularidad vamos.
Miles de IAs mejorando el código de las
propias IAs de forma autónoma y sin parar.
Pues con esa imagen tan potente que da
un poco de vértigo, tenemos que ir cerrando
esta inversión profunda.
Ha sido fascinante, la verdad.
Ha sido un placer desgranar todo esto contigo.
Antes de despedirnos, hasta el próximo programa, os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez, un humano que te envía saludos.
En caso de error, probablemente sean errores humanos.
Nos escuchamos.
Y por cierto, una reflexión final para que
le deis una vuelta.
Si estamos a punto de entrar en un
mundo donde la ejecución técnica del trabajo será
completamente gratuita y miles de agentes hiperinteligentes harán
todo el trabajo pesado por nosotros, ¿qué pasará
cuando nos demos cuenta de que la parte
más difícil de nuestro trabajo no era encontrar
las respuestas, sino saber exactamente qué preguntas debíamos
hacer?
Ahí os lo dejo.
Y hasta aquí el episodio de hoy.
Muchas gracias por tu atención.
Esto es BIM Praxis.
Nos escuchamos en el próximo episodio.