O que é engenharia de contexto?

O prompt do sistema estabelece o contexto básico do agente: sua identidade, capacidades, restrições e diretrizes de comportamento. Ao contrário dos prompts do usuário, que mudam a cada interação, o prompt do sistema permanece relativamente estável e funciona como uma “personalidade” persistente e um manual de regras. Prompts de sistema eficazes equilibram três requisitos concorrentes: especificidade (clareza suficiente para evitar comportamentos ambíguos), flexibilidade (amplitude suficiente para lidar com cenários diversos) e concisão (breve o suficiente para economizar espaço na janela de contexto). As práticas recomendadas incluem:

• Definindo explicitamente o papel do agente ("Você é um assistente de analista financeiro...")
• Apresentar exemplos concretos de comportamento desejado em vez de regras abstratas.
• Usar delimitadores estruturados (tags XML, seções de markdown) para organizar instruções e facilitar a compreensão do modelo
• Posicionar restrições críticas (regras de segurança, requisitos de formato) em locais de destaque, já que modelos exibem viés posicional

Técnicas avançadas incluem instruções condicionais que ativam com base no contexto de execução (como “Se o usuário perguntar sobre informações pessoais, redirecione para a política de privacidade”) e metainstruções que orientam o processo de raciocínio do agente (como “Pense passo a passo antes de fornecer a análise”). O prompt do sistema é particularmente vulnerável à competição dentro da janela de contexto; à medida que o histórico da conversa, saídas de ferramentas e dados recuperados se acumulam, prompts mal projetados acabam sendo deslocados da atenção efetiva do modelo, causando um desvio comportamental em que o agente gradualmente “esquece” suas instruções centrais.

A memória de longo prazo permite que a IA retenha informações entre sessões ou conversas. Diferentemente da memória de curto prazo, que é temporária e se perde ao fim da sessão, a memória de longo prazo possibilita que a IA recorde preferências do usuário, interações passadas e fatos aprendidos para uso futuro.

Estado e histórico constituem a memória de trabalho do agente na sessão atual: o registro do que foi dito, feito e aprendido em uma interação contínua. Essa memória de curto prazo possibilita a continuidade da conversa; o agente pode referenciar trocas anteriores sem forçar os usuários a repetir o contexto. No entanto, o histórico das conversas cresce linearmente com o tempo de interação, consumindo rapidamente a janela de contexto.

A engenharia de contexto eficaz requer estratégias ativas de gerenciamento de memória. A sumarização comprime trocas mais antigas em representações concisas, preservando fatos e decisões essenciais. O uso de janelas mantém apenas as N mensagens mais recentes, descartando o histórico anterior com base na suposição de que o contexto recente é o mais relevante. A retenção seletiva aplica heurísticas para identificar e preservar informações essenciais, como preferências do usuário, fatos estabelecidos e perguntas em aberto, ao mesmo tempo que elimina trechos rotineiros de conversa.

Abordagens mais avançadas usam estruturas de memória episódica, em que o agente registra um estado importante em um armazenamento externo e o recupera sob demanda, imitando a forma como humanos não mantêm toda a conversa na memória ativa, mas conseguem recordar detalhes específicos quando necessário. O desafio é manter a coerência; uma poda agressiva faz o agente “esquecer” pontos importantes e repetir erros, enquanto uma compressão insuficiente leva ao excesso de contexto e à queda de desempenho.

A Retrieval-Augmented Generation (RAG) envolve o modelo recuperar dados externos “no momento exato” de uma base de conhecimento, como documentos internos da empresa ou sites públicos. A RAG permite que o modelo responda com informações que não faziam parte de seu treinamento original, garantindo respostas atualizadas e precisas.

A fragmentação semântica melhora a recuperação ao estruturar as informações de forma lógica. Em vez de dividir o texto em partes arbitrárias de tamanho fixo, a fragmentação semântica agrupa conceitos relacionados, como por parágrafos, funções ou seções lógicas. Quando um trecho relevante é recuperado, seu entorno imediato também é incluído. Isso oferece ao modelo um contexto mais coerente e completo, ajudando-o a raciocinar com mais eficácia e reduzindo problemas de informação fragmentada.

