Building Engine v2: como a LangChain aborda a melhoria de agents

Ver no idioma original →

Autoria: LangChain · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: Building Engine v2: How LangChain approaches agent improvement · Canal: LangChain · 19:50 · Assistir no YouTube

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

Resumo

Ben, gerente de produto da LangChain, apresenta como a equipe usa o Engine para identificar problemas em agents, propor correções e avaliar resultados. Para melhorar o produto, a equipe criou benchmarks específicos para as diferentes tarefas e usa o próprio Engine em seus agents e no Engine, além de testar modelos distintos conforme a tarefa. O Engine V2 amplia a detecção para tendências entre traces e caminhos ineficientes, e introduz correções validadas com testes contra exemplos de produção e conjuntos de dados. A apresentação também aborda o red teaming proativo e os planos para o Engine V3, incluindo maior acesso, evals de referência e recomendações de modelos verificadas.

Pontos-chave

• O Engine automatiza etapas do ciclo de desenvolvimento de agents: identifica problemas em traces, agrupa causas, propõe correções e cria evals para verificar resultados.
• A equipe desenvolve benchmarks separados para avaliar cada tarefa do Engine, como detectar traces problemáticos e agrupá-los por causa raiz.
• A LangChain usa seus próprios agents e o próprio Engine para conferir se os resultados dos benchmarks se refletem em situações reais.
• Modelos menores podem ser mais eficazes e baratos para tarefas específicas; por isso, a equipe testa modelos diferentes para cada tarefa.
• O Engine V2 pode identificar tendências entre traces, como aumentos no número de chamadas de ferramentas, e detectar caminhos ineficientes.
• As correções validadas reproduzem o problema em produção, testam uma correção em uma versão de preview e verificam possíveis regressões com conjuntos de dados.
• O red teaming do Engine gera entradas potencialmente problemáticas para encontrar falhas antes que afetem usuários.
• Os planos para o Engine V3 incluem ampliar a disponibilidade, criar conjuntos de evals de referência e validar recomendações de mudanças de modelo e harness.

Capítulos

Início	Capítulo	Resumo
00:05	O que o Engine faz	Ben apresenta o Engine e descreve como ele automatiza a identificação de problemas, a criação de correções e a detecção de regressões.
02:12	Avaliação e benchmarks	A equipe explica por que avalia separadamente as tarefas do Engine e como cria benchmarks para detectar e agrupar traces problemáticos.
06:31	Melhoria contínua com modelos e dados reais	Ben relata o uso de modelos distintos por tarefa, da plataforma LangSmith e dos próprios agents da LangChain para avaliar o Engine.
09:09	Novos tipos de problemas detectados	A apresentação mostra como o Engine V2 amplia a análise para tendências entre traces e caminhos ineficientes.
12:55	Correções validadas	O Engine reproduz problemas em produção, testa correções em uma versão de preview e verifica regressões em conjuntos de dados.
16:04	Red teaming proativo	O recurso de red teaming testa entradas hipotéticas contra o agent para identificar falhas antes que atinjam usuários.
17:37	Planos para o Engine V3	Ben descreve planos para ampliar o acesso, criar evals de referência e validar recomendações de mudanças no harness e nos modelos.

Citações

Precisamos avaliar essas tarefas separadamente. — 03:18

Para tarefas específicas, modelos que não são de ponta podem ser mais eficazes. — 07:02

A visão que temos para o Engine é encontrar os problemas, corrigi-los e testar a correção de forma autônoma. — 13:28

São nossos primeiros passos rumo ao aprendizado contínuo. — 15:34

Conceitos e entidades

• Engine (ferramenta): Produto da LangChain que identifica problemas em agents e ajuda a propor e testar melhorias.
• Engine V2 (ferramenta): Versão do Engine apresentada, com detecção ampliada, correções validadas e recursos de red teaming.
• LangChain (empresa): Empresa cuja equipe desenvolve o Engine e usa a ferramenta para melhorar seus próprios agents.
• LangSmith (ferramenta): Plataforma usada pela equipe para inspecionar traces, acompanhar issues e gerenciar experimentos e conjuntos de dados.
• IssueBench (benchmark): Benchmark principal mencionado para medir a identificação de problemas pelo Engine.
• validated fixes (conceito): Recurso que verifica se um problema ocorre em produção e testa uma correção e possíveis regressões.
• red teaming (conceito): Processo proativo de criar entradas para tentar encontrar falhas em um agent antes que afetem usuários.
• Engine V3 (ferramenta): Próxima versão planejada, com metas como ampliar o acesso, criar evals de referência e validar mudanças de modelo.

Tradução completa (pt-BR)

