Como criamos um agent que melhora a si mesmo — Zubin Aysola, Weights & Biases

Autoria: AI Engineer · 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: How We Built an Agent That Improves Itself — Zubin Aysola, Weights & Biases · Canal: AI Engineer · 17:04 · Assistir no YouTube

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

Resumo

Zubin Aysola apresenta Arya, um agent da Weights & Biases, e explica como a equipe o desenvolve usando avaliações offline e traces de produção. O ciclo de melhoria combina o Weave para observabilidade, uma simulação alinhada ao ambiente de produção e tarefas criadas a partir de interações reais. Arya consegue analisar traces, propor tarefas e testar variantes do próprio sistema. A abordagem busca automatizar experimentos sem abrir mão da análise humana sobre como o agent deve melhorar.

Pontos-chave

A equipe busca manter o código de pesquisa e o de produção idênticos para evitar divergências entre os ambientes.
O Weave é usado para observar traces tanto em produção quanto em avaliações offline.
Traces de produção, incluindo falhas e comportamentos bem-sucedidos, podem virar tarefas de avaliação.
A equipe testa diferentes configurações e variantes do agent, usando experimentos paralelos para comparar resultados.
As tarefas de avaliação incluem instruções simples e simulações multi-turn com personas de usuários.
As avaliações medem tanto a conclusão de tarefas quanto diferenças relativas de comportamento entre variantes.
Arya pode analisar traces, criar tarefas, testar variantes e relatar os resultados de suas execuções.
A automação dos experimentos não elimina a necessidade de julgamento humano sobre como melhorar o sistema.

Capítulos

Início	Capítulo	Resumo
00:16	Arya e o desafio de avaliar agents	Zubin Aysola apresenta Arya e explica por que a avaliação precisa acompanhar as mudanças nas configurações dos agents.
04:31	O ciclo entre produção e avaliações offline	O palestrante demonstra como traces de produção alimentam avaliações offline e como os resultados orientam novas versões do agent.
08:13	Como construir ambientes de simulação	A equipe configura ambientes, executa o agent e mede seu desempenho para comparar variantes sem se afastar do comportamento de produção.
11:51	Tarefas e traces como dados de avaliação	A equipe organiza tarefas, executa avaliações repetidas e transforma comportamentos observados em produção em oportunidades de melhoria.
15:28	Arya testa melhorias em si mesmo	A demonstração mostra Arya analisando um trace, testando uma variante e propondo uma correção para um problema identificado.
16:30	Conclusões sobre o ciclo de melhoria	A palestra encerra destacando a relação entre métricas offline, dados de produção e melhoria iterativa dos agents.

Citações

Benchmarks, avaliações, os agents e a forma como você os configura variam em conjunto. — 01:19

Gere muitos traces e depois decida o que fazer com eles. — 06:39

É melhor executar mais experimentos do que menos. — 07:42

Automatizar não elimina a necessidade de pensar em como queremos fazer melhorias. — 14:57

Conceitos e entidades

Arya (ferramenta): É o agent da Weights & Biases apresentado na palestra, usado para pesquisa e melhoria iterativa do próprio sistema.
Weights & Biases (empresa): É a empresa onde Zubin Aysola trabalha e onde a equipe desenvolve Arya.
Weave (ferramenta): É a plataforma usada pela equipe para registrar e observar traces de produção e avaliações offline.
agent harness (conceito): É a estrutura de software que organiza o agent, suas ferramentas, configurações e formas de avaliação.
avaliação offline (conceito): É a avaliação do agent em um ambiente simulado, usada para comparar variantes antes de implantá-las em produção.
trace de produção (conceito): É o registro de uma interação real com o agent que pode ser analisado e convertido em tarefa de avaliação.
WBAF (conceito): É a sigla usada pelo palestrante para Weights and Biases Agent Factory, a estrutura de avaliação offline que ele desenvolve.
Zubin Aysola (pessoa): É o palestrante, que trabalha na Weights & Biases e apresenta o desenvolvimento e a avaliação de Arya.

Tradução completa (pt-BR)

00:16 Certo. Olá. Obrigado por terem vindo. Meu nome é Zubin Aysola. Trabalho na Weights & Biases. Estou desenvolvendo o agent Arya, que lançamos em disponibilidade geral na segunda-feira. Talvez vocês tenham visto a palestra do Tim, um dos meus colegas na Weights & Biases, com quem trabalho, no palco principal ontem. Então, vou explicar um pouco em profundidade como avaliamos e desenvolvemos o agent Arya e, em particular, o framework de avaliação que usamos e como usamos o Arya para se aprimorar no próprio ciclo de pesquisa. Também vou falar sobre algumas coisas da Weights & Biases

00:49 Então, sim, este é um recorte de alguns dos slides que apresentei na NeurIPS, mas acho que há coisas interessantes sobre o uso de agent harnesses. Imagino que a maioria das pessoas na plateia ou nesta conferência esteja animada para criar agent harnesses ou talvez usar o Claude Code com skills em uma variedade de pacotes diferentes. Mas há diferenças bastante significativas na maneira como esses agents de IA são empacotados quando usados com diferentes chamadas de ferramentas e assim por diante, em uma variedade de benchmarks. Inspirados por isso, estamos trabalhando na Weights & Biases para criar nosso próprio agent harness, que faça pesquisa para você na plataforma da Weights & Biases. Bom,

