Pular para o conteúdo principal
Voltar para o blog
IA aplicada
4 min de leitura

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:

  1. Vive no repositório, em arquivo próprio, com histórico.
  2. Passa por revisão, e a descrição do PR diz o que mudou e por quê.
  3. Tem teste, ou seja, um conjunto de casos com saída esperada que roda no CI.
  4. 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.

  1. 1Prompt engineering overviewAnthropic
  2. 2Chain-of-Thought Prompting Elicits Reasoning in Large Language ModelsWei et al. (arXiv:2201.11903), 2022
  3. 3Attention Is All You NeedVaswani et al. (arXiv:1706.03762), 2017
  4. 4The Twelve-Factor App: ConfigAdam Wiggins