Como escrever sua primeira eval de IA — SallyAnn DeLucia, Arize AI

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: How to Write Your First AI Eval - SallyAnn DeLucia, Arize AI · Canal: AI Engineer · 35:00 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de prompts e contexto

Resumo

SallyAnn DeLucia apresenta evals como sinais essenciais para medir o desempenho de agentes de IA e detectar regressões que avaliações subjetivas não revelam. Ela explica como observar traces, definir critérios concretos de sucesso e escolher uma dimensão por eval. Em seguida, demonstra como selecionar dados, criar um prompt de avaliação com LLM as a judge e iterar sobre os resultados no Arize. Ao final, recomenda começar com um conjunto pequeno de exemplos e envolver diferentes stakeholders na definição de qualidade.

Pontos-chave

Avaliações subjetivas não permitem detectar regressões nem comparar objetivamente prompts e versões de modelos.
Traces mostram as etapas e unidades de trabalho de um agente; evals testam se ele teve o desempenho esperado.
Uma eval de software tradicional costuma esperar uma saída única, enquanto agentes podem ter muitas respostas válidas.
Critérios de sucesso devem ser concretos e específicos para o caso de uso, em vez de termos vagos como “útil” ou “preciso”.
Para LLM as a judge, é boa prática avaliar uma qualidade por eval e acrescentar critérios ao longo do tempo.
Os exemplos usados na avaliação devem ser selecionados dos traces e organizados em um dataset.
Testar e ajustar o prompt da eval no playground ajuda a verificar se os resultados e as explicações fazem sentido.
Alinhar os resultados da eval com anotações humanas e executar evals continuamente em produção são etapas importantes.
Métricas indicam que algo pode estar errado; evals ajudam a identificar o modo de falha.
Começar com cerca de 20 traces, uma dimensão e um judge é uma forma prática de iniciar.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação e objetivos do workshop	SallyAnn DeLucia apresenta sua experiência com evals e explica que o workshop abordará critérios, dados e a criação de um judge.
04:09	Traces e tipos de eval	A palestrante mostra como traces registram as etapas de um agente e apresenta diferentes formas de avaliação.
07:12	Configuração da plataforma	Os participantes acessam o Arize, configuram um provedor de LLM e abrem o projeto de demonstração.
10:22	Exploração dos dados do agente de viagens	O grupo analisa solicitações, respostas e traces do agente para identificar possíveis critérios de avaliação.
13:25	Como ler um trace	A palestrante explica spans, chamadas de ferramentas e a organização dos passos em um sistema multiagente.
19:05	Definição de critérios concretos	O workshop distingue critérios vagos de critérios específicos e recomenda avaliar uma qualidade por eval.
22:09	Escrita dos critérios	Os participantes descrevem a tarefa, as condições de sucesso e falha e os sinais que a eval deve julgar.
25:13	Seleção de traces e criação do dataset	A demonstração mostra como filtrar spans relevantes e adicioná-los a um dataset para avaliação.
27:16	Criação e teste do judge no playground	A palestrante transforma os critérios em um prompt, mapeia os dados e testa os resultados da eval.
31:54	Iteração e próximos passos	A palestra aborda ferramentas de apoio, alinhamento com feedback humano, evals contínuas e colaboração entre stakeholders.
34:30	Recomendações finais e recursos	SallyAnn recomenda começar pequeno, comparar abordagens de avaliação e consultar os recursos da Arize.

Citações

Não há como provar se algo foi corrigido ou se está falhando; só temos impressões subjetivas. — 02:04

Traces são os logs para IA; evals são testes. — 03:38

Em vez de dizer apenas “útil” ou “preciso”, seja mais específico. — 19:35

Uma métrica indica que algo pode estar quebrado, mas evals dizem qual é o modo de falha. — 33:59

Conceitos e entidades

SallyAnn DeLucia (pessoa): Head of product na Arize e apresentadora do workshop sobre como escrever evals.
Arize AI (empresa): Empresa cuja plataforma é usada no workshop para observar traces e criar evals.
Alex (ferramenta): Agente de IA da Arize que pode ajudar a criar e iterar evals.
eval (conceito): Avaliação que testa uma dimensão do desempenho de um agente com critérios definidos.
trace (conceito): Registro das etapas realizadas por um agente para responder a uma solicitação.
LLM as a judge (conceito): Abordagem que usa um LLM secundário para avaliar um aspecto da saída de um agente.
decision model (conceito): Modelo que responde a uma pergunta de avaliação com uma probabilidade ou um rótulo, sem fornecer explicação.
unit test (conceito): Teste tradicional de software que costuma verificar uma entrada contra uma saída esperada.
Arize AI (ferramenta): Plataforma usada na demonstração para explorar traces, criar datasets e testar evals.

Tradução completa (pt-BR)

00:01 [música] >> Antes de começarmos, eu queria me apresentar. Sou Sally Ann e sou chefe de produto na Arize. Estou na Arize há cerca de 4 anos. Um dos primeiros projetos pelos quais fui responsável foi integrar nosso AI agent Alex à nossa plataforma. Então, já trabalho com evals há algum tempo e também participei da criação de muitos dos nossos produtos de evals. Acho que a maneira como eu

00:32 penso em evals é que elas são nosso principal sinal sobre nossos agents. E isso inclui todas as nossas evals na Arize. Então, meu objetivo para hoje é que vocês saiam daqui com três coisas. Uma definição clara do que é uma eval e do que não é. A capacidade de escrever seus próprios critérios. Espero conseguir apresentar uma pequena receita de como pensar em evals e aplicá-las a qualquer cenário real dos seus agents. E depois vamos criar uma judge funcional na Arize. Vou mostrar um pouco do ciclo de vida e como pensar em melhorar suas evals ao longo do tempo. Então, esta é um pouco da nossa agenda. Vou dar um pouco de contexto. Não quero passar muito tempo nos slides, mas quero garantir que todos tenham uma base bem sólida sobre o que é uma eval e como pensar nela. Vamos explorar alguns dados na Arize juntos, escrever nossos critérios e depois criar nossa eval. Essa é a parte principal do nosso workshop de hoje. E depois vou dar algumas ideias do que vocês podem fazer a seguir. Adoro ter sessões de trabalho para que as pessoas possam colaborar. Vou tentar circular pela sala e ajudar o pessoal. Depois, vou mostrar uma página resumida no Notion que vocês também podem abrir e acompanhar. Então, só para ter uma ideia de quem está na sala: quem aqui já lançou um chatbot ou um agent, já escreveu uma eval ou sequer abriu o produto da Arize hoje? Alguém? Certo, temos algumas pessoas aqui. Acho que isso vai ser ótimo para quem talvez ainda não tenha feito nada disso e, mesmo que você já tenha, acho que hoje

01:03 vai ser bastante útil. Então, vou começar dando contexto sobre por que não acho que avaliações subjetivas escalem. Este é o problema das impressões, como eu o vejo. Na segunda-feira, talvez você mude algo no prompt e faça o deploy. No geral, parece melhor. Você não tem como saber de verdade, mas, no geral, as coisas parecem estar indo bem. Na terça-feira, você faz o deploy e, uma semana depois, aquele caso de uso para o qual você lançou uma correção está quebrado. Na semana seguinte, conforme o problema continua piorando, ninguém consegue provar

01:33 se algo foi corrigido ou se está mesmo falhando. Só temos as impressões para nos guiar. Sem evals, você não consegue detectar regressões quando muda um prompt. Não consegue comparar objetivamente prompts ou mesmo versões diferentes de modelos. Não sabe se um modelo novo é melhor para o seu caso de uso e não consegue incluir critérios formais de qualidade na CI enquanto faz o deploy do seu agent. Então, sem evals, dá para imaginar que é bem difícil saber como seu agent está

02:04 se saindo. Uma pergunta que recebo com frequência é: uma eval é só um teste unitário? Acho que há muitas comparações entre evals de IA e testes de software tradicionais, mas acredito que sejam um pouco diferentes. Primeiro, em um teste, você geralmente tem uma entrada e uma saída correta. Você também consegue ler toda a lógica no código. Com um agent de IA, na verdade, não é possível ler essa lógica. Ela só aparece depois, na forma de rastros. Por isso, você precisa de uma eval de IA em que possa analisar, por exemplo, o itinerário dia a dia neste exemplo de planejador de viagens, a divisão do orçamento ou vários critérios.

02:34 Basicamente, há muitas saídas válidas, então não dá para usar um teste unitário mais tradicional como se faz com software. Gosto de pensar nisso assim: os rastros são os logs da IA; as evals são testes propriamente ditos. E sempre digo que… eu tinha um meme, não o incluí hoje, mas a verdade difícil de aceitar é que você precisa de rastros, precisa de observabilidade para realmente fazer suas evals.

