Context Engineering: o que o modelo lê quando responde

Como o modelo lê o seu pedido, como decide a resposta, e por que às vezes inventa coisa? A habilidade central de quem trabalha com LLM hoje deixou de ser escrever prompt mais bonito e passou a ser escolher o que entra no contexto do modelo a cada interação, ofício que ganhou o nome de context engineering. Antes de chegar nele, convém destrinchar o que está embaixo: o que é um token, como o modelo é treinado, o que muda quando ele vira agente, e por que o foco migrou do prompt para o contexto.

1 O que esta aula cobre

Como o modelo lê o seu pedido, como decide a resposta, e por que às vezes inventa coisa?

A habilidade central de quem trabalha com LLM hoje deixou de ser escrever prompt mais bonito e passou a ser escolher o que entra no contexto do modelo a cada interação, ofício que ganhou o nome de context engineering. Antes de chegar nele, convém destrinchar o que está embaixo: o que é um token, como o modelo é treinado, o que muda quando ele vira agente, e por que o foco migrou do prompt para o contexto.

2 Como uma máquina lê texto

Computador opera com números, não com letras, e por isso a primeira coisa que acontece quando você manda um pedido para o Claude é a quebra do texto em pedaços chamados tokens. Cada token é um trecho (pode ser palavra inteira, fragmento, ou sinal de pontuação) com um número associado num dicionário interno do modelo, que costuma ter entre 50 e 200 mil entradas.

Repare que “modelo” entrou inteiro enquanto “VAR” e “IPCA” se partiram em duas peças cada. Isso acontece porque o tokenizador foi treinado num corpus enorme de texto e aprendeu quais sequências de letras aparecem juntas com frequência: palavras comuns ganham token próprio, siglas e nomes raros se quebram. Como o corpus de treino é majoritariamente em inglês, textos em português costumam consumir mais tokens que em inglês para a mesma informação.

Por que isso importa na prática. Quando você paga por uso da API ou olha o limite da janela de contexto, a unidade é sempre token, nunca palavra. Um documento de 1.000 palavras em pt-BR tende a ocupar cerca de 1.500 a 1.800 tokens. Saber estimar isso evita surpresa no faturamento e na truncagem da resposta.

3 A tarefa única do LLM: prever o próximo token

Com o texto convertido em sequência de números, o modelo faz uma coisa só: recebe a sequência de tokens vista até agora e devolve, para cada token possível do dicionário, a probabilidade de ele ser o próximo. Em seguida escolhe um (geralmente o mais provável, com algum ruído controlado), anexa à sequência e repete.

A distribuição de probabilidades para o próximo token costuma ter cara assim, dado o início “A inflação de”:

Toda resposta do Claude sai desse processo: prever o próximo token, anexar, repetir. Não há “raciocínio” no sentido humano, e sim um modelo estatístico de larguíssima escala que aprendeu, observando bilhões de páginas, quais sequências de tokens fazem sentido.

parâmetro temperatura controla o quanto o modelo se afasta da escolha mais provável. Temperatura zero pega sempre o token de maior probabilidade, produzindo resposta determinística; temperatura alta amostra com mais ruído, permitindo variação criativa. O Claude usa temperatura moderada por padrão.

Quando um economista monta um ARIMA para projetar o IPCA dos próximos 12 meses, está fazendo IA preditiva (ou modelagem estatística clássica, dependendo de quem fala): o modelo recebe uma série numérica e devolve uma estimativa pontual, em geral com intervalo de confiança. O output é um número. O LLM faz IA generativa: a saída é uma sequência de tokens, que costuma virar texto, código ou imagem. Embora a mecânica também seja preditiva (o próximo token), o resultado útil é a sequência inteira, não uma estimativa pontual, e por isso a aplicação típica muda. Predictive ajuda a decidir um número (preço, demanda, risco); generative ajuda a produzir um artefato (relatório, script, resumo).

Os dois convivem. Um pipeline real pode ter um ARIMA gerando a projeção e um LLM redigindo o parágrafo do relatório que comenta a projeção.

4 As três fases do treinamento

Prever o próximo token só funciona se o modelo já tiver visto muito texto. O treinamento de um LLM grande passa por três fases distintas, cada uma resolvendo um problema diferente.

Cada fase tem um custo radicalmente diferente. O pré-treino custa dezenas a centenas de milhões de dólares de computação (milhares de GPUs por meses). O fine-tuning e o alinhamento custam ordens de magnitude menos, mas exigem mão de obra qualificada para gerar e avaliar exemplos. É por isso que pré-treinar do zero é raríssimo — quase todo mundo usa um modelo base pré-treinado por uma das poucas empresas com capital para isso (Anthropic, OpenAI, Google, Meta, Mistral, DeepSeek).

