Mantendo os agentes de IA ligados à terra: Estratégias de Engenharia de Contexto que Impedem a Rotação de Contexto Usando Milvus

Se já trabalhou em longas conversas de LLM, provavelmente já teve este momento frustrante: a meio de uma longa discussão, o modelo começa a desviar-se. As respostas tornam-se vagas, o raciocínio enfraquece e os pormenores-chave desaparecem misteriosamente. Mas se colocar exatamente a mesma questão numa nova conversa, de repente o modelo comporta-se de forma concentrada, precisa e fundamentada.

Isto não é o modelo a "ficar cansado" - é a podridão do contexto. À medida que uma conversa cresce, o modelo tem de fazer malabarismos com mais informações e a sua capacidade de estabelecer prioridades diminui lentamente. Estudos antrópicos mostram que, à medida que as janelas de contexto aumentam de cerca de 8K tokens para 128K, a precisão da recuperação pode cair 15-30%. O modelo ainda tem espaço, mas perde a noção do que é importante. Janelas de contexto maiores ajudam a atrasar o problema, mas não o eliminam.

É aqui que entra a engenharia de contexto. Em vez de dar ao modelo tudo de uma só vez, moldamos o que ele vê: recuperando apenas as partes que interessam, comprimindo o que já não precisa de ser detalhado e mantendo os avisos e as ferramentas suficientemente limpos para que o modelo possa raciocinar. O objetivo é simples: disponibilizar a informação importante no momento certo e ignorar o resto.

A recuperação desempenha um papel central aqui, especialmente para agentes de longa duração. As bases de dados vectoriais, como o Milvus, fornecem a base para a recuperação eficiente do conhecimento relevante para o contexto, permitindo que o sistema se mantenha no terreno, mesmo quando as tarefas aumentam em profundidade e complexidade.

Neste blogue, vamos ver como acontece a rotação do contexto, as estratégias que as equipas utilizam para a gerir e os padrões de arquitetura - desde a recuperação até ao design de avisos - que mantêm os agentes de IA atentos a fluxos de trabalho longos e com várias etapas.

Porque é que a podridão do contexto acontece

As pessoas assumem frequentemente que dar mais contexto a um modelo de IA conduz naturalmente a melhores respostas. Mas isso não é realmente verdade. Os seres humanos também têm dificuldade em lidar com entradas longas: a ciência cognitiva sugere que a nossa memória de trabalho contém cerca de 7±2 pedaços de informação. Se formos para além disso, começamos a esquecer, a desfocar ou a interpretar mal os pormenores.

Os LLM apresentam um comportamento semelhante - apenas numa escala muito maior e com modos de falha mais dramáticos.

A raiz do problema vem da própria arquitetura do Transformer. Cada token tem de se comparar com todos os outros tokens, formando uma atenção par a par em toda a sequência. Isso significa que a computação cresce O(n²) com o comprimento do contexto. Expandir o seu prompt de 1K tokens para 100K não faz com que o modelo "trabalhe mais" - multiplica o número de interações de tokens por 10.000×.

Depois, há o problema com os dados de treino. Os modelos vêem muito mais sequências curtas do que longas. Por isso, quando se pede a um LLM que opere em contextos extremamente grandes, está-se a empurrá-lo para um regime para o qual não foi devidamente treinado. Na prática, o raciocínio de contextos muito longos está muitas vezes fora da distribuição da maioria dos modelos.

Apesar destes limites, os contextos longos são atualmente inevitáveis. As primeiras aplicações de LLM eram maioritariamente tarefas de uma só vez - classificação, resumo ou geração simples. Hoje em dia, mais de 70% dos sistemas de IA empresariais dependem de agentes que se mantêm activos durante muitas rondas de interação, muitas vezes durante horas, gerindo fluxos de trabalho ramificados e com vários passos. As sessões de longa duração passaram de exceção a padrão.

A questão seguinte é: como manter a atenção do modelo sem o sobrecarregar?

Abordagens de recuperação de contexto para resolver o problema da rotação de contexto

A recuperação é uma das alavancas mais eficazes que temos para combater a podridão de contexto e, na prática, tende a aparecer em padrões complementares que abordam a podridão de contexto de diferentes ângulos.

