A versão sem glamour do aprendizado contínuo

Ver no idioma original →

Autoria: LangChain · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The Boring Version of Continual Learning · Canal: LangChain · 20:35 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Modelos de IA

Resumo

Will Brown defende que o aprendizado contínuo de modelos está deixando de ser algo futurista e se tornando parte rotineira do ciclo de vida de desenvolvimento de software. Para isso, equipes precisam transformar o feedback de usuários e métricas em evals, testar mudanças e escolher métodos como distillation e RL de acordo com seus objetivos. À medida que workflows amadurecem, pode fazer sentido criar modelos menores e especializados em vez de depender apenas de modelos generalistas. Assim como outras práticas de software, o post-training tende a ser automatizado e abstraído com o tempo.

Pontos-chave

• O aprendizado contínuo deve se tornar uma prática comum, integrada ao ciclo de vida de produtos com modelos.
• Agentes experimentais podem evoluir para produtos de produção, com versionamento, releases, rollbacks e atenção a custo, latência e desempenho.
• O feedback dos usuários e os dados de uso ajudam a identificar falhas, novos casos de uso e oportunidades de melhoria.
• Evals transformam objetivos e verificações qualitativas em métricas que podem orientar a seleção e a otimização de modelos.
• Distillation e RL oferecem caminhos diferentes para adaptar modelos; a escolha depende do problema e das características dos dados.
• Sistemas de produção podem ser projetados para coletar traces e permitir avaliações de alta fidelidade em ambientes de desenvolvimento.
• Modelos especializados podem oferecer mais controle, menor custo e iteração mais rápida para workflows maduros.
• O post-training ainda exige experimentação, mas suas práticas tendem a ser automatizadas e abstraídas, como aconteceu com outras etapas do desenvolvimento de software.

Capítulos

Início	Capítulo	Resumo
00:03	Aprendizado contínuo como prática cotidiana	Brown apresenta a ideia de que o aprendizado contínuo deixará de parecer ficção científica e se tornará parte comum dos produtos.
04:50	Do feedback dos usuários aos evals	O palestrante relaciona a manutenção de agentes em produção ao ciclo de feedback, à definição de métricas e à criação de evals.
09:35	Distillation, RL e adaptação de modelos	Brown compara métodos de treinamento e discute quando usar distillation ou RL para aprimorar modelos e sistemas.
13:16	Ambientes, especialização e escolhas de produto	A palestra aborda ambientes de avaliação, decisões entre comprar ou construir e a necessidade de modelos especializados.
17:27	O ciclo de vida dos modelos e a automação	Brown descreve o ciclo de desenvolvimento, monitoramento e melhoria dos modelos e prevê que o post-training se tornará mais automatizado.

Citações

Meu objetivo hoje é convencer vocês de que o aprendizado contínuo é algo sem glamour. — 00:03

É assim que um produto ou workflow com agent amadurece: começa a parecer menos uma ferramenta e mais um software. — 04:17

RL é meio que o botão para fazer as métricas subirem. — 11:11

Descobrimos algo que funciona e facilita nossa vida, fazemos isso o suficiente para confiar e então descobrimos como nunca mais fazer manualmente: automatizamos. — 19:01

A versão sem glamour é que o aprendizado contínuo são os ciclos de desenvolvimento de software para modelos. — 20:35

Conceitos e entidades

• Continual learning (conceito): Abordagem em que modelos são aprimorados continuamente a partir de novos dados, feedback e necessidades de produção.
• Will Brown (pessoa): Pesquisador que lidera pesquisa aplicada na Prime Intellect e apresenta a palestra.
• Prime Intellect (empresa): Empresa onde Will Brown lidera pesquisa aplicada.
• evals (conceito): Avaliações usadas para medir se modelos atendem aos objetivos e requisitos de um produto.
• SFT (conceito): Método de treinamento supervisionado mencionado como uma das opções para adaptar modelos.
• On-policy distillation (conceito): Técnica de distillation em que o modelo aprendiz é treinado com dados gerados segundo sua própria distribuição.
• Offline context distillation (conceito): Método de distillation que transfere conhecimento de um modelo professor usando contextos preparados offline.
• RL (conceito): Método de otimização que pode melhorar métricas específicas e adaptar modelos a sistemas e harness em evolução.
• Claude Code (ferramenta): Produto citado como exemplo de interface para interagir com agents.
• Codex (ferramenta): Produto citado como exemplo de interface para interagir com agents.
• Cursor (ferramenta): Produto citado como exemplo de interface para interagir com agents.
• GitHub Actions (ferramenta): Serviço de automação de workflows de desenvolvimento citado como exemplo de processo que pode ser substituído ou aprimorado.

Tradução completa (pt-BR)

00:03 Sou Will Brown. Lidero a pesquisa aplicada na Prime Intellect. E meu objetivo hoje é convencer vocês de que o aprendizado contínuo é tedioso. Com isso, quero dizer que vocês deveriam fazer isso. É para lá que as coisas estão caminhando. É o futuro. Mas também está deixando de parecer ficção científica muito rápido. E acho que, com o que vou falar hoje, meu objetivo é tentar traçar um panorama que pareça mais prosaico. Que pareça algo corriqueiro. Que pareça simplesmente: “Ah, claro, é esse o objetivo.”

00:34 Ainda não estamos nesse ponto, mas este é mais ou menos o panorama de onde acho que estaremos em pouco tempo, em termos de como o aprendizado contínuo dos modelos se encaixa nos produtos e nas implantações de empresas como as que muitos de vocês certamente estão construindo ou onde trabalham hoje. E isso vai tomar emprestadas lições do software. Hoje, software é algo tedioso. Software é uma commodity. Software é grátis. Software custa muito pouco. O custo do software está chegando a zero. E, mesmo assim, todos nós criamos software. E acho que em breve os modelos vão se parecer muito com isso. E a versão empolgante do aprendizado, a versão que acho que muitos de nós gostamos de

01:06 imaginar quando lemos blogs e pensamos em novos algoritmos é mais ou menos assim: imaginamos um agent implantado em produção que projeta as próprias receitas de treinamento. Que otimiza os próprios kernels. Os pesos vão ser atualizados a cada token que passar, e ele vai fazer hot swapping multi-tenant de todos esses adaptadores diferentes para módulos de memória, combinar todas essas receitas sofisticadas e descobrir na hora o que fazer, sem ninguém no circuito. E isso é literalmente AGI. Não estou dizendo que não quero isso. Estou dizendo que sim, quero isso, mas também digo que esse é o outro lado de uma moeda que parece muito mais tedioso. E isso é apenas, acho eu, de muitas maneiras, a conclusão natural do

