top of page
  • Foto do escritorRan Isenberg

Crie um chatbot com Amazon Bedrock: automatize chamadas de API usando Powertools para AWS Lambda e CDK

retirado de https://aws.amazon.com/bedrock/
retirado de https://aws.amazon.com/bedrock/

Bedrock e LLMs são os garotos legais da cidade. Decidi descobrir o quão fácil é construir um chatbot usando a capacidade dos agentes Bedrock de acionar uma API com base no esquema OpenAPI com o novo suporte Bedrock que o Powertools para AWS oferece.


Este post vai te ensinar como usar agentes do Amazon Bedrock para automatizar chamadas de API baseadas em função Lambda usando Powertools para AWS e CDK para Python. Também vamos discutir as limitações e pegadinhas dessa solução com agentes Bedrock.


Aviso Legal: Eu não sou um cara de IA, então se você quiser aprender mais sobre como isso funciona por baixo dos panos, este não é seu blog. Eu vou te mostrar um código prático para configurar agentes Bedrock com suas APIs em 5 minutos.

 

Índice

 

Introdução à base rochosa

O Amazon Bedrock é um serviço totalmente gerenciado que oferece uma escolha de modelos de base (FMs) de alto desempenho de empresas líderes em IA - https://aws.amazon.com/bedrock/

Bedrock apresenta uma afirmação ousada:

A maneira mais fácil de criar e dimensionar aplicativos de IA generativa com modelos de base

No entanto, o fato de que eu poderia construir tal aplicativo em uma hora ou mais fala muito sobre essa afirmação. No entanto, eu tive ajuda; usei o Powertool para a excelente documentação do AWS Lambda e o novo suporte para agentes Bedrock.


Do meu ponto de vista, a Bedrock oferece uma ampla gama de APIs e agentes que permitem que você interaja com LLMs de terceiros e os utilize para qualquer finalidade, dependendo da experiência do LLM - seja como auxiliar de uso geral, compor música, criar imagens a partir de texto ou chamar APIs em seu nome.

O Bedrock não requer nenhuma infraestrutura específica para você implantar (VPCs etc.) ou gerenciar. É um serviço totalmente gerenciado, e você paga apenas pelo que usa, mas pode ficar caro. O modelo de preços é bastante complexo e varia muito dependendo dos modelos que você usa e dos recursos que você seleciona.

Recursos muito procurados, como barreiras de proteção (filtros de linguagem limpos, scanners de informações pessoais identificáveis, etc.) aumentam o custo, mas, novamente, são totalmente gerenciados.

Agentes Bedrock

Os agentes permitem que aplicativos de IA generativos executem tarefas multietapas em sistemas e fontes de dados da empresa

Os agentes são seus chatbots amigáveis que podem executar tarefas multietapas. No nosso caso, eles chamarão APIs de acordo com a entrada do usuário.

Os agentes de base têm vários componentes:

  1. Modelo - o LLM que você seleciona para o agente usar.

  2. Instruções - o prompt inicial que define o contexto para a sessão do agente. Esta é uma prática clássica de engenharia de prompt : 'você é um agente de vendas, vendendo X para clientes'.

  3. Grupos de ações - Você define as ações do agente para o usuário. Você fornece um esquema OpenAPI e uma função Lambda que implementa esse esquema OpenAPI.

  4. Bases de conhecimento – Opcional. O agente consulta a base de conhecimento para contexto extra para aumentar a geração de resposta e a entrada em etapas do processo de orquestração.


Se você quiser aprender como eles funcionam, confira a documentação da AWS .


https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html
https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html
 

Powertools para suporte AWS Bedrock

Os agentes do Bedrock, ou apenas "agentes", entendem a entrada de texto livre, encontram a API correta para acionar, criam a carga útil de acordo com o OpenAPI e descobrem se a chamada foi bem-sucedida.

No início, não percebi que a Bedrock espera que suas APIs mudem.

Geralmente, eu sirvo minhas APIs com o API Gateway, que aciona minhas funções Lambda. O evento enviado para a função tem metadados e informações do API Gateway, e o corpo vem como uma string codificada em JSON.

Com agentes, eles não interagem com uma URL do API Gateway. Eles interagem com uma função Lambda (ou mais de uma), cada uma fornecendo um arquivo OpenAPI diferente. Os agentes invocam as funções diretamente, enviam uma entrada diferente do API GW e esperam uma resposta diferente da resposta regular do API Gateway .