4.1 Quando o aprendizado para

conhecimento do modelo congela no fim do pré-treino, num marco chamado knowledge cutoff. O Claude Sonnet 4.6, por exemplo, tem cutoff em algum momento de 2025, e eventos posteriores ele simplesmente não conhece.

Perguntar “qual a Selic atual?” para um LLM puro, sem ferramenta de busca, equivale a pedir um chute baseado no que era verdade meses ou anos atrás, e a resposta pode soar confiante mesmo estando completamente errada — esse é o cenário-mãe da alucinação.

5 A infraestrutura

Treinar um LLM e servir um LLM são operações distintas, com restrições diferentes.

Treino acontece uma vez, num cluster gigante, e produz um conjunto de pesos: bilhões de números que codificam tudo o que o modelo aprendeu. Esses pesos são gravados em arquivo, com centenas de gigabytes nos modelos de fronteira, e ficam parados até alguém querer usar.

Inferência é o que acontece a cada pedido seu. Servidores especializados carregam os pesos na memória da GPU e, para cada requisição, executam o loop de previsão de token. O custo computacional é alto porque uma resposta de mil tokens passa todos os bilhões de pesos pela sequência de entrada várias vezes, o que explica o preço por token e o limite da janela de contexto: cada token adicional aumenta o trabalho.

Você nunca conversa "com o modelo" no sentido literal. Conversa com um servidor de inferência que carrega o modelo e processa o seu pedido. O modelo em si — os pesos — é o mesmo para todos os usuários do mundo naquele momento. O que muda é o contexto que cada um manda.

6 Prompt engineering: a primeira tentativa de controlar o modelo

Quando os LLMs começaram a ficar úteis (GPT-3 em 2020, ChatGPT no fim de 2022), ficou claro que a qualidade da resposta dependia muito de como você perguntava, e em torno disso surgiu uma disciplina improvisada chamada prompt engineering, que catalogou as técnicas que ajudavam o modelo a responder melhor.

6.1 Zero-shot, few-shot, many-shot

A taxonomia mais antiga e mais usada classifica os prompts pelo número de exemplos que você dá antes da pergunta de verdade.

A intuição é direta: como o modelo está prevendo o próximo token, se você mostrar três exemplos de “vendi 10 unidades → 10” antes de “vendi quinze unidades →”, a previsão mais provável passa a ser “15”. Você não treinou o modelo, só inclinou a distribuição de probabilidade dele.

6.2 Chain-of-thought e variantes

Em 2022 a pesquisa mostrou que pedir explicitamente para o modelo mostrar o raciocínio passo a passo antes de chegar à resposta melhorava muito a acurácia em problemas de matemática e lógica. A técnica ganhou nome (chain-of-thought prompting) e virou padrão, na versão minimalista bastando acrescentar “pense passo a passo” ao prompt.

Modelos mais novos fazem chain-of-thought por padrão em problemas que pedem, sem você precisar instruir, e essa observação deu origem a uma classe inteira de reasoning models (Claude com extended thinking, OpenAI o-series, DeepSeek R1) que dedicam um bloco grande de tokens ao raciocínio interno antes de responder.

6.3 Outras técnicas que pegaram

A literatura de prompt engineering acumulou dezenas de técnicas, e as mais úteis no dia a dia são:

  • Persona — abrir com “você é um economista sênior” muda o estilo da resposta.
  • Output estruturado — pedir resposta em JSON, em tópicos ou em tabela específica força um formato.
  • Self-consistency — gerar várias respostas com temperatura alta e ficar com a maioria.
  • Decomposição — quebrar uma tarefa grande em sub-tarefas e perguntar uma por vez.

Tudo isso continua funcionando. O que mudou foi a percepção de que prompt engineering é um pedaço pequeno do problema maior: o prompt é só a última coisa que entra na janela de contexto, e tem muita coisa mais antes dele.

7 O problema da alucinação

LLM alucina: produz texto fluente, gramaticalmente correto e factualmente errado, com a mesma confiança com que produz texto factualmente correto. O comportamento decorre de como o modelo funciona — ele está prevendo o token mais provável dada a sequência, não consultando uma base de dados.

Os três cenários típicos:

  • Fato fora do cutoff — o modelo chuta com base no que era verdade no treino. “Qual a Selic atual?” pode receber um número que estava certo dois anos atrás.
  • Fato muito específico — o modelo viu pouco sobre o assunto e mistura informações de fontes vizinhas. Pedir a bibliografia de um economista pouco famoso pode trazer papers que não existem, com coautores trocados.
  • Cálculo aritmético — sem ferramenta, o modelo “estima” o resultado de uma conta, e multiplicações de números grandes saem erradas com frequência.
