DruckFin

Transcripción de Google: Jeff Dean sobre la especialización de hardware de inferencia y los sistemas de IA autorregulados

Y Combinator Startup School 2026, 20 de septiembre de 2026

¿Son los modelos de IA ya ingenieros junior?

Diana Hu: Muy bien. ¿Empezamos, Jeff?

Jeff Dean: Claro. Me parece perfecto.

Diana Hu: Muy bien. Jeff, bienvenido. Y de nuevo, muchísimas gracias por estar aquí. Especialmente porque acabo de pescar un resfriado, te agradezco mucho tu presencia.

Jeff Dean: Sí, me temo que he perdido la voz. No suelo sonar así, pero haremos lo que podamos.

Diana Hu: Has construido MapReduce, Bigtable, TensorFlow, la TPU, Gemini. Podríamos pasar una hora entera repasando todo lo que has hecho, pero lo que me encanta es que sigues haciendo predicciones audaces en público. El año pasado, en mayo de 2025, en AI Ascent, dijiste que la IA está al nivel de un ingeniero junior. Eso fue hace aproximadamente un año. ¿Qué tan cerca estamos de esa predicción?

Jeff Dean: Sí, o sea, siento que los modelos han mejorado mucho en tareas de programación basadas en agentes y de mayor duración. Parece bastante claro que ahora son bastante capaces. Dependiendo exactamente de tu definición de ingeniero junior, diría que es una predicción bastante acertada.

Diana Hu: ¿Qué subestimaste de esa predicción?

Jeff Dean: Creo que la capacidad para realizar tareas cada vez más complejas ha crecido más rápido de lo que pensaba. También creo que, fuera de la programación, estos sistemas basados en agentes están empezando a destacar realmente en otros dominios. Pienso que esa será una tendencia importante en el futuro.

Diana Hu: Danos otra predicción audaz. ¿Cuál crees que será la edición 2027?

Sistemas de IA que se mejoran a sí mismos

Jeff Dean: Creo que veremos mucha más automatización de los propios sistemas de ML. Básicamente, lograr que los sistemas de ML mejoren sus capacidades ejecutando montones de experimentos, descomponiendo los problemas en subproblemas, ejecutando esos subproblemas en un bucle cerrado de experimentación automática, uniendo los resultados y logrando obtener un sistema mejorado a partir de esa descomposición de problemas y experimentación totalmente automatizadas. Creo que eso va a ser muy emocionante. Pienso que esto se aplica no solo al ML, sino también a otros campos de la ciencia y la ingeniería. Básicamente, cualquier ámbito donde se pueda tener un objetivo medible es uno en el que creo que se puede avanzar mucho hoy en día.

Diana Hu: Ahora retrocedamos un poco en la historia. Allá por 2001, Google Search funcionaba con discos duros.

Jeff Dean: Sí.

Diana Hu: Y tú y Sanjay hicieron los cálculos y se dieron cuenta de que, en algún momento, todo el índice de búsqueda cabría finalmente en toda la memoria RAM de todas las computadoras que tenían en funcionamiento. Tomaron esa decisión radical y, básicamente, en pocos días con Sanjay, lanzaron a producción una versión de búsqueda completamente nueva que funcionaba en la RAM en lugar de en discos duros. Eso fue lo que hizo que las búsquedas de Google fueran tan rápidas. La historia tiende a repetirse de otra forma. ¿Cuál es el momento "cabe en la memoria" de ahora, en 2026, en el que todos los presentes en esta sala deberían estar pensando y diseñando?

El avance de Google Search que lo cambió todo

Jeff Dean: Sí, bueno, es un poco diferente, pero creo que vamos a ver cada vez más sistemas de hardware de inferencia de alto rendimiento y bajo consumo energético. Pienso que todo el mundo se está dando cuenta ahora de que la inferencia es la clave para que estos sistemas basados en agentes estén al alcance de cada vez más personas, que la latencia es realmente importante y que la especialización del hardware es una vía fundamental para fabricar dispositivos que consuman menos energía y ofrezcan menor latencia en comparación con dispositivos de cómputo de propósito más general como, digamos, las GPUs o las TPUs. Todos los que están aquí están acostumbrados a esperar respuestas de los modelos. Esperar no es divertido.

Diana Hu: Dominar la velocidad. O sea, ¿estás diciendo que qué pasaría si ya no tuviéramos que esperar?

Jeff Dean: Sí. Imagina lo que podrías hacer con algo cuya latencia sea 50 veces mejor.

Los agentes de IA funcionarán durante semanas

Diana Hu: Qué pensamiento tan interesante. Ahora bien, ¿cuál es una suposición que quizás 6.000 personas en esta sala sostienen y que ya es falsa sobre la IA?

Jeff Dean: Es una buena pregunta. Probablemente una de ellas es que la gente no termina de dimensionar lo posible que es contar con sistemas basados en agentes que puedan ejecutarse no solo durante una o dos horas en un problema que te importa, sino que, en ciertos dominios problemáticos y con modelos altamente capaces como base, puedes lograr que funcionen durante días o semanas y resuelvan tareas verdaderamente complejas. Algunas personas están empezando a ver indicios de esto, pero no creo que todos lo hayan interiorizado realmente. Eso va a ser un asunto bastante importante.

Diana Hu: ¿Cuál es una tarea en particular que hayas ejecutado y que haya corrido durante semanas? ¿De qué se trataba? ¿Qué les dijiste a los agentes que resolvieran?

Jeff Dean: Puedes indicar a los agentes que se encarguen de implementar versiones completamente nuevas de software en diferentes lenguajes de programación que puedan tener mejores propiedades de seguridad o de rendimiento, y luego ellos pueden ir y ejecutar eso de manera bastante seria.

Las matemáticas de servilleta que llevaron a las TPUs

Diana Hu: Eso es bastante genial. Ahora bien, algo por lo que eres muy conocido es que eres realmente bueno haciendo cálculos en una servilleta. Suena divertido. Una de las historias sobre ti es que, allá por 2013, cuando el reconocimiento de voz empezó a funcionar en Google, hiciste el cálculo en una servilleta de que si cada usuario de Google usaba su teléfono, le hablaba y utilizaba el sistema de reconocimiento de voz durante solo 3 minutos al día, tendrías que duplicar la flota de servidores de Google, lo cual sería sumamente costoso solo para hacer traducción de voz.