03:06 Este é um exemplo de por que os agents tornam isso mais difícil. É só um exemplo do que um rastro pode parecer. Para quem talvez não conheça o termo, um rastro é basicamente todas as etapas que um agent de IA executou para chegar a uma resposta. O usuário diz algo e, em todos esses spans que estou mostrando aqui, estão as etapas individuais que o agent executou para chegar à resposta. Neste exemplo, há um agent de pesquisa que vai fazer uma pesquisa e talvez até fazer algumas chamadas de ferramentas. Há também seu agent local, que talvez recupere algo de uma base de conhecimento. Então, há muita troca de informações. É aqui que dá para ver a lógica do seu agent. Vamos explorar alguns rastros na interface da Arize. Como podem ver, há muitas chamadas de LLM e muitas coisas combinadas. Dá para imaginar que um único teste unitário, como no software, não vai capturar com precisão toda

03:38 a complexidade de um agent nem nos dizer como ele está se saindo. Existem muitos tipos diferentes de evals. Hoje, vamos nos concentrar em LLM as a judge. Nesse método, usamos um segundo LLM e pedimos que avalie algum aspecto do nosso agent. Pode ser, por exemplo, QA, sumarização ou relevância. Depois, recebemos um rótulo e uma explicação. As explicações são muito úteis. Elas são como o raciocínio por trás da atribuição de um rótulo. Isso

04:09 ajuda a entender um pouco melhor, em vez de ter que aceitar o rótulo sem questionar. Mas há muitos tipos diferentes de evals. Quero destacar os decision models. Isso é algo relativamente novo. Se alguém participou ou acompanhou a onda de “Jevas a Job” que aconteceu há cerca de 2 semanas, a OpenAI lançou sua API de decision model na semana passada. Acho que os decision models vão ser uma parte enorme das evals no futuro. Eles são bem baratos e rápidos, funcionam mais como uma pergunta e resposta e retornam uma probabilidade e um resultado, que pode ser verdadeiro ou falso

04:39 ou um rótulo. Então, você não recebe a explicação que teria com LLM as a judge. O outro tipo de eval é baseado em código. É ótimo para testes determinísticos. Talvez você tenha um critério de eval que verifica se uma palavra aparece na saída ou se algo está em JSON. Para isso, evals baseadas em código são uma ótima opção. Também há métricas como ROUGE e BLEU, que são evals baseadas em código populares. Considero as anotações uma forma de avaliação. É quando temos verdades de referência em conjuntos de dados de referência. Às vezes, elas também são sintéticas. Agent as a judge é um tipo mais novo de eval que temos visto nos últimos 6 meses. Nesse caso, usamos um agent completo para avaliar algo em outro agent. Acho que isso é muito bom para critérios de sucesso supercomplexos. Depois, temos feedback dos usuários e métricas de negócio. Esses três últimos tipos são mais voltados para casos de uso em produção. Mas vocês vão notar que os quatro primeiros são algo que queremos usar ao longo de todo o ciclo de vida, tanto no desenvolvimento quanto em produção. E

05:09 a complexidade que existe em um agent e nos dizer como ele está se saindo. Na verdade, há muitos tipos diferentes de evals. Hoje, vamos nos concentrar em LLM as a judge. LLM as a judge é quando usamos um LLM secundário e pedimos que ele avalie algum aspecto do nosso agent. Pode ser algo como QA, sumarização ou relevância; então, recebemos um rótulo e uma explicação. As explicações são muito úteis. Elas são como o raciocínio ou o pensamento por trás da atribuição de um rótulo. Isso

05:40 dá um pouco de entendimento e evita que você precise aceitar um rótulo pelo valor de face. Mas há muitos tipos diferentes de evals. Quero mencionar os decision models. Isso é algo relativamente novo. Se alguém participou ou acompanhou a confusão sobre o Jevas a Job, que aconteceu há cerca de duas semanas, a OpenAI lançou sua API de decision model na semana passada. Então, acho que decision models serão uma parte enorme dos evals no futuro. Eles são bem baratos e rápidos e funcionam mais como perguntas e respostas: você recebe uma probabilidade e uma saída, como verdadeiro ou falso

06:10 ou um rótulo. Então, você não recebe a explicação que obtém com o Elements of AI Judge. O outro tipo de eval é baseado em código. Eles são ótimos para testes determinísticos. Talvez você tenha algum critério de avaliação que verifique se uma palavra aparece na saída ou garanta que algo esteja em JSON. Esse tipo de coisa funciona muito bem com evals baseados em código. Também há métricas como Rouge e Blue, que são evals de código populares. Vejo as anotações como uma forma de avaliação. É quando temos verdades de referência em conjuntos de dados de referência

06:42 . Às vezes, elas também são sintéticas. Agent as a judge é um tipo mais recente de eval que temos visto talvez nos últimos seis meses. Nesse caso, usamos um agent completo para avaliar algo em outro agent. Acho que isso é muito bom para critérios de sucesso supercomplexos. Depois, temos o feedback dos usuários e as métricas de negócio; esses três últimos são mais voltados aos casos de uso em produção. Mas você vai notar que os quatro primeiros são algo que queremos usar ao longo de todo o ciclo de vida, no desenvolvimento e em produção.

07:12 Isso é bastante importante, porque você quer que isso possa evoluir junto com seu caso de uso, e não quer investir muito em algo que está usando no desenvolvimento e simplesmente jogar fora. Esses evals podem crescer com você ao longo do tempo, e isso proporciona um desempenho consistente. Certo, vamos dar uma olhada nos dados. Vamos pausar nesta tela por alguns minutos para que todos possam começar. Esse código QR leva ao guia de uma página, que tem todas as instruções para o nosso workshop de hoje.

07:44 Mas quero que todos acessem, então, app.arize.com. Queremos entrar no AX. Se você não tiver uma conta, recomendo que crie uma conta gratuita hoje. Daí vou explicar os próximos passos daqui a pouco. Para quem já tem uma conta na Arize, o próximo passo é obter uma chave de API de um provedor de modelos. Vou fazer uma pausa aqui, circular pela sala e me certificar de que ninguém está com problemas para entrar na plataforma. A pergunta foi: dá para usar um endpoint personalizado?

08:14 É obrigatório usar um provedor comum para a etapa dois? Não, fique à vontade para configurar o provedor de LLM que quiser. Só precisamos de algo para o qual possamos fazer chamadas de LLM, para testar nosso eval. Mas, sim, na etapa dois, basicamente acesse o console da Anthropic, o console da OpenAI ou o console do provedor que preferir. Você encontra os provedores de IA em Settings, no produto, e vamos adicionar essa chave de API. Então, vou até meu laptop e mostrar um pouco como fazer isso.

08:46 Aqui, em Settings, no menu de navegação. Clique nessa opção e, em seguida, nas configurações da conta. Deixe-me tentar… Ótimo. Acesse AI Providers. Como você pode ver, temos vários provedores diferentes. Escolha o seu favorito: Anthropic, OpenAI, Gemini, tanto faz. Só precisamos de um que possamos usar para fazer chamadas de API.

09:20 E recomendo que você use o botão Test Integration ao fazer isso, só para garantirmos que temos uma chave de API funcionando. Sim, pessoal, vocês vão encontrar o projeto de demonstração. Desculpem, vou voltar. Só estou tentando garantir que todos tenham tempo para acompanhar, mas vocês podem acessar o projeto de demonstração que vamos usar de duas maneiras. A primeira é nesta página de rastreamento: quando acessarem aqui, vão ver o projeto de demonstração. Eu tenho o agente de LLM. Sei que algumas pessoas talvez estejam vendo o modelo de demonstração mais antigo.

09:51 Não importa qual deles vocês têm, poderão fazer o exercício de hoje. Só queremos olhar alguns rastros. Vocês podem ampliar o período para ver um pouco mais de dados, se quiserem. Vou dar mais alguns minutos a todos, porque só vi algumas pessoas levantarem a mão dizendo que conseguiram configurar o provedor de IA. E vou ver se consigo arranjar um que possamos compartilhar rapidinho também. Certo, se vocês abriram o projeto de demonstração do agente de viagens, este é um agente de planejamento de viagens. Ele

10:22 recebe uma solicitação de um usuário e pode fazer perguntas complementares, chamar ferramentas e, basicamente, retornar um plano. Na minha opinião, em termos de produto, uma boa resposta é aquela que responde às perguntas complementares feitas pelo usuário e respeita a quantidade de dias e o orçamento da viagem. Em geral, é assim que se parece uma solicitação de usuário. Vocês podem ver o destino, por quanto tempo querem viajar, qual é o orçamento e qual é o estilo geral de viagem. Esse é um exemplo do que poderíamos ver vindo de um usuário que acessa esse agente de viagens.