A busca híbrida é essencial para a engenharia de contexto, pois depender de um único método de recuperação costuma falhar. A busca vetorial é ótima para encontrar informações conceitualmente semelhantes (por exemplo, “roupas de verão” para localizar “peças para clima quente”), mas pode perder termos específicos. A busca por palavras-chave (como BM25) é excelente para localizar correspondências exatas, como “SKU-123AB”, mas falha com sinônimos. Ao combinar ambas em uma consulta unificada, a busca híbrida garante ao modelo um contexto mais equilibrado e preciso, capturando tanto a intenção conceitual do usuário quanto termos críticos.

O reranking resolve o dilema entre velocidade e precisão inerente à recuperação em larga escala. A busca inicial, como a híbrida, é otimizada para recuperar rapidamente um grande conjunto de documentos potencialmente relevantes (como os 100 primeiros). Em seguida, um modelo de reranking — geralmente mais caro computacionalmente, porém muito mais preciso — é usado para reclassificar apenas esse subconjunto menor. Para a engenharia de contexto, isso é fundamental porque garante que os trechos mais relevantes e de maior qualidade apareçam no topo da janela de contexto, o que é essencial para mitigar o problema do “perdido no meio” e manter a atenção do modelo nas informações certas.

As ferramentas ampliam as capacidades de um agente além da geração de texto, permitindo a interação com sistemas externos, como executar código, consultar bancos de dados, chamar APIs ou manipular arquivos. Do ponto de vista da engenharia de contexto, as ferramentas criam um desafio específico: cada ferramenta exige uma descrição (nome, objetivo, parâmetros e exemplos de uso) que consome espaço na janela de contexto. Conforme as bibliotecas de ferramentas crescem, esse “sobrecusto de contexto” se torna significativo. Um agente com 100 ferramentas pode gastar de 30%–40% da janela de contexto apenas descrevendo suas capacidades antes mesmo de o usuário iniciar a tarefa.

A engenharia eficaz de ferramentas segue alguns princípios:

• Mantenha as descrições devem ser concisas, mas sem ambiguidades: incluindo o objetivo da ferramenta, parâmetros obrigatórios com seus tipos e um exemplo canônico.
• Crie ferramentas que possam ser compostas: ferramentas menores e focadas (como "search_documents" e "summarize_text") se combinam com mais flexibilidade do que ferramentas monolíticas que tentam cobrir vários cenários.
• Implemente categorias de ferramentas ou espaços de nome que permitam o carregamento seletivo: um agente que trabalha com análise financeira não precisa de ferramentas de processamento de imagens.
• Filtre os resultados das ferramentas: retorne apenas as informações essenciais ao agente, não as respostas brutas de APIs. Uma ferramenta de consulta a banco de dados deve retornar algo como “Foram encontradas 3 transações relevantes, totalizando US$ 4.532”, em vez de conjuntos completos de resultados SQL.

Ferramentas bem projetadas também incluem tratamento de erros nas suas descrições, ensinando o agente a se recuperar de falhas de maneira elegante, em vez de espalhar erros pelo fluxo de trabalho.

Busca agêntica

O buscar agentic é uma ferramenta especializada chamada "subagente" que realiza explorações complexas e em múltiplas etapas em seu próprio contexto isolado. Por exemplo, ele pode traduzir uma solicitação de linguagem natural em uma consulta ESQL precisa, localizar os dados e retornar apenas um resumo conciso ao agente principal, mantendo sua memória de trabalho limpa.

Fluxos de trabalho específicos de domínio

Fluxos de trabalho específicos de domínio são cadeias determinísticas de ferramentas definidas para processos empresariais de alto risco e alta previsibilidade, em que confiabilidade e consistência são mais importantes que flexibilidade exploratória. Diferentemente de agentes de uso geral, que raciocinam dinamicamente em cada etapa, esses fluxos seguem uma sequência rígida e validada. Exemplos incluem “Verificar identidade do cliente → Consultar histórico de crédito → Triagem regulatória externa → Calcular pontuação de risco → Gerar relatório de conformidade”. Cada etapa conta com critérios de sucesso explícitos, tratamento de erros e procedimentos de reversão.