Jeff Dean: Sí.

Diana Hu: Y en su lugar, básicamente construiste un chip personalizado, y esa fue la historia de origen de la TPU.

Jeff Dean: Sí. Estábamos empezando a ver resultados de muy buena calidad en los modelos de voz basados en aprendizaje profundo que estábamos entrenando, pero eran computacionalmente costosos en comparación con el antiguo sistema de voz. Sin embargo, redujeron la tasa de error a la mitad. Eso equivalía a 20 años de avances en reconocimiento de voz en apenas unos meses de trastear con el modelo, escalarlo un poco y obtener mejores datos. Así que empezamos a preocuparnos de que, si la voz funcionaba mucho mejor, la gente la usaría más. Ese cálculo de servilleta trataba realmente sobre eso. ¿Qué pasaría si la gente empieza a usar más el reconocimiento de voz para dictar correos electrónicos, hablar con su teléfono o lo que sea? Resultó que nos dimos cuenta de que necesitábamos una solución mejor que ejecutarlo en CPUs en ese momento. Así que ideamos las TPUs, que están muy especializadas esencialmente en álgebra lineal densa de baja precisión, la cual se encuentra en el núcleo de casi todos los algoritmos modernos de aprendizaje automático que utilizamos hoy en día. Si construyes un chip especializado en álgebra lineal densa de baja precisión y no puede hacer nada más, resulta ser muy útil para la inferencia de aprendizaje automático, aunque no pueda ejecutar Chrome, Word o lo que sea. Eso produjo un chip un par de años después que era entre 30 y 80 veces más eficiente en energía que las CPUs y GPUs de la época, y también con una latencia muchísimo menor, entre 20 y 30 veces más baja.

Diana Hu: Lo cual es increíble, considerando los cimientos en los que se ha convertido la TPU hoy en día. No hay forma de que hubieras predicho que la TPU sería tan fundamental ahora con la arquitectura transformer, que se inventó mucho después de que realmente inventaras la TPU.

Jeff Dean: Sí, por eso construimos un sistema de álgebra lineal de propósito general, que es lo que realmente es una TPU. Sabíamos que los algoritmos de ML seguían evolucionando y que no querías sobre especializarte, pero sí lo suficiente como para obtener los drásticos beneficios de rendimiento de contar con unidades multiplicadoras muy grandes. Podíamos tener memoria de alta velocidad. Podíamos contar con interconexiones de alta velocidad para las TPUs posteriores que ponían muchos, muchos chips al servicio del mismo problema de manera eficiente. Hemos seguido escalando esos sistemas y mejorando su rendimiento a lo largo de muchas, muchas generaciones hasta ahora.

Cómo encontrar ideas revolucionarias

Diana Hu: Increíbles matemáticas de servilleta. Las servilletas son útiles. Entonces, en realidad, ¿cuál es un buen cálculo de servilleta que todos los presentes aquí que aspiren a ser futuros fundadores deberían hacer esta noche para construir potencialmente algo tan trascendental como la TPU?

Jeff Dean: Siempre es difícil de decir. Piensa en qué problemas ves en cualquier cosa en la que estés pensando, qué cuellos de botella identificas y si existen formas muy diferentes de plantear las soluciones a algunos de esos problemas que te otorguen un orden de magnitud o dos órdenes de magnitud de mejora en rendimiento, capacidad o lo que sea. Porque a veces, si miras de reojo un problema y piensas no necesariamente en estar anclado a exactamente cómo se resuelve ese problema hoy en día, sino en cómo lo resolverías desde los principios fundamentales (first principles), puedes dar con ideas realmente buenas que tal vez no sean en las que otros están pensando.

El nuevo modelo mental del ingeniero de IA

Diana Hu: Ese es un buen consejo. Para todos los presentes que no lo sepan, hace años Jeff escribió una lista muy famosa llamada "Números de latencia que todo científico informático debería conocer". Estos son números sobre, por ejemplo, cuánto tarda un fallo de caché (cache miss), una búsqueda en disco, un paquete de red viajando, digamos, desde California hasta los Países Bajos, un montón de números de este tipo sobre sistemas distribuidos e ingeniería de sistemas. Se ha impreso y se ha convertido en la biblia de muchos ingenieros de sistemas distribuidos. Avanzando rápidamente hasta el presente, esa lista está lista para una actualización. Danos la edición de IA para ahora, en 2026.

Jeff Dean: Si miras lo que es importante en los sistemas de IA hoy en día, querrás conocer cosas como el ancho de banda entre el sistema de memoria principal de tu acelerador y la memoria en el chip (on-chip), hasta la unidad multiplicadora. Quieres saber cuánta energía consume realizar una sola operación de multiplicación. ¿Cuál es el ancho de banda de interconexión entre chips y cuántos chips puedes conectar con ese ancho de banda? Y luego, si vas más allá de ese dominio, ¿cuál es la caída en el ancho de banda de la red cuando necesitas comunicarte con 10.000 chips en lugar de con 500? Pongo esto como ejemplo de números muy importantes que hay que aprender, y que realmente afectan la forma en que concibes la resolución de ciertos tipos de problemas.

Diana Hu: Algo interesante que te he escuchado comentar es que, hoy en día, la unidad en la que mides todo es la energía.

Jeff Dean: Sí.

Diana Hu: Señalaste que hacer un cálculo matemático cuesta alrededor de 1 picojoule, pero mover los datos y realizar operaciones de E/S de datos (I/O) cuesta mil veces más.

Jeff Dean: Sí. Simplemente traerlos desde la HBM en un acelerador hacia el procesador para que realmente pueda calcular sobre ellos.

Por qué la IA es en realidad un problema de energía

Diana Hu: Sí. Esa brecha decide silenciosamente qué productos son posibles y cómo se construyen estos algoritmos de IA. ¿Cuáles son los tipos de problemas que los fundadores siguen llamando problemas de modelos, pero que en realidad son problemas de energía o de E/S de datos?

