Jeff Dean sobre a próxima fase da IA: de TPU a agentes autoevolutivos

Na YC Startup School de 2026, a voz de Jeff Dean estava um pouco rouca.

No início da entrevista, ele explicou que havia perdido a voz e que sua voz hoje soava diferente do normal. Mas isso não afetou a atenção dos espectadores na plateia. Diana Hu, sócia da YC sentada diante dele, listou de uma só vez uma série de nomes que merecem entrar na história da computação: MapReduce, BigTable, TensorFlow, TPU, Gemini.

Qualquer um desses projetos seria suficiente para se tornar a obra-prima da carreira de um engenheiro. Eles estão todos concentrados no currículo de Jeff Dean e de um grupo de engenheiros do Google ao seu redor.

Diana não transformou a entrevista em uma retrospectiva de conquistas. Ela está mais interessada em outra questão: quando a IA generativa já varreu a indústria de software, o que Jeff Dean, o especialista mais habilidoso em reestruturar sistemas desde a base, está observando hoje?

A resposta não é um modelo maior.

Nesta conversa de quase uma hora, Jeff Dean mencionou repetidamente hardware de inferência, energia, movimentação de dados, engenharia de contexto, agentes de execução prolongada e sistemas automatizados de experimentação, além de como startups podem evitar o impacto direto dos modelos gerais. O que ele disse pode parecer disperso, mas por trás há uma linha mestra muito clara: a próxima fase da IA não é apenas tornar os modelos mais inteligentes, mas colocá-los em um sistema capaz de operar a longo prazo, testar e errar continuamente, validar automaticamente e acumular habilidades constantemente.

Isso também significa que a competição em IA está passando de "quem tem o modelo maior" para "quem consegue organizar melhor a inteligência".

Em maio de 2025, Jeff Dean fez um julgamento que gerou ampla discussão: a capacidade da IA já está próxima à de um engenheiro júnior.

Um ano depois, Diana perguntou a ele como estava se realizando essa previsão.

A resposta de Jeff Dean foi direta. Ele considerou esse julgamento "bastante preciso". O avanço do modelo em agentização, codificação de fluxos longos e tarefas complexas ocorreu até mais rápido do que ele havia previsto.

“A capacidade do modelo de realizar tarefas cada vez mais complexas está crescendo mais rápido do que eu esperava,” disse ele.

Mais notavelmente, essa capacidade já não se limita à escrita de código. Cada vez mais sistemas de Agentes estão entrando na ciência, engenharia e outras áreas profissionais. Eles não apenas respondem perguntas, mas também dividem tarefas, usam ferramentas, executam experimentos, leem resultados e continuam agindo com base no feedback.

Comparar a IA a um engenheiro júnior tende a desviar a atenção para a substituição de mão de obra. Mas Jeff Dean está mais interessado em outra mudança: quando um "engenheiro júnior" pode ser replicado em dezenas, centenas, trabalhando em paralelo por dias ou até semanas, como mudará a forma de organização da produção?

Em equipes tradicionais, engenheiros júnior precisam se familiarizar com os negócios, compreender as ferramentas e receber feedback contínuo. O agente também precisa disso. Apenas seus materiais de treinamento não são mais apenas documentos, mas prompts, instruções de ferramentas, arquivos de habilidades, sistemas de teste, avaliadores e todo o contexto ambiental.

Isso criou uma nova divisão de trabalho na engenharia de IA.

No passado, engenheiros eram principalmente responsáveis por escrever código. No futuro, mais engenheiros se concentrarão em definir problemas, configurar ambientes, escrever especificações, projetar circuitos de feedback e coordenar um grupo de Agentes para realizar tarefas.

A previsão de Jeff Dean para 2027 é exatamente essa. Ele acredita que os sistemas de aprendizado de máquina participarão cada vez mais na melhoria de si mesmos. Eles dividirão o objetivo em subproblemas, executarão automaticamente um grande número de experimentos, compararão os resultados e combinarão as soluções eficazes para formar novos sistemas mais fortes.

Sempre que houver um objetivo mensurável em um campo, há oportunidade de obter grandes avanços.

This sentence is the first key to the entire interview.

A automação por IA não necessariamente invade primeiro os campos com mais conhecimento, mas sim aqueles com feedback mais claro. Se o código passa nos testes, se o layout do chip reduz a área, se a estrutura do modelo melhora a precisão, se as propriedades do material atendem aos requisitos — essas questões têm critérios de avaliação relativamente claros. Desde que o avaliador seja suficientemente confiável, a máquina pode realizar testes repetidos em frequência extremamente alta.

Então, a unidade mais importante na era da IA pode não ser mais uma única resposta, mas sim um ciclo completo: propor uma solução, executá-la, medir os resultados e ajustar o rumo.

