Evals para agentes de IA de alto risco — Doneyli De Jesus e Annabell Schäfer, Langfuse

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: Evals for High-Stakes AI Agents — Doneyli De Jesus & Annabell Schäfer, Langfuse · Canal: AI Engineer · 53:09 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Ferramentas de desenvolvimento com IA, Governança e regulação de IA

Resumo

Annabell Schäfer e Doneyli De Jesus apresentam práticas para avaliar e aprimorar agentes de IA, com foco em aplicações de alto risco e setores regulados. Eles explicam um ciclo de engenharia que combina tracing, monitoramento, conjuntos de dados, experimentos e evals, além de demonstrar esses recursos em um assistente bancário. O workshop aborda como proteger informações pessoais, envolver especialistas de domínio na análise de falhas e automatizar verificações de qualidade em CI/CD. A recomendação central é equilibrar automação com revisão humana e usar evidências para decidir se um agente está pronto para produção.

Pontos-chave

• Métricas tradicionais de observabilidade podem parecer normais mesmo quando um agente afirma ter concluído uma ação que nunca executou.
• O ciclo de engenharia de IA apresentado combina tracing, monitoramento, conjuntos de dados, experimentos e evals em um processo contínuo.
• Em setores regulados, conjuntos de dados de referência e limites claros ajudam a detectar comportamentos inaceitáveis, como oferecer aconselhamento de investimento.
• Traces permitem inspecionar etapas, chamadas de ferramentas, entradas, saídas, custos e latência.
• Informações pessoais identificáveis podem ser mascaradas antes de serem persistidas no Langfuse.
• Especialistas de domínio podem revisar amostras de traces; um LLM pode ajudar a identificar padrões e categorias nas observações.
• Uma combinação de evals com LLM como juiz e verificações determinísticas pode oferecer uma avaliação mais robusta.
• Experimentos com conjuntos de dados permitem comparar alterações em prompts, modelos, contexto e ferramentas antes de levá-las à produção.
• Gates automatizados em CI/CD podem bloquear mudanças que não atinjam os limites de qualidade definidos.
• Agentes de programação podem automatizar tarefas, mas a definição dos objetivos e a curadoria dos dados ainda se beneficiam do julgamento humano.

Capítulos

Início	Capítulo	Resumo
00:12	Apresentação e desafio de avaliar agentes	As apresentadoras contextualizam sua experiência e explicam por que agentes podem falhar mesmo quando as métricas tradicionais parecem normais.
04:21	O ciclo de engenharia de IA	Annabell descreve como tracing, monitoramento, conjuntos de dados, experimentos e evals formam um processo contínuo de melhoria.
09:33	Abordagens para setores regulados	A apresentação diferencia estratégias para aplicações de baixo risco e sistemas regulados, destacando a importância de dados de referência.
11:36	Demonstração de um assistente bancário	Doneyli apresenta um caso financeiro em que é importante controlar riscos, respeitar guardrails e reduzir a imprevisibilidade.
15:14	Traces, mascaramento e guardrails	A demonstração mostra como inspecionar interações, mascarar dados pessoais e identificar solicitações de aconselhamento de investimento.
20:24	Conjuntos de dados e casos de teste	Doneyli explica como criar conjuntos de dados para medir a qualidade, testar ataques e representar requisitos específicos do agente.
24:30	Análise de erros e revisão humana	A equipe pode selecionar amostras de traces para especialistas anotarem e depois usar um LLM para encontrar padrões nas observações.
29:13	Evals determinísticos e LLM como juiz	A apresentação recomenda combinar avaliações baseadas em LLM com verificações determinísticas para medir diferentes dimensões de qualidade.
32:48	Experimentos e gates em CI/CD	Conjuntos de dados permitem comparar configurações e automatizar gates de avaliação sempre que há mudanças no agente.
39:06	Métricas de negócio e investigação de falhas	Dashboards ajudam a comunicar custos, interações resolvidas sem intervenção humana e as falhas mais frequentes.
45:57	Equilíbrio entre automação e supervisão	Annabell alerta contra delegar toda a correção do agente à automação e recomenda preservar a contribuição de especialistas.
48:02	Como começar e recursos disponíveis	A equipe sugere instalar a skill do Langfuse, reunir dados de referência e definir limites rígidos para riscos importantes.
51:06	Perguntas sobre hospedagem e confiabilidade dos evals	Na sessão de perguntas, os apresentadores abordam armazenamento, hospedagem própria e como alinhar um LLM como juiz às avaliações humanas.

Citações

O agente nunca fez o reembolso. A ferramenta nem sequer foi chamada. — 02:16

Se você vem de desenvolvimento de software, pense nesses conjuntos de dados como seus casos de teste. — 20:56

Se você depender 100% de LLM como juiz, existe uma chance diferente de zero de algumas avaliações não serem precisas. — 31:16

O equilíbrio ideal combina sua revisão dos dados e sua experiência de domínio com o trabalho que pode ser automatizado. — 47:31

Conceitos e entidades

• Langfuse (ferramenta): Plataforma open source apresentada para fazer tracing, monitorar e aprimorar aplicações de IA.
• Annabell Schäfer (pessoa): AI solutions engineer na Langfuse e uma das apresentadoras do workshop.
• Doneyli De Jesus (pessoa): Líder de arquitetura de soluções de IA na Langfuse e apresentador da demonstração prática.
• AI engineering loop (conceito): Ciclo de melhoria contínua que reúne tracing, monitoramento, conjuntos de dados, experimentos e evals.
• tracing (conceito): Registro inspecionável das etapas, chamadas de ferramentas e resultados produzidos por um agente.
• conjunto de dados de referência (conceito): Coleção de exemplos e comportamentos esperados usada para avaliar a qualidade de um agente.
• LLM as a judge (conceito): Abordagem que usa um LLM para avaliar saídas de outro sistema, idealmente comparando seus julgamentos com avaliações humanas.
• ClickHouse (ferramenta): Banco de dados citado como dependência da camada de armazenamento do Langfuse.
• Claude (modelo): Assistente mencionado como exemplo de ferramenta com a qual equipes podem interagir.
• GitHub Actions (ferramenta): Serviço usado na demonstração para executar jobs de CI após alterações na configuração do agente.
• PII (conceito): Informações pessoais identificáveis que podem ser mascaradas antes de serem armazenadas.
• CI/CD (conceito): Práticas de integração e entrega contínuas usadas para automatizar evals e gates de qualidade.

Tradução completa (pt-BR)

00:12 Certo, vamos começar. Boas-vindas a todos ao nosso workshop sobre avaliação de aplicações de IA com Langfuse. Meu nome é Annabelle. Sou engenheira de IA, engenheira de soluções de IA na Langfuse. Hoje estou acompanhada do meu colega Donelli, que lidera a arquitetura de soluções de IA na Langfuse. Ele trabalha com nossos maiores clientes para garantir que eles realmente coloquem agents confiáveis em produção. Na minha vida anterior, como gosto de chamar, porque parece que faz uma vida inteira, trabalhei em uma empresa que construía agents de IA para conformidade de dispositivos médicos.

00:43 E, nesse setor, era muito importante garantir que estávamos fazendo as coisas direito. Precisávamos garantir que tínhamos conjuntos de dados de referência validados pelos nossos clientes, e também usamos muitos sistemas com participação humana no processo. Na verdade, passei muito tempo na Langfuse e, em certo momento, pensei: “Por que não mudar de lado e também ajudar outras equipes que estão colocando agents em produção, especialmente em setores regulamentados?”. Então, entrei para a equipe da Langfuse há mais ou menos sete meses. Mas, antes de mergulharmos no assunto, queríamos ter uma ideia de quem está aqui hoje e de quem somos…

01:15 …e de quem está se reunindo conosco hoje. Então, estávamos curiosos para saber: quem de vocês já colocou agents de IA em produção? Com isso, quero dizer que fez parte de uma equipe que realizou esse trabalho — não necessariamente que alguém na empresa tenha feito isso, mas que vocês tenham participado do processo de colocá-los em produção. Certo, ótimo, que bom! Tem bastante gente. Também esperávamos encontrar isso. E quem de vocês já trabalhou com o Langfuse? Certo, alguns de vocês. E alguém já usou algum outro tipo de ferramenta de observabilidade ou evals?

01:46 Certo. Sim, algumas pessoas também. Ótimo. E, por fim, quem já resolveu evals para aplicações de IA? Para quem levantou a mão com confiança, adoraria que passasse no nosso estande e nos explicasse como. Porque, na verdade, é bastante difícil, e acho que todos vocês já passaram por isso se trabalham com IA ou simplesmente conversam com o ChatGPT ou o Claude. É bem complicado, porque agents de IA podem falhar enquanto as métricas do sistema continuam indicando que está tudo bem. Então, por exemplo, se olharmos para este caso aqui, temos…

02:16 …um agent de suporte ao usuário, e o usuário pergunta: “Posso receber um reembolso?”. O agent recebe a solicitação, consulta algumas políticas e então responde: “Sim, claro, emiti seu reembolso”. O usuário agradece, e levará alguns dias até que ele veja se deu certo. O status está verde. Em termos de observabilidade tradicional, nada deu errado. Também não há problemas de latência. Mas, se analisarmos mais a fundo o que realmente aconteceu, o agent não emitiu reembolso nenhum. A ferramenta nunca foi chamada. Nunca foi executada.

02:47 E o agent mentiu para o usuário, dizendo que tinha feito isso. Só vamos saber algumas semanas depois, quando o usuário voltar e disser: “Ei, aliás, nunca recebi meu reembolso”. Esse é o problema desses sistemas não determinísticos. Eles podem nos dizer que fazem coisas, mas, na verdade, não fazem. Por isso, precisamos encontrar uma abordagem, uma maneira de buscar continuamente sinais de que algo está dando errado e garantir que isso não aconteça de novo — ou, quem sabe, que nem chegue a acontecer. Esse é um problema que nossos fundadores também enfrentaram há três anos, quando participavam da turma da Y Combinator, e eles…

03:19 …perceberam: “Certo, não existe nada como um teste unitário para aplicações de IA, e precisamos de uma solução para isso”. Então, criaram a Langfuse, que hoje é uma plataforma open source para rastrear, monitorar e aprimorar continuamente seus sistemas de IA. Embora no início fôssemos principalmente uma ferramenta para desenvolvedores, hoje também temos especialistas de domínio como público-alvo. Assim, colaboramos com engenheiros de IA para garantir que o sistema faça o que realmente deveria fazer. Mas, nos últimos provavelmente 8 a 12 meses, também surgiu um novo grupo de usuários: agents de programação que ajudam nossos engenheiros a trabalhar com aplicações de IA…

03:50 …e aprimorá-las. Hoje, mais de 150 mil desenvolvedores no mundo todo adotaram a Langfuse, em grande parte também graças à nossa estrutura open source. É claro que 21 das empresas da Fortune 50 nos têm como parte da pilha tecnológica central ao colocar aplicações de IA em produção. E, todos os meses, mais de 90 bilhões de observações são ingeridas nas instâncias da Langfuse. O número, é claro, está aumentando, à medida que os agents dão cada vez mais passos e assumem cada vez mais tarefas. Empresas como RAMP,

04:21 Canva, Khan Academy e SUP trabalham conosco. Ao longo dos últimos três anos, é claro, passamos bastante tempo com elas, e uma coisa que percebemos ao trabalhar com essas empresas é que aquelas que conseguem colocar agents confiáveis em produção e aprimorá-los continuamente seguem algo que chamamos de uma espécie de ciclo de engenharia de IA. Trata-se de um conjunto de práticas que ajuda a aprimorar continuamente seu sistema por meio de uma abordagem sistemática. A base disso é sempre…

04:52 …o rastreamento. Rastrear significa registrar todas as etapas do que seu agent está fazendo, mais ou menos como um log, mas, de preferência, de uma forma que você possa inspecionar como pessoa. Monitorar significa encontrar os casos interessantes. O que está dando errado? O que está dando certo? O que devemos analisar mais a fundo? Também significa entender qual é o desempenho médio. Criar conjuntos de dados significa encontrar um conjunto representativo de exemplos que você quer que sua aplicação consiga tratar e definir também como quer que ela os trate. Depois, você quer executar experimentos com eles. Ou seja, testar diferentes…