10:52 Gostaria que todos dedicassem alguns minutos a olhar os rastros. Queremos fazer um levantamento geral: o que os usuários estão pedindo? O que a ferramenta do agente fez? Quais ferramentas foram usadas? Quais são as respostas? E, então, anotar se vocês compartilhariam essa resposta. Queremos explorar os dados e nos familiarizar com eles. Então, abram um ou dois rastros e comecem a pensar no que gostariam de medir enquanto analisam os dados

11:23 aqui. Como exemplo, vou voltar ao produto. Expliquei o meu no último dia. Vamos dar uma olhada em um desses rastros. Como podem ver, o destino é Praga, na República Tcheca, por três dias, com um orçamento de 800 dólares. O usuário pediu uma opção com mais cara de local e menos turística. Temos algumas ideias aqui e podemos começar a ver o plano criado pelo agente de planejamento de viagens. Então,

11:53 há um dia um, um dia dois e um dia três detalhados. Se quiserem ver outros atributos ou dados que temos, eles estão em Attributes. E é assim que se navega um pouco pelo nosso produto. Mais uma vez, esta é a árvore de rastros. Ela mostra cada etapa individual. Se quiserem ver os dados que foram passados em uma etapa — por exemplo, os dados enviados à OpenAI para processar nossa solicitação —, podemos selecionar esse span e, em seguida, olhar a entrada e a saída.

12:24 Vamos chegar a isso daqui a pouco, mas queremos prestar atenção em onde os dados estão e em quais dados achamos que talvez sejam necessários para fazer nossos evals. Vamos passar alguns minutos explorando e vendo que tipo de insights encontramos. Algumas pessoas estão perguntando onde encontrar os dados em si, então vou mostrar mais uma vez. Muitas vezes, nos espaços novos, eles podem ficar um pouco escondidos, mas não quero que vocês passem tempo demais analisando rastros hoje, já que estamos aqui para falar de evals. Então, vocês só precisam

12:55 clicar na opção Traces, aqui no menu de navegação. Isso vai orientar vocês a começar a usar a Arize, mas vamos acessar See Demo Project e, daí, vocês poderão encontrá-lo em Recently Viewed. Vocês também podem ampliar o período para ver um pouco mais de dados. Todos tiveram tempo, em geral, de encontrar o projeto e dar uma olhada rápida? Vou ver se alguém confirma com a cabeça; eu sei…

13:25 …como resolver isso. Certo. Então, antes de passarmos para a próxima parte, quero que vocês olhem para o agente e pensem em como mediriam esse agente ou o sucesso dele. Imaginem que vocês são a pessoa de produto, a pessoa de engenharia ou qualquer outra parte interessada no projeto. Olhem os rastros, vejam como os usuários estão interagindo com ele e como ele está respondendo, e comecem a anotar mentalmente o que vocês mediriam. Na próxima

13:57 parte do workshop, vamos começar a definir quais seriam esses critérios. Mas, em termos gerais, enquanto analisam, pensem em algumas das coisas que mediriam. Sim, a pergunta foi como devemos ler um rastro aqui. Mais uma vez, para quem talvez não esteja familiarizado, um rastro é essencialmente uma coleção de todas as etapas que um agente percorreu para responder à pergunta de um usuário. Então, vamos abrir este aqui. No topo, chamamos isso de span raiz. A definição técnica é: parent ID é igual a null. Isso significa que

14:29 este span não tem nada antes dele. Ele fica no topo. Em geral, é onde ficam a entrada e a saída final. Depois disso, temos os spans individuais. Chamamos cada um deles de span. Gosto de pensar neles como unidades de trabalho. Vamos dar uma olhada nesta primeira sequência de spans. A primeira coisa que esse agente fez, a partir do span raiz, além de chamar outros agentes, foi aparentemente chamar o agente de pesquisa. Isso é o que chamamos de sistema multiagente

14:59 um sistema em que há vários agents realizando tarefas diferentes em nome do agent principal. Então, neste primeiro, temos o agent de pesquisa, que vai chamar uma ferramenta. Cada um deles tem um tipo, como dá para ver pelos ícones diferentes. Este é um intervalo de agent. Este é um intervalo de ferramenta. O intervalo de ferramenta serve para obter dados externos. Então, você pode imaginar que, neste caso de pesquisa, há algumas informações essenciais que precisamos buscar, como clima, sites ou coisas adequadas desse tipo.

15:29 E, a partir daí, vamos usar um LLM. Aqui você pode ver todas as entradas e saídas que realmente foram usadas pelo LLM. Então, este é seu agent de viagens conciso. Ele usa as informações daquela ferramenta para fazer um resumo que podemos utilizar em uma etapa posterior, aqui. E você pode percorrer a árvore de rastreamento desse jeito, uma etapa de cada vez. Dá para ver como tudo se conecta, mas cada um desses elementos realiza uma etapa ou unidade de trabalho para que possa

16:00 prosseguir e responder. Então, mais uma vez, o objetivo desta aplicação é analisar o pedido de viagem de um usuário e planejar a viagem para ele. Dar a ele um itinerário com coisas que pode fazer e lugares onde pode se hospedar, tudo de acordo com as preferências dele. E cada um desses intervalos corresponde às unidades de trabalho realizadas para, no fim, gerar esse tipo de itinerário. Alguma pergunta sobre isso? Fico feliz em responder perguntas sobre rastreamento enquanto avançamos. >> Sim, a pergunta é: há

16:30 dois intervalos de LLM. >> Sim, às vezes… Vou voltar e conferir o rastreamento exato do que aconteceu. Às vezes, a instrumentação mostra as diferentes etapas: o LLM escolhe a ferramenta a ser usada e, em seguida, passa essas informações para a ferramenta. Então, vamos ver o que aconteceu aqui. Parte disso é simplesmente parte da instrumentação. Então, parece que aqui

17:00 foi assim, e acho que a primeira chamada ao LLM escolheu a ferramenta; depois, acho que nesta segunda chamada ao LLM os dados efetivos da ferramenta foram passados ao LLM para serem resumidos. Às vezes, é um pouco difícil acompanhar aqui; você precisa descer pelo rastreamento e depois voltar. Então, este intervalo de LLM escolheu esta ferramenta, e este intervalo de LLM resumiu o resultado da ferramenta. A ferramenta buscou aqueles dados, como a temperatura e os dados do destino, e depois o segundo LLM basicamente os resumiu para que pudéssemos continuar

17:32 trabalhando com eles. Sim, ótima pergunta. Para todos, caso não tenham conseguido ouvir: aquele nó raiz toma todas as decisões ou há alguma flexibilidade em relação a como isso funciona? Há bastante flexibilidade. Isso depende da infraestrutura do seu agent. Você pode ter o que é conhecido como supervisor ou agent orquestrador, que muitas vezes cria um plano para os subagents seguirem. Às vezes, as tarefas são simplesmente passadas para um LLM com um conjunto de ferramentas, e cada etapa acontece uma após a outra. Então,

18:02 depende um pouco do framework que você está usando, de como é sua infraestrutura e da arquitetura geral do seu agent. Neste caso, acho que é um agent de grafo de links. Então, não estamos usando exatamente uma arquitetura de supervisor. Temos apenas alguns agents modulares responsáveis por tarefas diferentes. Ótima pergunta. A pergunta era quais frameworks estratégicos oferecemos suporte na Arize. Somos agnósticos em relação a frameworks. Temos vários instrumentadores automáticos disponíveis por meio do nosso pacote de rastreamento, o Open Inference.

18:33 Não temos preferência por nenhum framework. Nosso objetivo é ser realmente flexíveis e oferecer a você ótima observabilidade e evals. Posso compartilhar a documentação, onde você pode ver todos os frameworks compatíveis. Certo. Vamos continuar um pouco. Parece que todos tiveram tempo para examinar os rastreamentos, se familiarizar com os dados e, espero, identificar algumas coisas que mediriam o sucesso. Então,

19:05 o primeiro passo para definir sua eval é definir o que significa ter um bom resultado. Às vezes, isso é difícil para as pessoas. Então, tenho aqui um pequeno truque para diferenciar critérios vagos de critérios concretos. Em geral, gosto de simplesmente anotar o que significa ter um bom resultado, mas usando critérios bem específicos. Em vez de dizer apenas “útil”, “preciso” ou “boa resposta”, é melhor ser um pouco mais específico. Por exemplo: uma resposta que acompanha as perguntas de acompanhamento do usuário,

