Prompt engineering, medido: o que muda o output

Antes das medições, um facto que explica discretamente metade do que se segue.

O modelo não tem memória. Entre duas chamadas, não retém nada — nem a sua última pergunta, nem a última resposta dele, nem o ficheiro que anexou, nem o facto de já lhe ter perguntado duas vezes. Cada chamada começa numa máquina vazia, e a única coisa que essa máquina sabe é a sequência de tokens que acabou de lhe entregar.

O que parece memória numa interface de chat é o seu cliente a reenviar a conversa inteira, todas as intervenções, desde o início. O modelo lê tudo de novo do zero, sempre. O Capítulo 13 mediu quanto custa essa releitura num forward pass; o Capítulo 16 transforma isso numa linha de uma fatura. O que importa aqui é a consequência para o design: o prompt não é uma mensagem para um sistema que tem estado. É o estado.

Isto arruma uma família de confusões. «O modelo esqueceu-se do que lhe disse» normalmente significa que isso nunca foi enviado. «Ignorou a minha instrução anterior» normalmente significa que a instrução saiu da window quando o histórico foi truncado. «Comportou-se de forma diferente em produção» normalmente significa que a produção monta um prompt diferente daquele que testou. Nada disto é um problema do modelo, e nada disto se resolve reescrevendo o que quer que seja.

A afirmação «este prompt é melhor» é uma afirmação sobre uma distribuição, e não consegue ver uma distribuição olhando para um output. O que precisa é aborrecido: casos com respostas conhecidas, N variantes e um intervalo.

O harness tem cinquenta linhas de TypeScript com a mesma forma do cliente do Capítulo 14 — um pedido, um prazo, alguma concorrência, uma contagem. 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 concretiza-o. Dezassete certas em vinte são 85 %, e o 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 sobrepõem-se em quase toda a sua extensão. Vinte casos não conseguem distinguir um bom prompt de um medíocre, e a maioria dos conselhos publicados sobre prompt foi validada com menos.

Sessenta casos, que é o que este capítulo usa, continua a não ser muito. É suficiente para ver efeitos grandes e honesto o bastante para admitir quando não consegue ver efeitos pequenos — e vai admiti-lo várias vezes abaixo.

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

Do melhor ao pior são 28,3 pontos, e os intervalos não se sobrepõem, por isso isto não é uma história sobre ruído. Como cada braço é pontuado nos mesmos sessenta itens, a pergunta mais precisa é a emparelhada: 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 emparelhada exata de 0,0009.³

Leia a tabela pela sua forma, não pelo vencedor. As duas melhores linhas terminam com o ticket; as duas piores enterram a instrução no meio ou deixam-na depois dos dados. É o mesmo fenómeno a que Liu et al. chamaram Lost in the Middle: material nas extremidades de um prompt é usado de forma mais fiável do que material no centro.⁴ O Capítulo 16 atribui um preço à window e o Capítulo 24 mede corretamente o efeito em comprimento, onde o meio colapsa como descrito e a recuperação no fim absoluto não reaparece. Aqui a regra prática emerge sozinha: tarefa no topo, dados no fundo, nada importante no meio.

Agora mova as mesmas palavras entre intervenções. O Capítulo 11 estabeleceu que o chat template não é decoração à 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. Portanto, deve importar de que lado desses marcadores fica a sua instrução, 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 emparelhada de 0,0146 — sem alterar um carácter delas. Esta é a resposta concreta a system prompt versus user prompt: não são duas formas de dizer a mesma coisa. São duas posições de token diferentes numa estrutura em que o modelo foi treinado, e a posição de system é onde pertencem as instruções que se aplicam à conversa inteira.

Repare também na terceira linha. Repetir a instrução depois do ticket — um truque muito recomendado — pontuou abaixo de a declarar uma vez. Neste modelo, nesta tarefa, dizê-la duas vezes foi pior do que dizê-la uma vez.

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

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

