Como criar agentes que melhoram com o tempo: modelo, harness e contexto | Interrupt London

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: How to Build Agents That Improve Over Time: Model, Harness, Context | Interrupt London · Canal: LangChain · 20:09 · Assistir no YouTube

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

Resumo

A apresentação descreve agentes como a combinação de modelo, harness e contexto, e explica como cada parte pode ser aprimorada de forma manual, com revisão humana ou, no futuro, automaticamente. O palestrante aborda fine-tuning supervisionado e RL para atualizar modelos, mudanças no código e nas instruções do harness e a evolução do contexto com base em interações. Traces e evals são apresentados como fundamentos do ciclo de melhoria: ajudam a identificar problemas, definir o que é uma boa resposta e validar alterações. A visão de longo prazo é um agente que detecta os próprios erros, cria evals e propõe suas próprias correções.

Pontos-chave

Um agente é composto por modelo, harness e contexto; cada dimensão pode ser aprimorada separadamente.
Atualizar modelos costuma exigir tempo e capital, e geralmente começa com uma decisão humana.
O fine-tuning supervisionado é adequado a tarefas mais delimitadas; RL pode atender tarefas mais complexas, mas é mais difícil de implementar.
O harness pode ser aprimorado com mudanças no código, nos prompts e nas ferramentas, usando traces para identificar problemas.
O contexto pode evoluir como texto e memória em diferentes níveis, inclusive por usuário ou organização.
Traces registram entradas, saídas e a sequência de eventos; evals definem o que é considerado um bom resultado.
Evals precisam de dados e critérios específicos do domínio, além de ambientes simulados para testar agentes com segurança.
Red teaming pode revelar problemas de forma proativa, embora avaliar universalmente a correção de respostas continue sendo difícil.
A visão de longo prazo é um ciclo em que o próprio agente identifica erros, cria evals e propõe mudanças no modelo, harness ou contexto.

Capítulos

Início	Capítulo	Resumo
00:00	O que compõe um agente	A apresentação define modelo, harness e contexto como os três componentes de um agente e introduz a ideia de melhorá-los ao longo do tempo.
03:07	Melhoria dos modelos e do harness	O palestrante compara fine-tuning supervisionado e RL e explica como traces podem orientar mudanças no código e nas instruções do harness.
06:44	Evolução do contexto e ciclo de melhoria	A apresentação mostra como contexto e memória podem evoluir e cita exemplos de produtos e projetos que propõem correções a partir de interações.
09:17	Traces e evals como fundamentos	O palestrante define os diferentes níveis de registros de execução e explica por que evals ajudam a estabelecer o que significa um bom resultado.
12:23	Critérios, ambientes de simulação e erros	A apresentação aborda critérios de avaliação, testes em ambientes simulados e formas de encontrar falhas, incluindo red teaming.
16:33	Red teaming e busca proativa por falhas	O palestrante descreve técnicas para investigar problemas de correção e outras categorias, reconhecendo a dificuldade de julgar respostas universalmente.
19:09	O agente que melhora a si mesmo	A visão de longo prazo é um ciclo em que o agente analisa erros, cria dados de eval e propõe alterações no modelo, harness ou contexto.

Citações

Essas três coisas, acreditamos, compõem o que é um agente: modelo, harness e contexto. — 02:06

A parte mais difícil do ciclo de melhoria costuma ser escolher o que lembrar, o que não lembrar e como lembrar. — 09:17

Evals são o novo PRD. — 11:53

Você quer executar seu agente e obter feedback sobre o desempenho dele. — 19:09

Conceitos e entidades

LangChain (empresa): Empresa que desenvolve ferramentas e infraestrutura para criar e observar agentes.
Deep Agents (ferramenta): Harness apresentado como exemplo, com ambiente de execução, gestão de contexto, memória e suporte a subagents.
Claude Code (ferramenta): Agente de programação citado como exemplo de harness e como fonte de traces para analisar dificuldades.
Codex (ferramenta): Agente de programação citado como exemplo de harness e como fonte de traces.
LangSmith Fine-Tuning (ferramenta): Recurso mencionado para preparar dados de traces e encaminhá-los a provedores de modelos para fine-tuning supervisionado.
SmithTune (ferramenta): CLI que interage com LangSmith para coletar e filtrar trajetórias e prepará-las para fine-tuning.
LangSmith Engine (ferramenta): Sistema experimental que analisa traces, agrupa problemas e propõe correções, testes e dados de evals com revisão humana.
OpenWiki (repo): Projeto open source voltado à criação de uma base de conhecimento atualizável para agentes, inicialmente pensado para programação.
SmithDB (ferramenta): Banco de dados criado para armazenar, consultar e visualizar dados de observabilidade de agentes.
Hex (empresa): Empresa citada por seu agente de análise de dados e por um processo que identifica lacunas de contexto.
Profound (empresa): Empresa citada por sintetizar dados em registros de marca e memórias pessoais a partir das interações com seu agente.
Fireworks (empresa): Provedor de modelos citado como opção para executar fine-tuning supervisionado.
Baseten (empresa): Provedor de modelos citado como opção para executar fine-tuning supervisionado.
red teaming (conceito): Prática de testar agentes de forma proativa para encontrar problemas, incluindo falhas de correção, segurança e imparcialidade.
traces (conceito): Registros das etapas de execução de um agente, incluindo entradas, saídas e a sequência de eventos.
evals (conceito): Avaliações que definem critérios de qualidade e permitem verificar se alterações melhoram o agente sem causar regressões.
fine-tuning supervisionado (conceito): Método que treina um modelo com trajetórias selecionadas, especialmente útil para tarefas mais delimitadas.
RL (conceito): Método que executa tarefas, avalia os resultados e atualiza o modelo por meio de ciclos de rollouts.