19:35 corresponde ao número de dias solicitado e mantém os totais dentro do orçamento informado. Para esta aplicação, esses são critérios bem concretos do que seria um resultado bem-sucedido. E recomendo que, se você estiver criando isso para sua aplicação, pare para pensar sobre quais são esses critérios. Outra dica útil é avaliar uma qualidade por eval. Há algumas exceções. Gosto de destacar que, especialmente com decision models e um agent como juiz, é possível

20:05 avaliar vários critérios de uma só vez. Mas, no caso de um LLM como juiz, muitas pesquisas mostram que ele só se sai bem ao avaliar um critério por vez. Então, acho que é uma boa prática pensar em um critério e depois adicionar mais evals com o tempo. Criar conjuntos de evals é um processo iterativo. Você não cria suas evals, define tudo e esquece, como se isso bastasse durante toda a vida útil da aplicação. É preciso iterar. Então, ao definir como é o sucesso, costumo anotar alguns critérios e depois começar a criá-los

20:36 e, com o tempo, podemos adicionar cada vez mais. Mencionei que trabalhei no Alex, nosso agent de IA que funciona na Arize, e, quando criei as evals pela primeira vez, tinha um conjunto bem simples. Era algo como correção de perguntas e respostas. Acho que também tinha algo como frustração do usuário e, claro, evals de segurança, como jailbreak e toxicidade. Agora temos 32 evals que são executadas no Alex. Dá para ver que é melhor começar com algo pequeno e, conforme sua aplicação ganha uso, fundamentar as evals em dados reais de produção e

21:07 depois aprimorá-las para descobrir o que mais você talvez precise definir como sucesso. Vejo algumas perguntas ali. Sim, a pergunta para o grupo é: uma eval genérica é melhor do que uma mais específica? Acho que depende. Em geral, eu diria que criar uma eval específica para seu caso de uso é melhor. Mas o que eu diria é que uma eval é melhor do que nenhuma eval. Então, muitas pessoas, por exemplo na Arize, quando estão começando, usam nosso hub de evals, que tem vários modelos prontos para uso e é ótimo para começar. Temos coisas como correção de perguntas e respostas, alucinação,

21:38 coerência da sessão e vários outros tipos de evals. Acho que são ótimas para começar, mas o ponto principal — e vamos falar um pouco sobre isso hoje — é alinhá-las ao seu caso de uso e depois criar evals mais específicas com o tempo. Então, acho que começar com evals básicas e reutilizá-las, especialmente em toda uma organização, é ótimo, porque é melhor ter algumas evals; depois, é só torná-las mais específicas. Certo, comecem com uma e adicionem mais evals depois. Acho que, em duplas ou com quem estiver perto de vocês, gostaria que

22:09 anotassem algumas ideias. Basicamente, há seis coisas que queremos registrar. Isso vai ser muito útil para realmente criarmos nossa eval. Primeiro, a tarefa: o que você quer que esta eval avalie? O que seria sucesso, o que seria fracasso, o que está sendo julgado — ou seja, o que as evals devem efetivamente julgar nesta avaliação — e, então, basicamente, três tópicos sobre como seria uma aprovação e como seria uma reprovação

22:41 parece. E lembre-se daquele slide ali: quanto mais específico e concreto você puder ser, melhor será sua avaliação. Então, vamos usar tudo isso, todas essas anotações que vocês estão escrevendo, para realmente criar nossa avaliação na próxima etapa. Portanto, quanto mais específicos pudermos ser, melhor. E acho que é uma ótima oportunidade para conversar com as pessoas ao seu redor, ver o que vocês estão pensando, o que perceberam nos traces, e eu vou circular por aqui. Avisem se tiverem alguma dúvida. Recebi uma pergunta aqui sobre como os dados aparecem no trace desta aplicação. Eles são bem específicos. Têm todas as informações da…

23:12 solicitação. E a pergunta era: isso já vem pronto ou preciso criar algo específico para meu caso de uso? Era aquele rapaz ali, só para confirmar. A pergunta é sobre como, com nossa instrumentação pronta para uso, abstraímos para vocês algumas das práticas recomendadas de tracing. Então, enviamos vários atributos comuns. Por exemplo, o valor de entrada ou as mensagens de entrada que enviamos ao LLM são bastante padronizados, mas vocês podem usar o que chamamos de instrumentação manual ou híbrida, que permite personalizar. O tracing é bem flexível. Queremos garantir…

23:42 que ele seja adaptado e que vocês obtenham as informações necessárias para seu caso de uso, mas tentamos facilitar isso ao mesmo tempo. E, se vocês têm aplicações próprias que querem rastrear, naquela página inicial havia nosso MCP evals. Essa chamada traz todas as nossas skills, que são a melhor maneira de fazer tracing atualmente. Deixem o agent descobrir como instrumentar a aplicação e vocês podem orientá-lo. Recomendamos bastante isso se forem enviar seus próprios traces para avaliar depois. Certo. Vou avançar para o próximo slide para mostrar um exemplo de como isso pode ficar, e sei que havia algumas perguntas ali…

24:12 que vou responder. Vou mostrar um exemplo de como seus critérios geralmente devem ficar. Esta é a tarefa que queremos avaliar: o usuário envia uma pergunta de acompanhamento sobre a viagem. O sucesso é responder diretamente à pergunta de acompanhamento usando os detalhes da viagem. A falha é recorrer a um orçamento genérico. E vocês podem ver aqui os casos de aprovação e reprovação. Algumas pessoas me perguntaram por que queremos usar tópicos e por que uma frase curta não é suficiente. O motivo é…

24:42 que, basicamente, vamos usar isso para escrever nosso prompt de LLM para fazer uma avaliação com LLM como juiz. Queremos ser muito específicos para que o LLM consiga entender. Gosto de pensar nisso como descrever para um colega de trabalho ou uma parte interessada como é o sucesso. Quase dá para tratar a criação desses critérios da mesma maneira. Vou responder a mais algumas perguntas e depois vamos passar para a próxima etapa. Para quem quiser adiantar um pouco, isto só está dizendo que, se houver conteúdo demais nos…

25:13 seus critérios, vocês podem reduzi-los, mas, para ganhar tempo, vou avançar. Vamos começar a criar nossa avaliação. Primeiro, vocês devem acessar os traces. Vou até lá agora. Em seguida, selecionem alguns traces para adicionar ao conjunto de dados. Por exemplo, se quisessem avaliar apenas a entrada em comparação com o itinerário — isto é, verificar se o itinerário contém as informações gerais da entrada —, vocês…

25:43 deveriam salvar todos esses spans raiz em um conjunto de dados. Se decidiram que talvez queiram testar o tool calling e ver se a chamada da ferramenta retorna as informações corretas, deveriam adicionar todas essas chamadas de ferramenta ao conjunto de dados. Temos filtros aqui; é a melhor maneira de identificar dados. Um ótimo exemplo: para spans raiz, vocês podem usar apenas parent ID igual a null ou partir dos traces padrão. E, se quisessem, por exemplo, filtrar uma chamada de ferramenta que…

26:13 acho que era a ferramenta essential, também poderiam filtrar pelo nome. Depois, bastaria selecionar esses itens na visualização de spans e adicioná-los a um novo conjunto de dados. Essa é a próxima etapa. Depois, vamos ao playground para criar e testar nossa avaliação. Podem ir até lá enquanto respondo a algumas perguntas. Avisem se surgir alguma dúvida sobre como adicionar itens ao conjunto de dados e como pensar nos filtros. Quero…

26:44 mostrar a algumas pessoas as próximas etapas, por causa do tempo, porque sei que não temos muito tempo. Espero que todos tenham conseguido escrever os critérios e identificar alguns spans para o que estão criando. E isto é basicamente a primeira versão do que vocês provavelmente viram, que vou fazer agora ao vivo para todos acompanharem. Primeiro, queríamos filtrar os spans que vocês estão avaliando. Foi isso que acabamos de ver. Então, examinem os traces…

27:16 e identifiquem qual span precisam avaliar, criem o filtro e adicionem os itens a um conjunto de dados. Agora, vamos entrar no nosso playground de prompts. É meu lugar favorito para testar nossos prompts. Vocês podem acessar o playground. Já configurei um, mas vou criar um novo. Nosso produto tem dois tipos de playground. Vamos usar o playground de prompts, ótimo para testar prompts de avaliação ou quaisquer prompts de LLM para seu agent. Também temos um playground de agent, para testar…