A leitura grosseira está errada aqui, e perceber porquê vale mais do que a tabela. Cada variante foi pontuada nos mesmos sessenta tickets, por isso as duas medições não são amostras independentes; são emparelhadas. A maior parte da largura de cada intervalo vem de uma fonte de incerteza que ambos os braços partilham — se estes sessenta tickets são representativos — e essa fonte cancela quando os compara entre si. Faça antes a pergunta emparelhada e a resposta é nítida: passar de aspas duplas para a tag XML virou 12 casos para certo e 1 para errado, probabilidade emparelhada 0,0034. É uma diferença real.

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

Portanto, há duas perguntas com dois instrumentos diferentes, e confundi-las é a forma como os conselhos sobre prompt falham nas duas direções ao mesmo tempo:

A conclusão geral — que os 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 apenas separadores, espaçamento e capitalização em dezenas de tarefas e encontraram amplitudes de accuracy suficientemente largas para inverter rankings publicados de modelos.⁵ A consequência prática não é «use tags XML». É que a formatação é um hyperparameter, não custa nada varrê-la, e qualquer comparação de dois modelos que fixa um formato está a comparar formatos tanto quanto modelos.

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

Os exemplos entram como intervenções anteriores reais, alternando user e assistant, porque essa é a estrutura em que o template foi treinado. Cada k foi executado com cinco escolhas aleatórias diferentes de um conjunto separado de dezasseis tickets etiquetados:

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 seu próprio ruído. Dezasseis compraram mais cinco e meio. A curva não é uma subida suave; é um degrau, um patamar e um degrau.

A coluna que mais importa é a última. Em k = 8, os oito exemplos que por acaso escolheu moveram a accuracy 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: em k = 16 o conjunto esgota-se, por isso as cinco execuções contêm exatamente os mesmos dezasseis exemplos, diferindo apenas na ordem em que aparecem. Só a ordem moveu a accuracy 8,3 pontos.

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

Agora o folclore. Cada uma destas é uma única frase anteposta a um system prompt que, de resto, é idêntico, nos mesmos sessenta casos.

Quatro das cinco não fizeram nada. Não «fizeram pouco»; nada que sessenta casos emparelhados consigam ver. A persona de especialista e o suborno pontuaram ambos abaixo da baseline intocada, e mesmo essas quedas falham o teste emparelhado — são ruído a apontar para baixo.

A terceira linha é aquela em que vale a pena ficar. «Isto é muito importante para a minha carreira» produziu exatamente a mesma accuracy, 46 em 60 — e dez das sessenta respostas mudaram, cinco em cada direção. A estatística de resumo foi idêntica e o comportamento não. Se a sua avaliação for um único número sobre um conjunto pequeno, uma alteração que reescreve um sexto dos seus outputs pode parecer uma alteração que não fez nada, e vai lançá-la acreditando que foi gratuita.

E depois a ameaça, que é a única frase que mexeu o ponteiro e o mexeu 35 pontos para baixo, virando 24 casos de certos para errados. Não é um artefacto de arredondamento; é um comportamento diferente do modelo. A lição não é «nunca ameace um modelo». É que o enquadramento emocional não é inerte. Desloca a distribuição, por vezes com força, numa direção que ninguém consegue prever lendo a frase — que é precisamente por isso que tem de ser medido em vez de raciocinado.

Uma ressalva que este capítulo lhe deve: estas cinco frases foram testadas num modelo pequeno e numa tarefa. Algumas têm suporte publicado noutros contextos — «respire fundo» veio de um paper que procurou instruções com alta pontuação em vez de as inventar, 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 forma de saber qual delas tem nas mãos é executar o bench.

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

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

O mecanismo não é misterioso quando se lembra do Capítulo 8. O modelo escolhe um next 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 aparece agora.

O que é diretamente mensurável. Pegue no prompt de 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 expedição:

Nomear uma fila para a excluir fez o modelo escolhê-la três vezes mais frequentemente, quase triplicou a massa de probabilidade que lhe atribuía, e custou 25 pontos de accuracy global — 16 casos perdidos contra 1 ganho, probabilidade emparelhada 0,0003.