01:38 caminho em que estamos hoje. E, à medida que os modelos que usamos melhoram no ritmo atual, esse tipo de coisa vai parecer bastante normal daqui a pouco. E eu simplesmente não acho que isso vá parecer uma mudança explosiva que transforma o mundo, exceto pelo fato de que já parece assim. Já é impressionante que os modelos façam o que fazem. Mas os iPhones eram assim não faz tanto tempo. A nuvem era assim. Os carros eram assim. Temos tecnologias incríveis que estão mudando o

02:10 mundo o tempo todo, de muitas maneiras. E nos acostumamos a elas muito rápido. Então, é mais ou menos isso que quero dizer com essa afirmação: vamos nos acostumar. Vai ser normal. Vai ser bom. Vai ser incrível. E quero pensar em ferramentas versus software como uma forma de refletir sobre como interagimos com nossas ferramentas hoje, como interagimos com agents hoje e sobre os tipos de empresas que as pessoas estão criando. Para muitos de nós, a principal experiência com agents é no terminal, ou em algum produto que é mais ou menos uma interface gráfica agradável e sofisticada sobre uma experiência de terminal, seja

02:40 Cursor, Claude Code, Codex ou coisas do tipo. E brincamos com agents. Nos divertimos bastante. Nós os orquestramos, pulando entre todas essas abas e deixando várias sessões de terminal abertas. Escrevemos nossos prompts e salvamos nossos arquivos de skill. É muito barato experimentar. Podemos testar as coisas rapidamente. Podemos nos divertir bastante reescrevendo nossas skills. Vemos os modelos fazerem algo e pensamos: “Ah, que ótimo.” E continuamos levando ao extremo, até percebermos que falha, e pensamos: “Ah, os modelos ainda não chegaram lá.” Então recuamos, porque ficamos confiantes demais, e depois reclamamos da quantização, mesmo que seja só uma questão de se acostumar com os modelos sendo

03:13 bons e depois levá-los além dos próprios limites. E não fazemos evals de verdade além desse tipo de impressão geral. Na maior parte das vezes, não medimos de verdade o que fazemos com nossos agents no dia a dia. Não conheço muitos desenvolvedores de software que poderiam me dizer a taxa de aprovação dos agents que usam para programar. A questão é só quantas vezes você sente que precisa gritar com o sistema que está criando e quantas vezes precisa mudar seus arquivos de skill, AGENTS.md e coisas desse tipo. Mas, na produção, quando criamos empresas em torno de agents, muitas das ideias para esses produtos de agent vêm dessas experimentações em que testamos coisas no terminal. Experimentamos e percebemos: “Ah, se eu encadear estas ferramentas e tiver um

03:46 workflow assim, quero executá-lo o dia todo. Não quero executá-lo só uma vez. Quero que seja uma tarefa agendada, ou um workflow recorrente, ou que eu o incorpore a uma skill e tenha um cron job que o execute toda manhã.” Mas os produtos que estamos criando também se parecem com isso. São agents em produção, e os produtos pegam ideias que testamos ao observar do que os modelos são capazes e quais são as capacidades emergentes da última rodada de treinamento dos laboratórios. Transformamos isso em algo que pode ser empacotado mais facilmente e oferecido a mais pessoas, para proporcionar a elas uma nova experiência de uso de IA.

04:17 E fazemos a orquestração por meio de código. Chamamos os agents por APIs. Fazemos controle de versões. Fazemos lançamentos e reversões. E adotamos a abordagem dos desenvolvedores, escrevendo especificações de maneira mais sistemática. Começamos a pensar em evals. Começamos a pensar em usar otimização de prompt. E começamos a nos preocupar com custo, latência e desempenho. Se você está lançando um agent em produção que atende muitos usuários, quer perceber regressões. Não dá para fazer uma impressão geral em escala, com todos os seus usuários o dia inteiro. Você não quer simplesmente esperar as pessoas reclamarem. Precisa ter um processo. É assim que um produto de agent ou um workflow de agent amadurece: começa a parecer menos uma ferramenta e mais um software.

04:50 E é assim que descobrimos os workflows. Fazemos essas experimentações para entender que programas agênticos são possíveis hoje, algo que está mudando muito rápido. Então, estamos sempre iterando. Sempre experimentamos algo novo. Estamos sempre reescrevendo nosso software. Mas reescrever software não é um fenômeno novo. Veja qualquer repo que você usa, qualquer biblioteca, e observe o histórico das versões ao longo do tempo. Muita coisa mudou. Muitas coisas acontecem porque uma mudança em um lugar significa que outra coisa também precisa mudar. E esse efeito dominó continua, esse efeito dominó se propaga por todo o

05:20 software interconectado. E muito disso é manutenção. É fazer com que a coisa — você quer adicionar recursos. Quer que ela faça algo melhor, mas também precisa acompanhar tudo o que está mudando ao redor. É isso que acontece em produção quando você lança software. E também estamos percebendo que isso precisa acontecer em produção quando lançamos agents. Como eu estava dizendo, os usuários vão ver algo, vão adorar, vão perceber que aquilo faz uma coisa, vão se empolgar e tentar algo mais difícil que ainda não consegue fazer. Depois vão reclamar, e isso vai ser incorporado a algo que você quer que ela consiga fazer. É uma ideia de novo recurso. É uma nova capacidade.

05:51 É um novo teste de regressão. Então, esse ciclo de experimentação é tanto a forma como construímos nossos agents quanto, depois que lançamos um produto com agent para os usuários, aquilo que eles vão fazer; e é o que vai impulsionar isso: a mudança na distribuição, o ciclo de aprimoramento que define para onde o conjunto de funcionalidades dos produtos que queremos criar deve ir. Isso não é algo específico de IA. É como quando você oferece a alguém um novo site, um novo produto de telefonia: as pessoas exploram, experimentam coisas, descobrem o que acham que faz sentido e o que gostariam que o produto fosse capaz de fazer. Elas têm novas ideias ao ver o que ele consegue fazer e querem que ele siga uma nova direção, e

06:23 então você precisa acompanhar. Definir a meta vem simplesmente de receber esse fluxo de feedback, que vem das métricas que você coleta sobre o comportamento dos usuários: quanto tempo as pessoas ficam na página, qual é a velocidade de recarregamento e com que frequência elas tentam fazer a mesma coisa de novo. Você reúne tudo isso e, como já comentamos um pouco esta noite, queremos transformar esses dados em evals. Evals são, de certa forma, a métrica que nos permite avaliar se o modelo está fazendo corretamente o que se espera de um modelo, de acordo com o que me importa. E evals são ótimas porque você pode usá-las para tudo. Você pode transformá-las em ciclos de otimização do harness para escolher suas skills.