Tradução completa (pt-BR)

00:00 Legal. Nesta sessão, quero falar sobre algo em que pensamos bastante na LangChain e que definitivamente faz parte do futuro que imaginamos para o setor e para onde estamos indo: construir agents que melhoram com o tempo. E isso é uma estrela-guia que orienta muito do nosso modo de pensar na LangChain, embora talvez ainda demore até conseguirmos fazer isso de forma totalmente automatizada.

00:32 E, ao falar sobre isso, quero preparar o terreno falando sobre o que é um agent e como pensamos em melhorá-lo. Porque não dá para melhorá-lo se não definirmos o que ele é. Pensamos que há três partes na construção de um agent. A primeira é um modelo. Ou seja, escolher a força motriz do agent. Há vários modelos diferentes que você pode escolher, e alguns são bons em coisas diferentes. Alguns têm context windows longas. Alguns são muito rápidos. Mas é preciso escolher um para ser o principal motor de trabalho do agent. E eu diria também que há outros modelos na periferia.

01:04 Há outros modelos para proteções, avaliações e coisas do tipo, que podem fazer parte do harness, mas não da carga de trabalho principal. Enfim, no núcleo de um agent está um modelo. Depois, há o harness. Você poderia usar Deep Agents, Claude Code, Codex. Esse é o harness do modelo. O que é um harness? É o sistema ao redor do modelo que o torna realmente útil. O modelo faz todo o raciocínio e toma as decisões. Mas o harness é responsável por decidir o que o modelo vê, por executar de fato as ações que o modelo decide realizar,

01:35 por observar e verificar os resultados, por persistir informações em disco ou em bancos de dados e, na verdade, por todo o controle do que acontece nesse ciclo. Construímos o Deep Agents como um exemplo de como esse harness pode ser. Ele incorpora várias práticas recomendadas para o que esses harnesses devem fazer. Assim, inclui um ambiente de execução, que é onde ele funciona. Isso inclui um sistema de arquivos e um sandbox. Ele faz várias tarefas de gerenciamento de contexto prontas para uso. Então, lida com skills, memória e sumarização.

02:06 E também inclui intervenção humana no loop, bem como subagents, que são formas diferentes de interagir com humanos e outros agents, respectivamente. A terceira parte de um agent é o contexto. Isso pode ser Markdown. Pode incluir arquivos. Pode ser conhecimento amplo. Pode incluir as ferramentas que ele usa. Mas, quando digo contexto aqui, refiro-me principalmente a texto e outras fontes de conhecimento que são fornecidas. Na nossa visão, essas três coisas compõem um agent. Ele tem o modelo, que é envolvido por um harness,

02:37 e conectado ao contexto. E, quando falamos sobre agents que melhoram com o tempo, eles podem melhorar em qualquer uma dessas dimensões. Você pode melhorar o modelo, o harness ou o contexto. E eles também podem melhorar de várias maneiras diferentes. Podem melhorar manualmente, ou seja, com a condução de uma pessoa. Um engenheiro de IA pode entrar e conduzir o ciclo. Isso corresponde a boa parte do trabalho que engenheiros de IA fazem hoje. Também pode haver uma pessoa no loop. Você pode ter algum processo em segundo plano que esteja melhorando

03:07 esse agent ao longo do tempo, mas com uma pessoa aprovando as mudanças. Ou o processo pode ser totalmente automatizado. E, de novo, talvez essa seja a estrela-guia ou o Santo Graal. Não acho que estejamos nem perto disso, de forma alguma. Mas é nessa direção que queremos trabalhar. Então, quero falar sobre essas três dimensões diferentes. Primeiro, quero falar sobre melhorar o modelo. Em geral, os modelos são melhorados atualizando seus pesos. Agents usam modelos diferentes, então é preciso escolher quais atualizar. Talvez você atualize os pesos do modelo principal que conduz o agent,

03:37 ou talvez atualize os pesos de uma proteção, de uma verificação de eval ou de algo parecido. Isso quase sempre é iniciado por uma pessoa. Vou falar disso em um instante, mas atualizar os modelos costuma exigir bastante tempo e capital. Por isso, quase sempre é preciso que uma pessoa participe, prepare tudo e decida fazer isso. Seria bastante caro fazer isso continuamente em segundo plano ou por impulso. E vemos dois métodos diferentes para isso. Um se chama fine-tuning supervisionado; o outro é RL, ou aprendizado por reforço.

04:08 Falando muito brevemente sobre fine-tuning supervisionado, em linhas gerais, você reúne várias traces e filtra aquelas com as quais quer que o agent aprenda. Em geral, são aquelas em que ele se sai bem. Depois, basicamente, treina o modelo com esses dados. Essa é uma ótima opção para tarefas mais simples. Vemos muita gente fazendo isso para tarefas de classificação, extração ou sumarização, que têm uma definição bastante restrita. E uma das coisas que lançamos recentemente é o LangSmith Fine-Tuning

04:38 na forma do smithtune. O smithtune é uma CLI. Ele interage com o LangSmith. Baixa trajetórias, filtra e processa os dados no formato correto. Depois, encaminhamos tudo para Fireworks, Baseten ou outro desses provedores de modelos, que têm APIs prontas para fine-tuning supervisionado: basta enviar os dados e receber um modelo. Então, integramos com essas APIs e recebemos de volta um modelo otimizado. Vemos pessoas fazendo isso, mais uma vez, para tarefas mais simples.