Não pense num elefante, medido. A reescrita é sempre a mesma: substitua a proibição pela regra positiva que a torna desnecessária. Não «não use expedição para problemas de software», mas «use expedição apenas quando estiver envolvida uma encomenda física».

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 adiou para este capítulo: dizer a um modelo para pensar passo a passo deixa de ajudar quando o modelo raciocina por si próprio, e pode prejudicar. Aqui está esse aviso com uma tabela por baixo, numa tarefa em que é fácil presumir que pensar mais tem de ser melhor.

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

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

Uma chain que falha é mais instrutiva do que uma que funciona. Quando lhe foi pedido que raciocinasse sobre «A sua integração Slack deixou de publicar 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.

É aconselhamento competente de troubleshooting e não é a tarefa. Quando lhe foi pedido que pensasse, o modelo desviou-se para o género que «pensar passo a passo sobre este ticket de suporte» mais se parece nos seus dados de treino — e depois respondeu a uma pergunta de classificação com quinhentos caracteres de raciocínio não relacionado no seu próprio contexto. Chain of thought ajuda em problemas com estado intermédio que vale a pena computar: aritmética, pesquisas multi-hop, satisfação de restrições. Encaminhar uma frase para uma de quatro caixas não tem estado intermédio. Não há nada para a chain segurar, por isso tudo o que faz é acrescentar texto plausível ao qual a decisão final tem depois de 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: pode substituir a chain longa que o modelo teria produzido por uma curta, com forma de prompt. E amostrar várias chains 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, note o custo do próprio andaime de comparação. Forçar a resposta para uma linha Final queue: fez o braço sem raciocínio cair de 76,7 % para 61,7 %. Quinze pontos, pagos para tornar os dois braços comparáveis. A estrutura que existe para sua conveniência também não é gratuita.

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

• A mesma chamada repetida com tudo fixo devolveu probabilidades bit a bit idênticas. Determinística.
• A mesma chamada em batch com vizinhos diferentes — tamanhos de batch 1, 4, 12, 30 e 60 — devolveu probabilidades que diferiam até 0,0128. A etiqueta escolhida nunca mudou, em 0 de 60 casos.

A etiqueta sobreviveu porque tinha margem: nos sessenta casos, a menor diferença entre as duas filas do topo foi 0,0459, três vezes e meia o drift. A estabilidade não era uma propriedade do algoritmo. Era uma margem, e as margens acabam. O Capítulo 17 é onde está a razão aritmética e onde os botões de sampling que alargam e estreitam essas diferenças são desmontados. A razão para a plantar aqui é que 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 num dia mau.

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

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

DSPy vai mais longe e é a ideia mais útil para um produto.¹² Declara o que cada etapa de uma pipeline recebe e devolve, e a framework compila isso em prompts, selecionando demonstrações e otimizando instruções contra a sua métrica. Muda o modelo e recompila em vez de reescrever. O prompt deixa de ser código-fonte que alguém ajusta à mão e torna-se um artefacto gerado contra uma métrica, que é o que devia ter sido desde o início.

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

Resta a disciplina. Prompts pertencem ao controlo de versões, em ficheiros, junto do código que os envia — não numa linha de base de dados que alguém editou numa terça-feira. Precisam de um identificador de versão guardado ao lado de todos os outputs que produziram, ou no dia em que algo regredir não conseguirá descobrir o que mudou. Precisam do bench em integração contínua, porque um prompt é a única parte do seu sistema que um fornecedor pode invalidar silenciosamente ao lançar um novo modelo. E precisam de casos: não cem engenhosos, apenas os vinte aborrecidos que falharam no trimestre passado, guardados para sempre. O bench é o entregável. O prompt é um subproduto dele.

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

O system prompt que comprou 21,7 pontos é enviado em todas as chamadas, para sempre. Os dois exemplos que compraram sete pontos são enviados em todas as chamadas, para sempre. Os dezasseis que compraram doze são enviados em todas as chamadas, para sempre, e têm aproximadamente dez vezes o comprimento da pergunta que o user efetivamente fez. A chain of thought que nada comprou produziu noventa e oito tokens extra por pedido, e output tokens são os caros.

Nada disso é visível numa tabela de accuracies, e tudo isso é visível numa fatura.

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

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