O prompt como um livro de regras - Orientando os agentes do LLM além das instruções básicas

Em nossa jornada de integração de LLMs (Large Language Models) com APIs tradicionais, vimos como os prompts se tornam os novos "documentos de API", descrevendo o que uma ferramenta pode fazer. A princípio, tudo parece muito simples. Você dá ao LLM acesso a algumas ferramentas, descreve-as e, voilà, você tem um agente inteligente! Mas, como muitos de nós estamos descobrindo, há uma diferença crucial entre um LLM que pode usar uma ferramenta e um LLM que usa uma ferramenta de forma inteligente ou eficaz em um contexto mais amplo. Isso aborda diretamente os desafios que vimos com nosso simples Assistente de calendário.

É nesse ponto que frequentemente encontramos o que chamo de síndrome do "estagiário entusiasmado". Seu agente de LLM, assim como um estagiário entusiasmado, mas inexperiente, segue diligentemente as instruções explícitas de suas ferramentas. No entanto, pode faltar a ele o julgamento experiente de um funcionário experiente que intuitivamente considera regras não declaradas, fatores humanos sutis ou o "melhor resultado geral". Os LLMs atuais são excepcionalmente bons em compreender e executar com base no texto que lhes é dado, mas não compreendem inerentemente o contexto implícito ou o "porquê" sutil por trás de uma tarefa que muitas vezes dita o verdadeiro sucesso.

Isso significa que, como desenvolvedores, nossa função evolui. Não estamos mais apenas descrevendo as funções da ferramenta; estamos elaborando meticulosamente manuais de regras em nossos prompts, orientando o LLM em processos complexos de tomada de decisão.

Estudo de caso: O assistente de calendário "atencioso"

Vamos revisitar nossa ferramenta "Calendar Assistant" da Parte 2. Imagine que nosso agente principal do LLM tenha acesso às duas funções principais que definimos:

1. CreateMeeting(attendees, subject, startTime, duration, location): Agenda uma reunião.
2. FindFreeTime(attendees, duration, timeWindow): Localiza os slots disponíveis.

Nossos prompts iniciais para essas ferramentas lidam com a interpretação básica e são configurados para respeitar o horário de trabalho padrão da empresa, ou seja, de segunda a sexta-feira, das 8h às 18h, horário local, para cada funcionário.

Agora, um usuário, que é um líder de equipe baseado em Londres, faz esta solicitação: "Precisamos realizar uma sessão estratégica crítica de uma hora para o Projeto Atlas no início da próxima semana. Os participantes serão eu, Maria (que também mora em Londres) e Ben (que mora em Edimburgo). Isso exige uma preparação significativa de todos os participantes. Por favor, agende-a em nossa sede em Londres".

O agente "estagiário entusiasmado" começa a trabalhar. Ele consulta os calendários usando o FindFreeTime e descobre que segunda-feira às 8:30 AM GMT está tecnicamente "livre" para todos dentro do horário de trabalho padrão definido.

