Agentes que se aprimoram enquanto você dorme — Fuad Ali, Arize AI

Ver no idioma original →

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: Agents That Self Improve While You Sleep - Fuad Ali, Arize AI · Canal: AI Engineer · 52:57 · Assistir no YouTube

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

Resumo

Fuad Ali apresenta um ciclo de autoaperfeiçoamento para agentes que combina traces, análise automatizada de falhas, data sets, evals e experimentos. No exemplo Wonder Toys, o agente Signal identifica um erro de filtros, propõe uma correção e testa se ela resolve o problema sem causar regressões. O palestrante destaca que humanos continuam essenciais para revisar PRs, curar data sets e definir o que conta como um bom resultado. Também discute como equilibrar a cobertura das evals, seus custos e o nível de automação adequado.

Pontos-chave

• Traces ajudam a entender o comportamento dos agentes, mas a leitura manual não escala quando há muitos registros.
• O Signal analisa traces, agrupa problemas e pode investigar o código para propor correções.
• Registrar falhas em data sets cria casos de teste que evoluem com os problemas encontrados em produção.
• Evals podem verificar desde condições determinísticas até resultados qualitativos, com diferentes custos e níveis de complexidade.
• Experimentos reproduzem falhas e avaliam se uma correção funciona sem prejudicar outros comportamentos.
• Pessoas agregam valor ao validar PRs, selecionar casos relevantes para data sets e definir critérios de avaliação.
• Evals em produção e no CI/CD devem ser escolhidas considerando cobertura, custo e impacto das falhas.
• A automação pode direcionar casos de baixa confiança para revisão humana.
• O custo do ciclo depende, entre outros fatores, das skills conectadas, do contexto fornecido e da frequência das evals.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação do ciclo de autoaperfeiçoamento	Fuad Ali introduz o problema de analisar falhas em agentes não determinísticos e apresenta o objetivo do workshop.
04:41	O exemplo Wonder Toys e os estágios de maturidade	O palestrante apresenta o agente de compras e descreve a progressão de traces e evals até testes de regressão e validação de correções.
08:20	Do trace à correção automatizada	O fluxo conecta traces, identificação de falhas, data sets, evals, correções, experimentos e revisão humana.
11:58	Signal analisa traces e encontra uma falha	O Signal monitora traces e identifica tentativas redundantes de busca causadas por uma incompatibilidade na formatação de categorias.
17:45	Agentes gerenciados e automações	Ali mostra como configurar agentes para investigar traces por agenda ou alerta e conectá-los a diferentes skills e fontes de dados.
20:20	Data sets e tipos de eval	O palestrante explica como transformar falhas em casos de teste e compara verificações de código, LLM as a judge, agent as a judge e decision models.
23:26	Onde a revisão humana agrega valor	Humanos podem validar PRs, selecionar falhas para data sets e orientar o desenho das evals com seus critérios de qualidade.
27:04	Experimentos para validar correções	Experimentos reproduzem casos de falha, verificam se a correção funciona e ajudam a detectar regressões antes da implantação.
31:14	Manutenção do ciclo e revisão de resultados	Evals, data sets e investigações continuam sendo atualizados, enquanto pessoas confirmam se os problemas e correções são válidos.
34:21	Visão futura e integração ao fluxo de trabalho	Ali discute automação de ponta a ponta, desafios de testar agentes com dependências e integração do Signal com ferramentas de trabalho.
39:02	Princípios do ciclo e desenho de evals	O palestrante reforça a importância de automatizar a análise em escala sem remover pontos de revisão humana e explica como avaliar resultados qualitativos.
45:45	Avaliar o Signal e reconhecer limites	A conversa aborda a avaliação recursiva de agentes, os limites de métricas indiretas e o potencial de decision models em fluxos de baixa latência.
49:50	Skills, custos e encerramento	Ali explica como conectar fontes como DataDog, controlar custos e ajustar contexto e frequência das evals antes de encerrar o workshop.

Citações

O fluxo geralmente é: trace, signal, data set, eval, correção e experimento. — 07:49

Os pontos em que uma pessoa agrega mais valor são validar a correção e revisar o PR. — 23:26

Só porque é possível automatizar algo, não significa que isso deva ser automatizado. — 39:02

Grande parte disso se resume ao ROI. — 44:12

Sem ground truth, você está apenas se entusiasmando com a saída do agente e fingindo que está aumentando o valor para os acionistas. — 47:47

Conceitos e entidades

• Arize AI (empresa): Empresa que oferece ferramentas para observar, avaliar e aprimorar agentes.
• Fouad Ali (pessoa): Gerente de produto na Arize que apresenta o workshop sobre ciclos de autoaperfeiçoamento para agentes.
• Signal (ferramenta): Agente da Arize que analisa traces, agrupa falhas e pode propor correções e evals.
• Arize AX (ferramenta): Plataforma e CLI citadas para instrumentar agentes, visualizar traces e executar fluxos de avaliação.
• Alex (modelo): Agente interno da Arize mencionado como ferramenta para criar evals a partir de evidências.
• Wonder Toys (modelo): Agente de compras fictício usado no workshop para demonstrar o ciclo de melhoria.
• traces (conceito): Registros detalhados das etapas, chamadas de modelo e ferramentas usadas por um agente.
• evals (conceito): Avaliações que verificam se o comportamento ou os resultados de um agente atendem a critérios definidos.
• data sets (conceito): Conjuntos de exemplos e casos de falha usados para testar agentes e acompanhar regressões.
• Decision Models (modelo): Modelos apresentados como uma opção de menor custo para classificar ou pontuar resultados.
• Datadog (ferramenta): Sistema que pode ser conectado por skill para consultar métricas, logs e traces de APM.

Tradução completa (pt-BR)

00:01 [música] >> Bem, obrigado a todos por virem ao workshop. Agradeço muito a presença de vocês. Meu nome é Fouad Ali. Sou gerente de produto na Arize. A Arize ajuda vocês a criar o ciclo de autoaperfeiçoamento dos seus agents. Hoje vou explicar como esse ciclo funciona, como ele é construído, e vou apresentar um

00:31 pequeno exemplo de agent para mostrar como ele funciona. Temos uma hora para este workshop. Pensando nisso, sei que workshops podem ser corridos e que o Wi-Fi pode cair. Então, deixei tudo pronto na minha tela e vou mostrar o processo. Acompanhar é opcional. Recomendo muito que vocês façam isso. Eu, pessoalmente, aprendo bem melhor quando posso pôr as mãos no teclado. Mas, se estiverem com problemas, não se preocupem. Também temos a Lori aqui, que ficará feliz em ajudar a resolver qualquer problema. Tudo certo? Legal. Sou o Fouad, trabalho com produto na

01:02 Arize e trabalhamos com muitos agents. Imagino que todos vocês estejam bem familiarizados com o que são agents, como eles falham e como são não determinísticos. E, sabem, esse é um problema clássico de engenharia que voltou a mostrar sua cara feia, só que dez vezes pior com agents, por causa do indeterminismo, certo? Quando vocês têm agents que conseguem fazer muitas coisas e têm muitas maneiras diferentes de fazê-las, fica mais complicado entender os modos de falha. E, além disso, há o fato de que

01:34 existem milhares desses agents. Talvez eu tenha agents internos, agents de programação, agents de marketing e, obviamente, agents voltados para os clientes também. Tudo isso acrescenta muito ruído ao problema. Então, como começar a criar um ciclo em que esses agents usem o feedback que vocês fornecem como seres humanos, o feedback dos clientes e, obviamente, evidências concretas, como traces, para orientar como podem melhorar? E é sobre isso

02:05 que vou falar hoje. O Signals é uma versão pronta desse sistema, que vou mostrar bastante hoje. Temos uma plataforma de agents gerenciados que permite definir, nos próprios termos de vocês, o que eles fazem. Obviamente, conjuntos de dados, evals, experimentos e tudo isso também farão parte. É isso que estamos tentando resolver. E desculpem pelo meme. O senso de humor do Claude não é muito bom, mas acho que ele ilustra bem o caso de uso. No modelo anterior de engenharia de software, provavelmente o SRE estaria

02:38 na primeira imagem, certo? Uma situação clássica: chega uma notificação do PagerDuty às quatro da manhã. Seu agent quebrou algo em produção. Neste caso, estamos fazendo um pequeno assistente de compras, e o assistente diz: “Não vendemos nenhum jogo de tabuleiro para todos os seus clientes em produção”. Não é uma situação em que você queira estar. Já houve casos piores de uso de agents também. Não sei se vocês estão a par do que aconteceu no Canadá com uma concessionária, em que alguém conseguiu comprar

03:09 um, acho que era um Prius ou algo assim, por cinco dólares, por meio de um chatbot. Obviamente, eles não honraram a venda, mas agora isso é problema do departamento jurídico. E esses agents podem falhar de várias maneiras, por vários motivos. Por isso, é muito importante tentar passar para um mundo em que estamos na etapa seguinte, em que os agents aprendem a corrigir a si mesmos e incorporam esse ciclo de feedback. Também vou falar um pouco sobre onde os seres humanos ainda agregam valor nesse tipo de mundo. Então,

03:39 é disso que vocês vão precisar para acompanhar. Como eu disse, isso é opcional. Vou mostrar o fluxo para vocês. Temos uma hora. Podemos passar o tempo restante respondendo a perguntas. Vocês também podem usar parte do tempo para experimentar o ciclo. Se tiverem um tempinho, eu deixo isso na tela por uns 30 segundos a um minuto. Se puderem, criem uma conta totalmente gratuita no Arize X. Vocês vão precisar de um ID de espaço e de uma chave de API, que posso mostrar como obter. Também vão precisar de algum tipo de

04:09 chave de API de um provedor de LLM, desculpem, OpenAI ou Anthropic; ambas funcionam. Vão precisar do Node e do Python na máquina. Se não tiverem, não se preocupem, ainda assim vamos explicar tudo. O Chris, do Claude Code, também vai ajudar a configurar isso. Imagino que nenhum de vocês seja novato nessas ferramentas. E é bem simples. Este é o aplicativo que temos: uma experiência de compra de brinquedos por chat. Ele se chama Wonder Toys. É bem simples. Você pode perguntar no chat sobre diferentes

04:41 produtos disponíveis. Também pode conversar para comprar. Tudo isso está sendo executado localmente na minha máquina. Esse é o agent com que vamos trabalhar hoje. Vamos mostrar como instrumentá-lo e configurá-lo para criar esse ciclo de feedback. Vou fazer uma pausa rápida aqui. Vou dar 30 segundos para vocês tentarem fazer algumas dessas coisas; de novo, é opcional. Não quero, sabem, que todo o workshop fique parado por causa de chaves de API. Legal. Então, são basicamente três coisas: colocar o

05:13 repo para funcionar, executar o aplicativo e garantir que vocês tenham uma chave de API que realmente alimente o agent. Não uma chave de API de provedor, como OpenAI ou Anthropic. Esta parte aqui é sobre instalar as skills que ajudam seu coding agent a trabalhar com nossas ferramentas de uma maneira mais orientada. Node e Python servem apenas para executar o repo, e é só isso. Legal. Vou continuar para aproveitar o tempo. Uma pergunta para vocês:

05:45 dessas, sabem, seis… Contei certo? Cinco caixas. Cinco caixas. Em qual dessas caixas vocês diriam que sua equipe está? Normalmente, começa assim: “Certo, estamos rastreando o que nossos agents fazem. Então, sabemos quando falham, sabemos quais ferramentas chamam. Conseguimos ver toda a árvore de traces dos pontos de interação do agent”. Essa é a caixa um. Levantem a mão: alguém já tem tracing dos agents?

06:16 Legal. Certo, temos vários, na verdade. Que bom. A próxima etapa é: “Certo, sei o que o agent está fazendo, mas ele está fazendo a coisa certa?” E como faço para pontuar e avaliar isso? Na indústria, chamamos isso de evals. Então, eu diria que algumas pessoas provavelmente estão nessa caixa. Alguém aqui está avaliando seus agents? Vocês têm evals sendo executados nos traces? Certo, temos alguns. Certo, muitos. Isso. Então, presumivelmente, alguém está lendo os traces. E é mais ou menos isso que