Muitos dos trabalhos representativos de Jeff Dean surgiram de um ponto de partida muito simples: primeiro, calcular corretamente as ordens de grandeza.

Em 2001, a pesquisa do Google ainda dependia fortemente de discos rígidos. Os discos rígidos tinham grande capacidade, mas velocidade de acesso lenta. Jeff Dean e Sanjay Ghemawat fizeram uma estimativa e descobriram que o índice completo de pesquisa do Google na época já poderia caber na memória de todos os servidores.

Hoje, soa como apenas uma atualização de mídia de armazenamento. Mas na época, significava um design de sistema completamente diferente.

Se o índice permanecesse principalmente no disco rígido, as consultas precisariam aguardar a busca mecânica. Basta colocar o índice na memória para que a latência de acesso caia drasticamente. Os dois rapidamente escreveram uma nova versão e a colocaram em produção em poucos dias. A busca do Google tornou-se significativamente mais rápida.

Esta história é mais facilmente apresentada como um momento de genialidade súbita. Mas a explicação de Jeff Dean soa mais como um engenheiro descrevendo um princípio comum: quando as condições do sistema mudam, uma solução que antes não funcionava pode agora se tornar viável — e, nesse caso, deve-se recalcular.

Muitas inovações industriais ocorrem nesses momentos.

Um problema antigo persistiu por muito tempo, e as pessoas se acostumaram a aplicar correções em torno dele. Posteriormente, os preços de hardware, a capacidade de memória, a largura de banda da rede ou a capacidade do modelo ultrapassaram um ponto crítico, e as restrições originais desapareceram. Contudo, a maioria ainda utiliza a arquitetura antiga, pois ela se tornou senso comum.

O que Jeff Dean é bom em fazer é transformar o senso comum de volta em suposição.

Ele perguntará: Por que precisa ser assim? A ordem de grandeza de hoje é a mesma de ontem? Se substituirmos o passo mais caro, o sistema inteiro não assumirá uma forma completamente diferente?

Essa também é a recomendação que ele dá aos empreendedores. Não se concentre apenas em onde as soluções atuais estão falhando; em vez disso, reexamine o problema a partir dos princípios fundamentais. É possível aumentar o desempenho em uma ordem de grandeza? É possível reduzir os custos em duas ordens de grandeza? É possível deixar de seguir o caminho de implementação padrão da indústria?

Às vezes, você só precisa franzir os olhos para ver um problema, não se prender à solução de hoje, mas pensar a partir dos princípios fundamentais como deveria ser resolvido.

Isso não soa misterioso. O verdadeiramente difícil é que, após entrarem em uma indústria, a maioria das pessoas rapidamente aprende todas as respostas padrão dela. A experiência ajuda a aumentar a eficiência, mas também faz com que as pessoas percam a capacidade de fazer novas perguntas.

Em 2013, o reconhecimento de voz baseado em aprendizado profundo do Google começou a superar significativamente os sistemas antigos. A taxa de erro caiu pela metade, equivalendo ao progresso feito no reconhecimento de voz nas últimas duas décadas, concentrado em poucos meses.

A equipe de produtos, claro, estava empolgada. Mas Jeff Dean primeiro fez um cálculo.

Se o reconhecimento de voz realmente melhorar, os usuários estarão mais dispostos a usá-lo. Supondo que cada usuário do Google use apenas três minutos de reconhecimento de voz por dia, quantos servidores a Google precisaria para suportar?

Os resultados não foram otimistas. De acordo com a eficiência dos CPUs na época, o Google poderia precisar dobrar o tamanho de seus servidores.

Este é o ponto de partida do TPU.

Não foi porque a equipe de pesquisa de repente quis fabricar chips, nem para provar que o Google é capaz de fazer hardware, mas porque um modelo bem-sucedido está prestes a gerar um custo de serviço insustentável.

Essa história revela uma lei frequentemente ignorada nos produtos de IA: o aumento na eficácia do modelo nem sempre reduz os custos. Pelo contrário, quanto melhor o desempenho, maior o volume de uso e maior a pressão sobre o sistema.

Quando o reconhecimento de voz não funciona bem, os usuários raramente o utilizam. O custo do sistema não é um problema. Quando a taxa de erro diminui significativamente, a demanda é repentinamente liberada, e as restrições de capacidade de processamento anteriormente ocultas nos bastidores emergem.

O caminho escolhido pelo TPU é desenvolver hardware dedicado para o modelo de computação mais central do machine learning. Ele não precisa executar navegadores nem processar todos os programas gerais. É principalmente especializado em álgebra linear densa de baixa precisão. Esse tipo de computação está exatamente no centro do machine learning moderno.