01:19 e provavelmente há outras coisas para as quais não preciso convencer ninguém, como por que queremos agents de software e por que usar um harness de software em vez de simplesmente deixar o LM à solta para chamar ferramentas ou fazer qualquer outra coisa. Mas não é esse o assunto aqui. Há um grande problema que se apresenta — é basicamente aquilo em que penso toda noite antes de dormir: benchmarks, avaliações, os agents e a forma como você os configura são todos covariantes. Portanto, se você está tentando aplicar avaliações bem fundamentadas a qualquer tipo de sistema que muda dinamicamente, precisa de boas medições para ver o desempenho real do sistema. E

01:51 você realmente quer ver como o sistema se sai tanto no ambiente de produção quanto no ambiente offline. Se você trabalha com RL há bastante tempo, talvez conheça a lacuna entre simulação e realidade, ou seja, como traduzimos ambientes de simulação para ambientes do mundo real e assim por diante. Vou falar sobre duas coisas e depois fazer uma demonstração ao vivo. A primeira é o Weave, da Weights & Biases, para agents, que, na minha opinião, é a melhor plataforma de observabilidade tanto para rastreamentos de agents em produção quanto offline. Uso principalmente no lado offline, onde crio ambientes de simulação, executo o agent Arya neles e

02:23 depois acompanho tudo no Weave; toda a minha equipe também faz isso. Assim, consigo ver o desempenho de todos nós nas métricas offline. A outra metade da equipe trabalha no lado de produção, fazendo deploy do agent e registrando as mesmas coisas exatamente no mesmo formato, para que eu possa importar esses rastreamentos de produção para os nossos ambientes e, então, otimizar o desempenho ou resolver nossos erros. É um ciclo virtuoso bem legal. E, obviamente, a outra coisa sobre a qual vim falar é o próprio Arya, o agent da Weights & Biases, que é basicamente a ferramenta que agora usamos para desenvolver a si mesma, porque já é sofisticada o bastante para fazer essa otimização iterativa offline por conta própria. Vou começar com uma demonstração ao vivo bem rápida e depois

02:55 vamos conversar sobre alguns outros slides e sobre como criamos o framework de avaliação offline. Se vocês entrarem na plataforma da Weights & Biases, este é um projeto de demonstração que chamei de “Arya pesquisa sobre o Arya”. Vou conversar com o Arya e pedir que faça pesquisa automática sobre si mesmo. Este é um prompt relativamente longo que pedi para ele gerar, na verdade, em uma destas outras sessões. Mas, se olharmos, ele vai pegar minha base de código, registrada como um artefato da Weights & Biases, que podemos ver aqui. Vai iniciar execuções de treinamento com essa base de código, que é o nosso framework de avaliação offline. Vai

03:27 analisar os rastreamentos de produção que temos, adicionar novas tarefas para otimizar o desempenho e fazer coisas desse tipo. Então, isso vai levar um tempinho. As avaliações demoram um pouco para rodar. Vamos ver o Arya tentar escrever uma nova variante de si mesmo. O outro lado dessa equação é a produção. Esta é uma visualização anonimizada de rastreamentos internos de clientes ou de rastreamentos internos do Arya. Vamos ver bem rápido o Arya aparecer aqui com a conversa exata que estamos executando, bem aqui. Mas vou usar este rastreamento como

03:58 uma oportunidade para pegar um desses rastreamentos de produção registrados no Weave e incluí-lo no meu framework de avaliação offline, para poder otimizar o desempenho com ele. Vou fazer isso ao vivo. Vamos pedir uma tarefa relativamente simples. Vai ser um pouco interessante porque é ligeiramente autorreferencial, mas vou abrir uma nova aba do Arya e pedir: “Pegue este rastreamento, registre-o nas nossas evals offline, não acho que a ortografia importe muito, e depois execute nele o agent candidato e o de produção”. Vamos deixar isso rodando também

04:31 e veremos essas avaliações serem registradas no Weave enquanto rodam. Essa é, basicamente, a versão resumida do que faço quase todos os dias: olho os rastreamentos de produção na nossa plataforma Weave da Weights & Biases, executo avaliações na nossa base de código, que é nosso ambiente isolado para avaliações offline de clientes, depois faço deploy de novas versões do agent e trabalho com a equipe para isso. Se olharmos nosso projeto de produção, veremos vários rastreamentos das últimas sete semanas, das nossas tarefas noturnas de CI, nas quais avaliamos o agent no formato de produção e outras variantes candidatas que criamos. Assim, podemos ver nosso desempenho relativo ao longo do tempo. Por exemplo,

