Prompt engineering para sistemas em produção

É estranho que a série sobre engenharia de IA tenha coberto RAG, fine-tuning e agentes, mas nunca tenha parado para falar de prompt engineering isoladamente. A razão é simples: escrever um prompt bom para um caso de uso parece trivial demais para merecer um post — até você precisar manter centenas deles, versionados, testados e em produção, e perceber que é uma disciplina de engenharia como qualquer outra.

O prompt não é texto, é uma interface

A diferença fundamental entre escrever um prompt para uma conversa pontual e escrever um prompt para produção é que o segundo é uma interface entre seu sistema e um comportamento que você precisa garantir de forma consistente, para milhares de entradas diferentes, incluindo entradas maliciosas. Trate prompt como trataria uma função pública da sua API: com contrato claro de entrada e saída, com testes, com versionamento.

Versionamento de prompt não é opcional

Se o seu prompt vive direto no código, sem histórico de versões nem forma de comparar "antes" e "depois", você vai eventualmente fazer uma mudança que piora o comportamento sem perceber — e não vai ter como reverter com confiança. O mínimo viável é: cada prompt em produção tem um identificador de versão, cada mudança é revisada como qualquer outra mudança de código, e existe um jeito rápido de rodar o golden dataset (veja o post sobre avaliação de LLMs) contra a versão antiga e a nova antes de promover.

Templates estruturados batem prompts soltos

Prompt de produção não deveria ser uma string concatenada na mão. Usar um sistema de templates — com variáveis explícitas, validação de tipo e escaping automático de conteúdo do usuário — evita uma classe inteira de bugs: instrução do sistema sendo sobrescrita acidentalmente por texto do usuário, formatação quebrada quando um campo vem vazio, injeção de instrução via input malicioso.

Defesa contra prompt injection é parte do design, não um patch depois

Isso conecta diretamente com o post sobre observabilidade e segurança da série anterior: qualquer sistema que insere texto do usuário dentro do prompt precisa assumir que parte desse texto vai tentar manipular as instruções do sistema. As defesas práticas incluem: delimitar claramente onde termina a instrução e começa o conteúdo do usuário, nunca dar ao modelo mais autoridade do que a ação realmente precisa (por exemplo, um agente de busca não deveria ter a mesma permissão de um agente que executa transações) e validar a saída do modelo antes de agir sobre ela, especialmente quando ela aciona uma ferramenta externa.

Testando prompts como se testa código

A prática mais eficaz que eu vejo funcionar é tratar cada mudança de prompt como um pull request: escrever o motivo da mudança, rodar contra o conjunto de casos de teste, revisar o diff — inclusive prompts que parecem pequenos podem ter efeitos grandes e não óbvios em como o modelo interpreta instruções vizinhas. Times que pulam essa etapa acabam com prompts que ninguém entende completamente depois de seis meses de ajustes ad hoc.

Prompt engineering em produção não é sobre achar a frase mágica. É sobre construir um processo repetível que sobrevive à saída da pessoa que escreveu o prompt original — porque ela vai sair, e alguém vai precisar mexer nesse sistema sem quebrar tudo.