A primeira geração de TPU trouxe ganhos de ordens de grandeza. Segundo Jeff Dean, ela foi 30 a 80 vezes mais eficiente em energia do que os CPUs e GPUs da época, com latência 20 a 30 vezes menor.

Aqui há outra escala de design que容易被忽略.

TPU é muito especializado, mas não tanto a ponto de executar apenas um modelo fixo. A equipe sabia que os algoritmos de aprendizado de máquina ainda evoluiriam rapidamente, então projetou o chip como um sistema de álgebra linear mais genérico. Ele abriu mão da capacidade de executar Chrome ou Word, mas manteve espaço para suportar a evolução futura dos algoritmos.

É um equilíbrio difícil de alcançar. Se não dedicar o suficiente, os rendimentos não serão evidentes. Se dedicar demais, uma simples alteração no algoritmo pode tornar o hardware obsoleto.

A avaliação de Jeff Dean sobre o hardware de inferência de hoje ressoa claramente com o TPU da época. Ele acredita que a próxima grande oportunidade ainda está na especialização, mas o foco se deslocará ainda mais para inferência de baixa latência e baixo consumo de energia.

Imagine o que você poderia fazer se a latência fosse melhorada em 50 vezes.

Quando o modelo responde em cerca de dez segundos, as pessoas o consideram uma ferramenta ocasional de consulta. Quando a latência se aproxima do imediato, ele poderá realmente integrar-se a interfaces interativas, robôs, vídeos em tempo real, sistemas operacionais e fluxos de decisão contínua.

Esperar não é apenas um problema de experiência. Esperar muda a forma do produto.

Se fosse atualizar uma versão de “Números de latência que todo engenheiro deve saber” para engenheiros de IA em 2026, Jeff Dean acredita que o foco deveria mudar de busca em disco rígido, falhas de cache e latência de rede transcontinental para o fluxo de dados dentro do chip.

Os engenheiros precisam saber: qual é a largura de banda da memória principal para a memória on-chip, qual é a largura de banda da memória on-chip para a unidade de multiplicação, quanto de energia é necessária para uma única multiplicação, como os chips são interconectados e como a eficiência da rede diminui ao escalar de 500 para 10.000 chips.

Esses números parecem distantes do produto, mas na verdade determinam quais produtos podem prosperar.

Jeff Dean apresentou uma proporção extremamente impactante. Realizar uma multiplicação matemática requer aproximadamente um picojoule de energia. Mover dados da memória de alta largura de banda para a unidade de cálculo pode custar cerca de 1000 vezes mais energia.

Em outras palavras, as ações caras nos sistemas de IA hoje geralmente não são “calcular”, mas “trazer os dados para serem calculados”.

Isso também explica por que o lote é tão importante.

Após um conjunto de pesos do modelo ser carregado da memória para a unidade de cálculo, se apenas um token for processado, todo o custo de transferência de dados recai sobre esse único token. Se um lote maior for processado simultaneamente, os mesmos pesos podem atender a mais cálculos, distribuindo o custo de energia e largura de banda.

Mas loteamento e baixa latência são intrinsicamente conflitantes. Para reunir um lote de solicitações, o sistema frequentemente precisa aguardar. O throughput aumenta, mas a resposta individual do usuário pode ficar mais lenta.

Portanto, muitos problemas aparentemente relacionados à camada do modelo são, na verdade, problemas de hardware e sistema. Por que o treinamento usa lotes grandes, por que a inferência exige KV Cache, por que o modelo busca baixa precisão e por que o sistema precisa de quantização — tudo isso está intimamente ligado às restrições de movimentação de dados e energia.

Jeff Dean tem se concentrado mais recentemente na inferência, justamente porque a inferência é extremamente sensível à latência. Um treinamento mais lento geralmente apenas atrasa o fim de um experimento. Já na inferência, cada segundo a mais de espera afeta diretamente a experiência do usuário e a eficiência do agente.

Se um agente precisar chamar o modelo 1.000 vezes consecutivas, reduzir a latência por chamada em 50% pode resultar em uma diferença enorme no tempo total de conclusão da tarefa. Sem falar no fato de que, no futuro, agentes poderão operar por dias ou semanas.

Portanto, o "problema energético" da IA não é um tema ambiental distante. Ele determina diretamente se os modelos podem servir a mais pessoas de forma econômica, se os Agentes podem operar continuamente e se a margem bruta das startups saudáveis.

Nos últimos anos, a indústria de IA costumava medir o progresso por meio de número de parâmetros, dados de treinamento e pontuações de referência. Em 2026, Jeff Dean enfatiza ainda mais tudo o que envolve o modelo.