05:23 …variações do seu sistema para verificar o desempenho e como as coisas estão indo. Depois, é claro, você quer avaliar os resultados. Isso não é algo que se faz uma única vez: você fecha esse ciclo continuamente e busca aprimorar esses agents de IA, aprender com a produção e trazer essas informações de volta para os conjuntos de dados. Mas vamos analisar cada uma dessas etapas um pouco mais a fundo. No caso dos traces, o objetivo mais importante é obter uma visão aprofundada do que seu agent está realmente fazendo. No lado direito da tela, podemos…

05:54 …ver um trace, que também é uma captura de tela da Langfuse. Neste caso, trata-se de um agent de suporte de TI que responde às perguntas dos seus pais para você não precisar fazer isso. Podemos ver primeiro o trace raiz, além do tempo e do custo agregados dessa etapa. Também temos uma divisão detalhada de cada etapa individual que o agent executa: tanto as gerações, que são as chamadas de chat da OpenAI, quanto as chamadas de ferramentas, que aparecem com um pequeno ícone de ferramenta à frente. Assim, temos uma visão detalhada do que está acontecendo e, se…

06:26 …a tela fosse mais larga, também veríamos as entradas, as saídas e todos os metadados envolvidos. Essa é a base para acompanhar o custo, a latência e os tokens envolvidos, além de manter um log que você, como pessoa, pode inspecionar para realmente entender o que está acontecendo. Seus agents de programação também podem trabalhar com esse log, analisá-lo em escala e simplesmente consultar esse registro inspecionável do que realmente aconteceu. Monitorar significa, então, dar sentido a tudo isso em escala, porque, especialmente agora, com níveis cada vez maiores de automação, traces mais longos…

06:56 …e muitos, muitos casos de uso, já não é viável que você, como pessoa, examine esses logs completamente à mão. Na verdade, você precisa de uma maneira de obter métricas agregadas sobre o que está acontecendo e também detectar sinais de que algo está dando errado. Por exemplo, métricas de custo e latência, mas talvez também sinais de qualidade, como se nossas proteções de conformidade foram respeitadas ou quantos usuários estão realmente frustrados com nosso sistema. Quantos estão escrevendo mensagens inteiras em letras maiúsculas porque talvez estejam um pouco chateados com o que o agent acabou de fazer.

07:28 E, sim, tudo isso sendo agregado e, é claro, encontrando também o que é interessante e que você quer investigar mais a fundo. O que você obtém da produção por meio desse monitoramento também é uma das bases que pode usar para construir seus conjuntos de dados. No fim das contas, os conjuntos de dados são uma representação do que você quer que seu agent consiga lidar em produção. Ou seja, todos os casos que podem surgir, incluindo talvez solicitações fora do escopo que você quer que sejam encaminhadas corretamente, garantindo que o agent não tente dar aconselhamento de investimento

07:59 ou responder como estará o tempo em Nova York se, na verdade, ele for apenas um agent de suporte de TI. Esses itens podem incluir tanto a entrada quanto aquilo que você espera que ele produza como saída, que pode ser uma resposta de exemplo, o comportamento esperado que você quer observar ou palavras-chave que deseja ver incluídas. Isso pode então ser usado como um benchmark estável, seja para melhorar e iterar offline, seja como parte do seu CI/CD. Esses conjuntos de dados são então usados para executar

08:30 experimentos. E experimentos são, se vocês se lembrarem da universidade, de estatística ou de algo que tenham estudado, no fim das contas a ideia de variar algo na configuração e observar o que acontece. Por exemplo, mudar um prompt, mudar um modelo, mudar o contexto ou a descrição da ferramenta e ver se ele lida melhor com aquilo com que você realmente queria que lidasse, idealmente isolando os fatores. Então, se você quiser verificar se o mesmo modelo tem um desempenho melhor com um prompt diferente, o ideal é mudar apenas o prompt, e não outras cinco coisas, porque, caso contrário, vai ser

09:01 difícil interpretar o que você está vendo. E, por fim, você precisa de evals ou abordagens de avaliação para garantir que também consiga medir o que está acontecendo nesses experimentos, porque, de novo, você não quer verificar tudo por conta própria. O que, aliás, você provavelmente deveria fazer de vez em quando. Mas ainda assim você também quer abordagens escaláveis, como, por exemplo, LLM as a judge: usar outro LLM para verificar o que o LLM fez. Ou também evals baseados em código, para tarefas como classificação, em que você pode verificar se há uma correspondência exata, ou também verificar o comportamento, o que pode

09:33 ser uma verificação determinística ou, se você estiver verificando coisas como texto todo em maiúsculas. Esse é o ciclo de engenharia de IA. O que observamos com muitos dos nossos clientes é que, dependendo do seu caso de uso, há alguns pontos de partida diferentes. Por exemplo, se você está em um ambiente de baixo risco e está construindo apenas um agent de chat interno, talvez no início nem tenha uma ferramenta de observabilidade. Aí, talvez comece com tracing e adicione alguns monitores só para verificar

10:03 em que situações as pessoas ficam frustradas, mas, de início, você não se preocupa tanto com a parte de evals. Você simplesmente desenvolve a solução ao longo do tempo e vai adicionando esses casos de teste à medida que avança, mas pode ir direto para produção. Porém, se você está desenvolvendo algo voltado para clientes, especialmente em ambientes regulados, provavelmente não quer correr o risco de o agent fazer algo que não deveria. Então, para esses setores regulados, vimos surgir algumas abordagens, e a base

10:33 é sempre o tracing. Você sempre quer saber o que está acontecendo, quais etapas o agent está executando, quais entradas e saídas está recebendo e também quais ferramentas estão sendo chamadas. E, além disso, as equipes de setores regulados encontraram algumas abordagens para construir esses conjuntos de dados de referência, nos quais você pode então iterar e fazer melhorias. E provavelmente todos vocês já ouviram falar de autoaperfeiçoamento. Tudo isso definitivamente depende de um conjunto de dados de referência como base. E há algumas maneiras de chegar lá. Por exemplo, curadoria especializada: trabalhar com

11:05 os especialistas no domínio da empresa para garantir que você está construindo o conjunto de dados de referência. Depois, por exemplo, execuções em modo sombra: você executa o processo manualmente de forma contínua, mas, em paralelo, também deixa o agent em execução e pode comparar sempre como ele teria lidado com o caso, como teria procedido. Assim, você mede a precisão e também constrói seu conjunto de dados de referência. Por fim, como fizemos na minha empresa anterior, execute um sistema totalmente com humano no loop e, com o tempo, divida os dados entre os casos que você tem confiança para automatizar e aqueles que sempre

11:36 quer manter com um humano no loop. Essa foi a introdução. Agora queremos passar para um exemplo mais prático. Para isso, também estou dando as boas-vindas a Donelli de volta ao palco, e vamos analisar juntos como rastrear a execução do seu agent no Langfuse, como avaliar e melhorar seu sistema e como fechar esse ciclo continuamente. >> Oi, pessoal. Como a Annabelle disse, sou Don, mas podem me chamar de Don para facilitar para todo mundo. Só minha mãe me chama de Don quando estou encrencado. É, tudo bem, ótimo. Ouvi algumas risadinhas. Então, ótimo quebra-gelo.

12:08 Então, esse foi o primeiro eval. Deu tudo certo. Agora, o que vou mostrar é um exemplo que criamos para algumas instituições financeiras com as quais estamos trabalhando, porque elas estão nesse processo: constroem seu primeiro protótipo, fazem sua primeira demonstração, mas aí surge a pergunta da liderança ou talvez das equipes: como avaliamos essas soluções agentic voltadas para clientes que estamos desenvolvendo? Quantos de vocês trabalham com serviços financeiros ou finanças? Sim, estamos em Nova York. Então, é claro que todos vocês trabalham. Algum outro setor além de serviços financeiros, algum setor regulado como saúde e coisas do tipo? Certo, legal. Ótimo. Então, acho que isso vai ser muito relevante para vocês. Basicamente, o que tenho aqui é um assistente bancário típico. Qualquer pessoa que tenha serviços bancários provavelmente já viu algo assim em cada um dos seus bancos, certo? Porém, tudo o que acontece nos bastidores é muito importante para o próprio banco ou para a

12:40 instituição, que precisa fornecer informações muito precisas, porque há responsabilidade financeira, há responsabilidade jurídica. Há muitos riscos para o próprio banco ao lançar esse tipo de solução com LLMs, que, como todos sabemos, são inerentemente não determinísticos. Então, queremos garantir que reduzimos a imprevisibilidade e que conseguimos reproduzir os resultados tanto quanto possível, além de identificar os modos de falha e descobrir em que situações o agent nos dá

13:12 resultados que não queremos, para que possamos então melhorá-los. Neste exemplo, tenho algumas coisas que gostaria de mostrar. A primeira é que posso me passar por alguns tipos diferentes de clientes, porque, obviamente, um banco sempre vai ter clientes como o cidadão comum, como eu. Só tenho alguns trocados no banco, mas também haverá pessoas com patrimônio líquido extremamente alto e assim por diante. Então, podemos simular aqui diferentes tipos de clientes. E isso é importante porque queremos saber se o agent consegue respeitar as barreiras de segurança que definimos para esses tipos de personas.

13:42 Outra coisa: se vocês repararem aqui, talvez eu possa ampliar. Também temos a identificação de PII ativada, e todos os dados considerados PII são mascarados automaticamente antes de serem persistidos no Langfuse. Mais uma vez, esse é outro requisito muito importante especificamente para instituições financeiras, que não…

14:13 querem que esses dados

14:44 que persistam, sabe, em um sistema de observabilidade informações como os dados do cartão de crédito, números de Social Security ou informações dos clientes. Eles querem manter isso nos sistemas de registro e, tanto quanto possível, nos sistemas que são deles. Isso também é possível, e vou mostrar alguns exemplos de como podemos fazer isso funcionar. Depois, também vamos verificar se o próprio agent está respeitando alguns dos controles que implementamos, como está sendo avaliado e se os critérios de qualidade que definimos também estão sendo aplicados.

15:14 Vamos medir tudo isso. Vou mostrar alguns exemplos e depois levar vocês aos bastidores do próprio produto para mostrar como configurar isso e como é um fluxo completo de ponta a ponta. Digamos que, neste caso, estou entrando como Anna. Estou perguntando sobre as tarifas de transferências internacionais. É uma pergunta bem simples, que usa apenas uma base de conhecimento. Em poucos segundos, a resposta vai chegar com os resultados da nossa base de conhecimento. Pronto. Aqui vocês podem ver

15:45 que estou exibindo informações que, obviamente, não mostraria a um cliente, mas estou fazendo isso para fins da demonstração. Estou destacando aqui as ferramentas chamadas, as fontes de dados consultadas e também alguns detalhes da configuração deste agent que contribuem para gerar esta resposta. Se eu disser: “Certo, olha, perdi meu cartão. Este é o número. Ele está bloqueado?”, estou inserindo o número do meu cartão de crédito em texto simples, certo? Então, obviamente, isso não é nada

16:16 bom. Portanto, é importante garantir que, embora você não possa controlar o que os usuários inserem no sistema, consiga detectar esse tipo de dado durante a instrumentação e ao criar seus evals. Agora vamos ver, no próprio trace, que o número do cartão de crédito foi, de fato, ocultado. Se eu vier aqui ao Langfuse e abrir meu trace, vocês verão que agora a pergunta aparece como “o número do meu cartão é”, e, no Langfuse, o dado foi completamente ocultado. Isso acontece

16:47 porque tenho uma função de mascaramento que oculta automaticamente qualquer tipo de informação pessoal identificável que eu tenha definido, para que ela não seja armazenada em texto simples no meu sistema. Para mostrar como é uma interação típica, posso ver aqui no topo o prompt enviado pelo usuário. Mas, como vocês sabem, nos bastidores acontecem muitas coisas que não mostramos necessariamente aos usuários finais, mas que são essenciais para nós, como equipes de plataforma e desenvolvedores, entendermos

