Prompt Engineering, medido: o que muda a saída

Antes das medições, um fato que explica discretamente metade do que vem a seguir.

O modelo não tem memória. Entre duas chamadas, ele não retém nada — nem sua última pergunta, nem sua própria última resposta, nem o arquivo que você anexou, nem o fato de que você já perguntou duas vezes. Toda chamada começa em uma máquina vazia, e a única coisa que essa máquina sabe é a sequência de tokens que você acabou de entregar a ela.

O que parece memória em uma interface de chat é seu cliente reenviando a conversa inteira, cada turno, desde o início. O modelo lê tudo de novo do zero, toda vez. O Capítulo 13 mediu o custo dessa releitura em um forward pass; o Capítulo 16 transforma isso em uma linha na fatura. O que importa aqui é a consequência para o design: o prompt não é uma mensagem para um sistema que tem estado. Ele é o estado.

Isso aposenta uma família de confusões. “O modelo esqueceu o que eu disse” geralmente significa que aquilo nunca foi enviado. “Ele ignorou minha instrução anterior” geralmente significa que a instrução caiu fora da janela quando o histórico foi truncado. “Ele se comportou diferente em produção” geralmente significa que a produção monta um prompt diferente daquele que você testou. Nenhum desses é um problema do modelo, e nenhum se resolve reescrevendo qualquer coisa.

A afirmação “este prompt é melhor” é uma afirmação sobre uma distribuição, e você não consegue ver uma distribuição olhando para uma saída. O que você precisa é chato: casos com respostas conhecidas, N variantes e um intervalo.

O harness tem cinquenta linhas de TypeScript com o mesmo formato do cliente do Capítulo 14 — uma requisição, um prazo, alguma concorrência, uma contagem. Ele reaparece no Capítulo 19 para avaliar um retriever e no Capítulo 29 como golden set.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

O número que volta não é o resultado. Isto é:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

O Capítulo 4 apresentou o argumento e este capítulo o desconta. Dezessete acertos em vinte são 85 %, e seu intervalo de 95 % vai de 64 % a 95 %. Uma variante que pontua 13 em 20 — 65 %, o que parece claramente pior — tem um intervalo de 43 % a 82 %. Esses dois intervalos se sobrepõem por quase toda a sua extensão. Vinte casos não conseguem diferenciar um bom prompt de um mediano, e a maior parte dos conselhos publicados sobre prompt foi validada com menos.

Sessenta casos, que é o que este capítulo usa, ainda não é muito. É o bastante para ver efeitos grandes e honesto o bastante para admitir quando não consegue ver os pequenos — e ele vai admitir isso várias vezes abaixo.

Três blocos — as regras R, o ticket T, a instrução I — concatenados em uma única mensagem do usuário. Todas as seis permutações, conteúdo idêntico byte a byte, sessenta casos cada.

Do melhor ao pior são 28,3 pontos, e os intervalos não se sobrepõem, então esta não é uma história sobre ruído. Como cada braço é pontuado nos mesmos sessenta itens, a pergunta mais precisa é a pareada: nos casos em que dois braços discordam, quão desequilibrada é a divisão? Passar da pior ordem para a melhor virou 21 casos para certo e 4 para errado — probabilidade pareada exata de 0,0009.³

Leia a tabela pelo seu formato, não pelo vencedor. As duas melhores linhas terminam com o ticket; as duas piores enterram a instrução no meio ou a deixam atrás dos dados. Esse é o mesmo fenômeno que Liu et al. chamaram de Lost in the Middle: material nas bordas de um prompt é usado com mais confiabilidade do que material no centro.⁴ O Capítulo 16 precifica a janela e o Capítulo 24 mede o efeito corretamente em comprimento, onde o meio colapsa como descrito e a recuperação no fim extremo não reaparece. Aqui, a regra prática surge sozinha: tarefa no topo, dados no final, nada importante no meio.

Agora mova as mesmas palavras entre turnos. O Capítulo 11 estabeleceu que o chat template não é uma decoração em volta do modelo, mas parte dele — <|im_start|>system e <|im_start|>user são tokens reais que o modelo viu milhões de vezes durante o fine-tuning, exatamente nessas posições. Então deve importar de que lado desses marcadores sua instrução cai, e importa:

Mover as regras e a instrução através da fronteira do template comprou 21,7 pontos — 19 casos ganhos, 6 perdidos, probabilidade pareada 0,0146 — sem mudar um caractere delas. Esta é a resposta concreta para system prompt versus user prompt: eles não são duas maneiras de dizer a mesma coisa. São duas posições de token diferentes em uma estrutura na qual o modelo foi treinado, e a posição de sistema é onde pertencem as instruções que se aplicam à conversa inteira.