06:46 estamos tentando viabilizar com os agents, certo? Mas, na prática, se vocês têm coding agents internamente, não há como alguém ler todos esses traces, certo? Ou, sabem, no caso de um chatbot que atende milhões de clientes, nenhum ser humano sozinho vai conseguir ler esses traces, certo? Depois, vocês querem conseguir salvar essas falhas como testes, certo? Assim, sempre que algo falhar, vocês registram isso e conseguem usar como teste de regressão daqui para a frente, para não cometer o mesmo erro

07:18 duas vezes. E, por fim, vocês querem fazer a correção e comprovar que realmente corrigiram o problema, certo? Então, nessas três últimas caixas, alguém de vocês já está nessa etapa, em que realmente… Ótimo. Legal. Temos alguns. Legal. Então, como conectar todas essas coisas e tornar esse workflow o mais fácil possível? E como incluir as pessoas nesse workflow nos pontos em que elas têm maior capacidade de gerar valor, sem que precisem necessariamente ler um monte de

07:49 traces, certo? O fluxo geralmente é: sinal da trace, que é nosso tipo de agent de SRE pronto para uso, que vou mostrar para vocês na plataforma. Então, o Signal lê as traces, cria um conjunto de dados com base nas falhas, propõe uma eval para você, corrige automaticamente o que está dando errado e, em seguida, executa um experimento que realmente comprova que essa correção é válida. Depois, você revisa essa correção e escolhe

08:20 se quer fazer merge dessa correção, e volta ao ciclo. Cada uma dessas etapas cria contexto adicional à medida que seu agent continua melhorando e avançando para novos casos de uso. Digamos que eu queira adicionar, por exemplo, um checkout com um clique a esse agent, ou algo assim. Isso alimenta não só o roadmap do seu produto, mas também sua organização de confiabilidade de engenharia. Então, é sobre isso que vamos conversar. Vou percorrer o ciclo. Vou mostrar um pouco do agent e das traces dele, o Signal revisando os agents,

08:52 o conjunto de dados de falhas, a eval que criamos com base nesse conjunto de dados de falhas, corrigindo o problema, comprovando a correção com um experimento, o que os agents fizeram por conta própria e o que ainda precisa de uma pessoa, onde vocês podem agregar mais valor, e depois também teremos um tempo para perguntas. Então, o Wonder Toys of the Shopping é o agent assistente que estamos usando hoje. Ele tem um bug que inserimos para esta demonstração. Embora eu espere que vocês não estejam inserindo bugs nos próprios agents. Ele foi desenvolvido com, como eu disse, o repo

09:22 tem vários frameworks de agent diferentes. Principalmente FastAPI, Next.js, Chroma DB e também SDKs de agent. E ele envia traces para o Arize AX. Há algumas ferramentas disponíveis para ele. Uma dessas ferramentas, especificamente aquela que tem o bug, dispara um filtro incorretamente. Então, vou mostrar em linhas gerais como é a experiência de tracing. Tornamos muito, muito fácil configurar traces, para que vocês não precisem instrumentar

09:53 as coisas manualmente para obter as informações dos agents. Temos skills configuradas que envolvem nosso CLI e nossos MCPs e ajudam vocês a começar com tracing. Já temos instrumentação automática para os principais provedores e para os principais frameworks de agent. Tudo é open source, então é muito fácil começar a usar tracing. Parece que muitos de vocês já conhecem tracing, então estarão familiarizados com a aparência da árvore de traces. Um usuário pergunta: “Mostre brinquedos para

10:25 crianças de 9 anos.” Isso percorre todo o caminho de uma solicitação, certo? O agent é chamado, o agent chama um modelo, o agent faz uma chamada final ao LLM. Ele tem algumas ferramentas disponíveis, como pesquisar produtos etc. E dá para ver todas as informações disponíveis para perguntar o que o agent está fazendo nos bastidores. Todos esses atributos mostram, por exemplo, a hora de início, a hora de término, a latência, qual foi a entrada, quais metadados foram passados, em que etapa do grafo ele está,

10:56 os resultados que ele busca no banco de dados e quais informações estão disponíveis para o agent em cada uma dessas etapas. Isso é útil, mas, de novo, provavelmente vocês não querem ler isso às 4h da manhã. Acho que seria bem difícil ler milhares delas às 4h da manhã só para descobrir onde está o erro. Então, o que queremos fazer é permitir que os agents usem essas informações e, depois, ver como podemos realmente fechar esse ciclo de autoaperfeiçoamento.

11:28 Então, percorri a trace. Se quiser instrumentar, usamos o AX CLI. Ele tem uma configuração guiada. É muito fácil começar a usá-lo. Tudo de que você precisa é de uma chave de API da Arize, e ele vai cuidar de traduzir todos aqueles atributos chatos para a bela árvore de traces que vocês viram. Você terá um span por chamada de ferramenta, com os argumentos e os resultados da chamada. Terá chamadas de modelo, contagens de tokens do prompt e todos os elementos básicos necessários para monitorar o que está acontecendo, além de agrupamentos.

11:58 Assim, você pode ver sessões com várias interações de ida e volta com um cliente, em vez de apenas traces individuais de uma única interação de ida e volta com um cliente. Então, apresento o Signal, que é meio que a segunda etapa desta plataforma, certo? Depois que você tem essas traces, o Signal é um agent sempre ativo, capaz de ler suas traces de acordo com uma programação. Você pode configurar isso na plataforma para seguir a programação que quiser. Por

12:30 padrão, está configurado para ocorrer a cada 6 horas. Você o direciona para um projeto que está recebendo traces ativas. Você o ativa, ele revisa essas traces e pode executar várias ações diferentes por meio das skills dele, certo? Então, a ação básica que vamos mostrar hoje é o Signal conectado a um repo no GitHub. O agent Signal está lendo as traces de outro agent. Ele lê o código-fonte desse agent com base no que está realmente

13:03 acontecendo nas traces de produção desse agent e na definição de código, e assim consegue propor correções para o que você está observando. Vou mostrar rapidinho como isso funciona. Temos este agent Wonder Toys. Ele está publicando traces. Podemos ver todas as solicitações dos usuários. Dá para ver que fiz muitas delas antes desta apresentação, às 13h. Podemos ver informações básicas, como latência, contagem de tokens e custo de execução deste projeto. E vocês verão

13:33 esta aba do Signal. O que o Signal faz é agrupar os problemas que encontra nas traces e propor e identificar uma correção para eles. Para este agent, o bug que inserimos causa novas tentativas de pesquisa redundantes. O que o Signal está observando, com base nas traces que chegam a este projeto, é que estamos fazendo três chamadas sequenciais ao LLM e causando alta latência por causa

14:04 de algo que está acontecendo na chamada de pesquisa de produtos, certo? Mais especificamente, o que está acontecendo é que a capitalização de algumas dessas consultas de filtro não está funcionando, certo? Então, em vez de você receber um alerta às 4h da manhã — se lembram do meme no começo desta apresentação? —, o Signal encontra o problema, analisa grupos desses problemas, escreve uma visão geral e uma análise, e prepara uma correção para você. Depois, você

14:35 pode criar evals para detectar esse problema automaticamente no futuro e acionar essas evals. Assim, se encontrarmos esse problema em qualquer momento nos próximos 30 dias, dispararemos um alerta automaticamente, e nossa equipe fará a triagem imediatamente. Você também pode adicionar casos de falha ao conjunto de dados aqui, para ter um registro para futuros testes de regressão desse modo específico de falha. Vocês também verão aqui um ícone do GitHub para conectar e abrir um PR ou abrir issues

15:08 também, para que o Signal possa criar um PR. Eu já fiz isso, então vocês podem ver as tentativas do Signal de corrigir o problema, certo? Vou clicar na sessão. O agent trabalhou por 6 minutos, encontrou a causa raiz também no repo de código, com base nas traces, e descobriu que as categorias dos produtos são armazenadas como slugs em minúsculas separados por hífens, mas o elemento está passando nomes legíveis por pessoas, com iniciais maiúsculas e espaços

15:40 Então, quando alguém pesquisa por jogos de carro, por exemplo, sem essa normalização, não recebemos resultado nenhum. O agent acaba pesquisando todos os produtos, certo? Dá para imaginar por que isso causa um pico de latência de até 14, 17 segundos. Todo mundo está acompanhando até aqui? Temos um agent, temos um problema. O Signal está lendo as traces para vocês e propondo uma correção em conexão com o GitHub. Então,

16:11 na verdade, lendo a definição desse agent e fazendo uma análise para você, além de garantir que isso fique disponível para você. Então, essa é uma entre muitas skills que você pode conectar ao Signal. Aqui, na plataforma de gerenciamento de agents, você verá que pode usar um dos nossos modelos prontos. Assim, o Signal analisa os traces do seu projeto em intervalos programados, agrupa falhas e sugere correções. Temos um agent de custos que pode sinalizar modelos caros realizando tarefas simples e recomendar um encaminhamento mais barato,

16:43 e até quantificar suas economias. Mas a parte interessante é que você pode começar do zero. O Agent Studio permite escolher uma configuração de agent, apontá-lo para um projeto que esteja recebendo traces, atribuir uma tarefa e também conectar skills a ele. Como mencionei, o GitHub é uma dessas fontes. Talvez você tenha um sistema de terceiros que contenha informações de RBAC e queira verificar as permissões desse agent. Você quer garantir que aquilo que o agent está chamando esteja dentro dos limites das permissões dele. Você pode… Você pode uma

17:15 skill para fazer isso. Você pode conectar uma skill a outro sistema de APM, como Datadog, se houver mais logs que queira incluir. Não há realmente limite para as skills que você pode definir, desde que tenha uma chave de API e elas possam ser chamadas pelo próprio agent harness. Nos bastidores, estamos executando esses agents em sandboxes gerenciadas pela Arize dentro da plataforma. Você também pode usar seu próprio harness e seu próprio provedor de sandbox, seja Modal, Daytona, E2B ou qualquer outro, e qualquer que seja o harness que você esteja usando, nós

17:45 oferecemos suporte a Codex, Cursor, Claude Code e Open Code, e mais opções de harness serão disponibilizadas. Então, todos entendem que temos um agent gerenciado fazendo isso na plataforma? Você pode configurar suas próprias automações para serem acionadas em um horário programado ou por um alerta. Assim, sempre que a latência ultrapassar 10 segundos, iniciamos automaticamente esse agent para investigar. Os agents de investigação também fazem parte disso. Eles atendem ao caso de uso de SRE. Há também uma perspectiva de custos para

18:17 isso. E há uma perspectiva de classificação de produtos. Existem muitas maneiras de usar essa plataforma de agents para operar sobre seus traces. Legal. Vou continuar. Então, os Signals leem seus traces e registram o que encontram. Mantêm um ticket por problema, como faria uma pessoa revisora. Assim, você não recebe centenas e centenas de issues sobre a mesma evidência. Eles abrem esses tickets. Você corrige o problema. Pode marcá-lo como resolvido, se achar que foi

18:47 resolvido, ou ignorá-lo, e o sistema vai deduplicar essas issues daqui para a frente, para que você não fique inundado de ruído. Acho que o campo, ou fluxo, de adicionar ao conjunto de dados é uma das partes mais importantes, porque como se constrói o aprimoramento contínuo? É preciso manter um registro do que falhou no passado e usar esses casos como verificações de regressão daqui para a frente, certo? Então, adicionar esses casos aos conjuntos de dados dá a você esse tipo de conjunto de referência vivo. Ou seja, você define casos de teste no código

19:19 antes de publicar o código. Todo mundo deveria fazer isso e, com sorte, agora todos estamos fazendo isso com a ajuda de alguns agents. Mas essa ideia de conjuntos de referência vivos, que mudam com o tempo à medida que você adiciona novos casos de uso e encontra novos modos de falha, é bastante inovadora e ajuda no ciclo de autoaperfeiçoamento. Assim, você não fica preso a uma única definição, feita em um único momento, do que falhou e de quais são nossos modos de falha; em vez disso, essa definição de modo de falha cresce organicamente à medida que seu agent

19:50 falha em produção, certo? Pense assim: toda vez que você tenta andar de bicicleta, percebe algo sobre como está pedalando. Com o tempo, isso fica tão arraigado na sua memória que andar de bicicleta parece algo natural. Você nem pensa nos modos de falha — como, por exemplo, cair da bicicleta e quebrar o pé, como aconteceu comigo há dois meses, e por isso estou contando essa pequena anedota. Normalmente, você já não pensa em colocar o pé esquerdo no pedal esquerdo, porque isso ficou muito arraigado no seu processo de aprendizado. E é isso que estamos tentando