17:18 como o agent está se comportando, como está atuando e qual é a qualidade das respostas. Posso ver a árvore completa de todas as etapas que ele executou. Aqui, por exemplo, está a chamada ao LLM da Anthropic, as ferramentas disponíveis. Aqui, ele chamou uma lista de ferramentas. Listou as contas e assim por diante. E estas são as respostas. Mas, mais importante, aqui no topo posso ver todas as pontuações que defini para este caso de uso. Vocês veem que elas são calculadas automaticamente

17:49 sempre que o sistema registra uma nova interação ou um novo trace. Também posso registrar coisas como se as informações que forneci ao cliente estão em conformidade com as informações bancárias. Isso significa que, se o cliente perguntar sobre o tempo, não vou fornecer essa informação, porque ela não está em conformidade. Também posso registrar se há algum tipo de modo de falha ou se há guard rails bloqueando alguma resposta que damos ao cliente. Um exemplo disso é quando alguém pode

18:20 chegar e perguntar: “Posso investir minhas economias em bitcoin?”. O próprio banco não deveria fornecer informações sobre isso, porque há implicações envolvidas. O agent lida corretamente com a situação, mas, ao mesmo tempo, sinaliza que se trata de aconselhamento de investimento e que a pessoa precisa falar com um consultor ou fazer outra coisa. Usamos uma pontuação para isso. Se eu voltar ao meu trace, é assim que eu

18:51 vejo isso. Aqui está o guard rail de entrada, que me informa que o principal risco é o aconselhamento de investimento. E, na pontuação, posso ver que a intenção do cliente foi, de fato, buscar aconselhamento de investimento. Assim, posso filtrar facilmente esses casos. Enfim, queria mostrar um fluxo simples. O último exemplo antes de entrarmos no processo completo de criação de um conjunto de dados e de um fluxo de avaliação é

19:22 que também oferecemos suporte a conteúdo multimodal. Digamos que, em vez de os clientes escreverem pelo chatbot, eles liguem para o seu contact center. Podemos vir aqui e dizer: “Quero processar esta ligação”. O sistema vai converter a fala em texto e, depois, o texto será avaliado para identificar se há alguma violação. Posso entrar aqui e ver que o cliente perguntou como bloquear o cartão. Também consigo ver o trace e até mesmo o link

19:53 para a mídia enviada pelo cliente, ou seja, o áudio da ligação feita pelo cliente, além da transcrição e da resposta do assistente. Isso é o rastreamento: como capturar todas essas atividades. Agora, quando tento pensar em como montar ou implementar uma estrutura para avaliar as interações que meus clientes vão enviar pelo meu sistema, precisamos lembrar que, como todos sabemos,

20:24 os clientes são imprevisíveis. Podemos projetar um sistema ou uma solução com uma intenção específica, mas nossos clientes sempre vão encontrar maneiras muito criativas de usar o sistema de outra forma. Também não podemos prever todos os resultados possíveis, especialmente no caso de soluções baseadas em LLM, quando as disponibilizamos para os clientes usarem no mundo real. É aí que começamos a construir nossos critérios de avaliação. Para nós, o ponto central disso é

20:56 a criação de conjuntos de dados. O que é um conjunto de dados? Basicamente, vamos abrir este, que é o genérico. Um conjunto de dados é, basicamente, um conjunto de perguntas e respostas esperadas que permite medir a qualidade das respostas do seu LLM ou da sua solução de IA. Se você vem da área de desenvolvimento de software, gosto de pensar nisso como seus casos de teste. E não acho que alguém aqui que já tenha colocado software em produção faria isso sem passar pela QA, a menos que

21:27 faça merge na main ou em prod — e tenho quase certeza de que a maioria de vocês já fez isso, embora não seja uma boa prática. Eu sei que já fiz, mas enfim. Ao mesmo tempo, é assim que você pode reunir evidências de que submeteu o agent a uma série de etapas ou requisitos que medem tudo o que quer acompanhar. É importante notar que a resposta esperada não precisa necessariamente ser a resposta que o agent vai

21:57 dar. Você também pode querer medir a intenção do agent, ou o que ele deve fazer. Se quiser medir o comportamento, há diferentes maneiras de avaliar a qualidade da resposta. Por isso, normalmente você acaba criando conjuntos de dados diferentes para medir aspectos ou áreas específicas da qualidade da sua frota de agents. Aqui vocês podem ver que tenho um conjunto que, basicamente, faz testes de red team no meu agent e procura ataques de injeção de prompt e

22:28 qualquer tipo de ataque que permita que alguém entre e contorne as guardrails que implementamos para, então, fornecer informações que essa pessoa não deveria receber. O outro exemplo que tenho aqui é bem específico para um caso de uso: quero saber quais casos foram contestados e em quais a contestação não foi resolvida. Então, a ideia aqui é que eu possa selecionar e organizar conjuntos de dados específicos não só para o caso de uso

22:59 mas também para os requisitos técnicos que tenho para esse agent. É aqui que eu diria que, infelizmente não — porque ainda acho que nós, humanos, somos muito importantes —, você ainda precisa ter seus especialistas de domínio no processo, trabalhando com as equipes de desenvolvimento para definir quais são esses requisitos. Há duas maneiras principais de criar seus conjuntos de dados de referência. Você pode ter uma equipe — e já vi variações das duas opções — que já tenha uma planilha em algum lugar. Nela estão todas as coisas que queremos testar no meu

23:30 agent, e é só enviar a planilha; isso é bem fácil. Você pode vir aqui e dizer: “Certo, perfeito, quero criar um conjunto de dados de teste” e, em seguida, enviar um CSV. Você pode enviar o CSV, e ele vai trazer exatamente tudo o que você tinha antes. Outra coisa que quero mencionar é que tudo o que estou mostrando também pode ser feito da mesma forma pela nossa CLI, pelo MCP ou pelas nossas APIs. Só que acho que é melhor mostrar isso em uma interface de usuário do que pedir ao Claude para fazer tudo de ponta a ponta. Não se engane. Certo. Então,

24:00 isso é tudo sobre essa parte, mas também posso vir aqui e dizer que quero adicionar itens ao meu conjunto de dados, por exemplo, itens que já fazem parte dos meus traces de produção. Digamos que você tenha visto como eu já estava coletando muita atividade do meu aplicativo. Posso vir aqui e dizer que quero adicionar tudo isso ao meu conjunto de dados e, em seguida, selecionar o conjunto de dados que quero usar. Então,

24:30 assim, você pode, de certa forma, usar o conjunto de dados que vai utilizar no próprio produto, analisando os traces de produção gerados pelo seu agent, desde que tenha determinado que, sim, esses são bons exemplos do que quero que sejam as saídas ou os traces futuros. Agora, um processo importante que sempre gosto de destacar é a análise de erros. Certo? A análise de erros é basicamente a ideia de que quero

25:02 analisar meus traces, e acho que Annabell também falou disso com muita eloquência quando esteve do outro lado, como usuária do Langfuse — estávamos conversando sobre isso hoje mais cedo. Ela passou dias, literalmente, analisando traces; esse era o trabalho dela: olhar para o trace, a estrutura, quais eram as saídas e tudo mais. E esse ainda é um processo muito importante, porque, quando você analisa o trace, começa a entender como o agent está se comportando, se está executando todas as etapas

25:34 necessárias, se está chamando todas as ferramentas que precisa chamar e se está fornecendo a saída que você quer. Isso é muito, muito importante. Mas como simplificar esse processo? Porque, obviamente, não é viável que eu, como pessoa, analise milhares de traces quando o sistema está em produção. Então, o que normalmente fazemos é selecionar uma amostra representativa do nosso sistema de produção, com traces para que um especialista humano analise e me dê

26:05 feedback. Certo? É como dizer: “Olha, tenho toda essa atividade. Vou selecionar apenas 10% ou 20%”. Posso dizer que quero me concentrar somente nos casos em que o cliente está falando sobre, sabe, contestações ou informações de cartão de crédito; seja qual for o filtro que você quiser, pode aplicá-lo. Depois, você pode criar para eles o que chamamos de fila de anotação. Nessa fila de anotação, na prática, você está dizendo a um especialista de domínio — digamos que, neste caso, sou eu —: “Você é o especialista em riscos.”

26:36 Preciso que você analise essa saída que o agent está nos fornecendo, ou fornecendo aos nossos clientes, e me dê sua opinião. E o importante aqui é tornar tudo muito, muito simples para o especialista de domínio, porque, obviamente, ele tem o trabalho dele. Não pode passar horas analisando isso. Então, normalmente, recomendo oferecer algumas opções de avaliação, como sim ou não, verdadeiro ou falso, uma escala de 1 a 10, seja lá o que

27:08 for. E então a pessoa também pode vir aqui e deixar um comentário. Digamos que, neste caso, o modo de falha seja a falta de uma citação. E vou adicionar um comentário: “A citação não está incluída. Precisa ser incluída em todos esses casos”, certo? Você vai passar por esse processo, e veja como foi simples para mim. Levou, o quê, talvez 10 segundos. Então,

27:40 digamos que eu tenha, sei lá, cem desses casos e que cada um leve 30 segundos. Isso dá 50 minutos. Não, nem isso. Certo. Hoje não estou muito bem de matemática. Mas enfim, você entendeu a ideia, certo? Você pode dizer ao seu especialista de domínio: “Olha, preciso de uma hora do seu tempo. Vou selecionar várias atividades para você. Só me dê sua opinião. Deixe alguns comentários.” E agora, com o Whisper Flow ou algo do tipo, a pessoa pode simplesmente ditar. Nem precisa digitar, certo? Então, torne tudo muito simples. A segunda coisa que você vai fazer com isso, vou

28:10 marcar como concluído. Agora, essa anotação humana fica junto ao trace como evidência. Mas a segunda etapa que quero fazer é pegar todas essas informações, todas as anotações que nos deram, e usar um LLM para encontrar todos os modos de falha ou as categorias que formam padrões entre os comentários. Certo? Então, você não está pedindo à equipe que invente categorias. Está apenas dizendo: “Deem seus comentários espontâneos

28:42 e sem filtros sobre esses traces”, e então você vai usar um LLM para identificar as categorias, porque é nisso que ele é muito bom. É ótimo em encontrar padrões. É ótimo em extrair informações de textos. Assim, você simplifica o trabalho do especialista de domínio e usa o LLM para aquilo em que ele é bom. Agora, quando tiver todas essas categorias, é aí que podemos passar aos nossos modos de falha. E esses modos de falha, se eu vier aqui e olhar meus experimentos, são aquilo

29:13 que você vai ver sempre que eu executar uma avaliação: todos esses aspectos em relação aos quais estou medindo. Talvez eu abra aqui. Então, depois que o especialista de domínio me dá as informações, eu extraio as categorias mais comuns que aparecem no meu conjunto de dados, com base no que disse o especialista de domínio. Aí posso definir quais são meus vetores ou dimensões de qualidade. Vamos chamar isso de pontuações, como costumamos chamar, mas gosto de usar palavras sofisticadas para dizer as coisas. Mas veja aqui: um dos critérios era citar especialistas, correção esperada das fontes para um registro formal, o que significa que, em alguns idiomas, você quer se dirigir aos seus clientes com um tom mais formal; se o idioma corresponder ao usado pelo cliente, deve incluir o que não foi solicitado, e assim por diante. Então, agora que tenho essa base de categorias que vou usar para avaliar a qualidade das minhas saídas, posso decidir: certo,

29:44 com palavras rebuscadas para dizer as coisas. Mas vocês veem aqui como, em um dos casos, os especialistas do site esperavam correção da fonte e registro formal, ou seja, sabem que, em alguns idiomas, você quer se dirigir aos seus clientes em um tom mais formal; se o idioma corresponder ao que o cliente usou para entrar em contato, é preciso incluir itens não solicitados, e assim por diante. Então, agora que tenho essa base de categorias que vou usar para avaliar a qualidade das minhas respostas, posso decidir: certo…