Alucinação não é "às vezes o modelo erra". É estrutural. Qualquer pipeline que dependa de fatos atualizados ou específicos precisa de mecanismo para alimentar o modelo com os fatos certos no momento do pedido. Não dá para confiar que o modelo "sabe".

7.1 RAG: a resposta padrão da indústria

A solução mais comum chama-se RAG (Retrieval-Augmented Generation): em vez de torcer para o modelo lembrar, você busca os documentos relevantes antes e os cola no contexto junto com a pergunta.

A busca pode ser por palavra-chave clássica (BM25), por similaridade semântica via embeddings vetoriais, ou híbrida, e o princípio importante é o mesmo: o modelo responde sobre o que está no contexto, não sobre o que ele lembra. RAG transforma um chute estatístico em uma resposta ancorada em fontes.

RAG não elimina a alucinação (se a busca trouxer trecho errado, a resposta sai errada), mas reduz bastante, e abre a porta para o passo seguinte: se o modelo pode ler um documento que você buscou, por que não deixar que ele busque sozinho quando precisar?

8 De assistente para agente

Até aqui o modelo era passivo: você manda um prompt, ele responde, fim. A virada seguinte foi dar a ele a capacidade de acionar ferramentas durante a geração da resposta.

A mecânica é uma extensão direta do que já vimos. O modelo continua prevendo tokens, mas foi treinado para às vezes emitir uma sequência especial que o servidor interpreta como “quero chamar a ferramenta X com estes argumentos”. O servidor executa a ferramenta, devolve o resultado em forma de mais tokens no contexto, e o modelo continua respondendo.

Esse ciclo é o agentic loop: o modelo pensa, age, observa o resultado, pensa de novo. Por baixo continua o mesmo loop de previsão de token, com a particularidade de que alguns tokens disparam efeitos no mundo real e trazem dados de volta.

8.1 O que é “tool” na prática

Uma ferramenta, do ponto de vista do modelo, é uma tripla: nome, descrição do que ela faz e esquema dos argumentos. Quando o modelo é treinado com exemplos do tipo “quando o usuário pede X, é útil chamar a tool Y com argumento Z”, ele aprende a propor tool calls em situações análogas.

No Claude Code, as ferramentas built-in cobrem o trabalho local: Read (lê arquivo), Write (escreve arquivo), Edit (edita), Bash (roda comando no terminal), Grep (busca por texto), Glob (busca por padrão de nome). O agente decide qual chamar e com que argumentos, e cada chamada pede confirmação sua a menos que esteja na lista de permissões.

Por exemplo, MCP é o jeito padrão de ensinar ferramentas novas ao agente: sem MCP, cada serviço precisaria ser integrado código a código, enquanto com MCP basta apontar o servidor e o agente ganha um leque novo de ações.

9 Context engineering: escolher o que entra na janela

Os pedaços vistos até aqui se encaixam:

  • O modelo só responde com base no que está no contexto, ou seja, na sequência de tokens que ele recebe.
  • O conhecimento dele congela no cutoff, então fatos atuais precisam vir pelo contexto.
  • Prompt engineering ajusta o último pedaço (a pergunta), mas o contexto inclui muito mais coisa.
  • RAG injeta documentos no contexto; tools injetam resultados de ação no contexto; memória persistente injeta conversas anteriores no contexto.

Ao longo de 2024 e 2025, na prática profissional, foi se consolidando a percepção de que escolher o que entra na janela de contexto a cada chamada é a habilidade central, e esse ofício ganhou nome próprio: context engineering.

A definição que vem ficando consensual:

Context engineering é o trabalho de decidir, organizar e otimizar tudo o que o modelo lê antes de responder: instruções do sistema, documentos buscados, histórico relevante da conversa, descrições de ferramentas, formato esperado de saída, exemplos e a pergunta do usuário. Prompt engineering é um caso particular, o sub-conjunto que cuida da última mensagem do usuário.

9.1 O que vive na janela de contexto

A janela funciona como uma pilha de fatias, e cada chamada ao modelo monta essa pilha de novo, em tempo real.