20:20 alcançar com esses agents. Então, quanto aos conjuntos de dados, depois que você tiver esses conjuntos de referência vivos, vai querer formalizar o comportamento esperado para eles, certo? É aí que entram as evals. Vi algumas pessoas levantarem a mão para dizer que estão executando evals. Posso ter uma ideia rápida de quantas pessoas há na sala? Quem aqui está executando evals com LLM as a judge ou usando avaliadores de código? Legal. Então, se vocês participaram de algum dos workshops anteriores da Arize, abordamos os avaliadores em bastante profundidade. Há

20:51 muitas formas diferentes de avaliadores. Só uma visão geral rápida: há verificações de código, que são muito baratas de executar e servem para verificações determinísticas, certo? Este campo está presente? Este é um JSON válido? Regras exatas. Este filtro foi aplicado? Esta ferramenta foi chamada com os argumentos corretos? São verificações muito fáceis, certo? As evals com LLM as a judge também ajudam nesse caso de uso, quando é necessária uma análise mais qualitativa ou de natureza mais vaga

21:22 do trace, certo? Isso usa outro modelo de LLM para avaliar os resultados do trace de um modelo. Obviamente, os custos serão mais altos, porque você está fazendo uma chamada adicional ao modelo. Para cada registro, você pode definir sua própria amostragem e filtragem. Não precisa executar essas verificações em 100% dos traces que estiver coletando. Há algumas compensações no design das evals que podemos discutir, mas é basicamente para isso que serve o LLM as a judge. Depois, temos

21:53 os casos de uso ainda mais abertos, para os quais existe o conceito de agent as a judge. Nesse caso, você não tem certeza do que está avaliando; tem um objetivo em mente e deixa que o próprio agent determine se esse objetivo foi alcançado. O agent pode definir seus próprios critérios e suas próprias pontuações, e pode conduzir esse processo sozinho. Obviamente, esse é o método de maior custo, porque várias chamadas a LLM acontecem nos bastidores.

22:23 Os decision models existem há, sei lá, cerca de um mês, e a Lower, da Arize, publicou bastante material sobre como compará-los em benchmarks, como funcionam e quais são as compensações envolvidas nos decision models. Eu diria que eles são uma forma muito, muito barata de executar algumas dessas verificações nos seus traces, em vez de usar um LLM tradicional. E eles oferecem opções tipadas, como sim, não, escolha e pontuação.

22:56 Então, quando você tem esse sinal de eval, certo? Você entende, qualitativamente, se está indo na direção certa ou não e se está passando nas suas verificações de eval. E você tem os dados dos traces. Tudo isso é um contexto muito rico para um agente de programação implementar uma correção, certo? Nesse caso, o Signal está rodando em uma sandbox gerenciada pela Arize, com um harness de programação, para implementar essas correções para você. Mas

23:26 se você estiver na fase de desenvolvimento, também pode trazer esses traces ao vivo para a Arize usando a CLI, certo? Assim, você tem contexto instantâneo para fornecer a outros agents, que podem trabalhar nessas PRs para você. É aqui que entra o equilíbrio com a supervisão humana. Eu diria que os momentos em que uma pessoa agrega mais valor são, primeiro, validar a correção, certo? Ler a PR. Talvez alguns de nós sejamos do grupo que não quer validar

23:58 cada PR humana. Presumo que, se você está em um caso de uso de alto risco, como finanças, você faz parte do grupo que quer que humanos leiam o PR antes do merge, certo? Então, esse é um ponto de alto impacto em que uma pessoa pode participar. Também na etapa de curadoria do conjunto de dados: adicionar algo a um conjunto de dados é parte do motivo pelo qual deixamos isso manual; a questão é se essas descobertas são boas o suficiente para adicionar ao meu fixture, certo? Então, essa é uma etapa manual do processo e também depende do julgamento humano. O design dos evals: temos agents que ajudam você a escrever esses evals, mas a parte de design dos evals

24:29 é algo em que os humanos definitivamente podem participar, porque você transmite ao agent seu próprio critério do que é bom, seja na forma de um LLM as a judge ou de uma verificação mais determinística. E incorporar todas essas informações ao coding agent dá a ele um contexto realmente rico para trabalhar. Como exemplo de como você criaria um eval com base nisso, vou acessar a aba de traces. Estou trabalhando no projeto Wonder Toys. Tenho o Signal em execução, e o Signal encontrou

25:00 dois issues até agora. Um é o issue de spans órfãos, que, na verdade, foi só um erro meu ao instrumentar isso. Mas ele detectou. E o segundo são as novas tentativas redundantes de busca. Esse é o bug que plantamos. Consigo criar um novo evaluator com um clique a partir disso. E isso, na verdade, parece que preciso usar um modelo diferente. Isso abre o Alex, que

25:31 é nosso agent interno, sobre o qual vou falar amanhã. Ele consegue criar esse eval para mim com base nessas evidências, certo? Então, com base nos traces que aparecem nas evidências aqui, podemos codificar em um template de prompt o que devemos esperar daqui para a frente e como garantir que o eval seja acionado e falhe quando ocorrerem erros. >> [fungada] >> Este é o eval que criei: “Você é um bot de IA prestativo que verifica novas tentativas redundantes de busca de produtos. Inspecione a trajetória completa, incluindo chamadas de ferramentas, veja se há alguma chamada de ferramenta desnecessária, retorne uma nova tentativa redundante quando a busca de produtos for chamada mais de uma vez, e coloque a pontuação e a classificação diretamente no trace.”

26:01 Depois, você pode executar esse eval nos traces recebidos pelo seu projeto, para garantir que detecte isso, monitorar e gerar gráficos disso, criar um alerta com base nisso e acompanhar também os gastos associados a esse eval. Com o tempo, talvez seu fluxo de desenvolvimento tenha codificado isso

26:32 como uma verificação de regressão, e você não precise mais executar esse eval em dados de produção. Você não vai querer gastar tokens do modelo executando isso em cada trace. Você também pode ver o custo ao longo do tempo e desativar esse eval. Legal. A próxima parte é: certo, temos uma correção. O Signal encontrou algo. Analisou o repo. Criamos um eval para detectar isso da próxima vez. Adicionamos as evidências a um conjunto de dados. Então, agora temos

27:04 um fixture vivo que cresce com o tempo. Como sabemos se a correção está certa? Como sabemos de verdade que não foi apenas código malfeito produzido pelo agent, que tentou encontrar um problema que nem existia? É aqui que entra o mundo da experimentação com agents. É um mundo muito, muito rico e complexo. Não vou gastar tempo falando de todos os diferentes frameworks e provedores que existem por aí. A equipe do Phoenix fez um bom trabalho mais cedo hoje ao falar um pouco sobre a integração com o harbor que têm no Phoenix. Mas, na verdade, o que nos preocupa é provar que a

27:36 correção funciona e provar que não quebramos mais nada, certo? Há muitos casos em que, nesse mundo não determinístico, uma pequena mudança no system prompt pode ter consequências em outras ferramentas que você não imaginava que fossem falhar. E também podem surgir problemas de redundância. Por isso, é muito importante garantir que possamos provar que essa correção realmente funcionou e que nada mais quebrou. Essa é, em essência, a etapa de experimentação.

28:07 Vou falar um pouco sobre isso também ao longo do fluxo. No Rise, oferecemos suporte a vários tipos diferentes de experimentos. Este é o experimento de correção do enum de código de categoria que acabei de executar. Como podem ver, temos evals sendo executados nesse experimento. O que estamos fazendo, essencialmente, é usar esse fixture vivo de casos de falha. Temos uma correção proposta. Nós

28:38 queremos, na verdade, executar o agent novamente nesses casos de falha e pontuar os resultados. Se eles atingirem um certo limiar — que cabe a você definir —, no meu caso, achei que 88,9% era muito bom. Então, pensei: pode enviar. Se atingirem esse limiar, você terá resultados que comprovam a correção proposta pelo agent, certo? E o agent também pode executar esses testes para você pelo AX CLI. Assim, enquanto o Signal encontra esses casos de falha e tem acesso

29:08 ao código do agent, ele pode encaminhar esses casos de falha e reproduzi-los com o agent usando a versão dois da correção, e depois pontuar os resultados por conta própria, certo? Então, você volta de manhã — não ficou trabalhando às 4 da manhã — e não tem apenas um PR com uma correção proposta: você também tem resultados de validação que dizem: “Ei, provei essa correção porque usei os casos de teste em que falhamos e medi novamente a latência ou as novas tentativas de chamadas de ferramentas, e vi que não estávamos mais repetindo as chamadas de ferramentas e que a latência estava menor. E, além disso, havia três outros evals nos quais você também não queria falhar. Então, garanti que esses evals não apresentassem regressões, certo? E, à medida que esse fixture vivo cresce com o tempo, surgem novos casos e esses experimentos se tornam cada vez mais robustos, certo? Na plataforma, obviamente, você pode consultar os resultados do experimento, ver qual foi a saída e quais são os evals. Se discordar do agent, você pode anotar essa saída, e isso se torna mais uma informação no

29:39 tentando novamente por mais tempo com as ferramentas, e a latência era menor. E, aliás, havia outras três evals nas quais você também não queria falhar. Então, fiz questão de verificar se essas evals não estavam regredindo, certo? E, à medida que esse conjunto de testes vivo cresce com o tempo, você tem novos casos, e esses experimentos ficam cada vez mais robustos, certo? E, na plataforma, obviamente, você pode ver os resultados desses experimentos, conferir qual é a saída e quais são as evals. Se você discordar do agent, pode fazer anotações nessa saída, e isso se torna mais uma informação para o

30:09 contexto para a próxima execução, certo? Está claro para todos, em linhas gerais, como funciona esse fluxo de experimentação, por exemplo, como executar alguns desses experimentos para usar um caso de teste e um eval que você criou como benchmark, e validar sua correção antes de ela ser lançada, antes de chegar à produção? Você também pode incorporar isso ao processo de CI/CD. Fica a seu critério como configurar. Obviamente, executar o agent pode ser caro. Então, fica a seu critério como quer executar isso.

30:40 Evals também, certo? Se você estiver usando um eval com um LLM as a judge, precisa ter cuidado com o modelo que escolhe, quando executa esses evals e qual taxa de amostragem usa, para garantir que os custos não disparem e que você não acabe gastando muito para validar essas correções a cada push. Legal. Continuando: aprovamos a correção e analisamos as taxas de conclusão de tarefas. Validamos esses resultados e, enquanto

31:14 você se afasta um pouco desse processo, o que continua em execução é o eval que você criou: ele é executado em cada novo trace e se torna contexto adicional para a próxima execução do Signal. O sistema de tarefas que temos no Arize também pode adicionar automaticamente resultados de evals que falharam a novos bancos de dados ou conjuntos de dados, para que esse fixture cresça com o tempo. E o Signal continua sendo executado a cada 6 horas, por causa de um alerta ou de um monitor acionado, garantindo que novas falhas sejam identificadas, e novos evals sejam

31:47 criado, e esse conjunto de dados cresce com esses novos exemplos ao longo do tempo. Também temos, sabe, resumos semanais que você pode consultar de uma forma um pouco mais fácil de ler, com um resumo do que está acontecendo com o agent. O que cabe a você é confirmar se esses issues são reais, certo? Você não pode simplesmente confiar em cada issue que esse agent apresenta. Eu diria para usá-lo como ponto de partida, validar essas correções e usar seu próprio julgamento para decidir quando esses issues são realmente reais. Registrar como é a resposta correta

32:18 por exemplo, então isso entra no fluxo de anotação, certo? Você executa o experimento, recebe uma nova saída, talvez não ache que seja a resposta perfeita ou a trajetória perfeita para o agent, e pode usar o produto de anotações para codificar esse critério. A decisão de mesclar a correção fica a seu critério. Você pode mesclar esses PRs automaticamente. Vou deixar isso a seu critério. E então, de fato, fazer o deploy e promover a nova versão, certo? Então, tenho a V2, validei, acho que o issue é real, criei o eval, analisei a pontuação, validei a correção, gostei do código, revisei o

