Como a Engenharia de Contexto Reduz o Gasto de Tokens
Engenharia de contexto é a disciplina de decidir o que realmente entra em um prompt antes que ele chegue ao Claude.
Ela se situa a montante da formulação do prompt e da seleção do modelo, e é frequentemente a maior alavanca que uma equipe tem sobre o custo da API.
Uma equipe que escreve um ótimo prompt, mas cola um repositório inteiro, já perdeu a maioria das economias disponíveis.
Esta página constrói o modelo mental por trás de três técnicas que recorrem ao longo desta seção: prompts de contexto mínimo, sumarização e segmentação de modelos.
Cada uma delas reduz o gasto de tokens, e cada uma o faz através de um mecanismo diferente, então vale a pena entendê-las como alavancas distintas, em vez de uma ideia turva de "ser eficiente".
Resumo
- Ideia Central: O gasto de tokens é uma função do que você escolhe enviar ao Claude, não apenas de como você formula a solicitação, portanto, aparar, condensar e rotear o contexto são todos controles de custo diretos.
- Por que Importa: Tokens de entrada são cobrados em cada chamada, e contextos grandes também atrasam as respostas e podem diluir a atenção do modelo nas partes que importam.
- Conceitos-Chave: prompts de contexto mínimo, sumarização, segmentação de modelos, aparo de grafo de dependência, orçamento de janela de contexto.
- Quando Usar: Qualquer sistema de produção que envia mais do que algumas centenas de tokens de material de apoio por chamada, especialmente loops de agente, pipelines RAG e assistentes de código.
- Limitações / Compromissos: Cortar o contexto agressivamente demais pode remover informações que o Claude realmente precisava, então cada técnica aqui troca algum risco de sub-contexto por uma redução garantida no custo.
- Tópicos Relacionados: aparo de grafo de dependência, sumarização pré-chamada, o parâmetro de esforço, deterioração do contexto (context rot).
Fundamentos
Cada solicitação ao Claude tem um custo que escala com o número de tokens de entrada e tokens de saída envolvidos.
Tokens de entrada incluem o prompt do sistema, o histórico da conversa, quaisquer documentos recuperados e quaisquer resultados de ferramentas injetados no contexto.
A maioria das equipes foca primeiro no comprimento da saída ou na escolha de um modelo mais barato, mas para muitas cargas de trabalho, o lado de entrada do balanço é maior e mais fácil de controlar.
Prompts de contexto mínimo é a prática de enviar apenas os trechos específicos que uma tarefa necessita, em vez do arquivo fonte completo, do documento completo ou do repositório completo de onde foi extraído.
Sumarização é a prática de usar um modelo barato e rápido para comprimir um documento longo em uma representação mais curta antes que essa representação seja enviada a um modelo mais caro para o trabalho real.
Segmentação de modelos é a prática de rotear uma solicitação para o modelo mais barato em uma linha, como o Claude Haiku 4.5, que ainda pode atender a um padrão de qualidade, e reservar um modelo mais forte como o Claude Opus 4.8 para as solicitações que realmente precisam dele.
Uma analogia simples: pense na janela de contexto do Claude como uma mesa.
Você pode empilhar o armário de arquivos inteiro na mesa para que nada esteja faltando, ou pode puxar apenas as pastas relevantes para a tarefa em mãos.
A segunda abordagem custa menos para preparar e também mantém a mesa utilizável.
# Uma chamada de contexto mínimo: apenas a função relevante, não o arquivo inteiro
prompt = f"""Revise esta função em busca de um bug de ponteiro nulo.
{relevant_function_source}
"""Mecânicas e Interações
Essas três técnicas agem em diferentes pontos do ciclo de vida de uma solicitação, e entender onde cada uma se encaixa esclarece quando usá-la.
Prompts de contexto mínimo agem no tempo de montagem: antes de construir a string do prompt, você decide quais trechos, linhas ou parágrafos são relevantes e exclui o resto.
Esta é geralmente a técnica de maior alavancagem porque remove tokens inteiramente em vez de comprimi-los, então não há chamada de API secundária e nenhum custo de compressão.
O compromisso é que requer algum trabalho inicial para saber o que é relevante, seja uma etapa de busca, um grafo de dependência ou um índice de recuperação.
Sumarização age no tempo de pré-processamento: um documento longo existe, é muito grande ou muito desfocado para ser enviado inteiro, e um modelo mais barato o reduz antes que o modelo caro o veja.
Isso adiciona uma chamada de API extra, mas essa chamada usa um modelo barato, então o custo líquido ainda é menor do que enviar o documento completo para o modelo caro.
A sumarização é mais valiosa quando o mesmo documento longo será referenciado em muitas chamadas, porque o custo de sumarização é pago uma vez e as economias se acumulam.
Segmentação de modelos age no tempo de roteamento: para cada solicitação de entrada, uma decisão é tomada sobre qual modelo na linha deve lidar com ela.
def choose_model(task_complexity: str) -> str:
if task_complexity == "simple_lookup":
return "claude-haiku-4-5"
if task_complexity == "standard_reasoning":
return "claude-sonnet-5"
return "claude-opus-4-8" # raciocínio multi-etapas, saída de alto riscoAs três técnicas compõem bem juntas.
Um pipeline pode usar prompts de contexto mínimo para selecionar arquivos relevantes, sumarização para condensar qualquer arquivo que ainda esteja muito longo e segmentação de modelos para decidir se a chamada final precisa do Sonnet 5 ou pode ser executada no Haiku 4.5.
Nenhuma delas requer as outras, mas empilhá-las produz economias multiplicativas, não aditivas, porque cada técnica reduz uma dimensão diferente do gasto.
Considerações Avançadas e Aplicações
Em escala, essas técnicas deixam de ser truques isolados e se tornam decisões de política que uma equipe documenta e revisita.
Um orçamento de janela de contexto, por exemplo, define um teto rígido sobre o quanto de contexto um agente tem permissão para acumular antes que algo precise ceder, seja sumarização, truncamento ou o fim da sessão.
Decisões de segmentação de modelos se beneficiam de uma lista de verificação explícita em vez de chamadas ad hoc, porque "esta tarefa precisa de Opus" é uma pergunta que engenheiros diferentes responderão de forma inconsistente sem critérios compartilhados.
Prompts de contexto mínimo para tarefas de código escalam ainda mais com grafos de dependência: em vez de escolher trechos manualmente, um grafo de importações e chamadas mostra exatamente quais arquivos são estruturalmente relevantes para uma alteração, o que escala para grandes bases de código de uma forma que a seleção manual não faz.
Vale a pena ser honesto que todas as três técnicas podem ser levadas longe demais.
Remover muito contexto, comprimir demais um documento ou rotear uma tarefa genuinamente difícil para um modelo barato produz uma economia de custo que é paga em respostas erradas, e uma resposta errada que precisa ser reexecutada é mais cara do que os tokens que foram economizados.
| Técnica | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Prompts de contexto mínimo | Remove tokens inteiramente, sem chamada extra | Requer saber o que é relevante | Revisão de código, Q&A direcionada, RAG |
| Sumarização | Comprime documentos longos reutilizáveis | Adiciona uma chamada, pode perder nuances | Documentos longos referenciados repetidamente |
| Segmentação de modelos | Combina custo com dificuldade da tarefa | Nível errado degrada a qualidade | Cargas de trabalho de alto volume e dificuldade mista |
O fio condutor em todas as três é que são decisões tomadas antes da chamada do modelo caro, não depois.
Otimizar a formulação de um prompt depois que o contexto já está inchado recupera muito menos custo do que decidir o que pertence ao prompt em primeiro lugar.
Conceitos Equivocados Comuns
- "Uma janela de contexto maior significa que não preciso aparar o contexto." Uma janela maior muda o que você pode enviar, não o que você deve enviar; contexto desnecessário ainda custa tokens e ainda pode degradar a qualidade da resposta.
- "Sumarização sempre economiza dinheiro." Ela só economiza dinheiro quando o documento sumarizado é reutilizado em várias chamadas ou é grande o suficiente para que o custo da própria chamada de sumarização seja pequeno em comparação.
- "Segmentação de modelos significa sempre usar o modelo mais barato." Segmentação significa combinar custo com dificuldade; rotear uma tarefa genuinamente difícil para um modelo barato produz respostas erradas e reexecuções, que custam mais do que os tokens economizados.
- "Engenharia de contexto é apenas engenharia de prompt com um novo nome." Engenharia de prompt otimiza a formulação; engenharia de contexto decide qual informação entra no prompt em primeiro lugar, o que é uma decisão separada e anterior.
- "Aparar contexto é arriscado, então é mais seguro enviar tudo." Enviar tudo tem seu próprio risco: deterioração do contexto (context rot), onde material irrelevante degrada o foco do modelo no que importa, além do custo extra garantido.
FAQs
O que é engenharia de contexto, em uma frase?
Engenharia de contexto é decidir qual informação incluir em um prompt, em oposição a como formulá-la ou qual modelo deve recebê-la.
Engenharia de contexto é a mesma coisa que engenharia de prompt?
Não.
- Engenharia de prompt molda a formulação, instruções e estrutura.
- Engenharia de contexto molda qual material (trechos, documentos, histórico) é incluído.
- Os dois são complementares e geralmente aplicados juntos.
Qual das três técnicas devo implementar primeiro?
Prompts de contexto mínimo são geralmente o ponto de partida de maior alavancagem porque removem tokens diretamente sem chamada de API adicional, enquanto sumarização e segmentação exigem alguma infraestrutura para configurar.
Enviar mais contexto alguma vez prejudica a qualidade da resposta, não apenas o custo?
Sim.
- Contexto irrelevante ou excessivo pode diluir a atenção do modelo nos detalhes que realmente importam.
- Esse efeito é às vezes chamado de deterioração do contexto (context rot), e significa que aparar o contexto é uma alavanca de qualidade, não apenas uma alavanca de custo.
Como a sumarização realmente economiza dinheiro se requer uma chamada de API extra?
A chamada de sumarização usa um modelo barato e rápido, enquanto o documento original seria de outra forma enviado na íntegra para um modelo mais caro em cada uso; quando um documento é referenciado muitas vezes, o custo barato único de sumarização é muito menor do que o custo repetido de enviar o documento completo.
O que é segmentação de modelos na prática?
Segmentação de modelos roteia cada solicitação para o modelo mais barato na linha do Claude, como o Haiku 4.5, que ainda pode atender ao padrão de qualidade exigido, reservando modelos mais fortes como Sonnet 5 ou Opus 4.8 para tarefas que genuinamente precisam de raciocínio mais profundo.
Essas técnicas podem ser combinadas?
Sim, e combiná-las é típico em sistemas de produção.
- Prompts de contexto mínimo estreitam o que é enviado.
- Sumarização comprime tudo o que ainda está muito longo.
- Segmentação de modelos decide qual modelo lida com a solicitação resultante.
O que é um grafo de dependência e por que ele se relaciona com a engenharia de contexto?
Um grafo de dependência mapeia quais arquivos ou módulos um trecho de código importa ou chama; enviar esse grafo mais apenas os trechos relevantes mantém um prompt relacionado a código focado, em vez de colar um repositório inteiro.
Existe o risco de aparar o contexto agressivamente demais?
Sim.
- Se informações relevantes forem excluídas, o modelo pode produzir uma resposta errada ou incompleta.
- Uma resposta errada que precisa ser corrigida ou reexecutada geralmente custa mais do que os tokens que foram economizados ao aparar.
Como o parâmetro de esforço se relaciona com a engenharia de contexto?
O parâmetro de esforço controla quanto raciocínio o modelo aplica a um determinado prompt; é uma alavanca separada do tamanho do contexto, mas ambos são varridos e avaliados da mesma forma, de uma configuração barata até a mais forte que ainda passa nas verificações de qualidade.
A engenharia de contexto se aplica fora de tarefas relacionadas a código?
Sim.
- Prompts de contexto mínimo se aplicam a qualquer documento recuperado, ticket de suporte ou linha de banco de dados, não apenas código fonte.
- Sumarização se aplica a qualquer texto longo: transcrições, relatórios, documentos legais.
- Segmentação de modelos se aplica a qualquer classificação de dificuldade de tarefa, independentemente do domínio.
Qual é o maior erro que as equipes cometem ao tentar reduzir o gasto de tokens?
Otimizar a formulação do prompt antes de abordar o que está incluído no prompt; mudanças na formulação economizam uma pequena porcentagem, enquanto as decisões de contexto geralmente respondem pela maioria do gasto.
Como sei se meu sistema precisa de engenharia de contexto?
Se seus prompts incluem regularmente arquivos completos, documentos completos ou históricos de conversa completos em vez das partes específicas relevantes para a solicitação atual, há muito provavelmente espaço para reduzir o gasto sem alterar a escolha do modelo.
Relacionados
- Noções Básicas de Engenharia de Prompt e Contexto - um guia prático para aparar um prompt inchado e medir as economias.
- Aparando Contexto: Grafos de Dependência em Vez de Repositórios Completos - aplica prompts de contexto mínimo especificamente a tarefas de código.
- Sumarização Antes da Chamada - um olhar mais aprofundado sobre pré-condensar documentos longos com um modelo barato.
- Lista de Verificação de Segmentação de Modelos - critérios concretos para escolher entre Haiku, Sonnet e Opus.
- Deterioração do Contexto: Por Que Mais Tokens Não Significam Melhores Respostas - o argumento do lado da qualidade para a mesma disciplina abordada aqui.
Versões da Pilha: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5 - e o SDK oficial
anthropicpara Python (última versão 0.x). Nomes de modelos, preços e versões de SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.