Jeff Dean: El ejemplo que mencionaste sobre una diferencia de 1.000 veces entre mover datos y calcular realmente sobre ellos en términos de energía es bastante significativo, y da forma a muchos aspectos de lo que hacemos en el aprendizaje automático. Porque si no tuvieras esa diferencia de 1.000 veces, entonces no tendrías que hacer lotes (batching). Pero tienes que agrupar lotes con muchos ejemplos o muchos tokens a la vez para amortizar ese movimiento de datos, de modo que no pagues una ralentización de 1.000 veces, sino que pagues un coste energético de 1.000 veces dividido por el tamaño del lote. Para una latencia muy baja, el procesamiento por lotes no es realmente muy bueno. Este tipo de cosas y la energía detrás de varias decisiones en el hardware informático que utilizamos afectan profundamente a muchas de las decisiones que tomamos al construir sistemas de mayor nivel.

Diana Hu: Un ejemplo muy concreto es cómo se realiza el entrenamiento de los modelos. Existe todo este concepto de agrupar conjuntos de datos en lotes y ejecutar épocas (epochs). La gente tal vez pueda confundir esto con un problema del modelo, pero en realidad es un problema de E/S de datos de sistemas, ¿verdad?

Jeff Dean: Sí. Tienes que ensamblar lotes para obtener una mejor eficiencia en tu hardware. Idealmente, podrías hacer un entrenamiento con un tamaño de lote de 1, pero no es tan bueno en términos de eficiencia. Así que hoy en día la gente utiliza lotes bastante grandes.

Diana Hu: Eres muy conocido por tomarte una semana larga o un fin de semana y salir con una solución brillante. ¿Existe algo así como que Jeff vaya a trabajar en ello durante un par de semanas y logre hacer un entrenamiento con un tamaño de lote igual a 1?

Jeff Dean: He estado pensando más en la inferencia, la verdad. La inferencia es un problema bastante interesante porque sí requieres una latencia muy baja. En el entrenamiento, no necesariamente necesitas una latencia increíblemente baja. Pienso que hay mucho margen para especializar más el hardware de cara a la inferencia en comparación con lo que hacemos hoy.

Diana Hu: ¿Cuáles son algunas de esas cosas interesantes sobre la inferencia en las que estás pensando mucho?

Jeff Dean: Simplemente tratar de minimizar el movimiento de datos, pensar en operaciones de precisión increíblemente baja y tal vez no dar soporte a muchísimos tipos diferentes de precisiones. Si sientes que tienes una buena respuesta sobre qué tipo de precisión necesitas, tal vez solo constrúyelo en el hardware y nada más.

Diana Hu: Lo cual nos lleva a una analogía central que escuché de destacados científicos informáticos: que, en realidad, todo el proceso de la IA es un gran problema de compresión. Para que los datos tengan pérdida (lossy), comprimirlos y luego restaurarlos, básicamente necesitas comprenderlos.

Jeff Dean: Si realmente entiendes los datos, deberías ser capaz de comprimirlos muy bien.

Diana Hu: Y ahora la arquitectura transformer es básicamente una de las formas en que ha resultado funcionar muy bien.

Jeff Dean: Sí, funciona bastante bien hasta ahora. Buen trabajo por parte de mis colegas.

La ingeniería de contexto es la próxima frontera

Diana Hu: Sí. Ahora alejemos un poco la lente. El progreso de la IA solía significar simplemente mejores modelos. Tenías más datos, entrenabas modelos con parámetros más grandes. Pero cada vez más, en el último año más o menos, se trata de todo lo que rodea al modelo. No solo el tamaño del modelo y el número de parámetros o más datos, es todo lo que orbita alrededor de cosas como la recuperación de información (retrieval), herramientas, memoria, herramientas de agentes, y todo eso podría consolidarse en lo que la gente llama ingeniería de contexto, ¿verdad?

Jeff Dean: Sí. El modelo es en realidad solo una pieza de lo que intentas hacer, que consiste en construir un sistema global capaz de resolver problemas verdaderamente interesantes. Eso implica un modelo que sepa cómo utilizar varias herramientas. Quizás sepa cómo recuperar información relevante, tal vez tenga un historial de otra información que haya recuperado para problemas pasados, y pueda poner información en el contexto del modelo. Lo bueno de eso es que la información es muy clara para el modelo, a diferencia de los datos de entrenamiento con los que se entrenó el modelo, donde todo está como mezclado en billones de tokens en una sopa de cientos de miles de millones o billones de parámetros, pero todo es menos claro que el contexto real que el modelo ve directamente para este problema o caso de uso en particular.

Jeff Dean: Luego, ser capaz de entender qué herramientas están disponibles, cuáles van a ayudar al modelo a resolver esta siguiente fase del problema, cómo descomponer un problema en una secuencia de llamadas a herramientas (tool calls), tal vez probar múltiples enfoques para resolver el problema y ver cuáles funcionan, y ser capaz de evaluar eso. Toda esta orquestación de sistemas de agentes complejos y multiagente es lo que creo que va a ser cada vez más importante. Tiempos súper emocionantes, diría yo.

Diana Hu: Lo divertido de este conjunto de dominios problemáticos es que en realidad es algo que todos en esta sala pueden hacer. Antes, para entrenar un modelo, necesitabas una cantidad increíble de recursos, un acceso descomunal a GPUs y datos. Pero para la ingeniería de contexto, cualquiera aquí puede hacerlo. Solo necesitas la API de algo como Gemini y luego trabajar en tu propia configuración para tu propia recuperación, tus propias llamadas a herramientas, etcétera. ¿Cuáles son algunos consejos para los presentes? ¿Cómo puede uno volverse mejor y excepcional en la ingeniería de contexto?

Jeff Dean: Una forma muy buena de hacerlo es utilizar estos modelos, entornos de ejecución (harnesses) y herramientas para intentar resolver problemas, y entonces a veces puedes ver exactamente dónde están fallando los modelos. A menudo, puedes hacer que el modelo funcione mejor y tenga éxito en ese tipo de problema no solo ajustando los parámetros del modelo —lo cual es difícil de hacer desde el exterior—, sino creando mejores directrices para el modelo, escribiendo habilidades (skills) para que el modelo sepa cómo utilizar diferentes herramientas que serían increíblemente útiles para resolver esta clase particular de problema. A medida que haces eso, terminas en este tipo de configuración de auto-mejora con la que intentas resolver las cosas. Esa es una forma excelente de mejorar tu comprensión de qué información adicional querría el modelo para volverse más capaz.

La habilidad que hizo que la IA mejorara en optimización