32:48 código. Agora é hora de atualizar o agent de fato. Acho que a outra coisa realmente interessante nisso é que você pode codificar as pontuações de confiança, especialmente com esses modelos de decisão que retornam uma pontuação de confiança explícita, e encaminhar automaticamente os casos para pessoas em filas de anotação, certo? Então, você não só fica responsável por revisar as saídas, como também recebe uma fila pronta

33:19 com base em todos os resultados de baixa confiança e, em alguns dos nossos benchmarks, vimos que essas pontuações de confiança são bem boas. Isso depende do seu caso de uso e das especificidades do setor, com certeza. Então, eu não diria que uma pontuação de confiança de 80% é o limite certo para todo mundo, mas definir esses limites é importante; depois de defini-los, você pode encaminhar automaticamente os casos de baixa confiança para alguém fazer a anotação.

33:49 Então, no teste de spam que vimos, 4,6% dos casos tiveram uma pontuação de confiança entre 0,3 e 0,7 e foram encaminhados para pessoas; o restante ficou com 99,5% de precisão, certo? Esse é um exemplo de um setor em que, especificamente para a detecção de spam, esses limites de confiança talvez sejam mais bem definidos. Com certeza, isso depende do caso de uso. Então, falei um pouco sobre algumas das coisas que já desenvolvemos com o Signal

34:21 para gerenciar agents e traces, certo? A capacidade de ler esses traces em escala, de adicionar itens a conjuntos de dados, de executar esses experimentos com a ajuda de um coding agent e de revisar os resultados diretamente. Você também pode interromper sessões, examinar o raciocínio do modelo e continuar uma sessão, encaminhá-la para um agent local, para que possa continuar o desenvolvimento por conta própria, se não quiser que tudo isso seja gerenciado pela Arize. Mas acho que nossa visão para o futuro é executar esse ciclo completo, de ponta a ponta,

34:53 com quase nenhum envolvimento humano até ser necessário testar alguma coisa, certo? Até você precisar navegar por uma interface e validar algo. Há muitos provedores para configurar esse tipo de experimentação, certo? Temos os Harbors da vida. Há muitas maneiras diferentes de testar o agent. Acho que a maior parte da discussão é sobre quantas dependências você precisa executar para rodar esse agent, certo? Executar um agent na fase experimental significa conectá-lo a um banco de dados simulado?

35:23 Você desativa algumas ferramentas? Executa tudo em uma imagem Docker? Dá até para fazer isso com segurança? Essas são algumas das perguntas que eu recomendaria que vocês considerassem ao começar a pensar nesse fluxo de experimentação. Com esse agent, sabe, é muito simples. Basta executar o agent inteiro novamente. Não há dependências. Ele inicia seu próprio banco de dados, e então enviamos requisições para ele. Esse pode ser um caso de uso bem simples. Mas, quando você tem dependências externas realmente importantes, seu

35:53 caso de uso pode ficar um pouco mais complexo. Nosso objetivo com isso é permitir passar do issue ao experimento com um único clique. “Ei, tenho essa correção proposta. Teste-a. Inicie toda a infraestrutura necessária para testá-la.” Além disso, trabalhamos na CLI para conectar o Signal também ao lugar onde você trabalha. Seja no Slack, marcando o Signal no Slack para se comunicar com ele; sejam seus agents locais, que usamos por meio da API, da CLI e de skills, com os quais você pode

36:25 pedir ao seu agent local que faça um resumo do que o Signal está encontrando e verifique os resultados. Garantir que a correção seja elaborada diretamente a partir do issue e dos traces dele também faz parte do que já fizemos, assim como incluir as evidências diretamente. Então, aqui estão os cinco traces que falharam, na descrição do PR, para que você possa validá-los. Agora, o Signal também propõe evals para você. Ele verifica seus evals e identifica quais estão saudáveis — ou seja, se um eval está passando

36:57 99,999% das vezes, talvez não queiramos gastar tokens nesse eval e possamos aposentá-lo daqui para a frente. Sentimos bastante confiança nele. Ou, ao contrário, se algum eval estiver com desempenho ruim, podemos torná-lo mais robusto. Temos um processo completo de alinhamento de evals, que serve para garantir que o judge esteja alinhado ao que eu penso e não esteja simplesmente atribuindo pontuações nas quais não acredito. Há todo um processo para isso. E, novamente, o fluxo de experimentação consiste em executar seu agent contra esses conjuntos de dados, onde quer que ele esteja.

37:29 Seja no seu laptop — no meu caso, para esse agent bem simples —, seja em uma infraestrutura mais complexa. Legal. Acho que seria ótimo começar a experimentar algumas dessas coisas. Tenho o URL do repo do workshop. Também temos páginas de documentação sobre experimentação com agents. E temos algumas outras palestras ao longo desta semana.

37:59 A Si tem uma amanhã, às 3h20, sobre correções de agents e suas implicações a jusante. Ou seja, você corrige algo em algum lugar e isso acaba tendo impacto mais adiante. E eu tenho uma palestra amanhã, às 3h45, sobre o Alex, nosso agent interno. Usamos o Alex para criar o Alex, então ele é a ferramenta perfeita de dogfooding para nós na área de agents. Vou falar um pouco sobre como projetamos esse agent, como estruturamos o contexto e a memória e algumas das decisões e

38:31 lições que aprendemos ao longo do caminho. Eu realmente recomendaria que vocês tentassem obter alguns traces do agent. Já deixamos tudo isso pronto para vocês, mas, se tiverem um exemplo próprio e ainda não tiverem instrumentado seu agent com traces, é muito simples instalar nossas skills e a CLI, pedir que instrumente seu agent e enviar esses traces para a Arize. Depois que os traces estiverem lá, basta um clique para ativar o Signal, e então você poderá ver o agrupamento de issues e padrões nos seus traces também.

39:02 Então, sim. As ideias que eu gostaria de deixar para vocês são: o trabalho árduo de ler uma enorme quantidade de dados definitivamente deve ser feito por um agent. Entender onde incluir pontos de intervenção humana de maior impacto é o tema central desta apresentação. Só porque é possível automatizar algo não significa que isso deva ser automatizado, mas você deve usar essa automação para realmente orientar quem revisa. Por isso, coisas como encaminhar automaticamente as pontuações abaixo do limite de confiança para a fila de revisão são realmente

39:34 importante. E garantindo que todo o contexto seja enviado de volta ao mesmo sistema. E, obviamente, estamos aqui com a Arize e estamos dizendo como a Arize é ótima, mas, na verdade, quero que você se certifique de que esse contexto seja registrado em algum lugar, certo? E essa é a única maneira de criar o ciclo de autoaperfeiçoamento: quando o julgamento humano, as pontuações das evals, os traces e as evidências dos traces ficam todos reunidos no mesmo lugar, alimentando o contexto para a próxima execução. Assim, você identifica novos problemas em vez de

40:04 simplesmente lutar para se manter à tona. E é isso que eu tinha para vocês. Muito obrigado. Fico à disposição para circular por aí e ajudar vocês a começar com algumas dessas coisas. Vocês podem conferir o repo e clonar o agent. Se não, podem instalar as skills, instrumentar o próprio agent e, sim, também posso responder a perguntas, se quiserem. Eu diria que há duas perspectivas para avaliar como fazemos isso de fato. Uma é: como avaliamos o Signal como linha de produto? E um dos principais fatores aí seria: com que frequência ele acerta nas nossas PRs, certo?

40:34 Isso é uma espécie de avaliação interna. Você quer dizer mais como avaliamos nosso próprio produto ou como você pode avaliar um caso de uso de agent, em termos gerais? Vamos fazer uma palestra inteira sobre evals para o Alex amanhã, mas, para dar a resposta resumida, o design de evals é, como AIPM, provavelmente minha principal função: como faço para projetar boas evals que realmente meçam as coisas certas? A resposta mais curta para essa pergunta é

41:05 Acho muito difícil formalizar decisões qualitativas. Formalizar coisas como latência e número de novas tentativas — esses são problemas mais clássicos que, por exemplo, o issue Signal encontrou. Acho que isso é relativamente simples: você encontrou uma inconsistência no uso de maiúsculas e minúsculas, viu evidências nas novas tentativas, faz a correção e mede a latência. Isso é muito fácil, certo? Já os resultados qualitativos são um pouco mais difíceis, e eu diria que há algumas coisas a considerar. Uma delas é

41:36 que a definição propriamente dita do que é bom só emerge da quantidade de sinal que você consegue fornecer; uso “sinal” nesse sentido. O que quero dizer com isso é: posso olhar para um exemplo e dizer se está certo ou errado. Não posso fazer um agent aprender com um único exemplo, porque aí ele simplesmente vai se ajustar demais àquele exemplo, ou talvez esse exemplo não se generalize bem. E parte do que eu estava falando sobre os fixtures vivos e as anotações é algo que fazemos bastante. Vou dar um exemplo: o Alex gera consultas de filtro, certo? Então

42:09 temos o Alex na plataforma. Temos um fluxo em que, se você quiser pesquisar agents ou traces, pode, obviamente, digitar um filtro ou pedir ao Alex para filtrar com IA. Como medimos o desempenho disso de fato? Não há uma resposta certa ou errada, porque ele pode retornar um filtro que funciona e não analisa esse JSON; vai mostrar alguns resultados, mas como saber se esse é realmente um bom resultado? Então, há algumas coisas. Primeiro, analisamos a sessão inteira do usuário, certo? Não perguntamos apenas: “Certo,

42:40 para este turno, foi uma boa resposta?”. Mas aquele usuário perguntou de novo? Ele ficou satisfeito com os resultados? Quantos filtros adicionais criou, certo? Isso pode servir como um sinal para você avaliar. A segunda coisa são as anotações: ler o conteúdo e perguntar: qual era a consulta? Parece um filtro correto? Retornou os resultados corretos da eval? E então fazer essa anotação manualmente, como PM que sabe o que esperar. Depois, você combina as duas coisas com novos casos de uso, e esse

43:10 contexto rico se torna o modelo de eval, certo? Você pode usar outro agente de programação para fornecer esse contexto e escrever um modelo de prompt realmente bom; aí, basicamente, isso se torna uma otimização de prompt, certo? Tipo: quão bom consigo deixar esse modelo de eval usando o modelo de menor custo, para poder executá-lo em escala? É mais ou menos assim que pensamos nisso. Amanhã vamos falar de alguns detalhes a mais: vou explicar um pouco quais modelos escolhemos e como pensamos nos casos de uso que valem ou não a pena avaliar. Mas, sim,

43:41 essa é a resposta resumida. É meio que um post hoc ergo propter hoc: como podemos garantir que aquilo que definimos como saudável é realmente saudável e onde devemos definir o ponto em que algo falha? O que quero dizer é: certo, está correto em 99,9% das vezes. Se esses 0,1% forem catastróficos e precisarmos identificar todos eles, a discussão é bem diferente, certo? E, quando falo de evals, há duas perspectivas. Há as evals que você pode executar no

44:12 fluxo de desenvolvimento como verificações de CI/CD, como verificações de regressão antes de fazer deploy do código. E há as evals que você executa em traces ao vivo; aí, a questão passa a ser a relação custo-benefício, certo? Se eu executar isso em 100% dos traces ao vivo, vale a pena pagar para rodar esse modelo em todos os meus traces, comparado ao custo dessa falha de 0,1%, certo? Acho que muita coisa se resume ao ROI. As diretrizes gerais são: tudo o que você puder detectar em CI/CD, deve detectar. E eu

44:43 entendo que é um desafio executar algumas dessas coisas. E convencer as equipes a executá-las em CI/CD também. Eu provavelmente tornaria algumas dessas verificações obrigatórias no processo de CI/CD, certo? Assim, você tem um conjunto de dados de fixtures que mostra onde essa eval falhou de fato nos 0,1% dos casos, e executa — reexecuta — essas avaliações a cada vez que faz push ou antes de uma PR ser mesclada. Assim, pelo menos você tem alguma confiança de que esse conjunto de casos não vai falhar. Depois, executa uma eval com uma taxa de amostragem nos traces de produção,