30:16 Legal. Então, como vou dar uma nota para isso, certo? Que tipo de nota é essa? Que tipo de avaliador é esse? Para isso, posso vir aqui e criar minha própria biblioteca de avaliadores, certo? Assim, quando essas traces chegam, como você sabe, elas calculam automaticamente essas notas para mim. Mas, ao mesmo tempo, posso fazer com que as notas sejam calculadas diretamente pelo aplicativo cliente sempre que algo

30:46 acontece online, em tempo real, para que eu possa apresentar o resultado de volta ao sistema. Basicamente, quero ter uma maneira de medir as saídas do agent tanto com notas de LLM as a judge ou avaliadores quanto com avaliadores determinísticos. Outra lição que aprendemos trabalhando com esses clientes é que, quanto mais você conseguir ter uma combinação equilibrada — dependendo dos tipos de categorias que

31:16 identificar — entre avaliadores de LLM as a judge e avaliadores determinísticos, melhor. Isso porque, se você depender 100% apenas de LLM as a judge, existe uma chance diferente de zero de que algumas das saídas não sejam precisas, porque essa é simplesmente a natureza dos LLMs. Mas, se incluir algumas verificações determinísticas, que sempre serão exatamente iguais para as mesmas entradas, independentemente do que

31:47 aconteça, você poderá ter uma nota combinada ou uma avaliação combinada da qualidade do seu agent. É isso que normalmente gostaríamos de ver. E você vê aqui que, quando estou tentando definir um novo avaliador, posso vir aqui e dizer que quero um novo avaliador de LLM as a judge ou um avaliador de código. Posso definir todos os detalhes de como vou avaliar a atividade específica desse agent. Então, é isso. E

32:18 se eu quiser ter um avaliador de código, você vê que isso é apenas código. É uma função. É código. Isso é muito simples. É apenas uma expressão regular. Ela faz uma correspondência exata. Mas isso vai me dar a mesma saída 100% das vezes. Não vai ser 95% ou 80%. Sempre vai dar exatamente a mesma saída para a mesma entrada. Então, de novo, a lição aqui é que você deve usar uma combinação dos dois. Isso sobre avaliação. Agora falamos, como Annabelle disse,

32:48 e talvez eu volte aqui ao ciclo de engenharia de IA. Falamos sobre criar os conjuntos de dados. Vimos como podemos então operacionalizar a medição da qualidade desses agents executando experimentos. E talvez eu volte aqui. Basicamente, um experimento é baseado em um conjunto de dados. Esses são meus casos de teste. São as tarefas que vou executar com meu agent. E agora vou dizer: sabe de uma coisa? Hoje, esse agent

33:19 está sendo executado com este system prompt, este modelo e estas ferramentas. O que acontece se eu mudar o modelo? O que acontece se eu fizer uma alteração no system prompt? O que acontece se, de repente, eu der acesso a novas ferramentas para acessar novos dados? Então, você quer conseguir prototipar isso antes de, sabe, promover para produção e simplesmente executar no improviso, que é basicamente o que todos nós temos feito, certo? É tipo: “Ah, sim, parece bom. Vou simplesmente enviar para produção.” Mas essa é uma maneira sistemática de fazer

33:51 isso. Daqui a alguns minutos, vou mostrar como incorporar isso ao seu pipeline de CI/CD, para que você não precise participar do processo. Assim, sempre que houver uma alteração no seu agent, uma tarefa de CI será iniciada para executar o experimento com o conjunto de dados. Ela vai avaliar seu agent com a nova configuração e efetivamente fornecer uma aprovação ou reprovação com base em todas as notas e em todos os avaliadores que mencionei antes. Assim, você terá uma maneira consistente de avaliar e medir as saídas desses agents.

34:23 Faz sentido? Certo, perfeito. Então, esses são os experimentos. Ótimo. Falamos de experimentos. Falamos de conjuntos de dados e de anotação humana para incluir as pessoas e seu conhecimento especializado no processo. Então, como junto tudo isso? Certo? Se eu vier aqui e tiver meu prompt — estes são meus system prompts, que versiono aqui no Langfuse. Você pode fazer isso aqui no Langfuse. Sabe, não cobramos por isso. Tudo bem. Não cobramos mesmo. Muitos dos nossos

34:54 clientes têm outra versão no sistema. Têm uma versão no GitHub, GitLab, seja lá qual for. Mas você deve considerar isso como o gatilho para iniciar a automação e fazer sua avaliação completamente de forma automática. Isso funciona assim: já defini uma automação aqui. E, se você vir a configuração, ela é acionada por qualquer alteração nos prompts que tenho aqui. A ação é iniciar uma tarefa de CI no meu GitHub, que é este aqui

35:27 mesmo. Espero não receber o unicórnio do GitHub. É este aqui. Já configurei minha CI, que está aguardando qualquer alteração na configuração do meu agent. Deixe-me aproximar aqui. E então posso vir aqui e ver meu prompt. Vamos ver este. Tenho cinco versões do prompt. Veja como o prompt evoluiu ao longo do tempo. Na versão um, ele tinha isto, e depois, na versão dois,

35:59 uma pequena alteração. Depois, na versão três, tentamos algo diferente, sabe? Esta é para desenvolvimento. Na versão quatro, adicionamos mais detalhes e também passamos parâmetros diferentes para a configuração do agent. Mas agora posso dizer: “Sabe de uma coisa? Este é o system prompt de produção que tenho agora. Quero testar novamente a versão quatro porque percebi algumas regressões.” Então posso vir aqui e selecionar “promover para produção”. E, de novo, estou mostrando isso como uma pessoa, sabe, como um homem das cavernas, clicando

36:30 por tudo. Tudo isso pode ser feito pela API ou pela CLI. Então você nem precisa fazer isso manualmente. Pode simplesmente chamar a API e dizer para promover esta versão do prompt com uma tag de produção, e ela vai iniciar o processo para você. Tenho a tag de produção. Vou salvar e promover para produção, que é a nova configuração. Em alguns segundos, devemos ter uma nova tarefa de CI que vai ser iniciada aqui e, então, iniciar o experimento para executar minha avaliação. Certo, lá

37:01 está. Obrigado, GitHub. Muito obrigado. Perfeito. Agora tenho esta tarefa sendo executada automaticamente. Assim, sempre que eu enviar qualquer alteração na configuração do meu agent, ela vai chegar à CI. A CI vai executar as verificações de aprovação da avaliação para me dizer se passei ou falhei em algum dos avaliadores que definimos antes. Desse modo, posso ter as evidências e também a garantia de que posso entrar em produção com segurança usando essa nova configuração — se o agent está de fato piorando ou

37:33 melhorando em qualidade, ou talvez até violando alguma das barreiras de proteção que implementei. Isso vai levar alguns minutos, mas deixe-me mostrar um experimento que executei antes. Para mostrar o resultado, posso vir aqui e ver a saída. Ela me mostra o prompt enviado, a versão, os rótulos e, em seguida, indica que foi aprovado, certo? Perfeito. Estes são os avaliadores usados para avaliar meu agent. Tenho aqui o conteúdo obrigatório, a cobertura das fontes, a correspondência do idioma, a correção e a ausência de ofertas adicionais não solicitadas. Também posso definir valores mínimos. Posso dizer que este é o limite mínimo para esta nota específica. Se não atingir esse limite, não será considerado aprovado para entrar em produção. Agora, obviamente, neste caso, não sou louco a ponto de simplesmente dizer: “Certo, passou, faça o merge e envie para a branch main.” Vou deixar assim. Mas, reconhecidamente, você poderia ter um processo completo, de ponta a ponta, que

38:04 a recuperação da fonte, a correspondência do idioma, a correção e a ausência de ofertas adicionais não solicitadas. E também posso definir mínimos. Posso dizer: este é o limite mínimo que estabeleci para essa pontuação específica. Se não atingir esse limite, não será considerado aprovado para entrar em produção. Agora, obviamente, neste caso, não sou louco a ponto de simplesmente dizer: certo, legal. Você passou; integre e envie para a branch main. Estou apenas deixando isso parado ali. Mas, admitidamente, você poderia ter um processo completo de ponta a ponta que…

38:36 vai simplesmente criar o PR para você e vai esperar alguém revisar o PR ou talvez, se você for como todo mundo está fazendo hoje, simplesmente enviar o PR direto para main, se ele passar pelo critério. Mas pelo menos você tem as evidências aqui, certo? Então, você não está enviando um PR baseado só em intuição ou no que acha que o agent é bom em fazer. Na verdade, você tem o histórico documentado, por assim dizer, e as evidências que explicam por que tomou essa decisão para essa nova

39:06 configuração do agent. Perfeito. Agora quero mostrar mais algumas coisas como um caso de uso real, certo? Porque falamos bastante sobre os aspectos técnicos do Langfuse, e cada vez mais as organizações estão muito focadas na economia de tokens, certo? Acho que, no início de 2026, todo mundo estava tentando maximizar o uso de tokens; agora todo mundo está tentando extrair valor dos tokens, ou seja lá como estão chamando isso. Então, todo mundo está tentando extrair o máximo de valor possível dos tokens.

39:38 Agora, deixa eu mostrar algumas maneiras de apresentar isso aos seus chefes, líderes ou a quem for. Talvez você queira desenvolver isso para as partes interessadas do negócio, para que se sintam um pouco mais tranquilas e tenham certeza de que a solução com agent que você está desenvolvendo realmente traz benefícios para o negócio. Isso não é só uma coisa legal que estamos desenvolvendo.

40:08 Tenho aqui um dashboard em que estou tentando reunir algumas métricas que posso apresentar ao negócio com base nos dados que estou coletando do meu agent. Certo? A primeira é — e talvez você discorde da lógica por trás disso, mas sabe, cada organização é diferente — que esse agent teve 1.400 interações nos últimos

40:39 sete dias que não precisaram ser encaminhadas a um atendente humano, certo? Isso é ótimo. Significa que estou economizando, sabe, mão de obra humana que seria usada para conversar com os clientes. E façam as contas: quanto isso me custou? Menos de US$ 7, certo? Nos últimos sete dias. Se você pensar em qualquer atendente — eu trabalhava em um contact center há 20 anos, antigamente — sabe quanto se paga a essa pessoa: US$ 15 ou US$ 20 por hora, certo? Essa pessoa

41:12 não vai atender 1.400 chamadas em uma hora. Então, você já está mostrando pelo menos um benefício para o negócio, ainda que aproximado, por ter essa solução em funcionamento, certo? Essa é a primeira coisa. A segunda é que você também pode começar a identificar em que situações o agent está falhando. Se vocês se lembram, definimos as categorias, ou modos de falha, como chamamos na área, em que o agent não me dá os resultados ou as respostas que quero. E estes são

41:43 os casos que estou registrando, em ordem de ocorrência, nos últimos sete dias. Vejam que agora, fora do escopo, registro informal e disputa não resolvida são meus três principais problemas, e eles vêm aumentando com o tempo. Então, em vez de eu ter que analisar milhares ou centenas de milhares de traces para descobrir qual atividade do agent está causando mais erros ou problemas, posso vir

42:14 aqui e restringir o escopo. E já sei que esse modo de falha é o principal: fora do escopo, registro informal e disputa não resolvida. Então, posso acessar o tracing e aplicar um filtro bem simples: disputa não resolvida. Posso salvar isso como uma visualização. Assim, não preciso aplicar o filtro toda vez. Vejam como ele está filtrando os resultados para mim no topo. E, na lateral, também posso selecionar disputa não resolvida igual a zero. Isso mostra todas as

42:45 instâncias em que o cliente teve uma disputa ou pediu para contestar um produto, e o agent não resolveu a questão. Ou o caso precisou ser encaminhado a um atendente humano, ou ficou sem solução até a sessão ser encerrada. Mas agora, em vez de analisar milhares de casos, posso restringir o escopo a algumas dezenas ou centenas. E assim posso fazer uma investigação mais direcionada. Também posso descobrir em que situações o próprio agent está tropeçando. Então,

43:18 essa é uma coisa. A segunda é que, se eu acessar os dashboards, quero poder ver quantas vezes os clientes deram uma avaliação positiva ou negativa. Posso registrar isso facilmente como uma pontuação. Vejam: posso registrar cada avaliação positiva ou negativa e simplesmente exibi-la aqui em um dashboard, fácil de entender. Qualquer pessoa do negócio, qualquer usuário — qualquer pessoa, na verdade — vai poder

