Prompt é código: versão, revisão e teste
Instrução é orientação probabilística. Código é garantia. Confundir os dois é o erro mais caro em aplicação de LLM.
Existe uma pergunta que separa a equipe que brinca com IA da equipe que a coloca em produção: onde vive o prompt? Se a resposta for "num campo de texto que alguém edita pelo painel", a feature de IA não tem engenharia, tem improviso com boa intenção.
Prompt é a configuração que mais muda o comportamento
Num sistema tradicional, a configuração ajusta parâmetros ao redor de uma lógica fixa. Numa aplicação de LLM, o prompt é a lógica.
Trocar uma frase de instrução pode alterar formato de saída, tom, taxa de recusa e acionamento de ferramenta de uma vez. É a coisa mais poderosa e mais frágil do sistema, e mesmo assim costuma ser a única que ninguém versiona.
O princípio de configuração do The Twelve-Factor App resolve metade do problema: separe configuração de código e nunca a coloque em lugar que não seja auditável. A outra metade é aceitar que o prompt não é só configuração, é comportamento, e por isso precisa também de teste.
Por que a ordem e a estrutura importam
A arquitetura Transformer, apresentada no artigo que introduziu a atenção como mecanismo central, processa a sequência inteira com pesos de atenção entre posições. Não existe uma separação rígida entre instrução e dado: tudo é contexto.
Isso explica três comportamentos que parecem misteriosos quando você só olha a saída:
- Instrução colocada depois de um bloco longo de dados costuma ter mais efeito do que a mesma instrução colocada antes.
- Delimitadores explícitos entre instrução e conteúdo reduzem a chance de o modelo tratar o conteúdo como comando.
- Exemplo concreto vale mais que adjetivo. "Responda de forma concisa" é vago; dois exemplos de resposta boa definem o alvo.
Não é superstição, é consequência de como o contexto é consumido.
Técnicas que sobrevivem ao hype
A literatura de prompt cresceu depressa e boa parte envelheceu mal. Três coisas continuam valendo.
Estrutura explícita. Papel, tarefa, restrições, formato de saída e critério de sucesso, separados. A documentação de engenharia de prompt da Anthropic organiza o trabalho nessa direção, e o ganho vem menos da mágica das palavras e mais da clareza que a estrutura obriga.
Raciocínio passo a passo. O artigo sobre cadeia de pensamento mostrou que pedir ao modelo para expor as etapas melhora tarefas de múltiplos passos. O detalhe prático que se esquece: o raciocínio custa tokens e latência, então vale ligar onde a tarefa é composta e desligar onde é classificação simples.
Exemplos no contexto. Poucos exemplos bem escolhidos, cobrindo inclusive o caso difícil e o caso que deve ser recusado, movem mais a saída do que qualquer reescrita de instrução.
Prompt como código, na prática
Tratar prompt com disciplina de código significa quatro coisas concretas:
- Vive no repositório, em arquivo próprio, com histórico.
- Passa por revisão, e a descrição do PR diz o que mudou e por quê.
- Tem teste, ou seja, um conjunto de casos com saída esperada que roda no CI.
- Tem versão registrada em execução, para que o log de produção diga qual prompt gerou aquela resposta.
O item 4 é o que salva a investigação. Sem ele, você olha uma resposta ruim de ontem sem saber qual texto a produziu.
O anti-padrão do prompt que só cresce
A evolução típica de um prompt em produção é por acréscimo. Cada problema encontrado vira mais uma linha de instrução, e em seis meses há um texto de duas mil palavras que ninguém ousa tocar.
O problema não é só o custo por chamada. É que instruções acumuladas entram em conflito, e o modelo passa a atender a mais recente, a mais enfática ou a mais próxima do fim do contexto, de forma difícil de prever.
O antídoto é o mesmo da refatoração de código: quando a correção número quinze chega, pare de somar linha e pergunte se aquilo devia ser prompt. Muitas vezes deve ser validação em código, roteamento para outro fluxo ou um segundo passo mais barato e determinístico.
Nem tudo deve ser prompt
Vale repetir isolado, porque é o erro mais caro: usar instrução em linguagem natural para garantir algo que o código garante melhor.
Formato de saída se garante com esquema e validação, não com pedido educado. Limite de valor se garante com verificação após a resposta. Acesso a dado se garante com permissão, nunca com a frase "não mostre dados de outros clientes".
Instrução é orientação probabilística. Código é garantia.
O que isso significa para o seu time
Se hoje o prompt da sua aplicação não está no Git, essa é a tarefa da semana. É barata e muda tudo o que vem depois.
Em seguida, monte um conjunto pequeno de casos, dez a vinte, com saída esperada, e faça ele rodar no CI a cada mudança de prompt. Isso transforma "achamos que melhorou" em evidência.
Por último, revise o prompt mais antigo do sistema procurando instruções em conflito. Quase sempre há duas, e quase sempre a resposta estranha que ninguém explicou vinha dali.
Referências
As fontes usadas neste texto, para você conferir e ir mais fundo.
- 1Prompt engineering overviewAnthropic
- 2Chain-of-Thought Prompting Elicits Reasoning in Large Language ModelsWei et al. (arXiv:2201.11903), 2022
- 3Attention Is All You NeedVaswani et al. (arXiv:1706.03762), 2017
- 4The Twelve-Factor App: ConfigAdam Wiggins
Leia também
RAG para base de conhecimento: o que sobrevive à produção
Encher a janela de contexto pode piorar a resposta mesmo com o trecho certo lá dentro. A posição da informação importa mais do que a quantidade.
Ler o artigoEvals no CI: testando o que não é determinístico
Asserção de igualdade não funciona quando a resposta certa pode ser escrita de dez formas. Troque a pergunta do teste e a suíte volta a servir.
Ler o artigoAgentes de IA na entrega: onde pagam e onde não
Se você consegue desenhar o fluxograma antes, é workflow. Agente só quando o caminho depende do que for descoberto no meio.
Ler o artigo