45:15 certo? Em vez de dizer: “Certo, vamos ignorar o processo de desenvolvimento e avaliar tudo o que chega à produção”. Isso pode custar muito caro, em comparação com: “Certo, vamos ignorar completamente a produção e testar apenas durante o desenvolvimento, tentando cobrir todos os casos — o que provavelmente não dá para fazer em um conjunto de dados com cobertura — e depois deixar acontecer em produção”. Eu diria que essas duas opções são extremas, e a resposta fica em algum ponto intermediário. E depende um pouco do ROI da eval, certo? E o modelo

45:45 que você decide usar tem implicações no custo etc., etc. É uma pergunta muito boa e fica bem metalinguística. Espero que vocês não tenham percebido como esta conversa ficou metalinguística até agora, com eu usando “sinal” de várias maneiras diferentes. A resposta curta é que você pode repetir esse ciclo inteiro, certo? Então, temos um projeto para traces de eval. Este foi criado pela Rise. Estas são todas as evals, e essas evals geram traces, certo? Você pode ter um agent lendo os traces das evals e verificando se as evals são boas. E cada um desses agents também produz seus próprios traces, certo? Então, quando você executa o Signal, estes são os traces do Signal. Aqui você verá: “Você é o Signal, um revisor automatizado da Rise”. Estas são as etapas que você precisa seguir. Estas são as instruções. Foi isso que o Signal chamou nos bastidores. Fez algumas chamadas bash. Chamou nosso MCP interno da MC para fazer essa investigação e depois a envia, registrando-a como um issue, certo? E também dá para executar o Signal em cima do Signal para garantir que… E é mais ou menos isso que

46:15 as evals são boas. E então, cada um desses agents produz seus próprios rastros, certo? Então, quando você está executando o Signal, estes são os rastros do Signal. Então, você verá aqui: você é o Signal, um revisor automatizado do Rise. Estas são as etapas que você precisa seguir. Estas são as instruções. Foi isso que o Signal realmente chamou nos bastidores. Então, ele fez algumas chamadas do bash. Chamou nosso MCP interno do MC para fazer essa investigação e depois a enviou, criando uma issue, certo? E então, você também pode executar o Signal sobre o Signal para garantir que… E isso é mais ou menos o que

46:46 como avaliamos internamente, certo? É meio que aquilo a que eu estava me referindo como a ferramenta definitiva para usar o próprio produto. Agora, suponho que sua pergunta seja mais sobre quando isso deixa de funcionar. Quando é útil fazer isso? Acho que as mudanças no harness são úteis até certo ponto, e vou falar um pouco sobre isso na minha palestra de amanhã, sobre como avaliamos Alex. Há certos casos de uso em que, depois de certo ponto, você simplesmente não precisa

47:17 continuar avaliando, e os retornos sobre o custo começam a diminuir. O que temos observado é que monitoramos o Signal e recebemos traces do Signal. Temos alguns critérios de pontuação de avaliação, mas chega um ponto em que não sabemos o que é bom para nossos clientes além do que eles próprios sabem. Então, você pode ativar o Signal e ele pode propor o PR, e podemos usar algumas métricas indiretas, como a taxa de merge do PR, a transcrição da sessão ou se a sessão foi encaminhada, se um conjunto de dados foi criado ou se uma eval foi criada, como mecanismos de feedback. Mas

47:47 além disso, e da taxa de merge do PR, não conseguimos dizer muito mais. Então, a partir daí, continuar avaliando traz retornos cada vez menores. Porque, nesse caso, você está apenas confiando na transcrição de um agent e não tem nenhuma verdade fundamental, certo? Você está só indo na intuição com a saída do agent e fingindo que está aumentando o valor para os acionistas, certo? Então, não acho isso útil. Mas acho que

48:18 para responder à sua pergunta, também usamos o Signal para avaliar o Signal. Acho que as verificações em tempo de execução, por causa da latência tão baixa, são provavelmente a parte mais empolgante: você pode realmente encaminhar uma solicitação durante a execução. Essas evals que estão vendo são feitas depois, quando o agent já foi executado e nós o avaliamos com base nisso. Então, devido à baixa latência dos modelos de decisão, essa é uma coisa que me deixa genuinamente empolgado no loop de execução.

48:48 E, egoisticamente — ou talvez nem seja egoísmo —, pelo meu próprio prazer, gosto que as pessoas estejam muito mais propensas a usar evals agora, porque elas são mais baratas. Isso é simplesmente bom para a saúde do ecossistema: mais pessoas pensando em evals, mais pessoas pensando em realmente classificar seus traces. Acho que isso vai abrir muitas possibilidades, justamente por ser mais barato. E, talvez sem relação com esta palestra, mas, na minha opinião pessoal, acho que, como esses modelos são tão pequenos

49:20 há coisas realmente interessantes que dá para fazer com recursos no dispositivo, e estou muito, muito empolgado com isso. Também estamos, de certa forma, abrindo caminho para algumas evals multimodais. Acho que evals multimodais podem ser muito complicadas por causa da latência. E também podem ser extremamente qualitativas. No espaço de evals multimodais, por exemplo, pode ser muito difícil confiar no gosto de um agent em relação a uma imagem gerada ou na forma como ele interpretou uma caixa de clique, mas obter pontuações de confiança permite ao menos

49:50 encaminhar isso para uma pessoa muito mais rápido. Então, acho que esse também é um espaço em que os modelos de decisão vão ajudar bastante. Sim, com certeza. Eu mencionei isso rapidamente quando falei de skills, mas vocês podem criar seus próprios agents. E, obviamente, temos o agent Signal pronto para uso. Deixe-me mostrar este aqui. Vocês vão ver que também temos uma skill do DataDog, com a qual dá para consultar

50:22 métricas, logs e traces de APM relacionados ao alerta. Também temos vários provedores disponíveis para isso. Vocês também podem escrever suas próprias skills, então o agent não tem acesso apenas aos traces do agent, mas também às métricas dos sistemas e aplicativos downstream. Assim, dá para conectá-lo basicamente a qualquer fonte de dados. Obviamente, há um certo critério na escolha da fonte de dados: conectem as fontes necessárias, garantam que ela tenha o acesso correto, confiram a chave de escopo e evitem inundar o context, porque mais nem sempre é melhor para fazer a triagem do alerta.

50:52 Mas, sim, também podemos fazer tudo isso. A resposta frustrante que todo mundo sempre dá é “depende”, mas, de fato, depende. Por exemplo, que harness vocês estão usando? Que provedores subjacentes estão usando? Com que frequência estão executando isso? Deixamos essas opções disponíveis como configurações. Também permitimos que vocês monitorem o custo. Aqui vocês podem ver os traces do Signal. É quanto está… Ah, acho que ainda está chegando agora, mas

51:22 da mesma forma que vocês podem ver o custo do Wonder Toys, podem ver o custo do Signal. Facilitamos entender o ROI. Por exemplo: “Certo, este agent assistente de compras me custa US$ 8, e custa US$ 20 para melhorá-lo com o loop de autoaperfeiçoamento. Vale mesmo a pena ou não?” Não tenho um número fixo, como “5% do orçamento do seu agent deve ser destinado ao loop de autoaperfeiçoamento”, ou algo assim. Acho que realmente depende.

51:53 Mas posso dizer que isso fica visível e disponível para vocês, e há várias formas de ajustar as configurações para deixar o custo um pouco menor ou maior, dependendo dos resultados que estão observando. Uma delas é a quantidade de context que vocês fornecem, certo? Quais skills estão incluindo, sem simplesmente gastar mais para fornecer informações que não ajudam de verdade. A outra é a questão do design das evals: com que frequência vocês as executam, a taxa de amostragem etc.

52:25 E outra coisa é que vocês podem usar esta parte da plataforma, mas tudo isso também pode ser acessado pela API. Então, se quiserem encaminhar isso para coding agents, cujo custo é subsidiado, ou algo assim, podem simplesmente exportar para um coding agent e fazer com que ele realize muitas das mesmas tarefas. Obrigado pelas perguntas maravilhosas. Estarei por aqui nos próximos três dias. Também temos o estande da Rise. Sintam-se à vontade para se inscrever. Experimentem este loop por conta própria. A inscrição é totalmente gratuita. O uso também é totalmente gratuito. E, sim, boa depuração.

52:57 >> [aplausos]

Transcrição original

[00:01] [music] >> Well, thank you guys for coming to the workshop. Really appreciate you. My name is Fouad Ali. I am a product manager at Arise. Arise is helps you guys build the self-improvement loop for your agents. Today today I’m going to be talking through what that loop is, how it gets built, and I’m going to be walking through a

[00:31] little bit of an example agent as well to kind of show how that agent works. Now we have an hour for this workshop. With that in mind, I know that workshops can be hectic, Wi-Fi can go out. So I have everything ready on my screen. I’ll be walking through it. It’s optional for you guys to follow along. Highly recommend you do. I personally learn a lot better when I have hands to the keyboard. But if you are having issues, don’t worry. And we also have Lori in the house who is more than happy to kind of help troubleshoot along as well. Sound good? Cool. So I’m Fouad, I work in product at

[01:02] Arise, and we work with a lot of agents. And I’m assuming you guys are all very familiar with what agents are and how they fail and how they are non-deterministic. And you know, this is sort of like a classic engineering problem that has reared its ugly head, you know, 10 times worse with agents because of the indeterminism, right? So when you have agents that can do a lot of things and have a lot of different ways of doing a lot of things, understanding their failure modes becomes trickier. And then add on to that the fact that

[01:34] there are thousands of these agents. Maybe I have internal agents. Maybe I have coding agents. You have marketing agents. And you have obviously customer-facing agents as well. And that all adds a ton of noise to the problem. And so how do you actually start to build to a loop where these agents use the feedback that you provide as a human being, customer feedback, and obviously actual evidence, so things like traces, um to inform how they can improve. Uh

[02:05] and that’s what I’ll be talking about today. Uh Signals are out-of-the-box version of this, which I’ll be showing heavily today. We have a managed agents platform that lets you kind of define on your own terms what these do. Um obviously data sets, evals, experiments, uh all that will be part of this as well. Uh but this is what we’re trying to solve, and uh apologies for the meme. Claude’s uh sense of humor is not that good, but um I think it illustrates the use case pretty well. Um in the previous world of software engineering, um your SRE would probably

[02:38] be in the first picture, right? So, classic situation, PagerDuty uh notification goes out 4:00 a.m. Your agent broke something in production. Um in this case, we’re we’re doing like a little, you know, uh shopping assistant, and shopping assistant is saying, “We sell zero board games to all your customers on production.” Not a situation you want to be in. Uh there have been worse use cases of agents as well, where uh I don’t know if you guys are familiar with what happened in Canada with a car dealership, where someone was able to get um

[03:09] a uh I think it was like a a Prius or something for like $5 uh through a chatbot. They obviously didn’t honor the sale, but that’s legal’s problem now. Um and so, these agents can fail in a number of different ways for a variety of reasons, and it becomes really important to try to move to a world where we’re in the after stage, where the agents can learn how to fix themselves and build that feedback loop into it. And I’ll talk a little bit about what where humans still add value in in that sort of world as well. So,

[03:39] this is what you’ll need to follow along. Again, like I said, this will be optional. I’ll be walking through the flow for you guys. Um we do have an hour. Um we can spend the rest of the time with questions. You can spend some of the time trying out the loop. Um I would recommend if you have some time I’ll I’ll put up here for you know 30 seconds ish to a minute. Um if you can sign up for a completely free Arise X account uh you’ll need a space ID and an API key which I can show you how to get. Um you’ll need some sort of coding

[04:09] um API or sorry um LLM API provider key OpenAI or Anthropic both work. Uh you’ll need Node and Python on your machine if you don’t have that don’t worry we’ll we’ll still talk you through it. Um Cloud Coder Chris will help kind of set this up for you as well. Um I assume none of you guys are strangers to those tools either. Uh and it’s very simple. So this is kind of the app we have. So it’s a chat base toy buying experience. It’s called Wonder Toys, right? Very simple. You can ask in the chat about different

[04:41] products that are available. You can chat to purchase. Um this is all running locally on my machine. So this is the agent that we’re going to be dealing with today. Uh we’re going to be walking through how we instrument it, how we set it up so that we can build that feedback loop. Um so I’ll pause here real quick. I’ll give you guys 30 seconds to try and do some of this again optional. I don’t want to you know block the entire workshop on API keys for sure. Cool. So really three things getting the