1. Recuperação Just-in-Time: Reduzindo o contexto desnecessário

Uma das principais causas da podridão de contexto é sobrecarregar o modelo com informações que ele ainda não precisa. O Claude Code - o assistente de codificação do Anthropic - resolve esse problema com a recuperação Just-in-Time (JIT), uma estratégia em que o modelo busca informações apenas quando elas se tornam relevantes.

Em vez de colocar bases de código ou conjuntos de dados inteiros no seu contexto (o que aumenta muito a hipótese de desvio e esquecimento), o Claude Code mantém um pequeno índice: caminhos de ficheiros, comandos e ligações de documentação. Quando o modelo precisa de uma informação, recupera esse item específico e insere-o no contexto no momento em que é importante - nãoantes.

Por exemplo, se pedir ao Claude Code para analisar uma base de dados de 10 GB, ele nunca tenta carregar tudo. Ele funciona mais como um engenheiro:

1. Executa uma consulta SQL para obter resumos de alto nível do conjunto de dados.

2. Usa comandos como head e tail para visualizar dados de amostra e entender sua estrutura.

3. Retém apenas as informações mais importantes - como estatísticas importantes ou linhas de amostra - dentro do contexto.

Ao minimizar o que é mantido no contexto, a recuperação JIT evita o acúmulo de tokens irrelevantes que causam apodrecimento. O modelo mantém-se concentrado porque só vê a informação necessária para o passo de raciocínio atual.

2. Pré-recuperação (Pesquisa Vetorial): Prevenir o desvio de contexto antes que ele comece

Por vezes, o modelo não pode "pedir" informação de forma dinâmica - o apoio ao cliente, os sistemas de P&R e os fluxos de trabalho dos agentes necessitam frequentemente do conhecimento correto disponível antes do início da geração. É aqui que a pré-recuperação se torna crítica.

A podridão do contexto acontece muitas vezes porque o modelo recebe uma grande pilha de texto em bruto e espera-se que descubra o que é importante. A pré-coleta inverte essa situação: uma base de dados vetorial (como a Milvus e a Zilliz Cloud) identifica as partes mais relevantes antes da inferência, garantindo que apenas o contexto de elevado valor chega ao modelo.

Numa configuração típica de RAG:

• Os documentos são incorporados e armazenados numa base de dados vetorial, como o Milvus.

• No momento da consulta, o sistema recupera um pequeno conjunto de fragmentos altamente relevantes através de pesquisas de semelhança.

• Apenas esses fragmentos entram no contexto do modelo.

Isto evita a podridão de duas formas:

• Redução do ruído: o texto irrelevante ou pouco relacionado nunca entra no contexto.

• Eficiência: os modelos processam muito menos tokens, reduzindo a possibilidade de perder o rasto de detalhes essenciais.

O Milvus pode pesquisar milhões de documentos em milissegundos, o que torna esta abordagem ideal para sistemas activos em que a latência é importante.

3. Recuperação híbrida JIT e Vetorial

A pré-recuperação baseada na pesquisa vetorial aborda uma parte significativa da podridão do contexto, garantindo que o modelo começa com informações de alto sinal em vez de texto em bruto e de grandes dimensões. Mas o Anthropic destaca dois desafios reais que as equipas frequentemente ignoram:

• Pontualidade: Se a base de conhecimentos for actualizada mais rapidamente do que o índice de vectores é reconstruído, o modelo pode basear-se em informações obsoletas.

• Precisão: antes do início de uma tarefa, é difícil prever com exatidão o que o modelo irá necessitar - especialmente para fluxos de trabalho exploratórios ou de várias etapas.

Assim, em cargas de trabalho do mundo real, uma abordagem híbrida é a solução ideal.

• Pesquisa vetorial para conhecimento estável e de elevada confiança

• Exploração JIT orientada por agentes para informações que evoluem ou só se tornam relevantes a meio da tarefa

Ao combinar estas duas abordagens, obtém-se a velocidade e a eficiência da recuperação vetorial para informações conhecidas e a flexibilidade do modelo para descobrir e carregar novos dados sempre que estes se tornem relevantes.