• Ele passa a fazer a chamada: CreateMeeting(attendees=["lead@example.com", "maria@example.com", "ben@example.com"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

Tecnicamente, uma reunião foi agendada. Mas será que o resultado é bom? Considere as implicações:

1. Considerações sobre viagens ignoradas: Para Ben, que mora em Edimburgo, uma reunião presencial às 8h30 em Londres é altamente problemática. Isso exigiria uma viagem extremamente cedo na segunda-feira de manhã ou, mais provavelmente, exigiria que ele viajasse no domingo à noite. O agente, ao observar apenas o "horário de trabalho disponível das 8 às 18 horas" no calendário, deixou de considerar completamente as impraticabilidades logísticas e o impacto pessoal de uma reunião no início da manhã que exigiria uma viagem significativa. Ele não diferenciou uma vaga às 8h30 para um participante local de uma vaga para um participante remoto que precisasse estar fisicamente presente.
2. Tempo de preparação negligenciado: O usuário declarou explicitamente que essa é uma "sessão de estratégia crítica" que exige "preparação significativa". O agendamento para a primeira hora da manhã de uma segunda-feira (8h30) pressiona implicitamente os participantes a usarem seu tempo pessoal do fim de semana para se prepararem, caso queiram estar prontos para um início tão cedo.

Esse é o momento em que, como desenvolvedor, você percebe que o agente executou sua tarefa com base na disponibilidade explícita do calendário, mas deixou de lado fatores humanos implícitos cruciais e considerações práticas. Faltou o discernimento para garantir um resultado genuinamente eficaz e atencioso.

Codificação de "experiência" e "consideração" em prompts

Para elevar nosso "estagiário" a um "assistente experiente", precisamos incorporar uma lógica mais sofisticada no prompt de orientação do agente principal (ou as instruções abrangentes que ele segue ao orquestrar ferramentas). Isso vai além de apenas descrever o FindFreeTime ou CreateMeeting ferramentas em si. Precisamos informar ao agente como se comportar de forma mais atenciosa.

Isso geralmente envolve instruir o agente a procurar e usar o que podemos considerar como uma "terceira ferramenta" ou uma camada adicional de informações e lógica. Nesse caso, trata-se de localização do participante, contexto da viagem e natureza da reunião. Nosso agente pode precisar implicitamente (ou explicitamente por meio de outra ferramenta como GetUserProfile(email)) acessar ou inferir:

• O local de trabalho principal de cada participante.
• O tipo de reunião (por exemplo, presencial ou virtual).
• As implicações da importância e do momento da reunião (por exemplo, "reunião crítica na manhã de segunda-feira").

Com acesso a esses "dados contextuais", precisamos adicionar uma lista de instruções no estilo "se... então..." ao prompt mestre do agente:

Snippet revisado da lógica do prompt do agente (conceitual):

"...Quando encarregado de agendar uma reunião:

1. Reunir contexto aprimorado: Para cada participante, determine sua localização provável (por exemplo, usando GetUserProfile(attendee_email)). Observe se a reunião foi especificada como "presencial" e se os participantes são remotos.
2. Leve em conta as viagens para reuniões presenciais:
   • Se a reunião é presencial, e um participante é remoto, e um horário proposto para o início da manhã (por exemplo, antes das 10h, horário local do local da reunião) é identificado:
     • Em seguida, sinalize isso para o solicitante. Por exemplo: "Ben estará viajando de Edimburgo para essa reunião presencial. Para permitir uma viagem confortável na segunda-feira, você prefere iniciar a reunião às 10h30 ou mais tarde, ou devo explorar opções virtuais?
3. Considere o tempo de preparação para reuniões críticas:
   • Se uma reunião seja descrita como "crítica", "importante" ou que exija "preparação significativa e está sendo agendado para um horário mais cedo em uma segunda-feira (ou imediatamente após um feriado):
     • Em seguida, solicite a confirmação do solicitante. Por exemplo: "Para essa sessão crítica de segunda-feira que exige preparação, um horário de início às 8h30 permitiria que todos tivessem tempo suficiente na própria manhã de segunda-feira ou um horário por volta das 10h seria mais adequado para permitir a preparação no dia?
4. Lidar com conflitos gerais de fuso horário/horário de trabalho (conforme discutido anteriormente):
   • (Incorpore a lógica para priorizar as "janelas sociais principais", lidar com intervalos fora delas e pedir confirmação para horários inconvenientes em diferentes fusos horários, se aplicável, mesmo para reuniões virtuais).
5. Respeite as substituições explícitas do usuário:
   • Se o usuário confirmar explicitamente um acordo inconveniente (por exemplo, "Sim, Ben está ciente e viajará no domingo"), prossiga, talvez com uma confirmação final: "Entendido. Agendamento confirmado'".

Prompts: De descrições simples a algoritmos complexos

Como você pode ver, o prompt do nosso agente principal evoluiu significativamente. Ele não é mais apenas uma lista de ferramentas disponíveis. É uma árvore de decisão detalhada e condicional. É um algoritmo em miniatura expresso em linguagem natural. Essas declarações "se... então..." tornam-se a espinha dorsal do processo de "raciocínio" do agente, orientando-o não apenas para uma solução, mas para uma solução melhor.

O desafio - e a habilidade emergente dos desenvolvedores - é prever essas possíveis armadilhas e codificar preventivamente a "experiência", a "política da empresa" ou a "cortesia comum" diretamente nas instruções do LLM. Isso prova que, embora os LLMs tragam um poder incrível, o trabalho do desenvolvedor em orientar esse poder para aplicativos realmente úteis e atenciosos é mais crucial do que nunca. Trata-se de transformar aquele "estagiário entusiasmado" em um colega digital confiável e experiente, um prompt cuidadosamente elaborado de cada vez.

Olhando para o futuro, a aspiração é que esses agentes evoluam para além até mesmo dos manuais de regras mais detalhados baseados em avisos, permitindo que eles realmente "aprendam" com os resultados de suas ações. Embora hoje codifiquemos meticulosamente a experiência, a próxima fronteira envolve agentes que podem refinar suas estratégias de forma autônoma. Imagine um agente que tenha acesso não apenas a ferramentas e dados para realizar seu trabalho, mas também a um feedback contínuo sobre o sucesso ou o fracasso dessas ações na obtenção dos resultados comerciais desejados. Nosso Calendar Assistant, por exemplo, se observar constantemente convites para reuniões às 12:00 PM sendo rejeitados por um determinado usuário com a justificativa de que "saiu para almoçar", poderá aprender com o tempo a despriorizar ou até mesmo evitar sugerir esse horário para essa pessoa, sem que um desenvolvedor tenha que programar explicitamente uma regra "nenhuma reunião ao meio-dia para o usuário X".

Agora, extrapole essa capacidade de aprendizado para processos comerciais mais complexos. Um agente inicialmente programado com um conjunto de procedimentos para, por exemplo, a integração de clientes ou a logística da cadeia de suprimentos, poderia, medindo os principais indicadores de desempenho e observando os resultados do mundo real, começar a identificar ineficiências ou descobrir caminhos mais ideais. Com o passar do tempo, ele poderá ajustar sutilmente sua abordagem, redefinir as prioridades das etapas ou até mesmo sugerir modificações nos processos básicos que os desenvolvedores projetaram inicialmente. O futuro, portanto, poderá ver os desenvolvedores não apenas como os arquitetos iniciais desses comportamentos de agente, mas também como cultivadores de sistemas em que os agentes refinam e otimizam progressivamente seus próprios "algoritmos" operacionais, tornando-se realmente parceiros dinâmicos e de aprendizado para atingir as metas de negócios.

Veja como a Akamai pode potencializar suas cargas de trabalho de IA em escala. Fale com nossos especialistas hoje mesmo.