[05:13] repo running the actual app making sure you have an API key that actually powers the agent. Um so not uh a provider API key like OpenAI or Anthropic. Um then this this part here is about installing the skills that helps your coding agent work with our tools uh in a more kind of opinionated manner. Um Node and Python just to run the repo and that’s about it. Cool. I’m going to continue in the interest of time. So open question for you guys

[05:45] of these you know six Did I count that right? Five boxes. Five boxes. Which of these boxes would you classify your team is in? And, you know, the usually it starts from, “Okay, we are tracing what our agents are doing. So, we know when they fail, we know what tools they call. We can see the entire trace tree for the interaction points of the agent. Uh and that’s box one. Show of hands, does anyone have tracing for their agents right now?

[06:16] Cool. Okay, we got a bunch, actually. It’s good. Then the next stage of that is, “Okay, well, I know what what the agent is doing, but is it doing the right thing?” Um and how do I actually score and evaluate that? So, we call those evals in the industry, and so I would say, you know, some people probably are in that box. Are Are any of you guys evaluating your agents? You have evals running on traces? Okay, we got a couple. Okay, a lot. Yep. Then there’s someone reading the traces, presumably. Uh and that’s sort of what

[06:46] we’re trying to unlock here, right, with the agents. Um but realistically, if you have coding agents internally, there’s no way someone’s actually reading all these traces, right? Or, you know, a chatbot serving millions of customers, no one single human being is going to be able to read those traces, right? Then you actually want to be able to save those failures as tests, right? So, every time something fails, you capture that, and you’re able to use that as a regression test moving forward, so you don’t, you know, mess the same thing up

[07:18] twice. Um and then finally, you want to prove that you want to make the fix, and you want to prove that you actually fixed the thing, right? So, in those last three boxes, have you got anyone kind of in in there, in that stage where they’re actually Awesome. Cool. We got a couple. Cool. So, how do you actually thread all these things together, and how do you make this workflow as easy as possible, and, you know, have humans in that workflow in their highest value leverage points, but not necessarily reading tons of

[07:49] traces, right? Um the flow generally goes trace signal, which is our out-of-the-box kind of SRE agent, which I’ll show you guys in the platform. Signal then runs reads the traces, creates a data set off the failures, proposes an eval for you, automatically fixes what’s going wrong, and then runs an experiment that actually proves that that fix is um something that’s valid. And then you review that fix, you choose

[08:20] to merge that fix, and you go back into the loop. And every single one of these steps builds additional context as your agent continues to improve, continues to, you know, move into new use cases. Let’s say I want to add, you know, one-click checkout on this on this agent or something like that. Um that then feed not just your product roadmap, but your engineering reliability organization as well. So, uh this is kind of what we’ll talk through. I’ll walk through the loop. Uh I’ll show you a bit of the agent and its traces, signal reviewing the agents,

[08:52] the failure data set, the eval that we build off of that failure data set, fixing it, proving it with an experiment, what the agents did themselves, and what still needs a person, um and where you guys can add the most value, and then we’ll have some time for questions as well. So, Wonder Toys of the Shopping is assistant agent that we’re doing today. Uh it’s got a bug in it um that we planted for the purpose of this demo. Although, I hope you guys are not planting bugs in your own agents. Um it’s built with uh like I said, the repo

[09:22] has a bunch of different agent frameworks out there. Um Mostly Fast API, Next.js, Chroma DB, uh and then agent SDKs as well. Uh and it sends traces to Arize AX. It has a few tools available to it. Um and one of those tools, specifically the one with the bug, um, misfires a filter. And so, I’ll kind of show you at a base level what the tracing experience looks like. Um, we made it very, very easy for you to set up traces, so you’re not instrumenting

[09:53] things manually to get, you know, the information out of your agents. Uh, we have skills set up that wrap our CLI and our MCPs uh, that help you get started uh, with tracing. We have provider um, all the major providers uh, instrumented already with auto instrumenters uh, and all the major agent frameworks as well. It’s all open source, so very easy to get started with tracing. Sounds like a lot of you guys are familiar with tracing, and so you’ll be very familiar with what the trace tree looks like. Um, a user asks, “Show me toys for

[10:25] 9-year-olds.” Um, and that goes through an entire request path, right? So, the agent’s called, the agent calls a model, the agent has an end uh, LLM call. It has some tools available to it, whether it’s searching products, etc. Um, and you can kind of see all the information available um, to ask it what the agent’s doing under the hood. Uh, so all these attributes kind of show, you know, start time, end time, latency, what the input was, what metadata was passed, what stage in the in the graph it is,

[10:56] um, results that it fetches from the DB, uh, and what at every single one of these stages, what information is available to the agent. Uh, so this is valuable, but again, you probably don’t want to read this at 4:00 a.m. Um, I think it would be kind of tough to read through thousands of these at 4:00 a.m. just to find where an error lies. Um, so what we want to do is we want to enable agents to make use of this information, and then see how we can actually close that self-improvement loop.

[11:28] So, I kind of walked through the trace. If you want to instrument, the AX CLI is what we use. Um it has a guided setup. It’s very easy to get started with it. All you need is an API key from Rise and it will take care of translating all those nasty little attributes into the beautiful trace tree that you saw there. Uh you’ll get a span per tool call with arguments and results uh to the tool call. You’ll get model calls, prompt token counts, all all the basics that you need to actually monitor what’s going on. Um as well as grouping.

[11:58] So, you can see sessions uh where there’s multiple back and forth with a customer instead of just individual traces that are single back and forth with a customer. So, enter Signal which is sort of the second step in this platform, right? So, once you have these traces, what Signal does is Signal is an always-on agent that is able to read your traces on a schedule. Uh and you can configure this in the platform to be kind of like whatever schedule you want. Um by

[12:30] default, it’s uh set to every 6 hours. Uh you point it to a project that’s, you know, has live traces coming into it. Um you enable it and it reviews those traces and can then do a number of different actions via its skills, right? So, [clears throat] the base action that we’re going to show today is Signal connected to a repo on GitHub. So, this agent Signal is reading another agent’s traces. It’s reading the source code of that agent based on sort of what’s actually

[13:03] happening in production traces from that agent and the coding definition, it’s able to actually propose fixes to what you’re seeing. Uh so, I’ll show you guys what that looks like here real quick. So, we have this Wonder Toys agent. It’s publishing traces in. We can see all the user requests. You can see I did a lot right before uh this presentation at 1:00 p.m. We can see, you know, kind of base facts like latency, token count, cost uh of running this project. And you’ll see

[13:33] this signal tab. So, what Signal is doing is it’s clustering issues it finds with the traces and actually proposing and identifying um a fix for for these issues. Um so, for the purpose of this agent, the bug we planted uh is causing redundant search retries. And so, we’re see what Signal is seeing is that based on the traces that are coming into this project, we are uh causing three sequential LLM calls and high latency because of

[14:04] something that’s happening with the search products call, right? And specifically, what that’s happening what’s happening is that um the casing on some of these queries for the filtering is not working, right? So, what Signal does is instead of you getting paged at 4:00 a.m. uh if you remember the meme in the beginning of this presentation, um Signal’s finding this issue, analyzing, you know, clusters of these issues, writing an overview and analysis, writing a fix for you, and then what you

[14:35] can do is you can create evals to catch this issue moving forward automatically and trigger off those uh evals. So, you know, if we run into this issue at any point in the next, you know, 30 days, we automatically fire an alert and that gets triaged by our team immediately. You can add failure cases to the data set here as well. So, that you have a snapshot uh for future regression tests on exactly this failure mode. You’ll see a GitHub icon here as well to connect and open a PR or open issues

[15:08] well, so that you can actually get Signal to write a PR. I’ve actually already done that, and so you can see the PR attempts uh that Signal has done to fix this, right? So, I’m going to go click into the session. And the agent worked for 6 minutes, found the root cause within the coding repo as well, based on the traces, and found that product product categories are stored as lowercase hyphenated slugs, but the element is passing human-readable names

[15:40] with title case and spaces. Uh so, when someone is searching for car games, for example, without that normalization, we actually never get back any results. The agent is then going and searching every single product, right? So, you can imagine why that causes the latency spike up to 14 17 seconds. So, everyone following along so far? We have an agent, we have an issue. Signal is reading the traces for you, proposing a fix in connection with GitHub. Uh so,

[16:11] actually reading the the definition of this agent, uh and then doing some analysis for you, and kind of making sure that that’s available to you. So, this is one of many skills you can connect to Signal. Um you’ll see here on the manage agents platform, you have the ability to use one of our out-of-the-box templates, so Signal is reviewing your project traces on a schedule, clustering failures, suggesting fixes. We have a cost agent that can flag expensive models doing cheap work, recommend cheaper routing,

[16:43] and actually quantify your savings. Uh but, the interesting part is you can actually start from scratch. Um And so, what the agent studio allows you to do is you choose an agent config, you point it to a project where traces are coming in, you give it a task, and you can connect skills to it as well. So, like I mentioned, GitHub is one of those sources. Maybe you have um you know, a third-party system that holds your R back information that and you want to check permissions on this agent. You want to make sure what the agent is calling is actually within its permission boundaries. You can You can a

[17:15] skill to do that. You can connect a skill to uh another APM system like DataDog if there’s more logs you want to pull in. Um there’s really no limit to what skills you can define as long as you have an API key and it’s callable from the agent harness itself. Um and we’re actually under the hood running these as a Rise managed sandboxes uh within the platform. Uh you can bring your own harness, bring your own sandbox provider as well uh to kind of you know whether you’re using Modal, Daytona, E2B, whatever it is or whatever harness you’re using as well we

[17:45] support Codex, Cursor, Cloud Code, and Open Code with more harness support rolling out. So, does everyone kind of understand, you know, we have a managed agent doing this in the platform. You can set up your own automations to you know either be triggered on a time schedule or off of an alert. So, anytime you see latency spike above 10 seconds, we automatically kick off this agent to do an investigation. Um and investigation agents are part of it. Kind of solves the SRE use case. There’s a cost lens to

[18:17] this. There’s a product classification lens to this. Um there are many ways in which you can kind of use this agent platform to operate on your traces. Cool. Uh I will continue through these. So, Signals are reading your traces, filing what it finds. It keeps one ticket per problem uh the way a reviewer would. So, you’re not getting hundreds and hundreds of issues on the same uh piece of evidence. Uh it opens those. You fix it. You can either resolve it if you think it’s

[18:47] resolved, you can ignore it um and it will dedupe those issues moving forward so you don’t, you know, kind of get inundated with noise. Um the add to data set field or uh flow I think is one of the most important parts here because how do you build the actual continuous improvement? You have to have a record of what’s failed in the past and guard against those as regression checks moving forward, right? So, adding these two data sets give you that sort of living fixture quality. So, you know, you define test cases in code

[19:19] before you ship code. Everyone should be doing that, and hopefully we are all doing that with the help of some agents now. Um but this idea of living fixtures that change over time as you add new use cases, as you see new failure modes, is a pretty novel one and that kind of helps with the self-improvement uh loop where, you know, you’re not beholden to one definition at one time of what has failed and what our failure modes, but you’re organically growing that definition of failure mode as your agent

[19:50] is failing in production, right? So, um think of it like, you know, every time you go to try and ride a bike, you notice something about how you’re riding, and then over time, those become so ingrained in your memory that riding a bike feels like nothing. You don’t even think about the failure modes of um I actually fell off a bike and broke my foot 2 months ago, which is why I’m mentioning this this little anecdote, but typically you don’t think about, you know, putting your left foot on left pedal anymore because it’s been so ingrained into your learning process. And that’s what we’re trying to kind of

[20:20] accomplish with these agents. Um so, on the data set side, once you get these living fixtures, you actually want to codify the behavior on these fixtures, right? And that’s where the eval comes in. Um so, I saw a few show of hands of that people are running evals. Uh can I get a quick gauge of the room? Who here is running LLM as a judge evals or you’re running code evaluators? Cool. So, if you were in any of the earlier workshops of the Rise, we went into evaluators in great depth. Um there are

