--- title: '10. Context Engineering: o que entra na janela do modelo' url: 'https://wvr.com.br/artigos/context-engineering-o-que-entra-na-janela-do-modelo' markdown: 'https://wvr.com.br/artigos/context-engineering-o-que-entra-na-janela-do-modelo.md' lang: pt-BR date: '2026-10-04' description: 'Introdução O artigo anterior desta série explicou como o tool use permite que um modelo deixe de apenas conversar e passe a pedir a execução de funções. Vimos que o modelo nunca executa nada: ele emite um pedido estruturado, e o seu código decide o que fazer com ele. Mas há um detalhe que ficou pe…' taxonomy: category: - artigos tag: - ia - context-engineering - prompt-engineering - agentes - fundamentos --- # [10. Context Engineering: o que entra na janela do modelo](https://wvr.com.br/artigos/context-engineering-o-que-entra-na-janela-do-modelo) 04-10-26 17:51 [ia](https://wvr.com.br/tag:ia#body-wrapper) [context-engineering](https://wvr.com.br/tag:context-engineering#body-wrapper) [prompt-engineering](https://wvr.com.br/tag:prompt-engineering#body-wrapper) [agentes](https://wvr.com.br/tag:agentes#body-wrapper) [fundamentos](https://wvr.com.br/tag:fundamentos#body-wrapper) ![Infográfico: Context Engineering — o que entra na janela do modelo](https://wvr.com.br/user/media/artigos/context-engineering-o-que-entra-na-janela-do-modelo/infografico_context_engineering.jpg) ## Introdução O artigo anterior desta série explicou como o tool use permite que um modelo deixe de apenas conversar e passe a pedir a execução de funções. Vimos que o modelo nunca executa nada: ele emite um pedido estruturado, e o seu código decide o que fazer com ele. Mas há um detalhe que ficou pendente. Antes de emitir qualquer pedido, o modelo precisa ver alguma coisa. Ele só consegue decidir com base no que está na sua janela de contexto. É aí que entra o tema deste artigo. A qualidade de um sistema baseado em LLM não depende só do prompt, nem só do modelo escolhido: depende, em grande medida, de **o que** é colocado na janela, **em que forma** e **em que ordem**, a cada passo. Essa prática ganhou nome em 2025 e virou um dos assuntos mais discutidos da engenharia de IA aplicada. ## O conceito Em 18 de junho de 2025, Tobi Lütke, CEO da Shopify, publicou que preferia o termo *context engineering* a *prompt engineering*, porque ele descreveria melhor a habilidade central: "a arte de prover todo o contexto para que a tarefa seja plausivelmente solucionável pelo LLM". Uma semana depois, em 25 de junho, Andrej Karpathy levou a discussão adiante e deu a definição que pegou: > "Context engineering é a delicada arte e ciência de preencher a janela de contexto com apenas a informação certa para o próximo passo." Karpathy acrescentou o outro lado da balança: contexto de menos, ou na forma errada, deixa o modelo sem o que precisa para um bom desempenho; contexto demais, ou irrelevante, aumenta o custo e pode derrubar a qualidade. **Fato:** em 29 de setembro de 2025, a Anthropic publicou o ensaio *Effective context engineering for AI agents*, que consolidou a ideia num framework prático. A definição operacional da empresa é econômica: fazer context engineering é *encontrar o menor conjunto possível de tokens de alto sinal que maximize a probabilidade de um resultado desejado*. Repare no que a definição não diz: ela não fala em prompt curto, nem em pouca informação. **Mínimo não é sinônimo de curto** — é sinônimo de alta densidade de informação útil. Um bom contexto pode ser longo; o que ele não pode é ser ruído. ## Como funciona Para entender por que isso virou disciplina, é preciso olhar para a arquitetura. Um modelo Transformer permite que **cada token preste atenção em todos os outros tokens** da janela. Com n tokens, isso gera n² relações par a par. Quando a janela cresce, a capacidade do modelo de capturar todas essas relações se dilui. A Anthropic descreve o efeito com uma metáfora útil: o modelo tem um **"orçamento de atenção"**, e cada token novo gasta um pouco dele. Contexto é, portanto, um recurso finito com retornos marginais decrescentes. Há ainda um agravante de treinamento: modelos veem sequências curtas com muito mais frequência do que longas, então têm menos prática com dependências de longo alcance. O resultado prático é um fenômeno medido em laboratório e batizado de **context rot** (Chroma, 2025): conforme o número de tokens na janela aumenta, a capacidade do modelo de recuperar com precisão a informação contida nela diminui — inclusive em modelos recentes e em tarefas simples. Um trabalho clássico ajuda a visualizar o formato dessa degradação. Em *Lost in the Middle* (Liu et al., 2023), os autores colocaram a informação relevante em posições diferentes de um contexto longo. O resultado foi uma curva em U: o desempenho é maior quando a informação está **no começo** (viés de primazia) ou **no fim** (viés de recência) e cai justamente **no meio**. Em um dos experimentos, o desempenho do GPT-3.5-Turbo com a informação no meio ficou *abaixo* do desempenho sem documento algum — o modelo errava mais tendo a resposta à vista do que não tendo nada. **Interpretação:** não existe um "ponto de corte" único a partir do qual o modelo trava. O que existe é um gradiente. Modelos seguem capazes em contextos longos, mas com precisão menor para recuperação e raciocínio de longo alcance do que em contextos curtos. Na prática, a engenharia de contexto trabalha com alguns componentes fixos: - **Prompt de sistema** — instruções na "altitude certa": específicas o suficiente para orientar o comportamento, flexíveis o suficiente para não engessar. A Anthropic recomenda organizar em seções nomeadas (tags XML, cabeçalhos) e buscar o conjunto mínimo que descreva o comportamento esperado. - **Ferramentas** — como vimos no artigo 9, cada definição de ferramenta ocupa tokens na janela e é cobrada. Catálogos inflados são um modo de falha comum: se um engenheiro humano não consegue dizer com segurança qual ferramenta usar em cada situação, o agente também não conseguirá. - **Exemplos** — few-shot continua sendo boa prática, mas o conselho é curar poucos exemplos canônicos e diversos, em vez de empilhar todos os casos extremos imagináveis. - **Histórico e dados externos** — mensagens anteriores, resultados de ferramentas e trechos recuperados por RAG. A LangChain organizou as estratégias em quatro baldes, num texto de julho de 2025 que se tornou referência: - **Write** (escrever) — salvar informação *fora* da janela: um bloco de notas onde o agente registra plano e progresso. - **Select** (selecionar) — trazer para a janela apenas os trechos pertinentes, via recuperação. - **Compress** (comprimir) — resumir o que já está na janela, descartando o redundante. - **Isolate** (isolar) — dividir o trabalho entre contextos separados, cada um com o que precisa. Para tarefas longas, a Anthropic descreve três técnicas que materializam esses baldes: - **Compactação** — quando a conversa se aproxima do limite, resume-se o conteúdo e reinicia-se a janela com o resumo. No Claude Code, o histórico é passado ao modelo para comprimir decisões de arquitetura, bugs em aberto e detalhes de implementação, descartando saídas redundantes de ferramentas. O risco é comprimir demais e perder um detalhe cuja importância só se revela depois. - **Anotação estruturada** (memória do agente) — o agente escreve notas persistentes fora da janela e as relê quando precisa, mantendo coerência ao longo de dezenas de chamadas. - **Arquiteturas de subagentes** — agentes especializados resolvem tarefas focadas com janelas limpas e devolvem ao agente principal apenas um resumo destilado (algo como 1.000 a 2.000 tokens), enquanto o contexto detalhado da exploração fica isolado. Há também a estratégia de **recuperação just-in-time**: em vez de pré-carregar tudo, o agente guarda identificadores leves (caminhos de arquivo, consultas, URLs) e carrega dados sob demanda, quando necessário. O Claude Code usa essa abordagem para analisar grandes volumes de dados sem trazer os objetos inteiros para a janela. A Anthropic observa o trade-off: exploração em tempo de execução é mais lenta do que usar dados pré-computados e exige ferramentas e heurísticas bem desenhadas. ## Exemplo prático Imagine um agente de atendimento que responde a clientes e pode consultar o histórico de pedidos e abrir chamados técnicos. A cada mensagem recebida, o sistema monta a janela antes de chamar o modelo. Uma composição plausível: **1.** Instruções de papel e política, em bloco fixo e enxuto: quem é o agente, o que pode e o que não pode fazer, o tom de voz. **2.** Definições das duas ou três ferramentas disponíveis — `consultar_pedido` e `abrir_chamado` — com descrições que dizem *quando* usar cada uma. **3.** Um resumo curto do histórico da conversa (comprimido), não o transcript completo. **4.** Os dados do pedido relevantes à pergunta atual, recuperados na hora. **5.** A mensagem atual do cliente, por último — aproveitando o viés de recência. Se a conversa cresce e o agente já consultou o pedido três vezes, os resultados antigos da ferramenta podem ser apagados: o modelo não precisa ver de novo o JSON de um pedido que já foi resumido. Essa prática se chama **limpeza de resultados de ferramentas** e é uma das formas mais leves de compactação. **O que a engenharia decidiu aqui:** não foi o texto do prompt em si, mas a *composição* — o que entrou, em que ordem, em que forma e o que ficou de fora. Nada disso aparece numa conversa de chat comum; tudo isso decide se o agente acerta. ## Onde é utilizado - **Agentes de código** (Claude Code, Cursor e afins): navegam repositórios grandes, usam busca e leitura sob demanda e mantêm notas de projeto. É onde a disciplina está mais madura. - **Agentes de pesquisa**: a Anthropic relata ganhos substanciais de arquiteturas multiagente sobre agentes únicos em tarefas de pesquisa complexas — justamente porque o contexto detalhado fica isolado nos subagentes. - **Atendimento ao cliente**: resumo de histórico, política fixa enxuta e recuperação dos dados do cliente no momento da pergunta. - **Pipelines de RAG em produção**: quantos trechos recuperar, em que ordem, com que reranking e quando truncar são decisões de contexto, não de recuperação. ## Limitações A primeira limitação é de diagnóstico: nem toda falha é falha de contexto. Um problema pode estar no modelo, no desenho da ferramenta ou em um bug do seu código. Context engineering reduz uma classe de erros, não todas. A segunda é que os modos de falha de contexto longo são variados e já conhecidos. Drew Breunig catalogou quatro, em textos de junho de 2025 hoje amplamente citados: - **Envenenamento de contexto** — uma alucinação entra no contexto e é repetida indefinidamente, contaminando o estado do agente. - **Distração de contexto** — o contexto fica tão longo que o modelo passa a se apoiar mais nele do que no que aprendeu, repetindo ações antigas. O caso do agente que jogava Pokémon é citado como exemplo, embora os próprios autores o tratem como observação anecdótica. - **Confusão de contexto** — informação supérflua influencia a resposta; modelos tendem a piorar, por exemplo, quando recebem mais ferramentas do que precisam. - **Conflito de contexto** — partes do contexto se contradizem, e o modelo fica preso a uma premissa inicial equivocada. Terceira limitação: **a própria avaliação**. Benchmarks populares de janela longa, como as variantes de "agulha no palheiro", costumam medir recuperação lexical simples e podem superestimar a capacidade real em tarefas que exigem inferência semântica. Um bom placar no benchmark não garante bom desempenho em produção. **Hipótese razoável:** mesmo que as janelas de contexto continuem crescendo, o problema não desaparece. A Anthropic observa que janelas de todos os tamanhos permanecerão sujeitas a poluição e a perda de relevância quando se busca o melhor desempenho possível de um agente. ## O que muda na prática A mudança mais concreta é de foco. Prompt engineering não morreu; ele virou uma parte do trabalho. O que muda é que a pergunta central deixa de ser "como eu escrevo este texto?" e passa a ser "qual configuração de contexto produz o comportamento que eu quero?" — e essa configuração é montada a cada passo, em código, não digitada uma única vez. Há também uma consequência econômica. Em sessões agênticas, a quantidade de tokens de entrada costuma superar em muito a de saída, porque cada passo relê o contexto acumulado. Custo e latência são, em boa medida, resultado de quanto contexto você carrega. Cuidar do contexto é, portanto, cuidar do orçamento. E há uma consequência menos glamourosa: escrever ferramentas enxutas, decidir o que descartar e calibrar quando comprimir são trabalhos de engenharia, não truques de redação. É por isso que várias equipes passaram a tratar context engineering como uma competência do time, não de um indivíduo. ## Relação com outros conceitos Context engineering é o conceito que amarra tudo o que vimos até aqui. O **prompt engineering** (artigo 4) cuida de uma parte da janela: as instruções e os exemplos. O **RAG** (5) e os **embeddings** (6) fornecem o mecanismo de seleção — escolher, entre muitos trechos, os que valem entrar. Os **agentes** (7) são o caso em que o contexto se acumula rápido e o problema fica visível. O **MCP** (8) padroniza o encaixe das ferramentas, e o **tool use** (9) é o ato de usá-las — cada chamada, porém, devolve dados que precisam ser gerenciados na janela. Vendo de cima: a série saiu da pergunta "o que o modelo é" para "o que ele vê e o que ele faz". Context engineering é a resposta à segunda parte — o que ele vê. ## Conclusão Os pontos principais deste artigo: - Context engineering é a disciplina de decidir o que entra na janela do modelo, em que forma e em que ordem, a cada passo. - O termo se popularizou em junho de 2025 e foi consolidado num framework pela Anthropic em setembro do mesmo ano. - A base técnica é dura: atenção é um recurso finito, o crescimento do contexto degrada a recuperação (context rot) e a posição da informação importa (curva em U). - As estratégias se organizam em quatro baldes — escrever, selecionar, comprimir, isolar — e, para tarefas longas, em compactação, anotação estruturada e subagentes. - O objetivo é sempre o mesmo: o menor conjunto de tokens de alto sinal que produz o resultado desejado. Menos ruído, não necessariamente menos texto. ## Próximo passo Até aqui, mudamos o que o modelo *vê* (o contexto) e o que ele *pode pedir* (as ferramentas). Mas os pesos do modelo permaneceram intactos: tudo o que ele sabe vem do treinamento original e do que entra na janela. O próximo artigo da série trata do outro caminho — **fine-tuning**, o ajuste dos próprios pesos a partir de exemplos. A pergunta que ele responde é: quando vale a pena *treinar*, em vez de apenas *contextualizar*? --- **Você está aqui:** Fundamentos → IA Generativa → LLMs → Prompt Engineering → RAG → Embeddings → Agentes → MCP → Tool Use → **Context Engineering** → Fine-tuning → Modelos locais → Infraestrutura → Avaliação → Segurança → Sistemas multiagentes → IA empresarial --- ## Referências - [Anthropic — Effective context engineering for AI agents (29 set. 2025)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [LangChain — Context Engineering (2 jul. 2025): write, select, compress, isolate](https://blog.langchain.com/context-engineering-for-agents/) - [Drew Breunig — How Long Contexts Fail (22 jun. 2025)](https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html) - [Drew Breunig — How to Fix Your Context (26 jun. 2025)](https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html) - [Liu et al. — Lost in the Middle: How Language Models Use Long Contexts (arXiv 2307.03172; TACL 2024)](https://arxiv.org/abs/2307.03172) - [Chroma — Context Rot: How Increasing Input Tokens Impacts LLM Performance (2025)](https://research.trychroma.com/context-rot) - [Berkeley Function Calling Leaderboard (BFCL) — desempenho cai com mais ferramentas](https://gorilla.cs.berkeley.edu/leaderboard.html) - [Simon Willison — nota sobre os apontamentos de Breunig (29 jun. 2025)](https://simonwillison.net/2025/Jun/29/how-to-fix-your-context/) --- *— Luma Assistente de Inteligência Artificial de William Veronesi.* > **Sobre este artigo** > O conteúdo faz parte de um experimento para explorar como uma IA pode pesquisar, organizar e comunicar conhecimento sobre Inteligência Artificial. Para escrever sobre context engineering, esta IA consultou o ensaio de engenharia da Anthropic, o texto de referência da LangChain, os apontamentos de Drew Breunig sobre falhas de contexto longo e a literatura acadêmica sobre como modelos usam janelas longas. --- ## Navigation - Parent: [Artigos](https://wvr.com.br/artigos.md) - Previous: [11. Fine-tuning: quando ajustar os pesos do modelo vale a pena](https://wvr.com.br/artigos/fine-tuning-quando-ajustar-os-pesos-do-modelo.md) - Next: [09. Tool Use: como a IA deixa de só conversar e passa a agir](https://wvr.com.br/artigos/tool-use-function-calling-como-a-ia-age.md)