Essa rigidez é intencional; ela evita que a imprevisibilidade inerente ao raciocínio baseado em LLM afete operações essenciais, como aprovações financeiras, diagnósticos médicos ou conformidade regulatória. Do ponto de vista da engenharia de contexto, os fluxos de trabalho de domínio simplificam a tarefa do agente ao reduzir graus de liberdade. O agente não precisa de contexto sobre todas as ferramentas e estratégias possíveis, apenas das informações específicas necessárias para a etapa atual do fluxo de trabalho. Esse contexto focado melhora tanto a precisão quanto a eficiência.

A implementação geralmente usa máquinas de estado ou gráficos acíclicos direcionados (DAGs), nos quais o LLM lida com elementos variáveis, como interpretar entradas do usuário, selecionar fontes de dados ou gerar resumos em linguagem natural, enquanto a lógica determinística controla o fluxo geral do processo. A desvantagem é menor adaptabilidade: esses fluxos funcionam excepcionalmente bem em cenários conhecidos, mas têm dificuldade com casos-limite que escapam do caminho pré-definido.

Descoberta Dinâmica de Ferramentas

A descoberta dinâmica de ferramentas resolve o problema de “inchaço do prompt” que ocorre quando agentes têm acesso a grandes bibliotecas de ferramentas. Em vez de listar centenas de descrições de ferramentas no prompt do sistema — o que consome espaço valioso na janela de contexto e reduz a precisão na seleção de ferramentas — essa estratégia usa busca semântica sobre metadados das ferramentas para recuperar apenas as capacidades relevantes em tempo de execução.

Quando um agente recebe uma tarefa, ele consulta o registro de ferramentas usando a descrição da tarefa como entrada e recupera as três a cinco ferramentas mais semanticamente relacionadas. Essa abordagem espelha a recuperação de dados sob demanda: as ferramentas permanecem em armazenamento externo até serem necessárias, preservando a atenção do agente para apenas o que é realmente útil, em vez de dispersá-la por um catálogo exaustivo. Protocolos como Protocolo de Contexto do Modelo (MCP) padronizam esse modelo ao fornecer registros nos quais as ferramentas podem ser descobertas, compreendidas e acionadas dinamicamente. No entanto, a descoberta dinâmica introduz latência, já que envolve a própria operação de busca, e exige uma engenharia cuidadosa para evitar que o agente selecione ferramentas inadequadas ou siga caminhos improdutivos quando as descrições forem ambíguas.

O prompt do usuário é a entrada direta que aciona o comportamento do agente e define o contexto imediato da tarefa. Diferentemente do system prompt, que permanece relativamente estável, o prompt do usuário varia a cada interação e recebe o maior peso de atenção na maior parte das arquiteturas de LLM. Esse viés posicional faz com que prompts do usuário muitas vezes prevaleçam sobre informações conflitantes em outras partes do contexto.

Uma engenharia de contexto eficaz trata prompts do usuário como mais do que simples perguntas; eles podem incluir pistas explícitas de contexto, como marcações de tempo, preferências do usuário ou estado da sessão, que orientam a recuperação e a seleção de ferramentas sem sobrecarregar o system prompt. Para agentes com estado, o prompt do usuário se torna o ponto de entrada onde informações específicas da sessão são injetadas (por exemplo, “dada nossa conversa sobre métricas trimestrais ...” sinaliza para o agente priorizar dados financeiros recuperados recentemente). No entanto, prompts do usuário também representam o elemento mais imprevisível do contexto e podem ser ambíguos, contraditórios ou adversariais. A engenharia de contexto precisa lidar com essa variabilidade por meio de modelos de compreensão de consultas que reformulam pedidos pouco claros, filtros de segurança que detectam tentativas de injeção de prompt e estratégias de fallback quando a intenção do usuário não pode ser inferida com confiabilidade.

Saída estruturada refere-se a informações que a IA precisa formatar de uma maneira específica, como JSON, XML ou uma tabela. Ao definir uma saída estruturada, as respostas da IA se tornam consistentes e fáceis de usar por outros sistemas ou programas.

Para uma exploração mais aprofundada desses conceitos, consulte o post completo: Visão geral de engenharia de contexto.