05:02 por um tempo, a CI ficou quebrada e, ontem à noite, o Arya teve que consertar a si mesmo. Mas estamos chegando a cerca de 66% de desempenho em algumas tarefas e assim por diante. Temos várias tarefas que treinamos o agent para realizar. Agora vou passar para uma versão mais concreta da apresentação e aprofundar um pouco a teoria por trás da criação de um ambiente de simulação para otimização iterativa offline e, basicamente, para criar um agent de software. Tradicionalmente, talvez você espere ter bastante robustez se estiver fazendo aprendizado por reforço, mas hoje em dia eu trabalho principalmente com engenharia de prompts, porque os modelos sofisticados são relativamente bons em realizar tarefas na Weights &

05:32 Biases. Por isso, estamos trabalhando mais na criação de skills para o agent de software do que em aprendizado por reforço. Mas acho que aplicar a mesma metodologia à forma como você cria o agent — e garantir a mesma robustez na simulação dos ambientes — é muito útil para o nosso trabalho. Comparamos versões idênticas bit a bit do agent no ambiente de produção e no ambiente simulado. Há bastante texto nesses slides, que eu e o Claude meio que despejamos ali. Mas vamos ficar só com os gráficos. Acho que o interessante aqui é que, tanto com o framework de registro do Weave quanto com a forma como projetamos o sistema, nosso código de pesquisa e de produção é exatamente o mesmo. Na verdade, há uma sincronização de cerca de quatro horas

06:05 trabalho que acontece entre a produção e nosso ambiente de pesquisa, para que não haja nenhuma divergência quando, sabe, os pesquisadores criam novas variantes do agent, novas skills etc. e fazem sua otimização por tentativa e erro. Assim, temos esse pequeno ciclo bem fechado, que basicamente espelha um ao outro em dois lados da stack: nossa camada de deploy e nossa camada de benchmark offline. E então, internamente, como equipe, disponibilizamos vários comandos para executar evals e gerar trajetórias de pontuação. É disso que estávamos falando com esse grande projeto, no qual temos vários exemplos de trajetórias. Se eu clicar em uma delas, podemos ver, quando carregar, nossas pontuações relativas em várias métricas diferentes. Mas, essencialmente, o que obtemos

06:39 são esses rastros superrobustos do agent sendo executado ao longo do tempo. Há muito sinal que podemos extrair deles. Acho que a tese por trás disso é gerar um monte de rastros e depois decidir o que fazer com esse monte de rastros enquanto tentamos descobrir como o agent se comporta. Você mede propriedades emergentes e, então, tenta direcionar o agent para direções específicas. Isso acontece de duas maneiras: eu analiso as tarefas manualmente ou, como faríamos naquele primeiro exemplo, peço a Arya que revise a execução que gerou para si mesma, ou revise alguma outra execução, decida o que deu errado ou certo e tente reforçar esse comportamento por meio de

07:11 prompts ou qualquer outra coisa. E então, sabe, o método propriamente dito por trás do agent é relativamente simples. Queremos testar vários modelos diferentes, tanto os modelos oferecidos pela inferência da CoreWeave quanto os oferecidos pelos provedores de modelos de fundação, entre outros. Então, definimos uma stack de software relativamente agnóstica para a maneira como lidamos com a compactação, preparamos o contexto, montamos as cargas úteis da interface do usuário etc. E, de novo, a ideia por trás disso é tentar tornar muito, muito simples criar muitas mutações exatamente da mesma configuração. Basicamente, você quer

07:42 definir diferentes configurações do agent em YAML, para obter várias versões paralelas e depois testar todas elas e ver o que acontece, porque, no fim das contas, você pode ter ideias de como melhorar o problema. Mas, se adotarmos um velho ditado do treinamento por aprendizado por reforço, ou simplesmente do treinamento de modelos, é melhor executar mais experimentos do que menos. Essa também é a tese por trás do próprio agent harness. E então falamos da stack de sandbox por trás do agent. Acho que houve muitas menções ao modo de código nesta conferência e a outras coisas do tipo. Uma coisa que realmente queremos ver acontecer, porque queremos criar

08:13 o melhor produto para nossos clientes, é simplesmente ter um ambiente de sandbox em que eles possam fazer tudo o que quiserem. Por exemplo, antes de ontem, eu não tinha certeza absoluta de que Arya conseguiria executar várias instâncias de si mesma em paralelo. Então, enquanto preparava esta apresentação, pedi a ela que criasse o ambiente de sandbox para executar várias instâncias paralelas do próprio ciclo de pesquisa. Certo? Ter esse ambiente sem restrições é muito útil para fazer o agent realizar coisas emergentes.

08:44 E então, sabe, não tenho muita certeza do que significa “seis frases por registro”, mas acho que, do ponto de vista teórico, queremos criar um bom padrão para gerar esses ambientes de simulação. Temos um DAG relativamente agnóstico, que talvez vocês conheçam do contexto tradicional de aprendizado de máquina: pegamos uma configuração, que são esses arquivos YAML, e a hidratamos. Ou seja, carregamos os dados em tempo real de que precisamos. Configuramos um ambiente — e os ambientes da Weights & Biases são relativamente caros, porque podemos querer testar com muitos dados de produção ou fazer outras coisas do tipo. São registros completos de treinamento de aprendizado de máquina.