O Powertools abstrai essas diferenças. Consegui pegar uma função Lambda que funcionava por trás de um API Gateway, usar o manipulador de eventos do Powertools para o API Gateway e alterar o tipo de manipulador de eventos para o manipulador Bedrock, e funcionou com os agentes. Incrível!


Abaixo, você pode ver o fluxo dos eventos:

  1. Os agentes usam LLM e entrada do usuário para entender qual API (função Lambda) invocar usando o arquivo OpenAPI que descreve a API.

  2. O Powertools lida com a análise de entrada do agente Bedrock, validação e rotas para a função interna correta. Cada função interna lida com uma rota de API diferente, criando assim um Lambda monolítico .

  3. Sua lógica de negócios personalizada é executada e retorna uma resposta que adere ao esquema OpenAPI.

  4. O Powertools retorna uma resposta no formato Bedrock que contém a resposta da seção 3.


Isso me leva ao problema número um — você não pode usar a função Lambda com agentes Bedrock e um API Gateway. Você precisa escolher apenas um.

Este é um grande problema. Isso significa que preciso duplicar minhas APIs — uma para Bedrock e outra para clientes regulares. As entradas e respostas são muito diferentes. É realmente uma pena que a Bedrock não tenha estendido o modelo do API Gateway com o contexto e os cabeçalhos dos agentes Bedrock.


Se você quiser ver uma variação do TypeScript sem o Powertools, sugiro fortemente que confira a postagem de Lee Gilmore .

https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/bedrock_agents/
Fluxo de agentes Bedrock - Documentação do Powertool https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/bedrock_agents/

 

O que estamos construindo

Construiremos um agente Bedrock que representará um vendedor. Pediremos ao agente para comprar pedidos em nosso nome. Usaremos meu projeto de código aberto AWS Lambda Handler Cookbook template que representa um serviço de pedidos. Você pode fazer pedidos chamando a API POST '/api/orders' com uma carga JSON de nome do cliente e contagens de itens. Os pedidos são salvos em uma tabela do DynamoDB por uma função Lambda.

O modelo Cookbook foi recentemente apresentado em um artigo da AWS .


Alterei o template e substituí o API Gateway por agentes Bedrock. Vamos construir as seguintes partes:

  1. Agentes com infraestrutura CDK como código

  2. Gerar arquivo de esquema OpenAPI

  3. Código do manipulador de função Lambda para dar suporte ao Bedrock

Todos os exemplos de código podem ser encontrados no branch bedrock .


Infraestrutura

Começaremos com o código CDK para implantar a função Lambda e o agente.

Você também pode usar o SAM de acordo com a documentação do Powertool.


Primeiro, adicione as construções 'cdklabs' ao seu arquivo de poesia.

poesia deps
poesia deps

Vamos rever a construção do Bedrock.

Esta construção é 90% daquela mostrada na excelente documentação do Powertool:


Nas linhas 18 a 24, criamos o agente Bedrock.

Na linha 21, selecionamos o modelo que desejamos usar.

Na linha 22, fornecemos a instrução de engenharia imediata.

Na linha 23, preparamos o agente para ser usado e testado imediatamente após a implantação.

Nas linhas 26-38, preparamos o grupo de ação e conectamos a função Lambda. Obtemos a entrada para o arquivo OpenAPI. O arquivo OpenAPI neste exemplo reside no arquivo 'docs/swagger/openapi.json'.


Manipulador de função Lambda - Powertools para Bedrock

Vamos revisar o código da função Lambda que implementa a API do serviço de pedidos.


Na linha 17, iniciamos o manipulador de eventos Bedrock Powertools. A validação de entrada é habilitada por padrão.

Nas linhas 27-43, definimos nossa API POST /API/orders. Esses metadados ajudam o Powertools a gerar um arquivo OpenAPI para nós (veja a próxima seção). Ele define a descrição da API, o esquema de entrada, as respostas HTTP e seus esquemas.

Nas linhas 59-62, definimos o ponto de entrada da função. De acordo com o caminho de entrada e o comando HTTP (POST), ele roteará a solicitação do agente Bedrock para a função interna correta. Neste exemplo, há apenas uma função na linha 20.