27:48 o agent de ponta a ponta. Então, não é tão relevante para hoje. Basta dar um nome. Vou chamar de AI engine evals. Depois, podemos criá-lo. Se vocês estavam no nosso eval hub e criaram uma avaliação, aparecem aqui e veem um painel lateral como este. No playground, podem simplesmente adicioná-la pelo menu suspenso aqui. Vocês verão sua avaliação aparecer. Para quem está apenas…

28:19 começando o processo de avaliação, vamos criar uma avaliação em branco. Vocês podem começar a escrever o template aqui. Basicamente, vão transformar todos aqueles critérios em um prompt. Em grande parte, é só copiar e colar. Vocês podem colar aqueles tópicos que tinham como critérios, mas muitas vezes é bom começar com uma introdução, dizendo algo como: você é um agent de avaliação ou um LLM de avaliação que analisa a precisão da saída da sua aplicação. Deixe-me…

28:51 carregar este aqui. Certo, perfeito. Gosto de começar minhas avaliações com um exemplo do que o LLM deve fazer. Sempre procuro deixar claro qual é a função dele. Você está avaliando se a saída de um assistente representa com precisão os detalhes solicitados ou fornecidos na entrada. Depois, é preciso fornecer os dados. Isso é muito importante. Ao examinar esses traces, provavelmente haverá atributos que vocês vão querer identificar. Não precisam se preocupar em escrever o…

29:22 nomes específicos no seu prompt de eval. Fazemos algo chamado mapeamento de variáveis, que permite conectar isso aos seus dados exatos. A vantagem é que seus evals podem ser flexíveis. Por exemplo, se você estiver executando um conjunto de dados que chama algo de um jeito, e seus traces chamarem isso de outro, em vez de precisar atualizar cada eval, você pode simplesmente atualizar a tarefa em que ele está sendo usado. Então, não se preocupe muito com o nome da variável. Este é um exemplo do que escrevi para o meu. Estes são os detalhes da verificação. São coisas como aqueles três itens da lista

29:52 sobre aprovação e reprovação. Aqui, marco como correto somente se, sabe, a saída for consistente com a entrada; como incorreto se houver um destino errado, um tipo de propriedade errado, seja o que for — isso será considerado incorreto. Em parâmetros, você verá que, se configurar isso na tarefa, é aí que ficam os rótulos. Este aqui é apenas correto ou incorreto, mas você pode ter, sabe, um problema com vários rótulos. Talvez use correto, incorreto e parcialmente correto. Tenho casos de uso no Arize em que é relevante para mim saber quando

30:23 algo está mais ou menos correto, mas não totalmente. Você também pode usar opções como não aplicável. Então, há bastante flexibilidade. O eval retornará apenas um rótulo, e aqui você tem algumas opções sobre a direção da otimização, que indicam, por exemplo, se um resultado bom ou correto é o desejável, ou se uma pontuação mais baixa é melhor. E há também as explicações. Novamente, elas são uma espécie de raciocínio para explicar por que o template ou o eval deu determinada resposta.

30:53 E então o que você vai querer fazer é carregar seu conjunto de dados. Você pode carregar os spans que criou e salvou no seu conjunto de dados. Agora estamos no ponto em que podemos começar a testar nosso eval. Temos aqui todas as entradas e saídas. Se precisar mapeá-las para variáveis diferentes, no meu caso elas são iguais, mas você pode fazer isso aqui. E agora você pode começar a executar. Vou usar o 4.1 mini, que me parece uma boa opção. E então vamos começar a ver a

31:23 saída do nosso eval aqui mesmo no playground. Este é um ótimo lugar para começar a iterar no template do seu eval. Veja a resposta e tente perceber se concorda ou discorda dela. Depois, você pode ajustar o prompt e continuar executando ao longo do tempo. Então, é isso que vamos fazer nos próximos minutos: tentar chegar a um template bem ajustado. Depois, você pode salvá-lo neste botão aqui, “Save evaluator”, e ele ficará disponível para uso em toda a plataforma, seja no nosso projeto de demonstração ou em qualquer aplicação que você desenvolva e traga para o Arize depois.

31:54 Vou circular por aqui para ajudar algumas pessoas a escrever seus templates e, depois, tenho só um ou dois slides para encerrar. Queria destacar que temos algumas ferramentas para ajudar. Pedi a todos que escrevessem seus critérios, criassem o eval e o testassem, mas também temos o Arize na plataforma, que pode ajudar com isso. Então, recomendo muito que vocês peçam ajuda ao Arize, especialmente depois de fazerem uma primeira rodada do eval. Ele

32:25 pode executar o playground para você, analisar os resultados, atualizar o prompt e repetir o processo. Isso é muito útil quando você está escrevendo evals. Retomando um pouco o restante do ciclo: hoje passamos bastante tempo na segunda etapa, em que você instrumenta e escreve seu eval. Mas o restante do ciclo inclui coisas como o Signal. Esse é nosso agent gerenciado na plataforma, que consegue analisar seus traces, encontrar problemas para você e até fazer correções. Assim, isso se torna um sinal que nossos agents gerenciados podem consumir e, em última análise, usar para ajudar a melhorar sua aplicação.

32:56 Estas são algumas coisas que, na minha opinião, boas equipes fazem em seguida: alinhamento. Alinhamento é o processo de anotar todos aqueles exemplos que adicionamos ao nosso conjunto de dados e, depois, executar o eval para ver se ele corresponde ao feedback humano. Os evals online consistem essencialmente em colocar isso em uma tarefa e executá-la continuamente nos nossos traces. Isso significa que, no Arize, toda vez que você envia um trace, nós o avaliamos

33:28 de acordo com todos os seus evals, e isso é publicado automaticamente. Depois, você pode usar esses dados para monitorar sua aplicação. O ponto principal que todos devem levar daqui é que cada stakeholder avalia o agent. Isso não é responsabilidade de apenas uma função. Você realmente quer reunir todos que tenham algum interesse no agent e pedir que definam como é o sucesso de acordo com os resultados que buscam. Então, equipes de produto, engenharia, suporte, especialistas e segurança — todas essas pessoas devem participar. E então

33:59 as principais diferenças entre uma métrica e um eval são que uma métrica informa que algo pode estar com problemas, mas os evals dizem qual é o modo de falha de fato. Então, você realmente quer usar os dois. E acho que uma coisa interessante para experimentar em seguida é que temos todos esses novos decision judges. Acho que é sempre interessante pegar seus elementos como judge, sabe, convertê-los em uma pergunta para um decision judge e talvez comparar o desempenho, para ver qual pode ser melhor. E, sim. E, novamente, comece pequeno: talvez 20 traces

34:30 e uma dimensão, um judge. Leia as explicações, faça iterações e, depois, você pode ampliar para cada vez mais evals. E só para mencionar alguns recursos: temos documentação sobre como avaliar seu LLM as a judge e também a documentação dos judges. Temos análises detalhadas sobre o benchmarking do decision model. Acho que alguém perguntou quando deve usar LLM as a judge e quando deve usar judge. Acho que esse é um ótimo caso de uso. E, sim, vou ficar por aqui pelo resto do dia. A Arize terá um estande na exposição a partir de, acho, 16h

35:00 de hoje. Então, se quiser saber mais sobre evals e conhecer um pouco melhor nosso produto, venha falar conosco. E, se houver alguma pergunta, ficarei feliz em respondê-la. Muito obrigada por terem participado hoje.

Transcrição original

[00:01] [music] >> Um, before we get started, I just wanted to introduce myself. I’m Sally Ann, and I’m head of product at Arize. Uh, been at Arize for like 4 years now. Um, one of the first projects that I owned actually was building our AI agent Alex into our platform. So, I’ve been dealing evals for a little while now, and uh, even building a lot of our evals product. And so, I think the way that I

[00:32] think about evals is that they’re our primary signal for our agents. Um, and that includes all of our evals at Arize. So, my goal today is you’ll leave with three things. Um, a clear definition of what an eval is and what it isn’t. Uh, being able to write your own criteria. So, I’m hopefully going to be able to provide you with like a little bit of a recipe uh, for how you can think about evals and how you can apply that for any of your real agent scenarios. And then we’re actually going to build a working judge in Arize. Um, and I’ll show you a

[01:03] little bit about the life cycle there and how you can think about improving your evals over time. So, this is a bit of our agenda. So, again, I’m going to give you a little bit of context. I don’t want to spend too much time in slides, but I want to make sure everyone has a really solid foundation for what an eval is and how you should think about it. Um, we’re going to explore some data in Arize together, um, write our criteria, and then we’ll actually go build our eval. That’s the main part of our workshop today. Um, and then I’ll give you a little bit of like where you could take this for what’s next. Um, I love it to kind of