06:56 Você pode usá-las simplesmente para escolher qual modelo usar. Quer usar Claude ou GPT para este workflow? Provavelmente é melhor fazer uma eval. E então escolher aquele que tiver o melhor desempenho na sua eval, se ela for boa. Isso significa que você precisa garantir que a eval seja boa, fazendo uma validação em um nível mais alto, como uma avaliação intuitiva baseada nela. A meta deve ser que a eval capture essa avaliação intuitiva. A avaliação intuitiva, por si só, não é escalável, mas é um processo iterativo muito útil para descobrir como a eval deve ser. Porque, em algum momento, você precisa olhar para o que o modelo diz e conferir. E isso também começa a mostrar qual é a visão da distribuição

07:27 com a qual você se importa. Então, você pode usar os modelos para explorar todos os dados dos seus usuários, começar a fazer avaliações intuitivas com base nesses dados e começar a fazer perguntas aos modelos, fazendo com que eles busquem informações nos dados e comecem a revelar padrões, modos de falha, casos de teste e casos extremos com os quais você deve se importar. Depois, você quer fazer coisas como gerar dados sintéticos, fazer distillation e RL. Há vários casos de uso diferentes para essas evals, mas, na verdade, elas são apenas o mesmo que um KPI. São o mesmo que qualquer métrica que você acompanha em um dashboard. É simplesmente algo que você monitora enquanto seu software está em produção no mundo real e

07:57 recebe feedback de usuários reais. Em produção, o que importa é o grau de maturidade, e é isso que permite às empresas de software escalar e lançar software que seja econômico para muitos usuários e tenha margens altas. Isso vem da evolução de um script escrito por alguém — que é apenas a ideia dessa pessoa para um novo recurso —, que então entra no roadmap e se torna um produto, porque passou por todas as etapas necessárias para se tornar algo realmente ótimo para o usuário final. E é isso que fazemos quando também experimentamos agents: testamos coisas e temos ideias.

08:28 Vamos avançando com elas pelo ciclo de maturidade até chegar ao ponto em que não estamos apenas escolhendo um modelo, mas também nos preocupamos com objetivos que talvez nenhum dos modelos consiga alcançar, mesmo depois de toda essa otimização. Porque sempre vamos ver o que a coisa consegue fazer, ter novas ideias e querer algo diferente. Ainda não terminamos de criar software, mesmo que seja mais fácil e rápido criá-lo. Estamos criando mais software do que nunca porque ainda não terminamos de criar software. E isso acontece porque, quando vemos algo funcionar, queremos saber o que mais poderíamos fazer. Estamos sempre em busca da próxima coisa. Então, isso vai continuar até que, sei lá, tenhamos resolvido toda a entropia

09:03 no universo das coisas possíveis que as pessoas poderiam querer fazer, e não reste mais nada para fazer porque literalmente já fizemos tudo e, de algum modo, nos lembramos de tudo. Queremos mais, então vamos querer experimentar coisas novas, o que significa que haverá necessidade de novos recursos, novas capacidades, novos casos de uso, mais eficiência e menor latência, além da descoberta dessa curva da fronteira de Pareto entre capacidades, recursos, custo e latência. É disso que tratam os ciclos de vida do software, e também os ciclos de vida dos modelos. Não vou dedicar muito tempo a distillation e RL, mas acho que essas são as famílias de métodos

09:35 que você deve conhecer. O SFT é ótimo. A distillation on-policy de um teacher da mesma família também é ótima, se você tiver um modelo maior do qual possa destilar on-policy para um modelo menor. Fazer isso online traz benefícios, pois ajuda a evitar o esquecimento e a preservar as informações. Também envolve trade-offs: em alguns casos, a coisa da qual você está fazendo distillation está muito distante da policy. Quanto mais online você opera, mais precisa estar on-policy. Essa é, de fato, a tensão entre essas duas famílias de métodos. Pessoalmente, sou muito fã de distillation de contexto offline; acho que é ótima, especialmente se você a combinar com distillation on-policy de um teacher da mesma

10:06 família. Assim, você pode treinar dados em um teacher. Esse teacher passa a conhecer o modelo e o que você quer que ele aprenda, mas não é necessariamente um ótimo modelo para executar a tarefa, porque você acabou comprometendo algumas coisas no processo. Mas, dentro da distribuição, você pode fazer distillation online a partir desse novo teacher. Esse é um processo relativamente repetível: você pode criar novos teachers fazendo distillation de contexto ou outros tipos de distillation. Essa é outra maneira de incorporar essas informações ao modelo. Em geral, é isso que eu recomendaria às pessoas, em vez de partir direto para OPSD. Acho que muita gente ficou muito empolgada com OPSD.

10:37 Tive muitas conversas, vi muitos resultados experimentais, inclusive dos meus próprios experimentos, e isso não funciona da maneira que as pessoas imaginam. De longe, parece algo muito elegante; parece que deveria ser simplesmente mágico. Mas acontece que não é magia. Ainda obedece às leis da física, e inserir conhecimento em um modelo é difícil: não existe solução mágica. Mas acho que, especialmente nos casos em que você depende de recuperação de informações, ferramentas e busca no sistema para obter os fatos, uma das maneiras mais fáceis e relativamente confiáveis de melhorar o modelo é RL. E acho também que RL é o método mais alinhado à Bitter Lesson no que diz respeito à dualidade entre eval e ambiente,

11:11 em que você se importa com suas métricas e quer apertar um botão para fazê-las subir. RL é, de certa forma, o botão para isso. Ele aprenderá algumas coisas melhor do que outras. Mas acho que, em certos casos, aquilo que ele não faz em termos de injeção ou consolidação de conhecimento são justamente coisas que muitas vezes as pessoas também não querem codificar diretamente no modelo, porque há diferentes ciclos de vida para a frequência com que essas coisas são atualizadas. Existem patches e lançamentos major e minor, e você quer poder pensar em como escalar o modelo de forma robusta sem colocar algo nele

11:41 vai ser difícil de remover. E, assim, o que o RL aprende geralmente acaba sendo mais cirúrgico, em torno da fluidez e da manutenção do harness. Então, acho que um caso de uso muito natural para RL online é quando você está sempre atualizando seu harness: dá para fazer RL online no harness. E, se o harness mudar um pouco ou o system prompt mudar um pouco, tudo bem, porque o RL consegue, de certa forma, levar essas diferenças em conta bem rápido. Então, acho que esses são os casos de uso. Ou, por exemplo, seleção: você pode usar RL para fazer o roteamento de modelos. Você pode ter um modelo pequeno, projetado com RL para entender, tudo bem, para a