05:09 Para tarefas mais complexas, especificamente para o modelo principal que conduz o agent, vemos algumas pessoas recorrerem a RL. RL é muito mais complicado que fine-tuning supervisionado. Não há uma oferta gerenciada de RL que seja realmente boa. Há várias ofertas gerenciadas para SFT, mas nenhuma para RL. Em geral, dá para fazer mais coisas com RL. E o funcionamento de RL é um pouco diferente. Em vez de simplesmente fornecer trajetórias, você fornece várias tarefas e executa rollouts nessas tarefas. Basicamente, executa o agent nelas.

05:40 Depois, você atribui uma pontuação em tempo real, faz a retropropagação, atualiza o agent ou o modelo que faz parte do agent e, então, executa mais rollouts. Portanto, é um pouco diferente de SFT, bem mais complicado, mas com um potencial maior. A próxima coisa que você pode atualizar é o harness. Como atualizá-lo? Bem, ele próprio é basicamente composto de código e lógica. Então, você atualizaria o código, os prompts ou as ferramentas. Em linhas gerais, o processo é bastante simples: você analisa várias traces, identifica problemas e, em seguida, faz mudanças com base nessas traces.

06:13 Provavelmente, você vai querer uma pessoa no loop, porque isso envolve mudar o código principal do agent ou as instruções principais do agent, o que geralmente afeta todos os usuários. Então, provavelmente, você vai querer que uma pessoa no loop revise essas mudanças. Mas é possível começar a automatizar o processo. E é isso que tentamos fazer com o LangSmith Engine, sobre o qual Ben falou mais cedo. O LangSmith Engine é um agent que funciona em segundo plano. Basicamente, analisa traces, monitora-as e as agrupa em diferentes problemas,

06:44 e então tenta propor correções, abrir um PR, adicionar testes, adicionar pontos de dados de evals e coisas do tipo. O próprio Engine não é nada além de um deep agent em um sandbox, com a CLI do LangSmith e alguns subagents especializados, algumas skills especializadas e alguns prompts especializados. Acreditamos que esse processo geral é um exemplo de como começar a automatizar sem ir até o fim. A pessoa continua no loop — uma parte muito importante —, mas já começamos a automatizar um pouco essa melhoria do harness. E, por fim, falando sobre melhorar o contexto,

07:15 Esta é a parte mais fácil de atualizar. É só texto. Então, é muito fácil atualizar isso. Como resultado, você pode atualizar isso em diferentes níveis. Em vez de atualizar apenas no nível central do agent, você pode começar a atualizar no nível do usuário ou da organização. E pode começar a ter memória nessas diferentes dimensões, que evolui com o tempo. Assim, de forma semelhante a como você atualizaria um harness, o processo basicamente consiste em analisar vários rastros, identificar problemas e, então, fazer alterações. E, de novo, você está fazendo alterações no texto, então é muito mais fácil fazer isso.

07:45 Há algumas empresas que, na minha opinião, fazem isso bem. Uma que quero destacar é a Hex. A Hex é um agent de análise de dados. Parte da proposta de valor deles é essa camada de contexto unificada. Essa camada de contexto unificada melhora com o tempo. Isso é uma parte central da proposta de valor. Como eles fazem isso? Basicamente, fazem algo parecido com a Engine. Executam um agent em segundo plano. O Review Agent analisa as interações para você, encontra lacunas de contexto e sugere correções. E, de novo, isso é especificamente para o agent que eles estão desenvolvendo. Mas, basicamente, eles têm esse processo em segundo plano, que analisa rastros e identifica coisas,

08:15 e depois propõe correções. A Profound é outro exemplo de empresa que, na minha opinião, faz isso bem. E eles também fazem isso no nível do usuário. Você pode ver que eles sintetizam dados constantemente em Registros de Marca. Isso talvez seja algo no nível da empresa. Mas também coletam Registros Pessoais, informados pelas interações com o AI Marketer deles. Então, conforme você interage com o agent, eles têm um processo em segundo plano que cria essa espécie de memória pessoal. Esses são exemplos de duas empresas que, na minha opinião, estão fazendo um ótimo trabalho nisso. Estamos experimentando coisas nessa linha.

08:45 Não temos nada na plataforma, mas temos um projeto open source chamado OpenWiki. O OpenWiki é basicamente a ideia de criar esse conhecimento, ou esse cérebro, para um agent, que pode ser atualizado. Então, isso é… Isso foi criado para programação. Começou… É alimentado pela análise do seu repo de código. Mas também temos integrações com seus agents de programação, então podemos analisar rastros do Codex ou do Claude Code, ver com o que eles têm dificuldade e trazer isso de volta para o OpenWiki. Então, o que essas três coisas têm em comum? Achamos que há duas coisas em comum: rastros e evals.

09:17 E achamos que essas são a base central desse ciclo de melhoria, e é nelas que investimos muito tempo. Esse ciclo de melhoria pode parecer diferente conforme o caso de uso e o setor. A parte mais difícil do ciclo de melhoria muitas vezes é escolher o que lembrar, o que não lembrar e como lembrar. E muito disso está no prompting, então é algo muito específico de cada domínio. Mas achamos que há outras formas de ajudar, principalmente com rastros e evals. É nisso, então, que estamos investindo bastante esforço. Sobre rastros: o que são rastros? Achamos que há alguns aspectos diferentes nos rastros.