Um sistema de IA verdadeiramente útil, além do modelo, precisa de recuperação, ferramentas, memória, informações históricas, ambiente de execução e mecanismos de feedback. O modelo deve saber quais ferramentas estão disponíveis, quando chamar as ferramentas, como dividir problemas complexos em uma sequência de ações, e também ser capaz de comparar várias soluções e determinar qual tem maior probabilidade de sucesso.

É por isso que a "engenharia de contexto" começou a chegar ao centro do palco.

Jeff Dean disse que as informações vistas pelo modelo durante a fase de treinamento são finalmente "misturadas" em centenas de bilhões ou trilhões de parâmetros. Elas são como uma sopa espessa: o conhecimento está presente, mas nem sempre é claro. As informações realmente inseridas no contexto atual são mais diretas para o modelo e mais fáceis de serem utilizadas com precisão.

Isso deixa uma oportunidade importante para pequenas equipes.

Treinar modelos base requer capital, dados e poder de computação massivos. A engenharia de contexto, porém, pode começar com uma única API. Empreendedores podem organizar conhecimento de domínio, fluxos de ferramentas, dados de clientes e critérios de avaliação em torno de negócios específicos, fazendo com que modelos gerais se comportem de forma mais confiável em cenários restritos.

Jeff Dean citou um exemplo próprio.

Ele e Sanjay Ghemawat frequentemente otimizam as bibliotecas de baixo nível internas do Google. Essas estruturas de dados podem ser executadas em milhões de processos, uma Clique aqui As diferenças de desempenho são amplificadas pela escala. A abordagem tradicional consiste em os engenheiros primeiro escreverem microbenchmarks, medirem o desempenho atual, modificarem o código, executarem novamente os benchmarks, observarem o uso de cache e as mudanças de desempenho, e então continuarem iterando.

As duas pessoas documentaram esse método de trabalho como uma habilidade de agente. O modelo aprendeu a executar benchmarks, modificar código, comparar resultados e otimizar continuamente com base nas medições.

Nós apenas fornecemos a ele os métodos que as pessoas usariam, em uma forma que o modelo possa utilizar.

This sentence can almost be considered a naive definition of context engineering.

Não é uma técnica mágica de prompt, nem é empilhar mais materiais de contexto. É responder três perguntas: quais etapas um especialista seguiria, quais ferramentas confiáveis o sistema possui e como os resultados devem ser verificados.

Quando esse conteúdo é estruturado, o modelo não adquire mais conhecimento, mas sim um conjunto de métodos executáveis repetidamente.

É por isso que "habilidades (skill)" se tornam ativos-chave no ecossistema de Agentes. Um arquivo de habilidade excelente pode encapsular anos de experiência implícita da equipe. Ele orienta o modelo sobre o que fazer primeiro ao enfrentar um tipo específico de problema, quais erros são mais comuns, quais ferramentas são confiáveis e o que constitui um resultado concluído.

A diferenciação das empresas futuras provavelmente não estará apenas nos pesos dos modelos, mas também nessas experiências codificadas nos fluxos de trabalho.

Quase todas as equipes que realmente desenvolveram Agentes já presenciaram o mesmo cenário.

Os primeiros passos foram fáceis. O modelo conseguia ler as exigências, chamar ferramentas e escrever código. Na etapa 30 ou 50, ele começou a esquecer o objetivo, mal interpretar o estado, repetir ações ou seguir cada vez mais na direção errada.

Jeff Dean atribui uma das razões ao problema de distribuição externa.

O modelo foi exposto a uma grande quantidade de tarefas comuns durante o treinamento. Sempre que a tarefa permanecer dentro da sua zona familiar da “estrada iluminada”, o desempenho geralmente é bom. Contudo, assim que operações contínuas o levam a estados desconhecidos, o desempenho cai abruptamente. Quanto mais se afastar da zona de conforto, mais fácil é a acumulação de erros.

Uma das soluções é fornecer habilidades e dicas para restringir o modelo o máximo possível aos caminhos com os quais ele está familiarizado. Outra abordagem é usar um sistema multi-agente.

Vários Agentes podem tentar diferentes abordagens, enquanto outro modelo atua como avaliador, determinando quais direções têm mais potencial. Os ramos falhos são descartados, e os ramos bem-sucedidos continuam avançando. Isso, em essência, realiza uma busca durante a fase de raciocínio.

Não é estranho à forma como a equipe humana trabalha. Diante de problemas complexos, uma pessoa propõe uma solução, outra analisa os riscos e uma terceira executa experimentos. A equipe não coloca todas as suas esperanças na primeira ideia, mas reduz erros pontuais por meio de divisão de tarefas e feedback.

Quanto mais tempo o agente estiver em execução, menos o sistema pode depender de uma única execução correta.

Um agente de longo prazo verdadeiramente confiável requer pontos de verificação, gerenciamento de estado, rollback, exploração de ramificações, avaliação externa, controle de permissões e recuperação de exceções. Ele é mais como um sistema distribuído do que uma janela de bate-papo extremamente longa.

