Qual a diferença entre engenharia de contexto e engenharia de prompts?

Engenharia de prompts é escrever bem o texto que alguém redigiu: a instrução, o formato pedido, os exemplos. Engenharia de contexto é decidir tudo que ocupa a janela naquela chamada — esse texto, mais o histórico, as definições de ferramentas e os documentos recuperados. A segunda contém a primeira. Não são concorrentes e a mais nova não aposentou a mais velha.

A confusão tem causa concreta. Quando os dois termos apareceram, o trabalho era diferente. Em 2020, você mandava um bloco de texto e recebia um bloco de texto de volta, e melhorar o resultado significava melhorar aquele bloco. Isso é engenharia de prompts, e para uma chamada única ela continua cobrindo quase tudo que importa.

Em 2026, boa parte das aplicações roda um agente que chama ferramentas em sequência. O que o modelo lê na décima iteração não foi escrito por ninguém: veio de uma busca, de um arquivo lido, de uma resposta de API. Decidir o que fica e o que sai daí é engenharia de contexto, e é um problema que a disciplina anterior nunca precisou resolver.

O que cada uma decide

O modelo não vê a divisão. Ele recebe uma sequência de tokens e responde. A separação existe no seu código, e é útil porque as duas metades falham de formas diferentes e se corrigem com ferramentas diferentes.

Engenharia de prompts decide o que está escrito. Que papel o modelo assume, que formato a saída tem, o que fazer diante de entrada ambígua, quantos exemplos mostrar e quais. É trabalho de redação técnica, avaliado rodando variações contra um conjunto de casos. O ciclo é curto: você muda uma frase e mede em minutos.

Engenharia de contexto decide o que chega. Quanto do espaço vai para cada categoria, o que é buscado sob demanda e o que é pré-carregado, quando o histórico é resumido, em que ordem os blocos entram e o que é descartado quando a janela aperta. É trabalho de sistema, avaliado com instrumentação: quantos tokens foram para cada categoria, em cada chamada.

As duas faixas verdes da figura são a interseção. O system prompt e a pergunta do usuário são texto escrito à mão, e portanto território das duas disciplinas ao mesmo tempo. Quem trabalha só com chamada única passa a vida inteira nessa interseção, e por isso a distinção parece acadêmica — até a primeira vez em que um resultado de ferramenta de 30 mil tokens entra na janela sem aviso.

O jeito mais rápido de sentir a diferença é olhar o formato da falha. Falha de prompt é consistente: o modelo erra do mesmo jeito em todos os casos parecidos, porque a instrução está ambígua da mesma forma toda vez. Falha de contexto é irregular: o mesmo pedido acerta numa sessão e erra em outra, e a variável que mudou foi o que já estava na janela quando ele chegou. Se o seu bug só aparece em conversa longa, ou só depois da décima ferramenta, ele não é de redação.

De onde veio cada termo

A prática é mais velha que os dois nomes, mas a ordem em que eles apareceram explica o que cada um estava tentando resolver.

O prompt virou interface em 2020. O paper do GPT-3 mostrou que dava para especificar uma tarefa sem atualizar nenhum peso, só descrevendo-a e colocando alguns exemplos na entrada — o que os autores chamaram de aprendizado em contexto (in-context learning)¹. A partir daí, o texto de entrada deixou de ser um detalhe de uso e virou o lugar onde o trabalho acontece.

O nome ganhou um contorno mais sério em 2021. Um trabalho daquele ano argumentou que prompts deveriam ser pensados pela lente da linguagem natural, e não como configuração — e mediu algo que contrariava o senso comum da época: prompts zero-shot bem escritos podiam superar prompts com exemplos. A explicação que eles propõem é que os exemplos, nesses casos, servem menos para ensinar a tarefa e mais para localizar uma tarefa que o modelo já sabia².