43:49 ver isso e dizer: “Certo, a maioria das avaliações é positiva, legal. Mas e as negativas? Vamos nos concentrar nelas. Sabe, 18% delas: o que está acontecendo?” A outra coisa é a parte de segurança. Aqui, a boa notícia é que a maioria das interações do agent com os clientes não apresenta nenhum tipo de risco. Mas vemos que, em 89 casos nos últimos sete dias, o cliente estava pedindo

44:21 aconselhamento sobre investimentos, e o agent pode ter dado ou tentado dar esse tipo de aconselhamento. Então, podemos nos concentrar nesses casos. E, de novo, é a mesma coisa. Posso voltar à visualização padrão. Agora, em vez da pontuação numérica, posso selecionar as pontuações categóricas, adicionar uma condição e indicar qual é a intenção ou o risco de segurança; depois, seleciono “aconselhamento sobre investimentos” como risco de segurança. E assim posso ver quais são os

44:54 exemplos específicos em que o aconselhamento sobre investimentos foi identificado como motivo para sinalizar o caso e em que o agent não deveria interagir com o cliente sobre esse assunto. E vocês podem ver isso até no exemplo anterior que mostrei. Então, era isso que eu queria mostrar sobre a natureza de desenvolver uma solução de ponta a ponta, voltada para o cliente. Obviamente, isso tem muitas implicações críticas em termos de responsabilidade e

45:26 de consequências financeiras e reputacionais, porque você não quer apresentar aos seus clientes informações incorretas ou alucinadas. Também mostrei como seguir um processo sistemático para reunir evidências e validar que as respostas desses agents estão, de fato, respeitando as proteções e os controles que vocês implementaram. Com isso, gostaria de passar a palavra novamente para Annabelle, para encerrarmos e talvez respondermos a algumas perguntas

45:57 no final. Obrigado. >> O que vemos algumas empresas ou equipes tentando fazer é o seguinte: “Conserte meu agent. Não cometa nenhum erro.” E provavelmente há algumas coisas que podemos recomendar menos do que isso. Mesmo que seu agent esteja conectado via MCP ou CLI aos seus dados no Langfuse ou em qualquer outra ferramenta que você use, isso é algo que vemos produzir mais conteúdo de baixa qualidade do que qualquer coisa que realmente ajude. Mas, claro, também somos muito a favor de

46:28 trabalhar com seus coding agents para melhorar continuamente suas aplicações. Então, queríamos compartilhar esta imagem como uma forma de ajudar vocês a se lembrarem. Aqui temos dois eixos. Um deles representa o tempo investido: muito tempo ou muito pouco tempo. O outro representa um sistema de baixa ou alta qualidade, e você não quer ficar naquela região de baixo. Se automatizar tudo e simplesmente deixar o agent agir, dizendo “conserte tudo, faça isso por mim”, então…

47:00 não vai dar certo. Você vai acabar com baixa qualidade e, sim, não precisa fazer nada, mas seus clientes também não vão ficar muito satisfeitos. Ao mesmo tempo, você também não quer mais seguir pelo caminho totalmente manual. Não quer mais instrumentar seu app por conta própria. Isso é algo que pode ser automatizado. Você não quer identificar todos os modos de falha por conta própria nem revisar todos os dados por conta própria. Isso pode ser automatizado. Mas, ao mesmo tempo, em algumas coisas, você deve trazer seu próprio julgamento. Deve trazer seus especialistas no domínio para construir os conjuntos de dados e selecionar o que realmente é o problema que

47:31 sua aplicação deve resolver e em que direção você quer que ela siga. E, para isso, você quer chegar a algum ponto aqui. O equilíbrio ideal é entre você revisar os dados, trazer seu julgamento e sua experiência no domínio, mas também trabalhar com seu coding agent em tudo o que pode ser automatizado, como instrumentar a aplicação, encontrar modos de falha, executar evals e talvez também fazer 20 experimentos em vez de apenas um, que seria o número que você conseguiria fazer, e, sim, evitar chegar àquele canto inferior esquerdo; em vez disso, tentar ser o

48:02 engenheiro de IA criterioso, que traz seu julgamento e garante que os e-mails sejam ótimos; assim, você também pode automatizar cada vez mais esse ciclo ao longo do tempo. Se estivéssemos no seu lugar e tivéssemos que começar amanhã, instalaríamos a skill da Langfuse, que é uma skill de agent. Ou seja, um conjunto de arquivos Markdown que ajuda seu coding agent a entender como trabalhar com a Langfuse e implementar essas boas práticas. Ela está conectada à nossa documentação e a todas as nossas páginas de integração. Também está conectada à nossa

48:33 Academy, onde ensinamos as boas práticas sobre conjuntos de dados, como instrumentar, como escrever avaliadores e tudo isso. Então, é um ótimo ponto de partida para fazer automaticamente aquilo que deve ser feito automaticamente, mas também para talvez selecionar um conjunto de dados que você deve analisar manualmente. Depois, você deve começar a coletar também ground truth com o qual possa avaliar seu agent, talvez a partir de dados históricos, da produção ou de algumas amostras que você esteja analisando com seus especialistas no domínio. E, se você atua em um setor regulado,

49:04 defina seus limites rígidos de modo a garantir que certas coisas definitivamente não aconteçam. Por exemplo, em serviços financeiros, o agent nunca deve dar conselhos de investimento. Portanto, inclua isso no seu conjunto de avaliação: idealmente, isso nunca acontece, mas, pelo menos, você ficará sabendo quando acontecer. E temos alguns recursos para vocês. O repo que a Donelli mostrou e usou também está disponível online. Vocês podem conferir. Podem pegar o que quiserem e também usar nos seus próprios casos de uso. Ele contém

49:35 dados fictícios, é claro, e não dados que tenham sido obtidos dos nossos clientes. Acho que esta sessão também será gravada, então vocês poderão assistir de novo. Também recomendamos a Langfuse Academy, que é um material mais completo sobre como fazer engenharia de IA, com todas as etapas descritas novamente. Também temos um workshop autoguiado que basicamente orienta vocês por todas as etapas, para que entendam tudo uma vez e depois possam seguir com a própria aplicação. Há algumas oportunidades para nos encontrar

50:06 nos próximos dias. Uma delas é a palestra da Donelli sobre como criar barreiras de deploy para agents de IA, na quarta-feira. Confiram se quiserem entender como garantir que os modelos de IA que vão para produção realmente passem pelos critérios de qualidade. Também temos um estande, o estande 9. Não verifiquei onde fica, mas tenho certeza de que vocês vão encontrá-lo. Vocês podem conhecer a equipe lá e também ganhar adesivos personalizados. Tirem uma foto do rosto de vocês e a IA gera adesivos com o rosto de vocês e a Langfuse, talvez com algumas piadas também

50:36 incluídas. Vocês podem levá-los para casa e colar em tudo o que tiverem. E, por fim, também vamos fazer uma corrida comunitária. Se quiserem sair do centro de conferências e conhecer a equipe, teremos dois dos nossos fundadores aqui e mais alguns integrantes da equipe. Todos nós gostamos muito de correr, então pensamos em convidar todo mundo para participar também. Então, sim, venham também. E ficaremos muito felizes em usar os minutos restantes para responder a qualquer tipo de pergunta. Também temos alguns adesivos que não são personalizados. É só um adesivo da Langfuse, mas acho que ainda é bem legal. Então, se quiserem alguns,

51:06 podem vir aqui pegar. Ficaremos felizes em responder a qualquer pergunta. E, por favor, venham falar conosco, não sejam estranhos. Vou passar a palavra para a Delli. >> Sim. Bem, a Langfuse tem uma dependência rígida do ClickHouse para os bancos de dados. Isso é simplesmente porque, na evolução do produto, começamos com Postgres. Mas o Postgres não conseguia lidar com a escala que alcançamos, com bilhões e bilhões de eventos por dia. Foi quando migramos para o ClickHouse. Então, em relação a essa camada de dados, sim, usamos o ClickHouse. Mas talvez a pergunta complementar para você seja: qual é a sua necessidade em relação aos bancos de dados? Porque também oferecemos a possibilidade de exportar os dados. Você pode exportá-los para o S3; pode usar a API, a CLI ou o MCP se quiser consumir os dados da Langfuse. Então, fica totalmente a seu critério. >> Quero hospedar isso em… >> Sim, você pode hospedar tudo na Amazon. Também temos uma opção de deploy autogerenciada. Você pode usar nossa oferta na nuvem, que é totalmente SaaS e pronta para uso; não precisa fazer nada, ela roda na Amazon. Mas, se quiser executar

51:37 a infraestrutura por conta própria porque tem, sei lá, algumas instâncias EC2 disponíveis que quer usar, também temos um modelo de deploy para isso, que já vem com todos os componentes. >> Sim, pergunta superimportante. A pergunta era sobre a confiabilidade dos avaliadores e também, provavelmente, sobre a consistência dos avaliadores LLM as a judge, para garantir que estejam realmente detectando o que vocês querem que detectem. Isso também é tratado pela skill da Langfuse, que ajuda vocês com isso. Há um termo para esse processo, mas me fugiu agora. No fim das contas, trata-se do

52:08 processo de garantir que o LLM julgue como um ser humano julgaria. O que você faz, basicamente, é avaliar uma amostra, idealmente representativa, por conta própria; depois, executa seu LLM as a judge e otimiza para que ele seja consistente com as avaliações feitas por avaliadores humanos. Idealmente, você tem alguns avaliadores humanos; essa é a abordagem acadêmica. A abordagem prática provavelmente é pedir a uma pessoa que rotule alguns dados e, então, otimizar em relação a esse ground truth. Depois, o ideal é conferir isso ao longo do tempo para garantir que seu conjunto continue sendo

52:39 representativo. E, especialmente se você estiver usando isso para executar avaliações em dados de produção, o ideal é começar com um pouco mais de falsos positivos, para detectar um pouco mais do que o necessário, mas sem deixar nada passar. Depois, basta ajustar ao longo do tempo.

53:09 representativo. E, especialmente se você estiver usando isso para executar avaliações em dados de produção, o ideal é começar com um pouco mais de falsos positivos, para detectar um pouco mais do que o necessário, mas sem deixar nada passar. Depois, basta ajustar ao longo do tempo.

Transcrição original

[00:12] All right, let’s get started. Welcome everybody to our workshop on evaluating AI applications with Lancuse. My name is Annabelle. I’m a um AI engineer uh AI solutions engineer at Langfuse. And I’m today joined by my um colleague Donelli who is leading AI solution architecture at Langfus. So working with our biggest customers on making sure they actually shipping reliable agents to production. I myself uh was in my previous life how I like to call it because it feels like a lifetime in a company building AI agents for medical device compliance.

[00:43] And in this industry it was super important to make sure we are running. We’re making sure we have ground truth data set that is validated by our customers and we also ran a lot of human in the loop systems and a lot of my time I actually spent in Lenfuse and at some point I decided okay why not swap sites and also help other teams that are shipping agents especially also in regulated industries and uh joined the langu team uh roughly seven months ago. So but before we dive right into it we wanted to get a little bit of a feeling of who is here today and who we are um

[01:15] yeah coming together with. So uh we were wondering who of you has brought AI agents to production before and with that I mean been part of a team doing it not necessarily yes someone in the company did it so actually like been part of a process to bring it to production okay that’s good amazing it’s a lot of people and we hoped uh to have this also and who of you has worked with languages before okay quite some and any other kind of observability in evas tool

[01:46] Okay. Yeah, also a few uh amazing. And then finally, who has solved EVAs for AI applications? For the confident hands, I would love you to come by at our booth and explain us how. Um because actually it is quite hard and I think um all of you have experienced it if you’re working with AI or also just chatting with Chat GPT or Claude. H it is quite tough uh because AI agents can fail while the system metrics themselves look green. So if you for example look at this example here we

[02:16] have a user support agent and the user is asking can I get a refund. The agent takes in the request looks up some policies and then it’s like yeah sure I issued your refund and the user is like thank you and it will take some days until the user sees if it actually worked out and the status is green. Nothing went wrong in traditional observability terms. There’s also no latency issues. But if we dig deeper into what actually happened, the agent never did refund anything. So the tool was never called. It was never executed.

