Context engineering: como alimentar o modelo com o contexto certo

O problema

Quando um LLM responde mal, muita gente culpa o modelo rápido demais.

Às vezes a culpa até é do modelo.

Mas, em trabalho real, uma parte enorme das respostas ruins nasce antes:

• contexto faltando
• contexto demais
• contexto desatualizado
• contexto contraditório
• contexto sem prioridade

O resultado costuma ser familiar.

Você pede ajuda para o modelo e ele:

• ignora a parte importante
• usa documento velho
• mistura regra de dois fluxos
• responde genericamente
• escolhe o detalhe errado para focar

E então alguém diz:

“Esse modelo é fraco.”

Às vezes não é fraqueza do modelo.

Às vezes você só deu contexto ruim para ele.

Modelo mental

Pense assim:

Context engineering não é colar mais texto. É escolher o mínimo contexto certo para a tarefa certa.

Essa frase resolve bastante coisa.

Porque tira o tema da lógica “mais é melhor”.

E coloca a conversa no lugar certo:

• o que o modelo precisa saber
• o que ele não precisa saber
• em que ordem isso deveria entrar
• com que nível de detalhe

Contexto bom ajuda o modelo a reduzir ambiguidade.

Contexto ruim só aumenta ruído com aparência de profundidade.

Quebrando o problema

Mais contexto nem sempre melhora a resposta

Esse é o primeiro ajuste mental importante.

Tem gente que trata janela de contexto como caminhão de mudança:

• quanto mais couber, melhor

Mas o efeito real pode ser o oposto.

Quando você joga informação demais, o modelo pode:

• perder hierarquia
• pegar regra irrelevante
• dar peso demais para detalhe lateral
• gastar atenção onde não devia

Ou seja: contexto em excesso também é uma forma de ambiguidade.

Contexto útil é o que muda a decisão do modelo

Uma pergunta simples ajuda muito:

• se eu tirar esta informação, a resposta piora de verdade?

Se a resposta for “não”, talvez esse contexto não precise entrar.

Normalmente o que ajuda mais é:

• requisito específico da tarefa
• trecho de código realmente envolvido
• contrato ou schema relevante
• regra de negócio atual
• erro observado
• restrições explícitas

O que costuma atrapalhar:

• arquivo inteiro sem recorte
• histórico enorme sem prioridade
• documentação lateral
• opinião solta que não muda a resposta
• dado repetido em formatos diferentes

Contexto tem que vir organizado, não só presente

Mesmo quando a informação certa está lá, ela pode entrar mal.

Exemplo:

• bug report perdido no meio
• regra crítica enterrada depois de vinte linhas de detalhe
• código principal misturado com utilitários irrelevantes
• instrução importante sem destaque

Isso importa porque modelo também é sensível à forma como o material chega.

Então context engineering também envolve:

• ordem
• agrupamento
• rótulo
• separação entre fato, restrição e objetivo

Não é só “colar”.

É montar.

Frescor de contexto pesa muito

Outro problema comum:

o time alimenta o modelo com coisa velha e depois culpa a resposta.

Exemplos:

• documentação antiga
• endpoint descontinuado
• regra de negócio que mudou
• versão passada do contrato

Se o contexto está desatualizado, o modelo pode responder de forma coerente com o passado e errada para o presente.

Isso é especialmente perigoso porque a resposta continua plausível.

Então, em tarefas importantes, vale perguntar:

• este contexto ainda vale?
• qual fonte é a mais atual?
• existe conflito entre documento e código?

Contexto velho é uma forma silenciosa de bug.

Resumo e recorte costumam ajudar mais do que dump bruto

Às vezes você tem material demais e não tem como mandar tudo.

Nessas horas, muita gente faz o pior dos dois mundos:

• manda um dump gigantesco sem curadoria

Frequentemente funciona melhor:

• resumir o que importa
• recortar o trecho relevante
• explicar a relação entre os pedaços
• destacar a restrição principal

Por exemplo, em vez de mandar quatro arquivos inteiros, talvez seja melhor mandar:

• o trecho crítico
• a assinatura pública
• a regra de negócio
• o erro observado

Isso reduz ruído sem sacrificar sinal.

Contexto também precisa respeitar fronteira de confiança

Não é só questão de qualidade da resposta.

É também questão de segurança.

Nem todo contexto que ajudaria deveria ser enviado.

Você ainda precisa filtrar:

• segredo
• dado sensível
• informação de cliente
• código que não pode sair daquele ambiente

Então context engineering maduro sempre equilibra duas perguntas:

• isto melhora a resposta?
• isto pode ser enviado?

Se você ignora a segunda, melhora saída e piora governança.

Context engineering é parte do sistema, não detalhe do prompt

Esse ponto vale muito para entrevista.

Muita gente fala de contexto como se fosse uma habilidade literária do usuário final.

Mas, quando a solução fica séria, contexto vira parte do desenho do sistema.

Você precisa pensar em coisas como:

• de onde o contexto vem
• como ele é selecionado
• como é ranqueado
• como é resumido
• como é atualizado
• como é auditado

Nessa hora, o problema deixa de ser “escrever melhor”.

E vira engenharia mesmo.

Exemplo simples

Imagine um assistente interno que ajuda engenheiros a responder perguntas sobre APIs da empresa.

Versão ruim:

• o sistema pega vários documentos aleatórios
• manda tudo de uma vez
• mistura RFC velha, contrato novo e comentário de Slack
• não marca qual fonte é oficial

O modelo até responde com confiança.

Mas pode:

• citar endpoint antigo
• sugerir payload inválido
• confundir autenticação de ambientes diferentes

Agora imagine uma versão melhor.

O sistema:

1. identifica a API e a versão certa
2. prioriza contrato atual e documentação oficial
3. resume contexto lateral em vez de despejar tudo
4. destaca restrições importantes, como autenticação e limites
5. exclui material obsoleto ou contraditório

Repare que o modelo pode até ser o mesmo.

O que mudou foi a qualidade da alimentação.

Isso é context engineering na prática.

Erros comuns

• Achar que janela grande justifica mandar tudo.
• Misturar fonte oficial e informal sem prioridade clara.
• Alimentar o modelo com documento velho porque “está mais fácil de pegar”.
• Colar arquivo inteiro quando só três funções importam.
• Não resumir contexto quando o problema pede recorte.
• Ignorar fronteira de segurança e privacidade.
• Tratar contexto como detalhe do prompt, e não como parte do sistema.

Como um senior pensa

Quem tem mais maturidade olha para contexto como alavanca de precisão e também como fonte de risco.

A lógica costuma ser:

“O que realmente precisa entrar para esta tarefa, e o que só aumenta ruído?”

Essa pessoa também entende que contexto ruim pode parecer rico.

Porque volume e utilidade não são a mesma coisa.

Então ela tende a:

• reduzir escopo
• priorizar fonte confiável
• destacar regra crítica
• resumir o que é lateral
• excluir o que está velho ou perigoso

Em sistemas mais sérios, ela também enxerga que isso precisa ser desenhado de forma reproduzível.

Não deveria depender só de “quem souber perguntar melhor”.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador geralmente quer ver se você entende que resposta boa depende tanto de contexto bom quanto de modelo bom.

Os sinais de maturidade costumam ser:

• você separar relevância de volume
• você falar de frescor, ordenação e fonte confiável
• você tratar contexto como peça do sistema
• você mencionar fronteira de segurança e dados

Uma resposta forte pode soar assim:

“Context engineering, para mim, é decidir o que o modelo realmente precisa ver para responder bem. Isso inclui selecionar fonte mais atual, remover ruído, priorizar informação oficial, resumir o que é lateral e organizar a ordem do contexto. Mais contexto nem sempre ajuda. Contexto errado, velho ou barulhento pode piorar bastante a resposta.”

Isso mostra entendimento de verdade.

Porque sai do nível de truque de prompt.

E entra no nível de sistema.

Um modelo bom com contexto ruim continua errando com muita confiança.

Context engineering não é entupir a janela. É proteger o sinal antes do modelo tocar nele.