Vejamos como isto funciona num sistema real. Tomemos como exemplo um assistente de documentação de produção. A maioria das equipas acaba por optar por um pipeline de duas fases: Pesquisa vetorial baseada em Milvus + recuperação JIT baseada em agentes.

1. Pesquisa vetorial com Milvus (Pré-recuperação)

• Converta sua documentação, referências de API, changelogs e problemas conhecidos em embeddings.

• Guarde-os na base de dados Milvus Vetor com metadados como a área do produto, a versão e o tempo de atualização.

• Quando um utilizador faz uma pergunta, execute uma pesquisa semântica para obter os K segmentos mais relevantes.

Isto resolve cerca de 80% das consultas de rotina em menos de 500 ms, dando ao modelo um ponto de partida forte e resistente ao contexto.

2. Exploração baseada em agentes

Quando a recuperação inicial não é suficiente - por exemplo, quando o utilizador pede algo muito específico ou sensível ao tempo - o agente pode chamar ferramentas para obter novas informações:

• Usar search_code para localizar funções ou arquivos específicos na base de código

• Usar run_query para obter dados em tempo real do banco de dados

• Usar fetch_api para obter o estado mais recente do sistema

Estas chamadas demoram normalmente 3 a 5 segundos, mas garantem que o modelo funciona sempre com dados actualizados, precisos e relevantes - mesmo para questões que o sistema não conseguiu antecipar.

Esta estrutura híbrida garante que o contexto se mantém atempado, correto e específico da tarefa, reduzindo drasticamente o risco de rotação do contexto em fluxos de trabalho de agentes de longa duração.

O Milvus é especialmente eficaz nestes cenários híbridos porque suporta:

• Pesquisa vetorial + filtragem escalar, combinando relevância semântica com restrições estruturadas

• Actualizações incrementais, permitindo que os embeddings sejam actualizados sem tempo de inatividade

Isto faz do Milvus a espinha dorsal ideal para sistemas que necessitam de compreensão semântica e controlo preciso sobre o que é recuperado.

Por exemplo, você pode executar uma consulta como:

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

Como escolher a abordagem correta para lidar com a rotação de contexto

Com a pré-recuperação de pesquisa vetorial, a recuperação Just-in-Time e a recuperação híbrida disponíveis, a questão natural é: qual delas deve ser utilizada?

Eis uma forma simples mas prática de escolher - com base na estabilidade do seu conhecimento e na previsibilidade das necessidades de informação do modelo.

1. Pesquisa vetorial → Melhor para domínios estáveis

Se o domínio muda lentamente, mas exige precisão - finanças, trabalho jurídico, conformidade, documentação médica - então uma base de conhecimentos alimentada por Milvus com pré-resgate é normalmente a opção correta.

A informação está bem definida, as actualizações são pouco frequentes e a maioria das perguntas pode ser respondida recuperando antecipadamente documentos semanticamente relevantes.

Tarefas previsíveis + conhecimento estável → Pré-recuperação.

2. Recuperação atempada → Melhor para fluxos de trabalho dinâmicos e exploratórios

Áreas como engenharia de software, depuração, análise e ciência de dados envolvem ambientes que mudam rapidamente: novos arquivos, novos dados, novos estados de implantação. O modelo não pode prever o que será necessário antes do início da tarefa.

Tarefas imprevisíveis + conhecimento em rápida mudança → recuperação Just-in-Time.

3. Abordagem híbrida → Quando ambas as condições são verdadeiras

Muitos sistemas reais não são puramente estáveis ou puramente dinâmicos. Por exemplo, a documentação do desenvolvedor muda lentamente, enquanto o estado de um ambiente de produção muda minuto a minuto. Uma abordagem híbrida permite-lhe:

• Carregar conhecimento conhecido e estável usando pesquisa vetorial (rápida e de baixa latência)

• Obter informações dinâmicas com ferramentas de agente a pedido (precisas e actualizadas)

Conhecimento misto + estrutura de tarefas mista → abordagem de recuperação híbrida.

E se a janela de contexto ainda não for suficiente?