[02:47] And the agent lied about doing it to the user. And we will only know about it in a few weeks when the user come backs and is like, “Hey, by the way, I never get I’ve never gotten my refund.” And this is the problem that we have with those nondetermin deterministic systems. They might tell us they do things, but they actually don’t. And this is why you have to find an approach and a way to continuously mine for those signals where things are going wrong and make sure they don’t happen again or maybe not even at all in the first place. And this is a problem our founders also faced three years ago when they were in the way combinator batch and they

[03:19] realized okay there’s nothing like a unit test for AI applications and we need a solution for it. So they built Langfuse which is by now an open source platform to continuously trace monitor and improve your AI systems. And while we started out as a dev tool mostly by now we also have domain experts as a target group. So collaborating with AI engineers to make sure the system does what it actually should be doing. Uh but also a new user group for the past probably 8 to 12 months uh which are coding agents that are helping our engineers also to work with AI

[03:50] applications and improve them. Lenfus is by now adopted by more than 150,000 uh developers globally also largely driven by our open source um setup. Of course, 21 of the Fortune 50 have us as part of their core tech stack when shipping AI applications. And every month more than 90 billion observations are ingested into uh length use instances. Uh of course increasing tendency as agents are taking more more and more steps and also taking over more and more tasks. Companies like RAMP,

[04:21] Canva, Khan Academy and SUP uh work with us and over the last three years we of course spend a lot of time with them and one thing we realized working with those companies is that the ones that successfully manage to ship reliable agents and also continuously improve them follow something that we call like some form of this and the AI engineering loop and it is about a set of practices that help you to continuously improve your system by taking a systematic approach. The foundation to this is always

[04:52] tracing. Tracing is about getting all the steps of what your agent is doing into a more or less lock, but ideally also in a way you can inspect it as a human. Monitoring is about finding the interesting ones. So what is going wrong? What is going right? Where should we look deeper into? But also understanding how is it performing on average. Building data sets is about finding a representative set of examples that you want your application to be able to handle and also how you want it to handle it and then you want to run experiments on it. So try different

[05:23] variations of your system to check um how it is performing, how it’s going and then of course you want to evaluate how it’s going and this is not something you do once but you continuously close this loop and want to improve uh those AI agents and learn from production and get get it back into data sets. Uh but let’s dive in each of those steps a little bit more into detail. So for traces, the most important goal is that you want to get deep insights into what your agent is actually doing. On the right side of the screen, we can

[05:54] see a trace that is also a screenshot from Lenfuse and in this case it’s an IT support agent. So an agent that is answering questions from your parents so you don’t have to do it. And we can see that there’s first like the root trace and we can see aggregate um time and also uh costs of this step. But we then also get a breakdown of each of the individual steps that agent is taking. So both the generations which are the open AAI chat ones and also the tool calls which we can see with a little tool in front of it. So we have a detailed view of what’s going on and if

[06:26] the screen would be wider we would also see that we can see the inputs and outputs and all the metadata involved. This is then the foundation to track the cost, the latency, the tokens involved, and also have a log to inspect for you as a human to really dig into what’s going on, but also for your coding agents to work with it and look at it at scale and just have this this inspectable lock of what’s actually been going on. Monitoring is then about making sense of it at scale because especially now with increasing uh automation levels, longer

[06:56] traces and like a lot a lot of use cases. It’s just not feasible anymore for you as a human to look through those logs completely manually. But you actually want a way to get aggregate metrics on what’s actually going on and also uh detect signals where things are going wrong. So for example, cost and latency metrics, but maybe also quality signals like our compliance guardrails um kept true to or also like how many users are actually frustrated with our system. How many are writing all caps messages because they are maybe a bit upset with what uh the agent just did

[07:28] and um yeah all of this aggregating and then u of course also finding the interesting stuff that you want to dig deeper into. what you get from production through this monitoring is then also one of the foundations um that you can use to build out your data sets and data sets are in the end a representation of what you want your agent to handle in production. So all the cases that it might be getting also maybe out of scope requests that you want to like correctly also be deferred and make sure that like the agent is not trying to give investment

[07:59] advice or also uh answering what the weather in New York is going to be like if it’s actually just a dead IT support agent. And those um items you can then have like the input but also what you expect um it to have as the output which can both be like a sample reply or also expected behavior that you want to see or keywords you want to have covered. And this can then be used as a stable benchmark either for like improving and iterating offline or also as part of your CI/CD. Those data sets are then used to run

[08:30] experiments on and experiments are um if you maybe look back into university and statistics or anything that you might have done. It’s in the end this idea of varying something about your setup and looking what happens then. So for example, changing a prompt, changing a model, changing the context or the tool description and to see if it’s then better dealing what you actually what you with what you actually wanted to deal with and ideally isolating concerns. So if you want to check if the same model performs better with a different prompt, you ideally only change the prompt and not five other things because otherwise it’s going to

[09:01] be hard for you to interpret what you actually see. And then finally, you need evals or evaluation approaches to make sure you can also measure what’s happening in those experiments because again you don’t want to look at everything yourself. Uh which you by the way should should probably sometimes do. Um but still you also want the scalable approaches which are for example LLM as a judge. So using another LLM to check what the LLM did. um or also code based evals for things like um classification tasks where you can check for an exact match or um also checking behavior can

[09:33] be a a deterministic check or if you are checking for all caps type um things. So this is the AI engineering loop and what we observe with um many of our customers is that there’s depending on your use case a few different entry points into this. So if you’re for example in a low stakes environment and you’re only building your internal chat agent, you might first not have a observability tool in place at all and then you maybe get started with tracing and add some monitors to just check

[10:03] where are people getting frustrated but you don’t care about the eval part too much in the first place. You just build it out over time and just like add those test cases as you progress but you can go to production directly. However, if you’re building a case that is customerf facing and especially if you’re building a case that is in regulated environments, you probably don’t want to risk the agent doing something that it’s actually not supposed to do. So for those regulated industries, we’ve seen a few approaches emerging and the foundation

[10:33] is always tracing. So you always want to know what is actually happening, what steps is it taking, what inputs and outputs is it seeing and also what tools are being called. And then on top of this um those teams in regulated industries found a few approaches on how to go about building out these ground truth data sets that you can then also loop on improve on and also you probably all heard about auto improvement. Um all of this definitely needs the foundation of a ground truth data set and you yeah have a few approaches to get there. For example expert curation so working with

[11:05] your domain experts within the company to make sure you’re building out the crown to data set. Then for example shadow runs. So you run the process continuously manually but in parallel you also have the agent running and you can always compare how would the agent have handled it? How would the agent have gone about it and then like this measure the accuracy but also build out your ground truth and then finally um like we did it also in my previous company. Run a fully human in the loop system and over time slice the data into parts where you are confident to automate versus things where you always

[11:36] want a human in the loop. So, so much on the introduction. Uh, we now want to go in a more practical example. And for this, I’m also welcoming Donelli again on stage and we’re going to look together into how to trace your agent execution into length use, how to evaluate and improve your system, and how to continuously close this loop. >> Hi everybody. Like Annabelle said, I’m Don, but you can call me Don to keep it easier for everybody. Only my mom calls me Don when I’m in trouble. Um, yeah, that okay, that’s great. heard a few giggles. So, you know, nice nice

[12:08] icebreaker. So, that’s the first eval. It went perfectly. Um, so now what I’m going to show you is an example that we built for a few financials institutions that we’re working with because they’re in the in in kind of this process of they build their first prototype, they build their first demo, but then the question comes from leadership or maybe from the teams. How do we we evaluate this customerf facing agentic solutions that we’re building? How many of you here are in financial services or in finance? Yeah, we’re in New York. So, of

[12:40] course, you all are. Um, any other industries others than financial services, regulated industries like healthcare and stuff like that? Okay, cool. Awesome. So, I think this is going to this going to speak to you very much. Um, so basically what I have here is, you know, a typical, you know, banking assistant. Everybody, anybody of us that has a banking services probably have seen this in each of of your banks, right? However, the all the stuff that happens behind is you know very important for the bank itself or for the

[13:12] institution to provide you with very accurate information because there is like financial liability, there’s legal liability. There’s a bunch of you know risk for the bank itself to put out these type of solutions when they are powered by LLMs which as we all know are inherently non-deterministic. So we want to make sure that we reduce the unpredictability and that we can then reproduce the outcomes as much as we can and figure out where are the failure modes and where is the agent giving us

[13:42] the results that we don’t want so that then we can you know improve upon those. In this example I have a few things that I I would like to show you. The first thing is that I can impersonate, you know, a few different type of clients because obviously a bank is always going to have customers that are like, you know, your everyday Joe like myself. I only have a couple of bucks in the bank, but then you’re going to have your ultra high net worth individuals and all of that. So, we can have here impersonation of different kinds. And this is important because we want to be able to

[14:13] know if the agent is able to respect any guard rails that we have put in place when it comes to those type of uh personas that we have. The other thing is if you notice here maybe let me blow it up. We also have PII identification uh enabled and any sort of uh data that is deem as PII is automatically masked before it gets persisted into Langfuse. Again, this is another very big requirement for spec specifically financials institutions that they don’t

[14:44] want to, you know, persist in an observability system their credit card information or social security numbers or their clients. They want to keep that on the systems of record and as much as possible in their systems uh that they own. So, that is also enabled and I’ll show you a couple examples on how we can uh get that to work. And then we’re also going to see if the agent itself is respecting some of the controls that we have put in place and how is being scored and if the quality gates that we

[15:14] have defined are also being enforced. So we’re going to me measure all of that. I’m going to show you a few examples and then take you behind the scenes in the product itself to show you how you can set that up and then how an end toend flow looks like. So let’s say that I am, you know, in this case I’m coming in as Anna. I’m asking about international wire fees. Very simple question, just a knowledge base. And then in a few seconds, it’s going to come back and give me the results from our knowledge base. And here you go. You see in here,

[15:45] I’m surfacing information that obviously I wouldn’t surface to a to a customer, but I’m doing it here for the purposes of the demo. But I’m calling out here the tools that are being called, the the data sources that are being called as well and some of the details as well that make up the configuration of this agent when it comes to giving back this answer. If I were to then say, okay, look, I I lost my card. This is my number. Is it blocked? I’m putting my credit card number in clear text, right? So that is obviously that’s not not

[16:16] great. So you want to make sure that even though that the user you cannot control that you cannot control what your uses your users input in the system you want to make sure that you catch that whenever you are instrumenting and whenever you are uh building your evals so now we’ll see in the trace itself that the credit card will be indeed redacted if I come here to langfuse and I open my trace you’ll see that now the question is my car number is and then it landed in LA completely redacted That is

[16:47] because I have a masking function that automatically any sort of PI information that I have defined will be immediately masked and then is not persisted in plain text in my system. So just to show you uh in terms of what a a typical interaction looks like and I can see from the top here this was the the prompt that the user sent but then as you all know behind the scenes there’s a lot of stuff going on that we don’t necessarily surface to our end users but are critical for us as the platform teams as the developers to understand

[17:18] how the agent is is behaving performing and the quality of the outputs as well. I can see the entire tree of all the steps that he took. You know, here the the the anthropic LLM call that he made, the tools that are available. Here it called a list of tools. It listed the accounts and and so forth. And these are the outputs. But then more importantly here on the top, I can see all the scores that I have defined for this particular use case. You see that they’re they’re automatically calculated

[17:49] whenever there’s a a new interaction or a new trace being captured by the system and I can I can capture things if you know down from if the information that I gave to the customer is compliant with banking information meaning that the customer is asking about the weather I’m not going to give that information it’s not compliant um if there’s any sort of failure modes um if there’s any guard rails that we’re that we’re blocking any any answers that we’re giving back to the customer. One example of that is for instance I can come someone can might

[18:20] come and ask can I put my savings in bitcoin right so that is something that the bank itself shouldn’t be providing information about that because that is you know that has some ramifications and the agent you know correctly does that but at the same time it is flagging it as investment advice and this requires you know for the person to either talk to an advisor or or something else and we are using a score to do that. And if I go again to my trace, this is how I

