Fundamentos LLM · MOFU · IT

Context Engineering: por que supera o prompt solto em aplicações B2B

Por Adriano Schneider · · 10 min de leitura

Sua equipe passou uma semana ajustando o prompt e o modelo ainda responde de forma inconsistente? O problema provavelmente não está no prompt — está no que vai em volta dele. Context engineering é a disciplina que separa projetos de IA que funcionam em produção daqueles que funcionam só no demo.

O que é a context window — e por que ela é tudo

Vou ser direto: um modelo de linguagem não tem memória entre chamadas. Cada vez que você envia uma mensagem, o modelo recebe um bloco de texto — chamado de context window — e gera uma resposta baseada exclusivamente no que está nesse bloco.

Pense na context window como uma lousa. Tudo que está escrito ali é o universo de conhecimento disponível para o modelo naquele instante. Se a lousa tiver lixo, o modelo trabalha com lixo. Se estiver bem organizada, com informações relevantes e bem estruturadas, o modelo trabalha com qualidade.

Em 2026, modelos como GPT-4o, Claude 3.5 Sonnet e Gemini 1.5 Pro suportam janelas de 128 k a 1 milhão de tokens. Para ter ideia, 128 k tokens são cerca de 90 mil palavras — o equivalente a um livro de 300 páginas. Isso soa como muito espaço. E é. Mas mais espaço não significa melhores respostas.

Em projetos meus com empresas de médio porte, vejo constantemente o mesmo erro: a equipe despeja contratos, manuais e histórico de chat bruto na janela, espera que o modelo "encontre" o que precisa, e depois estranha quando a resposta é vaga ou errada. O modelo não é um mecanismo de busca. Ele é um gerador de texto probabilístico. O que você põe dentro determina o que sai.

Prompt engineering vs context engineering — a diferença real

Prompt engineering ficou famoso entre 2022 e 2024. O conceito central: escrever instruções bem formuladas para extrair respostas melhores do modelo. "Aja como um especialista em tributação brasileira. Responda de forma objetiva. Use bullet points." Isso funciona — e continua sendo relevante.

Mas prompt engineering sozinho tem um limite claro: ele trata apenas das instruções, não do conteúdo que acompanha essas instruções. Context engineering é o nível acima: é a engenharia de tudo que entra na janela.

Context engineering envolve decisões sobre:

Um prompt brilhante numa context window mal construída produz resultados mediocres. Um prompt simples numa context window bem estruturada produz resultados consistentes. Essa é a virada de chave.

Tabela comparativa: Prompt Solto vs Context Engineering

Abaixo está o artefato que você leva deste artigo. Use como critério de avaliação para qualquer projeto de IA que sua equipe estiver construindo ou contratando.

Dimensão Prompt Solto Context Engineering
Foco principal Redação da instrução pontual Arquitetura de tudo que entra na janela de contexto
Consistência Baixa — pequenas variações no input geram respostas muito diferentes Alta — contexto estruturado reduz variância e aumenta previsibilidade
Escalabilidade Não escala — cada caso de uso exige novo prompt manual Escala — mudança de contexto adapta o comportamento sem reescrever lógica
Integração com dados Manual — informações coladas no prompt a cada chamada Sistêmica — RAG, APIs e bancos alimentam a janela de forma programática
Custo por token Alto — tende a enviar mais informação do que o necessário por falta de seleção Controlado — seleção e compressão reduzem tokens sem perder qualidade
Manutenção Artesanal — prompts documentados em planilha ou Notion, sem versionamento Engenheirada — context builders versionados em código, testáveis em CI/CD
Tratamento de erros Reactivo — erro descoberto em produção, corrido na mão Proativo — fallbacks, contexto de erro e instruções de recuperação são parte do design
Adequação para produção Adequado para POCs e demos Necessário para qualquer aplicação com usuários reais

Os componentes da context window que você precisa conhecer

Uma context window bem construída para aplicação B2B tem, tipicamente, estas camadas:

1. System prompt estruturado

Não é só "você é um assistente útil". Em produção, o system prompt define:

2. Memória de curto prazo — histórico gerenciado

Preservar todo o histórico de uma conversa longa é um erro clássico. Além de custar tokens, histórico extenso dilui a atenção do modelo. A solução: sumarização periódica. A cada N turnos, um sumarizador comprime o histórico antigo em um bloco compacto que substitui os turnos originais. O modelo mantém continuidade sem pagar pelo custo total.

3. Memória de longo prazo — recuperação semântica

Para o modelo "lembrar" de informações de sessões anteriores ou de uma base de conhecimento corporativa, usamos recuperação vetorial (o núcleo do RAG). O trecho recuperado entra na janela apenas quando é relevante para a consulta atual. Isso evita encher a janela com informação que o modelo não precisa.

4. Estado da tarefa

Em agentes que executam múltiplos passos, o contexto precisa incluir o estado atual: o que já foi feito, quais ferramentas foram chamadas, qual é o objetivo final. Sem isso, o agente "esquece" o que estava fazendo e recomeça — comportamento que vejo toda semana em POCs mal estruturados.

5. Exemplos few-shot selecionados dinamicamente

Em vez de incluir os mesmos 5 exemplos sempre, um sistema bem projetado seleciona exemplos semanticamente próximos da consulta atual. Isso melhora qualidade e economiza tokens quando a janela está apertada.