00:05 Olá, pessoal, estou muito animado para conversar com vocês hoje. Como o Harrison disse, sou Ben. Sou gerente de produto. Trabalho no nosso produto Engine, que é nosso agent para engenharia de agents. O que quero fazer hoje é apresentar o processo que seguimos na LangChain para desenvolver e melhorar nossos agents por meio do Engine, certo? Esse agent para engenharia — engenharia de agents, quero dizer. Já conhecemos muito bem o processo de criação de agents. É muito desafiador. Tudo, desde identificar erros enquanto analisamos traces manualmente, até tentar agrupá-los com base nos diferentes problemas identificados, fazer esse tipo de análise de causa raiz desses problemas, desenvolver correções e escrever evals. Todo esse processo, do início ao fim, pode ser muito desafiador. E então, o que criamos no Engine é um produto e uma ferramenta que cuida de cada etapa desse processo, que identifica os diferentes problemas que você pode encontrar nos seus traces, que cria correções prontas para deploy para cada um dos problemas identificados,

00:39 que cria evals prontos para uso para você executar offline e garantir que essas correções funcionem adequadamente sem causar regressões, além de detectar regressões em qualquer problema que possa voltar a aparecer depois que você já tentou corrigi-lo. Estamos muito animados com o Engine. Nós o lançamos em maio, no nosso Interop em San Francisco. Desde então, o Engine analisou mais de 70 milhões de traces e criou mais de 21.000 issues para os muitos clientes que o estão usando hoje. Estamos muito

01:10 animados com esse progresso, mas dedicamos muito tempo e esforço para tornar o Engine muito melhor do que a versão que lançamos em maio como beta público. Então, como eu disse, a ideia desta breve palestra e sessão de hoje é apresentar o processo que nossa equipe seguiu para melhorar o Engine e torná-lo um produto mais rápido, mais robusto, mais barato e que vá além do que temos hoje neste ciclo de vida de desenvolvimento de agents e do que está automatizado atualmente. A primeira coisa sobre a qual quero falar

01:41 é, na verdade, o processo de avaliação do Engine. Enquanto desenvolvemos esse agent muito complexo, também tem sido muito difícil criar evals para o Engine. E o motivo de isso ser tão difícil para o Engine são as muitas tarefas complexas que esse agent executa. Para dar alguns exemplos das tarefas que ele executa: o Engine identifica esses traces problemáticos ou que contêm falhas e os agrupa depois de identificar uma causa raiz. Ele escreve uma descrição legível da issue para uma

02:12 pessoa ler e entender. Ele investiga essa issue e compara os traces com o código-fonte real do seu agent para criar uma correção. Ele cria exemplos de conjuntos de dados usando as entradas problemáticas que encontrou em produção e criando essas saídas de referência de ground truth. Ele monitora regressões para garantir que esse problema não volte a acontecer. Estou passando por todas essas etapas diferentes desse agent e pelo trabalho que ele faz. Cada uma dessas tarefas é muito diferente da anterior. Portanto, para garantir que o Engine tenha um bom desempenho e para podermos torná-lo

02:44 melhor e mais barato, precisamos avaliar cada tarefa separadamente. Por isso, criamos benchmarks exclusivos para cada uma delas. Por exemplo, criamos um benchmark exclusivo para identificar esses traces problemáticos, que nos permite testar o Engine e entender o quanto ele consegue identificar traces problemáticos. Para avaliarmos isso adequadamente, o benchmark que criamos é um conjunto de

03:18 traces com problemas inseridos neles. É como encontrar uma agulha num palheiro de traces, e simplesmente testamos a capacidade do Engine de encontrar esses traces problemáticos. Esse benchmark é separado de outro muito parecido: a capacidade do Engine de agrupar esses traces por causa raiz. Nesse benchmark, fornecemos ao Engine, o agent, um conjunto de traces com erros conhecidos, além de uma série de issues existentes. E avaliamos a capacidade do Engine de associar esses traces com erros conhecidos ao

03:48 conjunto de issues ou de criar novas issues. Esses são apenas alguns dos benchmarks que criamos. Mas, como eu disse, para cada uma dessas tarefas, precisamos criar novos benchmarks e garantir que o Engine tenha um bom desempenho e funcione a todo vapor em cada uma das diferentes tarefas que executa. Uma coisa interessante que quero destacar ao falarmos desses benchmarks é que há, de fato, dois lados nessa questão. Temos evals que precisamos garantir que sejam benchmarks capazes de nos ajudar a testar componentes muito

04:21 específicos da execução do agent. Mas também queremos garantir que esses benchmarks sejam fiéis ao que veríamos em um ambiente de produção, que é o outro lado da questão. Portanto, para garantir que quaisquer mudanças que consideremos muito eficazes nos nossos benchmarks também sejam realmente eficazes em um ambiente de produção, usamos o Engine nós mesmos. Testamos muito nossos próprios produtos. E criamos muitos agents diferentes na LangChain, incluindo agents de go-to-market que cuidam de várias atividades relacionadas a go-to-market, como enviar mensagens outbound e fazer pesquisa de prospects.

04:53 Também temos agents de programação que são acionados pelo Slack ou pelo GitHub. Executamos o Engine sobre cada um desses agents que criamos. O Engine encontra erros e envia essas issues para o nosso Slack. Podemos investigá-las. As equipes que trabalham nesses agents de go-to-market ou nos agents de programação podem nos dizer que o Engine encontrou issues realmente valiosas ou que há algo errado com essa descrição. Isso realmente nos ajuda a equilibrar o processo que seguimos para criar benchmarks e avaliar o Engine nessas tarefas específicas.