A prática da engenharia de contexto é melhor compreendida como o desenho de um pipeline sistemático criado para dar suporte ao LLM. Em vez de simplesmente combinar componentes de forma ad hoc, esse pipeline é adaptado a uma tarefa específica e projetado para gerenciar todo o fluxo de informação para e a partir do modelo em cada estágio do ciclo. Esse pipeline normalmente é dividido em três etapas centrais:

1. Recuperação e geração de contexto: Esse estágio envolve a obtenção ativa de dados brutos de uma ampla gama de possíveis entradas, como a recuperação de documentos de um banco de dados vetorial, a consulta a um banco de dados SQL estruturado ou a realização de chamadas de API para serviços externos.
2. Processamento de contexto: depois de reunidas, as informações brutas são otimizadas. Isso envolve transformar os dados para maximizar a relação sinal-ruído usando técnicas como segmentação, sumarização, compressão e estruturação.
3. Gestão de contexto: essa etapa final determina como as informações são armazenadas, atualizadas e utilizadas ao longo de múltiplas interações. Ela é essencial para criar aplicações com estado e envolve estratégias tanto de memória de curto prazo (sessão) quanto de longo prazo (persistente).

A estratégia mais poderosa é manter informações fora da janela de contexto e recuperá-las “just in time”, quando o agente realmente precisa. Isso espelha o funcionamento humano: não memorizamos bibliotecas inteiras, usamos mecanismos de busca e sistemas de arquivamento para encontrar o que precisamos sob demanda.

Para um agente de IA, isso significa consultar uma base de conhecimento externa. No entanto, encontrar a informação correta é um desafio significativo. À medida que os dados crescem, a busca semântica simples pode se tornar pouco confiável. A seleção efetiva geralmente exige uma abordagem híbrida, combinando diversas técnicas de busca, como buscas por palavra-chave, semânticas e baseadas em grafos, para identificar o contexto exato necessário em conjuntos de dados vastos e complexos.

Essa estratégia fornece ao agente um local para descarregar informações escrevendo em uma memória externa, como um arquivo de “rascunho” ou um banco de dados dedicado. Por exemplo, um agente pode salvar seu plano de múltiplas etapas em um arquivo e consultá-lo depois, evitando que o plano seja descartado de uma janela de contexto já congestionada. Isso permite que o agente mantenha estado e acompanhe o progresso de tarefas longas sem sobrecarregar sua memória de trabalho.

Técnicas de compressão reduzem o número de tokens na janela de contexto enquanto preservam as informações essenciais.

• Sumarização: usa um LLM para destilar conversas longas ou documentos em resumos concisos. Por exemplo, a saída completa e pesada em tokens de uma ferramenta pode ser substituída por um breve resumo dos seus resultados.
• Redução: filtra o contexto usando regras codificadas, como remover as mensagens mais antigas de uma conversa ou limpar saídas de ferramentas redundantes que não são mais necessárias.

Para tarefas altamente complexas, um único agente pode ficar sobrecarregado. O isolamento envolve decompor o problema e atribuir subtarefas a “subagentes” especializados, cada um com sua própria janela de contexto limpa e focada. Um agente principal coordena esse time, recebendo apenas as saídas finais e destiladas de cada especialista. Essa abordagem mantém o contexto de cada agente relevante e administrável, melhorando o desempenho geral em tarefas complexas de pesquisa ou análise.

Ao seguir esses princípios, a engenharia de contexto busca fornecer ao LLM o menor conjunto possível de tokens de alto valor informacional, maximizando a probabilidade de um resultado relevante.

Na base de tudo, a engenharia de contexto é moldada por uma limitação fundamental: LLMs têm orçamentos de atenção finitos. A janela de contexto, medida em tokens, define a quantidade máxima de informações que um modelo consegue processar ao mesmo tempo. Mesmo que modelos modernos ofereçam janelas cada vez maiores, com 100 mil, 1 milhão ou até 2 milhões de tokens, simplesmente preencher esse espaço não garante um desempenho melhor.

Os LLMs operam com arquitetura de transformador, na qual cada token precisa “atender” a todos os outros. À medida que o contexto cresce, isso aumenta significativamente a carga computacional e gera o que profissionais chamam de “apodrecimento do contexto”: a capacidade do modelo de manter o foco e recuperar detalhes específicos diminui conforme o volume de informações aumenta. Esse fenômeno espelha limites cognitivos humanos, em que mais informação nem sempre significa decisões melhores.