Diana Hu: ¿Puedes dar un ejemplo de algo de ingeniería de contexto que tú personalmente hayas hecho, de habilidades que hayas escrito o herramientas que realmente hayan marcado una gran diferencia en tu flujo de trabajo?

Jeff Dean: Sanjay y yo estuvimos trabajando hace unas semanas, y a menudo realizamos cierta cantidad de mejoras de rendimiento para bibliotecas de muy bajo nivel. Tenemos una biblioteca de microbenchmarks que escribimos en Google donde puedes redactar microbenchmarks sobre cuánto tardan diferentes tipos de operaciones o cuánto tarda en poblarse esta estructura de datos. A veces, esas estructuras de datos se utilizan en millones de procesos en todo Google, por lo que es bastante importante asegurarse de que tengan un alto rendimiento. Puedes escribir microbenchmarks, pero sin un sistema basado en agentes, lo que normalmente haces es medir cuál es el rendimiento actual en algunos benchmarks que te importan, hacer algunas modificaciones para mejorar el rendimiento, volver a ejecutar los benchmarks para ver dónde mejoraron las cosas, ejecutar un conjunto más amplio de benchmarks y medir la huella de caché de las cosas.

Jeff Dean: Escribimos una habilidad que básicamente le enseñaba al modelo a hacer la mayoría de esas cosas en varias secuencias para que pudiera realizar mediciones de benchmarks auto-mejoradas, cambios de código, medir la mejora del rendimiento e iterar sobre eso. Eso pareció funcionar bastante bien para ciertos tipos de problemas. En realidad, se trata simplemente de transmitirle al modelo el enfoque que utilizaríamos nosotros como personas, pero en un formato que él pueda usar.

Diana Hu: Vaya, eso parece muy impresionante. Así que estás diciendo que tienes esta habilidad y que, si alguien tuviera acceso a ella, podría realizar optimizaciones como Jeff Dean. Parece que al mundo le encantaría esto y valdría una cantidad infinita de dinero para alguien tener acceso a ella.

Jeff Dean: De hecho, publicamos un documento hace quizás unos meses llamado "Performance Hints" [Consejos de rendimiento] que escribimos Sanjay y yo. Es como un documento de 30 páginas sobre varios tipos de trucos de rendimiento. Algunas personas han tomado eso, se lo han dado en forma resumida a varios modelos y han visto que el modelo ahora puede mejorar en el razonamiento sobre problemas de rendimiento en el código.

Diana Hu: Lo escucharon aquí mismo. Podrían optimizar su propio código como Jeff Dean si toman este documento que publicaron, "Performance Hints".

Jeff Dean: Sí. Está disponible de forma gratuita, así que todos deberían probarlo.

Por qué fallan los agentes de larga duración

Diana Hu: Muy interesante. Ahora bien, estás hablando de agentes. Probablemente todos aquí estén construyendo uno o hayan construido uno en algún momento. Estoy seguro de que todos han visto a su agente descarrilarse quizás en el paso 30 o 40. Los agentes son geniales hasta el paso 10 más o menos, y luego empiezan a tambalearse en el paso 50. ¿Cuál crees que es el freno hoy en día? ¿Son los evaluadores de contexto o simplemente errores que se acumulan porque básicamente es un sistema de lazo abierto (open-loop)?

Jeff Dean: Obviamente, queremos que los agentes puedan funcionar durante períodos de tiempo muy prolongados porque así es como van a resolver problemas cada vez más complejos. Pero como observas hoy en día, a veces dejan de funcionar después de 10 interacciones con las herramientas. A veces se debe a que el modelo está intentando hacer algo para lo que no tiene mucha experiencia. Ha sido entrenado en todo un conjunto de cosas, y tan pronto como te sales un poco de la distribución de las cosas que sabe hacer, al igual que la mayoría de los modelos de aprendizaje automático, su rendimiento comienza a degradarse. Cuanto más te alejas de la zona de confort de lo que sabe hacer, más probable es que no funcione tan bien.

Jeff Dean: Hay un montón de cosas que puedes hacer. Una de ellas es proporcionar al modelo habilidades y pistas que tiendan a mantenerlo en el camino más iluminado de las cosas que sí sabe hacer. Tener sistemas multiagente donde dispones de varios agentes probando diferentes enfoques, y cuentas tal vez con otro modelo u otro agente evaluando cuáles de ellos parecen prometedores, es otra forma de explorar el espacio de posibles soluciones, ceñirse a las que parecen más prometedoras y descartar aquellas que no parecieron funcionar o que se descarriaron. Esa es una técnica general muy útil: el cómputo en tiempo de inferencia (inference-time compute) para realizar búsquedas sobre formas plausibles de resolver el problema, lo que puede conseguir un rendimiento mucho mayor o una fiabilidad muy superior en flujos de agentes de larga duración.

Diana Hu: ¿Cuáles son algunas de las formas en que implementaste este flujo de trabajo particular para tus agentes de manera interna?

Jeff Dean: Tenemos entornos de ejecución (harnesses) y luego todo un conjunto de habilidades, particularmente en el entorno de desarrollo interno de Google. Tenemos habilidades para que los agentes sepan cómo utilizar una gran cantidad de nuestras herramientas internas para programación, revisiones de código, medición de rendimiento o recuperación de archivos de registro (log files). Esas son simplemente habilidades que puedes añadir para hacer que el modelo base sea más capaz, a pesar de que no necesariamente haya sido entrenado exactamente en la forma en que los ingenieros internos de Google obtendrían archivos de registro de nuestro sistema propietario. Con el tipo adecuado de definición de habilidades, de hecho puedes lograr que funcione, y eso mejora la utilidad de los agentes.

Dónde las startups aún pueden vencer a Google

Diana Hu: Hablemos ahora de dónde pueden ganar las startups. Esta sección es una que me importa mucho personalmente porque todos en esta sala necesitan decidir qué construir en el futuro si son futuros fundadores. El caso de Google es que codesarrollan todo en el sistema, desde los procesadores hasta los productos. ¿Cuáles son las capas que alguien como Google seguirá construyendo, perfeccionando y dominando, y en cuáles puede ganar todavía un equipo de dos o tres personas?

