Prompting: o contrato com o modelo

Todo LLM moderno recebe mensagens rotuladas com um papel (role). Os três que importam são system, user e assistant.

System é onde você, arquiteto, fala com o modelo antes do usuário. É o espaço para definir identidade, tom, restrições e formato de saída. Pense nele como o briefing que um gerente dá a um funcionário antes da reunião com o cliente: o funcionário (modelo) vai interagir com o cliente (user), mas as regras já estão estabelecidas.

User é a mensagem de quem usa o sistema — pode ser um humano digitando ou sua aplicação montando uma string programaticamente. Assistant é a resposta do modelo; em few-shot (veremos adiante) você também injeta mensagens de assistant para mostrar exemplos de resposta esperada.

Um erro comum é colocar tudo no user e não usar o system. O resultado é um modelo que ignora restrições porque elas chegaram misturadas ao pedido, sem autoridade de configuração. Regras de negócio, persona e formato pertencem ao system. O user deve carregar apenas o dado variável — a pergunta, o texto a processar, o contexto da sessão.

Um bom prompt tem quatro ingredientes: contexto, instrução clara, formato de saída e, quando necessário, exemplos.

Contexto é o que o modelo precisa saber para não inventar: quem é o usuário, qual o domínio, quais restrições existem. Sem contexto, o modelo preenche lacunas com probabilidade — e probabilidade nem sempre é o que você quer.

Instrução clara significa verbo de ação + escopo + restrição. "Resuma" é fraco. "Resuma em até três frases, focando em impacto financeiro, sem mencionar nomes de pessoas" é um contrato.

Formato de saída reduz pós-processamento. Se você precisa de JSON, diga no system. Se precisa de lista numerada, diga. O modelo segue formato quando instruído — não por padrão.

Exemplos (few-shot) são o atalho mais poderoso quando a instrução por si só é ambígua. Mostrar dois ou três pares input/output esperados calibra o modelo melhor do que qualquer adjetivo como "detalhado" ou "profissional". Zero-shot funciona para tarefas simples e bem definidas; few-shot entra quando o padrão de saída é específico demais para descrever só com palavras.

Um padrão que uso em produção: system define persona + regras + formato; user traz apenas {{variavel}}. Isso torna o prompt versionável, testável e separado do dado.

Aqui está a parte que mais vejo ser ignorada: prompt não dá conhecimento novo ao modelo. Se o modelo foi treinado até março de 2024 e você precisa que ele responda sobre um evento de outubro de 2024, nenhum prompt resolve isso. O modelo vai alucinar ou dizer que não sabe — e ambos são comportamentos corretos dado o que ele tem.

Da mesma forma, prompt não dá ferramentas. Você pode instruir o modelo a "consultar o banco de dados", mas ele não tem como fazer isso sozinho. A capacidade de agir no mundo — chamar APIs, buscar documentos, executar código — vem de arquitetura: RAG para conhecimento externo, tool calling para ações. Essas são as duas próximas aulas.

O que o prompt controla: comportamento (tom, formato, restrições), estratégia de raciocínio (chain-of-thought, decomposição de problema) e calibração de exemplos (few-shot). O que o prompt não controla: fatos além do treino, dados em tempo real e execução de código ou chamadas externas.

Entender esse limite é fundamental para não projetar sistemas frágeis. Quando um requisito não cabe no prompt, a resposta de arquitetura é RAG ou tools — não um prompt maior.