Nas linhas 49-53, manipulamos a entrada (validada automaticamente pelo Powertools!) e a passamos para o manipulador lógico interno para criar o pedido e salvá-lo no banco de dados. Esta é uma implementação arquitetônica hexagonal. Você pode aprender mais sobre isso aqui .

Na linha 56, retornamos um objeto de resposta Pydantic, e o Powertools manipula o formato de resposta Bedrock para nós.


Encontre o código completo aqui .


Gerando arquivo OpenAPI


O Powertools for AWS Lambda fornece uma maneira de gerar o arquivo OpenAPI necessário a partir do código.


Vejamos a versão simplificada abaixo:

Você pode executar este código e então mover o arquivo de saída para a pasta que você atribuiu na construção do CDK na linha 28.

 

Agente Bedrock em ação

Depois de implantar nosso serviço, podemos entrar no console do Bedrock e ver nosso novo agente nos esperando:


Agentes de console
Agentes de console

Vamos testá-lo e conversar com ele no console:

Teste de agentes
Teste de agentes

Sucesso! Ele entendeu que queríamos fazer um pedido; ele construiu a entrada de payload, executou a função Lambda com sucesso e até exibiu sua saída.


Vamos ver qual entrada ele enviou para a função (eu imprimi dos logs do Lambda)


Como você pode ver, é muito diferente do esquema do API Gateway. A linha 8 contém todos os tipos de metadados sobre a origem do agente, o caminho da API, o payload, as linhas 9-18 e o comando HTTP, que é mostrado na linha 20.


Vamos verificar a funcionalidade da função e a precisão dos agentes examinando o pedido que foi salvo com sucesso na tabela do DynamoDB.


Nova ordem adicionada à tabela do DynamoDB
Nova ordem adicionada à tabela do DynamoDB

Como você pode ver, o ID do pedido corresponde à resposta do agente e aos parâmetros de entrada.

 

Limitações e pegadinhas

A documentação e os exemplos de código do Powertools foram perfeitos. Funcionou imediatamente.

A Powertools fez um excelente trabalho. No entanto, tive vários problemas com agentes Bedrock:

  1. Os agentes Bedrock atualmente suportam o esquema OpenAPI 3.0.0, mas não o 3.1.0. O Pydantic 2, que eu uso para definir meus modelos, gera a versão mais recente. Eu tive que mudar o número para 3.0.0 manualmente e esperar que minha API não use nenhum recurso especial do 3.1.0. Felizmente, isso não aconteceu, mas foi difícil encontrar o erro, pois ele foi gerado durante a implantação do CloudFormation ('Arquivo OpenAPI rejeitado') e não explicou por que meu arquivo de esquema era inadequado. O excelente suporte do Powertool em seu canal do Discord me ajudou. Obrigado, Leandro!

  2. Seu Lambda precisa ser monolítico e conter todas as rotas do seu OpenAPI. Uma alternativa seria criar vários grupos de ação com vários arquivos OpenAPI, o que é possível, mas não escala com um grande número de rotas e APIs.

  3. Este é um problema importante - Você não pode usar a função Lambda com agentes e um API Gateway. Você precisa escolher. Isso significa que preciso duplicar minhas APIs - uma para Bedrock, outra para clientes regulares. As entradas e respostas são muito diferentes. É realmente uma pena que a Bedrock não tenha estendido o modelo API Gateway com o contexto e os cabeçalhos dos agentes Bedrock.

  4. Meu agente enviou um tipo de payload incorreto. Ele marcou o payload como um inteiro, mas continuou enviando o objeto JSON como uma string em vez de um número. Minha API tem validação estrita, então não converteu a string em um número e falhou na solicitação. Tive que depurar o problema, o que não foi tão fácil quanto eu esperava. Sua milhagem pode variar com diferentes LLMs; escolhi o "mais simples".


 

Resumo

Conversar com um "agente" que resultou na criação de uma entrada do DynamoDB é bem incrível. Ainda mais incrível é o fato de que consegui fazer isso funcionar tão rápido. Serviços gerenciados com suporte ao CDK são o caminho a seguir!


Espero que o Bedrock faça mudanças de acordo com meu feedback e melhore a experiência do usuário. A implementação atual não me permite usá-lo em APIs de produção sem duplicar muito código.

Opmerkingen


bottom of page