Jeff Dean: Obviamente, Google, nuestros modelos Gemini y nuestra infraestructura de hardware realmente intentan construir modelos muy generales que puedan hacer casi cualquier cosa. Pero en muchos casos, eso significa que no prestamos mucha atención a dominios particulares donde tal vez una interfaz muy bien diseñada, y quizás un modelo junto con un conjunto de habilidades, o un modelo especializado que no esté en la mezcla general de cosas que nuestros modelos hacen bien, pueda de hecho tener una ventaja significativa. Puedes construir algo encantador, de altísima precisión y altísima calidad para un dominio que te apasione de verdad. Ahí es donde dos o tres personas en una habitación construyendo eso pueden tener ventaja.

Jeff Dean: Pero también advertiría que los modelos generales están mejorando definitivamente en un rango cada vez más amplio de cosas. Así que tienes que averiguar: ¿va a ser duradero eso en lo que estás trabajando, o crees que los modelos a la vanguardia van a mejorar en eso en los próximos 6 o 12 meses, o es algo que no van a poder hacer hasta dentro de 2 o 3 años? Quieres sopesar eso al decidir en qué trabajar.

Diana Hu: En los modelos generales, por supuesto, van a seguir trabajando y mejorando. ¿Cómo debería razonar la audiencia sobre qué áreas elegir y en cuáles trabajar?

Jeff Dean: Lo más importante es elegir algo que te entusiasme muchísimo, que quieras construir y que pienses que sería útil en el mundo. Si haces eso, ya vas muy por delante en comparación con si te despiertas y piensas: "Realmente no quiero hacer esto", o si construyes algo que en realidad no es tan útil para el mundo o para mucha gente. Ese es el criterio de selección número uno que intento aplicar para determinar en qué problema debo trabajar a continuación.

Jeff Dean: En segundo lugar, creo que debes observar qué pueden hacer los modelos actuales más generales en ese dominio problemático. Puedes ponerlos a prueba: ¿son capaces de hacer esto muy bien? Si están fallando por completo, eso es probablemente una buena señal. Si son más o menos capaces de hacer una parte, pero no muy bien, eso quizás no sea una gran señal. Probablemente sea un indicio de que la capacidad está empezando a estar presente en esos modelos y que, con más datos de entrenamiento, modelos a mayor escala o lo que sea, es probable que mejore. Busca algo en lo que el modelo tenga éxito un 0% o un 1% de las veces, no un 20%.

Diana Hu: ¿Cómo encuentras esas cosas? ¿Son elementos que están efectivamente fuera de la distribución (out of distribution) del conjunto de entrenamiento, y cuál es exactamente la forma del problema que encaja con eso?

Jeff Dean: A veces es un producto que construyes y que podría tener acceso a un tipo particular de datos a los que un modelo general podría no tener acceso. Podría ser que estés construyendo algo para ayudar a los usuarios a organizar toda su información personal, y el modelo general no tendrá necesariamente acceso a eso. Ahí puedes tener una gran ventaja porque, de repente, tu producto tiene visibilidad sobre datos importantes.

Jeff Dean: Podría tratarse de algún problema increíblemente difícil donde, si consigues los datos de entrenamiento adecuados y puedes entrenar un modelo más específico que uno de propósito general, de hecho puedes lograrlo de una manera muy asequible. Tal vez no requiera tanto cómputo entrenar un modelo de nicho para este problema en particular, pero puedes obtener algo que sea altamente preciso. Eso puede ser a veces un bloque de construcción realmente bueno para resolver un problema importante que quizás no sea manejado muy bien por el modelo general.

Diana Hu: Básicamente hay dos caminos. El primer camino es un poco gracioso: ustedes están organizando la información del mundo, eso está bien cubierto, pero organizar la información personal está abierto. El segundo camino: hablaste de modelos más especializados en ciertos dominios. ¿Puedes contarnos más sobre cuáles son algunos de esos dominios?

Jeff Dean: Si miras el trabajo de mis colegas en AlphaFold, ese fue un modelo muy específico para el plegamiento de proteínas. Fue sumamente exitoso y pudo manejar ese dominio bastante bien, de modo que de repente cuentas con esta herramienta y modelo asombrosos que pueden darte respuestas a preguntas sobre las proteínas y su estructura de manera verdaderamente eficaz. Pero no es un modelo general; es uno muy específico. Hay otros dominios donde ese tipo de enfoque puede funcionar muy bien, tal vez en ciencia de materiales o diseño de chips, lo que te permitirá aprovechar las capacidades de un modelo de nicho pero muy preciso para hacer cosas que hoy en día son difíciles.

Cómo convertirse en un fundador nativo de IA

Diana Hu: Si algunos de ustedes encuentran un problema de una forma similar a AlphaFold, podría ser un buen problema en el que trabajar. Ahora supongamos que ya encontraron un problema en el que trabajar. Vamos a hablar un poco sobre cómo convertirse en un fundador nativo de IA. En el pasado, dijiste que gestionar una flota de 50 o 100 agentes consiste en escribir documentos de diseño (design docs) o especificaciones realmente buenos y nítidos. ¿Cómo se vuelve la gente buena en eso? ¿Cómo son esos documentos?

Jeff Dean: Tendrás mucho más éxito al trabajar con tus agentes virtuales si puedes especificar claramente qué es lo que quieres. Cuanto más claro seas sobre lo que deseas, más directrices y esquemas tendrá el agente de lo que está intentando lograr. En cambio, si no especificas gran cosa, el agente tiene qué deducir lo que querías decir. En muchos casos, puede inferir cosas diferentes a las que habías imaginado. Siempre le hemos dicho a los científicos informáticos desde el principio que es muy importante especificar qué se supone que debe lograr el software que estás escribiendo antes de ir a escribirlo. Ahora tenemos de hecho sistemas basados en agentes que pueden hacer la escritura, pero la importancia de especificar qué es lo que quieres ha aumentado en realidad. Antes, se lo entregarías a un ser humano muy inteligente que quizás tenga contexto o pueda hacerte preguntas de seguimiento. Los agentes a veces pueden hacer eso, pero las especificaciones claras son una idea excelente.