É exatamente aí que o histórico de Jeff Dean começa a se tornar novamente crucial.

Um dos problemas centrais resolvidos pelo MapReduce é como permitir que um grande número de máquinas não confiáveis realizem cálculos confiáveis. Os sistemas de Agentes de hoje enfrentam uma contradição semelhante: chamadas únicas ao modelo não são perfeitas, as ferramentas também podem falhar, mas a tarefa inteira ainda precisa ser concluída da forma mais estável possível.

A futura plataforma de agentes excelentes poderá herdar muitas ideias de sistemas distribuídos. As tarefas podem ser divididas, os resultados podem ser verificados, as falhas podem ser retentadas, os estados podem ser restaurados e erros locais não devem destruir todo o processo.

Quando Jeff Dean diz que os agentes funcionarão por dias ou até semanas, ele não está descrevendo uma conversa mais longa. Ele está descrevendo uma nova infraestrutura de computação.

No contexto da Startup School, a questão mais destacada é, naturalmente, a oportunidade de empreendedorismo.

O Google pode projetar conjuntamente chips, data centers, modelos e produtos. Modelos gerais como o Gemini ainda estão expandindo rapidamente os limites de suas capacidades. Como uma equipe de duas ou três pessoas pode vencer?

A resposta de Jeff Dean não é romântica.

As oportunidades para pequenas equipes geralmente existem em áreas específicas que os modelos gerais não abordam adequadamente. Empreendedores podem combinar interface do produto, dados proprietários, fluxos de trabalho e habilidades de domínio para oferecer maior precisão e melhor experiência em um cenário restrito.

Mas ele imediatamente emitiu um aviso: os modelos gerais estão se tornando rapidamente mais fortes. Funcionalidades de produtos que parecem independentes hoje podem ser diretamente cobertas por modelos básicos em seis ou doze meses.

Portanto, os empreendedores precisam avaliar se suas vantagens são duradouras.

Jeff Dean apresentou um critério de seleção muito específico: procurar tarefas cuja taxa de sucesso dos modelos gerais atuais esteja próxima de 0% ou 1%, e não tarefas que já conseguem atingir 20%.

Se o modelo falhar completamente, isso pode ser um bom sinal. Se ele já consegue fazer parte, mas não faz bem, isso nem sempre é um bom sinal.

A razão é simples. 20% significa que as capacidades já começaram a surgir. Mais dados, modelos maiores e raciocínio mais longo provavelmente o levarão rapidamente à utilidade. 0% ou 1% indicam que a tarefa pode estar faltando dados cruciais, ferramentas especiais, feedback do domínio ou uma capacidade que um modelo geral dificilmente poderá obter em curto prazo.

Isso pode ser chamado de "regra de 1%" de Jeff Dean.

Não se trata de sugerir que empreendedores escolham apenas os problemas mais difíceis, mas sim buscar problemas onde os modelos gerais apresentam cegueiras estruturais.

Existem aproximadamente três tipos de cegueiras deste tipo.

A primeira categoria são dados proprietários. Modelos gerais podem organizar informações do mundo, mas nem sempre conseguem acessar todos os perfis de um usuário, os processos internos de uma empresa ou dados em tempo real gerados por um determinado dispositivo. Uma vez que um produto de startup obtenha esses dados, poderá desenvolver uma perspectiva diferente daquela dos modelos básicos.

A segunda categoria é a avaliação profissional. Muitas indústrias não sofrem com falta de capacidade de geração, mas sim com falta de julgamento confiável. Medicina, materiais, chips, manufatura e pesquisa científica exigem validadores de alta qualidade. Quem definir “o que está correto” poderá permitir que os Agentes se otimizem continuamente.

A terceira categoria são modelos estreitos e profundos. O AlphaFold não é um modelo de bate-papo geral; ele desenvolveu capacidades altamente especializadas para o problema da estrutura de proteínas. Ciência dos materiais, design de chips e outras áreas especializadas também podem apresentar oportunidades semelhantes.

Essa avaliação não é fácil para empreendedores. Ela exige que a equipe compreenda tanto os limites das capacidades do modelo quanto os problemas profundos do setor. Entender apenas IA pode levar a funcionalidades que são rapidamente absorvidas pela plataforma. Entender apenas o setor pode levar a subestimar a velocidade do avanço do modelo.

The real opportunity lies at the intersection of both.

Diana propõe uma hipótese: se, no futuro, cada fundador puder gerenciar simultaneamente 50, 100 agents, e todo o código for escrito por agents, qual habilidade se tornará rara?

A resposta de Jeff Dean foi "gosto".

Mais precisamente, é determinar o que o agente deve fazer.

