Middleware para agentes profundos gerenciados

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: Middleware for Managed Deep Agents · Canal: LangChain · 04:13 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Infraestrutura e hardware de IA, Privacidade e proteção de dados

Resumo

Nathan, PM da LangChain, apresenta o middleware como uma forma de estender o ciclo de vida de um agent com comportamentos personalizados, como aplicação de políticas, tolerância a falhas e limites de uso. O vídeo demonstra o middleware PII pré-construído para detectar e redigir endereços de e-mail antes que a entrada chegue ao modelo. Em seguida, mostra como criar um middleware personalizado de logging que registra as chamadas de ferramentas. A recomendação é começar pelas opções pré-construídas e consultar a documentação ao desenvolver funcionalidades personalizadas.

Pontos-chave

• Middleware estende o ciclo de vida de um agent com comportamentos personalizados.
• Casos de uso incluem logging, analytics, transformação de prompts, novas tentativas, tratamento de erros, limites de taxa e guardrails.
• O middleware PII pode detectar e redigir endereços de e-mail na entrada antes que ela chegue ao modelo.
• A redação impede que o agent use o e-mail para realizar uma busca de cliente.
• O exemplo mostra a etapa do middleware PII no grafo e a entrada modificada antes de chegar ao modelo.
• Middleware personalizado pode envolver chamadas de ferramentas para registrar quais ferramentas são usadas.
• Os logs podem ser enviados para tracing ou usados para acompanhar o desempenho.
• É recomendável experimentar o middleware pré-construído antes de implementar uma solução própria.

Capítulos

Início	Capítulo	Resumo
00:00	O que é middleware	Nathan explica como middleware estende o ciclo de vida de agentes profundos gerenciados e cita usos como políticas, tolerância a falhas e limites.
00:33	Casos de uso e exemplo de redação de e-mail	O vídeo apresenta usos comuns de middleware e começa a demonstrar a redação de e-mails com o middleware PII.
01:37	Redação de dados pessoais antes do modelo	O middleware detecta e redige o e-mail na entrada, impedindo que o agent o use para buscar os dados do cliente.
02:40	Criação de middleware personalizado	O apresentador cria um middleware de auditoria para registrar as ferramentas usadas pelo agent.
03:42	Inspeção dos logs e conclusão	O exemplo mostra as chamadas de ferramentas registradas e recomenda começar pelas opções pré-construídas.

Citações

Middleware é uma forma de estender o ciclo de vida do seu agent com comportamentos personalizados. — 00:00

Alguns usos possíveis incluem logging ou analytics, transformar prompts, adicionar novas tentativas ou tratamento de erros. — 00:33

Antes mesmo de chegar ao modelo, a entrada foi modificada no próprio processo. — 02:07

O middleware pré-construído é um ótimo lugar para começar. — 04:13

Conceitos e entidades

• middleware (conceito): Camada que estende o ciclo de vida de um agent com comportamentos personalizados.
• PII middleware (ferramenta): Middleware pré-construído que detecta e pode redigir informações pessoais, como endereços de e-mail.
• Managed Deep Agents (conceito): Agentes profundos gerenciados nos quais é possível configurar middleware para personalizar seu comportamento.
• LangChain (empresa): Empresa e plataforma mencionada como responsável pelo contexto de desenvolvimento apresentado no vídeo.
• LangSmith (ferramenta): Produto citado no exemplo como local onde a entrada redigida não é armazenada.
• Nathan (pessoa): PM da LangChain que apresenta os exemplos de middleware.

Tradução completa (pt-BR)

00:00 Sou Nathan. Sou gerente de produto aqui na LangChain e hoje vou falar sobre middleware para agentes profundos gerenciados. Middleware é uma forma de estender o ciclo de vida do seu agent com comportamentos personalizados. Ele permite gerenciar coisas como aplicação de políticas, tolerância a falhas e muito mais quando seu agent interage com ferramentas, interage com o modelo ou atinge limites, como o uso de tokens. Temos uma ótima documentação sobre como começar a usar middleware, e nossos SDKs de middleware funcionam muito bem com agentes profundos gerenciados. Então, você pode usar princípios que talvez já conheça ou princípios que já existam por aí para criar