05:25 Mas talvez a parte mais interessante desse uso interno seja que, na verdade, executamos o Engine sobre o próprio Engine. Enquanto o Engine investiga traces dos nossos agents de go-to-market e dos nossos agents de programação, ele produz traces. E esses traces são analisados por outra instância do Engine. Nós a chamamos de meta Engine. Também conectamos esse meta Engine para nos enviar notificações pelo Slack, da mesma forma. Assim, nossa equipe recebe uma notificação quando nosso próprio produto apresenta algum problema, quando algo pode ter falhado ou quando há uma resposta abaixo do ideal em uma das

05:57 saídas do Engine. Isso está se tornando uma das principais maneiras de identificarmos oportunidades de melhoria no Engine, e nossa equipe monitora constantemente esse feed de notificações no Slack com essas issues. Quero destacar algumas observações e ideias interessantes que tivemos enquanto trabalhávamos para melhorar o Engine, especialmente em relação ao uso de diferentes modelos. Uma coisa interessante é que, obviamente, tarefas diferentes exigem níveis diferentes de inteligência. Uma coisa que me

06:31 surpreendeu é que pode parecer óbvio que usar um modelo que não seja de inteligência de ponta vai sair mais barato. Mas também descobri que, para tarefas específicas que executamos no Engine, usar esses modelos que não são de ponta pode, na verdade, ser mais eficaz. Se a tarefa é, por assim dizer, uma tarefa boba, às vezes é melhor usar um modelo mais simples ou menor em vez desses modelos de última geração, que são muito caros e também muito grandes. Estamos sempre experimentando trocar os modelos usados nas diferentes tarefas executadas

07:02 pelo Engine. Outro ponto rápido que quero mencionar é que nossa equipe depende totalmente da plataforma LangSmith. Passamos muito tempo analisando traces manualmente sempre que temos um problema muito específico. Também dependemos, como mencionei, desse feed de issues geradas pelo Engine. Mas também usamos o Engine na nossa plataforma de experimentos. Assim, podemos manter esse registro dos diferentes experimentos que executamos e ver como o custo e o desempenho nos nossos diferentes benchmarks mudam ao longo do tempo. E, enquanto trabalhávamos

07:33 pelo Engine. Outro ponto rápido que quero destacar é que nossa equipe depende totalmente da plataforma LangSmith. Passamos muito tempo analisando traces manualmente sempre que temos um problema muito específico. Também, como mencionei, dependemos desse feed de issues do Engine que são geradas. Mas também usamos o Engine como nossa plataforma de experimentos. Assim, podemos manter um registro dos diferentes experimentos que executamos e ver como o custo e o desempenho nos diferentes benchmarks estão mudando ao longo do tempo. E, enquanto trabalhamos em

08:07 Ao aprimorarmos esse processo e melhorarmos o Engine, à medida que criamos esses benchmarks e depois buscamos resultados cada vez melhores com base neles, conseguimos alcançar pontuações muito melhores nos diferentes benchmarks. Harris mencionou na palestra de abertura que tivemos uma identificação de erros duas vezes melhor no IssueBench, que é nosso principal benchmark para identificação de problemas. Também testamos as correções propostas pelo Engine em uma série de benchmarks de programação padrão do setor. Além disso, combinamos isso com

08:39 benchmarks que criamos especificamente para esses problemas relacionados a agents, nos quais também vimos o Engine melhorar bastante. Esses números são interessantes, mas o que eles significam na prática? No fim das contas, significam que identificamos mais problemas para os clientes que usam o Engine. Significam maior precisão nas descrições e nas análises de causa raiz dos problemas que identificamos. E significam tempos de resolução muito mais rápidos para as equipes que estão criando agents com base no LangSmith.

09:09 Até agora, falei sobre o processo de criação de evals e alguns dos resultados gerais que observamos. Mas quero falar de uma maneira específica como modificamos nosso harness e o Engine para encontrar esses problemas com mais eficácia. Vou fazer isso usando este pequeno recurso visual. Temos este círculo na tela. Imaginem que, dentro dele, está o conjunto completo de problemas que podem surgir durante a criação de agents. Portanto, cada pequeno ponto dentro desse círculo representa um tipo de problema

09:40 que vocês podem imaginar no espaço de problemas da criação de agents. Quando lançamos o Engine pela primeira vez, nossa versão 1, lançada em maio, vocês podem imaginar que o Engine abrangia uma parte desses problemas. Gostaria de imaginar que o círculo fosse maior do que o que temos neste recurso visual, mas ele abrangia uma parte dos problemas que existem para engenheiros que criam agents, mas não todos. E, à medida que avaliamos e iteramos com base nos nossos benchmarks, ampliamos o que o Engine, em seu estado anterior, é capaz de fazer.

10:13 Mas ainda há uma parte desse espaço de problemas de agents que o Engine, com a arquitetura da nossa versão 1, nunca conseguiria identificar de fato. Esta é a representação dessas oportunidades mais amplas de melhoria. Isso porque, na nossa primeira versão do Engine, garantimos que ele fosse realmente excelente em encontrar erros em um trace específico. Seja uma alucinação, uma chamada de ferramenta com falha ou