Engenharia de contexto é de 2025. O termo circulou em meados daquele ano e ganhou tratamento sistemático quando a Anthropic publicou um guia de engenharia definindo a disciplina como curar o conjunto de tokens disponível durante a inferência, com quatro técnicas: compactação, notas estruturadas fora da janela, subagentes e recuperação sob demanda³. Em julho do mesmo ano, um levantamento acadêmico formalizou o campo a partir de mais de 1.400 trabalhos, decompondo-o em recuperação e geração de contexto, processamento e gestão⁴.

Repare no que os dois termos têm em comum: nenhum inventou uma técnica. Os dois nomearam um conjunto de práticas que já existiam, no momento em que elas ficaram grandes demais para caber no nome anterior.

Há uma diferença menos discutida e mais prática entre as duas: como cada uma é medida. Um prompt se avalia rodando variações contra um conjunto de casos com a saída esperada, e o número que sai é uma taxa de acerto. Um contexto se avalia por instrumentação — quantos tokens foram para cada categoria, em qual posição da janela estava a informação que respondia, quantas iterações antes de a resposta aparecer. São instrumentos diferentes, e um time que só tem o primeiro consegue melhorar prompt indefinidamente sem nunca enxergar o problema de montagem.

O que mudou foi o loop

Um agente funciona assim: o modelo lê a janela, decide chamar uma ferramenta, o resultado da ferramenta volta para a janela, e o modelo lê tudo de novo. Repita vinte vezes.

Cada volta acrescenta conteúdo que ninguém escreveu e ninguém revisou. Um git diff grande, um log de teste que falhou, o HTML de uma página, a resposta de uma API paginada: qualquer um desses passa de 10 mil tokens sem esforço. Na décima iteração, o system prompt que você escreveu com tanto cuidado é uma fração pequena do que o modelo está lendo.

Aí aparecem perguntas que a engenharia de prompts não tem como responder, porque não são sobre texto:

• Qual resultado de ferramenta ainda importa na iteração 15?
• O log de 40 mil tokens deveria entrar inteiro ou cortado na origem?
• O histórico deveria ser resumido aos 60% da janela ou aos 90%?
• Quinze ferramentas descritas em toda chamada valem os tokens que custam?
• A resposta certa está no meio do contexto, onde o modelo lê pior⁵?

Nenhuma dessas decisões é sobre escrever melhor. Todas são sobre montar melhor. É essa lacuna que o segundo termo veio preencher, e é por isso que ele apareceu quando apareceu: agentes em produção são de 2025, não de 2021.

Um caso que separa as duas

Vale acompanhar um bug real do começo ao fim, porque a diferença fica óbvia quando ela custa dinheiro.

Um agente de atendimento responde a uma pergunta sobre reembolso citando a política errada. A política certa existe, está na base, foi indexada. O agente tem uma ferramenta de busca e a chamou.

O primeiro reflexo de quem trabalha com prompt é reescrever a instrução: “cite sempre a política vigente”, “verifique a data de vigência antes de responder”. Isso melhora um pouco a taxa de acerto e não resolve, porque a causa está fora do texto.

O que aconteceu foi outra coisa. A busca devolveu seis trechos, dois deles de uma versão revogada da política. Os seis entraram na janela em ordem de relevância, e o trecho certo caiu na quarta posição, no meio de um contexto que já tinha 18 mil tokens de histórico de conversa. O modelo leu tudo e escolheu o mais parecido com a pergunta, que era o revogado.

As correções que funcionam são todas de montagem: filtrar por data de vigência no metadado da busca, cortar de seis trechos para dois, colocar o resultado da busca no fim da janela em vez do meio, resumir o histórico antes de acrescentar documento. Nenhuma delas é uma frase melhor escrita.

E existe a correção que pertence de fato à engenharia de prompts, e que também é necessária: instruir o modelo a dizer que não achou quando os trechos não respondem. Sem isso ele responde do que veio, com a mesma confiança de sempre.

Os dois trabalhos são reais. O erro é escolher um deles pelo hábito, em vez de pelo diagnóstico.

Como saber de qual das duas é o seu problema

Existe um teste que separa as duas em uma tarde, e ele vale mais que qualquer definição.

