Contexto demais também atrapalha: quando a IA deixa de encontrar o que importa

Quando um Agente IA começa a responder incorretamente, uma das primeiras reações costuma ser adicionar mais informações.

Inclui-se outro documento na base de conhecimento, mais uma regra no prompt, um histórico maior de mensagens, novos exemplos de atendimento e mais dados sobre o cliente. A expectativa parece lógica: quanto mais o Agente souber, melhores serão as respostas.

Esse raciocínio confunde duas coisas diferentes: ter acesso a uma informação e receber essa informação em todas as interações.

Um Agente pode consultar centenas de documentos, milhares de produtos e anos de histórico sem carregar tudo isso sempre que responde. Quando todas essas informações entram simultaneamente no contexto do modelo, o conteúdo relevante começa a competir com regras antigas, exemplos desnecessários, resultados de ferramentas e trechos sem relação com a conversa atual.

Em alguns casos, o problema não é falta de conhecimento. O Agente sabe muito sobre a empresa, mas não consegue identificar com clareza o que precisa considerar naquele momento.

Contexto não é a mesma coisa que base de conhecimento

Para entender o problema, é preciso separar três conceitos.

A base de conhecimento representa o universo de informações que o Agente pode consultar. Ela pode conter políticas comerciais, catálogos, manuais, contratos, registros de clientes, perguntas frequentes e outros documentos da empresa. Organizar o que um Agente IA precisa saber antes de atender clientes continua sendo importante. A diferença está em como esse conhecimento chega ao modelo.

A memória preserva informações que precisam permanecer disponíveis ao longo do tempo, como preferências do cliente, decisões anteriores, etapas concluídas ou compromissos assumidos.

O contexto é o conjunto de informações efetivamente enviado ao modelo durante uma interação. Ele pode incluir o prompt do sistema, as mensagens recentes, documentos recuperados, resultados de ferramentas, dados do cliente e instruções sobre a tarefa atual.

A Anthropic descreve engenharia de contexto como o trabalho de selecionar e manter o conjunto de informações mais útil durante a execução do modelo. A pergunta deixa de ser apenas “como escrever um bom prompt?” e passa a incluir outra: qual combinação de informações aumenta a probabilidade de o Agente produzir o comportamento esperado?

O objetivo não é colocar todo o conhecimento da empresa dentro de cada solicitação. É permitir que o Agente encontre e utilize a informação certa quando ela for necessária.

Por que mais contexto não significa mais inteligência

As janelas de contexto dos modelos cresceram. Isso permite analisar documentos maiores, manter conversas mais longas e executar tarefas com várias etapas.

Ainda assim, uma janela maior não garante que o modelo utilizará todas as informações com a mesma precisão.

A documentação sobre janelas de contexto da Claude explica que tudo o que é enviado ocupa espaço: prompt do sistema, mensagens, documentos, imagens, resultados de ferramentas, definições das ferramentas e a própria resposta. A mesma documentação alerta que, conforme a quantidade de tokens cresce, precisão e recuperação de informações podem se deteriorar.

O modelo não consulta o contexto como um banco de dados tradicional, no qual uma busca retorna apenas os registros correspondentes. Ele precisa interpretar as relações entre os trechos recebidos e decidir quais deles devem influenciar a resposta.

Quanto maior o volume, maior a quantidade de elementos disputando a atenção do modelo. Por isso, a Anthropic recomenda buscar o menor conjunto de informações com sinais fortes o suficiente para produzir o resultado desejado.

Como o excesso de contexto prejudica um Agente

1. A informação relevante fica diluída

Imagine um Agente responsável por responder dúvidas sobre entregas.

O cliente pergunta:

“Meu pedido foi enviado ontem. Quando ele deve chegar?”

Para responder, o Agente provavelmente precisa da localização do cliente, da modalidade de envio, da data da postagem e do prazo informado pela transportadora.

Ele não precisa receber, ao mesmo tempo, o catálogo completo de produtos, as regras do programa de afiliados, os scripts de recuperação de carrinho, a política de garantia e dois anos de conversas anteriores.

Mesmo que esses documentos estejam corretos, eles não ajudam a resolver a pergunta atual. Eles aumentam a quantidade de conteúdo que o modelo precisa analisar antes de encontrar os poucos dados que realmente importam.

2. Regras diferentes começam a competir

Quanto mais instruções são acumuladas, maior é a possibilidade de existirem regras repetidas, desatualizadas ou contraditórias.

Um documento pode informar que o prazo de troca é de 30 dias, enquanto uma versão antiga ainda menciona 15. O prompt pode orientar o Agente a sempre solicitar o telefone do cliente, enquanto uma instrução adicionada depois determina que isso só deve acontecer após a qualificação.

Quando todas essas regras entram juntas no contexto, o modelo precisa decidir qual delas possui prioridade. Se a hierarquia não estiver clara, a resposta pode variar entre conversas aparentemente semelhantes.

Esse é um dos motivos pelos quais prompt não pode ser tratado como toda a operação. O problema não está apenas na quantidade de instruções, mas na ausência de governança sobre validade, prioridade e escopo.

