Engenharia de contexto: o novo prompt engineering

Durante um tempo, "prompt engineering" foi sinônimo de escrever a frase perfeita. À medida que aplicações de IA ficaram mais complexas — com memória, ferramentas e recuperação de documentos — percebeu-se que o desafio real não é a frase, e sim tudo o que entra na janela de contexto do modelo. Esse trabalho de curadoria ganhou um nome: engenharia de contexto. Neste artigo você vai entender o que é e como praticá-la.

De prompt engineering para engenharia de contexto

Prompt engineering trata da arte de formular instruções. É uma habilidade fundamental, explorada em prompt engineering para código: como pedir o que você precisa. Mas em sistemas reais o prompt raramente é estático — ele é montado dinamicamente a cada chamada, combinando peças de várias fontes.

Engenharia de contexto é a disciplina de decidir quais informações entram na janela de contexto, em que ordem, em que formato e com que prioridade, para que o modelo tenha exatamente o que precisa para a tarefa — nem mais, nem menos. O nome muda o foco: de uma frase para um sistema de informação.

A diferença prática é grande. No prompt engineering, você ajusta palavras à mão e testa. Na engenharia de contexto, você projeta um pipeline: um conjunto de regras e componentes que, dado um pedido qualquer do usuário, constrói o contexto ideal automaticamente. É a transição de "escrever um texto" para "construir o sistema que escreve o texto".

O que cabe na janela de contexto

Antes de tudo, é preciso lembrar que esse espaço é finito. Vale revisitar o que é janela de contexto e por que ela importa: cada modelo tem um limite de tokens, e tudo compete por esse orçamento. Engenharia de contexto é, em grande parte, gestão de orçamento de tokens.

Os principais componentes que disputam esse espaço são:

A arte está em equilibrar esses elementos sem estourar o limite nem diluir a atenção do modelo em ruído.

Por que "mais contexto" nem sempre é melhor

Há uma intuição enganosa de que, se o modelo aceita 200 mil tokens, convém enchê-los. Na prática, ocorre o oposto por três razões. Primeiro, custo e latência crescem com o número de tokens processados a cada chamada. Segundo, a atenção do modelo se dilui: informação relevante enterrada em um mar de texto irrelevante perde peso. Terceiro, há o fenômeno do "lost in the middle", em que conteúdo no meio de contextos longos é sistematicamente menos aproveitado do que o que está nas pontas. Contexto é um recurso a ser curado, não um balde a ser preenchido.

Instruções: a base de tudo

Boas instruções de sistema são o alicerce. Elas definem identidade, restrições e formato de saída. Algumas diretrizes:

Um padrão poderoso para tarefas de raciocínio é induzir o modelo a pensar em etapas. A técnica de Chain-of-Thought, descrita por Wei e colegas (2022), mostra que pedir ao modelo para explicitar passos intermediários melhora significativamente o desempenho em problemas de raciocínio. Incluir essa orientação nas instruções é uma decisão de engenharia de contexto.

Few-shot: ensinar pelo exemplo

Além de descrever a tarefa, você pode demonstrá-la. Incluir alguns exemplos de entrada e saída desejada — a abordagem few-shot — costuma alinhar o formato e o tom melhor do que qualquer descrição textual.

Classifique o sentimento como POSITIVO, NEGATIVO ou NEUTRO.

Texto: "Entrega rápida, adorei o produto." -> POSITIVO
Texto: "Chegou quebrado e ninguém respondeu." -> NEGATIVO
Texto: "O produto é o que diz a descrição." -> NEUTRO

Texto: "{entrada do usuário}" ->

Esses exemplos consomem tokens, então há um trade-off: mais exemplos costumam melhorar a consistência, mas comem orçamento. Selecionar quais exemplos incluir — idealmente os mais próximos do caso atual — é, de novo, engenharia de contexto.

Recuperação: trazendo conhecimento sob demanda

