Vídeo original: The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI
Enlace del video: https://www.youtube.com/watch?v=kwSVtQ7dziU
Nota: A continuación se incluye la traducción completa al chino; se procura mantener el sentido y la estructura originales, eliminando solo unas pocas muletillas sin significado (como um, uh).
«Escribir código» ya ni siquiera es un verbo preciso, ¿no? Ahora soy más bien alguien que pasa 16 horas al día expresando intenciones a mis agentes, manifestando cosas.
¿Cómo puedo no quedarme solo con una sesión única de Claude Code o Codex o alguno de esos frameworks de agentes? ¿Cómo puedo tener más? ¿Cómo puedo hacerlo de forma adecuada? La parte de agentes ahora se da por sentada. Ahora, las entidades tipo Claude se dan por sentadas; ahora puedes tener múltiples entidades, ahora puedes darles instrucciones, ahora puedes optimizar las instrucciones. Pero quiero decir: por eso se vuelve tan adictivo, porque es como infinito, y todo sigue siendo una cuestión de habilidad.
Hola a todos, bienvenidos de nuevo a No Priors. Hoy estoy aquí con Andrej Karpathy (Andre Karpathy), y tendremos una conversación amplia sobre agentes de código, el futuro de la ingeniería y de la investigación en IA, cómo más personas podrán contribuir a la investigación, qué está pasando en robótica, sus predicciones sobre cómo los agentes tocarán el mundo real, y la educación en la próxima era, entre otros temas. Bienvenido, Andrej. Andrej, gracias por hacerlo. Sí, gracias por invitarme.
Así que estos últimos meses han sido meses muy emocionantes en IA.
Sí, se podría decir eso.
Recuerdo que una vez entré a la oficina y estabas como bloqueado; te pregunté qué estabas haciendo y me dijiste: «solo tengo que programar 16 horas al día, porque si no, “programar” deja de ser el verbo correcto, ¿no? Pero tengo que…»
…pasar 16 horas al día expresando mi voluntad a mis agentes. Se volvió evidente porque hubo un salto de capacidades.
¿Qué pasó? Y cuéntame tu experiencia.
Sí, siento que vivo permanentemente en ese estado de “subidón” con la IA, como siempre. Porque como persona puedes lograr muchísimo, ¿no? Porque tu cuello de botella es tu velocidad de tecleo, etc. Pero ahora con estos agentes, diría que en diciembre todo cambió por completo: pasé de 80/20 a 20/80, escribiendo código yo mismo, en lugar de solo delegar en el agente. Ni siquiera creo que ya sea 20/80; creo que es muchísimo más. Creo que básicamente desde diciembre no he vuelto a teclear una sola línea de código, y eso es un cambio enorme. Estoy hablando con ello como si hablara con mis padres y demás; y no creo que una persona “normal” se dé cuenta de que esto pasó, ni de lo dramático que es. Es como: si vas al escritorio de un ingeniero de software aleatorio o algo así, lo que está haciendo es el workflow por defecto, pero desde diciembre, construir software es completamente distinto. Así que estoy en ese subidón tratando de entender qué es posible y empujarlo al límite. ¿Cómo puedo no quedarme solo con una sesión de Claude Code o Codex o alguno de esos frameworks de agentes? ¿Cómo puedo tener más? ¿Cómo puedo hacerlo adecuadamente? Entonces, ¿cómo uso estos agentes en segundo plano? ¿Qué son esos agentes en segundo plano?
Así que hay muchas cosas nuevas. Quiero estar a la vanguardia, pero estoy inquieto porque no estoy en la vanguardia. Veo en Twitter a mucha gente haciendo todo tipo de cosas; suenan como ideas muy buenas, y necesito estar a la vanguardia o me pongo muy nervioso. Así que creo que estoy en ese subidón de lo posible porque, en el fondo, esto aún no se ha explorado.
Bueno, si tú estás nervioso, los demás también. Tenemos un equipo que trabaja con nosotros y estamos convencidos de que su configuración es que… ya sabes, no hay un solo ingeniero que escriba código a mano; todos llevan micrófono y les susurran a sus agentes todo el tiempo. Es el ambiente de trabajo más raro de la historia. Pensé que estaban locos y ahora lo acepto totalmente: «Ah, así es». Es como que tú estás justo delante.
¿Cómo ves tu capacidad actual para explorar o hacer proyectos? ¿Qué la limita?
Sí. ¿Qué la limita? Yo creo que todo es como muchas cosas: incluso cuando no funciona, en gran medida sientes que es una cuestión de habilidad. No es que no exista la capacidad; es que aún no has encontrado cómo combinar lo que ya está disponible. Por ejemplo: quizá no escribí instrucciones lo bastante buenas en el archivo agent/MD o en otra parte, o no le conecté herramientas de memoria lo bastante buenas, etc. Entonces cuando el sistema no funciona como esperabas, se siente más como un recordatorio: ¿será que todavía no tengo suficiente destreza de uso, o que aún no lo paralelicé bien? Básicamente quieres ser Peter Steinberg. Peter es famoso: hay una foto interesante de él delante de monitores, con muchas instancias de Codex. Así, muchos agentes de Codex se colocan en los monitores; si los indicas bien y te esfuerzas bastante, cada uno tarda como 20 minutos. Todos tardan como 20 minutos. Él tiene varios, ya sabes, con 10 repositorios “checkeados”, y va pasando entre ellos y dándoles trabajo. Es como que puedes actuar a un nivel más macro. Ya no es una línea de código, es una función nueva. Es: esto es una feature nueva y se la delego al agente 1; es una feature nueva que no interfiere con las otras, se la doy al agente 2, y luego, según cuánto te importe ese código, revisas su trabajo lo más posible. ¿Qué operaciones macro puedo usar para manipular mis repositorios?
Como: otro agente hace una investigación; otro escribe código; otro propone planes de implementación. Así que todo son operaciones macro sobre tu repo; solo quieres volverte muy bueno en eso y desarrollarlo como memoria muscular, porque es muy… sí, es muy valioso: primero, porque funciona; pero también es algo nuevo que aprender. Por eso es tan adictivo. Sí, de verdad siento que mi intuición es: cada vez que espero a que un agente termine algo, lo obvio es: bueno, puedo hacer más trabajo, ¿no? Como: si pudiera conseguir más tokens, debería paralizarme por añadir más tareas. Eso es muy estresante, porque si no sientes que tu capacidad de gastar tokens está muy limitada, entonces sabes que el mayor cuello de botella del sistema eres tú.
Sí. Al menos no estás maximizando tu suscripción; idealmente, para múltiples agentes: si agotas el cupo en Codex, deberías cambiarte a Claude o algo así. No sé: eso es lo que he estado intentando. Cuando me sobra suscripción, me pongo nervioso: significa que no estoy maximizando mi throughput de tokens, así que… De hecho, me pasaba algo parecido cuando era doctorando: te ponías nervioso si tus GPUs no estaban corriendo; tenías capacidad de GPU y no estabas maximizando los FLOPs disponibles. Pero ahora no es sobre FLOPs: es sobre tokens. ¿Cuál es tu throughput de tokens? ¿Cuál es el throughput de tokens de tus órdenes? Diría que esto es interesante: llevamos al menos 10 años diciéndote que, en muchas tareas de ingeniería, la gente no se sentía limitada por cómputo.
Sí, toda la industria ahora siente que los recursos la limitan.
Ahora tuviste un salto tan grande de capacidad que piensas: «ah, en realidad… ya no es mi capacidad de acceder a cómputo; como que yo soy la restricción vinculante».
Sí, es una cuestión de habilidad.
Eso es muy potente, porque sí: puedes mejorar. Por eso creo que es tan fácil volverse adicto: cuando mejoras, se desbloquean cosas.
¿A dónde crees que va? Si piensas: bueno, Andre está iterando y otra gente está 16 horas al día con agentes de programación… ¿cómo se ve un año de maestría?
Sí. ¿Cómo se vería dominarlo a fin de año, o en dos, tres, cinco, diez años, etc.?
Creo que todo el mundo está interesado en subir en la pila. O sea: no es una sola sesión con tu agente; es cómo múltiples agentes colaboran y forman equipos, etc. Todo el mundo está tratando de entender cómo se ve eso. Y luego diría que los agentes en segundo plano también son una dirección interesante, porque cuando digo “agentes en segundo plano”, me refiero a una capa que lleva la persistencia a un nivel completamente nuevo. Es algo que está en loop constante; no es algo en lo que participas interactuando. Tiene como su propio sandbox; hace cosas por ti incluso cuando tú no “pareces” estar haciendo nada. Y además, podría haber sistemas de memoria más complejos, etc., que aún no están implementados en agentes. Entonces, yo diría que ese agente residente en segundo plano debería tener un sistema de memoria más complejo que el agente por defecto, no solo compresión de memoria cuando se agota el contexto. Correcto.
¿Crees que eso resonará más con los usuarios, comparado con, por ejemplo, un acceso más amplio a herramientas… para este tipo de agente residente en segundo plano?
Sí. Ahí… creo que hay muchas ideas muy buenas. Sí. Buen trabajo, Peter.
Quiero decir: Peter lo está haciendo increíble. Lo vi hace poco, hablé con él de esto; es muy humilde al respecto, pero creo que está innovando simultáneamente de cinco maneras distintas y juntándolas. Por ejemplo: como el archivo SOUL y los archivos MD; él realmente moldeó una personalidad convincente e interesante, y siento que muchos agentes actuales no entienden bien eso. En realidad, creo que Claude tiene buena personalidad: se siente como un compañero de equipo; te entusiasma, etc. Diría que, por ejemplo, Codex es más seco. Y eso es interesante porque en ChatGPT parece más optimista y más propenso a seguirte el juego. Pero diría que el agente de programación de Codex es muy seco: no parece importarle lo que estás creando. Es como: «Oh, lo implementé». Y tú: «Ya, pero ¿entiendes lo que estamos construyendo?».
Eso es verdad.
Otra cosa: por ejemplo, Claude, creo que manejan bien el tema de lo adictivo. Cuando Claude me elogia, sí siento que me lo he ganado… porque a veces le doy una idea poco madura, le doy una idea que creo que aún no está del todo madura, y no reacciona con mucha fuerza: como «sí, podemos implementarlo». Pero cuando yo mismo creo que es una gran idea, parece que realmente recompensa más. Entonces siento que quiero “ganarme” su elogio, lo cual es rarísimo.
Así que sí creo que la personalidad importa. Creo que muchas otras herramientas quizá no lo valoren tanto. Y creo que Peter también se preocupa mucho por eso, así que eso está bien. Y luego el sistema de memoria, y ya sabes: a él le interesa mucho eso. Y luego, un único portal de WhatsApp hacia toda la automatización.
Sí. Fuera de la ingeniería de software, ¿has hecho algo interesante o divertido con tus manos?
Sí. En enero tuve un agente en segundo plano; pasé por una etapa de subidón con agentes en segundo plano. Construí un agente que básicamente se encarga de mi casa; lo llamé el elfo doméstico Dobby. Básicamente, usé el agente para encontrar, en la LAN, todos los subsistemas de smart home de mi casa, y me sorprendió que funcionara “out of the box”. Por ejemplo: tengo Sonos en casa. Le dije: «¿puedes intentar encontrarlo?». Y literalmente hizo un escaneo de IP de todos los equipos básicos en la LAN, encontró el sistema Sonos; resultó que no tenía password ni nada. Entró y fue como: «sí, tienes estos sistemas Sonos instalados; déjame intentar hacer ingeniería inversa de cómo funciona». Hizo búsquedas en la web, encontró endpoints de API, y me dijo: «¿quieres probar?». Y yo: «sí». Le dije: «¿puedes intentar poner algo en el estudio?». Y lo hizo; empezó a sonar música. Yo: «no puedo creer… esto es una locura. Fueron como tres prompts». Sí.
No puedo creer que acabo de escribir algo como: «¿puedes encontrar mi Sonos?», y de repente empezó a reproducir música. Hizo lo mismo con las luces. Básicamente fue como hackearlo: entendió todo el asunto, creó la API, creó un dashboard para que yo vea el centro de mando, con todas las luces de la casa, y luego encender/apagar luces. Así, yo puedo preguntarle a Dobby cuando me voy a dormir: cuando diga que tengo sueño, significa que se apagan todas las luces, etc. Entonces controla todas mis luces, el HVAC, las cortinas, la piscina y el spa, y el sistema de seguridad. Tengo una cámara apuntando hacia afuera, y cada vez que alguien entra, uso un modelo de visión para mirar el video. Primero hay detección de cambios, ¿no?
Luego, tras detectar cambios, pasa el frame al modelo de visión para analizarlo, y me manda un mensaje por WhatsApp. Adjunta una imagen de la puerta y me dice: «Hey, acaba de llegar un camión de FedEx; mejor mira, quizá tengas un paquete». Dobby me manda un SMS así directamente. Es completamente absurdo y muy cool. Ahora Dobby básicamente se encarga de estas cosas de la casa, y yo me comunico por WhatsApp. Tener esta experiencia de “operación macro” que mantiene toda tu casa, es muy interesante. Aún no lo he llevado a un nivel más extremo; sé que mucha gente juega más duro. Pero incluso solo con automatización doméstica, ya me resulta muy útil. Antes tenía que usar seis apps distintas; ahora ya no. Dobby controla todo en lenguaje natural; es impresionante. Siento que ni siquiera he llevado este paradigma al límite, pero ya es suficientemente útil e inspirador.
¿Crees que esto muestra lo que la gente realmente quiere de la UX del software? Porque hay algo que se pasa por alto: los humanos tienen que gastar energía aprendiendo software nuevo, adaptándose a interfaces nuevas.
Sí, hasta cierto punto estoy de acuerdo. Es como diseñar el sistema “al revés” en función de la imaginación que la gente tiene sobre la IA. Porque en la cabeza de la mayoría, la IA no es el LLM en el sentido primitivo: un LLM, en esencia, es solo un generador de tokens que escupe tokens. Lo que la gente cree que es la IA, se parece más a un ente con personalidad e identidad: tú le dices cosas, lo recuerda, es como una entidad detrás de WhatsApp. Eso es mucho más natural de entender.
Así que, en cierto sentido, esto está alineando el producto con la expectativa previa de cómo “debería comportarse” la IA. Solo que para lograrlo, por detrás hay que meter muchísimos detalles técnicos; y para la mayoría, el primitive “LLM” todavía es demasiado tosco, estrictamente aún no se parece a la IA que imaginan.
Sí, creo que eso también muestra cómo entendemos la IA. Describirla como Dobby, o darle una personalidad, claramente hace que resuene más. A la vez, también siento que el hecho de unificar seis sistemas distintos de automatización doméstica apunta a otro tema:
¿De verdad la gente necesita hoy esta pila de software fragmentado que no se habla entre sí?
Sí.
Correcto. Porque, en cierto sentido, conservaste el hardware, pero tiraste el software —al menos la capa de experiencia de usuario— a la basura. ¿Crees que eso es lo que la gente realmente quiere?
Sí. Creo que se siente así: estas apps en las tiendas, para usar estos dispositivos smart home, etc. En cierto sentido, esas apps ni deberían existir. ¿No debería ser solo una API, y que el agente la use directamente? ¿No puedo hacer trabajos de automatización doméstica que una app individual no puede hacer bien, y que el LLM conduzca herramientas, llame a las herramientas correctas y haga cosas bastante complejas?
Entonces sí: en cierto sentido, esto señala que quizá hay una sobreproducción masiva de apps custom que no deberían existir. Los agentes las “aplastan”: todo debería ser más como endpoints de API expuestos, y el agente es el pegamento inteligente, llamando herramientas y conectando piezas. Otro ejemplo: mi cinta de correr. Tiene una app. Yo quiero rastrear con qué frecuencia hago cardio, pero no quiero iniciar sesión en una web UI y seguir un flujo, etc. Todo eso debería ser: hacer disponible la API. Esa es la forma de ir hacia una web de tipo “agent” o herramientas “agent-first”, y todo eso. Así que creo que la industria tiene que reconfigurarse en muchos sentidos: como que el cliente ya no es un humano. Es un agente que actúa en nombre del humano. Esa reconfiguración puede ser enorme.
Una objeción que a veces se plantea es: ¿la gente quiere programar algunas de estas herramientas? ¿Esperamos que la gente “normal” haga lo que yo describí?
Pero creo que, en cierto sentido, esto es simplemente la tecnología actual. Hoy existe algo de vibe coding; yo lo estoy viendo y usando ese sistema. Pero siento que lo que acabo de describir debería ser gratis en uno, dos o tres años. Sin programación en segundo plano. Es trivial. Es el “mínimo para entrar”. Cualquier IA, incluso modelos open source, debería poder hacerlo.
Debería ser muy fácil traducir intenciones humanas de baja complejidad técnica a esto. Muy fácil. Sí. Hoy implica vibe coding, pero no mucha gente lo hará. Pero aun así necesitas tomar algunas decisiones de diseño, ¿no? Estamos hablando de cosas como el framework, por ejemplo.
Sí.
Sí. Pero siento que esto solo es el comienzo: la barrera desaparecerá. Será software efímero que te representa; algo parecido a un agente residente en segundo plano que maneja todos los detalles sin que tú participes. El agente en segundo plano tiene una máquina; lo resolverá. Solo te muestra una UI, y tú solo dices lo que quieres. Mmm.
¿Por qué no empujas más los límites de lo que tú y Claude pueden lograr? O sea, estás enfocado en proyectos más importantes, AutoResearch, etc., o estás escalando una montaña o lo que sea, ¿no?
Sí. Es que me distraigo con todo. Pasé como una semana en lo del hogar; tengo casi más cosas que hacer. Pero diría que, por desgracia, este tipo de herramientas en sí mismas se vuelven cada vez más “ocupantes” y más potentes.
Sí. No he aprovechado de verdad cosas como email, calendario y demás; no le he dado acceso, porque sigo siendo un poco escéptico y esto aún es nuevo y tosco en los bordes. No quiero que acceda por completo a mi vida digital todavía. En parte por seguridad y privacidad; hay que ser muy cuidadoso en ese terreno. Así que diría que algunas cosas están frenadas. Sí, quizá eso sea una característica dominante, pero también es que me distraigo: siento que me fui una semana y luego pasaron otras cosas. Y…
Quiero decir: mencionaste que puedes entrenar o al menos optimizar un modelo para las tareas que querrías que el agente haga a largo plazo. ¿Cuál fue la motivación detrás de AutoResearch?
AutoResearch. Sí. Antes tuiteé algo: para aprovechar al máximo las herramientas disponibles, tienes que eliminarte como cuello de botella. No puedes estar ahí promptando el siguiente paso. Tienes que sacarte del loop. Tienes que organizar las cosas para que sean totalmente autónomas, y cuanto más sepas cómo maximizar tu throughput de tokens sin caer en loops, mejor. Ese es el objetivo. Mencioné que ahora el juego se llama aumentar tu impacto: yo pongo pocos tokens de vez en cuando, y ocurren muchísimas cosas en mi nombre. Así que AutoResearch… como tuiteé, creo que a la gente le gusta, etc., pero quizá no les gusta como “trabajo”, por lo que significa. Para mí, AutoResearch es un ejemplo de “tomarse en serio lo que significa”.
No quiero ser el investigador “en el loop”, revisando resultados, etc.; siento que obstaculizo el sistema. La pregunta es: ¿cómo reestructuro las abstracciones para no tener que estar encima? Lo organizas una vez y le das a start. El juego es: ¿cómo hacer que más agentes corran más tiempo sin tu participación, haciendo cosas por ti? AutoResearch es eso: un objetivo, una métrica, un límite de lo que se puede o no se puede hacer, y luego te vas.
¿Te sorprendió su efectividad?
Sí. No esperaba que funcionara. Con Project Data Chat, en el fondo creo que mucha gente está confundida por mi obsesión con entrenar un GPT-2 y cosas así, pero para mí entrenar GPT es solo una herramienta; un patio de recreo para entrenar LLMs. En el fondo me interesa más la idea de mejora recursiva, y hasta dónde puedes empujar la auto-mejora de un LLM. Porque siento que todos los labs frontera están haciendo esto por razones obvias: todos intentan mejorarse recursivamente.
Para mí es como un jueguito. Y también me gusta, a la vieja escuela, hacer tuning manual de hiperparámetros. Soy investigador; llevo veinte años haciendo esto. Tengo cierta confianza: he entrenado este modelo miles de veces; hice muchos experimentos, ajustes básicos, todo lo que estoy acostumbrado; lo he hecho por veinte años. Llegué a un punto en que pensé que estaba bastante bien ajustado, y luego dejé a AutoResearch tunearlo durante una noche. Volvió y encontró ajustes que yo no vi.
Sí, olvidé cosas como el weight decay del value embedding y que mi beta atómica no estaba bien ajustada. Esas cosas interactúan; si ajustas una cosa, otras cambian. Yo no debería ser el cuello de botella. No debería ejecutar yo esas búsquedas de hiperparámetros. No debería ni mirar los resultados. Aquí hay un criterio objetivo. Solo tienes que organizarlo para que pueda seguir para siempre. Esta es una versión única de AutoResearch: un solo loop intentando mejorar. Me sorprendió que encontrara estas cosas; el repo ya estaba bastante bien ajustado y aun así encontró algo. Y eso es un solo loop. Los labs frontera tienen clusters de decenas de miles de GPUs. Es fácil imaginar muchísima automatización en modelos pequeños, y en el fondo el nivel frontera de inteligencia es extrapolación y escalado de pérdidas: haces mucha exploración en modelos pequeños y luego intentas inferir.
Así que dices que nuestro trabajo de investigación será más eficiente: tendremos mejor dirección al escalar, si podemos experimentar mejor.
Sí. Diría que lo más interesante que están haciendo los labs frontera es experimentar en modelos más pequeños, intentar hacerlos lo más autónomos posible, y sacar a los investigadores del loop. Hay demasiados; ¿lo contrario de qué? Demasiada confianza. Sí: no deberían tocar nada de eso. Tienes que reescribir todo. Claro, pueden aportar ideas, pero en realidad no deberían implementar las ideas.
Habría una cola de ideas: quizá un “científico automatizado” que genera ideas a partir de papers archivados y repos de GitHub; agrega ideas. Los investigadores pueden aportar ideas, pero es una sola cola; hay “workers” que sacan proyectos y los intentan. Lo que funcione va a un feature branch. Quizá algunos humanos miran los feature branches; a veces se mergea a main. Así que sí: sacar humanos de todos los procesos, automatizar lo máximo posible, y lograr el mayor throughput de tokens por segundo posible. Eso requiere repensar todas las abstracciones: hay que barajar todo.
Sí, lo veo muy emocionante. Si damos un paso recursivo más: ¿cuándo podrán los modelos escribir un program MD mejor que el tuyo?
Sí. Entonces program MD es…
No estamos en el loop.
Sí, exacto.
Sí: program MD fue mi intento torpe de describir cómo debería funcionar AutoResearch: “haz esto, luego aquello, prueba estas ideas; aquí hay ideas: mira la arquitectura, mira el optimizador, etc.” Lo inventé en markdown, ¿no?
Sí, totalmente. Te imaginas distintos program MD que te dan progresos distintos. Básicamente, cada organización de investigación se describe con un program MD.
Una organización de investigación es un conjunto de archivos Markdown que describen roles y cómo se conecta todo. Puedes imaginar una organización mejor. Quizá hacen menos standups por la mañana porque no sirven. Es código, ¿no? Una organización hace menos standups; otra hace más; una asume más riesgo; otra hace menos standups. Puedes imaginar múltiples organizaciones de investigación. Y todas tienen código; y si hay código, puedes ajustar el código. Así que 100%: es la capa meta.
¿Viste el texto de mi idea de competencia? Mi idea es que la gente escriba distintos program MD, ¿no? Para el mismo hardware, ¿dónde obtienes la mayor mejora?
Entiendo.
Luego puedes recoger todos esos datos, dárselos al modelo, y escribir un program MD mejor.
Sí. Sí.
Sí. Exactamente.
Obtendríamos algo mejor. Es imposible que no ocurra.
Puedes 100% ver de dónde vienen las mejoras: puedo cambiar program MD para que haga más de esto, o deje de hacer cosas que no funcionan.
Meta-optimización. Sí.
Puedes imaginarlo 100%. Creo que es una gran idea, pero paso a paso: primer proceso, segundo proceso, siguiente proceso; capas de cebolla. La parte LLM ahora se da por sentada. La parte agente se da por sentada. Las entidades tipo Claude se dan por sentadas; ahora puedes tener múltiples entidades, darles instrucciones, optimizar las instrucciones… es un poco demasiado. Pero por eso se vuelve tan adictivo: es como infinito; todo sigue siendo un problema; por eso es tan loco.
Vale. Si diagnosticamos el momento actual y qué habilidades son relevantes ahora: lo que te gusta, lo que crees que significa… es que debemos implementar loops en distintos dominios y que funcionen: crear métricas o permitir que el agente persiga la métrica sin ti.
Sí.
¿Aún tenemos ingeniería de rendimiento y cosas así?
Sí. Quiero poner algunas advertencias sobre el ecosistema LM. Primero: esto encaja muy bien con cualquier cosa que tenga métricas objetivas fáciles de evaluar. Por ejemplo: escribir kernels CUDA más eficientes, partes del código del modelo, etc., son perfectos.
Porque tienes código ineficiente y quieres código eficiente con el mismo comportamiento, pero más rápido: perfecto.
Muchas cosas así encajan muy bien con AutoResearch, pero muchas no: si no puedes evaluar, no puedes hacer AutoResearch, ¿no? Esa es la primera advertencia. La segunda es: estamos hablando del “siguiente paso” y vemos cuál es, pero en el fondo todo esto aún… es como si tuviera grietas en las costuras; no funciona de forma totalmente fluida. Si intentas ir demasiado lejos, todo se vuelve inútil.
Porque estos modelos aún no… han mejorado mucho, pero los bordes siguen siendo toscos. Así lo describiría. A la vez siento que hablo con un doctorando excelente que ha sido programador de sistemas toda su vida… y con un niño de 10 años. Es raro: en humanos esa combinación no existe. Esa “dentadura” (jaggedness) es extraña; en humanos hay menos. Los agentes tienen muchos comportamientos irregulares: a veces pido una feature y vuelve con algo completamente equivocado, caemos en un loop equivocado, y me frustro mucho: sientes su poder, pero también hace cosas sin sentido a veces. Me irrita muchísimo cuando siento que el agente desperdicia cómputo en cosas que debería reconocer como un problema obvio.
Sí. Creo que parte de esto viene de que, en el fondo, estos modelos se entrenan con RL. Los labs están intentando resolver justo lo que hablamos: mejorar modelos en cualquier aspecto verificable, con recompensa. ¿Escribiste el programa correctamente y pasaste unit tests? Sí o no. Pero cosas con matices les cuestan: cuál es mi intención, cuándo pedir aclaraciones. Todo lo “blando” se vuelve peor. Entonces es como: o estás en el carril verificable, como parte del circuito superinteligente, o te sales a lo no verificable y de pronto todo se vuelve serpenteante.
Otra forma de decirlo: si hoy vas a un modelo de punta como ChatGPT y le pides un chiste, ¿qué chiste te da? Un chiste. Siento que ChatGPT tiene tres chistes.
Sí. Sí. Y obviamente su favorito es: ¿por qué los científicos no confían en los átomos?
Ok.
Porque lo inventan todo.
Ok.
“Lo inventan todo.” Ese es…
¿De dónde sale eso?
Es un chiste que oías hace tres o cuatro años, y hoy todavía lo oyes.
Ok.
Entonces, aunque los modelos han mejorado muchísimo…
Sí.
Si les das una tarea de agente, pasan horas moviendo montañas por ti. Y luego pides un chiste, y te dan un chiste tonto, uno malo de hace cinco años. Porque eso está fuera del RL: no pertenece a lo que se optimiza. Esa es parte de la “irregularidad”: no deberías esperar que, al mejorar, también tengan mejores chistes, o más variedad. Simplemente no se optimizó y quedó atascado.
¿Crees que eso significa que no vemos una generalización más amplia, como “inteligencia para chistes”, asociada a la inteligencia de código?
Sí. Creo que hay cierto desacoplamiento: hay cosas verificables y no verificables; cosas que los labs optimizan arbitrariamente según los datos, y cosas que no.
Pero hay un supuesto en algunos grupos de investigación: si eres más inteligente en generación de código o en dominios verificables, deberías mejorar en todo. Y lo de los chistes sugiere que eso no está ocurriendo en todos los casos.
No creo que ocurra. Sí, creo que vemos un poco, pero no en cantidad satisfactoria.
Eso también existe en humanos: puedes ser muy bueno en matemáticas y aún contar un chiste malísimo.
Sí, cierto. Pero eso sigue significando que no es como el relato de que, al obtener modelos mejores, obtenemos “gratis” mucha inteligencia y capacidad en todos los ámbitos. Eso no es exactamente lo que está pasando. Hay puntos ciegos; cosas no optimizadas. Todo está metido en redes neuronales opacas: o sigues el carril de entrenamiento y todo va a velocidad de la luz, o no. Es irregular. Por eso, aunque el progreso sea evidente, no puedes lograr que se materialice plenamente: o no funciona del todo, o es una cuestión de habilidad y aún no sabemos usarlo. Es difícil decirlo.
¿Puedo hacer una pregunta herética? ¿Esta irregularidad persistirá, concentrada en una sola interfaz general —un único modelo—, o debería descomponerse en cosas que puedan optimizarse por caso… dominios de inteligencia… como múltiples expertos por dominio, etc.? Más directamente: ¿no lo hemos tocado porque sería confuso que sea tan bueno en una cosa y no en otras?
Sí. Mi impresión actual es que los labs intentan construir un modelo monolítico único, con inteligencia arbitraria en muchos dominios, y lo “rellenan” en los parámetros. Pero sí creo que deberíamos esperar más especiación en los agentes. En el reino animal hay cerebros muy diversos; muchos nichos ecológicos. Hay animales con corteza visual sobredesarrollada u otras partes. Creo que veremos más especiación: no necesitas un oráculo omnisciente. Haces algo específico y lo pones en una tarea específica. Deberíamos ver eso, porque podrías tener modelos más pequeños con un núcleo cognitivo, pero especializados, y más eficientes en latencia o throughput para una tarea concreta. Como un matemático “lean”. Por ejemplo, he visto algunas versiones que apuntan a eso como objetivo por dominio. Podría haber ejemplos donde dividir tenga sentido.
Una duda mía es si la capacidad de la infraestructura de cómputo disponible está limitada por eficiencia, empujando hacia más “especiación”. Sí: eso importa, ¿no? Si dejamos la financiación aparte —aunque la financiación toca todo esto—, si pudieras tener todo el cómputo que quisieras para cualquier cosa, incluso un modelo, ¿no? Pero si sientes presión de que no puedes servir un modelo gigante para cada caso de uso… ¿crees que eso llevaría a especiación? ¿Tiene sentido la pregunta?
Sí, tiene sentido. Lo que me cuesta es que aún no hemos visto mucha especiación, ¿no?
No.
Vimos monocultura del modelo.
Sí.
Así que… claramente hay presión por crear un buen modelo de código y luego volverlo a meter en el “main merge”.
Sí. Sí. Aunque haya presión…
Quizá siento que hay estrechez de oferta a corto plazo que podría causar más especiación ahora.
Sí. Creo que, en el fondo, los labs sirven modelos sin saber qué preguntará el usuario final. Tal vez eso explica parte: deben cubrir cualquier posible pregunta. Pero si vas a una empresa y colaboras en problemas concretos que te importan, quizá ahí sí lo veas. O habrá apps de alto valor, más nicho. Pero ahora están persiguiendo el “todo”. Creo que la ciencia de manipular el “cerebro” no está plenamente desarrollada; solo parcialmente.
¿Qué quieres decir con “manipular”?
Por ejemplo: fine-tuning sin perder capacidades. No tenemos esos primitivos. O usar la inteligencia de formas fuera de la ventana de contexto. La ventana de contexto funciona y es barata. Es como obtenemos personalización, etc. Pero tocar pesos es más delicado que tocar solo la ventana de contexto, porque cambias el modelo y su inteligencia subyacente. Entonces diría que eso aún es una ciencia en desarrollo. Y además tendría que ser lo bastante barato como para que esa “especie” sea valiosa en esos contextos. ¿Puedo preguntar sobre cómo escalas lo que describiste de AutoResearch en el mundo abierto? Dijiste: necesitamos más “superficies de colaboración” alrededor, para que la gente contribuya a la investigación global. ¿Puedes hablar de eso?
Sí. Hablamos de tener un único hilo de investigación: yo pruebo cosas en el loop. Pero la paralelización es el componente interesante. Quiero probar ideas, pero aún no tengo algo “click” con lo que esté muy satisfecho. Pero esto es algo con lo que me gusta trastear en mi sistema de agentes en segundo plano cuando no trabajo.
Una pregunta es: si tienes muchos nodos paralelizables, es fácil que múltiples AutoResearch “hablen” por un sistema común. Me interesa más cómo tener una multitud de workers no confiables en internet.
Por ejemplo, en AutoResearch quieres encontrar snippets de código que lleven el entrenamiento a una pérdida de validación muy baja. Si alguien te da un commit candidato, puedes verificar fácilmente si es correcto o bueno. Alguien puede afirmar en internet que su código optimiza mejor y te da mejor rendimiento. Puedes comprobarlo, aunque cueste trabajo. Pero podrían mentir. Así que estás lidiando con algo que se parece un poco a blockchain: en lugar de bloques son commits; los commits se encadenan; son cambios de código. El proof-of-work es hacer muchos experimentos para encontrar un commit que funcione. Es difícil. Y la recompensa es entrar en un leaderboard; no hay dinero. No quiero empujar demasiado la analogía, pero el patrón es: búsqueda muy cara, verificación barata. Alguien prueba 10.000 ideas; tú solo chequeas si lo que te entregan funciona, porque 9.999 no funcionan.
En resumen: tienes que diseñar un sistema donde un pool de workers no confiables colabore con un pool confiable que verifica; todo es asíncrono y funciona. Y desde seguridad: si alguien te manda código arbitrario y tú lo ejecutas, es muy turbio. Pero en principio debería ser posible.
Proyectos como SETI@home o Folding@home tienen un esquema parecido: encontrar una configuración de baja energía es caro; si alguien cree haber encontrado una, puedes verificarla. Muchas cosas tienen esta propiedad: proponer es caro, verificar es barato. Entonces, Folding@home, SETI@home o un AutoResearch@home encajarían muy bien.
Así que, en resumen: una multitud de agentes en internet podría colaborar para mejorar un LLM, incluso quizá “dar la vuelta” a Frontier Labs. Quién sabe. Quizá sea posible. Los labs frontera tienen mucho cómputo confiable, pero la Tierra es mucho más grande y tiene muchísimo cómputo no confiable. Si metes un sistema de verificación que lo maneje, la multitud podría encontrar soluciones mejores, y la gente aportaría ciclos a lo que le importa.
Última idea: muchas empresas u organizaciones tienen cosas que les importan. Si tú tienes cómputo, podrías contribuir a distintos AutoResearch: quizá te importa el cáncer o algo así. En lugar de donar a una institución que compra cómputo, te unes al foro/proyecto de AutoResearch y aportas cómputo al pool. Sí, es muy inspirador. También es interesante: hay públicos en Silicon Valley y otros lugares que descubren que vuelve a ser interesante usar PCs personales.
Sí.
Correcto. Así que quizá estén motivados para montar sus propios agentes en segundo plano y también aportar a AutoResearch.
Casi como si el dólar fuese algo que le importa a todo el mundo, pero ¿los FLOPs serán lo que le importe a todo el mundo en el futuro? ¿Cambiar