Jeff Dean: Para darte un ejemplo de un uso de un agente de programación que funciona extremadamente bien: puedes pedirle a los modelos actuales que traduzcan software de un lenguaje informático a otro de manera muy eficaz. En ese caso, de hecho tienes una especificación increíblemente detallada: tienes todo el software que indica lo que se supone que debe hacer el sistema. Si tienes una implementación en Python de algo y quieres una implementación en Go, eso es algo para lo que los modelos parecen increíblemente capaces hoy en día. Puede tomar todas las pruebas (tests) que están en Python, traducirlas a Go, asegurarse de que pasen en la versión de Go, comparar las diferencias de comportamiento entre las implementaciones hasta que no quede ninguna, y ser sumamente eficaz porque esa especificación es muy clara.

Diana Hu: Ahora supongamos que cada fundador se vuelve experto en ejecutar cientos de agentes al mismo tiempo y que los agentes escriben todo el código por ellos. ¿Cuál se convierte en la habilidad escasa?

Jeff Dean: Tener un gusto increíblemente bueno sobre qué pides a tus agentes que trabajen. Ese es el quid de un problema de investigación desde mi perspectiva. Un investigador puede tener todas las herramientas y todas las técnicas, pero a menudo la mayor parte de la batalla consiste en en qué problema vas a gastar tu tiempo. Si eliges bien el problema y tienes éxito al resolverlo, eso es mucho mejor que si ejecutas de forma encantadora una investigación científica sobre un problema bastante aburrido. Esa sabiduría de alto nivel sobre en qué trabajar es increíblemente importante, y creo que los modelos no van a ser necesariamente tan buenos en eso. Vas a tener personas dirigiendo una gran cantidad de computación asistida por IA para lograr grandes cosas y más rápido. Esa esencia de lo que quieres que hagan tus modelos es la clave en la que debes centrarte.

Diana Hu: Hablemos un poco más sobre el gusto, porque se habla mucho de ello ahora mismo en esta era actual de programación con agentes. ¿Cómo se cultiva el gusto? ¿Cómo se hace algo concreto?

Jeff Dean: Es algo difícil. No es como si hubiera un objetivo medible del gusto en muchos casos. Parte de ello proviene de la experiencia. Haber trabajado en un montón de problemas diferentes en el pasado te enseña de alguna manera sobre qué tipo de qué problemas podrían ser interesantes en el futuro, o qué clase de cosas podrían ser apenas posibles juntando enfoques anteriores, y luego cuáles son los problemas abiertos en los que tendrías que trabajar para llegar a algo mágico o sumamente útil.

Jeff Dean: Otra forma en que puedes adquirir más experiencia por ti mismo es anotar un montón de cosas que creas que podrían ser importantes en los próximos 12 meses. Tal vez elijas una de ellas para trabajar en ella, pero regresa y evalúa dentro de 12 meses cuáles de esas otras cosas realmente parecieron importantes, cuáles fueron a crear otras personas en el mundo y cuáles aún no parecían haber hecho. Eso puede darte muchas más muestras para tu propia capacidad de creación de gusto. Esa es una habilidad importante que hay que tener.

Cuestiona tus mayores suposiciones

Diana Hu: Una tercera forma de la que hablábamos antes era realizar experimentos mentales muy locos.

Jeff Dean: Esa es otra buena manera. A veces es bueno no dar por sentado cosas que la mayoría de la gente parece dar por sentadas. El otro día estaba haciendo un experimento mental loco con unos colegas. Durante 60 años, toda la industria de diseño y fabricación de chips de silicio ha hecho un trabajo tremendo para fabricar transistores a una escala cada vez más pequeña y con una tasa de errores muy baja. La suposición que queremos es que cada chip que fabricamos del mismo diseño debe ser idéntico a cualquier otro chip. No quieres que ningún bit se voltee; ningún bit debe cambiar. Se han integrado todo tipo de márgenes de error, y las memorias tienen hoy en día memoria ECC.

Jeff Dean: A macroescala, no hacemos esa suposición cuando construimos sistemas distribuidos a gran escala. Construimos sistemas de archivos distribuidos fiables a gran escala a partir de piezas poco fiables. Los discos individuales pueden fallar, pero tus datos deben estar seguros. Tenemos mecanismos a un nivel superior para permitirnos tener tres copias de los datos en tres máquinas diferentes y tres bastidores (racks) diferentes, de modo que si cualquier conmutador de rack, máquina individual o disco falla, sigues teniendo tus datos. Tenemos técnicas de codificación Reed-Solomon. Pero no parece que hagamos esto a un nivel verdaderamente extremo en la escala a nivel de transistores de la tecnología en la que estamos trabajando.

Jeff Dean: Un experimento mental interesante es: ¿qué pasaría si intentaras construir un sistema a partir de transistores que pudieran tener 20 errores al día en lugar de uno cada millón de años? Ese sería un punto de diseño muy diferente y podría permitirte hacer cosas realmente interesantes en el lado de la fabricación. Tendrías metodologías de diseño muy diferentes, porque si quieres enviar una señal de aquí para allá y tienes estos transistores súper poco fiables, podrías tener formas muy distintas de señalización. Podrías enviarla a través de múltiples rutas redundantes para asegurarte de que llegue por alguna de ellas. Creo que ese sería un conjunto de experimentos mentales bastante interesante. No digo que debamos ir a hacer esto, pero ese es el tipo de cosas en las que uno sí quiere cuestionar ocasionalmente las suposiciones. A menudo estos experimentos mentales no funcionan porque hay muy buenas razones por las que durante los últimos 50 años hemos hecho esto de esta manera y no de otra, pero es bueno revisarlas de vez en cuando.

Diana Hu: Eso es una locura. Empieza a rimar mucho con la computación neuromórfica o con el cerebro humano y cómo funciona la naturaleza.

Jeff Dean: Las señales en nuestro cerebro no son especialmente fiables para ir de un lugar a otro. En los cerebros, cuando hay cosas realmente importantes que necesitas trasladar de un sitio a otro, existen múltiples vías que te permiten hacerlo.

Diana Hu: ¿Cuál es una de esas suposiciones locas que tiraste por la ventana y que realmente construyó un sistema trascendental en el pasado?