Pegue dez casos em que a aplicação erra. Para cada um, monte o contexto ideal à mão: cole o documento certo, o trecho certo da política, o resultado certo da ferramenta. Nada de busca, nada de agente. Só o modelo, o seu prompt e o conteúdo que deveria ter chegado.

Se o modelo acerta assim, o problema é de contexto. O conteúdo certo existia e não chegou, ou chegou enterrado no meio de outros trinta mil tokens. Mexer no texto da instrução não vai resolver, e é exatamente aí que a maioria dos times gasta as duas semanas seguintes.

Se o modelo erra mesmo com tudo na mão, o problema é de prompt — a instrução está ambígua, o formato não está descrito, falta um exemplo do caso difícil — ou a tarefa está além do que o modelo faz. Nos dois casos, otimizar a montagem de contexto seria trabalho jogado fora.

O teste é barato e quase ninguém roda, porque ele exige admitir antes de começar que você não sabe qual das duas coisas está quebrada.

Onde a distinção não ajuda

Trocar o nome não muda o trabalho. Boa parte do que se publicou sobre engenharia de contexto em 2025 e 2026 é a mesma coisa que se chamava de engenharia de prompts em 2023, com vocabulário novo. Se o seu caso é uma chamada única de chat, os dois termos descrevem o mesmo trabalho e a distinção não paga o esforço de aprender.

A fronteira é porosa de propósito. O system prompt é texto escrito e é uma fatia da janela. Um exemplo few-shot é prompt e ocupa contexto. Discutir de qual lado cai cada coisa é o tipo de conversa que consome uma reunião e não muda uma linha de código.

Nenhum dos dois nomes descreve o gargalo real com frequência. Uma parte considerável do esforço nas duas disciplinas é gasta em tarefas que o modelo simplesmente não sabe fazer. O teste da seção anterior existe justamente para descobrir isso antes.

O segundo termo carrega uma promessa que ele não cumpre. “Engenharia de contexto” soa como uma disciplina resolvida, com práticas estabelecidas. Não é: a evidência sobre ordenação de blocos, ponto de compactação e formato de resumo é fina e varia por família de modelo. O que existe de firme é a instrumentação — medir onde os tokens estão indo — e isso é diagnóstico, não solução.

O que fazer com isso

1. Instrumente antes de nomear. Registre, por chamada, quantos tokens foram para system prompt, ferramentas, histórico e documentos. A fatia dominante costuma surpreender, e ela define de qual disciplina é o seu problema.
2. Rode o teste do contexto ideal em dez casos que erram, antes de reescrever qualquer instrução.
3. Trate o system prompt como texto, com o rigor da engenharia de prompts: versionado, testado contra casos, revisado por alguém.
4. Trate o resto como sistema, com orçamento explícito por categoria e truncamento na origem.
5. Refaça a medição a cada troca de modelo. O ponto onde o contexto começa a atrapalhar muda, e sua configuração foi calibrada para o modelo anterior.

Se você só faz chamadas únicas, pare no passo 3. O resto é infraestrutura para um problema que você ainda não tem.

Footnotes

1. Brown et al. (2020) mostraram que a tarefa pode ser especificada na própria entrada, sem atualizar pesos, o que transformou o texto de entrada no lugar onde o trabalho acontece. ↩

2. Reynolds e McDonell (2021) mediram prompts zero-shot superando prompts com exemplos em vários casos, e propuseram que os exemplos servem mais para localizar uma tarefa já aprendida do que para ensiná-la. ↩

3. O guia de engenharia da Anthropic, de setembro de 2025, define a disciplina como curar o conjunto de tokens disponível durante a inferência e descreve compactação, notas estruturadas, subagentes e recuperação sob demanda. ↩

4. Mei et al. (2025) sistematizaram o campo a partir de mais de 1.400 trabalhos, decompondo-o em recuperação e geração de contexto, processamento e gestão. ↩

5. Liu et al. (2023) mediram queda de desempenho quando a informação relevante fica no meio do contexto, inclusive em modelos anunciados como de contexto longo. ↩