10:45 chamadas de ferramenta em loop, explosão de contexto, certo? Todos esses problemas ficam muito visíveis em um único trace. Ao analisar traces, o Engine investiga, encontra vários traces com aquele problema e os agrupa com base na causa raiz. Mas muitas vezes é difícil encontrar erros usando apenas um trace. E há erros que podem parecer iguais à primeira vista. Por exemplo, digamos que, entre 1º e 14 de setembro, nossa equipe trocou o modelo do agent por um novo, e vemos que o custo e a latência estão praticamente iguais, embora esperássemos uma grande redução no custo ou na latência.

11:17 Se eu olhar os traces, se comparar o trace A com o trace B, eles podem parecer exatamente iguais, sem nenhuma mudança perceptível. Mesmo que eu veja que, no trace A, tivemos apenas seis chamadas de ferramenta, ou que, no trace B, tivemos apenas 19 chamadas de ferramenta, eles parecem praticamente iguais. Eu diria que não parecem problemáticos. Mas o fato de o Engine ou um engenheiro de agents conseguir determinar que o número de chamadas de ferramenta aumentou muito de uma etapa para a seguinte é um forte indício

11:50 de que algo pode estar errado. Talvez esse novo modelo tenha simplesmente enlouquecido e esteja decidindo chamar ferramentas muito mais vezes do que deveria. Esse tipo de contexto entre traces — entender o histórico do agent e os traces que ele produz — é um dos tipos de problema que o Engine ficou muito melhor em identificar. São tendências relacionadas a métricas que queremos acompanhar e garantir que o Engine consiga detectar. O outro tipo de problema que passamos a conseguir identificar muito melhor é…

12:22 São dois entre vários aspectos nos quais trabalhamos: a capacidade de o Engine detectar caminhos ineficientes ao tentar identificar um problema ou atender às exigências de uma solicitação do cliente. Digamos que, em 5% das vezes em que seu agent atende a uma solicitação muito comum, ele embarque em uma missão paralela e comece a fazer todo tipo de chamada de ferramenta ou a consultar todo tipo de fonte de dados que não deveria. É importante que sua equipe saiba que, em parte dos casos, ele está seguindo um caminho ineficiente, para que vocês possam estar cientes disso e trabalhar para limitar esse comportamento. Problemas assim são

12:55 exemplos dos tipos de problema que o Engine V2 ficou muito melhor em encontrar. Até agora, falei sobre as melhorias no Engine: melhorias na funcionalidade existente, que encontra problemas, propõe correções e propõe evals. Queremos que o Engine cubra todo o ciclo de desenvolvimento de agents: desde encontrar problemas e criar correções até testar essas correções e

13:28 fazer o deploy dessas correções. Desde nosso primeiro lançamento, temos nos perguntado como podemos testar de fato para nossos usuários. No momento, criamos uma correção proposta, entregamos os evals e deixamos que vocês experimentem. Mas a visão que temos para o Engine é que ele encontre os problemas, corrija-os e teste as correções, tudo de forma autônoma. É isso que estamos lançando com as correções validadas como parte do Engine. Quero mostrar a vocês como isso funciona na prática. Harrison falou um pouco sobre isso na palestra de abertura, e quero entrar em alguns detalhes aqui.

13:58 O Engine continua encontrando problemas como faz hoje. Ele identifica um problema de chamadas de ferramenta em loop e, em seguida, identifica entradas específicas que encontrou em produção e que fizeram seu agent falhar de alguma forma. Para verificar se esse problema é real, enviamos essas mesmas entradas para a versão de produção do seu agent e confirmamos que o problema ainda ocorre nela. Queremos confirmar que esse é um problema contínuo e reproduzir o bug, como se faz no desenvolvimento de software. Depois de identificar e confirmar que se trata de um problema real,

14:31 propomos uma correção e a iniciamos em uma branch de pré-visualização e em um deploy de pré-visualização disponíveis na nossa plataforma de deploys do LangSmith. Em seguida, executamos essas mesmas entradas que causam falhas na versão com a correção em pré-visualização do seu agent, para confirmar que a correção criada pelo Engine realmente resolve o problema identificado e que essas entradas já não causam falhas na versão proposta do seu agent. Depois de verificar que essa correção funciona para essas entradas, queremos analisar um conjunto mais amplo de entradas, como as

15:02 que vocês têm em um conjunto de dados do LangSmith. Vocês podem configurar os diferentes conjuntos de dados que têm no LangSmith, e o Engine executará evals com as entradas existentes que estavam causando falhas no seu agent, bem como com a gama mais ampla de entradas que vocês querem garantir que não sofram regressões. Assim, vocês recebem muito mais do que um problema proposto, uma indicação do que talvez seja necessário resolver e outra de como resolvê-lo. Em vez disso, recebem um problema verificado, que sabemos que ainda está causando falhas no seu agent, e uma correção verificada, que sabemos que resolve o problema e não…

