Context Engineering: talvez o problema nunca tenha sido o seu prompt
Prompt engineering ganhou fama de habilidade quase artesanal: encontrar a frase certa, o adjetivo certo, a instrução mágica que faz o modelo responder do jeito esperado. Boa parte dessa fama nunca fez muito sentido, e o termo “context engineering” existe justamente para apontar para onde a atenção deveria ter ido o tempo todo.
De ajustar frase para organizar informação
Prompt engineering, no sentido estrito, é sobre como formular a instrução: a frase, a estrutura, os exemplos usados dentro do próprio pedido. Context engineering desloca o foco para uma pergunta diferente: o que exatamente está entrando na janela de contexto do modelo antes mesmo da instrução ser processada.
A distinção importa porque a instrução é só uma fração do que o modelo enxerga numa interação real. Existe também instrução de sistema, histórico de conversa, resultado de ferramentas chamadas anteriormente, documento recuperado por busca (RAG) e qualquer memória de sessões passadas que o sistema decida reinserir. Context engineering é o trabalho de selecionar, organizar, resumir e podar tudo isso, ativamente, antes de qualquer resposta ser gerada.
Por que isso rende mais que só reescrever a pergunta
Um modelo respondendo mal raramente está “confuso” com o pedido em si. Mais frequentemente, ele simplesmente não tem, dentro da janela de contexto daquela chamada, a informação necessária para responder bem, ou tem informação demais, irrelevante, competindo por atenção com o que de fato importa.
Trocar um adjetivo na instrução não resolve isso. Ajustar o que é recuperado de uma base de conhecimento, cortar histórico de conversa que não é mais relevante, ou resumir uma ferramenta cujo retorno é grande demais para caber inteiro, resolve.
O que entra sob o guarda-chuva de “contexto”
Alguns exemplos concretos do que costuma ser trabalhado em context engineering:
- instrução de sistema, reduzida ao que realmente orienta o comportamento esperado;
- resultado de busca ou recuperação (RAG), filtrado por relevância antes de entrar no prompt;
- histórico de conversa, compactado ou truncado quando cresce demais;
- saída de ferramenta (function calling), formatada de um jeito que o modelo consiga usar sem reprocessar ruído.
Cada um desses itens compete pelo mesmo espaço finito. Adicionar mais um documento “só para garantir” não é gratuito, ocupa espaço que poderia estar sendo usado por algo mais relevante para aquela pergunta específica.
Não é mágica, é engenharia mesmo
Vale reforçar: context engineering não é uma técnica que resolve todo problema de qualidade de resposta sozinha. Um pipeline de recuperação mal ajustado continua trazendo documento irrelevante, não importa quão bem organizado o restante do prompt esteja. E um modelo com contexto perfeitamente selecionado ainda pode errar por outros motivos, alucinação, ambiguidade real na pergunta, limite de capacidade do próprio modelo.
O ganho de tratar isso como engenharia, e não como sorte com o prompt, é que o problema fica depurável. Em vez de reescrever a pergunta dez vezes torcendo por um resultado melhor, dá para perguntar objetivamente: o que está entrando nesse contexto, isso é relevante, e o que poderia estar faltando.