Cada fatia compete por espaço. A janela do Claude Sonnet 4.6 hoje vai até 200 mil tokens (1 milhão na variante de contexto estendido), o que parece muito até você notar que um repositório médio de código fácil estoura esse limite. Daí o trabalho real:

  • O que merece estar lá em cima. Instruções gerais que valem sempre (CLAUDE.md, system prompt). São caras porque ocupam contexto em todas as chamadas, então precisam ser densas.
  • O que merece ser buscado a cada turno. Arquivos específicos via @-mention, resultado de ferramentas, trechos relevantes. Variam por interação.
  • O que pode ser resumido ou descartado. Histórico antigo — o Claude Code comprime turnos quando a janela enche, perdendo detalhe mas preservando direção.
  • O que nunca deve estar. Token desperdiçado em “olá, tudo bem?”, explicação repetida do que o agente já sabe, dump bruto de arquivo gigante quando só três linhas importam.

9.2 As alavancas do context engineering no Claude Code

Você já usou várias dessas alavancas sem dar nome a elas:

  • CLAUDE.md — sobe automaticamente como parte do system prompt e é onde você ensina o agente sobre o projeto. Densidade alta vale ouro porque entra em toda chamada.
  • @arquivo — inclusão pontual de conteúdo no contexto da pergunta, mais cirúrgico do que pedir “lê o projeto inteiro”.
  • /clear — zera o histórico. Quando você muda de tarefa, manter o que veio antes só polui a previsão de token.
  • /compact — resume o histórico em vez de jogar fora, e cabe quando você quer continuar mas o contexto começou a apertar.
  • MCP — amplia o leque de ferramentas e, portanto, o que o agente pode trazer para o contexto sob demanda.
  • Skills e subagentes — permitem que tarefas específicas rodem com prompt e contexto próprios, sem poluir a conversa principal.
Pensar a interação como context engineering muda a pergunta que você faz a si mesmo: em vez de "como reformulo este prompt", a pergunta passa a ser "o que precisa estar no contexto para que a resposta saia certa de primeira?". Quase sempre a resposta envolve colocar menos lixo e colocar a informação certa, não polir a frase final.

10 Onde estamos hoje

A comunidade técnica firmou alguns consensos provisórios:

  • Prompt mágico não existe. Não há frase secreta que multiplique a inteligência do modelo, e a maior parte do ganho vem da qualidade do contexto, não do floreio.
  • Tamanho de janela importa menos do que se pensava. Janelas maiores ajudam, mas um modelo com 1M de contexto mal-curado responde pior do que um com 200k bem-curado.
  • Tools mudaram o jogo. A maior parte do trabalho útil hoje envolve o modelo agindo (buscando, executando, escrevendo arquivo), não só respondendo, e agentes saíram do laboratório para o uso diário.
  • Alucinação não foi resolvida. Foi mitigada por RAG, tools e modelos melhores, mas continua sendo o risco operacional número um em qualquer pipeline que dependa de fato.
  • A fronteira de pesquisa virou agentic. Como dar mais autonomia ao modelo sem perder controle, como rodar agentes por horas, como avaliar a qualidade de um sistema agêntico — é o que ocupa labs e papers hoje.

O ofício de quem trabalha com IA generativa passou a girar em torno da engenharia de contexto e de agentes: o modelo é uma commodity cara acessada via API, e o diferencial está no pipeline montado em volta dele — o que entra no contexto, quais ferramentas o agente tem, como o loop é desenhado, como o erro é detectado.

No seu caso, dentro do Claude Code, isso significa uma coisa concreta: cada decisão que você toma (o que escrever no CLAUDE.md, o que @-mencionar, quando dar /clear, qual MCP ligar, quando ativar extended thinking, quando rodar um subagente) é context engineering. Vocabulário acadêmico à parte, é o trabalho do dia a dia.

11 Encerrando

O caminho até aqui passou por sete peças encaixadas: o modelo lê texto como sequência de tokens; aprende a prever o próximo token em três fases (pré-treino, fine-tuning e alinhamento); vive num servidor de inferência com conhecimento congelado no cutoff; alucina por construção; é mitigado por RAG e por ferramentas; vira agente quando ganha capacidade de chamar tools num loop. E todas essas peças dependem, no fim, do que entra na janela de contexto a cada turno.

A indústria deu nome a essa última camada — escolher e organizar o que entra na janela — e chama de context engineering. Da próxima vez que uma resposta do Claude vier morna ou errada, antes de reescrever o prompt, pergunte se o agente tinha em contexto o que precisava ter. Quase sempre o problema está aí.

Compartilhe esse artigo

Facebook
Twitter
LinkedIn
WhatsApp
Telegram
Email
Print
Análise Macro © 2011 / 2026

comercial@analisemacro.com.br – Rua Visconde de Pirajá, 414, Sala 718
Ipanema, Rio de Janeiro – RJ – CEP: 22410-002

como podemos ajudar?

Preencha os seus dados abaixo e fale conosco no WhatsApp