00:33 ótimos middleware para seus agentes profundos gerenciados. Alguns casos de uso possíveis incluem monitoramento com registro em logs ou análise, transformação de prompts, adição de novas tentativas ou lógica de tratamento de erros, ou adição de limites de taxa e proteções. Vamos adicionar alguns exemplos a um agent profundo gerenciado em que tenho trabalhado. Vamos começar. Vamos adicionar um middleware de PII para ocultar e-mails. Neste agent, tenho uma ferramenta que permite fazer buscas pelo e-mail do cliente, e vamos fazer com que ela deixe de funcionar usando o middleware. Mas, para começar, vamos mostrar o comportamento atual. Se eu perguntar em qual plano a Ops está,

01:05 então o agent deve conseguir usar a ferramenta de busca por e-mail para recuperar os dados do cliente e responder especificamente à pergunta. Então, ele encontrou o e-mail e executou a chamada à ferramenta usando esse e-mail. Se eu olhar o gráfico de linhas, vou ver que o middleware está configurado e que ele passa as coisas para o modelo. Neste caso, ainda não há middleware, mas vamos adicionar um e veremos esse gráfico se expandir. Para adicionar o middleware de PII, vou simplesmente incluí-lo neste atributo de middleware aqui.

01:37 Neste caso, estou configurando o middleware de PII com o atributo de e-mail a ser bloqueado. Quero usar uma estratégia de ocultação e quero aplicá-la à entrada enquanto ela é encaminhada ao modelo. Se eu voltar aqui, vou ver o middleware adicionado ao gráfico. Se eu voltar ao chat e tentar fazer a mesma pergunta, mas desta vez usando o middleware, vamos ver em qual plano está o e-mail. E, quando eu enviar esta solicitação, esse middleware pré-construído vai detectar automaticamente o e-mail e

02:07 ocultá-lo, impedindo que o agent o veja. O agent tentará fazer uma busca, mas ela não vai funcionar, porque ele não recebe o e-mail. Então, se eu voltar aqui, vou ver “Em qual plano está o e-mail ocultado?”. Isso nem sequer fica armazenado no LangSmith. E, se você olhar o gráfico, vai ver que isso está passando pelo fluxo. Ele executa o middleware de PII e então oculta o e-mail nessa etapa do processo. Assim, antes mesmo de chegar ao modelo, a entrada é modificada diretamente. Se você estiver tentando bloquear tipos específicos de PII, pode usar esse middleware de PII. As outras ferramentas aqui são

02:40 muito úteis para casos comuns. Então, experimente definitivamente diferentes opções, dependendo do que você está tentando fazer. E vale sempre a pena usar o middleware pré-construído antes de criar o seu próprio. Mas, em alguns casos, você vai querer definir um middleware personalizado. Neste exemplo, vamos criar um middleware personalizado que faz algo básico: registro em logs. Vou criar um novo diretório de middleware no meu projeto e adicionar este arquivo de auditoria. Nesse arquivo de auditoria, vou simplesmente incluir o exemplo aqui. E ele usa este decorador de encapsulamento de ferramenta,

03:10 que vai encapsular automaticamente qualquer chamada a ferramenta que for usada. Há vários hooks diferentes no pacote de middleware que você pode usar, dependendo de onde quer posicionar o middleware no ciclo de vida do agent. Neste caso, ele será acionado em cada uso de ferramenta, porque queremos registrar qual ferramenta está sendo usada. Certo, configurei o middleware e agora vou adicioná-lo à definição do meu agent. Então, se olharmos o gráfico de linhas aqui, podemos ver que temos este middleware de chamadas à ferramenta de patch

03:42 E ele é executado no início. Se eu interagir com este agent, por exemplo, enviando a mesma pergunta que já fizemos, e der uma olhada nos logs do agent, quando eu executar isso, veremos que ele vai registrar as chamadas às ferramentas que estão sendo usadas. Aqui, ele está apenas registrando tudo na saída padrão, mas, claro, você poderia enviar isso para o sistema de rastreamento, monitorar o desempenho ou fazer o que precisar neste caso. Então, estas são as chamadas às ferramentas que foram executadas. Portanto,