12:12 família atual de modelos que estou considerando, qual é o melhor para cada tarefa? Isso é muito mesmo um problema clássico e canônico de RL, e há muitas coisas assim em que não é preciso ir direto para a competição com Cursor, Anthropic ou OpenAI. É mais uma questão de: onde a otimização direta de uma métrica se encaixa nos pipelines de modelos dos sistemas que você está criando? E então há o extremo disso, em que acho que um caminho que vejo mais empresas seguindo, e que ocupa boa parte do que penso o dia inteiro e do que estamos desenvolvendo, é facilitar para que as empresas sejam muito

12:44 nativas de ambientes, em que você quer que seus agents funcionem como ambientes por padrão. Você quer que a produção se torne… quer conseguir simular o mundo dos produtos que está criando em toda a empresa, em termos do fluxo de dados. E acho que, quando você diz a alguém: “Ei, quer transformar sua empresa em um ambiente de RL? Assim, você pode treinar seu modelo na sua própria empresa e fazer com que ele melhore continuamente?”, isso parece loucura e ficção científica. Mas, se você disser: “Ei, você quer um ambiente de desenvolvimento e um de produção?”, a pessoa responde: “Sim, claro.” E é mais ou menos isso. É a sua versão de desenvolvimento. Você precisa conseguir fazer deploy da coisa de um jeito que não prejudique a produção de verdade. E esse é um ambiente que se parece com a escala em que você está

13:16 fazendo deploy de modelos. Então, independentemente de você estar treinando todos os modelos, transformar o sistema inteiro em algo que possa ser avaliado por padrão, e em que coletar traces e avaliá-los faça parte do ciclo de manutenção, de forma nativa no produto, é como vemos as pessoas querendo construir sistemas de software daqui para a frente, com modelos no circuito. Porque isso significa que você meio que obtém de graça tudo o que consegue com evals, já que não precisa ter uma versão de eval que corresponde a, digamos, 20% do seu produto. Você meio que quer que a superfície de avaliação passe a ser: onde quer que haja agents, é onde você executa evals. Porque aí você pode decidir: tudo bem, será que eu… você pode coletar

13:49 todos os seus traces e decidir se precisa deles ou não. Se não precisar, tudo bem. Quer RL aqui ou SFT ali? Tudo bem. A escolha é sua. O importante é que você queira que a avaliação tenha alta fidelidade. Você quer que a avaliação corresponda ao que está realmente vendo em produção, assim como quer que as métricas coletadas em produção sejam coisas que você consiga estimar no ambiente de desenvolvimento. E isso também levanta a questão: tudo bem, quando você constrói e quando compra? Quando faz um fork? Acho que é uma questão muito parecida com a do software convencional, em que você pode perguntar: tudo bem, quando você compra a solução de um fornecedor e a usa para algum tipo de

14:20 coisa de software, em vez de encontrar a melhor versão open source, fazer um fork e transformá-la na sua própria solução? Boa parte da resposta é: bem, quão boa é a melhor solução para o que você precisa? Quanto o seu caso de uso se afasta da distribuição dos casos principais para os quais a solução está sendo otimizada? E é ótimo que os modelos de ponta sejam muito bons na maioria das coisas, mas acho que uma solução única para todos raramente foi a solução mágica para qualquer coisa em software. E acho que, com os modelos, especialmente quando você considera todas as trocas entre custo, latência e desempenho, começa a perceber que muitas vezes quer algo mais especializado. Dá para obter praticamente qualquer produto de software em nuvem do mundo pela Amazon, GCP, AWS, GCP ou Azure. E, ainda assim, temos um milhão de novas nuvens surgindo todos os anos, porque há algo que não está muito bem resolvido na solução principal, e existe um nicho a descobrir ao dizer: “Tudo bem, vou criar os melhores ambientes isolados de navegador para agents. Vou criar o melhor armazenamento de código para agents. Vou criar o melhor ciclo de vida de deploy, porque o GitHub Actions é lento e quero algo que o substitua.” Há tantas coisas assim que, pela própria complexidade de tentar fazer tudo ao mesmo tempo, as empresas são empresas.

14:53 Elas têm um conjunto de acionistas, por assim dizer. Têm um preço para suas ações. E é difícil equilibrar as coisas em todos os prazos e manter todos os funcionários satisfeitos. Então, é difícil fazer tudo ao mesmo tempo numa grande empresa. E acho que isso também é verdade, em certa medida, para os laboratórios: eles vão criar modelos ótimos, muito bons em muitas coisas, mas será que vão criar o melhor modelo do mundo para tudo? Em geral, sou cético quanto a isso. E acho que um setor que gosto de citar, e que abraçou isso por completo, é o das finanças quantitativas. Se você perguntar a um quant que modelo ele usa, a resposta será: “Como assim? Tenho milhões de modelos.” Há um modelo para

15:23 tudo, porque há muitas escalas de tempo e muitas aplicações diferentes. E acho que esse é um dos setores mais voltados à superinteligência e ao aprendizado de máquina, no sentido de adotar plenamente o desenvolvimento separado da produção, modelos em toda parte, automatizar tudo, dados entrando e decisões saindo. E acho que os LLMs nos mostraram que boa parte do restante da economia também pode seguir esse caminho. Ainda precisamos pensar na complexidade. Ainda precisamos projetar esses sistemas. Ainda precisamos otimizá-los e nos importar com nossas métricas. Mas essa é uma ferramenta que nos permite levar coisas do domínio da estatística pura e das séries temporais para um trabalho de conhecimento mais geral.

15:54 Mas a complexidade dos tipos de aplicação de modelos continua… não há motivo para que seja menor do que a complexidade dos tipos de trabalho que as pessoas fazem, especialmente à medida que os modelos melhoram. Isso significa que precisamos considerar essas trocas de Pareto em todos os pontos da curva. Então, em algum momento, começamos simplesmente usando aquilo que funciona e depois decidimos: construímos ou compramos? Fazemos um fork? Há muitas bibliotecas open source excelentes por aí, e a maioria das pessoas não cria necessariamente softwares complexos inteiramente do zero quando chega a determinada escala. Você olha as referências do que outras pessoas já fizeram. Você constrói sobre o que veio antes, fica sobre os ombros de gigantes e cria novos softwares com base nos padrões, seja fazendo literalmente um fork ou usando os