15:34 faça regressão em relação a outros exemplos. Estou muito animado com isso. Acho que esses são, de certa forma, nossos primeiros passos rumo ao aprendizado contínuo e a esse processo de melhorar continuamente seu agent e torná-lo mais capaz, ainda permitindo que uma pessoa participe do processo e monitore as diferentes mudanças propostas. Como foi mencionado anteriormente, isso está disponível em beta privado no momento. Está disponível para nossos clientes que usam o LangSmith em seus próprios ambientes. Queremos ampliar o acesso, mas adoraríamos que você entrasse na nossa lista de espera e experimentasse essa nova

16:04 capacidade de validar essas correções pelo Engine. Outra coisa que Harrison mencionou é a capacidade de fazer testes de equipe vermelha no seu agent. Penso nisso como uma forma de identificar problemas preventivamente. Hoje, os problemas que o Engine detecta são aqueles que já chegaram à produção e para os quais já existe um trace que você pode analisar, o que significa que provavelmente afetaram algum usuário. Também há maneiras de tentarmos quebrar seu agent antes que ele chegue a um usuário. E, assim, essa equipe vermelha

16:34 funcionalidade do Engine cria proativamente hipóteses sobre possíveis entradas que poderiam quebrar seu agent, com base no system prompt do agent ou em outros detalhes do harness ou do contexto disponíveis. Ela tenta descobrir o que poderia causar uma resposta insatisfatória do agent e, usando sua implantação de produção do agent, envia diferentes entradas para essa implantação e monitora as diferentes respostas. Assim, se houver respostas insatisfatórias

17:04 geradas, o Engine agrupará essas respostas em um problema semelhante, junto com uma correção proposta e, se você também estiver usando nossa funcionalidade de correções validadas, incluirá uma correção validada para resolver o problema antes que ele chegue a um cliente. Mais uma vez, estou muito animado com isso. Isso está disponível em beta privado para nossos clientes que usam o LangSmith em seus próprios ambientes, e adoraríamos que você experimentasse e nos desse seu feedback. Tudo isso de que acabei de falar faz parte do Engine V2. E, enquanto o lançamos e o anunciamos hoje, já estamos pensando em

17:37 e trabalhando no Engine V3. Quero dar uma ideia do que estamos considerando. Primeiro, queremos ampliar o acesso a essas correções validadas que estamos executando, bem como à capacidade de fazer testes de equipe vermelha no seu agent em diferentes stacks de implantação. Queremos disponibilizar isso de forma mais ampla e já estamos pensando em como podemos acessar os diferentes endpoints e as diferentes implantações dos seus agents para oferecer esses recursos. Ao mesmo tempo, hoje o Engine é muito bom em identificar exemplos de eval a serem adicionados aos seus conjuntos de dados com base nos problemas

18:11 que identificou, sejam problemas encontrados proativamente por meio de testes de equipe vermelha, sejam problemas identificados em produção. Encontramos essas ótimas entradas, que são adicionadas aos seus casos de teste de regressão. Mas queremos que o Engine fique melhor em criar um conjunto inicial de evals para você executar, garantindo que nenhum dos diferentes comportamentos esperados do seu agent regrida quando você fizer mudanças no modelo ou no harness. E, por último, o assunto de que vou falar

18:42 aqui é uma espécie de objetivo norteador para nós enquanto desenvolvemos o Engine: queremos propor mudanças mais amplas, eu deveria dizer, no harness do seu agent e nos modelos usados para diferentes tarefas. Isso significaria que o Engine não ficaria mais encontrando correções, ajustes ou otimizações específicas para o seu harness; em vez disso, diria que esse modelo é grande demais e caro demais para o seu agent, e que você deveria experimentar este outro. E nós já validamos esse modelo com seus evals e podemos confirmar que ele é mais rápido e mais barato. E o motivo para isso estar vindo

19:17 depois é que queremos que todo esse fluxo consiga identificar lacunas nos traces do seu agent, além de permitir a experimentação. Assim, em vez de uma recomendação pouco precisa para usar agora o modelo A em vez do modelo B, você terá uma afirmação verificada de que o modelo A terá um desempenho muito melhor nos seus evals. Agora, só mais uma coisa rápida que vou acrescentar aqui: Harrison mencionou que temos o Engine disponível nas nossas implantações autogerenciadas, com a opção de usar sua própria chave. Isso estará disponível na próxima versão da nossa

19:50 implantação autogerenciada, o que nos deixa muito animados. Foi muito divertido conversar com todos vocês sobre o Engine V2 e o progresso que fizemos, além de falar um pouco sobre o que estamos pensando para o Engine V3. Temos vários clientes incríveis que estão experimentando o Engine, nos dando ótimos feedbacks e acelerando seu processo de desenvolvimento de agents, e adoraríamos que você se juntasse a eles. Obrigado.

Transcrição original

[00:05] Hey everybody, very excited to be chatting with you today. Uh like Harrison said, I’m Ben. I’m the product manager. I work on our product engine, which is our agent for agent engineering. Um what I want to do today is is walk you through the process that we have at LangChain of developing and improving our agents through engine, right? This this agent for engineering, agent engineering I should say. Now, the process of building agents we’re very familiar with. It’s very challenging. Everything from the identification of errors as you manually look through traces, as you try to