09:14 Talvez tenhamos que simular execuções em GPU se estivermos fazendo pesquisa automática etc. Esse processo é relativamente intensivo, então talvez seja necessário paralelizá-lo. Depois, hidratamos de novo, porque muitas vezes há configurações de execução que não podem ser codificadas em uma especificação YAML; então aplicamos essas alterações aos dados da configuração. Em seguida, executamos o agent, e executar o agent é trivial. Como mencionei no começo, executamos a versão idêntica bit a bit à que está em produção e, depois, atribuímos uma pontuação. É na pontuação que passo boa parte do meu tempo: basicamente, tentando pensar na robustez da maneira como medimos os resultados.

09:44 Imagino que a maioria das pessoas aqui seja bem boa em pensar nesse tipo de coisa. Acho que realmente vale a pena dedicar tempo, depois de definir uma configuração para executar avaliações, a pensar na robustez das nossas avaliações. Uma mensagem no Slack que recebi hoje de um colega de equipe — provavelmente não posso mostrá-la na tela ao vivo — me deixou muito feliz. Ele passou praticamente o dia de ontem pensando na qualidade das nossas avaliações e na divergência entre elas e a produção. Acho muito útil esse tipo de modelo mental: por que as coisas estão funcionando bem? Por que não estão funcionando bem? Quais lacunas vemos entre esses dois padrões? No nosso caso, a Arya, da Weights & Biases, pontua

10:15 a si mesma de duas maneiras: de forma normativa, que basicamente nos diz se concluímos ou não uma tarefa, e de forma relativística, em que podemos definir estilos com base em uma variante que faz perguntas ao usuário e outra que não faz, e ver qual se comporta melhor por meio de uma pontuação relativa. É uma formulação bem tradicional do ponto de vista do aprendizado por reforço. E, claro, se você estiver executando tudo isso em paralelo, precisa encerrar as execuções para poder começar de novo, sem atrapalhar o trabalho dos colegas de equipe etc. Vamos ver o que acontece neste projeto, porque vários colegas meus estão executando evals agora. Então, veremos como Arya se sai.

10:47 E então, de maneira mais tradicional, acho que as tarefas de avaliação são apenas especificações YAML que definimos como uma condição inicial de um ambiente, com várias configurações de usuário, e também uma condição final à qual queremos chegar. No nosso caso, as tarefas são fluxos de usuários. Então, nós os simulamos de três maneiras. Fazemos algo simples, só texto, como: “Ei, aqui está uma instrução para Arya”. Talvez a tarefa que ela gera neste chat aqui, em que registra um rastro específico da produção em nossa framework local, seja na verdade apenas uma pergunta simples que fiz a ela, como

11:19 a pergunta sobre Arya fazer pesquisa automática por conta própria. Podemos simplesmente pedir que ela continue enquanto faz isso, e essa tarefa consiste em uma única pergunta para ela. Também existem outras variantes de tarefas, em que simulamos um modelo de linguagem com a persona de um usuário e pedimos: “Ei, finja ser este usuário e faça certas perguntas em uma ordem específica”, para que possamos simular ambientes com várias interações e conversas com nosso agent. Depois, é só executar várias dessas tarefas. Temos 886 tarefas. Nós as categorizamos por nível e as disponibilizamos para nossa equipe de produto, para que ela possa decidir se as tarefas são

11:51 boas o bastante ou se refletem coisas que consideramos importantes em nossos benchmarks etc. E então simplesmente as executamos várias vezes. Sim. E, no fim das contas, a trajetória é a parte principal e os dados que ficam por trás de tudo o que faço. Então, analiso os rastros de produção que aparecem no nosso tráfego e os rastros offline que temos. Tento explorar ao máximo os padrões de comportamento de ambos. Criamos nossas próprias ferramentas para entender os rastros. Temos, por exemplo, este projeto de rastreamento de comportamento, que executamos tanto em produção quanto offline. E é esse o ciclo virtuoso de avaliação. Então, fundamentalmente, toda produção

12:23 perder ou deixar passar qualquer benefício da produção também, porque acho útil subir a ladeira em uma direção positiva. Isso se torna uma tarefa para nosso framework de agent. E então usamos isso para, de certa forma, definir o agent e melhorá-lo. E estas são, vocês sabem, nossas pontuações reais, diretamente do Weave. Temos várias categorias diferentes nas quais nos avaliamos. Acho que o agent é muito bom em orientar você conceitualmente. Queremos torná-lo melhor em fazer algumas análises de erros em projetos. Tentamos tornar essas tarefas o mais difíceis possível para o agent, a fim de realmente testar os limites do desempenho dessa ferramenta. Agora vou voltar para Arya. Restam mais ou menos cinco minutos…

12:53 …para uma demonstração do que ela está realmente fazendo. Neste momento, ela vai executar vários trechos de código enquanto tenta extrair esse trace de produção e registrá-lo no framework. Se eu abrir esta demonstração ao vivo que acabei de iniciar com aquele prompt bem longo, Arya vai me dizer quais execuções de pesquisa realizou. Podemos clicar em alguns desses links. Pedi que ela escrevesse um relatório usando os relatórios do Weights & Biases sobre a execução que acabou de fazer. Se avançarmos por aqui, veremos que este é o trace de produção mais recente que ela acabou de registrar. Ela escreveu uma nova tarefa para si mesma, executou-a e depois a avaliou. Então, esta é a variante de produção sendo comparada com nosso benchmark em uma tarefa específica. Se nós…