Jeff Dean: Las TPUs son un buen ejemplo: poder especializar el hardware para un dominio problemático muy de nicho antes de que ese dominio pareciera tan importante como lo es hoy. El origen de MapReduce es otro buen ejemplo. Sanjay, yo mismo y varios otros colegas habíamos trabajado en varias iteraciones del sistema de rastreo (crawling) e indexación en Google. Habíamos escrito montones de código paralelizado a mano con un montón de puntos de control (checkpointing) para asegurarnos de que fuera robusto y fiable si se ejecutaba en 100 computadoras o 1.000 computadoras y algunas de ellas se caían. Pero ese código tendía a entremezclarse con la cosa relativamente simple que a menudo intentabas hacer, como examinar todos los contenidos de todas las páginas web y calcular al margen una asignación (mapping) de la URL al idioma en el que está la página. Quedaba oscurecido por todo este otro código de paralelización y fiabilidad.

Jeff Dean: Recordamos nuestra formación en lenguajes funcionales y nos dimos cuenta de que podíamos mirar esos problemas de reojo y desarrollar esta abstracción de MapReduce por encima de la implementación. Debajo de la implementación, podías colocar todos los mecanismos de puntos de control y fiabilidad en esa biblioteca de nivel inferior sobre la cual todo lo demás podía construirse. Eso se convirtió en una forma enormemente exitosa de lidiar con cálculos a muy gran escala en Google de una manera robusta y fiable, a partir de ese experimento mental de: si lo miramos de reojo, ¿podríamos encontrar montones de problemas que encajaran en esta abstracción?

IA que construye una mejor IA

Diana Hu: Hablaste un poco sobre tu interés actual en trabajar en hardware personalizado. En este momento, AlphaChip diseña la disposición física de los chips. También tienes AlphaEvolve, que propone soluciones, las evalúa y se queda con todas las que funcionan. Parece que estás empezando a construir sistemas que pueden multiplicarse y construir una IA que construye otra IA.

Jeff Dean: Más en general, existe este fundamento del método científico: propones un experimento, implementas lo que necesitas para ejecutar el experimento, evalúas el experimento y luego obtienes resultados de eso. Cada vez hay más problemas en los que ahora es posible implementar un escenario donde todo ese bucle de ejecutar no solo unos pocos experimentos, sino ejecutar muchísimos experimentos —porque eres capaz de automatizar ese bucle y hacer que la latencia de ese bucle sea extremadamente baja— va a ser realmente importante. Nos va a permitir abordar una gran cantidad de dominios problemáticos diferentes en la ciencia y la ingeniería, en el propio diseño de modelos de aprendizaje automático y en tareas de ingeniería como el diseño de chips.

Jeff Dean: Si de verdad puedes hacer esas cosas de manera automatizada y cuentas con un marco de orquestación capaz de tomar objetivos de muy alto nivel y descomponernos en subproblemas, cada uno de esos subproblemas puede ejecutar uno de estos bucles automatizados explorando la mejor manera de resolver ese subproblema. Luego, el marco de orquestación puede unificar las soluciones de los subproblemas para dar con la solución general del problema de nivel superior. Eso va a acelerar el progreso del aprendizaje automático, acelerará la ciencia y acelerará la ingeniería. Va a ser increíble.

Diana Hu: Muchos campos donde puedes tener evaluadores muy buenos, adyacentes a cosas que pueden ser verificadas formalmente, están maduros para sistemas de IA que puedan auto-mejorarse.

Jeff Dean: En muchos casos, es necesario hacer que tus evaluadores sean mucho más rápidos. A modo de ejemplo, mis colegas hicieron algún trabajo hace tal vez una década sobre química cuántica, donde intentas comprender las propiedades de una molécula en particular. Puedes generar cierta configuración molecular y quieres entender qué propiedades posee. Puedes ejecutar un simulador de teoría de funcionales de densidad (density functional theory) computacionalmente muy intensivo, que es algo que podría tomar una noche de cómputo para darte la respuesta de una sola cosa. Mis colegas tomaron un montón de resultados de esas ejecuciones de simulación —las configuraciones moleculares de entrada y las salidas del costoso simulador— y los utilizaron para entrenar una aproximación neuronal del simulador. En lugar de tardar una noche, crearon algo que era 300.000 veces más rápido y casi tan preciso como ejecutar el simulador a escala completa.

Jeff Dean: Eso cambia por completo la forma en que haces ciencia. Si tienes 10 millones de cosas que filtrar (screen), podrías hacer eso mientras vas a alzar, en lugar de ser un esfuerzo de 6 meses donde intentas juntar suficiente cómputo para ejecutar todas estas simulaciones. Hay mucho espacio en muchos dominios para modelos de validación mucho más rápidos, posiblemente modelos de validación aprendidos que puedan darte una aproximación a la respuesta verdadera con muchísima más rapidez. Eso cambia la forma en que se pueden concebir esos bucles experimentales y la velocidad con la que puedes dar la vuelta a través de ellos.

Diana Hu: ¿Cuáles son algunos de los espacios y problemas en los que estás súper emocionado de que este método científico acelerado vaya a resolver o lograr?

Jeff Dean: El propio aprendizaje automático es uno de ellos. ¿Podemos tener un modelo que sea capaz de auto-mejorarse recursivamente ejecutando montones de experimentos? Si piensas en cómo se mejoran hoy los modelos en grandes equipos de investigación, la gente piensa en algunas ideas, ejecuta un grupo de experimentos a pequeña escala, comprueba si funcionaron bien, toma los más prometedores para probarlos a mayor escala, evalúa eso e integra los resultados en una nueva receta para tu modelo.

Jeff Dean: No hay un impedimento real para convertir eso en un bucle mucho más automatizado donde el modelo mismo decida que va a explorar, tal vez con un empujón por parte de personas al nivel más alto como: "¿Por qué no pruebas algunas nuevas ideas en torno a arquitecturas de modelos que incorporen esto?". Irá a ejecutar montones de experimentos, verá cuáles funcionan y los incorporará a un ritmo mucho más rápido. En efecto, lo que quieres es optimizar tus descubrimientos por unidad de cómputo de entrada.

Diana Hu: A medida que todos en la sala se conviertan en fundadores o comiencen sus carreras, probablemente coleccionarán un montón de rechazos. A ti también te ha pasado, Jeff. En 2014, tú, Geoffrey Hinton y Oriol Vinyals escribieron un artículo sobre destilación (distillation), que consiste en tomar un modelo profesor grande para entrenar un modelo mucho más pequeño y eficiente que sea más barato de computar con menos parámetros. Se ha convertido en un truco que todo el mundo está utilizando ahora mismo en la industria, y ese documento fue rechazado en NeurIPS.