[20:51] many, many different forms of evaluators. Um so, just quick quick overview. There are code checks that are, you know, really, really cheap to run that are for deterministic checks, right? Is this field present? Is this valid JSON? Exact rules. Was this filter applied? Was this tool called with the right arguments? >> [clears throat] >> Very, very easy for that, right? >> [snorts] >> LLM as a judge, evals also help with this use case where you need to have more of a qualitative or nebulous kind

[21:22] of analysis of the trace, right? And so, this is using another LLM model to score the results of one model’s trace. Um obviously costs will be higher here because you’re making another model call. Um per record, obviously you can, you know, kind of set your own sampling, filtering. You don’t have to run these on 100% of the traces that you’re running at. Um there’s some trade-offs in terms of eval design that we can discuss, but that’s sort of what an LLM as a judge is for. Then you have

[21:53] for the even more open-ended use cases, you have this concept of agent as a judge. So, where you’re not actually sure what you’re evaluating, you have a goal in mind, um and you leave kind of the the determination of whether that goal has been achieved to the agent. So, the agent can actually pick its own rails, it can actually pick its own scores, it can go through that process itself. And that’s obviously the highest cost method because there’s multiple LLM calls happening under the hood. Um [snorts and clears throat]

[22:23] decision models have been around for, you know, what? A month-ish now, and with Lower actually at Arize has published a ton of material on sort of benchmarking them and how they operate, and what trade-offs are present with decision models. I will say they are a very, very cheap way to run some of these checks on your traces versus um using a classic LLM. Um and they give you, you know, type type choices, yes, no, choice, score.

[22:56] So, once you have sort of this eval signal, right? So, you you understand, you know, qualitatively is this in the right direction? Is it not in the right direction? Is it passing my eval checks? And you have the trace data. That’s all really rich context for a coding agent to go um implement a fix, right? So, signal in this case is is running on on an Auri managed sandbox with a coding harness, implement those fixes for you, but

[23:26] if you’re in your development phase, you can actually pull these traces live into Auri through the CLI as well, right? So, it’s instant context to feed other agents to actually work on those PRs for you. Um and this is where we have kind of the human check and balance in in the room. Um so, I would say the the places a human adds the most value here are one, obviously validating the fix, right? Reading the PR. There are, you know, maybe some of us in the camp of we don’t want to validate

[23:58] every human PR. I assume if you’re in a high-stakes use case like finance, you’re very much in the camp that humans read the PR before the merge, right? So, that’s one very high-leverage point for a human to be here. In the data set curation phase as well, so adding that to a data set is part of why we left it manual is are these good enough findings to add to my fixture, right? So, that’s a manual step in the process, uh and that relies on kind of human judgment as well. Um the eval design, so we have agents that kind of help you write these evals, um but the eval

[24:29] design portion is something where humans can definitely be in the mix because you’re imparting your taste of what is good onto the agent, whether that’s in the form of an LLM as a judge or a more deterministic check. Um and then folding all this information into the coding agent gives it really rich context for it to work from. Um so, just as an example of kind of like how you would create an eval off this, I’m going to go to my traces tab. I’m working off of this Wonder Toys project. I have signal running and signals found

[25:00] two issues so far. One is the orphan spans issue, um, which was actually just my mistake instrumenting this. Uh, but it did catch it. Um, and two is the redundant search retries. That’s the bug we planted. Um, so I’m able to create a new evaluator with one click off of this. And that actually, uh, looks like I need to use a different model. That actually opens up Alex, uh, which

[25:31] is our in-house agent that I’m doing a talk about tomorrow, um, that is able to go and create that eval off of that evidence for me, right? So, based on the traces that are supported in the evidence here, we can kind of codify in a prompt template what we should be expecting moving forward and how we how we make sure that the eval fires and fails on any mistakes that are made. >> [snorts] >> So, this is the eval I came up with. You’re a helpful AI bot that checks for redundant search product retries, inspect the complete trajectory

[26:01] including tool calls, see if there’s any unnecessary tool call, return a redundant retry when search product is called more than once, um, and put the score and classification choice on the trace itself. And then you can run this eval on incoming traces that are coming into your project, so you make sure you catch that, you can monitor that, you can graph that, you can create an alert off of that, uh, and you can track spend associated with that eval as well. So, over time, you know, maybe your development flow has codified this

[26:32] as a regression check and you no longer need to deploy this eval on production data. You don’t want to spend the model tokens on running this on every trace. You can actually view the cost over time and retire that eval as well. Cool. So, the next part of this is okay, we have a fix. Signal found something. It analyzed the repo. We created an eval to catch it for the next time. We added the evidence to a data set. So, now we

[27:04] have a living fixture that’s growing with time. How do we know that the fix is right? How do we actually know that, you know, it wasn’t just slop code that the agent produced and tried to find an issue that didn’t actually exist? Um and this is where the world of agent experimentation comes into play. And this is a very, very rich and deep world. Um so, I won’t spend, you know, time talking about all the different frameworks and providers that exist out there. Phoenix team did a good job earlier today talking a little bit about the harbor integration they have in Phoenix. Uh but really what we’re concerned about is prove that the

[27:36] fix works and prove we didn’t break anything else, right? Um and there are many cases where, you know, in this non-deterministic world, if you make a small change to a system prompt, it can then have ramifications on other tools that you didn’t think were going to break. Uh and, you know, kind of um redundancy issues there. Um and so, making sure that we can prove that this fix actually worked and that nothing else broke is really, really important. And that’s kind of the experimentation stage. Um

[28:07] so, I will talk a little bit about this through the flow as well. So, in the Rise, we support a bunch of different types of experiments. Um this is the category code enum fix experiment that I just ran. And so, you’ll see here that we have actual evals running on this experiment. So, what we’re essentially doing is we have this living fixture of failure cases. We have this proposed fix. We

[28:38] actually want to rerun the agent on these failure cases and score the results. And if they meet a certain um threshold, that’s kind of up to you to define. In my case, 88.9% I thought was pretty good. So, I was like, ship it. Um if they meet that threshold, you actually have results to prove that fix from the agent, right? And the agent can actually run these tests for you through the AX CLI as well. So, as Signal is going and finding these failure cases, and it has access

[29:08] to the agent code, it can actually pipe those failure cases through and replay them through the agent with the version two fix, and then score those results themselves, right? So, you come back in the morning, you weren’t working up at 4:00 a.m. You not only have a PR that has a proposed fix, you have some validation results that say, “Hey, I proved this fix because I actually took the test cases that we failed on, and I re-measured latency or tool call retries, and I saw that we were no

[29:39] longer retrying tools, and latency was lower. And hey, by the way, you had three other evals that you don’t want to fail on, either. So, I made sure to check that those evals are not regressing, right? And so, as that living fixture grows over time, you have new cases, these experiments become more and more robust, right? Um and in the platform, obviously, you can go view those experiment results, see what the output is, see what the evals are. If you disagree with the agent, you can annotate that output, and that becomes another piece of information to the

[30:09] context for the next run, right? So, everyone kind of clear on this experiment flow at a high level, like how you can run some of these experiments to take a test case, take an eval that you’ve created as a benchmark, and actually validate your fix before it goes out, before it goes to prod. Um and you can shove this into the CI/CD process as well. Um up to you on how you want to configure it. Obviously, running the the agent may be expensive. Um so, your discretion on how you want to run that.

[30:40] Evals as well, right? If you’re using an LM as a judge eval, you want to be careful about which model you’re picking, when you’re running those evals, what sampling rate you’re running those evals at, to make sure you’re not just ballooning costs and you know, just sending a ton of spend on validating these fixes on every push. Cool. So, kind of continuing on, we approve the fix, we look at the task completion rates. Um we validate those results and while

[31:14] you kind of step away from this process, what keeps running is that the eval that you created runs on every new trace and becomes additional context to the next signal run. The task system that we have in arise can also automatically add failed eval results to new databases or data sets so that that fixture grows over time. And signal keeps rerunning every 6 hours or off of an alert or off of a triggered monitor and make sure that new failures are surfaced, new evals are

[31:47] created and that data set grows with those new examples over time. We also have, you know, weekly digests where you can kind of consume these in a little bit more of an easy-to-read result where you just have a summary of what’s going on with the agent. What is waiting for you is confirming that these issues are real, right? You can’t just trust every single issue that comes out of this agent. I would say use it as a starting point, validate these fixes and use your judgment on when those issues are actually real. Writing down what the right answer looks

[32:18] like, so this kind of goes in the annotation flow, right? You run the experiment, you get a new output, maybe you don’t think this is the perfect answer or the perfect trajectory for the agent and you can actually use the annotations product to kind of codify that taste. Merging the fix, this is up to you. You can auto merge these PRs. I will leave that to your discretion. Uh and then actually deploying and promoting the new version, right? So, I have V2, I validated it, I think the issue is real, I created the eval, I looked at the score, I validated the fix, I like the code, I reviewed the

[32:48] code. Now it’s time for me to actually upgrade the agent. Um I think the the other thing that’s really interesting about this is like you can codify the confidence scores, especially with these decision one models that actually return an explicit confidence score, and have those auto route to human beings uh in annotation queues, right? So, um not only are you, you know, responsible for reviewing the outputs, but you actually get a ready-made queue

[33:19] for you that is based on all the low confidence results, and um you know, in some of our benchmarking uh we’ve seen these confidence scores to be pretty good. It depends on your use case and uh specifics in the industry, for sure. Uh so, I wouldn’t say that an 80% confidence score is the right threshold for everyone, uh but setting those thresholds is important, and then once you have those thresholds defined, you can kind of auto route those low confidence cases to a person to go annotate. Um

[33:49] So, I mean, there’s, you know, in the spam test that we saw, 4.6 % of cases scored between 0.3 and 0.7 confidence to people, left the rest at 99.5% accuracy, right? So, that is one example of an industry where, you know, specifically for spam detection, where those confidence thresholds might be more defined. It It depends on the use case, for sure. Um So, I kind of talked about some of the stuff we’ve built so far with signal

[34:21] manage agents and traces, right? So, the ability to actually read those traces at scale, the ability to add things to data sets, uh the ability to run those experiments with the help of a coding agent, um, and actually review those results in line. You can also interrupt sessions. You can look through the model’s reasoning. You can kind of continue a session, kick it off to a local agent, uh, so that you can continue development on your own side if you don’t want this all managed by a rise. But, I think our vision for the future is this running this full end-to-end loop

[34:53] with almost zero human involvement until you need to go test something, right? Until you need to go click around in a UI and validate something. Um, and so there are a lot of providers out there for that experimentation setup, right? There’s the harbors of the world. There’s many, many different ways that you can test the agent. Um, I think most of it, and and this is where a lot of the discussion is happening, is how many dependencies do you have to run to run this agent, right? Um, running an agent in the experimental phase, does that mean you connect it to a mock DB?

[35:23] Do you stop some tools? Um, do you actually run the entire thing in a docker image? Can you even do that safely? Um, those are all sort of questions that I would encourage you guys to think about as you start thinking about this experimentation flow. With this agent, you know, it’s very simple. We just rerun the agent in its entirety. There are no dependencies. It spins up its own DB, and then we run requests through that. So, that might be a very simple use case. But, when you have external dependencies that really matter, your

[35:53] use case become can become bit more convoluted. Um, so our goal for this is really enabling the one click from issue to experiment. Hey, I have this proposed fix. Go test it. Spin up all the infrastructure necessary to go test it. Um, in addition to this, and we’ve we’ve worked on the CLI around this, is connecting signal where you work as well. So, whether that’s in Slack, so tagging uh, from Slack to communicate with signal, whether that’s your local agents, which we have through the API, CLI, and skills, where you can actually

[36:25] ask your local agent to go do a digest of what signal is finding and and check those. Um making sure that we have the fix drafted straight from the issue and its traces and that’s part of what we’ve done already and actually having the evidence in line. So, here are the actual five traces that failed in the PR description so you can actually go validate those. Um we have signal now proposing evals as well for you so it’ll actually check your evals see which ones are healthy as in, you know, if this eval is passing

[36:57] 99.999% of the time maybe we don’t want to spend the tokens on this eval and so we can retire this eval going forward. Uh we feel pretty confident on it. Or, you know, vice versa if any eval is in poor health, making that eval more robust. And we have a whole process on eval alignment which is how do I make sure the judge is actually aligned to what I think and isn’t just outputting scores that I don’t believe in. Um so there’s a whole process for doing that. And then, again, the experimentation flow, running your agent against running