Modelos não sabem tudo, e seu conhecimento tem data de corte. A solução é injetar informação relevante no contexto no momento da consulta — a técnica de RAG, detalhada em RAG na prática: dê memória e contexto ao seu LLM.

A formulação seminal vem de Lewis e colegas (2020), que propuseram combinar um recuperador de documentos com um gerador, de modo que o modelo produza respostas ancoradas em conhecimento externo recuperado. Em vez de confiar apenas no que está "na cabeça" do modelo, você busca os trechos pertinentes e os coloca no contexto.

O desafio de engenharia aqui é selecionar os trechos certos:

1. Receba a pergunta do usuário.
2. Busque os k documentos mais relevantes (busca vetorial/semântica).
3. Filtre e ordene por relevância e atualidade.
4. Monte o contexto: instruções + trechos recuperados + pergunta.
5. Chame o modelo.

Recuperar demais polui o contexto e confunde o modelo; recuperar de menos deixa lacunas. Calibrar esse k e a qualidade da busca é onde mora boa parte do trabalho.

Chunking e citações

Dois detalhes fazem grande diferença na qualidade do RAG. O primeiro é o chunking: como você fatia os documentos. Pedaços grandes demais trazem ruído junto com o sinal; pequenos demais perdem o contexto que dá sentido ao trecho. Fatiar respeitando fronteiras semânticas (parágrafos, seções) costuma render melhor do que cortar por número fixo de caracteres.

O segundo é pedir citações: instrua o modelo a indicar de qual trecho recuperado cada afirmação veio. Isso reduz alucinação, porque ancora a resposta na fonte, e dá ao usuário como verificar. Um agente que responde "segundo o documento X, seção Y" é muito mais confiável do que um que afirma sem rastro.

Memória: o que persiste entre sessões

Um agente útil precisa lembrar. Há duas camadas:

A decisão sobre o que lembrar, o que resumir e o que descartar é puramente engenharia de contexto.

Estratégias de compactação do histórico

Quando a conversa fica longa, há várias táticas para manter o essencial sem estourar o orçamento:

A combinação típica em produção é: resumo do passado distante + mensagens recentes na íntegra + fatos estruturados recuperados sob demanda. Assim o agente parece lembrar de tudo gastando uma fração dos tokens.

Ferramentas: estendendo o que o modelo pode fazer

Quando o agente pode chamar funções, as definições dessas ferramentas também ocupam contexto. Esse é o terreno de como construir um agente de IA que executa tarefas. Cada ferramenta declarada consome tokens com seu nome, descrição e parâmetros.

A consequência prática: não despeje cinquenta ferramentas no contexto. Quanto mais opções, mais tokens gastos e maior a chance de o modelo escolher errado. Exponha apenas as ferramentas relevantes para a tarefa atual, eventualmente filtrando o conjunto dinamicamente.

Boas definições de ferramenta seguem o mesmo cuidado de boas instruções: nome claro, descrição que diz quando usar (não só o que faz), e parâmetros com tipos e descrições objetivas. Uma ferramenta mal descrita é chamada na hora errada, com argumentos errados — e cada erro consome um turno e tokens.

Um protocolo emergente para padronizar como agentes acessam ferramentas e dados externos é descrito em o que é MCP (Model Context Protocol)?. Ele ajuda a organizar essa camada de forma reutilizável entre aplicações.

A ordem importa: montando o contexto

Decidir o que entra é metade do trabalho; a outra metade é onde cada coisa entra. Uma estrutura que funciona bem na prática:

[instruções do sistema]      <- estável, no topo (bom para cache)
[memória de longo prazo]     <- fatos duráveis do usuário
[ferramentas disponíveis]    <- só as relevantes
[conhecimento recuperado]    <- trechos do RAG, com fontes
[histórico resumido]
[mensagens recentes]
[tarefa atual]               <- no fim, em destaque