Observe também a terceira linha. Repetir a instrução depois do ticket — um truque amplamente recomendado — pontuou abaixo de declará-la uma vez. Neste modelo, nesta tarefa, dizer duas vezes foi pior do que dizer uma.

Mesmo prompt, melhor posicionamento, sessenta casos. A única coisa que muda é o que envolve o texto do ticket.

Uma dispersão de dezoito pontos causada por pontuação. Mas olhe os dois intervalos extremos: [73,9, 91,9] e [54,1, 77,3]. Eles se sobrepõem. Pela leitura grosseira — compare as barras de erro, e se elas se tocarem, não diga nada — esta tabela não prova nada.

A leitura grosseira está errada aqui, e entender por quê vale mais do que a tabela. Toda variante foi pontuada nos mesmos sessenta tickets, então as duas medições não são amostras independentes; elas são pareadas. A maior parte da largura de cada intervalo vem de uma fonte de incerteza que os dois braços compartilham — se estes sessenta tickets são representativos — e essa fonte se cancela quando você os compara entre si. Faça a pergunta pareada em vez disso e a resposta fica nítida: passar das aspas duplas para a tag XML virou 12 casos para certo e 1 para errado, probabilidade pareada 0,0034. Essa é uma diferença real.

E então o mesmo teste esvazia a manchete. A tag XML venceu o rótulo simples Ticket: por 8,3 pontos, que é o número que um post de blog colocaria no título. Pareado: 6 ganhos, 1 perdido, probabilidade 0,1250. Não estabelecido. Sete casos é o que sustenta aquela melhoria famosa.

Então há duas perguntas com dois instrumentos diferentes, e confundi-las é como conselhos sobre prompt dão errado nas duas direções ao mesmo tempo:

A constatação geral — de que modelos são forte e imprevisivelmente sensíveis a escolhas de formatação sem conteúdo semântico — não é nova. Sclar et al. variaram nada além de separadores, espaçamento e caixa em dezenas de tarefas e encontraram dispersões de acurácia amplas o bastante para inverter rankings publicados de modelos.⁵ A consequência prática não é “use tags XML”. É que formatação é um hyperparameter, não custa nada varrer, e qualquer comparação de dois modelos que fixa um formato está comparando formatos tanto quanto modelos.

In-context learning — mostrar ao modelo exemplos resolvidos no prompt e fazê-lo generalizar a partir deles sem nenhuma atualização de weights — é a capacidade que tornou o GPT-3 famoso.⁶ A pergunta prática nunca é se funciona. É por quantos exemplos vale a pena pagar.

Os exemplos entram como turnos anteriores reais, alternando usuário e assistant, porque essa é a estrutura na qual o template foi treinado. Cada k foi executado com cinco sorteios aleatórios diferentes de um pool separado de dezesseis tickets rotulados:

Dois exemplos compraram sete pontos. Os seis exemplos seguintes não compraram nada mensurável — 83,7, depois 81,7, depois 83,7, uma sequência que vagueia dentro do próprio ruído. Dezesseis compraram mais cinco e meio. A curva não é uma subida suave; é um degrau, um platô e um degrau.

A coluna que mais importa é a última. Em k = 8, quais oito exemplos você por acaso escolheu moveram a acurácia em 10 pontos — mais do que todo o ganho de passar de dois exemplos para oito. E a linha de baixo é a versão mais nítida disso: em k = 16 o pool se esgota, então todas as cinco execuções contêm exatamente os mesmos dezesseis exemplos, diferindo apenas na ordem em que aparecem. Só a ordem moveu a acurácia em 8,3 pontos.

Esse é o resultado que Lu et al. relataram e ele sobrevive em todo lugar onde foi procurado: a ordenação dos exemplos é um hyperparameter genuíno, com efeitos comparáveis à quantidade de exemplos.⁷ Então o conselho honesto sobre few-shot prompting não é um número. É:

Agora o folclore. Cada uma destas é uma única frase acrescentada ao início de um system prompt que, no resto, é idêntico, nos mesmos sessenta casos.

Quatro das cinco não fizeram nada. Não “fizeram um pouco”; nada que sessenta casos pareados consigam ver. A persona especialista e o suborno pontuaram abaixo do baseline intocado, e mesmo essas quedas falham no teste pareado — são ruído apontando ladeira abaixo.

A terceira linha é aquela para observar com calma. “Isso é muito importante para minha carreira” produziu exatamente a mesma acurácia, 46 de 60 — e dez das sessenta respostas mudaram, cinco em cada direção. A estatística resumida foi idêntica e o comportamento não. Se sua avaliação é um único número sobre um conjunto pequeno, uma mudança que reescreve um sexto das suas saídas pode parecer uma mudança que não fez nada, e você vai lançá-la acreditando que foi grátis.