16:25 padrões. Estamos sempre aprendendo com outras coisas. E acho que é a mesma coisa, seja você fazendo pré-treinamento do zero, destilação ou RL: projetar um modelo para um caso de uso é a versão de desenvolvê-lo internamente, por perceber que você precisa de algo especializado e personalizado, porque quer ir além do que a solução pronta vai oferecer, já que ela não considera seu caso de uso a prioridade máxima. E então surge esse ciclo de vida do desenvolvimento de modelos, em que queremos definir as especificações e saber com o que nos importamos. Queremos nos importar com nossas métricas. Depois treinamos o modelo. Usamos todos os nossos métodos.

16:57 padrões. Como estamos sempre aprendendo com outras coisas. E acho que isso é igual, seja fazendo pré-treinamento do zero, destilação ou aprendizado por reforço (RL): projetar um modelo para um caso de uso é a versão de desenvolvê-lo internamente, ao perceber que você precisa de algo especializado e personalizado, porque quer ir além do que a solução pronta para uso vai oferecer, já que ela não considera o seu caso de uso como a coisa mais importante. E assim surge esse ciclo de vida do desenvolvimento de modelos, no qual queremos definir as especificações, queremos saber com o que nos importamos. Queremos nos importar com nossas métricas. Então treinamos nosso modelo. Usamos todos os nossos métodos.

17:27 Testamos. Fazemos uma implantação em ambiente de teste. Lançamos. Monitoramos. Vemos como as pessoas usam. Tuitamos algo como: “Ei, me contem do que vocês gostam no novo modelo e em que aspectos ele poderia ser melhor”, porque as pessoas estão percebendo: “Ah, ele consegue fazer coisas novas, mas também não consegue fazer esta outra coisa nova”, porque A dá uma ideia para B, mas B não funciona muito bem, embora A funcione. E é assim que desenvolvemos produtos. É assim que estamos desenvolvendo modelos. É assim que os laboratórios desenvolvem modelos. Se você der uma olhada nas redes sociais de qualquer um deles, eles estão sempre perguntando aos usuários: “Ei, em que ele poderia ser melhor?” Porque sabem que as pessoas sempre vão ter uma ideia de algo novo. Sempre vão encontrar um novo caso de uso.

17:58 E é mais ou menos assim que é usar modelos hoje em dia. As pessoas reclamam do custo. As pessoas querem… Quanto mais as pessoas têm modelos poderosos, mais vão querer usá-los para coisas diferentes, o que significa que temos um botão que podemos girar para, tipo, dizer: “Certo, na verdade, podemos simplesmente melhorar algo tornando-o menor, mais especializado e mais focado, porque ele já não precisa fazer tudo”. Você paga um custo por modelos que conseguem fazer tudo, ou quase tudo, porque eles precisam ter pesos maiores e ser muito flexíveis em diferentes workflows. Mas, à medida que os processos e workflows amadurecem, você acaba pagando mais do que precisa, já que

18:29 não precisa mais de todas as outras capacidades. Você meio que quer sua solução personalizada, porque isso significa que pode iterar mais rápido. Pode ter mais controle, da mesma forma que as pessoas criam software do zero. Você não… nem sempre vai conseguir exatamente o que quer pelo preço certo, e muitas vezes pode conseguir algo bem mais barato se tiver algo muito mais adaptado às suas cargas de trabalho. E, assim como no desenvolvimento de software, o ciclo de vida do desenvolvimento de software está sempre se automatizando. Há muitas coisas que são meio que manutenção de rotina no software. Você precisa obter a documentação, precisa… você lança um novo SDK, faz integração contínua, faz builds noturnos, e engenheiros nunca foram de dizer:

19:01 “Vamos fazer isso manualmente todas as vezes.” Em geral, você quer automatizar o processo. É mais ou menos o que fazemos no software: encontramos algo que funciona e facilita nossa vida, então fazemos isso, e fazemos o suficiente para ganhar confiança de que é bom; depois descobrimos como nunca mais fazer isso, porque está automatizado. Então, acho que estamos nesta fase inicial agora, com o pós-treinamento, em que muita gente diz: “Ah, pós-treinamento é muito difícil”. Sim, é. É difícil. É irritante. É uma droga. É igual a executar CI/CD manualmente. Vamos chegar lá. Estamos trabalhando para automatizar o processo, porque estamos explorando os limites e entendendo as melhores práticas.

19:32 E então, quando tivermos as melhores práticas, ótimo, o mundo vai saber como fazer isso. E isso se torna o tipo de coisa muito mais rotineira e corriqueira, porque todos nós simplesmente temos nossos sistemas que… Vocês sabem como o GitHub Actions funciona? Eu, na verdade, não sei como o GitHub Actions funciona. Sei que não funciona muito bem, mas é… acho que é esse tipo de coisa que muita gente está sentindo em relação ao pós-treinamento: “Ah, eu tenho… há tantas coisas para aprender, tantos conceitos”; mas, na faculdade, todos nós aprendemos sobre sistemas operacionais nas aulas, se fizermos essas aulas, e há tantas coisas nos bastidores do software que acabam sendo abstraídas

20:03 e deixadas para trás. E eu já não sei como funciona uma B-tree. Em algum momento, eu sabia. Eu… soube Verilog por um semestre. Já não sei mais. Há tantas partes da pilha de software moderno que é útil estudar e depois esquecer, porque então você constrói por cima delas e as abstraímos. Acho que agora estamos todos na faculdade de pós-treinamento, tentando pensar: “Certo, que tipo de aprendizado por reforço funciona? Faço esta coisa?” Estamos resolvendo nossas listas de exercícios, experimentando, mexendo nas coisas, e então, em algum momento, crescemos e amadurecemos, e percebemos que é tipo: “Ah, nós simplesmente…” Bem, descobrimos quais coisas

20:35 funcionam e quais não, e começamos a ver como é essa curva de compensação: quando fazer isso, com quais dados, com qual receita. E estamos chegando lá. E, sim, a versão sem graça disso é simplesmente que o aprendizado contínuo são ciclos de vida de desenvolvimento de software para modelos, e estamos criando muito software com muitos modelos em… Então, acho que vamos querer algum tipo de ciclo de vida.

Transcrição original

[00:03] I’m Will Brown. I lead applied research at Prime Intellect. And my goal today is to convince you that continual learning is boring. And by this, I mean like you should do it. It’s where things are going. It’s the future. But it’s also like it’s becoming less sci-fi very quickly. And I think with what I’m going to talk about today, my goal is to kind of paint a picture of it that is going to feel more mundane. It’s going to feel regular. It’s going to feel like just, oh, of course, is the goal.