A engenharia de contexto ajuda a reduzir a sobrecarga, mas por vezes o problema é mais fundamental: a tarefa simplesmente não cabe, mesmo com um corte cuidadoso.

Certos fluxos de trabalho - como a migração de uma grande base de código, a revisão de arquiteturas de vários repositórios ou a geração de relatórios de pesquisa profunda - podem exceder mais de 200 mil janelas de contexto antes que o modelo chegue ao fim da tarefa. Mesmo com a pesquisa vetorial a fazer o trabalho pesado, algumas tarefas requerem uma memória mais persistente e estruturada.

Recentemente, o Anthropic ofereceu três estratégias práticas.

1. Compressão: Preservar o sinal, eliminar o ruído

Quando a janela de contexto se aproxima do seu limite, o modelo pode comprimir interações anteriores em resumos concisos. Uma boa compressão mantém

• Decisões-chave

• Restrições e requisitos

• Questões pendentes

• Amostras ou exemplos relevantes

E remove:

• Saídas de ferramentas prolixas

• Registos irrelevantes

• Passos redundantes

O desafio é o equilíbrio. Se a compressão for demasiado agressiva, o modelo perde informação crítica; se for demasiado ligeira, ganha-se pouco espaço. A compressão eficaz mantém o "porquê" e o "o quê" enquanto descarta o "como chegámos aqui".

2. Tomada de notas estruturada: Mova as informações estáveis para fora do contexto

Em vez de manter tudo dentro da janela do modelo, o sistema pode armazenar factos importantes na memória externa - umabase de dados separada ou um armazenamento estruturado que o agente pode consultar conforme necessário.

Por exemplo, o protótipo de agente Pokémon do Claude armazena factos duradouros como:

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

Entretanto, os detalhes transitórios - registos de batalhas, saídas de ferramentas longas - permanecem fora do contexto ativo. Isto reflecte a forma como os humanos utilizam os blocos de notas: não guardamos todos os detalhes na nossa memória de trabalho; armazenamos pontos de referência externamente e consultamo-los quando necessário.

A tomada de notas estruturada evita a podridão do contexto causada por detalhes repetidos e desnecessários, dando ao modelo uma fonte fiável de verdade.

3. Arquitetura Sub-Agente: Dividir e conquistar grandes tarefas

Para tarefas complexas, pode ser concebida uma arquitetura multi-agente em que um agente principal supervisiona o trabalho global, enquanto vários sub-agentes especializados tratam de aspectos específicos da tarefa. Estes sub-agentes mergulham profundamente em grandes quantidades de dados relacionados com as suas sub-tarefas, mas apenas devolvem os resultados concisos e essenciais. Esta abordagem é normalmente utilizada em cenários como relatórios de investigação ou análise de dados.

Na prática, o melhor é começar por utilizar um único agente combinado com a compressão para realizar a tarefa. O armazenamento externo só deve ser introduzido quando for necessário reter a memória ao longo das sessões. A arquitetura multi-agente deve ser reservada para tarefas que exijam genuinamente o processamento paralelo de sub-tarefas complexas e especializadas.

Cada abordagem estende a "memória de trabalho" efectiva do sistema sem rebentar a janela de contexto - e sem desencadear a rotação do contexto.

Melhores práticas para projetar um contexto que realmente funcione

Depois de lidar com o excesso de contexto, há outra parte igualmente importante: como o contexto é construído em primeiro lugar. Mesmo com compressão, notas externas e sub-agentes, o sistema terá dificuldades se o prompt e as ferramentas em si não forem projetados para suportar raciocínios longos e complexos.

O Anthropic oferece uma forma útil de pensar sobre isto - menos como um exercício de escrita de um único prompt, e mais como a construção do contexto em três camadas.

Sistema de sugestões: Encontrar a Zona Cachinhos Dourados

A maioria dos prompts de sistema falham nos extremos. Demasiados detalhes - listas de regras, condições aninhadas, excepções codificadas - tornam o prompt frágil e difícil de manter. Demasiada pouca estrutura deixa o modelo a adivinhar o que fazer.