13:24 …olharmos o relatório que ela gerou, esta é a demonstração que pedi para ela fazer. Ela executou um trace real do agent do W&B e o transformou em uma tarefa de regressão do WBF. O WBAF é a fábrica que estou construindo, a fábrica de agents do Weights & Biases. Esse é o princípio por trás da nossa avaliação offline. Ela identificou que o problema era não estarmos chamando corretamente o weave.log, uma das chamadas do nosso SDK, no sandbox. Ela reproduz o trace de origem, que podemos abrir aqui, e depois executa várias variantes do agent para ver como ele pode se aprimorar. Então, ela adicionou um objetivo de escalada, que basicamente dizia o que fazer para corrigir o problema. Executou o…

13:56 …trace, e então podemos ver se ela nos dá uma pequena explicação do que aconteceu no final. Como a variante de produção se saiu em comparação com a variante candidata? E, sabe, é nisso que passo meu tempo agora. Acho que esse ciclo de aprimoramento é extremamente convincente para mim: em vez de voltar ao meu Claude Code, escrever benchmarks offline e tentar pensar no que quero que o agent faça, vou simplesmente trabalhar nesta plataforma e alternar entre meu projeto de tracing de produção, onde vejo os traces chegando ao longo do tempo, enquanto Arya, sabe, está se construindo, e depois voltar para…

14:27 …meu projeto de avaliação offline para ver o que minha equipe está fazendo, o que estou fazendo e que mudanças quero implementar. Que mudança fizemos na skill de produção ou na variante do agent, e assim por diante. E, sabe, acompanhar a implementação disso. Acho que um grande desafio é que é muito fácil colocar algumas dessas tarefas em modo automático, quando você só quer ver o agent fazer tudo. Não escrevo uma linha de código há talvez oito meses, porque simplesmente peço ao Claude que escreva todo o meu código. É um padrão muito bom, mas isso não dispensa você de pensar em…

14:57 …como queremos fazer melhorias. Acho muito valioso usar essas ferramentas para aprimorarem a si mesmas, porque assim você pode passar mais tempo nessa zona cinzenta, tentando pensar de fato em como melhorar o sistema, certo? Então, se você está construindo um agent, recomendo que use o Weights & Biases para acompanhar esse agent e assim por diante. Também temos uma plataforma excelente de acompanhamento de modelos. Algumas das outras demonstrações que mostramos aqui incluem Arya treinando modelos de machine learning em H200, executando na infraestrutura da CoreWeave, e fazendo pesquisa automática para o nano chat do Karpathy, entre outros projetos em escala de produção. Mas o que me empolga neste caso é não precisar…

15:28 …sair desta plataforma para fazer meu trabalho agora, certo? Tenho observabilidade completa do ponto de vista da produção. Tenho observabilidade completa do ponto de vista offline. E, se olharmos o que Arya está dizendo, ela está executando muitas avaliações em meu nome para se aprimorar. Esse modo automático que acabei de mencionar é muito empolgante, porque agora posso passar todo o meu tempo pensando em como fazer este sistema se reforçar melhor. Os pequenos limites bem definidos que posso estabelecer para torná-lo uma ferramenta mais útil para todos vocês e, consequentemente, para mim. Mas, enfim, essa foi uma demonstração rápida. Podemos olhar o trace da chamada de produção que temos aqui…

15:59 …do Arya. Esta é a avaliação que ela acabou de executar. Se olharmos o trace em si, veremos que AR fez bastante coisa. Ela executou esta coluna de previsão e pontuação. Houve várias chamadas de ferramentas. E, se voltarmos ao chat, veremos a variante que ela executou. Parece que a variante candidata tinha apenas um pequeno prompt que inserimos no system prompt ou em uma das skills para resolver exatamente aquele erro do SDK e mitigá-lo. Essa reprodução da produção para a simulação e, em seguida, para o agent, que então define o padrão de melhoria, é o que eu realmente gostaria que todos levassem desta apresentação.

16:30 Essa é a Arya da CoreWeave. Boas-vindas ao Weights & Biases. Espero que tenha sido uma palestra interessante sobre como decidimos criar nossas métricas de avaliação offline, como coletamos dados da produção e sobre o ciclo de aprimoramento para criar esses agents, além das coisas em que penso no dia a dia. E, sim, vamos começar. Muito obrigado a todos.

17:04 [música]

Transcrição original

[00:16] Okay. Hello. Thank you for showing up. Uh my name is Zuben Isola. Uh I work at Weights and Biases. I’m building the Arya agent which is something that we released to general availability on Monday. You might have seen Tim’s talk uh one of the pe my peers at Weights and Biases who I work with uh on the main stage yesterday. So I’m going to give you a little bit of a deep dive into how we evaluate and build the Arya agent uh and in particular uh the evaluation framework that we use and how we use Arya to sort of self-reinforce itself in the loop of doing research for itself uh and talk about some weights and biases

