Os LLMs interagem de forma diferente. Em vez de apenas verificar os dados em relação a um esquema, um LLM lê uma descrição em linguagem simples sobre o que uma ferramenta ou outro sistema pode fazer. Como desenvolvedor, tenho que expor as informações que um LLM chamador pode ler, consumir e, por fim, usar para entender como operar minha interface. Você não fornece ao LLM um esquema rígido. Em vez disso, você fornece uma descrição que inclui a finalidade, as entradas e os resultados esperados de uma ferramenta.
O LLM usa sua compreensão da linguagem para descobrir como usar a ferramenta com base nessa descrição. É como passar da verificação de um formulário rígido para a compreensão de instruções verbais. Isso é mais flexível, especialmente para tarefas menos estruturadas, mas significa que a interação depende da interpretação, que pode ser menos previsível do que os formatos rígidos. Você pode ver essa metodologia sendo usada em uma série de coisas, desde o Model Context Protocol (MCP) até o Agent Development Kit de código aberto do Google, como mencionei em meu último blog.
Os prompts são os novos "documentos de API"
Portanto, para os LLMs, o "contrato de API" ou a documentação é essencialmente o prompt que você escreve para descrever a ferramenta ou o recurso. Em vez de escrever anotações de código ou arquivos de esquema, os desenvolvedores agora escrevem descrições claras e detalhadas que informam ao LLM:
- O que ela faz: A principal função da ferramenta.
- O que ele precisa: As entradas necessárias, talvez com exemplos ou dicas de formato.
- O que ele devolve: O resultado ou a ação esperada.
- Quaisquer regras: Restrições ou diretrizes importantes.
Isso significa que a engenharia de prontidão está se tornando uma habilidade crucial. Para que esses sistemas funcionem, é imprescindível que as equipes de desenvolvimento possam escrever instruções que os LLMs possam entender e agir de forma confiável.
Exemplo simples: Uma ferramenta de "assistente de calendário" para um LLM
Vamos imaginar uma ferramenta mais dinâmica, como um assistente de calendário, e descrevê-la para um LLM:
Descrição geral da ferramenta: "Esta é uma ferramenta de assistente de calendário. Ela pode agendar novas reuniões e encontrar intervalos de tempo disponíveis para um grupo de pessoas."
Função 1: CreateMeeting Prompt: Nome da ferramenta: CreateMeeting. Descrição: Agenda uma nova reunião no calendário. Entradas necessárias: attendees (uma lista de endereços de e-mail), subject (texto do título da reunião), startTime (a data e a hora em que a reunião deve começar; tente interpretar horários relativos como "amanhã às 15h" ou "na próxima segunda-feira de manhã"), e duration (texto que descreve a duração, por exemplo, "1 hora", "30 minutos"). Entrada opcional: local (texto, por exemplo, "Sala de conferência B" ou um link de chamada de vídeo). Responde com uma mensagem de confirmação que inclui os detalhes finais da reunião ou um erro se o agendamento falhar (por exemplo, conflito de horário, participantes inválidos). Se a hora de início ou a duração for ambígua, peça esclarecimentos ao usuário antes de prosseguir. Assuma que os horários estão no fuso horário local do usuário, a menos que especificado de outra forma.
Como o LLM poderá usá-lo (após interpretar a solicitação do usuário): CreateMeeting(attendees=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")
Função 2: FindFreeTime Prompt: Nome da ferramenta: FindFreeTime. Descrição: Encontra intervalos de tempo comuns disponíveis para um grupo de pessoas em um período de tempo especificado. Entradas necessárias: attendees (uma lista de endereços de e-mail) e duration (texto que descreve a duração desejada da reunião, por exemplo, "1 hora"). Entrada opcional: timeWindow (texto que descreve quando procurar, por exemplo, "na próxima semana", "na tarde desta sexta-feira", "nos próximos 3 dias"; o padrão é a semana de trabalho atual se não for especificado). Responde com uma lista de horários de início disponíveis (data e hora) ou uma mensagem indicando que não foram encontrados slots comuns. Seja específico sobre o intervalo de datas que está sendo pesquisado se for usada uma janela relativa como "próxima semana". Assuma que os horários estão no fuso horário local do usuário, a menos que especificado de outra forma.
Como o LLM poderá usá-lo (após interpretar a solicitação do usuário): FindFreeTime(attendees=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")
Aqui, os prompts orientam o LLM sobre como lidar com listas, interpretar entradas potencialmente confusas, como datas e durações, e até mesmo quando pedir esclarecimentos. Isso está mais próximo de como funcionam as interações com ferramentas de LLM no mundo real.
O desafio: Ambiguidade e precisão do prompt (Preparando o cenário para a Parte 3 desta série)
A primeira vez que você cria uma ferramenta como essa como desenvolvedor, pensa consigo mesmo: 'Isso é incrível! Escrever esses agentes é muito fácil". E então, como acontece com frequência na vida de um desenvolvedor, a realidade bate na sua cara...
Embora os prompts do Calendar Assistant tentem lidar com algumas imprecisões (como "amanhã às 15h"), confiar em descrições de linguagem natural pode introduzir maneiras novas e interessantes de o software fazer algo que você realmente não esperava.
Considere estes exemplos:
- Solicitação de CreateMeeting conflitante:
- Usuário: "Marque uma reunião de duas horas para mim e Charlie nesta sexta-feira à tarde, mas certifique-se de que seja antes das 14 horas".
- Problema: "Sexta-feira à tarde" geralmente implica horários após as 12h ou 13h. "Antes das 14h" cria um conflito potencial ou uma janela muito estreita (por exemplo, das 13h às 14h). O prompt não informa explicitamente ao LLM como lidar com restrições conflitantes em um único parâmetro, como o horário. Ele deve priorizar "tarde" ou "antes das 14 horas"? Ele deve apresentar o conflito ao usuário?
- Solicitação vaga de FindFreeTime:
- Usuário: "Encontre tempo para uma conversa rápida com Dave na próxima semana".
- Problema: o que é um "bate-papo rápido"? O parâmetro de duração precisa de algo mais específico, como "15 minutos" ou "30 minutos". O prompt atual exige uma duração e não especifica um padrão ou como lidar com termos vagos como "quick chat". O LLM pode falhar ou ter que adivinhar.
- Suposições implícitas no FindFreeTime:
- Usuário: "Encontre uma hora para a reunião da equipe na próxima quarta-feira".
- Problema: quem é "a equipe"? O LLM precisa da lista de participantes (endereços de e-mail). O prompt exige isso, mas a solicitação do usuário depende de o LLM conhecer o contexto de "a equipe". Um bom fluxo de interação pode envolver a pergunta do LLM: "Quem faz parte da equipe?" se a lista de participantes não for fornecida ou inferida a partir do histórico da conversa. Nesse caso, o agente que está ligando pode chamar outro agente para descobrir quem é "a equipe".
- Fusos horários não especificados:
- Usuário (em Londres): "Agende uma reunião com Priya (em Nova York) para amanhã às 9 horas".
- Problema: são 9 horas da manhã, horário de Londres, ou 9 horas da manhã, horário de Nova York? Os prompts atuais incluem uma suposição básica ("Assume-se que os horários estão no fuso horário local do usuário, a menos que especificado de outra forma"), mas lidar com fusos horários corretamente é complexo. E se o usuário não especificar e os participantes estiverem em fusos diferentes? A ferramenta precisa de uma lógica de backend sofisticada para lidar com fusos horários ou de instruções muito mais explícitas no prompt sobre como solicitar e confirmar informações de fuso horário se houver vários locais envolvidos. Uma simples suposição pode levar a erros de agendamento.
Esses exemplos mostram que, mesmo com prompts decentes, a ambiguidade nas solicitações do usuário, as informações conflitantes ou as suposições não declaradas (como fusos horários) podem levar a erros, ações incorretas ou ciclos de esclarecimento frustrantes. A eficácia da interação LLM-API depende diretamente da qualidade e da integridade do prompt que descreve os recursos e as limitações da ferramenta. Ele precisa abranger não apenas o caminho feliz, mas também como lidar com imprecisões, informações ausentes, possíveis conflitos e detalhes contextuais, como fusos horários.
Tornando-se complexo: quando vários agentes de IA conversam (transição para questões mais profundas)
Descrever uma única ferramenta com precisão é uma coisa, mas fica muito mais complicado quando você tem vários agentes de IA tentando trabalhar juntos. Como você escreve prompts para que o Agente A entenda claramente o que o Agente B pode ou não fazer, inclusive como o Agente B lida com a ambiguidade? Como eles se coordenam? Como garantir que eles trabalhem juntos de forma confiável, sem problemas inesperados causados pela forma como interpretam as instruções uns dos outros? Descobrir como definir essas interações de forma clara e confiável usando a linguagem é um grande desafio que estamos enfrentando à medida que esses sistemas evoluem.
Veja como a Akamai pode potencializar suas cargas de trabalho de IA em escala. Fale com nossos especialistas hoje mesmo.
Comentários