09:50 Há alguns termos diferentes que usamos ao falar de rastros. O primeiro é execução. É como uma única invocação de um modelo ou uma única invocação de uma ferramenta. Basicamente, é uma única etapa. Você então junta várias dessas execuções e obtém um rastro. Esse é uma sequência dessas etapas. Você combina vários desses rastros e obtém um thread. A forma de pensar nisso é: se eu mandar uma mensagem para um agent, ele vai e realiza várias tarefas. Há várias execuções acontecendo em segundo plano. Isso, por si só, é um rastro. Quando começo a conversar com ele, crio esse thread. E, como falamos na palestra principal, as trajetórias

10:21 são uma visualização desse thread em um formato padronizado. O importante é que, em todos esses casos, você tem as entradas exatas, as saídas exatas e a sequência exata de eventos. Isso é realmente necessário, seja para fazer fine-tuning do modelo, seja para tentar depurá-lo com um agent de programação e depois atualizar o código. Poder ver exatamente o que entra, exatamente o que sai e a sequência exata é muito importante. Achamos que rastros são um novo tipo de dado. Por isso, criamos o SmithDB, um banco de dados nosso

10:51 que criamos para lidar com esse novo tipo de dado. Achamos que há novos tipos de falhas. Essas falhas são semânticas. São falhas de lógica. Há vários problemas que surgem e não aparecem nos logs tradicionais. Eles aparecem no contexto conversacional. Então, a forma de lidar com eles e de fazer a triagem precisa mudar. E, da mesma forma, a maneira de interagir com os dados e consultá-los também precisa mudar. E foi por tudo isso que criamos o SmithDB, nosso banco de dados que

11:22 foi desenvolvido especificamente para observabilidade de agents. Pensamos bastante em como estruturar esse banco de dados para que seja o melhor banco de dados para ingerir, consultar, armazenar e visualizar dados. Um exemplo disso, lançado hoje, é este filtro de IA, esta Busca por IA, em que você digita, mais uma vez, uma pergunta pela qual quer filtrar. É uma pergunta semântica. Nos bastidores, atribuímos uma pontuação a cada trajetória individualmente, de acordo com o fato de ela atender ou não ao filtro. E este é um exemplo de como

11:53 pensamos em criar esse banco de dados, otimizado para esse novo tipo de dado. Assim, você consegue ver o que está acontecendo. Consegue consultar o que está acontecendo. Mas o próximo passo são as evals. As evals são muito importantes para esse ciclo por alguns motivos. Primeiro, são o novo PRD. É uma frase de que gosto muito: você pode ter um documento de requisitos do produto que descreve o que o produto deve fazer. Em IA, há tantos casos extremos que, muitas vezes, a melhor forma de descrevê-los é por meio de evals.

12:23 As evals são onde você define o que é um bom resultado. Isso pode significar responder de determinada forma a certas consultas. Pode significar não responder a certas consultas. Definir os limites, definir o que é um bom resultado, é uma parte muito importante das evals e de definir como você quer melhorar. Então, elas são como as barreiras de proteção que vão manter você na zona segura enquanto itera nesse ciclo de melhoria. Criar evals é muito, muito difícil. Essa é uma das principais coisas em que trabalhamos com

12:53 várias pessoas. Não existe exatamente uma solução mágica para evals. Claro, podemos fornecer infraestrutura para executar evals e visualizar os resultados das evals. Mas as evals precisam ser específicas de cada domínio, tanto nos conjuntos de dados em que são executadas quanto nos avaliadores usados. Então, ainda achamos que criar evals é muito difícil. Há diferentes partes nisso. Primeiro, você precisa criar entradas realistas. E isso pode ser difícil. Talvez você nem saiba o que as pessoas vão perguntar ao seu agent. Às vezes, elas vão sair completamente do assunto. Às vezes, vão abordar algo tangencial ou próximo disso.

13:26 Mas talvez você não consiga prever todos esses casos de antemão. Então, até mesmo enumerar quais são as entradas realistas não é tão fácil quanto parece. E é por isso que o rastreamento é tão importante. Você precisa conseguir definir como é uma boa resposta. Já vimos pessoas fazerem isso de diferentes formas. Posso citar três de cabeça. Primeiro, você pode definir qual é a saída esperada, um determinado número que ela deve mencionar ou uma frase exata que deve usar. Isso é chamado de correspondência exata. Isso fica complicado com agents mais complexos,

13:58 porque geralmente é difícil fazer isso. Então, o que vemos as pessoas fazerem é definir critérios. Basicamente, o agent deve incluir na resposta uma parte que mencione isto. A resposta não deve dizer isto. Os critérios podem ser positivos ou negativos. Eles podem se aplicar à própria resposta final ou ao ambiente em que o agent está sendo executado. Muitas vezes, esses agents interagem com o ambiente. Podem alterar bancos de dados de determinadas maneiras. Podem manipular arquivos de determinadas maneiras. Então, você não quer avaliar a resposta final dele.

14:28 Você quer avaliar como ele interage com o ambiente ou, mais especificamente, qual é o estado final do ambiente. E a terceira coisa que os critérios podem avaliar é a sequência exata de tool calls também. Então, dependendo do seu caso de uso, talvez você só se importe que ele termine com o estado correto do banco de dados. Ou talvez se importe com a sequência de tool calls. E você pode escrever critérios para qualquer uma dessas coisas. Mas definir o que é considerado bom costuma ser uma das coisas mais difíceis de fazer e uma das que é melhor deixar para especialistas do domínio ou especialistas no assunto. E, por fim, a última coisa que quero destacar