[00:49] things. So yeah, this is a rip from some of the slides that I presented at Nurups, but uh I think there’s some interesting things about like using uh agentic harnesses. I I imagine most people in the audience or at this conference are all excited to build agent harnesses or maybe use cloud code with skills in a variety of different packages, but there’s, you know, pretty strong differences in the way that you package these AI agents if you use them with different tool calls, etc. on a variety of different benchmarks. And so inspired by that, we’re doing some work at Weights and Biases to build our own agent harness to do research for you in the weights and biases platform. Um, you

[01:19] know, and then there’s probably some other things that I don’t need to convince people of as to like why we want software agents and why a software harness as opposed to like just letting the, you know, LM run free and call tools or whatever else. Uh, but that’s not for here. Uh, but one big problem presents itself, which is basically the thing that I go to bed thinking about every day, which is, you know, benchmarks, evaluations, the agents, and how you configure them are all covariant. And so like if you’re trying to apply principled evaluations to any sort of system that dynamically changes, you need to have good measurement to see how the system actually performs. And

[01:51] you really want to see how the system performs in both your production environment and your offline environment. Uh you know if you’re RLP build from a long time ago, you might think about like the sim tore gap uh which is like basically how do we translate simulation environments into the real world environments etc. Uh and so there’s sort of two things that I’ll talk about uh and then give a live demo of which is weights and biases weave for agents which is basically in my opinion at least the best observability platform for both production and offline tracing of agents. So I use it predominantly from the offline side where I build simulation environments run the Arya

[02:23] agent over them and then track them in weave and my entire team does that as well. So I can see all of our performance in offline metrics. And then the other half of my team works on the production side of things, deploying the agent, logging the same things in the exact same format so that I can rip those production traces into our environments and then hill climb on them or resolve our errors. And it’s a pretty nice flywheel. And then obviously the other thing that I’m here to talk about is Arya, the weights and devices agent itself, which is basically the thing that we use to now build itself because it’s sophisticated enough that it can actually do that offline hill climbing uh by itself. So I’m going to just jump into a super quick live demo and then

[02:55] we’ll talk through some other slides uh about how we built the offline evaluation framework. So if you hop into the weights and biases platform, this is a demo project that I called Arya researches Arya here. Uh and I’m just going to chat to Arya and ask it to basically do auto research for itself. And so this is a relatively long prompt that I had it generate in actually one of these other sessions. Um but if we look at it, what it’s going to do is it’s going to take my codebase that is logged as a weights and biases artifact uh which we can see over here. It’s going to launch training jobs uh against this codebase which is our offline evaluation framework. It’s going to

[03:27] review production traces that we have, add new tasks to hill climb against uh and do stuff like that. And so, you know, this thing’s going to cook for a little bit. The evaluations take a little bit of time to run. And so, we’ll see Arya uh basically try to write a new variant for itself. The other side of this equation, right, is the production side of things. And so, this is a sanitized view of internal customer traces or internal traces on Arya. So we’ll actually see very quickly uh that Arya will actually pop up here the exact conversation that we’re running um right here. But in this trace I’m going to use

[03:58] this as an opportunity to take one of these production traces that are logged in weave and put them into my offline evaluation framework so that I can hill climb on them. And so I’m just going to do that live. We’ll ask you know for a relatively simple task. Um this is going to be a little interesting because it’s going to be slightly self-referential but I’ll go here. I’ll pop up in a new Arya tab and I’ll just ask it hey take this trace log it into our offline evals I don’t think spelling matters too much and then run the candidate and production agent on it and we’ll have it cook for that as well

[04:31] and we’ll see those evaluations get logged into weave as they’re running um so that’s basically the tight version of what I do basically every day which is look at production traces in our weights and biases weave platform run evaluations in our codebase which is our offline client evaluation sandbox uh and then deploy new versions of the agent uh and work with my team to do that. And if we look at our production project, this is, you know, a bunch of traces that we have over the last seven weeks of our nightly uh like CI jobs that run where we evaluate the agent in its production format and other candidate variants that we cut. And so we can see our relative performance over time. Uh like you know,

[05:02] for a while the CI broke, we had Arya have to fix itself last night, but you know, we’re getting about like 66% performance on some of the tasks, etc. And so we have a variety of tasks um that we train the agent to do. And so now I’m just going to jump into a material version of the presentation to go a little bit deeper into the theory behind building a simulation environment for offline hill climbing for basically building a software agent where traditionally you might expect that you are really robust if you’re doing reinforcement learning but I mostly prompt engineer these days because the sophisticated models are relatively good at performing tasks at weights and

[05:32] biases and so we’re really working on building skills for the software agent more than doing reinforcement learning. But I think applying the same methodology to how you build the agent. So the same robustness of how you simulate environments uh is really helpful for our work. So we benchmark a bite-wise identical version of the agent in our production environment and our simulated environment. There’s a lot of text on these slides that I and Claude sort of slop out. Uh but you know we’ll just go for the graphics. Um so I think the exciting part here is that both using the logging framework from weave as well as just in the way that we’ve designed the system our research and production code are exactly the same. And in fact, there’s like a 4-hour sync