Colocar as instruções estáveis no início tem um bônus: muitos provedores oferecem cache de prefixo, que reaproveita o processamento da parte inicial idêntica entre chamadas, reduzindo custo e latência. Por isso, mantenha o começo do contexto o mais estável possível e deixe a parte variável (a pergunta atual) no fim.

Contexto em sistemas multiagentes

À medida que as aplicações evoluem de um único agente para times de agentes, a engenharia de contexto ganha uma dimensão nova: cada agente tem sua própria janela, e o desafio passa a ser o que um agente passa para o outro.

Imagine um agente "pesquisador" que varre dezenas de documentos e um agente "redator" que escreve a resposta final. Seria desastroso despejar tudo o que o pesquisador leu no contexto do redator — estouraria o orçamento e diluiria a atenção. A solução é o pesquisador entregar um resumo destilado: só as conclusões e citações relevantes. Isso é engenharia de contexto entre fronteiras de agentes.

Três princípios ajudam aqui:

O efeito colateral positivo é que dividir uma tarefa grande entre agentes com contextos enxutos costuma sair mais barato e mais preciso do que um único agente com um contexto gigantesco tentando dar conta de tudo.

Custo e desempenho: o lado econômico

Engenharia de contexto é, no fim das contas, também uma disciplina de custo. Como a cobrança e a latência crescem com o número de tokens processados, decisões de contexto têm impacto direto na conta e na experiência do usuário.

Algumas alavancas práticas para reduzir custo sem perder qualidade:

A regra de ouro: trate cada token como dinheiro, porque ele literalmente é. Um pipeline bem projetado entrega a mesma qualidade por uma fração do custo de um que enche a janela por preguiça.

Padrões e armadilhas comuns

Alguns princípios que separam bons sistemas de contexto dos ruins:

A armadilha mais frequente é tratar a janela como um balde infinito: jogar tudo dentro e esperar que o modelo se vire. O resultado costuma ser custo alto e qualidade baixa.

Como avaliar e iterar

Engenharia de contexto sem medição é chute. Para iterar com método:

Tratar o contexto como algo a ser experimentado e medido, e não adivinhado, é o que diferencia um protótipo de um sistema de produção.

Perguntas frequentes

Prompt engineering morreu? Não. Ele virou um componente da engenharia de contexto. Escrever boas instruções continua essencial — mas agora é uma peça dentro de um sistema que também gerencia memória, recuperação e ferramentas.

Janelas de contexto gigantes tornam o RAG obsoleto? Não. Mesmo com janelas enormes, jogar tudo dentro é caro, lento e sujeito ao "lost in the middle". RAG continua sendo a forma de levar ao modelo só o que é relevante, com fontes verificáveis.

Como decido o valor de k no RAG? Empiricamente. Comece pequeno (3 a 5 trechos), meça a qualidade e suba só se houver lacunas. Mais trechos aumentam custo e ruído; o ponto ótimo varia por domínio e por qualidade da busca.

Qual o maior erro de iniciante? Tratar o contexto como depósito. O segundo maior é não medir: ajustar o pipeline "no feeling" sem um conjunto de avaliação que diga se a mudança ajudou ou piorou.

Conclusão

Engenharia de contexto é a evolução natural do prompt engineering para a era dos agentes: o foco sai da frase isolada e vai para o sistema que decide, a cada chamada, o que o modelo verá. Dominar essa disciplina significa orquestrar instruções claras, exemplos few-shot bem escolhidos, recuperação precisa de conhecimento (Lewis et al., 2020), memória bem gerida, ferramentas enxutas e técnicas de raciocínio como Chain-of-Thought (Wei et al., 2022) — tudo dentro de um orçamento finito de tokens, na ordem certa e medido com rigor. Quem trata o contexto como um recurso a ser projetado, e não como um depósito a ser preenchido, constrói agentes mais confiáveis, mais baratos e mais precisos.

Referências