04:13 essa foi uma introdução rápida a middleware e ao uso tanto do middleware integrado quanto da funcionalidade de middleware personalizado. Temos muita documentação excelente sobre a criação de middleware personalizado, então recomendo que você confira para saber mais, caso queira explorar maneiras mais criativas de desenvolver. Em geral, porém, o middleware pré-construído é um ótimo ponto de partida. Então, dê uma olhada se tiver interesse em adicionar mais funcionalidades personalizadas em torno das chamadas às suas ferramentas ou em controlar o conjunto de informações enviado ao LLM.

Transcrição original

[00:00] I’m Nathan. I’m a PM here at LangChain and today I’m going to be talking about middleware for managed deep agents. Middleware is a way to extend your agent life cycle with customized behavior. It allows you to manage things like policy enforcement, fault tolerance, and more when your agent interacts with tools, interacts with the LM, or hits limits like token usage. We have great documentation about how to get started with middleware and our middleware SDKs all play great with managed deep agents. So, you can take principles you may already know or use principles that already exist out in the wild to build

[00:33] great middleware for your managed deep agents. Some potential use cases include tracking with logging or analytics, transforming prompts, adding retries or error handling logic, or adding rate limits and guardrails. We’ll add a few examples to a managed deep agent I’ve been working on. Let’s get started. We’ll add a PI middleware to redact email. In this agent, I have a tool which allows look up by customer email and we’re going to break that with the middleware, but to start let’s show the current behavior. If I ask what plan is

[01:05] Ops on, then the agent should be able to use that look up by email tool to fetch the customer data and answer the question specifically. So, it found the email, it ran the tool call using that email. If I look at the line graph, you’ll see it’s got the middleware set up and it passes things to the model and in this case there’s no middleware yet, but we’ll add some and we’ll see this graph expand. So, to add the PI middleware, I’m just going to add into this middleware attribute here.

[01:37] In this case, I’m setting up PI middleware with the attribute email to be blocked. I want to use a redaction strategy and I do want to apply this to the input as it passes through to the LM. If I look back here, I’ll see the middleware added to the graph. If I go back to the chat and I try asking the same question, but this time using the middleware, we’ll see what plan is the email on. And when I send this request in, this pre-built middleware will automatically detect the email and

[02:07] redact it and prevent the agent from seeing it. The agent will attempt to do a lookup, but it actually won’t work because it doesn’t get the email. So, if I look back here, you’ll see what plan is redacted email on. So, this isn’t even stored inside of LangSmith. And if you look at the graph, you can see that this is passing through. It runs the PII middleware and then it redacts it at that step in the process. So, before it even hits the model, the input has been modified in place. If you’re trying to block specific types of PII, you could use that PII middleware. Other tools in here are

[02:40] really handy for common cases. So, definitely experiment with different options here depending on what you’re trying to do. And it’s always worth using the pre-built middleware before you go ahead and build your own. But in some cases, you’re going to want to define custom middleware. In this example, we’ll create some custom middleware that just does something basic, logging. So, I’ll create a new middleware directory in my project and I’ll add this audit file. And in this audit file, I’m just going to bring in the example here. And this uses this wrap tool

[03:10] called decorator, which is going to automatically wrap any tool call that’s used. And there’s a bunch of different kits from the middleware package that you can use depending on where you want to place your middleware in the agent life cycle. In this case, this is going to come around every single tool use because we want to log what tool is being used. Okay, so I’ve set up the middleware and now I’m going to add this to my agent definition. So, if we take a look at the line graph here, we can see we have this patch tool

[03:42] calls middleware. And this runs at the beginning. And if I interact with this agent, for example, sending the same question that we’ve been asking already, and I take a look at the agent logs. When I run this, we’ll see this is going to actually log the tool calls that are being used. Here, it’s just logging them into my standard out, but obviously you could send this to tracing, you could track performance, or whatever you need to do in this case. So, here’s the tool calls that were run. So,

[04:13] that’s a quick introduction to middleware and using both the built-in middleware and the custom middleware functionality. We have a ton of great documentation on building custom middleware, so I definitely encourage checking that out to see more if you’re trying to get more creative with how you build. In general though, the pre-built middleware is a great place to start. So, definitely give it a look if you’re curious about adding more custom functionality around your tool calls or controlling the set of information that’s sent to the LLM.