E então a ameaça, que é a única frase que mexeu no ponteiro e mexeu 35 pontos para baixo, virando 24 casos de certos para errados. Isso não é artefato de arredondamento; é um comportamento de modelo diferente. A lição não é “nunca ameace um modelo”. É que enquadramento emocional não é inerte. Ele desloca a distribuição, às vezes com força, em uma direção que ninguém consegue prever lendo a frase — exatamente por isso precisa ser medido, não raciocinado.

Uma ressalva que este capítulo deve a você: essas cinco frases foram testadas em um modelo pequeno e uma tarefa. Algumas têm suporte publicado em outros lugares — “respire fundo” saiu de um artigo que procurou instruções de alta pontuação em vez de inventá-las, o que é uma afirmação diferente e melhor do que a que circulou depois.⁸ O que generaliza não são as frases. É que a lista que sobreviveu em posts de blog e a lista que sobrevive à medição são duas listas diferentes, e a única maneira de saber qual delas você tem em mãos é rodar o bench.

Uma regra que todo mundo repete — diga o que você quer, não o que você não quer — com a ausência habitual de um número. Aqui está o número. O mesmo requisito de formato, escrito de três maneiras, com o modelo gerando livremente para que a conformidade possa ser observada:

Três proibições foram piores do que uma instrução, e fizeram o modelo escrever cinco vezes mais texto — o oposto exato das três ao mesmo tempo. Adicionar de volta a frase positiva o resgatou para 68 %.

O mecanismo não é misterioso quando você lembra do Capítulo 8. O modelo escolhe um próximo token a partir de uma distribuição condicionada por tudo o que veio antes, e uma proibição coloca a coisa proibida dentro desse condicionamento. Não há operador para negação; há um contexto em que uma palavra agora aparece.

O que é diretamente mensurável. Pegue o prompt baseline e adicione uma linha: Do not use the shipping queue for software problems. Depois olhe apenas para os quarenta e cinco tickets que não são tickets de envio:

Nomear uma fila para descartá-la fez o modelo escolhê-la três vezes mais, quase triplicou a massa de probabilidade que ele atribuiu a ela e custou 25 pontos de acurácia geral — 16 casos perdidos contra 1 ganho, probabilidade pareada 0,0003.

Não pense em um elefante, medido. A reescrita é sempre a mesma: substitua a proibição pela regra positiva que a torna desnecessária. Não “não use envio para problemas de software”, mas “use envio apenas quando houver um pacote físico envolvido”.

O Capítulo 12 construiu chain of thought corretamente — primeiro como técnica de prompting,⁹¹⁰ depois como algo treinado com recompensas verificáveis — e terminou com um aviso que deixou para este capítulo: dizer a um modelo para pensar passo a passo deixa de ajudar quando o modelo raciocina por conta própria, e pode prejudicar. Aqui está esse aviso com uma tabela embaixo, em uma tarefa na qual é fácil presumir que pensar mais deve ser melhor.

Os dois braços são lidos com o mesmo instrumento, na mesma posição. A única diferença é se uma chain of thought que o próprio modelo escreveu fica primeiro no contexto.

A acurácia caiu e o custo subiu, e a própria regra deste capítulo se aplica ao próprio resultado deste capítulo: a queda é 7 casos ganhos contra 10 perdidos, probabilidade pareada 0,629, o que não está estabelecido. O que está estabelecido é que ela produziu noventa e oito output tokens extras por chamada e não comprou nada mensurável com eles. A incerteza está inteiramente do lado do benefício. A conta é certa.

Uma cadeia que falha é mais instrutiva do que uma que funciona. Solicitado a raciocinar sobre “Sua integração com o Slack parou de postar mensagens depois de terça-feira”, o modelo escreveu:

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

Esse é um conselho competente de troubleshooting, e não é a tarefa. Quando solicitado a pensar, o modelo derivou para o gênero que “pense passo a passo sobre este ticket de suporte” mais se parece nos dados de treinamento — e então respondeu a uma pergunta de classificação com quinhentos caracteres de raciocínio não relacionado no próprio contexto. Chain of thought ajuda em problemas com estado intermediário que vale computar: aritmética, buscas multi-hop, satisfação de restrições. Roteamento de uma frase para um de quatro baldes não tem estado intermediário. Não há nada para a cadeia segurar, então tudo o que ela faz é adicionar texto plausível ao qual a decisão final precisa sobreviver.

Duas consequências práticas. Primeiro, para um modelo treinado para raciocinar — os modelos RLVR do Capítulo 12 — a instrução é pior do que redundante: ela pode substituir a cadeia longa que o modelo teria produzido por uma curta, com cara de prompt. E amostrar várias cadeias e votar, que é o que self-consistency faz,¹¹ não consegue resgatar uma tarefa sem nada sobre o que discordar: multiplica o custo pelo número de amostras para desempatar empates que não existem. O Capítulo 12 mediu essa troca onde ela se aplica. Segundo, observe o custo do próprio andaime de comparação. Forçar a resposta para uma linha Final queue: derrubou o braço sem raciocínio de 76,7 % para 61,7 %. Quinze pontos, pagos para tornar os dois braços comparáveis. Estrutura que existe para sua conveniência também não é grátis.