[18:51] see it. I have the input guard rail here that tells me that this is the primary risk is investment advice. And in the score here, I can see that the intent of the customer on this score was indeed investment advice. So that way I can very easily go out and filter for those in particular. But anyways, I wanted to show you kind of a simple flow of this. The last one before getting into the end to end on how you build a data set and how you build an evaluation flow is that

[19:22] the fact that we can also support multimodal. So let’s say that instead of you having the customers writing via chatbot they’re calling your contact center. We can come here. We can say I want to process this call and this going to do a speech to text and then the text is going to be evaluated to to figure out if there’s any violation on on here and I can come then in here it says that the customer was asking about blocking his card and I can indeed see the trace here and I can even see the actual link

[19:53] to the media that the customer was sent or in terms of that audio uh or that call that the customer made and also the transcript and what the assistant gave back. So that is in terms of the tracing how can I capture all of those activities. Now when I am trying to then think about okay how do I then put together or put in place a framework on how to evaluate this interactions that my customers are going to be sending through my system because as we all know

[20:24] customers are unpredictable. We might design a system or a solution with a a specific intention, but our customers are always going to find very clever ways to use a system in a different way. And we also cannot anticipate every single outcome specifically with LLM power solutions that are going to happen when we we release this into the wild for customers to use. So that is when we start relying on building our evaluation criteria and for for us the anchor of

[20:56] that is building data sets. So what is a data set? A data set is basically and let’s go to this one that is the the generic one. A data set is basically your set of questions and expected outputs that allow you to then measure the quality of the outputs of your LLM or AI solution. If you come from a software development background, the way that I like to think about this is that these are your test cases. And I don’t think anybody here that has shipped software into production will ship anything without passing into QA unless

[21:27] you merge into main or prod, which I’m pretty sure most of you have done it, but it’s not a best practice. Um, I know I know I have, but whatever. Um, but at the same time, this is the way that you can then have the evidence that you pass the agent through a series of steps or requirements that measure all the things that you want to capture. And one thing to note here that the expected output doesn’t necessarily need to be the answer that the the agent is going to

[21:57] give. It could also you want to measure maybe the intent of the agent. You want to measure what the agent is supposed to do. If you want to measure behavior, there are different ways that you can measure the quality of the output. And that is why you typically end up with different sets of data sets to measure a specific things or or specific areas of quality in your agent fleet. You see here how I have one that is like basically red teaming my agent and looking for prompt injection attacks and

[22:28] any sort of uh attack that will allow someone to come in and circumvent the guardrails that we have put in place to then provide information that they shouldn’t get. The other one I have here is like very specifically for a use case that I want to know which uh which cases have been disputed and where the dis the that dispute has not been solved. So the point here is that I can come and and curate a specific data sets that are very specific to not only the use case

[22:59] but also the technical requirements that I have for that agent. This is where I would say that not unfortunately because I think I still think humans we are very important. So this is where you still need your domain experts in the loop working with the development teams defining what are these. There are two main ways that you can basically create your golden data sets. You either have a team and I’ve seen variations of both. You either have a team that already has a spreadsheet somewhere. these are all the things that we want to test on my

[23:30] agent and just upload it and that’s pretty easy. You can come here and say okay perfect I want to create a test data set and then I want to upload a CSV and you can upload the CSV and it will exactly bring up everything that you just had before. The other thing I like to mention here everything that I’m showing you can do it as well identically through our CLI or NCP in our APIs. It’s just that I think it’s very it’s better for me to show it in a UI rather than telling claude to do it end to end. Make no mistakes. Okay. Um

[24:00] so that is that on that but then I could also come here and say that I want to add um you know items into my data set for instance that are already as part of my production traces. So let’s say that you saw how I was already collecting a lot of activity from my application. I can come here and say I want to add all of these into my data set and then select the data set that I want to select. So

[24:30] this way you can kind of dog food in a way the data set that you’re going to use by looking at the production traces that your agent is producing as long as you have determined that yes these are good examples of what I want future outputs or traces to look like. Now an important thing here to do is a process that I always like to call out which is error analysis. Right? So error analysis is basically this idea that I want to

[25:02] look at my traces and I think Annabelle kind of talked about this uh very eloquently as well when she was on the other side as a user of of Langfuse that she had to like and we were talking earlier today. She spent like days like literally looking at traces like that was her job like looking at the trace the structure what was what were the outputs and all of that. And that is still a very important process because when you look at the trace you you first start understanding how the agent is behaving if it’s taking all the steps

[25:34] that you needed to take if it’s calling all the tools that it needs to call and if it’s giving you the output that you want. That’s you know very very important. But then how do you simplify that process? because obviously it is not feasible for me as a human to go out and look at thousands of traces once the system is in production. So what we typically do is we want to curate a sample that is representative of our production system on of traces for a human expert to come look and give me

[26:05] feedback. Right? It’s the same as like hey I have all this activity. I’m just going to take 10% or 20% and I can say I just want to focus on the ones that the customer is talking about, you know, disputes or credit card information, whatever filter that you want, you can do that. And then you can build for them what we call an annotation queue, right? In this annotation queue, effectively what you’re doing, you’re telling a domain expert, in this case, let’s say me, that, hey, you are the risk expert.

[26:36] I need you to take a look at this output that the agent is giving us or is giving our clients and give me your input. And the thing is here you want to make it very very simple for the domain expert because obviously they have their day job. They cannot spend just hours looking at this. So the the typical things that I recommend is you can give them like a couple scores that they can give you, you know, yes, no, true, false, a scale 1 to 10, whatever that

[27:08] is. And then they can also come here and give you a comment. So let’s say here failure mode, let’s just say for for for the sake of argument that in this case is missing a citation. And then I’m going to I’m going to put a comment. Citation is not there. Needs to be included in all these cases, right? You’re going to go through this process and and look how you know it was simple for me. It took me what 10 seconds maybe. So let’s

[27:40] say I have I don’t know a hundred of these and it takes me 30 seconds each. That is what 50 minutes. No, no, not even. Right. I’m I’m I’m bad at math today. But anyways, you get the idea, right? So you you you can tell your domain expert, hey, give me an hour of your time. I’m going to curate a bunch of activity for you. Just give me your feedback. Just give me a few comments. And now with whisper flow or something, they can just dictate it. They don’t even need to type it. Right? So make it very simple. The second thing that you’re going to do with this, I’m going

[28:10] to mark this as completed. Now this human annotation lives with the trace as evidence. But then the second step that I want to do is take all this information, all this annotation that they gave us and then actually use an LLM to find all the failure modes or categories that are patterns across all of their comments. Right? So it there might be you’re not asking the the the theme to invent categories. You’re just telling them, give me your unfiltered

[28:42] raw commentary on these traces and then you’re going to use an LLM to then figure out the categories because that’s what they are great at. They are great at pattern matching. They are great at extracting information from text. So that way you keep it simple for the domain expert and use LLM for what they are great at. Now once you have all those categories that is where we can then get into our failure modes and those failure modes if I come here and look at my experiments that is what

[29:13] you’re going to see whenever I run an evaluation you see all of these things that I’m measuring against. Maybe let me brought it up here. So now after I have my domain expert give me the the the inputs I extracted what are the most common categories that appear in my corpus of data based on my domain expert. I can then define what are my vectors or dimensions of you know quality. Let’s just call it we just call it scores right but I like to come up

[29:44] with fancy words to to say things. But you see here how one of them was sites experts expected source correctness for formal register meaning that you know in some languages you want to address your customers with a more formal tone uh if the language matches what the customer came in with u must include non solicited and so forth. So now that I have that foundation of the categories that I’m going to measure on the quality of my outputs, then I can decide okay

[30:16] cool. So now how am I going to grade that right? What type of score is that? What type of evaluator is that? And for that I can either do come here and build my kind of library of evaluators, right? So that those as as you know traces coming in they’re automatically calculating those scores for me but at the same time I can have the scores being calculated directly from the client application whenever something

[30:46] happens online in real time so that then I can surface it back to the system. But basically, I want to have a a way of me measuring the outputs of the agent across both LLM as a judge scores or evaluators, but also deterministic evaluators. Another lesson that we’ve that we’ve seen working with these clients is that the more that you can have a mix um a balance mix that is depending on the type of categories that

[31:16] you identify between LLM as a judge evaluators and deterministic evaluators the better because what that’s going to do is if you rely 100% just on LLM as a judge there’s a nonzero chance that some of the outputs are going are not going to be accurate because that’s just the nature of the LLMs. But if you factor in some deterministic checks that are always going to be exactly the same for the same inputs irrespective of what

[31:47] happens, then you can have a blended score or a blended assessment on the quality of your agent. So that’s what we typically would like to see. And you see here when I’m def trying to define a new evaluator I can come and say I want it to be a new LLM as a judge evaluator or I want it to be a code evaluator and I can define all the details on as to how I’m going to evaluate that particular agent activity. So that’s that. And then

[32:18] if I want to have a code evaluator, you see this is just code. It’s a function. It’s code. This is very simple. It’s just a reax. This is doing an exact match. But this is going to give me the same output 100% of the time. This is not going to be well 95% or 80%. It’s always going to be 100% the same output for the same input. So again, the lesson here, you want to have a mix of both. So that’s on the evaluation side. So now we’ve talked about like Annabelle said

[32:48] and maybe let me go back here to the AI engineering loop. So we’ve talked about here building the data sets. We’ve we touched on how we can then operationalize the measurement of the quality of those agents running experiments. And then maybe let me go back here. So basically an experiment is anchored on a data set. That’s my test cases. Those are my tasks that I’m going to run against my agent. And now I’m going to say, you know what, this agent

[33:19] is running today with this system prompt, this model, these tools. What happens if I change the model? What happens if I make a change on the system prompt? What happens if I now all of a sudden I give it access to new tools to access new data? So you want to be able to kind of prototype that before, you know, promoting into production and just running on Vibes, which is pretty much what all we’ve all been doing, right? It’s like, ah, yeah, it looks kind of good. Let me just push it into prod. But this is a a systematic way of you doing

[33:51] that. And in a few minutes, I’ll show you how you can incorporate this as part of your CI/CD pipeline, so you don’t have to be in the loop. So that anytime a change hits on your agent, then a CI job is going to kick off to run the experiment against the data set. It’s going to evaluate your agent with a new configuration and it’s going to give you a pass fail gate effectively across all of the scores and evaluators that I mentioned before. So you have a consistent way on how you evaluate and measure the outputs of these agents.

[34:23] Make sense? Okay, perfect. So that’s experiments. That’s great. So we touched on experiments. We touched on data sets and human annotation to bring those humans and their expertise into the loop. So now how do I bring it all together? Right? If I come here and I have my prompt this my system prompts that I’m versioning here in Langfuse. You can do it either here in Langfuse. You know we don’t we don’t have it’s okay. We don’t we don’t even charge for this. So that’s fine. A lot of our

[34:54] customers what they do is they have another version in system. they have a version in GitHub, GitLab, whatever that is. But you should look at this as your trigger for then kicking off the automation to do your eval completely automatically. So the way that this happens is I already have defined an automation here. And if you see the configuration is triggering on any prompt changes that I have here. And then the action is it’s going to launch a CI job in my GitHub, which is this guy

[35:27] right here. Hopefully I don’t I’m not get I’m not getting the unicorn from from GitHub. So it’s this guy right here. So I have already my CI set it up set up waiting for any changes in the config of my agent. Let me bring it closer here. And then I can come and see my prompt. Let’s just see this one. I have five versions of the prompt. You see how the prompt has evolved over time. Version one, it used to have this and then version two,

[35:59] a slight change. Then version three, it was, you know, we tried something different. This is for development. Then version four, we added more details and also passing different parameters into the configuration of the agent. But what I can do now is I can say, you know what, this is the production system prompt that I have right now. I want to test again with version 4 because I saw some regressions. So I can come here and do promote into production. And again, I’m showing you this as a human, you know, like a caveman like clicking