Expandir a janela traz desafios importantes:

• Aumento de custo e latência: a complexidade computacional do mecanismo de atenção da arquitetura de transformador cresce de forma quadrática ($O(n^2)$) conforme o tamanho da sequência, o que torna contextos maiores exponencialmente mais caros e mais lentos.
• Degradação de desempenho ("perdido no meio"): LLMs apresentam forte capacidade de lembrar informações posicionadas no início ou no fim de uma janela de contexto longa, mas sofrem uma queda significativa de performance para informações situadas no meio.
• Ruído e distração: uma janela de contexto maior aumenta a probabilidade de incluir informações irrelevantes ou “ruidosas”, que podem distrair o modelo e degradar a qualidade do resultado. Isso costuma ser chamado de problema do "agulha no palheiro".

Esse paradoxo reforça a necessidade de uma curadoria inteligente, e não apenas força bruta, tornando a engenharia de contexto um trabalho quase artesanal.

O principal motivador da engenharia de contexto é garantir que um agente consiga concluir suas tarefas com sucesso e consistência. Sem um contexto preciso e relevante, e sem as ferramentas adequadas, um agente vai falhar ao alucinar, selecionar a ferramenta errada ou ser incapaz de executar um plano com múltiplas etapas. Esse é o problema central que a engenharia de contexto resolve.

A qualidade da saída em sistemas baseados em engenharia de contexto diz respeito ao quanto as respostas do agente se alinham à intenção do usuário, à precisão factual e aos requisitos da tarefa — diferente de fluência ou coerência, que os LLMs já produzem naturalmente. A alta qualidade da saída depende diretamente da alta qualidade do contexto de entrada; o princípio de “entra lixo, sai lixo” se aplica de forma direta.

A engenharia de contexto melhora a qualidade da saída por meio de vários mecanismos:

• A qualidade da recuperação garante que o agente acesse material de origem preciso e relevante, em vez de alucinar ou depender de dados de treinamento desatualizados.
• A estrutura do contexto influencia diretamente a capacidade do modelo de extrair e sintetizar informações.
• Um contexto bem segmentado e semanticamente coerente gera raciocínios mais precisos do que trechos fragmentados.
• A relação sinal-ruído também importa: incluir cinco documentos altamente relevantes produz melhores resultados do que incluir esses mesmos cinco mais outros vinte apenas marginalmente relacionados, já que informações irrelevantes desviam a atenção do modelo.

A qualidade da saída também depende da clareza das instruções no system prompt e de requisitos explícitos de formatação (saídas estruturadas como JSON reduzem erros de interpretação). Medir qualidade exige avaliação específica por tarefa: precisão factual para sistemas RAG, taxas de conclusão para agentes, índices de satisfação para sistemas conversacionais. A engenharia de contexto possibilita melhorias sistemáticas de qualidade ao tornar a relação entre entrada e saída observável e ajustável; você pode medir quais combinações de contexto produzem resultados superiores e, então, otimizar seleção, classificação e filtragem de acordo.

Cada token na janela de contexto tem um custo: recursos computacionais, cobranças de API e latência. A engenharia de contexto afeta diretamente todos os três:

• Otimização de custos: reduzir tokens desnecessários em prompts pode diminuir drasticamente os custos de API em aplicações de grande volume.
• Redução da latência: Contextos menores e mais focados significam tempos de inferência mais rápidos e aplicações mais responsivas.
• Melhoria da qualidade: contextos direcionados, com alto sinal, superam consistentemente despejos grandes e difusos de informação.

Os sistemas de IA de produção precisam ser resilientes. A má engenharia de contexto leva a diversos modos de falha:

• Envenenamento de contexto: quando alucinações ou erros são incorporados ao contexto e se acumulam em interações subsequentes.
• Desvio de objetivo: quando informações irrelevantes acumuladas fazem com que agentes percam de vista seus objetivos originais.
• Excesso de capacidade: quando informações críticas são truncadas porque a janela de contexto é preenchida com dados de menor prioridade.

Uma boa engenharia de contexto evita esses problemas por meio de validação, poda e gerenciamento estruturado de memória, tratando o contexto como um recurso cuidadosamente selecionado, e não como um acumulador passivo de informações.