A engenharia de contexto está substituindo a engenharia de prompts como a habilidade de IA que importa

A engenharia de prompts nunca foi realmente sobre encontrar palavras mágicas. Era sobre fornecer ao modelo informações suficientes e relevantes, em um formato que ele pudesse usar, para produzir uma boa resposta. Essa distinção importava menos quando a tarefa era uma simples troca de pergunta e resposta. Ela importa enormemente agora que a maioria dos sistemas de IA em produção são agentes: loops que chamam ferramentas, leem resultados, recuperam documentos e mantêm estado ao longo de dezenas de etapas.

A habilidade que determina se esses sistemas funcionam não é mais a formulação do prompt. É a engenharia de contexto — a disciplina de decidir o que entra na janela de contexto do modelo em cada etapa, como é estruturado e quando é descartado. Equipes que tratam isso como secundário constroem agentes caros, lentos e que erram de formas difíceis de depurar.

Por que a engenharia de prompts deixou de ser suficiente

Um único prompt bem elaborado assume que o modelo já tem tudo o que precisa para responder. Fluxos de trabalho agênticos não funcionam assim. Um agente depurando um incidente de produção pode reunir trechos de logs, um manual operacional, três threads do Slack relacionadas e a saída de duas chamadas de ferramentas — tudo antes de escrever uma única palavra de sua resposta real. Nada disso é “o prompt” no sentido de 2023. É um orçamento de contexto, e cada token nele é uma decisão.

Janelas de contexto maiores pioraram a situação antes de melhorá-la. Quando os modelos da era GPT-4 atingiam o teto por volta de 32 mil tokens, as equipes eram forçadas a ser seletivas por necessidade. Janelas de contexto de um milhão de tokens removeram essa restrição, e a resposta ingênua — despejar tudo o que é relevante e deixar o modelo organizar — acabou degradando o desempenho. Pesquisas sobre recuperação em contexto longo mostram consistentemente que os modelos prestam atenção de forma desigual em um contexto grande, frequentemente favorecendo informações próximas ao início ou fim e perdendo precisão em fatos enterrados no meio. Mais tokens não é mais sinal. É frequentemente mais ruído com uma conta de API mais alta.

As quatro tarefas da engenharia de contexto

Na prática, a engenharia de contexto se divide em quatro problemas separáveis, e a maioria das falhas de agentes remonta a errar em um deles.

Seleção de recuperação

Decidir o que trazer para o contexto. Essa é a tarefa para a qual os pipelines de RAG foram construídos, mas a qualidade da seleção importa mais que a abrangência da recuperação. Retornar os 20 trechos mais semanticamente semelhantes não é o mesmo que retornar os 5 que realmente respondem à pergunta. Equipes que otimizam para abrangência em vez de precisão acabam voltando à armadilha de despejar tudo, só que agora é um modelo de embedding fazendo o despejo em vez de um humano.

Compressão

Saídas brutas de ferramentas, arquivos de log e trechos de documentos raramente valem a pena enviar literalmente. Um stack trace de 400 linhas geralmente se comprime em três linhas relevantes e um resumo sem perder nada que o modelo precise. A compressão é de onde vem a maior parte da economia de custo em tokens em sistemas de agentes em produção, e também é onde uma sumarização ingênua pode silenciosamente apagar o único detalhe que importava.

Estrutura e ordenação

Onde a informação fica no contexto afeta se o modelo a usa corretamente. Colocar restrições e instruções imediatamente antes da etapa de geração, em vez de enterrá-las no topo de um prompt de sistema longo, melhora de forma mensurável o seguimento de instruções em contextos longos. Ordenação não é cosmética — é estrutural.

Reescrita de memória

Agentes que operam em mais de um turno precisam de uma política sobre o que é escrito na memória persistente versus o que permanece efêmero no contexto atual. Escrever tudo transforma a memória em um segundo depósito com o mesmo problema de ruído. Não escrever nada faz o agente re-derivar os mesmos fatos em cada sessão, consumindo tokens e latência em redescoberta.

Onde as equipes erram

A falha mais comum é tratar o contexto como gratuito. Não é. Cada documento adicional na janela aumenta latência, custo e — além de certa densidade — uma queda mensurável na qualidade da resposta, às vezes chamada de “degradação de contexto”. A segunda falha mais comum é a montagem estática de contexto: construir um único pipeline de construção de contexto e usá-lo para toda consulta, independente de a tarefa precisar de três documentos ou trinta. A terceira é ignorar completamente a política de descarte, de modo que uma sessão de agente de longa duração acumula saídas de ferramentas até que a maior parte da janela de contexto seja andaime de etapas que o agente não precisa mais.

Como isso parece em um sistema que funciona

Equipes que acertam isso geralmente têm um orçamento de contexto explícito por etapa: um teto de tokens para documentos recuperados, um teto separado para saídas de ferramentas, e uma alocação reservada para instruções e turnos recentes de conversa que nunca é deslocada. Elas registram o que estava no contexto quando um agente produziu uma resposta ruim, da mesma forma que registrariam um stack trace, porque a composição do contexto agora é uma superfície primária de depuração, não um detalhe de implementação.

Conclusões práticas

Pare de otimizar a redação do prompt isoladamente. Auditar o que realmente entra na janela de contexto em cada etapa da execução do seu agente, e medir quanto disso o modelo realmente usa.
Trate a precisão de recuperação como mais importante que a abrangência. Retornar menos resultados mais relevantes é melhor que retornar mais resultados e esperar que o modelo os filtre.
Construa uma etapa de compressão para saídas de ferramentas e logs antes que eles cheguem à janela de contexto, não depois que uma revisão de custos sinalizar o gasto em tokens.
Coloque a instrução da tarefa e as restrições próximas ao ponto de geração, não enterradas no topo de um prompt de sistema longo, especialmente quando seu contexto exceder alguns milhares de tokens.
Defina uma política explícita de reescrita de memória em vez de recorrer por padrão a acumular tudo ou descartar tudo entre turnos.