[00:34] This isn’t where we are today, but this is kind of the picture of where I think we will be not too long from now in terms of how continual learning for models fits into the products and deployments of companies like the ones I’m sure many of you here are building or working at today. And it’ll be borrowing lessons from software. So software now is boring. Software is a commodity. Software is free. Software is dirt cheap. The cost of software is going to zero. And yet we all build software. And soon I think models are going to look a lot like that. And so the exciting version of learning, the version that I think a lot of us like

[01:06] when we read blogs and think about new algorithms are like imagining in our heads is like, oh, we have an agent deployed in production and it’s designing its own training recipes. It’s like optimizing its own kernels. Weights are going to update every single token that flows through, and like it’s going to be like doing multi-tenant hot swapping of all these different adapters for memory modules and combining all these fancy recipes and figuring out like what to do on the fly with no human in the loop, and it’s like literally AGI. And I’m not saying no to this. I’m saying yes to this, but I’m saying this is also the other side of a coin that looks much more boring. And this is just kind of, I think, in many ways the natural conclusion of like the

[01:38] path we’re on today. And like as the models we’re using get better and better at the rate that they are, like this is the sort of thing that like is going to feel just pretty normal not that long from now. And I just, I don’t think it’s going to feel like this explosive world-changing thing, except in the way that it already does. Like it already does feel wild that the models are doing what they’re doing. But iPhones were like that not so long ago. The cloud was like this. Cars were like this. Like, we have technology that is incredible and changing the

[02:10] world all the time in many ways. And we get used to it really quickly. And so, that’s kind of what I mean by this claim, is that we’re going to get used to it. It’s going to be normal. It’s going to be fine. It’s going to be amazing. And I want to think about tools versus software as like the way that we interact with our tools today and the way we interact with agents today and the kinds of companies people are building. A lot of us, our primary experience with agents is in the terminal, or it’s with some product that is kind of a nice glossy GUI on top of a terminal experience, be

[02:40] it Cursor, Claude Code, or Codex, or things like this. And we play with agents. We’re having a lot of fun. We’re like orchestrating them by like hopping on all these tabs and like having a bunch of terminal sessions open, and we’re like writing our prompts, and we’re saving our skill files. And it’s like really cheap to play. We get to experiment quickly. We get to have a lot of fun rewriting our skills, and like we see the models do a thing and then we’re like, “Oh, this is great.” And we keep pushing it to the extreme and we realize it fails and we’re like, “Oh, the models aren’t quite there yet.” And then we walk back to a thing because we got overconfident, and then we complain about quantization, even if it’s just like getting used to the models being

[03:13] good and then pushing them beyond their limits. And we don’t really eval it beyond this sort of vibe check. We’re not really measuring what we’re doing with our agents day-to-day most of the time. Like I don’t know too many software developers who could tell me their pass rate of their agents that they’re using for coding. It’s just how often do you feel like you have to yell at the system you’re building, and how often you have to change your skill files and AGENTS.md and these sorts of things. But then in production, when we’re building companies around agents, well, a lot of the ideas we’re doing for these agent products come from this experimentation where in the terminal we’re playing with things. We’re trying stuff out and we see, oh, if I chain together these tools and have a

[03:46] workflow that looks like this, I actually want to run this all day. I want to run this not just like on a one-off thing, but I’m going to have, it’s going to be a scheduled task, or it’s going to be a recurring workflow, or it’s gonna, I’m going to bake it into a skill and have a cron job that like runs this every morning. But these are also what the products that we’re building look like. They’re, the products are agents in production that are taking ideas that we experimented with from seeing what the models are capable of and what the emerging capabilities of the last training run from the labs has been. And we’re turning this into a thing that can then be packaged more easily and given to more people to give them a new experience around using AI.

[04:17] And we’re orchestrating this via code. We’re calling the agents via APIs. We’re doing versioning. We’re doing releases and rollbacks. And we’re taking the developer approach of authoring specs more systematically. We start thinking about eval. We start thinking about using prompt optimization. And we start caring about cost, latency, and performance. And if you’re shipping an agent to prod that is serving tons of users, you want to notice regression. You can’t do the vibe check at scale for all your users all day. You don’t want to just wait for people to complain. You need to have a process. And this is how it, what it looks like for an agent product or an agent workflow to become mature, is that it starts looking less like a tool and more like software.

[04:50] And this process is how we discover the workflows. Like we are doing these experimentations to understand like what are the agentic programs that are possible today, which is changing very quickly. And so we’re always iterating on this. We’re always trying a new thing. We’re always rewriting our software. But like rewriting software is not a new phenomenon. Like look at any repo that you use, any library, and look at like the history of the versions of it over time. Like it’s changed a lot. Like there’s a lot of things that happen because one thing changes that means another thing has to change. And this domino effect keeps, this domino effect just cascades throughout all of

[05:20] software that’s interconnected. And so a lot of it is maintenance. It’s making the thing, you want to add features. You want to make it better at a thing, but you also have to keep up with whatever, everything else that’s moving around it. And this is what happens in production when you ship software. And this is also what we’re realizing has to happen in production when you ship agents. As I was mentioning, users will see a thing, they’ll love it, they will find that it does one thing, they’ll get excited and try a harder thing that it actually can’t do yet, and then they’ll complain, and then this gets fed back into a thing that you want the thing to be able to do. It’s a new feature idea. It’s a new capability.

[05:51] It’s a new regression test. And so this experimentation loop is both how we build our agents, but also once we ship an agent product to users, it’s what they’re going to do, and it’s going to be what’s driving this, the distribution shift, the cycle of improvement of where the feature set should be going for the products we want to build. This is just like, this is not an AI-specific thing. This is like when you give someone a new website, a new phone product, people explore, people try stuff out, people figure out what they think makes sense, what they would like it to be able to do. They get new ideas from seeing what it can do, and they want it to be different in a

[06:23] new direction, and so you have to keep up. And so defining the goal is just from getting this stream of feedback that comes from the metrics you collect about user behavior and how long people stay on the page and like how fast is your reload time and like how often are people retrying the same thing. And you take all these, and as we’ve kind of all talked about already tonight, we want to turn these into evals. Evals are kind of like the metric that allow us to kind of look at, is the model doing model stuff correctly for what I care about? And the evals are great because you can use them for everything. You can turn them into harness optimization loops for choosing your skills.

[06:56] You can use it to just pick which model. Do you want to use Claude or GPT for this workflow? You probably want to eval. And just like pick whichever one does best on your eval if your eval is good, which means you need to make sure your eval is good by doing some higher-level grounding in like doing the vibe check based on the eval. And the goal should be that the eval captures the vibe check. Like the vibe check on its own is not a scalable thing, but it’s a very useful iterative process to uncover what the eval should be. Because like we just, at some point you have to go look at what the model says and check it, and this also starts telling you what is the picture of the distribution

