O chatbot de suporte da ShopEasy pode responder à pergunta “Onde está meu pedido?” chamando uma função de backend, como lookup_order, e transformando o resultado em uma frase útil que o usuário possa ler.
Uma maneira simples de definir um Modelo de Linguagem de Grande Porte (LLM), neste curso, é dizer que ele recebe o texto que enviamos e prevê o próximo texto a ser enviado de volta — funcionando como um recurso de preenchimento automático extremamente poderoso, capaz de gerar parágrafos inteiros.
Mesmo em uma única pergunta sobre um pedido, a ShopEasy já lida com algumas entradas distintas. O prompt do sistema é a instrução privada que a ShopEasy envia com cada solicitação; por exemplo: “Você é o suporte da ShopEasy. Seja conciso. Peça o número do pedido caso ele não tenha sido informado.” O histórico da conversa é o registro contínuo das interações anteriores, incluído pela ShopEasy para garantir a consistência do modelo. A entrada do usuário é a nova mensagem, como “Onde está meu pedido?”. As ferramentas são funções executadas no servidor pela ShopEasy — como lookup_order e request_refund — quando o chatbot precisa de dados ou de realizar uma ação.
Uma vez que a ShopEasy possui esses componentes, a solicitação segue um ciclo repetível. Uma mensagem do usuário chega à API da ShopEasy, e a aplicação monta um prompt para o modelo concatenando o prompt do sistema, o histórico da conversa e a nova entrada do usuário. A aplicação envia esse prompt a um provedor de LLM, que retorna uma saída do modelo: ou uma resposta textual direta ou uma proposta de chamada de ferramenta com argumentos.
Quando o modelo propõe uma chamada de ferramenta, o código da aplicação ShopEasy decide se deve executá-la e, então, chama uma função específica — como lookup_order para obter o status de envio ou request_refund para iniciar um reembolso. Em seguida, a ShopEasy envia o resultado da ferramenta de volta ao modelo como uma nova mensagem, permitindo que ele elabore a resposta final destinada ao usuário; apenas essa resposta final é enviada ao usuário. Um detalhe importante para a segurança e a depuração posterior é que o modelo não possui memória interna entre as chamadas; portanto, a ShopEasy deve reenviar o histórico da conversa a cada interação, caso contrário, o modelo responderá como se nunca tivesse interagido com aquele usuário antes. Vamos ilustrar esse ciclo em um diagrama de fluxo de solicitação.
Este diagrama torna visível o limite de confiança. A entrada do usuário não é confiável, pois qualquer chamador pode digitar um texto arbitrário; da mesma forma, os resultados das ferramentas não são confiáveis, pois uma ferramenta pode retornar conteúdo inesperado que acaba sendo alimentado de volta ao modelo. [fontes][/fontes]
Uma implicação importante desse ciclo para a segurança é que o modelo não lê o banco de dados, não emite reembolsos nem aplica políticas. O modelo apenas gera texto sugerindo o próximo passo, enquanto o código da aplicação ShopEasy é o componente que realmente executa ações e retorna dados por meio de ferramentas. [fontes][/fontes]
Essa separação só permanece clara se mantivermos três identidades distintas. O usuário final é o cliente que consulta um pedido; suas permissões devem limitar quais pedidos ele pode visualizar e quais ações pode solicitar. O serviço ShopEasy é o nosso próprio backend, que possui capacidades mais amplas, como acesso ao banco de dados e a possibilidade de executar a função request_refund. A credencial do provedor de LLM é a chave de API ou o token de serviço que o ShopEasy utiliza para chamar o endpoint do modelo; essa credencial autoriza apenas o uso do modelo, e não ações do cliente. Misturar essas identidades gera falhas nas quais o backend gasta dinheiro, expõe dados ou realiza ações em nome de um usuário que não deveria ter permissão para acioná-las. Se algo der errado, qual parte pode realmente fazer valer as regras: o texto do prompt, o LLM ou o código da aplicação ShopEasy? [fontes][/fontes]