[00:39] cluster them together based on the different problems that you identify, this kind of root cause analysis for those problems, the spinning up of fixes, the writing of evals. This entire process from start to finish can be very challenging. And so, what we’ve built in engine is a product and a tool that handles each step of this process, that works to identify the different issues that you might find within your traces, that creates deployable fixes for each one of those identified issues,

[01:10] creates ready-to-use evals for you to run offline and ensure that these fixes work appropriately without regressing, and additional regression detection for any of the issues that might crop back up again after you’ve attempted to fix them previously. So, we’re really excited about engine. We launched it in and in May at our Interop in San Francisco. And since then, engine has scanned over 70 million traces and has created over 21,000 issues for the many customers that are that are using it today. We’re really

[01:41] excited about this progress, but we’ve had a lot of time and a lot of effort spent on making engine much better than the version that we released in May as our public beta. And so, like I said, the the hope of today’s little talk and session that I have is I want to walk you through this process that our team has followed for making Engine better and for making this a product that is faster, stronger, cheaper, um and and go beyond what we have today within this existing agent development life cycle and what’s automated today. The number one thing that I want to talk

[02:12] about actually is the process for for evaluating Engine. As we have been building this very complex agent, it’s been very hard to create these these evals for Engine as well. And the reason that it’s so hard for Engine is because of the many complex tasks that are handled by this agent. And so to run you through, you know, some of the tasks that are handled, Engine will identify these offending or problematic traces and cluster them together after identifying a root cause. It will write a readable issue description for a

[02:44] human to read through and and parse. It will investigate that issue and and compare the traces to the actual source code of your agent to create a fix. It will create data set examples using the offending inputs that it found in production and by creating these ground truth reference outputs. It will monitor for regressions to ensure that this problem doesn’t happen again. And so I’m running through all these different stages of this agent and the work that it does. And each one of these tasks is very different from the last. And so in order for us to ensure that Engine performs well and that we can make it

[03:18] better and cheaper, we need to be evaluating these separately. And so we have created unique benchmarks for each one of these tasks. And so for example, we have created a unique benchmark for identifying these offending traces to that that allows us to test Engine and understand how well is it able to identify problematic traces. And so in order for for us to assess this adequately, the benchmark that we’ve generated uh is a set of of

[03:48] traces with seeded problems within them. And so it’s it’s like finding a needle in a haystack of traces, and we just test Engine’s ability to find these problematic traces. Now, that benchmark is separate from another one that’s very similar, which is Engine’s ability to cluster those traces by root cause. For this benchmark, we provide Engine that the agent with a set of known errors traces, as well as a series of existing issues. And we evaluate Engine’s ability to match these known error traces to the

[04:21] the set of issues or to create new issues. And so, these are just just a couple of the benchmarks that we’ve generated. But like I said, for each one of these various tasks, we have to create new benchmarks and ensure that Engine is performing and is firing on all cylinders for each one of these different tasks that it handles. And so, the something interesting that I want to highlight as we talk about these benchmarks is that there there it really is there are two sides to this coin, where we have eval that we need to ensure these these benchmarks that we’ve created that help us to test very

[04:53] specific components of the agent’s run. But we also want to ensure that those those benchmarks are faithful to what we would see in a production environment, which is the other side of that coin. And so, in order to ensure that any of the changes that we find very effective against our benchmarks really are effective in a production environment, we dog food Engine. We try our own products a lot. And we have many different agents that we build at LangChain, including go-to-market agents that handle a bunch of go-to-market related like sending outbound, doing prospect research.

[05:25] And we also have coding agents that are invoked via Slack or via GitHub. And so, each of these agents that we have built, we run Engine on top of. And Engine will find errors, it will send those those issues to our Slack. We can investigate them. The teams that are working on on these go-to-market agents or the coding agents can tell us that it you know, Engine has found really valuable issues or something is wrong with this description. And it really helps us to balance out this process that we have had on the the benchmarking and the evaluating of Engine on these specific tasks.

[05:57] But maybe the most interesting of these of this dog fooding is that we actually run Engine on top of Engine. So, as Engine investigates traces for our go-to-market agents and for our coding agents, it produces traces. And those traces are scanned by another instance of Engine. We call it the the meta Engine. And we’ve we’ve uh hooked up this meta Engine to send us Slack notifications in the same way. And so, our team gets notified when our own product is acting up in a little way, or something might have failed, or or there’s a you know, a suboptimal response in one of the the uh

[06:31] outputs that Engine has. And so, it’s actually becoming one of the primary ways that we identify opportunities for growth on Engine, and our team is constantly monitoring this this Slack feed of notifications with these issues. I want to highlight a couple of interesting uh just notes and kind of thoughts that we’ve had as we have been uh working on improving Engine, specifically around kind of our our use of different models. Um something interesting is that different tasks obviously require different levels of intelligence. Something that I have