[07:27] that you care about. And then you can go use the models to explore all of your user data and start vibe checking against your user data and start asking questions to the models and have these models pull from the data and kind of start surfacing these patterns and the failure modes and the test cases and the edge cases that you want to care about. And then you want to do these things like generate synthetic data, do distillation, do RL. And there’s a bunch of different use cases for these evals, but really it’s just the same thing as a KPI. It’s the same thing as any metric you check on a dashboard. It’s just something you’re watching as your software is deployed in the world and

[07:57] it’s getting feedback from real-world users. And in production, maturity is kind of what matters, and it’s what allows software companies to scale and deploy software that is like cost-effective for a great many users with great margins. And it comes from evolving from someone wrote a script, which is just their idea for a new feature, that then gets onto the roadmap and becomes a product because it’s kind of gone through all the stages of being hardened into something that is actually like great for the end user to experience. And this is really what we’re doing when we’re playing with agents as well, is we’re testing stuff out. We’re coming up with ideas.

[08:28] We’re moving them along the maturity cycle to get to the point where we’re not just picking a model, but we’re also caring about objectives that maybe none of the models, even after all this optimization, like because we’re always going to see what the thing can do and get new ideas and want something else. Like we have not finished building software yet, even if it’s easier and faster to build software. We’re building more software than ever because we haven’t finished building software yet. And this is because when we see a thing that works, we want to know what else we could do. We’re always looking for the next thing. And so this is like, until we have kind of like, I don’t know, solved all entropy

[09:03] in the world of possible things people could want to do, and there’s just nothing left to do because we’ve done literally everything and we’ve somehow remembered it all, we want more, and so this will mean we want to try new things, which will mean there’s a need for new features and new capabilities and new use cases and more efficiency and lower latency, and discovering this curve of the Pareto frontier between capabilities, features, cost, latency. This is what software life cycles are about, and it’s also what model life cycles are about. And so distillation and RL, I won’t spend too much time on this, but I think these are the families of methods you

[09:35] should be aware of, which is that SFT is great. On-policy distillation from a same family teacher, if you have a bigger model that you can distill on-policy into a small model, is great. Doing it online has benefits of being better for not forgetting and remembering. It also has trade-offs of, in some cases, if the thing you’re distilling from is like too far off-policy. Like the more online you go, the more on-policy you kind of need to be. And so this is really the tension between these two families of methods. And so I personally am a big fan of offline context distillation, I think is great, especially if you combine it with on-policy teacher distillation from the same

[10:06] family. So you can train data into a teacher. This teacher now knows the model, knows the stuff you want to learn, but it’s not necessarily like a great model for doing the thing because it has, you’ve broken things in the process, but you can within distribution do online distillation from this new teacher. And this is a relatively repeatable process where you can kind of create new teachers by doing context distillation or other kinds of distillation. And then this is another way you can bake them into the model. And this is generally what I would recommend to people over jumping right to OPSD. I think a lot of people have gotten very excited about OPSD.

[10:37] I’ve had a lot of conversations and seen a lot of experimental results, and of my own, where it doesn’t work the way people imagine it would. It has a nice, if you look at it from a bird’s-eye view, it looks like it should just be magic. But it turns out it’s not magic. It still follows laws of physics, and like injecting knowledge into a model is hard, and there’s not a silver bullet. But I think especially in cases where you are kind of leaning on retrieval and tools and system search to get your facts, one of the easiest ways to just fairly reliably improve the model is RL. And I think RL is also the one that is most kind of Bitter Lesson-aligned with the

[11:11] eval-environment duality, where you care about your metrics and you want to press a button to make your metrics go up. RL kind of is the button to do this. And some things it’ll learn better than others. But I think in some cases the things that it doesn’t do in terms of like knowledge injection or consolidation are the sorts of things that often people don’t want to, like, have hard-coded into the model anyways, because there’s different life cycles of how fast you update these things. There’s like patches and major and minor releases, and you want to be able to think about like, how can I like robustly scale the model without like putting something in

[11:41] that’s going to be hard to take out. And so the stuff that RL learns generally ends up being, it’s more surgical around fluidity and harness maintenance. And so I think a very natural use case for online RL is if you’re always updating your harness, you can do online RL in the harness. And if the harness changes a little bit or the system prompt changes a little bit, like that’s okay because the RL can kind of account for these differences very quickly. And so I think those are the use cases, or like selection, you can use RL to do model routing. You can have a small model that is designed with RL to understand, okay, for the

[12:12] current family of models I’m considering, like which one’s best for which task. Like this is very much a canonical, classic RL problem, and there’s lots of things like this where it doesn’t need to be jumping all the way into, I’m competing with Cursor or Anthropic, OpenAI. It’s more just about like, where does direct hill climbing of a metric fit into the model pipelines for the systems you’re building? And so then there is the extreme of this, where I think one place I see more companies going, that I think is often a lot of what I think about all day and what we’re working on, is making it easier for companies to just be very environment

[12:44] native, where you want your agents to just be environments by default. You want the production to become, like you want to be able to simulate the world of the products you’re building over the company itself in terms of the data flow. And I think when you tell someone, hey, do you want to turn your company into an RL environment? Like, so you can train your model in your own company and have it be continuously improving? It sounds crazy and sci-fi, but if you say, hey, do you want like a dev and a prod? They’re like, yeah, of course. And like that’s kind of what it is. It’s like, it’s your dev version. You need to be able to deploy the thing in a way where it’s not actually breaking prod. And that is an environment that looks like the scale at which you’re

[13:16] deploying models. And so whether or not you’re training all the models, like turning the full system into something that is evaluatable by default, and where collecting traces and evaluating it as part of the life cycle of maintenance is just native in the product, is the way that we see people wanting to build software systems going forward with models in the loop. Because it just means that all the things you get out of evals, you kind of get for free now, because you don’t have to like have a, oh, I’m going to have my eval version that like is like 20% of my product. You kind of want the eval surface to become, wherever agents are is where you’re evaling. Because then you can make the choice of like, okay, do I, you can collect

[13:49] all your traces and say, do I need them or not? If you don’t, that’s fine. Do you want RL here or SFT there? Like, it’s fine. It’s up to you. It’s just that you want the eval to be high fidelity. You want the eval to match what you’re actually seeing in production, the same way that you want your metrics you collect in prod to be the sorts of things you can estimate in dev. And so this also raises the question of like, okay, when do you build versus buy? When do you fork? And I think it’s a very similar question to normal software, where you can ask like, okay, when do you buy a vendor solution and just use it for some kind of