Os melhores prompts ficam no meio: estruturados o suficiente para guiar o comportamento, mas flexíveis o suficiente para o modelo raciocinar. Na prática, isso significa dar ao modelo uma função clara, um fluxo de trabalho geral e uma leve orientação da ferramenta - nada mais, nada menos.

Por exemplo:

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

Este aviso define a direção sem sobrecarregar o modelo ou forçá-lo a fazer malabarismos com informações dinâmicas que não pertencem aqui.

Desenho de ferramentas: Menos é mais

Uma vez que o prompt do sistema define o comportamento de alto nível, as ferramentas carregam a lógica operacional real. Um modo de falha surpreendentemente comum em sistemas aumentados por ferramentas é simplesmente ter demasiadas ferramentas - ou ter ferramentas cujos objectivos se sobrepõem.

Uma boa regra de ouro:

• Uma ferramenta, um objetivo

• Parâmetros explícitos e não ambíguos

• Sem sobreposição de responsabilidades

Se um engenheiro humano hesitasse sobre qual a ferramenta a utilizar, o modelo também hesitaria. Uma conceção clara da ferramenta reduz a ambiguidade, diminui a carga cognitiva e evita que o contexto seja sobrecarregado com tentativas desnecessárias.

A informação dinâmica deve ser recuperada, não codificada

A última camada é a mais fácil de ignorar. As informações dinâmicas ou sensíveis ao tempo - como valores de estado, actualizações recentes ou estado específico do utilizador - não devem aparecer de todo na linha de comandos do sistema. A sua inclusão na linha de comandos garante que se tornará obsoleta, inchada ou contraditória em tarefas longas.

Em vez disso, estas informações devem ser obtidas apenas quando necessário, quer através de recuperação quer através de ferramentas de agente. Manter o conteúdo dinâmico fora do prompt do sistema evita o apodrecimento do contexto e mantém o espaço de raciocínio do modelo limpo.

Conclusão

À medida que os agentes de IA entram em ambientes de produção em diferentes sectores, estão a assumir fluxos de trabalho mais longos e tarefas mais complexas do que nunca. Nessas configurações, o gerenciamento do contexto se torna uma necessidade prática.

No entanto, uma janela de contexto maior não produz automaticamente melhores resultados; em muitos casos, faz o oposto. Quando um modelo é sobrecarregado, alimentado com informações obsoletas ou forçado a responder a solicitações maciças, a precisão desvia-se silenciosamente. Esse declínio lento e subtil é o que chamamos agora de podridão do contexto.

Técnicas como a recuperação JIT, a pré-recuperação, os pipelines híbridos e a pesquisa semântica com base em dados vectoriais visam o mesmo objetivo: garantir que o modelo vê a informação certa no momento certo - nem mais, nem menos - para que possa manter-se no terreno e produzir respostas fiáveis.

Sendo uma base de dados vetorial de código aberto e de elevado desempenho, o Milvus está no centro deste fluxo de trabalho. Fornece a infraestrutura para armazenar conhecimentos de forma eficiente e recuperar as partes mais relevantes com baixa latência. Em conjunto com a recuperação JIT e outras estratégias complementares, o Milvus ajuda os agentes de IA a manterem-se exactos à medida que as suas tarefas se tornam mais profundas e dinâmicas.

Mas a recuperação é apenas uma peça do puzzle. Um bom design de prompt, um conjunto de ferramentas limpo e mínimo e estratégias de transbordamento sensatas - seja compressão, notas estruturadas ou sub-agentes - trabalham em conjunto para manter o modelo concentrado em sessões de longa duração. É assim que se parece a verdadeira engenharia de contexto: não se trata de hacks inteligentes, mas de uma arquitetura bem pensada.

Se você deseja que os agentes de IA permaneçam precisos por horas, dias ou fluxos de trabalho inteiros, o contexto merece a mesma atenção que você daria a qualquer outra parte central da sua pilha.

Tem dúvidas ou quer um mergulho profundo em qualquer recurso? Participe do nosso canal Discord ou registre problemas no GitHub. Também pode reservar uma sessão individual de 20 minutos para obter informações, orientação e respostas às suas perguntas através do Milvus Office Hours.