14:59 é o ambiente de simulação. Então, quando você executa evals, precisa de um ambiente para executá-las. Se o seu agent interage naturalmente com sistemas de produção, provavelmente você não quer que ele acesse esses sistemas enquanto você executa várias evals, especialmente se elas fizerem operações de escrita ou realmente alterarem o banco de dados. Por isso, uma das coisas que vemos as pessoas fazerem para conseguir executar essas evals é criar ambientes de simulação nos quais possam interagir livremente com um banco de dados simulado ou com um ambiente de desenvolvimento que iniciam,

15:31 e basicamente executar essas evals de ponta a ponta, que interagem de fato com esse ambiente simulado. Pode ser complicado. Seu agent talvez interaja com vários serviços diferentes. Talvez você tenha ambientes de desenvolvimento ou de homologação para eles, ou talvez não. Se o agent interage com um sistema que você mesmo criou, pode ser mais fácil. Mas, se ele interage com o Salesforce, o que você faz? Esse não é um sistema que você controla com facilidade. Por isso, também passamos muito tempo pensando em como esses ambientes devem ser.

16:01 Além disso, também passamos muito tempo pensando em como encontrar erros do agent. De novo, há diferentes maneiras de fazer isso. Você pode examinar como as pessoas realmente usam o seu agent e procurar situações em que ele falha. Pode pedir a especialistas do domínio que pensem em como usariam o agent, testem-no e depois identifiquem quando ele comete erros. A abordagem dos especialistas do domínio é meio manual e cara. Já a análise dos rastreamentos de produção depende basicamente de as ocorrências já terem acontecido. E, às vezes, algo pode acontecer com tão pouca frequência

16:33 que, quando você percebe, já é tarde demais. Você ainda pode querer contabilizar isso como um erro, mas isso não ajuda tanto quanto teria ajudado se você soubesse antes. Essa é justamente a ideia por trás do red teaming, que lançamos recentemente. A ideia do red teaming é ajudar a encontrar esses problemas de forma proativa. E há várias maneiras diferentes de pensarmos em como fazer isso. Analisamos várias dimensões diferentes. Uma delas é simplesmente a correção geral da resposta. Conseguimos encontrar problemas em que o agent simplesmente não responde corretamente?

17:04 O desafio aqui é: como sabemos se a resposta está correta ou não? O que quero dizer é que, na verdade, não é nada trivial avaliar se uma resposta está correta. Isso exige muito conhecimento do domínio. Se você conseguisse fazer isso de forma confiável como parte do ciclo do agent, então simplesmente faria isso como parte do ciclo do agent: executaria e avaliaria. E, se o resultado fosse considerado incorreto, continuaria executando. Por isso, ter um avaliador universal de correção é uma das coisas que tornam isso difícil de fazer. Ainda não resolvemos esse problema.

17:34 Não temos um avaliador universal de correção. Mas o que fazemos é usar alguns algoritmos diferentes que testam o agent de maneiras inteligentes, para que possamos saber qual deveria ser a resposta correta. Por exemplo, um dos algoritmos que temos envia ao agent duas consultas muito semelhantes — pelo menos semanticamente semelhantes. Se ele responder de maneiras semanticamente diferentes, sabemos que uma delas está errada. Então podemos investigar qual delas tem mais chances de estar certa ou errada. E, fazendo isso, podemos fundamentar a resposta naquilo que sabemos ser a resposta correta

18:07 É algo que você não poderia fazer dentro do ciclo, porque provavelmente não faria isso enquanto o agent está sendo executado. Seria complicado demais e caro demais. Mas isso fornece uma espécie de ponto de referência. Há outros tipos de problemas, relacionados à segurança e também à justiça. A longo prazo, queremos ter basicamente um menu desses diferentes problemas que você possa verificar e que gere esses relatórios — relatórios de red teaming — sob demanda. Uma das coisas que também estamos combinando com isso é

18:38 que mencionei um dos problemas de executar evals: o ambiente simulado. Você vai precisar dele para isso, porque esse processo executa o agent. Por isso, também estamos trabalhando bastante para criar esses ambientes simulados. Em particular, nossa equipe de labs está fazendo muita pesquisa nessa área. Em linhas gerais, este é o ciclo de melhoria, bem abstrato e de alto nível, que você quer estabelecer para aprimorar seu agent com o tempo. Você quer executar o agent. Quer obter feedback sobre o desempenho dele, seja de uma pessoa, seja de um avaliador online.

19:09 Depois, você quer analisar o que aconteceu dentro daquele rastreamento para obter esse feedback. Quer adicionar isso como um ponto de dados de eval, para que, ao tentar melhorar, possa garantir que está de fato melhorando nesse aspecto e não regredindo em relação aos casos anteriores. E então quer sugerir mudanças para o agent: atualizar os pesos do modelo, o código do harness ou o contexto. A versão realmente futura disso é aquela em que o próprio agent faz tudo. O agent percebe que cometeu um erro. O agent cria um ponto de dados de eval por conta própria,

19:39 sugere as próprias mudanças e basicamente gera as próprias correções, seja no contexto, no código do harness ou nos pesos do modelo. Estamos começando a pensar em como isso seria no Engine. É, sem dúvida, uma visão de longo prazo. Há muitas nuances nesse ciclo também. De novo, este ciclo está apresentado em um nível muito alto, então há muitas nuances. Passamos bastante tempo pensando nelas. Se você está pensando em como fazer isso e quer explorar essas nuances a fundo com a gente, venha conversar conosco sobre esse ciclo. Ficamos muito animados com isso.

