O Que é Context Engineering e Como Aplicá-la

Um assistente de código com IA gera uma função para lidar com uploads de usuários. O código parece certo, compila e passa em todos os testes. Você faz o merge. Dois dias depois, chega um bug de alta prioridade. Arquivos de usuários do plano premium estão sendo processados pela fila padrão, mais lenta. O código gerado chamou a função genérica `enqueue_job()` porque não tinha ideia de que existia uma utility `priority_enqueue_job()` para papéis específicos de usuário. O código estava correto, mas errado para o sistema.

Esse é o teto que a maioria dos times atinge com LLMs. A capacidade de raciocínio do modelo é boa, mas ele é quase totalmente ignorante da realidade operacional do seu sistema. Resolver isso exige uma abordagem no nível de sistema. Isso é context engineering: o processo de selecionar e estruturar a informação certa para dar ao modelo, para que a saída não seja apenas plausível, mas correta dentro do seu ambiente específico.

 

O custo de modelos desconectados

Quando um modelo opera com contexto incompleto, ele produz saídas que são plausíveis, mas erradas. Esses erros são traiçoeiros porque passam pela análise estática e até por testes unitários básicos. São bugs de integração e de lógica que revelam um gap entre o mundo do modelo e a realidade da base de código.

Já vi isso acontecer de algumas formas. Um modelo sugere adicionar `axios` a um serviço Node.js, sem saber que já existe um client HTTP interno, reforçado, com tracing e tratamento de erro embutidos, que é obrigatório para todas as chamadas de rede. Um LLM refatora um método em Python para ganhar eficiência, mudando o tipo de dado de um valor de retorno pouco usado de `list` para `generator`. Os testes unitários do módulo local passam, mas um serviço downstream que consome essa saída agora falha em runtime porque espera poder chamar `len()` no resultado. Ou um modelo escreve uma query de banco de dados que funciona perfeitamente isoladamente, mas omite uma cláusula obrigatória `WHERE tenant_id = ?` porque não tem consciência da arquitetura multi-tenant do sistema.

Em cada caso, um desenvolvedor precisa intervir manualmente, descobrir o que o modelo deixou passar e rodar a tarefa de novo com a informação que faltava. Esse processo manual de reengenharia de contexto para cada requisição é um imposto de produtividade que não escala. É o que transforma uma ferramenta “10x” em uma ferramenta 1.1x com um alto custo de manutenção.

O que é context engineering

Engenharia de prompt foca em refinar as instruções dadas a um modelo, em formular corretamente o comando. Engenharia de contexto é sobre fornecer a informação operacional necessária para que o modelo execute esse comando corretamente. Um prompt engineer trabalha na mensagem `System:`. Um context engineer constrói os pipelines de dados que populam a mensagem `User:` com tudo que o modelo precisa saber.

Isso vai além de simplesmente jogar dados no prompt. É identificar as partes críticas de informação que definem os limites operacionais de uma tarefa. Essa informação deveria ser uma preocupação arquitetural de primeira classe, não um detalhe de última hora.

Principais limites do contexto operacional incluem:

• Pontos de dados relevantes: Em vez de todo o schema do banco, forneça os schemas das tabelas relacionadas à requisição do usuário. Em vez de todos os endpoints de API, entregue as specs OpenAPI dos serviços envolvidos.
• Histórico de interação do usuário: O que o usuário acabou de fazer? Qual erro ele acabou de ver? Qual é o papel dele e quais permissões isso concede?
• Variáveis de estado do sistema: Feature flags atuais, limites de rate de API de um serviço dependente, ou a carga em uma réplica de banco. Essa informação é volátil e existe fora da base de código.

Tratar contexto como um detalhe é o motivo pelo qual tantas integrações com IA parecem frágeis. Tratar como parte da arquitetura do sistema é como você torna essas integrações confiáveis.

Como gerenciar contexto