[07:02] been surprised by is it it may seem obvious that, you know, if you use a not a frontier intelligence model, that it will be cheaper. But I I’ve also found that for specific tasks that we run Engine on, using these non-frontier models actually can be more effective. If it’s a {quote} unquote dumb task, it’s sometimes better to use a dumber or a smaller model as opposed to these state-of-the-art models that are really expensive and and uh really bulky. And so, we we constantly play around with swapping out the models that are used for the different tasks that are handled

[07:33] by Engine. Another quick point that I want to make is is our team is totally reliant on the LangSmith platform. We spend a lot of our time looking through traces manually whenever we have a very specific problem. We also, as I mentioned, rely on this feed of engine issues that are produced. But we also use engine for our experiments platform. And so we can have this this store of record of the different experiments that we run, and we can see how our cost and our performance upon our different benchmarks is changing over time. And so as we’ve been working on

[08:07] improving this process and making engine better, as we’ve been building these benchmarks and then hill climbing against those benchmarks, we’ve been able to achieve much better scores against the different benchmarks. And so Harris had mentioned this in his keynote that we have two times better error identification against IssueBench, which is our our kind of primary benchmark for identification of issues. And then we also test the fixes that engine proposes against a a series of these industry standards industry standard coding benchmarks. And then we also pair that with

[08:39] benchmarks that we have designed specifically for these agent-related issues where we’ve seen engine get a lot better as well. So these are cool numbers, but what does that actually mean? It ultimately means more issues identified for our customers that are using engine. It means increased accuracy in our description and our root cause analysis of the problems that we’ve identified. And it means much faster resolution times for the teams that are building agents on top of LangSmith.

[09:09] Now, what I’ve talked about so far is kind of like the the process of designing evals and some of the results that we’ve seen in the aggregate. But what I want to do is is talk about a specific way that we’ve modified our harness and we’ve modified engine to more adequately find these issues. And I’m going to do so with this this little visual here. And so I have this this circle up on the screen which you can imagine within the circle it contains the complete set of of problems that might exist as you’re building agents. So any any little dot within this circle is a kind of problem

[09:40] that you can envision within the agent building problem space. Now, when we first launched Engine, our RV1 that we launched in May, you can uh you can imagine that Engine captured a portion of those problems. Now, I’d like to imagine that it’s a bigger circle than what we have in this visual, but it captured a portion of the problems that are that are you know, that exist for engineers building agents, but not all of them. And as we have worked to evaluate and to iterate against our our benchmarks, we have expanded what Engine in its in

[10:13] its previous state is able to do. But, there’s still a portion of this agent problem space that Engine in its architecture from our V1 version would never really be able to to identify. And that’s because our first version These are this is the representation of these broader improvement opportunities. And this is because in our first version of Engine, we ensured that Engine was really excellent at finding errors in a specific trace. Whether that’s a hallucination, whether that’s a broken tool call, whether

[10:45] that’s looping tool calls, context explosion, right? These are all problems that are very visible from a single trace, and Engine as it pours through traces does investigation, it can find multiple traces with that problem, cluster them together based on root cause. But, often times it’s difficult to find errors um with just a single trace. And there are some kinds of errors that that may appear the same at first glance. So, let’s say between September 1st and September 14th, our team has swapped out a new model for our agent, and we see that the cost and latency are pretty

[11:17] much the same, even though we were expecting to see a huge drop in cost or a huge drop in latency. And if I look at traces if I look at what trace A versus trace B, these might look like the exact same thing, and no change is recognizable. And even if I see that in trace A, we only had six tool calls, or in trace B, we only had 19 tool calls. These look about the same. These look not problematic, I should say. But the ability for Engine or an agent engineer to determine that the tool calls from from one step to the next has increased massively is a huge indication

[11:50] that something might be wrong. Maybe this new model has just gone haywire and it’s it’s deciding to call tools far more than it should. And so, this kind of uh context across across traces, an understanding of the history of your agent and the traces that it produces, is one of the kinds of problems that we’ve gotten much better at identifying with Engine. These kind of metric-related trends that we want to track and ensure Engine is able to catch. The other kind of problem that we have uh uh become much more capable of, this is

[12:22] These are two of of several of what we’ve worked on, is the ability for Engine to detect inefficient paths as it works to identify a problem as it works to identify or or to meet the demands of a of a customer request. Let’s say that that 5% of the time that your agent is handling a very normal request, it goes on a side quest and starts calling all sorts of tool calls or starts looking at all sorts of sources of data that it shouldn’t. This is important for your team to know that some amount of time it’s taking an inefficient path that you should be aware of, that you should work to to contain. And so, problems like this are

[12:55] examples of the kinds of problems that we’ve gotten much better at finding in Engine V2. Now, what I’ve talked about so far uh with our improvements to Engine have been uh improvements to the existing functionality within Engine as it as it finds issues, as it proposes fixes, and as it proposes evals. And what we want Engine to do is really to cover the entire agent development life cycle from this finding of issues, from the creation of fixes, but also through the testing of those fixes and