20:09 Era isso que eu tinha para esta palestra. Obrigado pelo tempo de vocês.

Transcrição original

[00:00] Cool. For this session, I want to talk about something that we think a lot about at LangChain, and that is definitely part of the future of where we think the industry and where we are going, which is building agents that improve over time. And so this is a North Star that, while doing this in a fully automated way, may not be anytime soon. This is a North Star that guides a lot of how we think about things at LangChain.

[00:32] And so as I talk about this, I want to set the stage with talking about just like what is an agent and how do we think about improving it? Because you can’t improve it if you don’t define what it is. And so we think there are three parts to building an agent. First is a model. And so this is choosing the powerhouse of the agent. And there’s a bunch of different models that you can choose from. And some are good at different things. Some have long context windows. Some are really fast. But choosing one to be the core workhorse of an agent. And then the other thing I’d say is there’s other models at the periphery.

[01:04] There’s other models for guardrails and evaluations and things like that that might be part of the harness, but not the core workload. But anyways, at the core of an agent is a model. Then there is the harness. So you could use Deep Agents, Claude Code, Codex. This is the harness of the model. What is a harness? This is the system around the model that makes it really useful. So the model does all the reasoning and decision making. But the harness is responsible for deciding what the model sees, for actually taking the actions of what the model decides to do,

[01:35] for observing and verifying results, for persisting things onto disk or into databases, and is really related to all the control around what happens in this loop. We’ve built Deep Agents as an example harness for what this can look like. It encodes a bunch of best practices for what these harnesses should do. So it has an execution environment, which is where it runs. So this includes a file system and sandbox. It does a bunch of off-the-shelf context management. So it deals with skills, memory, summarization.

[02:06] And then it has human in the loop as well as subagents for different ways for interacting with humans and other agents, respectively. And then the third part of an agent is context. And so this is markdown. This can be files. This can be knowledge that’s broad. It can be tools that it uses. But when I say context here, I mostly refer to kind of like text and other sources of knowledge that is brought. And these three things, we think, make up what an agent is. It’s got the model, you wrap it in a harness,

[02:37] and you connect it to context. And so when we talk about agents improving over time, they can improve across any of those dimensions. So you can improve the model, you can improve the harness, or you can improve the context. And they can improve in a bunch of different ways as well. So they can improve manually. So they can be human driven. So you can have a human AI engineer go in and kind of like drive the cycle. And that’s a lot of what AI engineers do today. They can be human in the loop. You can have some background process that is improving

[03:07] this agent over time. But you have a human approving things. Or they can be fully automated. And again, this is maybe the North Star or the Holy Grail. And I don’t think we’re there right now by any stretch of the imagination. But this is where we want to work towards. And so I want to talk about these three different dimensions. I want to talk about improving the model first. So models are generally improved by updating the weights of the model. Agents use different models, so you want to choose which ones to update. And so maybe you update the weights of the core model that’s driving the agent,

[03:37] or maybe you update the weights of a guardrail or an eval check or something like that. This is almost always human-initiated. So the way that you update the models, and I’ll touch on that in a second, but the way that you update the models is generally pretty time and capital intensive. And so you almost always want to have a human going in and preparing and deciding to do this. It would be pretty costly to just do this continuously in the background or on a whim. And there’s two different methods that we see for doing this. One is called supervised fine-tuning, and the other is RL, or reinforcement learning.

[04:08] Talking very briefly about supervised fine-tuning, at a high level, you take a bunch of traces. You filter to ones that you want the agent to learn on. And so these are generally ones where it does well. And then you basically train the model on that. And this is a really good option for simpler tasks. So we see people doing this a lot for classification or extraction or summarization tasks, where it’s pretty narrowly defined. And so one of the things that we launched recently is LangSmith Fine-Tuning

[04:38] in the form of smithtune. smithtune is a CLI. It interacts with LangSmith. It pulls down trajectories. It filters them. It processes them into the right data format. We then hand off to Fireworks or Baseten or another one of these model providers that have, they actually have a bunch of off-the-shelf supervised fine-tuning, basically, APIs where you can just pass in data and get back a model. And so we plug into that and then get back an optimized model. And so we see people doing this, again, for kind of like simpler tasks.

[05:09] For more complex tasks, specifically like that core model that’s driving the agent, we see a few people reaching for RL. So RL is a lot more complicated than supervised fine-tuning. There’s no managed offering for RL that’s really that great. So there are a bunch of managed offerings for SFT. There’s none for RL. You can generally do more things with RL. And the way that RL works is a little bit different. Rather than just giving it trajectories, you give it a bunch of tasks. And you do rollouts over those tasks. You basically run the agent over it.

[05:40] You then score it in real time, backprop it, update the agent or the model that’s part of the agent, and then do more rollouts. And so a little bit different than SFT, a lot more complicated, but higher ceiling. The next thing you can update is the harness. The harness, how do you update it? Well, it itself is basically code and logic there. And so you’d update the code, or you’d update the prompts, or you’d update the tools. The general process for this at a high level is pretty simple. You look at a bunch of traces. You identify issues. You then make changes based on those traces.

[06:13] You’ll probably want a human in the loop for this, because this will be changing core code of the agent, or core instructions of the agent that will usually propagate to all users. And so you probably want some human in the loop to review these things. But you can start to automate it. And so LangSmith Engine, and Ben talked about LangSmith Engine earlier, LangSmith Engine is our attempt to do this. So this is an agent running in the background. It basically runs over traces, monitors them, clusters them into basically different issues,