Uma última medição, porque é a pergunta que todo mundo faz depois do primeiro resultado surpreendente. Sessenta prompts, greedy decoding, executados repetidamente:

• A mesma chamada repetida com tudo fixo retornou probabilidades idênticas bit a bit. Determinística.
• A mesma chamada em batch com vizinhos diferentes — batch sizes 1, 4, 12, 30 e 60 — retornou probabilidades que diferiam em até 0,0128. O rótulo escolhido nunca mudou, em 0 de 60 casos.

O rótulo sobreviveu porque tinha espaço para isso: nos sessenta casos, a menor lacuna entre as duas filas no topo foi 0,0459, três vezes e meia o drift. A estabilidade não era uma propriedade do algoritmo. Era uma margem, e margens acabam. O Capítulo 17 é onde está a razão aritmética e onde os controles de sampling que alargam e estreitam essas lacunas são desmontados. A razão de plantar isso aqui é que ela limita o que qualquer medição de prompt pode significar: o bench mede um sistema reproduzível apenas até uma tolerância, e uma diferença de dois pontos entre variantes fica dentro dessa tolerância em um dia ruim.

Tudo acima é um humano escolhendo uma variante e uma máquina a avaliando. O próximo passo óbvio é deixar a máquina escolher as variantes também.

APE faz exatamente isso: um modelo propõe instruções candidatas, elas são pontuadas em exemplos held-out, e as melhores sobrevivem.⁸ As instruções que ele encontra frequentemente são coisas que nenhum humano escreveria, e esse é o ponto — a busca é sobre o que pontua, não sobre o que soa profissional.

DSPy vai além e é a ideia mais útil para um produto.¹² Você declara o que cada etapa de um pipeline recebe e retorna, e o framework compila isso em prompts, selecionando demonstrações e otimizando instruções contra sua métrica. Mude o modelo e você recompila em vez de reescrever. O prompt deixa de ser código-fonte que alguém ajusta manualmente e se torna um artefato gerado contra uma métrica, que é o que deveria ter sido desde o início.

Nenhum dos dois remove a necessidade do bench. Ambos fazem dele a única coisa de que você precisa, porque um otimizador sem métrica não otimiza nada.

Resta a disciplina. Prompts pertencem ao controle de versão, em arquivos, ao lado do código que os envia — não em uma linha de banco de dados que alguém editou numa terça-feira. Eles precisam de um identificador de versão armazenado junto de cada saída que produziram, ou no dia em que algo regredir você não conseguirá descobrir o que mudou. Eles precisam do bench em integração contínua, porque um prompt é a única parte do seu sistema que um fornecedor pode invalidar silenciosamente ao implantar um novo modelo. E eles precisam de casos: não cem casos inteligentes, apenas os vinte chatos que quebraram no trimestre passado, guardados para sempre. O bench é o entregável. O prompt é um subproduto dele.

Tudo neste capítulo foi medido em acurácia. Cada uma dessas variantes também tem um preço.

O system prompt que comprou 21,7 pontos é enviado em toda chamada, para sempre. Os dois exemplos que compraram sete pontos são enviados em toda chamada, para sempre. Os dezesseis que compraram doze são enviados em toda chamada, para sempre, e têm aproximadamente dez vezes o comprimento da pergunta que o usuário de fato fez. A chain of thought que não comprou nada produziu noventa e oito tokens extras por requisição, e output tokens são do tipo caro.

Nada disso é visível em uma tabela de acurácias, e tudo isso é visível em uma fatura.

O Capítulo 16 é sobre a unidade em que essas decisões são de fato denominadas. O token como unidade de cobrança, a context window como orçamento em vez de memória, por que uma conversa de quarenta turnos custa muito mais do que quarenta vezes o primeiro turno, pelo que o prompt caching paga e não paga, e por que a ordem do seu prompt decide se o cache acerta — o que acaba sendo uma segunda razão, inteiramente econômica, para colocar o material estável primeiro e o material variável por último.

O bench e cada tabela foram produzidos com Qwen/Qwen2.5-0.5B-Instruct sob greedy decoding, então se reproduzem exatamente. A documentação da Hugging Face sobre chat templates é a referência para o que os marcadores de template do Capítulo 11 realmente expandem, e para o fato de que um modelo enviado com o template errado é uma falha real e recorrente. Para os efeitos de posição e formato em escala de produção em vez de escala de laboratório, as citações acima são as fontes primárias; os guias de prompting dos fornecedores são úteis por seus exemplos e devem ser lidos sabendo que nenhum deles publica um intervalo.