Ele acredita que o maior valor do trabalho de pesquisa não está em executar os experimentos perfeitamente, mas em escolher uma questão digna de ser estudada. Uma equipe pode usar os métodos mais sofisticados para realizar uma pesquisa irrelevante. Ou pode se concentrar em uma questão fundamental que, se resolvida, transformará todo o campo.

Após o agente reduzir o custo de execução, a importância da escolha do problema aumentará ainda mais.

No passado, uma ideia vaga desaparecia naturalmente devido ao alto custo de desenvolvimento. No futuro, bastará mobilizar um número suficiente de Agentes para transformar muitas ideias rapidamente em protótipos. O mundo não verá automaticamente mais produtos bons, apenas mais produtos.

Especificações também se tornarão mais importantes.

Jeff Dean disse que, ao colaborar com agentes virtuais, quanto mais clara for a meta, maior será a taxa de sucesso. No passado, necessidades vagas eram entregues a um engenheiro sênior, que podia fazer perguntas e complementar a intenção com base em um contexto compartilhado. Embora os agentes também possam fazer perguntas, são mais propensos a fazer suposições quando faltam contextos.

Uma tarefa típica de alta taxa de sucesso é migrar um software de uma linguagem de programação para outra. A razão não é que a migração seja simples, mas sim que as especificações sejam extremamente completas. O código antigo define o comportamento, os testes definem os limites, e o agente pode comparar item a item até que a nova versão apresente o mesmo comportamento.

Agora os agentes podem escrever software para você, mas explicar exatamente o que você quer tornou-se ainda mais importante.

Esta frase tem implicações diretas para as organizações nativas de IA.

Os gestores do futuro não apenas atribuirão tarefas, mas também definirão metas e critérios de aceitação mais claros. Documentos de design não serão mais apenas materiais de comunicação entre equipes, mas também entradas para execução por máquinas. Testes, métricas, restrições e exemplos serão movidos para a fase de definição de tarefas, em vez de permanecerem no final do processo de desenvolvimento.

Quanto ao treinamento do "gosto", Jeff Dean apresentou um método muito prático.

Escreva uma lista de coisas que você acredita que se tornarão importantes nos próximos 12 meses. Você não precisa fazer todas elas. Após 12 meses, revise quais previsões se confirmaram, quais foram realizadas por outras pessoas e quais não tiveram progresso algum. Ao acumular continuamente amostras de previsões, as pessoas gradualmente ajustam seu julgamento.

O gosto não é totalmente um dom. Também pode ser desenvolvido por meio de análise e treinamento.

Na segunda metade da entrevista, Jeff Dean compartilhou um experimento mental bastante louco.

Nos últimos 60 anos, a indústria de chips tem buscado transistores menores, mais estáveis e com taxas de erro mais baixas. Assume-se que chips fabricados com o mesmo design devem ser o mais idênticos possível, com menos inversões de bit melhor.

Em grandes sistemas distribuídos, engenheiros já aceitam que componentes individuais podem falhar. Discos rígidos podem quebrar, máquinas podem cair, e switches podem apresentar problemas. A confiabilidade do sistema não vem da ausência total de erros em cada componente, mas da replicação, verificação, redundância e recuperação.

Então Jeff Dean perguntou: e se os transistores cometessem 20 erros por dia, em vez de um erro a cada milhões de anos?

Este não é um plano de produto real. Ele apenas tenta remover uma premissa comum. Talvez transistores extremamente confiáveis possam ser fabricados de maneira completamente diferente, e o sistema garanta os resultados por meio de múltiplos caminhos e redundância de alto nível.

A maioria dos experimentos mentais nunca se torna um produto. Muitas práticas industriais persistem por décadas, e há razões válidas para isso. Mas Jeff Dean acredita que ainda assim é necessário revisar periodicamente essas razões.

MapReduce vem de um processo semelhante.

Os sistemas de rastreamento e indexação do Google inicial continham grande quantidade de código paralelo manual, pontos de verificação e lógica de recuperação de falhas. Os cálculos de negócios reais eram frequentemente simples, como ler todas as páginas da web e determinar o idioma da página. Contudo, grande parte do código do sistema enterrava essa intenção simples.

Jeff Dean e Sanjay Ghemawat se inspiraram na programação funcional. Eles abstraíram grandes tarefas em Map e Reduce, descentralizando paralelização, agendamento, tolerância a falhas e retenção para um framework unificado. Desenvolvedores de negócios precisam apenas expressar o cálculo em si.

Este design não tornou a máquina infalível. Ele tornou os erros passíveis de serem absorvidos pelo sistema.