[01:33] have some like working sessions so people can collaborate together. I’ll try to like walk around the room, help folks out. Um, and then I will show kind of like a one-pager that’s in Notion that you can kind of open and follow along as well. So, just check the room a little bit. Who here has either like shipped a chatbot or an agent, ever written an eval, or even just opened the Arize product today? Anyone here? All right, we got a a few folks here. So, I think this is going to be great for folks who maybe haven’t done any of this and even if you have, I think today

[02:04] should still be pretty helpful. So, going to start off the context with like why I don’t think vibe checks actually scale. So, this is the vibes problem as I see it. You know, you have Monday, you maybe change something to your prompt, you ship it. It overall feels better. You don’t really have a way to know, but overall things are looking good. You know, Tuesday ship it, a week later now that use case that you shipped a fix for is broken. And then next week, as the problem continues to get worse and worse, there’s no way for anybody to prove

[02:34] whether something was fixed or that it’s actually failing. have vibes to go off of. What you can’t do without evals is you can’t detect regressions when you change a prompt. You can’t objectively compare prompt or even different model versions. You don’t know if a new model is any better for your use case and you can’t actually put any official quality gates into CI as you’re shipping your agent. So, without evals it’s you can imagine it’s it’s pretty hard to actually know how your agent is

[03:06] performing. A question I commonly get is is an eval just a unit test? I think that there’s a lot of comparison of AI evals to like kind of traditional software tests and I do think that they’re a little bit different. Cuz first off, with a test you kind of just have like one input and there’s one correct output. You can also read all of the logic in the code. With an AI agent, you actually cannot read any of that logic. That actually comes out after in the form of traces. And so, you kind of need to have this AI

[03:38] eval where you can look at like the day-by-day itinerary in this travel planner example I have here, the budget breakdown or multiple criteria basically. So, there’s these many valid outputs that you just can’t have, you know, a more traditional unit test on like you can with software. So, basically how I like to think about this is traces are the logs for AI Um, evals are actual tests. And I always say that uh uh I used to have a meme, I didn’t include it today, but the hard pill is you kind of need traces, you

[04:09] need observability to actually do your evals. So, this is an example here for why agents make this harder. So, this is just a sample example of what like a trace could look like. And for anybody in the room who’s maybe not familiar with what a trace is, um essentially it is all of the steps that an AI agent took to be able to get an answer back to a response. So, a user says something and then what I’m showing here in all of those spans is all the individual steps the agent took uh to get that answer. So, in this example, there’s like a

[04:39] research agent that’s going to go perform some research, uh maybe even do like some tool calls there. You have, you know, your local agent that’s maybe retrieving something from a knowledge base. So, lots of back and forth are happening. And this is where I mean you can see the logic of your agent. Um, and we’re going to explore some traces in the Arize UI just a little bit. Um, so you can see there’s lots of LM calls, lots of things composed together. And so, you can imagine just having one single unit test like in software not really going to accurately capture all

[05:09] the complexity that’s in an agent and be able to tell us how it’s performing. There’s actually lots of different types of evals. Today, we’re going to focus on LM as a judge. Um, LM as a judge is where we take a secondary LLM and we ask it to grade some aspect of our agent. Um, and so, there can be things like QA, summarization, relevance, and then you get a label and an explanation out of that. Explanations are really helpful. Explanations are kind of like the the reasoning or the thinking behind providing a label. It

[05:40] gives you a little bit of understanding and not just have to take a label at face value. But, there’s lots of different types of evals. I want to call out decision models. Uh this is something that’s pretty new. Uh if anybody kind of took or was a part of the the Jevas a Job storm that happened about 2 weeks ago and OpenAI just last week released their decision model API. So, I think decision models are going to be a huge part of evals in the future. Um, those are pretty cheap and fast and it’s uh more like a question answer and you just get like a probability and an output whether it’s like a true or false

[06:10] or a label. So, you don’t get that explanation that you get with Elements of AI Judge. The other type of eval is code. Uh, these are really great for any deterministic tests. So, maybe you have some eval criteria that’s like checking if a word is in an output or making sure that something’s in JSON. Uh, that’s going to be really great for code-based evals. There’s also things like Rouge and Blue scores that are popular code evals. Um, annotations I do see as a form of evaluation. This is where we’re having uh you know, golden truths on golden

[06:42] datasets. Um, sometimes they’re synthetic as well. Um, agent as a judge is a newer type of eval that we’ve seen maybe over the last 6 months. Um, that’s where we’re going to take a full agent and evaluate something in a different agent. I think this is really good for super complex um like success criteria. Um, then we have user feedback and business metrics and those three at the end are going to be more for your production use cases. But, you’ll notice the first four are something that you want to use across your life cycle in development and production. Um, and

[07:12] that’s pretty important because you want this to be able to evolve with your use case and you don’t want to like put a lot of investment in something you’re using in development and just throw it away. Those evals can grow with you over time and it gives you that consistent um performance. All right, let’s go ahead and look a little bit at the data. Um, so we’re going to pause here on this slide give everyone a few minutes to go and get started. That QR code is going to be for the one-pager which has all of the instructions for our workshop today.

[07:44] Um, but I want everyone here to go ahead to go to you know, app.arise.com. Uh, we want to log into AX. So, if you don’t have an account um encourage you to make a free um account today. Um, and then I’ll go over the steps from there in just a second. Um, and for anybody who already I guess might have an arise account, the next step is going to be getting an API key from um a model provider. So, I’ll pause there uh walk around make sure nobody has any issues logging into the platform. The question was, can you do you have to use like can you use a custom endpoint?

[08:14] Do you have to use a a common provider for step two? No, feel free to set up whatever LLM provider you want. We’ll just want something that we can make LLM calls to so we can test our eval out. But yeah, step two basically go to your Anthropic console, your OpenAI console, whatever provider of your choosing. You can find your AI providers under settings in the product and we’re just going to want to go ahead and add that API key in. So, let me go to my laptop here and show you all a little bit of how to do this.

[08:46] So, settings here in the nav. You’re going to go click into that and then under your account settings, let me try to Cool. You’re going to come to AI providers. And you can see here we have a whole bunch of different providers. So, just choose one that is your favorite to use, Anthropic, OpenAI, Gemini, doesn’t matter. Just something that we can use to make API calls with.

[09:20] And I encourage you to use the test integration button when you’re doing that just so we can make sure we have a working API key. Yeah, for for folks you’ll find the demo project. Sorry, I’ll go back. Just trying to make sure everyone has time to to catch up, but you can access the demo project that we’re going to use in one of two ways. The first is on from this when you go to this tracing page here, you’ll see see demo project. I have the LLM agent. I know some folks might have our older demo model there.

[09:51] Does not matter which one you have, you should be able to do our exercise today. So, we just want to be able to look at some traces. And you know, you can expand the time if you want to see a little bit more data there, but give everyone a few more minutes cuz I only saw a handful of hands that got the AI provider. and to see what I can do to see if I can get one that we can share really quickly, too. All right, so if you have that travel agent demo project opened, this is a travel planning agent. It

[10:22] takes a request from a user and then can it make follow-up questions, call tools, and basically returns a plan. What I think good looks like in product terms is it answers the follow-up questions the user asked for and respects the trip’s days and budget. So, this is generally what a user request looks like. You can see the destination, how long they want to go, what their budget is, and what their kind of general travel style looks like. And that’s an example of what we might see from a user who goes to this travel agent.

[10:52] So, I’d love for everyone to take a a few minutes. We want to look at the traces. We kind of want to just take inventory. What are users asking for? What did the agent tool do? What tools, what are the answers? And then just kind of make note, was this an answer that you would share? So, just want to kind of explore the data and get familiar with it. As yeah, open one or two traces and maybe start thinking a little bit about what you’d want to measure as you’re you’re looking through the data

[11:23] here. So, as an example, let me hop on over to the product. I explained mine to last day. Let’s go ahead and take a look at one of these traces. So, you can see here, this destination is for Prague, Czech Republic, for 3 days, $800 budget. The user asked for an option that feels more local, less touristy. We have some kind of our ideas here and then we can start to view the plan that the the trip planning agent created. So,

[11:53] you have a detailed day one, day two, day three. And if you want to see any additional, you know, attributes, any additional data that we have, you can see that in attributes. And so, a little bit of how to navigate our product here. So, again, this is the trace tree. This is every individual step. If you want to see the data that was passed in for a step, like for example, we want to see the data that went into OpenAI to process our request, we can switch to that span and then look at the input and output.

[12:24] So, we’re going to get to this in a little while, but we want to pay attention to where the data lives and what data we think might be needed to do any of our evals. So, we’ll spend a few minutes here just exploring and seeing what kind of insights we find. Getting some questions about where to find the actual data here, so let me just show that one more time. A lot of times in the new spaces it can be a little hidden, but didn’t want folks to spend too much time tracing today when we’re here to talk about evals. So, you’ll just want to