[37:29] these data sets against your agent wherever it lives. Uh whether it’s your laptop, in my case for this very simple agent, or whether it’s on more complicated infrastructure. Cool. So, I think it would be really great to get started with some of these. Uh so I have the workshop repo URL. Um we have docs pages as well for agent experimentation. And um we have a few other talks throughout this week as well. Um

[37:59] So, if you has one tomorrow at 3:20 about um agent fixes and their run-off um implications. So, you know, you fix something somewhere and that eventually has impact downstream. Um and I have a talk tomorrow at 3:45 talking about Alex which is our in-house agent. Um and we use Alex to build Alex so it’s all kind of the perfect dog fooding tool for us in the agent space. So, I’ll talk a little bit about how we designed that agent, you know, how we design context, memory, and some of the decisions and

[38:31] lessons we learned along the way. Really, I would encourage you guys to try to get some traces from the agent. We have this built out for you, but if you have an your own example and you haven’t traced your agent yet, it’s very, very simple to install our skills and CLI, have it instrument your agent for you, and send those traces to Arize. Um once you get those traces in, it’s one click to enable signal, and then you can start to see the clustering of issues and patterns across your traces as well. Um

[39:02] so, yeah. I would say the things I want to leave you guys with are the hard work of reading a ton of data should definitely be just be done by an agent. Understanding where to add the highest leverage human points is kind of the theme of this presentation. Just because you can automate something doesn’t mean it should be automated, but you should use that automation to really inform the reviewer. So, things like auto routing low confidence threshold scores to that reviewer queue are really

[39:34] important. Um and making sure that all the context is fed back to the same system, and obviously we’re here with Arize, and you know, we’re telling you how great Arize is, but really I you want to make sure that this context is recorded somewhere, right? And that’s the only way you build the self-improvement loop is when the human judgment, the eval scores, and the traces, and the the trace evidence are all held together in the same place feeding that context for the next run, so you’re catching new issues instead of

[40:04] just fighting to stay afloat. Um and that’s what I have for you guys. Thank you so much. Um I’m happy to walk around and kind of help you guys get started on some of these. Um you can check out the repo, clone down the agent. If not, uh we you can install the skills, instrument your own agent, and yeah, I can take questions as well if you would like. I would say there’s like two lenses to take how we’re actually evaluating. There’s how do we evaluate signal as a product line, and that one of the key factors there would be, okay, how often is this right about our PRs, right?

[40:34] That’s sort of like an internal evaluation. Do you mean more of that how we evaluate our own product or how you can evaluate an an agent use case, generally speaking? Uh we will do a whole talk about evals for Alex tomorrow, but to give you the long and short of it, um eval design is you know, as an as an AIPM, I think that’s probably my primary job is like how do I actually design good evals that actually measure the right things? The shorter answer to that question is

[41:05] I think codifying qualitative decisions is very hard. Codifying things like latency, retry count, like these are more classical issues that, for example, the issue signal found, I think, is relatively simple, like you found an inconsistency in casing, you saw evidence in retries, make the fix, measure the latency. That’s really easy to do, right? Now, qualitative outcomes, I think, are a little bit harder, and I would say there’s there’s a couple things to index on there. One is

[41:36] the the actual like definition of what is good is only emergent from as much signal as you can give it, and I use signal as like the word signal. Um so what I mean by that is, okay, I can look at one example and say it’s right or wrong. I can’t get an agent to learn from one example because then it’s just going to overfit to that one example, or that example might not generalize properly. Um and so part of what I was talking about with the living fixtures and the annotations is a lot of what we do. So I’ll give you an example, Alex generating um filter queries, right? So

[42:09] we have Alex in in platform. Uh we have a flow where, okay, if you want to search agents or search traces, you can obviously type in a filter, or you can ask Alex to filter with AI. How do we actually measure the performance of that? There’s no right or wrong answer, cuz it could return a filter that succeeds, and it doesn’t, you know, parse this JSON, and it will give you some results, but how do you know that’s actually a good result? So, there’s a few things. One, we look at the entire session of users, right? So, we’re not just saying, “Okay,

[42:40] for this turn, was this a good response?” But, did that user ask again? Did it Was it happy with the results? How many additional filters did they create, right? So, that can be one thing to as a signal for you to evaluate on. The second is, I mean, annotations like reading through, okay, what was the query? Does this look like a right filter? Did it return the right eval results? And actually annotating that by hand as a PM who knows what to expect. Um, and then you combine both of those with new use cases, and that

[43:10] rich context becomes the eval template, right? So, you can actually use another coding agent to feed that context in and write a really good prompt template, and then it becomes like a a prompt optimization essentially, right? So, like, how good can I get this eval template on the lowest cost model so I can run this at scale? Um, so, that’s kind of how we think about it. We have some more specifics to talk tomorrow where I’ll talk through a little bit of which models we choose, and um, how we think about which use cases are worth running an eval on or not. Um, but yeah,

[43:41] that’s the short answer. So, it is kind of like a, you know, post hoc algo propter hoc, like, where can we make sure like what we define as healthy is actually healthy, and where should we define where it breaks? So, So, what I mean by that is, okay, it’s right 99.9% of the time. If that 0.1% is catastrophic, and we need to catch all of those, it’s a very different discussion, right? And then evals, when I when I say like Evals there’s kind of two lenses. There’s the Evals that you can run in the

[44:12] development flow as CICD checks, as regression checks before you deploy code. There’s Evals that you’re running on live traces, which that becomes a cost-benefit ratio question, right? If I’m running this on 100% of live traces is the cost of running this model on all my traces worth it compared to the cost of this 0.1% failure, right? So I think a lot of it boils down to ROI. I think general guidelines are whatever you can catch in CICD you should, and I

[44:43] understand it’s a challenge to run some of these. So like and and convince teams to run some of these in CICD I would probably make some of these non-optional checks in the CICD process, right? So you have a data set of fixtures that shows where this Eval has actually failed on the 0.1% of cases and you run you rerun those with an Eval score every single time you push or before a PR is merged. So you’re at least you at least have some confidence that that set of cases is not going to fail. And then you run an Eval that has a sampling rate on your prod traces,

[45:15] right? Um so instead of saying, “Okay, we’re going to ignore the development process, evaluate everything that comes in production.” That can be a very high cost thing to do versus “Okay, we ignore prod completely and only test in development and try to capture every case, which you probably can’t do um in a data set with coverage, and then just let it happen in prod.” I would say both of those are extremes, and the answer is somewhere in the middle. And it depends a bit on the ROI of the Eval, right? Um and what model

[45:45] you decide to use has an implication on cost, etc., etc. It’s a very good question, and it gets very meta, and uh I I hope I hope you haven’t noticed how meta this conversation has gotten so far where I’m using signal in multiple different ways. Um the short answer is you can do that entire loop again, right? So, we have a project for eval traces. This is a Rise created. These are all the evals, and those evals are traced, right? And you you can have an agent reading the eval traces and making sure

[46:15] the evals are good. And then, each of those agents actually produces their own traces, right? So, when you’re running Signal, these are Signal’s traces. So, you’ll see here you are Signal, an automated reviewer for Rise. These are these are steps you have to do. These are the instructions. This is what Signal actually called under the hood. So, made a few bash calls. It called our MC internal MCP to go do this investigation and then mits it, writes it as an issue, right? And then, you can run Signal on top of Signal as well to make sure that And that’s kind of what

[46:46] how we evaluate internally, right? Uh, it’s kind of what I was alluding to as the the ultimate dog fooding tool. Um, now I I assume your question is more of like a when does this break down? When is this useful to do? Um, I think the harness changes are useful up to a certain point, and I’ll talk a little bit about this in in my talk tomorrow on like how we evaluate Alex. So, like there are certain use cases where you just a- after a certain point, you don’t need

[47:17] to continue evaluating, uh, and there’s just diminishing returns on cost from there. Um, where we’ve seen it is, you know, we monitor Signal and we have, you know, traces coming in from Signal. We have some evaluation score criteria, but there is a certain point at which we actually don’t know what is good for our customer beyond what the customer knows themselves. Um, so, I mean, you can turn on Signal and it can propose the PR, and we can use some proxy metrics like merge rate on the PR, or the session transcript or whether

[47:47] session was handed off or whether data set was created or eval was created as feedback mechanisms, but beyond that and beyond that and the merge rate of the PR, we can’t really tell that much more. So, it becomes, you know, diminishing returns to continue to evaluate from there. Um cuz then you’re just kind of relying on an agent transcript and you have no ground truth, right? You’re just vibing with the agent’s output and pretending you’re increasing shareholder value, right? So, um I don’t think that’s useful. Uh but I think

[48:18] we have, to answer your question, we have used signal to evaluate signal as well. I think in execution time checks, because such low latencies like probably the most exciting, like where you can actually route a request during execution time. So, these these evals that you’re seeing are are, you know, post talk where the the agent has already run and we’re evaluating it from that. So, due to the low latency of decision wall models, I think that’s something I’m actually genuinely excited for uh in the execution loop. Um

[48:48] Like selfishly, or maybe not even selfishly, but like for my personal enjoyment, I like that people are much more likely to use evals now because they’re cheaper. Um so, that’s like just, you know, purely good for the ecosystem health. Uh like more people thinking about evals, more people thinking about actually classifying their traces. I think it’ll unlock that to a large degree just because it’s cheaper. Um And then, maybe not related to to this talk, but like just my my personal opinion is I think like um because these models are so small

[49:20] that there’s some really interesting stuff you can do with on-device stuff um that I’m really, really excited for. Um we’re also like kind of pioneering it for some multimodal evals as well. Um because I think multimodal evals can be really complicated because of latency. Um and they can also be super, super qualitative. So, in the multimodal eval space, like trusting an agent’s taste on an image that was generated, for example, or how it interpreted a click box can be very hard, but getting confidence scores allows you to at least

[49:50] route this to human a lot faster, so I think that’s also a space where decision models will help a lot. Yes, 100%. So, I kind of briefly alluded to this when I talked about skills, but you can actually create your own agents. Um And we have the out-of-the-box signal agent, obviously. Um Let me do this one. So, you’ll see here we have a DataDog skill as well where you can pull up

[50:22] metrics, logs, and APM traces around the alert. Um we have a bunch of providers available for you to do that as well. You can also write your own skills, so the the agent is doesn’t just have access to the agent traces, but downstream system application metrics as well. Um so, you can connect it to basically any data source. Um Obviously, there’s like an element of taste to the data source like connect the ones that you need to connect, make sure it has the right access, make sure, you know, the scope key, make sure that you’re not over

[50:52] flooding context because more isn’t always better to actually triage the alert. Um but yeah, we have the ability to do all that as well. The the shitty answer that everyone always gives is it depends, but it it does kind of depend. So, for example, like what harness are you using? Um what underlying providers are you using? How often are you running this? And we expose those as configurations. We allow you to kind of monitor the cost, too, so you’ll see here that this is the signal traces. This is how much it’s Oh, I guess this is still flowing in right now, but the

[51:22] same way that you can view kind of your cost for like Wonder Toys, you can view the cost of signal. Um so, we make it easy for you to understand the ROI like, okay, if this shopping assistant agent cost me $8, and it cost me 20 bucks to improve with the self-improvement loop, is that really worth doing or not? Um Now, like I don’t have like a hard number as like 5% of your agent budget should be allocated to the self-improvement loop or something like that. I think it really just depends. Um

[51:53] but I will say like that is exposed to you and available to you and there many ways in which you can kind of pull the levers to make that a little bit cheaper or more expensive depending on how you’re seeing results. Um so one is the amount of context you’re providing, right? So which skills are you including up to a certain point without like just spending more money to give it more information that doesn’t actually help. Um and then the other is like the eval kind of design question, how often you’re running these evals, sampling rate, etc. Um

[52:25] And then the other thing is like you I mean you can use this part of the platform, but all these are consumable via API as well. So if you want to shunt this to coding agents, which you get a subsidized cost for or something like that, you can just export that to a coding agent and have it do many many of the similar things. Thank you for the wonderful questions. I’ll be around over the next 3 days. We have the Rise booth as well. Um feel free to sign up. Try this loop out for yourself. Completely free to sign up. Completely free to use. Um and yeah, happy debugging.

[52:57] >> [applause]