Engenharia de contexto: o que substituiu a engenharia de prompts
Durante muito tempo, “trabalhar com IA” significava uma coisa: formular bem um prompt. Em 2025-2026 isso já não basta. Os modelos chamam tools, puxam documentos via RAG, mantêm memória de sessão e operam em cadeias de agentes. O que decide a qualidade não é a elegância da frase, mas a engenharia de contexto - a disciplina que projeta exatamente o que o modelo vê em cada passo: instruções, factos, histórico, permissões e limites. Abaixo - como ela substituiu a engenharia clássica de prompts e como aplicar em produtos e processos internos.
- Prompt - texto de instrução; contexto - toda a entrada do modelo num passo
- Mudança - de “acha a frase mágica” para “monta o pacote de dados certo”
- Camadas - system, retrieval, memória, tools, estado da tarefa, políticas
- Objetivo - estabilidade, menos alucinações, controlo do custo de tokens
- Prática - contexto estreito e relevante vence “meter tudo na janela”
- Para o negócio - processo e arquitetura vencem um chat sortudo no ChatGPT
O que é engenharia de prompts - e onde encontrou o limite
Engenharia de prompts (prompt engineering) é a arte de formular pedidos a um LLM para obter o estilo, formato e comportamento certos: papéis (“és um analista sénior”), exemplos few-shot, chain-of-thought, templates rígidos de resposta.
Funciona bem para:
- tarefas pontuais no chat;
- geração de rascunhos;
- ensinar a equipa “como perguntar ao modelo”;
- protótipos sem acesso a dados internos.
O limite aparece depressa:
| Situação | Por que um prompt sozinho não chega |
|---|---|
| Precisas de preços e regras atuais | O modelo não conhece a tua tabela sem retrieval |
| Diálogo longo / agente com tools | A janela enche de ruído; o foco perde-se |
| Vários papéis e sistemas | Um system prompt “universal” dilui-se |
| Controlo de risco e compliance | Políticas e máscara de PII não são “uma frase bonita” |
| Custo de API | Tokens a mais em cada turno = prejuízo direto |
O prompt continua a ser parte do sistema. Deixou de ser a alavanca principal de qualidade.
O que é engenharia de contexto
Engenharia de contexto (context engineering) é projetar o pacote de entrada completo para o modelo em cada chamada: o que meter no system, o que puxar da base, o que tirar da memória, que resultados de tools mostrar, o que descartar e o que proibir.
Se o prompt é “como pedir”, o contexto é “em que ambiente informativo o modelo responde”.
Camadas típicas de contexto:
- Instruções e papel - system prompt, política de resposta, formato JSON/Markdown.
- Tarefa do utilizador - pedido atual e histórico mínimo necessário.
- Conhecimento recuperado - fragmentos de wiki, CRM, código, FAQ via pesquisa/RAG.
- Estado - etapa do funil, id do negócio, versão do documento, resultado do passo anterior.
- Observações de tools - respostas de API, SQL, browser, ferramentas MCP.
- Restrições - “não prometas desconto”, “não cites PII”, “escala para um humano”.
O engenheiro de contexto pensa como projetista de pipeline, não como copywriter de frases de sorte.
Como o contexto substituiu a “magia do prompt”
| Antes (foco no prompt) | Agora (foco no contexto) |
|---|---|
| System prompt longo “para tudo” | Prompt estreito + montagem dinâmica da entrada |
| Colar o PDF inteiro no chat | Retrieval: só chunks relevantes |
| “Lembra-te de todo o diálogo” | Compressão, resumo, memória seletiva |
| Um modelo - um chat | Agentes, orquestrador + subagentes, janelas separadas |
| Qualidade = arte de formular | Qualidade = relevância, atualidade, ordem das camadas |
| Depurar o texto do prompt | Depurar a origem: miss de retrieval, falha de tool, overflow |
A mudança de paradigma não significa que os prompts “morreram”. Tornaram-se uma camada ao lado de retrieval, memória, tools e políticas - como uma query SQL ao lado do schema e dos índices.
Por que a mudança acelerou em 2025-2026
Vários fatores coincidiram:
- Agentes e tools - o modelo age, não só responde; o contexto deve incluir resultados das ferramentas.
- Janelas longas - cabe mais, mas “mais” sem filtro = ruído e custo maior.
- Dados empresariais - sem RAG e versionamento de documentos, as respostas não servem ao negócio.
- Multiagente - cada subagente precisa do seu brief estreito, não do log completo.
- Custo e latência - o engenheiro de contexto otimiza o orçamento de tokens como o backend o payload.
Por isso a prática mudou: do “prompt engineer” para platform/ML eng e produto que constroem pipelines de contexto.
Prática: como montar o contexto num passo
Checklist útil antes de chamar o LLM:
- Objetivo do passo - o que deve sair (JSON, decisão, rascunho).
- Instruções mínimas - sem duplicar o que tools e dados já dão.
- Retrieval - top-k fragmentos com metadados (fonte, data, versão).
- Histórico - só réplicas relevantes ou um resumo curto, não o fio inteiro.
- Saídas de tools - brutas mas cortadas; sem segredos nem campos a mais.
- Orçamento de tokens - limite rígido; em overflow: instrução → tarefa → factos → histórico.
- Políticas - o que o modelo não pode afirmar sem um humano.
Exemplo para suporte:
[system] papel + proibições + formato
[retrieved] 3 chunks da base de conhecimento (com data)
[state] id do ticket, plano do cliente, idioma
[user] pergunta atual
Não assim:
[system] 4 páginas de “sê útil...”
[history] 80 mensagens completas
[files] todo o workspace do Notion
[user] pergunta
Contexto vs prompt: o que corrigir se a resposta falha
| Sintoma | Muitas vezes corrige-se com prompt | Muitas vezes corrige-se com contexto |
|---|---|---|
| Tom / formato errado | Sim: afinar a instrução | Raramente |
| Factos inventados | “Não inventes” ajuda pouco | Retrieval + recusar sem fonte |
| Conteúdo desatualizado | Meter uma data no prompt | Versões de documentos + filtro de atualidade |
| O modelo “esqueceu” a tarefa | Repetir no fim | Manter goal/state num bloco à parte |
| Caro e lento | Cortar cortesia | Cortar histórico e ruído de retrieval |
| Ação perigosa | “Tem cuidado” | Remover o tool / exigir human-in-the-loop |
Regra de debug: primeiro dados e seleção, depois redação.
O que isto significa para o negócio
Se colocas IA no CRM, suporte, pesquisa interna ou agentes de código:
- O orçamento deixa de ir para “cursos de prompts para managers” e vai para qualidade do corpus, indexação, logs e políticas de acesso.
- KPI de qualidade: hit-rate de retrieval, % de respostas “com fonte”, custo por cenário, escaladas a humano.
- Playbooks de prompts ainda ajudam em chats manuais - mas a IA de produto constrói-se como pipeline de contexto.
- Escolher contexto longo, RAG ou fine-tuning é uma decisão de arquitetura à parte; ver a análise.
Teste de maturidade para o dono: consegues explicar de que fontes o modelo montou a resposta do caso de ontem? Se não - ainda tens engenharia de prompts no chat, não engenharia de contexto no sistema.
Erros frequentes
- Dar ao modelo “tudo o que há” porque a janela é longa.
- Manter um system prompt gigante em vez de montagem dinâmica.
- Não versionar documentos do RAG - respostas confiantes mas desatualizadas.
- Passar ao subagente o log completo do orquestrador em vez de um brief curto.
- Meter segredos e PII no contexto “porque é conveniente para o modelo”.
- Confundir melhorar a frase com tapar um buraco nos dados.
Conclusão
A engenharia de prompts ensinou-nos a falar com os modelos. A engenharia de contexto ensina a construir sistemas em que o modelo recebe exatamente a informação, as tools e os limites de que o passo precisa - nem mais nem menos. Em 2026, a qualidade da IA empresarial não é definida por uma “frase mágica”, mas por um pipeline: seleção de factos, memória, tools, políticas e orçamento de tokens. O prompt continua a ser parte desse pipeline - mas já não é o protagonista.
Perguntas frequentes
Em que a engenharia de contexto difere da de prompts?
A de prompts foca-se no texto da instrução. A de contexto cobre toda a entrada do modelo: instruções + factos recuperados + histórico + estado + resultados de tools + proibições. O prompt é uma camada; o contexto é o sistema que monta essa camada e as outras.
Ainda é preciso prompt engineering em 2026?
Sim, como competência e como camada. Instruções claras, formatos e few-shot continuam a importar. Mas em produtos e agentes, um “prompt perfeito” não estabiliza a qualidade sem seleção de dados, memória e políticas.
É a mesma coisa que RAG?
Não: é mais amplo. RAG é uma forma de encher o contexto com conhecimento do corpus. O contexto também inclui memória do diálogo, estado do workflow, saídas de tools, papéis e políticas de segurança. RAG é um componente típico e importante, não toda a disciplina.
Por onde começar na empresa?
Escolhe um cenário (suporte, pesquisa de regulamentos, assistente de vendas). Fixa as fontes da verdade, adiciona retrieval com datas/versões, comprime o histórico a um resumo e regista “o que entrou no contexto”. Afina o prompt depois de os dados deixarem de mentir.
Como saber se o problema é o contexto e não o modelo?
Se mudar de modelo (GPT → Claude → Gemini) quase não altera o erro, mas mudar documento / top-k / corte de histórico altera - o problema é a montagem da entrada. Muda de fornecedor só quando o pipeline de contexto for transparente e mensurável.