[06:05] job that happens between production to our research environment so that we don’t get any drift when you, you know, researchers are cutting new variants of the agent, new skills, etc., and doing their hill climbing. And so, we have this nice little tight loop that basically mirror each other on two sides of the stack from our deployment layer and our offline benchmarking layer. Uh, and then, you know, we expose internally as a team a bunch of run eval commands to generate score trajectories. And so that’s what we were talking about with this like large project where we have a bunch of trajectory examples where if I click into one of these, you know, we can see like our relative scores of a variety of different metrics when it loads. Um, but essentially what we get

[06:39] is these super robust traces of the agent rolling out over time. And there’s a lot of signal to reap from this. And I think the thesis behind this is generate a ton of traces and then decide what you’re going to do with said ton of traces as you try to figure out how the agent performs. you’re measuring emergent properties and then trying to align the agent in particular directions. And so the two ways that that happens is I look manually at the tasks or like we would do in that first example, I would ask Arya to review the roll out that it generated for itself or review some other rollout and decide what went wrong or what went well and try to reinforce that behavior through

[07:11] prompting or anything else. Uh and then you know the actual method behind the agent is relatively simple. We want to test on a variety of the different models both models offered through corewave inference models offered through you know the foundation model players etc. And so we define you know a relatively agnostic software stack for how we treat compaction and how we prepare context and how we assemble UI payloads etc. And the again mental pattern behind this is to really try to make it very very simple to have lots of mutations of the exact same configuration. You want to basically

[07:42] YAML define different configurations of the agent to sort of get multiple parallel uh variants and then test them all and see what happens because ultimately you can have insight into how to make the problem better. But if we take an adage from old reinforcement learning training or just simple model training, it’s just better to run more experiments than fewer. And so that’s the thesis behind the agent harness itself too. And so then you know we talk about like the sandbox stack behind the agent. And I think that you know there’s a lot of mentions of code mode here at this conference and other things like that. And one thing that we really want to see happen because we want to build

[08:13] the best product for our customers is to just have a sandbox environment that they can do anything they wanted. So for example prior to yesterday I wasn’t entirely certain that Arya was going to be able to do a bunch of parallel executions of itself. And so I asked it both while I was writing this presentation and preparing for this to just create the sandbox environment uh for itself to run a bunch of parallel executions of its own research loop. Right. Uh, and so like having that unconstrained environment is really useful for getting the agent to do emergent things.

[08:44] And so, you know, I I’m not really sure what the six phrases per record uh means, but I think from a theory standpoint, we want to build then a good pattern for generating these simulation environments. And so we have a relatively agnostic DAG that you might think about in a traditional machine learning context, which is like we take a configuration, which are these YAML files. We hydrate them. So we load the live data that we need to. We set up an environment and the environments and weights and biases are relatively expensive because we have lots of production data that we might want to test against or other things like that. These are full machine learning training

[09:14] logs. We might have to simulate uh GPU executions if you’re doing auto research etc. That’s a relatively intensive process and so you might want to parallelize that. Then you would rehydrate because oftentimes there’s runtime configurations that you can’t encode in a YAML specification and so you hot patch that data back into the config config. Uh and then you run the agent and running the agent is trivial. You run it, as I mentioned at the beginning, in the bite-wise identical version that you have in production, and then you score it. And scoring is where I spend a lot of my time, which is basically trying to think about the robustness of how you measure results.

[09:44] Uh, and I imagine most people here are pretty good at thinking about things like that. And I think it’s really worth spending the time once you have a configuration of how to run evaluations, thinking about the robustness of our emails. uh a Slack message that I probably can’t show live on the screen that I got from one of my teammates today made me very happy where he basically just spent all of yesterday thinking about the health of our evaluations and the drift between our evaluations and production. Uh and I think that kind of mental model of like you know why are things working well why are things not working well? What are the gaps that we see in these two patterns is really useful. Um in our case weights and biases Arya scores

[10:15] itself in two patterns which is normatively which gives us basically did we pass a task or not and then relativistically where we can set styles based on one variant where it asks questions to the user and one variant where it doesn’t ask questions to the user and we can sort of see which one behaves better uh with a relative scoring. So a pretty traditional formulation from a reinforcement learning standpoint. And then of course if you’re running this in parallel you got to tear it down because you want to start it again and you don’t want to clobber your teammates’s work etc. Uh and so we’ll see what happens in this project because a bunch of my teammates are running eval right now and so we’ll see how Arya performs.

[10:47] Uh and then you know more traditionally on tasks I think the eval tasks are just YAML specifications that we define as a starting condition of an environment with a bunch of user configurations as well as then an ending condition that we sort of want to get to. Uh in our case tasks are flows from users. So we simulate them in three ways. Uh we do just simple text which is like hey here’s an instruction to Arya. You might imagine that the task that it generates in this chat over here um where it’s logging a specific trace from production uh into our local framework actually looks like you know just a simple

[11:19] question that I asked it basically which was that question of Arya doing auto research itself um we can just ask it to continue um as it does that and that task is just a single question to it there’s other variants of the tasks that exist as well where we simulate a language model that has a persona from a user and we ask it, hey, pretend to be this user, ask certain questions in a particular order so that we can simulate multi-turn environments and interactions with our agent. Uh, and then you just run a bunch of these. So, we have 886 tasks. We categorize them by levels. We expose them to our product team so that they can decide whether or not the tasks are