Jeff Dean: No culpo al comité de programa. Muchas veces, un artículo recibe tres revisiones, y uno de los revisores lo miró y dijo que era poco probable que tuviera un impacto significativo. Cuando escribimos el documento, vimos que este era un problema súper importante porque sabíamos que fabricar modelos más baratos y altamente capaces a partir de modelos a mayor escala era algo que queríamos desesperadamente para servir modelos a más personas en dominios como voz o visión. Pero a veces el revisor no tiene esa experiencia porque tal vez no está pensando en servicios de IA a gran escala y está pensando en si esto es un avance fundamental. Es rechazado de vez en cuando, y está bien. Lo publicamos en arXiv, la gente lo lee, la gente lo usa, y todo va bien. De hecho, lo usamos para fabricar nuestros modelos Flash a partir de nuestro modelo Pro a mayor escala. En parte por eso nuestros modelos Flash en Gemini son tan capaces en relación con su tamaño y velocidad, algunos de los mejores en el benchmark para su clase de tamaño de modelo.

Diana Hu: Incluso si te rechazan, sigue adelante.

Jeff Dean: Esa es la lección que destilaría de eso.

Construye algo que realmente importe

Diana Hu: Te uniste a Google como una startup de 20 personas allá por 1999. Si tuvieras que tomar al Jeff Dean de 25 años de entonces y teletransportarlo a la actualidad en esta era con tus habilidades, ¿qué harías? ¿Te unirías a un laboratorio de vanguardia o iniciarías una empresa?

Jeff Dean: Siempre es difícil de decir, y es una elección muy personal sobre en qué quieres gastar tu tiempo. Para mí, algunas de las preguntas más importantes son: ¿vas a trabajar en algo que realmente te importa, y si eres capaz de avanzar en ello con colegas con los que te gusta trabajar, marcará eso una diferencia en el mundo de alguna manera positiva? ¿Podrás ofrecer ese servicio para ayudar a los bioquímicos, o a los programadores, o a todos los consumidores en internet? Lo que debes esforzarte por hacer es tener un impacto en el mundo que sea positivo, trabajar con personas con las que disfrutes trabajando, esforzarte al máximo y dar lo mejor de ti.

Jeff Dean: En términos de unirte a un laboratorio de vanguardia frente a iniciar una empresa con dos o tres de tus amigos cercanos, son experiencias diferentes. En una organización grande y establecida, tienes estructura, montones de colegas increíbles que saben cosas que tú no sabes, montones de problemas interesantes en los que trabajar y una plataforma existente para el impacto donde tu trabajo influye en muchísima gente en el mundo. Como startup muy pequeña, tienes que tener algo que te apasione, y hay un montón de riesgo en asumir ese problema de una manera que te permita tener éxito y hacer crecer un proyecto. Pero eso también puede ser increíblemente gratificante. Como mínimo, independientemente del camino que elijas, pregúntate: si trabajo en este problema y ocurre el mejor resultado posible, ¿será el mundo mucho mejor de alguna manera, o el mundo dirá: "Eh, eso es más o menos genial, pero da igual"? Ese no es el tipo de cosas en las que debes gastar tu tiempo.

Diana Hu: Has podido ser un mentor y gestor increíble para muchos ingenieros y construir sistemas enormes. ¿Cuáles son algunas lecciones para todos los presentes sobre cómo trabajar con gente inteligente o encontrar gente inteligente?

Jeff Dean: Siempre quieres encontrar personas que posean muy buenas habilidades en algún área que se necesite en un equipo que estás intentando formar, ya sea dentro de una empresa o al iniciar una empresa. Pero también quieres encontrar gente con la que te encante estar, porque vas a pasar mucho tiempo rodeado de personas que trabajan en problemas muy difíciles. Quieres personas con poco ego, que jueguen en equipo y que tengan habilidades complementarias a las tuyas.

Jeff Dean: Siempre encuentro que trabajar en un equipo pequeño donde la gente sabe cosas que yo no sé, y donde tal vez yo tengo algunas habilidades que otras personas no tienen tanto, es súper divertido. Estás construyendo colectivamente algo que ninguno de vosotros podría hacer individualmente, pero en el proceso adquieres de hecho una gran cantidad de nuevos conocimientos y habilidades para ti, y ellos también. Considera tu carrera de ingeniería o investigación como si tuvieras un cinturón de herramientas increíble lleno de técnicas. Siempre quieres ir añadiendo nuevas herramientas a ese cinturón, porque nunca sabes cuándo te vas a topar con un problema en el que necesites estas cuatro herramientas especializadas en lugar de estas tres. Añadir más herramientas hace que sea más probable que los problemas con los que te encuentres en el futuro puedan ser resueltos por ti.

Diana Hu: Varias personas en esta sala construirán eventualmente algo tan trascendental como lo que has hecho con MapReduce, la TPU, la destilación, etcétera. ¿En qué problema esperas que estén trabajando?

Jeff Dean: El mundo es un lugar muy grande y está lleno de problemas. Me entusiasman particularmente los nuevos enfoques sobre el hardware, como un hardware de inferencia mucho más eficiente. Pienso que existen tipos de algoritmos radicalmente diferentes para el aprendizaje automático que podrían ser mucho más eficientes en el uso de datos que los enfoques que utilizamos hoy en día. Si piensas en nuestros modelos a gran escala actuales, probablemente ven 1.000 veces más datos que los que ve un ser humano a la edad de 18 años. Sin embargo, el humano a la edad de 18 años es mejor en muchas cosas y está a la par de los modelos de vanguardia que han visto muchos más datos. ¿Podrías crear sistemas mucho más eficientes en el uso de datos que puedan aprender continuamente de sus propias acciones? El aprendizaje continuo es muy interesante. Las interacciones multiagente son algo fascinante. Crear formas de tener un mejor discurso entre las personas en el mundo, mantener conversaciones mucho más civiles y ayudar a la gente a conocer a otras personas en todo el mundo que deberían conocer en función de sus intereses; todas estas son cosas interesantes. Hay montones de cosas geniales en el mundo, y todos deberíamos salir y esforzarnos para que ocurran cosas aún más geniales.

Diana Hu: Eso suena maravilloso. Muchísimas gracias, Jeff Dean. Eso es todo por hoy.

Jeff Dean: Te lo agradezco. Gracias a todos.