[06:44] and then tries to propose fixes, put up a PR, add tests, add eval data points, things like that. Engine itself is nothing more than a deep agent in a sandbox with LangSmith CLI and some specialized subagents, some specialized skills, and some specialized prompts. And so this general process we think is an example of starting to automate, but not going fully there. Still human in the loop, very important part, but starting to automate some of this improvement of the harness. And then lastly, talking about improving the context,

[07:15] this is the easiest to update. This is just text. And so it’s very easy to update this. And as a result, you can update this at different levels. So rather than just updating this at purely the core agent level, you can start to update this at the user or org level. And you can start to have memory at those different dimensions that evolves over time. And so similar to how you’d update a harness, the process is basically look at a bunch of traces, identify issues, and then make changes. And again, you’re making changes to the text, so it’s a lot easier to do.

[07:45] There’s a few companies that I think do this well. One I want to call out is Hex. And so Hex is a data analytics agent. Part of their value prop is this unified context layer. This unified context layer improves over time. That’s a core part of the value prop. How do they do it? They basically do something similar to Engine. They run an agent in the background. So the Review Agent analyzes interactions for you and finds context gaps and suggests fixes. And again, it’s specifically for the agent that they’re building. But they basically have this background process, looking at traces, identifying things,

[08:15] and then proposing fixes. Profound is another example of a company that I think does this well. And they actually do this at the user level as well. So you can see that they constantly synthesize data into Brand Records. That’s maybe like a company-level thing. But then it also collects Personal Records informed by interactions with your AI Marketer. So as you’re interacting with the agent, they have a process in the background that will create this basically personal memory. So these are examples of two companies that I think are doing a really good job of this. We’re experimenting with things in this vein.

[08:45] We don’t have anything in the platform, but we do have an open source project called OpenWiki. OpenWiki is basically this idea of creating this knowledge or this brain for an agent that can be updated. So this is… This is built for coding. It started… It’s populated by looking at your coding repo. But we actually have integrations with your coding agents, so we can look at Codex or Claude Code traces and see what it struggles with, and then bring it back into OpenWiki. So what’s common across all of these three things? We think there’s two things that are common, traces and evals.

[09:17] And we think these are the core foundation of this improvement loop, and it’s where we spend a lot of time. This improvement loop may look different for different use cases and different verticals. The hardest part of the improvement loop is oftentimes choosing what to remember and what not to remember and how to remember. And a lot of that is in the prompting, and so that’s very domain-specific. But we think there are other ways that we can help, namely with traces and evals. And so this is where we’re putting a bunch of effort. So traces, what are traces? We think there’s a few different aspects of traces.

[09:50] So there’s a few different terms that we use when talking about traces. First is run. This is like a single invocation of a model or a single invocation of a tool. It’s basically a single step. You then add up a bunch of those runs and you get a trace. And this is a sequence of those steps. You combine a bunch of those traces and you get a thread. And so the way to think about this is if I message an agent, it goes and does a bunch of work. There’s a bunch of runs happening in the background. That itself is one trace. When I start having a conversation with it, I create this thread. And then trajectory, as we talked about in the keynote, trajectories

[10:21] are a view over this thread in a standardized format. The important thing is that for all of these, you have the exact inputs, the exact outputs, and the exact sequence of events. And this is really needed, whether you’re going to be fine-tuning the model or trying to debug it with a coding agent and then update the code. Being able to see exactly what goes in, exactly what comes out, and the exact sequence is really important. We think traces are a new type of data. That’s why we built SmithDB, which is a database of our own

[10:51] that we built to deal with this new type of data. We think there’s new types of failures here. The failures here are semantic failures. They’re logic failures. There are a bunch of issues that pop up that don’t show up in traditional logs. They show up in the conversational context. And so how you deal with those and how you triage those needs to change. And likewise, how you interact with the data, how you query it, also needs to change. And all of that is why we built SmithDB, which is our database that we

[11:22] purpose-built for agent observability. We think a bunch about how to structure this database to be the best database for ingesting, querying, storing, visualizing data. The example of this that we launched today is this AI filter, this AI Search, where you type in, again, a question that you want to filter on. This is a semantic question. And under the hood, we score each trajectory individually according to whether it meets that filter or not. And so this is an example of how we

[11:53] think about building this database that is optimized for this new type of data. So you can see what’s going on. You can query what’s going on. But next comes evals. So evals are really important for doing this loop for a few reasons. First, they’re the new PRD. And so this is a saying that I really like, where you might have a product requirements document describing what the product should do. In AI, there’s so many edge cases that the best way to describe that oftentimes is in the form of evals.

[12:23] So evals are where you define what good looks like. And so good can mean you respond in a certain way to certain queries. It can mean you don’t respond to certain queries. Defining the limits, defining what good looks like is a really important part of evals and a really important part of defining how you want to improve. And so this is kind of like the guardrails that are going to keep you in the safe zone as you iterate in this improvement loop. Building evals is really, really hard. This is one of the main things that we work with

[12:53] a bunch of folks on. There’s not really a silver bullet for evals out there. Sure, we can provide infrastructure for running evals and visualizing eval results. But evals need to be domain-specific, both the datasets that they run on and the evaluators that are used. And so we still think building evals is really hard. There’s different parts of this. So first, you need to come up with realistic inputs. And so this can often be hard. You might not know what people will even ask your agent. Sometimes they’ll go completely off topic. Sometimes they’ll go orthogonally or close to it.