Hoje, os agentes também podem estar em estágio semelhante. Muitas equipes ainda estão manualmente orquestrando prompts, lógicas de nova tentativa e chamadas de ferramentas para cada tarefa. No futuro, surgirá uma abstração tão simples quanto o MapReduce, tornando a decomposição, validação, recuperação e exploração paralela de agentes de longo prazo capacidades subjacentes?

Este pode ser exatamente o momento para as próximas empresas de infraestrutura.

Jeff Dean está mais entusiasmado com a direção de automatizar o próprio método científico.

O processo tradicional de pesquisa científica envolve formular uma hipótese, projetar um experimento, executar o experimento e analisar os resultados, gerando então uma nova hipótese. A velocidade desse ciclo foi historicamente limitada pelo custo dos experimentos e pelos atrasos na validação.

A IA pode alterar duas partes.

Uma parte é propor e executar automaticamente mais experimentos. Outra parte é transformar validadores caros em modelos aproximados baratos.

Jeff Dean citou o exemplo da química quântica. Os pesquisadores, para determinar as propriedades de uma configuração molecular, podem executar simulações da teoria do funcional da densidade. Uma única simulação pode levar toda uma noite. Os pesquisadores do Google treinaram um aproximador neural com grandes volumes de entradas e saídas de simulações. Ele alcança precisão próxima à do simulador original, mas é cerca de 300 mil vezes mais rápido.

Após a alteração da velocidade de verificação, a forma das questões científicas também muda.

Antes, filtrar 10 milhões de candidatos poderia ser um projeto exigindo meses de poder computacional. Agora, o sistema consegue realizar a triagem inicial no tempo de um almoço dos pesquisadores. Os experimentos deixaram de ser apostas únicas e valiosas para se tornarem buscas em alta frequência.

Essa também é a lógica comum por trás de sistemas como AlphaEvolve e AlphaChip. O modelo propõe soluções, as ferramentas executam as soluções, o avaliador filtra os resultados, e os melhores resultados avançam para a próxima rodada. Desde que o ciclo seja suficientemente rápido, o sistema pode explorar continuamente um espaço de soluções imenso.

O próprio machine learning também se tornará objeto dessa ciência automatizada.

Hoje, grandes equipes de pesquisa geralmente são lideradas por pessoas que propõem novas arquiteturas ou métodos de treinamento, realizam primeiro experimentos em pequena escala e depois selecionam as abordagens mais promissoras para escalar. Jeff Dean acredita que não há obstáculos fundamentais que impeçam os modelos de assumirem cada vez mais etapas desse processo. As pessoas fornecem direções de alto nível, enquanto o sistema explora automaticamente estruturas, receitas de dados e estratégias de treinamento, combinando os experimentos bem-sucedidos para criar novos modelos.

O indicador futuro para medir a eficiência da pesquisa pode não ser mais apenas operações de ponto flutuante por segundo, mas sim "quantas descobertas válidas são geradas por unidade de poder de cálculo".

A capacidade de processamento é claramente importante. O mais importante é como transformar essa capacidade em descobertas.

Em 2014, Jeff Dean, Geoff Hinton e Oriol Vinyals submeteram um artigo sobre distilação de conhecimento. Hoje, a distilação de conhecimento é um método fundamental na compressão de modelos e na transferência de capacidades. Modelos grandes atuam como professores, transferindo suas capacidades para modelos menores, mais rápidos e mais baratos.

Este artigo, que mais tarde teve um impacto profundo, foi recusado pela NeurIPS na época.

Um revisor considerou que «é pouco provável que tenha um impacto significativo». Leitores interessados podem acessar «Recusado ≠ Falha! Estes artigos de alto impacto foram rejeitados por conferências de topo».

Jeff Dean não expressou raiva ao falar sobre essa experiência. Ele disse que os revisores podem não compreender os desafios práticos enfrentados por serviços de IA em larga escala. Para o Google, transformar modelos grandes e caros em modelos menores capazes de atender centenas de milhões de usuários é claramente muito importante. Para revisores focados apenas na novidade teórica, isso pode não parecer suficientemente “básico”.

Após a recusa do artigo, a equipe o publicou no arXiv. A indústria ainda o leu e ainda começou a usá-lo.

Hoje, o modelo Flash da Gemini consegue manter forte desempenho com menor volume e menor latência, e a destilação é um dos métodos importantes para isso.

Essa história não é apenas um material inspirador de "persistência leva ao sucesso". Ela demonstra que os sistemas de avaliação sempre têm cegueiras. O valor de uma solução às vezes só é imediatamente visível por quem realmente passou pelo gargalo desse sistema.

For entrepreneurs, this is equally important.

A negação do mercado, dos investidores e dos colegas pode significar um erro de direção, ou simplesmente que a outra parte não está no mesmo contexto do problema. A diferença está em se a equipe possui evidências suficientemente específicas para saber por que esse problema é importante e por que pode ser resolvido agora.