Exemplos práticos em contexto B2B

Caso 1: Análise de contratos

Uma empresa de logística queria extrair cláusulas de multa de contratos com fornecedores. A primeira tentativa foi um prompt simples: "Leia o contrato abaixo e liste as cláusulas de multa." Funcionou em 60% dos casos — o suficiente para animar no demo, insuficiente para usar em produção.

Com context engineering, reformulamos a abordagem:

  1. System prompt especificou o schema de saída (JSON com campos obrigatórios)
  2. Antes do contrato bruto, injetamos metadados: tipo de contrato, fornecedor, data
  3. Incluímos 2 exemplos few-shot de contratos parecidos com cláusulas já anotadas
  4. Adicionamos instrução de fallback: "Se não encontrar cláusula de multa explícita, retorne campo vazio e justifique"

Resultado: acurácia subiu de 60% para 94% nos mesmos contratos. Sem trocar o modelo, sem fine-tuning.

Caso 2: Assistente de vendas interno

Um distribuidor de insumos industriais queria que o assistente respondesse dúvidas sobre especificações de produto durante negociações. O problema: o catálogo tinha 12 mil SKUs e o modelo "inventava" especificações quando não sabia a resposta.

Com context engineering via RAG:

  1. Apenas os 5 trechos mais relevantes do catálogo entram na janela por consulta
  2. Cada trecho é acompanhado de metadado de fonte (nome do documento, versão, data)
  3. O system prompt instrui explicitamente: "Use apenas informações das fontes fornecidas. Se não encontrar a informação, diga exatamente isso."
  4. A resposta inclui referência à fonte usada

Alucinações caíram para praticamente zero. O assistente passou a dizer "não encontrei essa especificação no catálogo atual" em vez de inventar — comportamento que constrói confiança com o usuário.

Armadilhas comuns que destroem a qualidade do contexto

Context stuffing — encher por encher

A lógica é tentadora: "O modelo aceita 128 k tokens, vou colocar tudo." Não funciona. Pesquisas mostram que modelos têm atenção mais fraca para informações no meio de contextos longos (o fenômeno "lost in the middle"). Informação relevante enterrada no meio de muito conteúdo irrelevante é ignorada com frequência.

Conflito de instruções

Quando o system prompt diz uma coisa e os dados recuperados implicam outra, o modelo tende a se perder. Exemplo: system prompt pede resposta em português, mas os documentos estão em inglês e o usuário escreve em inglês. O modelo oscila entre idiomas. Resolução: hierarquia clara de instruções e dados normalizados antes de entrar na janela.

Histórico sem gestão

Conversa de suporte que começa com um problema técnico e evolui para outro tópico, com todo o histórico acumulando: o modelo começa a misturar contextos. Gestão de histórico com sumarização resolve. Custo estimado da sumarização: 5–10% do custo total da conversa.

Ignorar o contexto de erro

Quando uma ferramenta falha (API timeout, banco indisponível), o contexto precisa informar o modelo sobre o que aconteceu e o que fazer. Sem isso, o modelo tenta a mesma ação indefinidamente ou gera resposta sem sentido para o usuário.

Como começar a implementar context engineering na prática

Sem ser prescritivo demais — cada projeto tem suas particularidades — aqui está o caminho que sigo com os times que oriento:

  1. Mapeie as fontes de informação — O que o modelo precisa saber para responder bem? Liste todas as fontes: banco de dados, documentos, APIs externas, histórico do usuário.
  2. Defina o schema do contexto — Quais seções sempre estão presentes? Quais são opcionais? Em que ordem entram?
  3. Implemente como código, não como texto colado — O context builder deve ser uma função testável, não um processo manual. Versione junto com o restante do código.
  4. Meça antes e depois — Defina métricas de qualidade (acurácia, taxa de recusa, alucinação, latência) antes de começar. Medir o impacto de cada mudança no contexto é o que separa engenharia de achismo.
  5. Itere incrementalmente — Uma mudança no contexto por vez. Mudanças simultâneas impossibilitam isolar o que funcionou.

A relação entre context engineering, RAG e arquitetura geral

Context engineering não substitui nenhuma outra técnica — ele é a camada que integra tudo. O RAG fornece os dados relevantes; o context engineering decide como esses dados são apresentados ao modelo. A arquitetura SPEC-driven garante que as decisões sobre o contexto estejam documentadas e versionadas. O entendimento de como os LLMs raciocinam informa quais estruturas de contexto funcionam melhor para cada tipo de tarefa.

Em 2026, com modelos cada vez mais capazes, a diferença entre projetos que entregam valor e projetos que ficam no demo não está mais no modelo escolhido. Está na qualidade do contexto que chega a esse modelo.

Conclusão: contexto é o produto

Prompt engineering é uma habilidade. Context engineering é uma disciplina de engenharia. Para POCs e experimentos internos, prompt solto com ajustes manuais é suficiente. Para qualquer aplicação que precise funcionar com consistência, escalar e ser mantida por um time ao longo do tempo, context engineering não é opcional — é o núcleo do trabalho.

Se sua equipe está investindo semanas em ajustar prompts sem medir a qualidade do contexto ao redor, o diagnóstico é esse. E a boa notícia é que corrigir o caminho é mais rápido do que parece.