[13:26] But you may not be able to predict all these cases up front. And so even being able to just enumerate what realistic inputs are is not as easy as it sounds. And this is why tracing is so important. You need to be able to define what a good answer looks like. There’s different ways that we’ve seen people do this, maybe calling out kind of like three off the top of my head. One, you can define what the expected output is, a certain number that it should mention, an exact kind of like phrase that it should use. This is kind of called an exact match. This gets complicated for more complex agents,

[13:58] because it’s usually hard to do that. And so what we see people do is then defining criteria. Basically, this agent should have part of the answer that mentions this. This answer should not say this. It could be positive or negative criteria. These criteria could act on either the final answer itself or the environment that the agent’s running in. So oftentimes, these agents are interacting with the environment. They might be changing databases in certain ways. They might be manipulating files in certain ways. And so you don’t want to judge its final answer.

[14:28] You want to judge how it interacts with its environment, or more specifically, what the end state of the environment is. And the third thing that the criteria can judge is actually the exact sequence of tool calls as well. And so depending on your use case, you may just care that it ends with the right database state. Or you might care about the sequence of tool calls. And so you can write criteria for either of those. But defining what good looks like, this is oftentimes one of the hardest things to do and one of the things that’s best done by domain experts or subject matter experts. And then the last thing that I want to call out

[14:59] is the simulation environment. So when you run evals, you need an environment to run them in. If your agent naturally interacts with production systems, you probably don’t want it hitting production systems as you run a bunch of evals, especially if those are doing write operations or actually changing the database. And so one of the things that we see people doing in order to be able to run these evals is coming up with these simulation environments where they can basically interact freely with either like a mock database or a dev environment that they spin up,

[15:31] basically run these end-to-end evals that actually do interact again with this simulated environment and run that way. This can be tricky. Your agent may interact with a bunch of different services. You may or may not have kind of like dev or staging things for those. If the agent’s interacting with a system that you create, that might be easier. If it’s interacting with Salesforce, what do you do there? That’s not a system that you kind of easily own. And so we also spend a lot of time thinking about what these environments should look like.

[16:01] And then on top of that, we also spend a lot of time thinking about how do you find agent mistakes. So again, there’s different ways to do this. You can look through how people actually use your agent and look for places where it fails. You can have domain experts think about how they would use the agent, try it out, and then see when it messes up. The domain expert one is kind of manual and costly. The looking at production traces one, this basically relies on the instances having already happened. And sometimes something might happen so infrequently

[16:33] that by the time you catch it, it’s too late. And you still might want to quantify that as an error, but it doesn’t do you as good as if you’d known about it ahead of time. And that’s really the idea behind red teaming, which we launched recently. The idea behind red teaming is to help find these issues proactively. And so there’s a bunch of different ways that we think about doing this. There’s a bunch of different dimensions that we look at. So one is just the overall correctness of the response. Can we find issues where the agent is just not correct in how it responds?

[17:04] The challenge here is how do we know if it’s correct or not? So what I mean by this is in order to judge whether an answer is correct or not is actually not trivial at all. That requires a ton of domain knowledge. If you could do that reliably as part of the agent loop, then you just do it as part of the agent loop and run it and then judge it. And then if it says it’s incorrect, just keep on running it. And so having this universal judge for correctness is one of the things that makes this hard to do. We haven’t solved that.

[17:34] We don’t have a universal judge for correctness. But what we do is we have a few different algorithms that probe the agent in clever ways so that we do know what the correct answer should be. So for example, one of the algorithms that we have is we basically send two very similar queries, at least semantically similar queries, to the agent. And if it responds in semantically different ways, we know one of them is wrong. And then we can investigate which one is more likely to be right or more likely to be wrong. And so by doing that, we can ground basically the answer in

[18:07] what we know the right answer to be. It’s not something that you could do in the loop, because you’re probably not going to do that as the agent’s running. That would be too crazy and too expensive. But it provides this kind of reference point. There’s other types of issues. There’s types of issues that are related to security, that are related to kind of like fairness. In the long run, what we want to have is basically a menu of these different issues that you can check for, and that they can generate these basically reports, these red teaming reports on the fly. One of the things that we’re also marrying with this,

[18:38] I mentioned kind of like one of the issues with running evals is this simulated environment. You’ll need that for this because this does run the agent. And so we’re also doing a lot of work on basically creating these simulated environments. And our labs team in particular is doing a lot of research there. So at a high level, this is like the really high level abstract kind of like flywheel that you want to set up in order to improve your agent over time. You want to run your agent. You want to get feedback on how it does, either by a human or by an online judge.

[19:09] You then want to go in. You want to see what happened inside of that trace to get that feedback. You want to add that as an eval data point so that as you try to improve, you can make sure that you’re actually improving on that and not regressing against previous ones. And then you want to suggest changes to the agent, either update to the model weight, update to the harness code, or update to the context. The really kind of future version of this is where all of this is done by the agent itself. And so the agent notices that it made a mistake. The agent goes, creates an eval data point of its own,

[19:39] suggests its own changes, and it basically generates its own fixes, again, either to the context or the harness code or the model weights. We’re starting to think about what this looks like in Engine. This is very much a North Star vision. There’s a ton of nuance in this loop as well. Again, this loop is very high level, so there’s a ton of nuance there. We spend a ton of time thinking about the nuance. If you’re thinking about how to do this and want to dive deep into the nuance with us, please talk to us about this loop. We get really excited by this.

[20:09] So that’s all I got for this talk. So thank you guys for the time.