[12:55] click the traces option on the nav here. This will kind of prompt you to get started with the rise, but we’re just going to go to see demo project and then you can see it in recently viewed from there. And you can always expand the time to see a little bit more data there. Has everyone generally had time to like find the project, take a a quick look? See if you had nods, we’ll give I know.

[13:25] Like fix that. All right. So, basically what I want folks to do now before we get into the the next part of of this, is just like look at the agent and think about how you would measure this agent or success for this agent. Think of yourself as the product person, engineer, any real stakeholder of this project and look at the traces, look at how users are interacting with it, how it’s responding, and start making kind of like mental note of what the things are that you would measure. In the next

[13:57] part of the workshop, we’re actually going to start defining what that criteria would be, but high-level as you’re going through, think about some of those things that you would measure. Yes, so the question was like how we should think about reading a a trace here. So, again for for anyone who may be just not familiar, a trace is essentially a collection of all the steps an agent took to answer a user’s question. So, let’s go ahead and open this one here. So, at the top we call that our root span. Like the technical definition of that is parent ID equals null. This means that

[14:29] this span here doesn’t have anything ahead of it. It just sits at the top. And this is usually where the input and final output live. And then from there we have our individual spans. So, each of these is what we call a span. I like to think of it as a unit of work. So, let’s take a look at this first collection of spans here. So, from the root span the first thing that this agent did along with calling some other agents it looks like called the research agent. So, this is a what we call a multi-agent

[14:59] system where there’s multiple agents doing different tasks on behalf of the bigger agent. So, in this first one we have the research agent and that is going to go ahead and call a tool. So, each of these has like a type you can see it different icons. This is an agent span. This is a tool span. Tool span that’s going to be for getting external data. So, you can imagine like in this one research there’s some essential info that we have to grab like things like weather or sites or adequate things like that.

[15:29] And then from there we’re going to use an LLM. You can see here all of the inputs and outputs that actually went into the LLM. So, this is your concise travel agent. And this is using that information from that tool to actually summarize that we can use it in a later step here. And so you can just go down the trace tree just like that like one step at a time. You can see how they all connect but each of these is going to be doing a step or unit of work so that it can go

[16:00] ahead and answer. So, again the goal of this application is to look at a user’s request for a trip and plan it for them. Give them an itinerary of things that they can do, places they can stay all in accordance with their kind of preferences. And so each of these spans is the units that were done to ultimately get this final kind of itinerary. Any questions on that? Happy to answer some questions about tracing while we’re we’re going through this. >> Yeah, so the question is is like there’s

[16:30] two LLM spans. >> Yeah, so sometimes it’s I’ll go back and look at the exact trace of what happened there. Sometimes it’s instrumentation of showing the the different like the LLM like choosing the tool to use and then actually like passing that information to the tool. So let’s go ahead and take a look at what happened here. And some of this is just kind of part of instrumentation here. So this looks like here

[17:00] this way and I think the first LLM call chose the tool and then I think in this second LLM call that’s where the actual data of the tool was passed to the LLM to summarize. So here it’s kind of hard sometimes you have to go down the trace to come back up. So this LLM span chose this tool and then this LLM span summarized the output of the tool. So that tool went and grabbed that like temperature data, destination data and then the second LLM basically summarized it so that we can do kind of

[17:32] further work with it. Yeah, great question. So the question for for everyone in case they couldn’t hear it is is that kind of root node making all of the decisions or is there some flexibility with how that works? And there’s a lot of flexibility. It comes down to what your agent kind of infrastructure is. So you can have what’s known as kind of like a supervisor or an orchestrating agent and a lot of times that will make a plan for the sub agents to follow and then sometimes it’s just passed kind of to an LLM with a set of tools and each step is goes like one by one. So

[18:02] depends a little bit about like what framework you’re using, what your infra looks like and the general architecture of your agent. In this case here this is a link graph agent I believe. So we’re not doing any like supervisor architecture really. Just we have a a few like modular agents that are responsible for different tasks. Great question. The question was like what strategic frameworks we support with arise. We’re agnostic to frameworks. We have a bunch of what we call auto instrumenters available through our tracing package open inference.

[18:33] We don’t have a preference of which framework we want to use. Our goal is to be really flexible and provide you with really good observability and evals on top of it. So I can link our docs where you can see all the different frameworks that are supported. Okay. Let’s keep going a little bit here. Sounds like everyone had some time to take a look at the traces, get themselves familiar with the data here and hopefully was able to spot some things that they would measure for the success. So

[19:05] the first step of defining what your eval is is defining what good means. This is sometimes tricky for folks to do. So I’ve kind of have this little trick here for vague versus concrete criteria. I generally like to just write down what good means but with really specific criteria. So instead of just being like helpful, accurate, good response, you want to get a little bit more specific. So answer that follows the user’s follow-ups,

[19:35] matches the requested number of days, keeps totals within the stated budget. For this application those are all really concrete criteria for what success looks like. And I encourage you you know if you’re ever building this for your application, you know, sit down and and kind of think about what that criteria is. Another helpful hint that I have is judge one quality per eval. There’s some exceptions to this. I like to point out that for especially the decision models and agent as a judge, you can really get

[20:05] away with you know doing multiple criteria in one. But for LM as a judge, there’s lots of research that shows that it really only does well with handling one criteria at a time. So I think it’s good practice to just think of one of them and then add more evals over time. Building evals sets iterative thing. You don’t just build your evals and then like set it and forget and you’re set for the life of the application. You kind of have to iterate and so um you know, when we’re defining like what success looks like, I usually write down a handful um and then kind of start to build those

[20:36] and then over time we can add more and more. Um I mentioned I worked on Alex, our AI agent um that lives in Arize and when I first built evals, I had a very simple set. It was like QA correctness. I think I had some like user frustration, and of course like jailbreak toxicity, those types of safety evals. Um and now we have 32 evals that run um on Alex. So you can see how you want to start with something small um and then as your application gets usage, you can ground that in real production data and

[21:07] then evolve your evals to see what else you might need to define success. I see some questions over there. Yeah, so the question for the the group is is a generic eval better than a more specific one? I think it really depends. I think generally speaking, I say building a specific eval for your use case is better. But what I would say is an eval is better than no eval at all. So a lot of folks like at Arize, for example, when they’re getting started, we have an eval hub with a bunch of out-of-the-box templates in it and they’re really great for starting. We have things like QA correctness, hallucination,

[21:38] uh session coherence, all sorts of different evals and I think they’re great for getting started, but the the key is and we’ll go through this a little bit today, is to kind of align that to your use case um and then create more specific ones over time. So I think basic ones and reusing them, especially across an org, are great because it’s better to have some evals, but then just make them more specific. All right, so start with one, add more evals later. Um I think in pairs or whoever the group of around you, um I would like to kind

[22:09] of have y’all jot down some ideas. Um basically, there is six things we want to write down. This is going to be really helpful for us actually building our eval. Um so first, it’s going to be the task. Like what do you want this eval uh to be going off of, uh what success looks like, what failure looks like, um, what they’re judging, like what the evals are actually supposed to judge here in this evaluation, and then, you know, basically three bullets on what pass would look like, um, and what fail

[22:41] looks like. And remember from this slide over here, the more specific and concrete you can be, the better your eval will be. So, we’re going to use all of this, uh, all these notes that you’re writing to actually build our eval in the next step. So, the more specific we can be, um, the better. And so, yeah, I think it’s a great opportunity to kind of chat with folks around you, see what you’re thinking, what they noticed in the traces, and I’ll walk around and let me know if you have any questions. I got a question over here that was like, um, the the way that the data looks on the trace for this application is pretty specific. It has all like the

[23:12] request info. Um, and the question was like, does that come out of the box, or do I have to like build that specific to my use case, right? That was the just guy, make sure. Um, and the question is is with our out-of-the-box instrumentation, we kind of abstract kind of all of the tracing best practices for you. So, there’s a lot of common attributes that we send in. So, things like input down value, or the input messages that we send to the LLM, that’s pretty standard, but what you can do is called, um, you know, manual instrumentation or hybrid, which allows you to customize. So, uh, tracing is really flexible. We want to make sure

[23:42] it’s tailored and you get the information you need for your use case, but we try to make it easy at the same time. Um, and if you have, um, you know, your own applications that you want to trace, on that kind of starter page was our like MPX evals, that call brings in all of our skills, uh, which is the best way to do tracing these days. Let your agent figure out how to instrument it, and you can kind of nudge it along. So, highly recommend that if you’re going to send in your own traces, uh, to evaluate later. All right. I’m just going to click to the next slide to show you an example of what this could look like, and then I know there were some questions over here