[14:20] software thing, versus when do you find the best open-source version and fork it and make it your thing? And a lot of it is like, well, how good is the best thing at your thing? How far out of distribution is your use case from the main thing that the thing is optimizing for? And like it is great that the frontier models are quite good at most things, but I think one-size-fits-all has rarely been the silver bullet solution for anything in software. And I think models, especially once you have all the trade-offs of cost, latency, and performance, you start realizing that oftentimes you want the more specialized thing. Like you can get almost any software cloud product in

[14:53] the world from Amazon, GCP, AWS, GCP, or Azure. And yet we have a million new clouds starting every year because there’s something that is not quite there in the mainline thing, that there’s a niche to uncover by saying, “Okay, I’m gonna make the best browser sandboxes for agents. I’m going to make the best code storage for agents. I’m going to make the best like deployment life cycle loop because GitHub Actions is slow and I want to have something that replaces it.” And there’s so many of these things where just the nature of like complexity of trying to do everything at once is that companies are companies.

[15:23] They have kind of one set of shareholders. They have one stock price. And it’s hard to balance things on every timeline and keep everyone happy that works there. And so like it’s hard to do everything at once as a big company. And I think to some degree this is true of the labs as well, where it’s like they’re going to make great models that are really good at a lot of things, but are they going to make the best model in the world for everything? I’m generally skeptical of this. And I think one industry I like to point to that I think has kind of fully embraced this is quantitative finance, where if you ask a quant what model they use, they’re like, “What do you mean? I have millions of models.” There’s a model for

[15:54] everything because there’s so many time scales, there’s so many different applications. And I think that is one of the more superintelligence, machine learning-pilled industries in terms of embracing just like full-on dev versus prod, models everywhere, automate everything, just data comes in, decisions come out. And I think what LLMs have shown us is that this is kind of where a lot of the rest of the economy can head too, where it’s just, we still have to think about the complexity. We still have to design these systems. We still have to optimize these systems and care about our metrics. But it’s a tool that allows us to take stuff from the realm of pure statistics and time series into more general knowledge work.

[16:25] But the complexity of types of model applications is still, no, there’s no reason it should be any smaller than the complexity of types of work people do, especially as models get better. Which means we do have to care about these Pareto trade-offs at every point of the curve. And so at some point we start by just using the thing that works, and then we decide, do we build versus buy, do we fork? And there’s a lot of great open-source libraries out there, and most people don’t build complex software necessarily fully from scratch above a certain scale. You kind of look at the references of what people have done before. You build on the, you stand on the shoulders of giants, and you build new software based on the patterns, whether it’s literally forking or it’s using the

[16:57] patterns. Like we’re always learning from other things. And I think this is the same as like, whether you’re doing pre-training from scratch or whether you’re doing distillation or whether you’re doing RL, like designing a model for a use case is the version of building it in-house, for realizing that you need something that is specialized and custom, because you want to go beyond what the out-of-the-box thing is going to give you, because the out-of-the-box thing is not thinking about your use case as the top most important thing. And so we have this life cycle then that emerges of model development, where we want to spec, we want to know what we care about. We want to care about our metrics. Then we train our model. We use all of our methods.

[17:27] We test it. We stage it. We release it. We monitor it. We see how people use it. We tweet about, hey, let me know what you like about the new model and what things it can be better at, because people are realizing, oh, it can do new stuff, but it also can’t do this other new thing, because your A gives you an idea for B, but B doesn’t quite work even though A works. And this is the way that we develop products. It’s the way that we’re developing models. It’s the way that the labs develop models. If you kind of look at any of their social media presences, they’re always asking users, hey, what can it be better at? Because they know that people are always going to have an idea of a new thing. They’re always going to find a new use case.

[17:58] And that’s kind of what it is like to use models nowadays. People are complaining about cost. People want, the more that people have powerful models, the more of them they’ll want to use for different things, which means we have this knob we can turn of like, okay, we actually can just like make a thing better by making it smaller and more specialized and focused because it no longer needs to do everything. You’re paying a cost for models that can do everything or almost everything by having them need to have larger weights and be very flexible across workflows. But as processes and workflows mature, you’re kind of overpaying in that you

[18:29] don’t need all of the other capabilities anymore. You kind of want your custom solution because it means you can iterate faster. You can have more control, just in the same way that people build software from scratch. You don’t, like, you’re not always going to get the exact thing you want at the right price, and you can often get something much cheaper by having something that is much more tailored to your workloads. And just like with software development, the software development life cycle is always automating itself. There’s a lot of things that are kind of routine maintenance you do in software. You have to get the docs, you have to, you ship a new SDK, you do continuous integration, you do nightly builds, and engineers have never been ones to say,

[19:01] “We’re just going to do it manually each time.” Like, generally, you want to automate the process. It’s kind of like what we do in software is we figure out a thing that works and makes our lives easier, then we do it, and we do it enough that we gain confidence that it’s good, and then we figure out how to never do it again because it’s automated. And so, I think we’re in this early stage of this right now with post- training, where a lot of people are like, “Oh, post-training is really hard.” Yes, it is. It’s hard. It’s annoying. It sucks. Same as like running manual CI/CD. Like we’re going to get there. We’re working on automating the process of it because we’re poking at the edges of it and understanding the best practices.

[19:32] And then once we have the best practices, then great, the world knows how to do it. And it becomes the sort of thing that becomes much more routine and mundane because we all just like have our systems that like, do you guys know how GitHub Actions work? I don’t actually know how GitHub Actions work. I know it doesn’t work very well, but it’s, this is the sort of thing where I think a lot of people are having this feeling about post-training, where it’s like, oh, I have, there’s so many things to learn, so many concepts, but like in college we all like learn about operating systems classes, if we take those classes, and like there’s so many things that are under the hood in software that eventually get abstracted

[20:03] away. And I don’t know how a B-tree works anymore. At some point I did. There’s, I knew Verilog for one semester. I don’t know it anymore. There’s so many pieces of the stack of modern software that are useful to go through and then forget, because then you build on top of them and we abstract them away. I think now we’re all in post-training college right now, in terms of trying to think like, okay, what type of RL works, do I do this thing? Where we’re doing our problem sets, we’re experimenting, we’re tinkering, and then at some point we grow up and mature, and we realize it’s like, oh, we just, well, we figure out the things that

[20:35] work and the things that don’t, and we start seeing what this trade-off curve looks like for when do you do it, on what data, with what recipe, and we’re getting there. And yeah, the boring version of it is just that continual learning is software development life cycles for models, and we’re building a lot of software with a lot of models in… And so I think we’re going to want some life cycle.