Uma abordagem sistemática de contexto significa identificar o que importa, desenhar como entregar isso e manter a informação atualizada.

Primeiro, você precisa mapear as categorias de informação que um modelo precisa para executar uma tarefa corretamente. Contexto de usuário inclui ID, permissões, preferências e atividade recente. O usuário é admin ou usuário padrão? Está em um plano free ou enterprise? Isso muitas vezes define quais regras de negócio aplicar. Contexto de domínio é a lógica e as restrições do seu negócio, como “Pedidos acima de $10.000 exigem uma etapa de aprovação manual”. Contexto operacional é o estado em tempo real do seu sistema, como limites de rate de API ou feature flags ativas. Esse é o tipo de contexto mais dinâmico. Por fim, contexto de interação é o estado da sessão atual, como perguntas anteriores em um chat ou a mensagem de erro do último teste que falhou.

Depois de saber o que você precisa, você tem que levar isso até o modelo. Existem alguns padrões, cada um com trade-offs diferentes de performance e complexidade. O método mais simples é o envio direto de parâmetros, onde você inclui contexto de curta duração, como um `session_id`, direto na chamada de API. Para informações mais persistentes, um context store como Redis pode armazenar perfis de usuário ou conjuntos de permissões, que sua aplicação recupera antes de chamar o modelo. Para buscar informação em grandes volumes de texto como documentação ou a base de código, Retrieval-Augmented Generation (RAG) pode encontrar os trechos mais relevantes para incluir. Parte do contexto pode até ser inferida a partir de eventos do sistema, como injetar automaticamente informações sobre um microserviço com alta latência.

O principal trade-off é entre completude e performance. Uma query completa de RAG pode adicionar 500ms de latência a uma requisição. Um contexto maior aumenta o custo de tokens e pode introduzir ruído que piora a performance do modelo. O objetivo é fornecer o contexto mínimo suficiente, não o máximo possível.

Contexto desatualizado é tão ruim quanto nenhum contexto. Um modelo que acha que uma função depreciada ainda está em uso vai gerar código que já chega quebrado. Assim como seus schemas de API, a estrutura do contexto que você fornece também muda, então você deve versionar seus objetos de contexto. É preciso monitorar o quão antiga está a informação e definir limites de desatualização. Isso não deveria ser manual. Conecte isso aos seus pipelines de CI/CD. Quando a documentação é atualizada, um hook pós-commit deve disparar a reindexação. Quando um novo microserviço é deployado, sua spec OpenAPI deve ser publicada automaticamente no seu context store.

Colocando em prática

Construir sistemas conscientes de contexto significa desenhar serviços onde a montagem de contexto é uma responsabilidade principal. Em vez de cada feature chamar o LLM diretamente, você pode ter um serviço central que coleta informações de diferentes fontes e fornece isso para outros serviços.

Isso também significa desenhar pensando em falha. O que acontece quando uma fonte de contexto não está disponível? O sistema deve degradar de forma controlada. Uma ferramenta de geração de código que não consegue acessar a base completa pode recusar fazer um refactor complexo e oferecer uma alternativa mais simples e segura. Ela deve sinalizar que a resposta está baseada em informação incompleta.

Você precisa medir o impacto. Acompanhe com que frequência a saída do modelo é aceita sem modificações versus quando exige mudanças manuais. Instrumente seus sistemas para registrar quando a falta de um tipo específico de contexto leva a um erro. Esses dados vão mostrar onde o contexto mais importa e onde vale investir em melhorar seus pipelines de recuperação.

Times que tratam IA como um problema de engenharia de prompt rapidamente entram em um loop de ajustar instruções e corrigir manualmente saídas plausíveis, mas erradas. Eles batem em um teto de confiabilidade.

Times que tratam IA como um problema de integração de sistemas, um problema de contexto, vão construir a infraestrutura para fornecer aos modelos a informação que eles precisam para serem realmente úteis. Eles vão destravar um nível mais alto de performance e confiabilidade.