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:

• Instruções do sistema: o papel, as regras e o tom do agente.
• Memória de longo prazo: fatos sobre o usuário e o histórico que devem persistir entre sessões.
• Memória de curto prazo: o histórico da conversa atual.
• Conhecimento recuperado: documentos buscados sob demanda (RAG).
• Definições de ferramentas: as funções que o modelo pode chamar.
• A tarefa atual: a pergunta ou comando do momento.

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:

• Seja específico sobre o papel: "Você é um analista financeiro que responde apenas com base nos documentos fornecidos."
• Declare o que NÃO fazer: limites são tão importantes quanto capacidades.
• Defina o formato esperado: se você quer JSON, peça JSON e mostre o schema.

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:

• Memória de curto prazo é o histórico da conversa corrente. Quando ela cresce demais, aplica-se sumarização: condensa-se o passado em um resumo compacto que cabe no orçamento.
• Memória de longo prazo guarda fatos duráveis (preferências do usuário, decisões tomadas) em um armazenamento externo, e os relevantes são recuperados quando necessário — funcionando, na prática, como um RAG sobre a própria história do usuário.

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:

• Janela deslizante: manter apenas as N mensagens mais recentes na íntegra.
• Sumarização progressiva: substituir as mensagens antigas por um resumo que é atualizado conforme a conversa avança.
• Memória estruturada: extrair fatos-chave ("o usuário prefere respostas curtas", "o projeto usa PostgreSQL") e guardá-los separados do diálogo bruto, reinjetando só os relevantes.

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:

• Isolamento: cada agente recebe apenas o contexto necessário ao seu papel, não o histórico inteiro do sistema.
• Compressão na fronteira: a saída de um agente é resumida antes de virar entrada de outro.
• Contrato claro: defina o formato exato do que cada agente produz e consome, como uma API. Saídas estruturadas (JSON com campos nomeados) reduzem ambiguidade e custo.

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:

• Cache de prefixo: mantenha o início do contexto estável para reaproveitar processamento entre chamadas.
• Recuperar só o necessário: cada trecho de RAG a menos é custo e ruído a menos.
• Resumir o histórico: substituir mensagens antigas por resumos corta tokens de forma drástica em conversas longas.
• Escolher o modelo certo para a tarefa: nem todo passo precisa do modelo mais caro; classificações e resumos simples podem rodar em modelos menores.

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:

• Posição importa: modelos prestam mais atenção ao início e ao fim do contexto. Coloque o essencial nas pontas, não enterrado no meio.
• Menos é mais: contexto enxuto e relevante supera contexto vasto e ruidoso. Encher a janela não é o objetivo.
• Formato comunica: estruturar a informação com marcadores, tags e seções ajuda o modelo a navegá-la.
• Cuidado com o "lost in the middle": informações importantes no meio de um contexto muito longo tendem a ser ignoradas.
• Compacte com inteligência: prefira resumir o irrelevante a simplesmente truncá-lo.

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:

1. Monte um conjunto de casos representativos, com a resposta esperada.
2. Meça: qualidade da resposta, número de tokens, latência e custo por chamada.
3. Mude uma variável por vez — o k do RAG, a quantidade de exemplos few-shot, a estratégia de resumo — e compare.
4. Vigie a relação custo/qualidade: muitas vezes dá para cortar metade dos tokens com perda mínima de qualidade.

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

• Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W., Rocktäschel, T., Riedel, S., Kiela, D. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
• Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., Chi, E., Le, Q., Zhou, D. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics.
• Brown, T. et al. (2020). Language Models are Few-Shot Learners. NeurIPS.