3. O modelo pode perder informações no meio do conteúdo

O estudo Lost in the Middle, publicado na Transactions of the Association for Computational Linguistics, analisou como modelos utilizam informações distribuídas em contextos longos.

Os pesquisadores observaram que o desempenho frequentemente era melhor quando a informação relevante aparecia no começo ou no final do contexto e pior quando ela estava posicionada no meio. O resultado mostrou que aceitar entradas extensas não significa utilizar todas as partes dessas entradas com a mesma confiabilidade.

Na operação de uma empresa, isso significa que uma regra importante pode estar presente no contexto e, ainda assim, não influenciar adequadamente a resposta.

A equipe olha para o registro e conclui que o Agente “tinha a informação”. Tecnicamente, ela estava disponível. Na prática, estava cercada por tanto conteúdo que deixou de receber a atenção necessária.

4. Cada interação fica mais cara e lenta

Contextos maiores exigem o processamento de mais tokens. Em fluxos com várias etapas, ferramentas e subagentes, o mesmo conteúdo também pode ser reenviado diversas vezes.

Além do custo direto da inferência, surgem custos indiretos: consultas maiores, respostas mais demoradas, necessidade de modelos mais caros e maior dificuldade para investigar por que determinada informação foi utilizada.

O trabalho ACON, apresentado no ICML 2026, parte do problema de que Agentes de longa duração acumulam históricos de ações e observações. Nos experimentos, a compressão otimizada reduziu entre 26% e 54% o pico de tokens, preservando grande parte do desempenho e, em alguns cenários, melhorando os resultados de modelos menores.

Reduzir contexto não é apenas uma medida de economia. Em determinadas tarefas, também é uma estratégia de qualidade.

5. Estados antigos continuam acompanhando a conversa

Históricos longos podem preservar informações que já foram corrigidas.

Considere uma conversa em que o cliente inicialmente afirma que deseja o Plano Básico, mas depois decide contratar o Plano Profissional. Se todo o histórico for reenviado sem nenhuma organização, as duas intenções continuarão presentes.

O modelo precisará inferir que a informação mais recente substitui a anterior.

Esse problema se torna mais grave quando o histórico contém hipóteses levantadas pelo próprio Agente, resultados antigos de ferramentas ou dados que mudam com frequência, como disponibilidade de horários, estoque e valores.

Manter todo o histórico integralmente pode fazer com que estados antigos continuem influenciando decisões novas.

Ter acesso a tudo, carregar apenas o necessário

Uma arquitetura de contexto bem organizada pode ser dividida em quatro camadas.

Contexto fixo

O contexto fixo contém as informações que devem orientar praticamente todas as interações:

* identidade e função do Agente;

* limites de atuação;

* regras de segurança;

* critérios para transferência humana;

* padrão esperado de comunicação;

* instruções sobre o uso das ferramentas.

Mesmo essa camada precisa ser revisada. O prompt não deve se transformar em um arquivo no qual toda exceção encontrada é adicionada indefinidamente.

A recomendação é começar com o conjunto mínimo de informações que descreve completamente o comportamento esperado e adicionar instruções a partir de falhas observadas em testes. Também é melhor usar exemplos diversos e representativos do que acumular uma lista extensa de casos extremos.

Estado atual da conversa

Essa camada contém as mensagens necessárias para compreender a interação atual.

Em uma conversa curta, pode ser possível manter os turnos recentes integralmente. Em conversas longas, o sistema pode preservar as últimas mensagens e substituir o restante por um resumo estruturado.

Esse resumo não precisa recontar toda a conversa. Ele deve registrar o estado atual:

* intenção identificada;

* produto de interesse;

* informações já fornecidas;

* objeções levantadas;

* decisões tomadas;

* dados pendentes;

* próxima ação esperada;

* compromissos assumidos pelo Agente.

Assim, vinte mensagens de negociação podem ser transformadas em um pequeno conjunto de informações operacionais.

Informações recuperadas sob demanda

Documentos, produtos e regras específicas devem entrar no contexto quando a intenção da conversa indicar que são necessários.

Se o cliente pergunta sobre cancelamento, o Agente recupera a política de cancelamento. Se pergunta sobre um produto, recupera a ficha daquele produto. Se deseja marcar um horário, consulta a agenda naquele momento.

A Anthropic chama essa abordagem de recuperação just in time. Em vez de carregar todos os objetos previamente, o Agente mantém referências, identificadores e ferramentas para buscar informações conforme a tarefa avança.

Essa lógica também ajuda a decidir se uma resposta deve vir da base, de um sistema ou de uma ferramenta. A base pode continuar extensa sem transformar todas as interações em solicitações extensas.

Memória persistente

Algumas informações precisam sobreviver ao encerramento da conversa, mas não precisam permanecer dentro de todas as mensagens.

Preferências do cliente, decisões comerciais, etapas concluídas e dados importantes podem ser armazenados externamente. Depois, apenas os registros relacionados à tarefa atual são recuperados.