[11:51] good enough or they reflect things that we care about from our benchmarks, etc. And then we just run them a bunch of times. Yeah. And then, you know, the ultimate thing here is that the trajectory is like the meat and the data that I live behind. And so I look at our production traces that exist in our traffic and our offline traces that exist. And I really try to exploit the behavior patterns from both of those. And so we build tooling ourselves to understand our traces. Uh we have like this behavior trace project etc that we run in both prod and offline. And yeah that’s the eval flywheel. So you know fundamentally every production

[12:23] miss or every production goodness as well because I think it’s useful to hill climb in a positive direction uh becomes a task for our agent framework. And so we use that to sort of define the agent and make it better. And these are, you know, our real scores straight from weave. So we have a bunch of different categories that we measure ourselves on. I think the agent is really good at conceptually guiding you. We want to make it better at doing some error analysis for projects. You know, we try to make these as difficult as possible for the agent to really test the metal of how this thing performs. And so I’ll hop back to Arya now. There’s sort of five minutes left um

[12:53] with sort of a demo of what it’s actually doing. So right now it’s going to run a bunch of code as it’s trying to rip this production trace and log it into the framework. If I hop into this uh live demo that I just triggered with that nice long prompt, you know, Arya is going to tell me the research runs that it did. So we can click through some of these links. Uh I asked it to write a report using weights and biases reports from the uh run that it just had. If we scrub this, we can see that this is the most recent production trace that it just logged. It wrote itself a new task, ran it, and then scored it. And so this is like the production variant getting benchmarked on our specific task. If we

[13:24] look at the report that it generated, this is the demo that I asked it to do. Um, so you know, it ran a real womb agent trace, turned it into a WBF regression task. WBAF is the factory that I build, which is the weights and biases agent factory. That’s the principle behind our offline benchmarking. It identified that the problem was that we weren’t calling weave.log, one of our SDK calls properly in the sandbox. It replicates the source trace, which we can click into here, uh, and then runs a bunch of variants of the agent to see how it makes itself better. And so, you know, it added a hill climb target uh which was basically like here’s what to do to fix it. Ran the

[13:56] trace and then we can see if it gives us a little explanation of exactly what happened at the end. Uh how did the prod versus candidate variant perform and you know this is now what I live in. And so I think the flywheel here is exceptionally compelling for me where instead of going back to my cloud code and writing offline benchmarks and trying to think about what I want the agent to do, I’m just going to live in this platform instead and hop between my production tracing project where I’m looking at traces roll in as they come through over time where AR is, you know, building itself and then hop back into

[14:27] my offline evaluation project to sort of see what my team is doing, what I’m doing, and what changes I want to make. what change did we make to the prod skill or to the agent variant etc. And you know to sort of like watch this thing roll out. I think a big challenge that we have is it’s really easy to go like auto mode for some of these tasks where you want to just see the agent do everything. And I haven’t written a line of code in maybe eight months because I just tell Claude to write all my code for me. And that’s a really nice pattern, but it doesn’t absolve yourself of the thought behind

[14:57] how we want to make improvements. And I think using these tools to improve themselves is very valuable because you get to spend more of your time in the gray of actually trying to think how we make this system better, right? And so if you’re building an agent, I implore you to use weights and biases to both track that agent etc. Uh we have a really excellent model tracking platform as well. So some of the other demos that we’ve shown here are Arya training machine learning models on H200’s running on core infrastructure and doing auto research for Karpathy’s nano chat etc or full-scale production projects. But I think the exciting thing in this case for me is that I don’t need to

[15:28] leave this platform in order to do my job now right. I have full observability from a production standpoint. I have full observability from an offline standpoint. And if we look at, you know, the things that Arya is saying, it’s running lots of evaluations on my behalf to improve itself. And that auto mode that I just mentioned is really exciting because now I get to spend all of my time thinking about how I can make this system reinforce itself better. The tight little guard rails that I can put around it to make it a more useful tool for all of you and then inherently for me. Um, but yeah, that’s a that’s a quick demo. We can we can look at the production call trace that we have here

[15:59] from Arya. This is the evaluation that it just ran. So if we look into like the actual trace, we’ll see that, you know, AR did a bunch of work. It ran this predict and score column. We have a bunch of tool calls that ran. Uh and you know, if we hop back into the chat, we’ll see the actual variant that it ran. Um it looks like the candidate variant just had a tight little prompt that we injected into the system prompt or in one of the skills to sort of solve that exact SDK error uh and mitigate it. And that kind of replication from production to simulation to agent then defining the improvement pattern is the thing that I really would like to leave everybody with.

[16:30] So that’s coreweave Arya. Uh welcome to weights and biases. I hope that was an interesting talk in sort of how we decide to build uh our offline evaluation metrics, how we reap data from production and the flywheel of trying to build these agents and the things that I think about on a day-to-day basis. Uh and yeah, let’s get started. Thank you all so much.

[17:04] >> [music]