[24:12] that I’m going to come to. So, just going to show an example, um, here of like what your criteria you generally want it to look like. Um, so, this is like the task that we want to judge. User sends a follow-up about their trip. Uh, the success is answers the follow-up directly using the trip’s details. Failures is falls back to a generic budget. And you can see here, this is the pass and fail. Some folks asked me like why we want to have the bullets and why the one-liner’s not enough and uh, the reason for that is

[24:42] basically we’re going to use this to write um, our LLM prompt to do our LLM as a judge. So we want to be really specific so the LLM um, can understand. The way that I like to think about this is describing to like a coworker or, you know, a stakeholder like what success looks like. You almost want to treat this criteria uh, creation the same. So I’m going to answer a few more questions and then we’re going to move on to the next step. Uh, for folks who want to get a little bit ahead of that, um, you can this is just describing make sure that um, if you have too much in

[25:13] your criteria, you can cut it back, but I think for the sake of time I’m going to move here. Um, we want to go ahead and start building our eval. The first step is you’re going to want to go to those traces. Let me go there now and you’re going to want to select a few um, traces to actually add to your data set. Um, so for example, say you wanted to just go ahead and evaluate the input versus the itinerary. Like does the itinerary have the general input? You

[25:43] would want to save all of these root spans to a data set. Um, if you’ve decided you wanted to maybe test the tool call and see if the tool call returns um, the right information that it was supposed to, you would want to add in all of these tools uh, calls to your data set. Um, we have filters here. It’s the best way to identify data. Um, so one really great example, if it’s like root spans, you could do just parent ID equals null or go off of the default traces. Um, and if you wanted to do like a tool call for example that um,

[26:13] I think it was the essential tool, you could also filter by name that way. Um, and then you would just want to grab these or go from the span view to, you know, select those and add to a new data set. So um, that’s kind of the the next step and then we’re going to head on over um, to our playground to actually build and test our eval. So, folks can head over there while I answer some questions. And let me know if there any that come up for adding to the data set and how you should think about filtering. I want to

[26:44] show some folks kind of the next steps here for time cuz I know we don’t have that much left here. So, everybody hopefully has been able to go through, write their criteria, identify some spans for what they’re building. And then this is essentially kind of the first pass is what you probably saw, which I’m going to do now live for everyone to kind of follow along with. But we wanted to filter the spans you’re judging. That’s what we just walked through. So, look through the traces,

[27:16] identify what span you need to evaluate, build your filter, add those to a data set. And now what we’re going to do is go into our prompt playground. That’s my favorite place to go to actually test out our prompts here. So, you can go to the playground. I already have one set up, but I’m going to go ahead and create a new one. We have two types of playgrounds in our product. We’re going to use the prompt playground. That’s great for testing eval prompts or you know any LLM prompts for your agent. We do also have an agent playground. That’s for testing

[27:48] kind of your agent end to end here. So, not so relevant for today. So, just give it a name. I’m going to do AI engine evals. And then we can go ahead and create it. So, if you were in our eval hub, you were over here and you created an eval, you kind of have a slide over that looks like this. You can go ahead in the playground, just add that from the drop down here. So, you’ll see your eval pop up here. For anybody who’s just

[28:19] starting the eval process, we’re just going to do blank eval. And you can actually just start writing your template here. So, what you’re going to basically do is take all that criteria and turn that into a prompt. A lot of it should be like paste. You can paste in those like bullets that you had as criteria, but um um a lot of times you want to first give it kind of an intro, like you aren’t eval agent or an eval LLM uh looking at the output accuracy for your application. Let me actually just

[28:51] load this one in. Okay, perfect. Um so, I like to start my evals with an example of what the LLM is supposed to do. I I always kind of center it in its job. You’re evaluating whether an assistant’s output actually accurately captures the details requested um or input in the or provided in the input. Um you then want to provide the data. So, this is really important. When we’re looking at those traces, there’s probably uh attributes that you want to identify. You don’t really need to worry about writing the

[29:22] specific names in your eval prompt. We do something called variable mapping um that allows you to connect it to your exact data. Uh the benefit of that is that your evals can be flexible. Like, if you’ve running on a data set calls it one thing, and then your traces call it something different, rather than you need to update every eval, you can just update the task where it’s being used. So, don’t worry too much about the name of the variable. Um and then this is an example of what I have written for mine. Um these are the check-in particulars. Those are things like those three bullet

[29:52] points for pass and fail. Um and then here I have mark only correct if, you know, the output is consistent with the input, incorrect if there’s a wrong destination, property type, whatever it is, that’s going to be incorrect. Um and under params here, you’ll see if you set it up in the task, that’s where we have the labels. This one here is just correct or incorrect, but you can have, you know, a multi-label problem. Maybe you do correct, incorrect, partially correct. I have use cases in Alex where it’s actually relevant to me to know when

[30:23] something is somewhat correct, but not fully. Um you can also do things like not applicable. Um so, lots of flexibility. The eval will return only one label, um and then you have some things here around the optimization direction, which says like is good or is correct the good thing or is a lower score a good thing and then explanations. Again, those are kind of the reasoning for why the template or by the eval gave a certain response.

[30:53] And then what you’re going to want to do is load in your data set. So those spans that you created and saved your data set, you can load them in. And now what we’re in the spot to do is actually start testing our eval. We have all those inputs and outputs that are here. If you need to map them to different variables, mine happen to be the same, but you can do that here. And so now what you can do is actually start to run. I’m going to run with 41 mini, that seems good to me. And we’ll actually start to see the

[31:23] output of our eval right here in the playground. And this is a great spot to just start iterating on your eval template. Look at the response, you know, kind of see if there’s something that you agree with or disagree and then you can adjust the prompt and then continue to run it over time. So that’s going to be what we do for the next little bit here is try to get to a template in a good spot. And then what you can do is save that off here in this little button here, save evaluator, and then that will be available to use across the platform for

[31:54] either our demo project or for any application that you build and bring into our eyes after. So I’m going to walk around, help some folks write their templates and then I have just, you know, one or two slides here to to close us out. I did want to kind of point out that we do have some tools to help you. I had everybody write out their criteria and write their eval and test it, but we do have Alex in the platform that can help you with that. So I definitely recommend helping or having Alex help you, especially after you’ve done kind of your initial eval pass. It

[32:25] can actually run the playground for you, look at the results, update the prompt and repeat. So that’s really helpful for when you’re writing evals. Um pulling out a little bit of the the remainder of the loop here. So we spent a lot of time on the second loop our second step today, um where you instrument, you write your eval, um but then what the rest of the loop looks like is we have things like signal. That’s our managed agent in the platform that is able to look at your traces, find issues for you, even make fixes. Um so this becomes signal that our

[32:56] managed agents can then consume and ultimately help improve your application. Um these are some things I think good teams do next, alignment. Um alignment is going to be the process of like annotating all of those examples that we added to our data set, and then going to run that eval and seeing if um it matches the human feedback. Um online evals will be essentially us putting that into a task and have it running continuously over our traces. So what that means in our eyes, every time you send in a trace, we’ll evaluate it

[33:28] according to all your evals, and then that automatically gets posted, and then you can use that to actually monitor your application. Um a key everybody to walk away here with is that every stakeholder evaluates the agent. This is not just one kind of role’s job. You really want to get everybody in the room who has some kind of stake in the agent and have them basically define what success looks like according to their outcomes. So uh product, eng, support, um experts, um security, those are all folks. And then

[33:59] um the key differences between like an metric and an eval is like a metric tells you that something might be broken, but evals tell you what the actual failure mode is. So you really want to use both there. Um and then I think what might be fun to try next is we do have all these new decision judges. Um and so I think it’s always interesting to take your elements as a judge, you know, convert it to a decision judge question, um and then maybe compare the performance there, uh see which one might be better. Um and yeah. And then again, start small, 20 traces

[34:30] maybe, one dimension, one judge, you know, read the explanations, iterate over it, and then you can expand to more and more evals. Um and just some resources, we have some docs, um, evaluate your LLM as a judge, your judge docs. Uh, we do have some deep dives on like the decision model benchmarking. So, I think somebody had a question of like, when should I use LLM as a judge, when should I use judge? I think that’s a really great use uh, case and uh, yeah, I’ll be hanging out for the rest of the day. Arize has a booth in the expo starting at I believe 4:00

[35:00] today. So, if you want to learn more about evals, see a little bit more of our product, definitely come find us. Um, and if there are any questions, um, happy to answer them and thanks so much for joining me today.