[13:28] the deploying of those fixes. And what we’ve been asking ourselves since our first launch is how can we actually test for our users? Right now, we create a a proposed fix and we hand you the evals and let you experiment on that. But the vision that we have for Engine is the finding of problems, the fixing of those problems, and the testing of that fix all autonomously. And this is what we we are releasing with our validated fixes as part of Engine. And what I want to do is walk you through how this actually works. Harrison spoke to this a little bit in

[13:58] the keynote and I want to get into some of the nitty-gritty here. Engine still finds issues as it does today. It finds an issue about tool looping and then identifies specific inputs that it’s seen in production that have broken your agent in some way. Now, to verify that this problem is real, we actually send those same inputs to your production version of your agent to verify that it is still broken in your production version. We want to confirm this is a this is an ongoing problem and reproduce the the bug as you would in software. After we’ve identified and confirmed this is a real problem,

[14:31] we will then propose a fix and spin that up in a preview branch and in a preview deployment available on our our LangSmith deployments platform. And we will run those same breaking inputs against this previewed fix version of your agent so that we can can confirm that whatever fix Engine has spun up really solves the problem that identified and that those breaking inputs are no longer breaking in this proposed version of your agent. And after verifying that this fix is effective for those inputs, we want to look at a broader set of inputs like the

[15:02] ones that you have in a LangSmith data set. And so you can configure the different data sets that you have on LangSmith and so the Engine will run evals against the existing inputs that have been breaking your agent as well as the the broader range of inputs that you want to ensure do not regress. And so what you end up with is now much more than uh a kind of proposed issue and a hint at what you might want to solve and a hint at how you might solve it. And instead you get a verified issue that we know is still breaking your agent and you get a verified fix that we know addresses the problem and does not

[15:34] regress against other examples. I’m really excited about this. I think this is like our our kind of first steps into continual learning and this process of continually making your agent better and more capable while still allowing for a human to be in the loop and monitoring the different changes that are proposed. So as was mentioned earlier, this is available in private beta right now. This is available to our LangSmith deployment customers. We are looking to expand that, but we’d love for you to to join our waitlist and try out this new

[16:04] ability to validate these fixes via engine. Now the other thing that Harrison mentioned is this ability to red team your agent. I think about this as a way to preemptively identify issues. Today the issues that engine catches are ones that have already reached production and they already have a trace for you to go and analyze and that means that it’s likely affected a user in some way. There are also ways that that we can try to break your agent before it ever actually touches a user. And so this red

[16:34] teaming functionality for engine proactively creates hypotheses for for potential inputs that might break your agent based on your agent system prompt or other details of the harness or the context that are available and tries to figure out what might cause for an unsatisfactory output from your agent and against your production deployment of the agent will hit that hit that deployment with these different inputs and monitor the different responses. And so if there are any, you know, unsatisfactory responses that

[17:04] are created, engine will cluster these together in a in a similar issue, packaged up with a proposed fix and if you’re also using our our validated fixes functionality with a validated fix to address that before it ever actually actually hits a customer as well. Again, really excited about this. This is available in private beta again to our LangSmith deployments customers and would love for you to try it out and give us your feedback. And all of this that I’ve just been talking about is all part of Engine V2. And as we’re launching it and announcing it today, we’re already thinking about

[17:37] and already working on Engine V3. And I want to give you a kind of taste of what we’re looking at. And the first is that we’re we’re absolutely looking to expand the access to these validated fixes that we’re running as well as this ability to red team against your agent for different deployment stacks. We want to make this more broadly available and we’re thinking about that today how we can hit the different endpoints and and the different deployments of your agents today to make these available. At the same time, Engine today is really good at identifying eval examples to be added to your data sets based on issues

[18:11] it’s identified, whether that’s issues that have been red teamed against and are found proactively, or whether it’s issues that have been identified in production. We find these these great inputs that are added to your regression test cases. But what we want Engine to become better at is creating a a baseline set of evals for you to run against to ensure that all of the different behaviors that you would expect out of your agent are not regressing as you make changes to the model or changes to the harness. And lastly, the one that I’ll talk on

[18:42] here is is kind of a a North Star for us as we build Engine, which is that that we want to make broader changes broader proposals, I should say, to your agent’s harness and to the models that are used for different tasks. That would mean that Engine is no longer finding these specific fixes or tweaks or optimizations to your harness, but rather it’s saying that this entire model is is too bulky, it’s too expensive for your agent. You should try this one. And we’ve actually validated this model against your evals and can confirm it’s faster and it’s cheaper. And the reason this is kind of coming

[19:17] after is because we want this whole flow of being able to identify gaps in your agent’s traces, as well as the ability to experiment on. So that instead of a very loose recommendation of of now using a model A as opposed to model B, you have a verified claim that this model A is going to perform much better against your e-vals. Now, the last quick thing that I’ll add in here uh that Harrison mentioned is we do have engine available in our in our self-hosted deployments um via bring your own key. This is going to be available in our next release of

[19:50] our self-hosted um which we are really excited about. So, very very fun to chat with you all about engine V2 and the progress that we’ve made, as well as kind of what we’re thinking about for engine V3. We have a lot of really awesome customers that have been trying engine today, that have been giving us great feedback, and that are accelerating their agent development process, and we would love for you to join this list. So, thank you.