Definição numa frase
Diseño sistemático de instrucciones, datos, herramientas, memoria y estado que se entregan al modelo en cada paso.
Definição: projetar as informações disponíveis para uma tarefa
Engenharia de contexto é o projeto e o gerenciamento das informações apresentadas a um modelo de IA durante uma execução para ajudá-lo a realizar uma tarefa específica. Essas informações podem incluir instruções, a mensagem do usuário, partes do histórico, exemplos, resultados de ferramentas, documentos recuperados e dados sobre o estado atual do trabalho. A decisão central não é apenas o que dizer ao modelo, mas quais informações incluir, em que formato, em que momento e com quais limites.
O termo é usado em um campo em evolução e não tem uma definição formal universal aceita por todas as disciplinas e fornecedores. É mais preciso tratá-lo como uma denominação prática para um conjunto de decisões técnicas observáveis: reunir informações, escolher as partes pertinentes, organizá-las para a tarefa e atualizá-las quando os resultados ou o estado do sistema mudam. O nome não garante que um sistema aplique um método específico nem que melhore seu desempenho.
Em uma conversa simples, o contexto pode consistir principalmente em instruções e mensagens. Em uma aplicação que recupera documentos ou usa ferramentas, também pode incorporar resultados externos. Em um agente que trabalha em várias etapas, parte das informações pode ser armazenada fora da conversa e reinserida quando necessário. Em todos os casos, o importante é o conteúdo que fica efetivamente disponível para o modelo naquela execução.
O que pode fazer parte do contexto
As instruções definem o papel, os limites ou o formato esperado. A mensagem do usuário expressa a necessidade imediata. O histórico pode fornecer referências a decisões anteriores, desde que essas interações continuem pertinentes. Os exemplos mostram padrões de resposta ou de resolução, embora sua utilidade dependa de serem representativos da tarefa.
Documentos recuperados e resultados de ferramentas fornecem informações externas à mensagem inicial. Uma ferramenta pode, por exemplo, retornar o conteúdo de um arquivo ou o resultado de uma busca. O estado do trabalho pode registrar o que já foi feito, o que ainda falta e qual resultado precisa ser preservado para a próxima etapa. Esses elementos não precisam estar sempre presentes: incluí-los sem necessidade também consome espaço e pode acrescentar ruído.
O contexto não é necessariamente um único texto escrito por uma pessoa. Pode ser uma composição preparada por uma aplicação antes de cada chamada ao modelo. Uma parte pode vir de uma solicitação; outra, de uma fonte de dados, de uma busca, do histórico ou de uma operação anterior. Por isso, analisar apenas o prompt visível para o usuário nem sempre permite saber quais informações o modelo recebeu.
Elementos comuns e perguntas de controle
| Elemento | Para que pode servir | Pergunta de controle |
|---|---|---|
| Instruções | Delimitar a tarefa, as restrições e o formato. | São claras e compatíveis entre si? |
| Histórico e estado | Manter a continuidade entre etapas ou turnos. | Que partes ainda são necessárias e estão atualizadas? |
| Documentos e resultados de ferramentas | Fornecer dados para responder ou agir. | São pertinentes, confiáveis e suficientes para esta tarefa? |
| Exemplos | Ilustrar um padrão de resposta ou de trabalho. | Representam o caso atual sem induzir uma imitação inadequada? |
Como funciona o ciclo de engenharia de contexto
Uma estratégia de contexto pode ser entendida como um ciclo. Primeiro, identifica-se o que a tarefa exige: por exemplo, responder a uma pergunta, modificar um arquivo ou comparar fontes. Em seguida, obtêm-se as informações disponíveis por meio da mensagem, do histórico, de documentos, de ferramentas ou de uma memória externa. Obter dados não significa que todos devam ser incluídos: é preciso selecionar o que é pertinente, verificar se está atualizado e descartar o que não ajuda.
Depois, o material é organizado e transformado. Pode ser necessário extrair trechos, resumir resultados, separar fatos de questões em aberto ou estruturar o estado do trabalho. Em seguida, o conteúdo selecionado é incorporado ao contexto que o modelo verá. Após a resposta ou ação do modelo, o sistema pode verificar o resultado e atualizar o estado: preservar uma descoberta útil, substituir informações desatualizadas ou buscar o que ainda falta.
O processo se repete quando a tarefa continua. A estratégia adequada depende da tarefa, das fontes e dos recursos do sistema; não existe uma receita que garanta um resultado correto. Uma seleção inadequada pode deixar de fora um dado decisivo. Uma seleção excessiva pode dificultar que o modelo encontre o que importa. Por isso, é melhor projetar o ciclo em torno de necessidades concretas e observar quais informações o sistema utiliza.
Ciclo básico
- 01Definir do que a tarefa precisa e qual resultado se espera.
- 02Obter dados possíveis da mensagem, do histórico, de documentos ou de ferramentas.
- 03Selecionar, organizar e transformar as informações pertinentes.
- 04Incluir essas informações no contexto disponível para o modelo.
- 05Revisar a resposta ou ação e atualizar o estado para a próxima etapa.
Exemplo prático: agente de programação
Imagine que alguém peça a correção de um erro em um aplicativo. Carregar todos os arquivos do projeto de uma só vez pode ser desnecessário. Uma estratégia mais seletiva começa identificando a mensagem de erro e localizando os componentes provavelmente relacionados. O sistema pode consultar arquivos, testes e documentação por meio de ferramentas e fornecer ao modelo os trechos pertinentes, junto com as restrições da alteração solicitada.
Depois de uma modificação, os resultados dos testes ou as saídas das ferramentas podem passar a fazer parte do contexto da etapa seguinte. Se o trabalho precisar continuar em outra etapa, uma nota de estado pode resumir o objetivo, as decisões, os arquivos modificados e as tarefas pendentes. Essa nota é uma representação parcial do trabalho, não uma transcrição completa nem uma garantia de que nenhum detalhe tenha se perdido.
Esse padrão mostra por que gerenciar o contexto pode envolver tanto consultas sob demanda quanto a manutenção de informações entre etapas. Sistemas descritos para agentes de longa duração usam mecanismos de transferência de informações e estado externo para continuar o trabalho quando uma única janela de contexto não é suficiente. A forma concreta de implementá-los depende do agente.
Exemplo prático: atendimento ao cliente
Em um assistente de atendimento ao cliente, a pergunta de uma pessoa poderia ser combinada com a política vigente aplicável ao caso e com uma parte pertinente do histórico cujo uso esteja autorizado. Por exemplo, para consultar o status de uma devolução, o sistema poderia precisar da solicitação atual, da regra correspondente e do dado do pedido necessário para identificar a transação. Este exemplo é ilustrativo: as fontes disponíveis não documentam um sistema específico de atendimento ao cliente com essa configuração.
A seleção também deve limitar o acesso ao que é necessário. Se um dado pessoal não ajudar a resolver a solicitação, não há motivo para incluí-lo por padrão no contexto. A aplicação deve definir quais informações pode recuperar, quem pode acessá-las e por quanto tempo serão mantidas. Essas decisões de privacidade e autorização fazem parte do projeto do sistema; não são resolvidas simplesmente acrescentando instruções ao modelo.
O assistente também precisa distinguir uma política vigente de mensagens anteriores que possam estar desatualizadas. Se a resposta depender de uma regra atual, as informações recuperadas devem poder ser conferidas em uma fonte autorizada. O fato de um documento aparecer no contexto não prova, por si só, que ele esteja correto, atualizado ou seja aplicável ao caso.
Exemplo prático: agente de pesquisa
Um agente de pesquisa pode dividir uma pergunta complexa em várias linhas de trabalho e manter separados os materiais reunidos em cada uma. Em vez de apresentar todos os documentos a um único modelo em cada etapa, pode guardar fontes e descobertas por tema e enviar ao coordenador uma síntese com referências ao material pertinente e as perguntas ainda sem resposta.
Uma síntese facilita a transferência de informações entre etapas, mas pode omitir nuances ou ressalvas. Por isso, o estado do trabalho deve diferenciar o que foi observado nas fontes, o que é uma inferência e o que ainda precisa ser verificado. Se uma conclusão depender de um detalhe, talvez seja necessário voltar ao documento original, em vez de confiar apenas no resumo.
Um sistema de pesquisa multiagente descrito pela Anthropic é um exemplo de organização do trabalho entre agentes com contextos separados e sínteses de descobertas para um agente coordenador. Trata-se de um caso concreto de projeto, não de uma demonstração de que a mesma arquitetura seja superior para toda pesquisa.
Conceitos próximos: prompt, RAG, fragmentação, memória e janela de contexto
A engenharia de prompts se concentra principalmente em redigir e organizar instruções para orientar a resposta do modelo. A engenharia de contexto tem um escopo mais amplo: também considera como reunir, selecionar, ordenar e atualizar as demais informações disponíveis. As duas práticas podem se sobrepor; uma boa instrução faz parte do contexto, mas não resolve, por si só, quais documentos devem ser recuperados nem qual estado deve ser preservado.
A geração aumentada por recuperação, ou RAG, é uma abordagem que combina recuperação de informações e geração. Pode ser uma forma de obter documentos para o contexto, mas não é sinônimo de engenharia de contexto. Um sistema pode usar RAG e ainda precisar decidir o que recuperar, quais trechos incluir e como tratar o resultado. Também é possível gerenciar contexto sem usar um sistema RAG.
A fragmentação, ou chunking, consiste em dividir documentos ou outros materiais em unidades para armazená-los, recuperá-los ou processá-los. Isso afeta quais partes podem chegar ao modelo, mas não determina, por si só, se elas são relevantes nem como serão combinadas com instruções e histórico. Memória, por sua vez, designa mecanismos para preservar e recuperar informações entre momentos ou tarefas. Ao recuperar algo dessa memória, o sistema precisa decidir se ainda é pertinente antes de incorporá-lo ao contexto.
A janela de contexto é o limite de informações que um modelo pode processar em uma execução, de acordo com as características do sistema. Ela não equivale a uma estratégia de seleção de conteúdo: uma janela ampla não define o que incluir nem garante que o modelo dará a mesma atenção a todas as partes. O cache pode reutilizar conteúdo ou resultados de processamento para reduzir trabalho repetido, mas também não é o mesmo que decidir quais informações são necessárias para uma tarefa.
Como distinguir os conceitos
| Conceito | Pergunta principal | Relação com a engenharia de contexto |
|---|---|---|
| Engenharia de prompts | Como expressar as instruções? | É uma parte do projeto do contexto, não o processo inteiro. |
| RAG | Como recuperar informações para gerar uma resposta? | Pode fornecer documentos, mas sua seleção e inclusão ainda precisam ser gerenciadas. |
| Fragmentação (chunking) | Como dividir materiais em unidades? | Influencia o que pode ser recuperado; não decide, por si só, o que convém incluir. |
| Memória | Que informações preservar e recuperar entre momentos? | Pode fornecer um estado que deve ser avaliado antes de entrar no contexto atual. |
| Janela de contexto | Quanta informação uma execução pode processar? | Impõe um limite, não uma política de seleção. |
Erros comuns e limitações
Um erro comum é presumir que mais contexto sempre ajuda. Experimentos com modelos que recebem contextos longos observaram que a capacidade de usar informações pode variar de acordo com a posição em que aparece a evidência pertinente. Portanto, aumentar a quantidade de texto ou o tamanho da janela não garante que o modelo identifique ou utilize melhor o dado necessário.
Outro erro é confundir informação disponível com informação utilizada. O fato de um documento ter sido incluído não demonstra que ele tenha influenciado corretamente a resposta. Da mesma forma, um resumo não preserva necessariamente todas as nuances do original. Durante a compressão, podem se perder condições, exceções ou divergências; detalhes decisivos devem poder ser conferidos na fonte.
O material recuperado também pode estar incompleto, ser irrelevante ou estar desatualizado. Além disso, documentos e páginas da web podem conter instruções maliciosas dirigidas ao agente. Se o sistema tratar esse conteúdo como instruções confiáveis, poderá ser induzido a se desviar da tarefa. A injeção de instruções é um risco associado à incorporação de conteúdo não confiável; as medidas de defesa precisam ser testadas, e sua eficácia não deve ser presumida apenas porque existem.
A seleção do contexto também envolve decisões sobre custo, latência e privacidade. Recuperar ou processar mais informações pode exigir trabalho adicional, e transferir dados desnecessários aumenta sua exposição sem necessidade. Não existe uma quantidade universalmente correta de contexto: ela depende da tarefa, da qualidade das fontes, das restrições do sistema e dos erros que se pretende evitar.
Como avaliar uma estratégia
Para descobrir se uma estratégia ajuda, é recomendável definir tarefas de teste representativas e estabelecer antecipadamente o que será considerado um resultado aceitável. Depois, podem-se comparar variantes: por exemplo, o que acontece ao recuperar menos documentos, ordenar as evidências de outra maneira ou manter um resumo de estado mais explícito. Quando possível, as comparações devem alterar uma decisão por vez para facilitar a interpretação.
A avaliação pode observar a qualidade das respostas ou ações, as omissões de informações relevantes, os erros de seleção, a latência, o custo e a quantidade ou sensibilidade dos dados incluídos. Em sistemas com documentos, também é importante verificar se as respostas se apoiam em fontes aplicáveis e atualizadas. O resultado deve ser interpretado em relação às tarefas e aos dados de teste utilizados: não demonstra automaticamente que a estratégia funcionará em outros casos.
Para atribuir uma melhoria ao gerenciamento do contexto, é preciso comparar resultados de forma sistemática e manter constantes, tanto quanto possível, o modelo e as demais condições relevantes. Uma impressão anedótica ou o fato de uma resposta parecer convincente não basta para demonstrar causalidade. Se ocorrerem erros, analisar o que foi recuperado, o que foi omitido e quais informações chegaram de fato ao modelo pode ajudar a localizar o problema.
Lista rápida para revisar um projeto
- 01As informações incluídas atendem a uma necessidade identificada da tarefa?
- 02A pertinência e a atualidade das fontes foram verificadas?
- 03O sistema preserva detalhes críticos que poderiam se perder em um resumo?
- 04Dados pessoais desnecessários foram excluídos?
- 05Qualidade, omissões, latência e custo foram medidos em tarefas representativas?
- 06Foram testadas entradas não confiáveis e situações em que a recuperação falha?
Critérios práticos e conceitos relacionados
Ao projetar um sistema, comece especificando a tarefa e os dados que poderiam mudar a resposta ou a ação. Obtenha informações apenas de fontes permitidas, selecione o que for pertinente e mantenha uma forma de consultar o material original caso uma síntese não seja suficiente. Atualize o estado quando surgirem novas evidências, em vez de acumular indefinidamente um histórico que talvez já não seja útil.
Em seguida, teste o projeto com casos comuns e casos-limite: fontes contraditórias, informações desatualizadas, solicitações ambíguas e documentos que contenham instruções alheias à tarefa. Verifique o que chega ao modelo, o que fica de fora e qual resultado é obtido. Se o sistema falhar, não presuma que ele precisa de mais contexto; confira se o problema está na recuperação, na seleção, na organização, na atualidade dos dados ou na interpretação do modelo.
Para continuar explorando o vocabulário relacionado, consulte as entradas do glossário sobre engenharia de prompts, RAG, fragmentação ou chunking e memória, além da entrada geral do glossário. A distinção prática é simples: o prompt trata sobretudo de instruções; RAG, de recuperar informações para gerar; chunking, de dividir materiais; memória, de preservar e recuperar estado. A engenharia de contexto considera como combinar essas peças em uma execução específica.