A memória preserva continuidade. O contexto decide o que precisa voltar para a conversa atual. Essa separação evita transformar o histórico do cliente em um bloco permanente de texto e ajuda a definir o que o Agente deve lembrar, registrar e esquecer.

Compactar não é simplesmente apagar mensagens

Quando uma conversa se torna longa, uma das alternativas é a compactação.

Nesse processo, partes anteriores do histórico são resumidas e substituídas por uma representação menor. Decisões, problemas pendentes e fatos relevantes são preservados. Repetições, mensagens intermediárias e resultados antigos de ferramentas podem sair.

A documentação de compactação da Claude apresenta esse mecanismo como uma forma de manter conversas longas focadas, substituindo conteúdo antigo por resumos que permitam continuar a tarefa.

A compactação exige cuidado. Um resumo agressivo demais pode eliminar um detalhe que parecia pouco importante no momento, mas que se tornaria necessário depois.

Uma boa compactação deve responder a quatro perguntas:

1. Qual é o objetivo atual?

2. O que já foi decidido?

3. Quais fatos continuam válidos?

4. O que precisa acontecer em seguida?

Ela não precisa preservar todas as palavras usadas para chegar até ali.

Um fluxo prático para selecionar o contexto

Antes de enviar informações ao modelo, o sistema pode seguir uma sequência simples.

1. Identificar a intenção principal da mensagem.

2. Determinar quais tipos de informação podem ser necessários para atender essa intenção.

3. Recuperar apenas os documentos, dados e registros relacionados.

4. Verificar validade, versão e prioridade das informações.

5. Organizar o conteúdo antes de enviá-lo ao modelo.

6. Registrar a nova decisão ou preferência depois da resposta, quando necessário.

Em um atendimento comercial, o fluxo poderia funcionar assim:

1. O cliente pergunta sobre o preço de um produto.

2. O sistema identifica o produto mencionado.

3. Recupera preço, condições de pagamento e regras comerciais relacionadas.

4. Consulta dados do cliente apenas se forem necessários para personalizar a oferta.

5. Envia ao modelo as mensagens recentes e as informações recuperadas.

6. Registra a nova preferência ou decisão na memória.

Essa abordagem é diferente de enviar o catálogo completo, todas as regras comerciais e o histórico integral antes mesmo de compreender o que o cliente deseja.

O que deve permanecer e o que pode sair

Uma forma de revisar o contexto é classificar cada informação em três grupos.

Informações obrigatórias afetam segurança, identidade, permissões ou regras centrais do atendimento.

Informações condicionais são necessárias apenas em determinadas intenções, produtos, clientes ou etapas do processo.

Informações descartáveis incluem resultados antigos de ferramentas, documentos sem relação com a tarefa, mensagens repetidas, hipóteses superadas e dados substituídos por um estado mais recente.

Essa classificação ajuda a evitar dois extremos: retirar informações essenciais ou manter tudo por medo de perder algum detalhe.

Como diagnosticar excesso de contexto

Alguns sintomas aparecem com frequência quando o Agente recebe mais informações do que consegue utilizar adequadamente:

* responde sobre um produto diferente daquele mencionado;

* utiliza uma regra antiga mesmo tendo acesso à versão atual;

* mistura informações de diferentes etapas da conversa;

* repete perguntas que já foram respondidas;

* ignora uma correção recente do cliente;

* apresenta respostas melhores quando uma nova conversa é iniciada;

* fica progressivamente mais lento ou caro em interações longas;

* recupera muitos documentos, mas utiliza poucos deles na resposta;

* muda de comportamento conforme a posição de uma regra no prompt.

Esses sinais não provam, isoladamente, que existe excesso de contexto. Eles indicam que vale testar versões menores e mais direcionadas.

O teste pode comparar o mesmo conjunto de conversas em três configurações:

1. contexto completo;

2. contexto recuperado por relevância;

3. contexto recuperado por relevância com histórico compactado.

O objetivo é observar a qualidade da resposta, o custo, a latência, a consistência e quais informações foram realmente utilizadas. Esse diagnóstico deve fazer parte do processo de testar o Agente antes do atendimento real e continuar depois da publicação.

A base pode crescer sem que o contexto cresça junto

Uma empresa pode possuir uma base de conhecimento com milhares de páginas. Isso não significa que cada página deva acompanhar todas as mensagens.

O Agente precisa de mecanismos para navegar nesse conhecimento: classificação da intenção, busca, filtros por produto ou cliente, controle de versões, memória externa, ferramentas específicas e resumos estruturados.

A base de conhecimento representa o que o Agente pode saber.

O contexto representa o que ele precisa considerar agora.

Construir um Agente confiável depende menos de despejar informações dentro de uma janela cada vez maior e mais de organizar como essas informações entram, permanecem e saem do contexto.

Antes de adicionar outro documento, mais vinte exemplos ou todo o histórico de atendimento, vale fazer uma pergunta diferente:

Esta informação realmente ajuda o Agente a tomar a próxima decisão?

A pergunta central não deve ser apenas “o que o Agente pode saber?”, mas “o que ele precisa saber agora?”.