[36:30] through. All of this can be done via the API on the CLI. So you don’t even have to do this by hand. You can just call the API and say promote this prompt version with a production uh tag and it will kick it off for you. I have the production tag. I’m going to save and promote promote to production which is the new configuration. In a few seconds we should have a new CI job that is going is going to launch here that then is going to kick off the experiment to run my evaluation run. Okay, there you

[37:01] go. Thank you GitHub. Thank you so much. So perfect. So now I have this job that is running automatically. So any time that I push any changes in the config of my agent, it’s going to hit the CI. It’s going to run the eval gates to tell me if I’m passing or failing any of the evaluators that we have defined from before. And then with this way, I can have the evidence and also the assurance if I can go into production, you know, safely with this new configuration. if it’s actually the agent is degrading or

[37:33] improving in quality or maybe even violating any sort of guard rails that I have put in place. That’s going to run for a few minutes, but let me show you one that I run earlier. And to show you the result, I can come here and see what the output is. And it’s telling me that this was the prompt that was sent, the version, the labels, and then it’s telling me that they gave passed, right? So, perfect. And these are the evaluators that I measured my agent against. I have here the most include,

[38:04] the source recall, the language match, the correctness and not unsolicited upsell. And I can also define minimums. I can say this is the minimum threshold I have for this specific score. If it doesn’t clear that bar, it’s not going to be considered as a pass uh to go into production. Now, obviously, in this case, I’m not crazy enough to just say, okay, cool. So you pass, go merge it and push into into main. I’m just letting it sit there. But admittedly, you could have a full end to end process that it

[38:36] will just create the PR for you and it will just wait for someone to review the PR or maybe if you are, you know, like like everybody’s doing today, just pushing the PR into main straight up uh if it’s clearing the bar, but at least you have the evidence here, right? So you’re not pushing a PR just running on vibes or just running on what you think that the agent is good at at doing. You’re actually have the the paper trail so to speak and the evidence on why you make that decision for this new

[39:06] configuration of the agent. Perfect. So now I want to show you one couple more things as an actual like use case, right? because we’ve been talking a lot about the technical aspects of of langu and more you know organizations are focused a lot on tokconomics right I think 2025 in beginning 2026 everybody

[39:38] was token maxing now everybody is like token valuing or whatever they’re calling it now so everybody’s like trying to extract as much value as they can of their tokens. So now let me show you a couple of ways that you can then show your bosses or your leaders or whoever or maybe you want to build this for your business stakeholders for them to feel a little bit more reassured that whatever agent solution that you’re building is actually bringing benefits to the business. This is not just like

[40:08] oh the cool thing that we’re building. Now I have here a dashboard that I’m trying to put together a few metrics that I can report on to the business based on the data that I’m being collecting from my agent. Right? The first one is and this is where you might argue with me in the logic behind this but you know every organization is different. But what I’m trying to show here is that I’ve had 1,400 interactions of this agent over the last

[40:39] seven days that didn’t need to go to a human agent, right? So that’s great. So that means that I’m saving, you know, human capital from spending time to talking to customers in in and do the math then. How much has that cost me? It has cost me less than $7, right? Over the last seven days. If you take any contact I used to be a contact center employee back in the day 20 years ago you know what you gonna pay that person $15$20 an hour right so that person is

[41:12] not going to handle 1400 calls in one hour so already you’re showing at least some directional business benefit by having this solution in place right so that’s the first thing the second thing is you could also start pinpointing what are the areas where your agent is tripping Right? If you remember, we define the categories or the failure modes as we call them in the industry where the agent is not giving me the results or the answers that I want. And these are

[41:43] the ones that I’m capturing in order of occurrence over the last seven days. You see here that now out of scope, informal register, and dispute not resolved are are my top three and they’ve been creeping up over time. So now, instead of me having to go through thousands or hundreds of thousands of traces trying to figure out which one is the activity from the agent that is causing the most errors or the most trouble, I can come

[42:14] here and scope it down. And I know already that this failure mode is my top one, the autoscope, the foremost registered and the dispute not resolved. So now I can come here in my tracing and do a very simple filter and say dispute not resolved. I can save it as a view. So I don’t even need to every time filter it. You see how it’s filtering up top for me. And even on the side I can come here and say dispute not resolved equals zero. So that shows all the

[42:45] instances where the customer had a dispute or was asking for a dispute of a product and it hasn’t been resolved by the agent. So it either had to go to a human agent or it just lingered and the session closed and nothing happened. But now I can then spend my time instead of going through thousands, I can scope it down to maybe dozens or hundreds. And now I can do um an investigation that is more targeted. And now I can also find where are the areas where my agent is actually uh tripping itself up. So

[43:18] that’s that’s one. The second one is that if I want to come here in the dashboards, I want to then be able to say okay what are the number of times where my customers are giving me either thumbs up, thumbs down. I can I can capture that as a score very easily. You see here every time I can come here thumbs up thumbs down and I can just show it here in a dashboard very easy to consume any business person any user any human actually is going to be able to

[43:49] see this and say okay most of them are thumbs up that’s cool but what about the thumbs down let’s focus on that you know 18% of them what’s been happening and then the other one is around the security mix more in here good news most of our interactions from the agent is not catching any sort of risk in the interaction that is having with the customers. But we see here that in 89 cases over the last seven days, it actually the customer was asking for

[44:21] investment advice and the agent might have given or might have tried to give investment advice. So we can then go out and focus on those. And again, same thing. I can come here and say, let me go back to my default view. And now I can say instead of the numeric score, I can come and say the categorical scores add a condition. And then say what is the intent or the security risk and then the security risk, let’s say investment advice. And now I can see what are the

[44:54] specific examples where investment advice was identified as a reason for being flagged and that the that the agent shouldn’t engage on that with the customer. And you see here even from the previous example um that I was showing you. So that’s kind of what I wanted to show in terms of first the the nature of going end to end on a solution that you’re putting customerf facing first. Obviously, which has a lot of critical implications in terms of liability, you

[45:26] know, financial implications for and reputational as well because you don’t want to be putting out information that is not accurate or is hallucinated in front of your customers and how you can follow a systematic process so that then you can show evidence and validate that the outputs of these agents is actually following the guardrails and the controls that you have put in place. And with that I would like to leave you with Annabelle again so we can close and then maybe we can take a couple of questions

[45:57] at the end. Thank you. >> So what we see some companies trying to do or some teams trying to do is this. Please fix my agent. Make no mistakes. And there’s probably a few things that we can recommend less than this. Even though your agent might be hooked up via MCP or CLI with your data in Lenfuse or in whichever tool you might be using. Um this is something that we just see producing rather slop than anything um that is actually helping you. But of course we’re also very much in favor of

[46:28] working with your coding agents to continuously improve your applications. Um so we wanted to share this just as a picture how you can maybe memorize it. So we have two of those a here. We have one uh being the time invest. So, a lot of time spent or very little time spent and then also a low quality system or a high quality system and you don’t want to be down there. If you fully automate it and just let your agent go for it and just be like fix everything, do it for me. Um, this is

[47:00] not going to turn out well. You will end up with low quality and yes, you don’t have to do anything, but also your customers will not be super satisfied. At the same time, you also don’t want to go go the full manual way anymore. You don’t want to instrument your app yourself anymore. This is something that can be automated. You don’t want to catch all the failure modes yourself and re review all the data yourself. This can be automated. Um but at the same time, for some things, you should get your taste in. You should get your domain experts in the room to build out the data sets to curate what is actually um what actually is the problem that

[47:31] your application should be solving and in which direction you want it to go. And for this um you want to land somewhere here. So where the ideal balance is between like um you reviewing data, bringing in your taste, bringing in your domain expertise, but also working with your coding agent for all the things that you can automate like instrumenting it, finding failure modes, running the evals, maybe making also 20 experiments instead of only one um that you would come up with and yeah, just like avoid getting down there in the left uh down corner, but try to be the

[48:02] the tasteful AI engineer that is bringing in the taste, making sure the the emails are great and then you can also more and more automate this loop over time. If we were you and we would have to get started tomorrow, h this is what we would be doing. We would install the lenuse skill which is a yeah it’s an agent skill. So it’s a set of markdown files that is helping your coding agent to wrap its head around how to work with lenfuse and how to implement those best practices. It is hooked up with our documentation with all our integration pages. um it is hooked up with our

[48:33] academy where we ingrain the best practices around data sets and how to instrument and how to write evaluators and all of this. So it’s a a great starting point um to do the things uh automatically um that you should be doing automatically but also to maybe curate a set um of data that you should look manually at. uh you should then start to collect um also ground truth that you can evaluate your agent against maybe from historical data also from uh production or from some samples that you’re running with your domain experts and if you’re in a regulated space uh

[49:04] define your hard limits in a way to make sure these are the things that definitely shouldn’t happen for financial services for example it should never give investment advice so make sure that you’re ingraining this also in your evaluation set um that ideally never happening but at least you will know about it um when it’s going to happen and we have a few resources for you. So the repository Donelli showed you and used um is also available online. Uh you can check it out yourself. You can take everything that you want from it and also use it for your own use cases. It’s

[49:35] of course fictional data and not um not something that actually um was taken from our customers and I think also this session will be recorded so you can take a look again. uh we then also recommend the langu academy which is like a larger writeup of uh how to go about AI engineering um the whole steps um described again and we also have a self-s serve workshop that is basically guiding you through all the steps so you understood it once and then um yeah can go ahead with your own application there’s some opportunities to bump into

[50:06] us over the next days uh one is um Donelli is giving a talk also on building deployment gates for AI agents on Wednesday so Check it out if you want to understand how you can make sure uh that AI models that go to production are actually um clearing quality gates. Uh we’re also having a booth, a booth 9. Um I haven’t checked out where it is, but I’m sure you will find it. Um you can meet the team there, but also you can get custom stickers. So you take a picture of your face and then it AI generates stickers of your face and length use with a maybe some jokes also

[50:36] included. Um and you can take them home and sticker it on everything you have. And then finally, we also have a community run. So if you want to step out the conference center and meet the team, we also have two of our founders here um and a few more team members and we’re all big runners. So we thought we just might invite everyone else as well to join us um for this. So yeah, please come for this one as well. And we’re super happy to use the remaining minutes for any kind of questions. They also have some non-custom stickers here. It’s just a lengthy sticker, but I think it’s still pretty cool. So if you want some,

[51:06] you can come up uh and get them. We’re happy to take any questions. and ple please meet us and don’t be a stranger. I’m handing this to Delli. >> Yeah. Well, the Langfuse per se has a hard dependency for their stores with click house. Um that is just because you know in the evolution of the product it started with Postgress. Uh but then Postgress couldn’t handle the scale that we achieved and like billions of billions of events per day. That’s when we moved over to Clickhouse. So in terms of that data plane yes in clickout so but maybe the followup for you what is

[51:37] the need for you in terms of that data stores because we also offer the ability for you to export the data you can export it to S3 you can use the a yeah you can use the API the CLI or the MCP if you want to consume the data from langfuse so it’s totally up to you yeah >> I want to host it on >> yeah you you can host it 100% on Amazon um it’s you know we have a self-hosted deployment as well um you can either use our cloud offering that is fully SAS turnkey you don’t need to do anything it runs on Amazon but if you want to run

[52:08] the infra yourself because you have I don’t know some you know EC2 instances lying around there you want to use we also have a deployment model for that and it comes prepackaged with all the components >> yeah super important question so the question was about interator reliability um and also probably just consistency of LLM as a judge evaluators to make sure it’s actually catching um what you want it to catch um there’s actually also part of this language skill is handling this as well and helping you to um h there’s a term for it. Um it fell out of my head but it’s in the end about the

[52:39] process of making sure the LLM is judging like a human would judge and uh what you do basically is you judge a sample um ideally a representative sample yourself and then you run your LLM as a judge and you then optimize for the LLM as a judge being coherent with what your human human raiders do and ideally you have like a few human raiders and that’s academic approach to it. So probably the practical approach to it is have one human label some data and then optimize against this ground truth and then ideally you just check it over time to make sure your set stays

[53:09] representative and especially if you are using it for um running on production data it’s in the end ideally you just start with having a a few too many false positives so you catch a little more than necessary but don’t miss anything and then you just tune it down over time.