Jeff Dean não incentiva as pessoas a persistirem cegamente. Ele incentiva: compreender o problema, verificar continuamente e não considerar uma única avaliação como o julgamento final do mundo.

No final da entrevista, Diana fez uma pergunta imaginativa.

Se o jovem Jeff Dean, que se juntou ao Google em 1999, fosse transportado para 2026, ele se juntaria a um laboratório de ponta ou fundaria uma empresa com dois ou três amigos?

Jeff Dean não forneceu uma resposta padrão.

Grandes organizações possuem estruturas, plataformas e muitos colegas excelentes. Dentro delas, uma pessoa pode acessar conhecimentos que não domina e utilizar produtos maduros para impactar usuários globais. Equipes pequenas são mais livres, mas também assumem maiores riscos. Os fundadores devem acreditar verdadeiramente em um problema e estar dispostos a enfrentar a incerteza por anos.

O critério que ele apresentou é mais fundamental do que "entrar em uma grande empresa ou empreender".

Se eu resolver esse problema e o melhor resultado realmente acontecer, o mundo ficará claramente melhor, ou as pessoas apenas dirão: “Legal”, e pronto?

Se a resposta for apenas “muito legal”, talvez não valha a pena investir seu tempo mais valioso.

Ele também enfatizou a importância dos colegas: procure pessoas com habilidades complementares, humildes, dispostas a colaborar e fáceis de conviver. Problemas verdadeiramente difíceis geralmente exigem trabalho conjunto a longo prazo. Os membros da equipe devem possuir, cada um, ferramentas únicas que os outros não têm, e continuar expandindo sua “cinta de ferramentas” por meio do trabalho conjunto.

Essa frase tem uma simplicidade de engenheiro antigo.

O setor de IA gosta de falar sobre crescimento exponencial, inteligência superinteligente e grandes financiamentos. Mas Jeff Dean acabou voltando a escolha para três pequenas coisas: trabalhar em uma questão que realmente importa, trabalhar com pessoas que você gosta e fazer o possível para tornar o mundo um lugar melhor.

Ao longo da carreira de Jeff Dean, há muitas lendas que são repetidamente contadas.

Ele e Sanjay Ghemawat reescreveram o sistema de busca em poucos dias, trazendo o índice para a memória. Uma estimativa de três minutos de voz impulsionou o Google a criar o TPU. O MapReduce ocultou paralelismo em larga escala e tolerância a falhas dentro de uma abstração unificada. A destilação de conhecimento transformou-se de um artigo rejeitado em uma tecnologia fundamental da indústria.

Essas histórias facilitam imaginar ele como um gênio constantemente inspirado.

But from this interview, his approach is actually highly consistent.

Primeiro, determine a ordem de grandeza. Depois, identifique o verdadeiro gargalo. Em seguida, questione as suposições padrão e crie uma abstração mais simples. Por fim, use medições e feedback para impulsionar a iteração contínua do sistema.

O setor de IA hoje está passando por um ponto de virada semelhante.

O modelo já é forte o suficiente para assumir tarefas de nível de engenheiro júnior. O que determina a produtividade real, a seguir, não é apenas a inteligência do modelo, mas sim o custo de raciocínio, a organização do contexto, a qualidade das ferramentas, a velocidade de validação e a confiabilidade em execuções prolongadas.

Os agentes se tornarão cada vez mais como membros da equipe. Mas eles precisam de especificações claras, de habilidades, de pontos de verificação, de avaliadores e de um sistema que permita falhas.

As oportunidades para startups também não desaparecerão, apenas se tornarão mais exigentes. É melhor não se concentrar em tarefas que modelos gerais já conseguem realizar em 20%, mas sim buscar problemas cuja taxa de sucesso ainda esteja próxima de 0% ou 1%. Lá podem estar escondidos dados proprietários, avaliadores especializados, modelos de domínio restrito ou novas abstrações de sistema.

Quando a geração de código se tornar cada vez mais barata, o que realmente será caro será o problema em si.

O que vale a pena fazer? Quais restrições estão obsoletas? Quais mudanças acabaram de cruzar o ponto de inflexão? Qual sistema se tornaria um produto completamente diferente se fosse 50 vezes mais rápido?

Jeff Dean não forneceu uma lista de oportunidades para 6.000 empreendedores. Ele ofereceu uma forma de pensar mais duradoura.

Não corra atrás da resposta mais quente.

Primeiro, calcule a questão.

Link de referência

https://x.com/ycombinator/status/2082938685071491219

https://www.ycrootaccess.com/p/jeff-dean-the-1-rule-for-building

Este artigo é do número de identificação do WeChat "Machine Heart" (ID: almosthuman2014), autor: Panda