A engenharia de contexto de IA consiste em projetar tudo o que envolve o agente em termos de informações, limites e instruções, para que ele saiba o que pode ver, o que deve fazer e como agir quando se depara com uma situação nova ou com dados incompletos. De acordo com a explicação de Doug Whitley, diretor de engenharia do Stack Overflow, e Ash Zade, diretora de produtos, o objetivo não é inundar o agente com todos os dados disponíveis, mas fornecer o contexto específico de que ele precisa para realizar uma tarefa com resultado previsível.
Isso foi discutido em uma conversa publicada pelo Stack Overflow Blog como parte da série “No Dumb Questions”, que abordou as diferenças entre engenharia de contexto, infraestrutura de contexto e engenharia de contexto, além da relação desses conceitos com as tecnologias RAG e MCP e dos motivos que levam as empresas a comprar soluções prontas em vez de construir tudo internamente.
Da infraestrutura à engenharia
Whitley diferencia a infraestrutura de contexto, relacionada à forma como o contexto é armazenado, exibido e fornecido ao agente, da engenharia de contexto, que se concentra no projeto do sistema e nas razões para organizar seus componentes de determinada maneira. Já a engenharia de contexto no sentido executivo diz respeito à construção efetiva do sistema, como a escolha dos algoritmos, das linguagens de programação e das ferramentas utilizadas.
Ele coloca o RAG em uma área que reúne os três níveis. Índices, armazenamentos de contexto e métodos de busca representam o aspecto da infraestrutura, enquanto o processo de construir o sistema em uma linguagem como .NET, Python ou Rust representa o aspecto da engenharia. Por outro lado, a arquitetura define a forma geral do sistema e as regras que governam seu funcionamento. Quanto ao MCP, Whitley o considera um protocolo com requisitos específicos, mas a decisão de integrá-lo ao sistema, as linguagens utilizadas e os recursos que ele oferecerá são todas decisões de projeto.
Reduzindo o espaço de decisões tomadas pelo agente
Zade explica a ideia usando o exemplo de uma busca por pneus de carros. Se um agente for enviado a uma biblioteca para procurar “pneus”, poderá encontrar informações sobre aviões, bicicletas e carrinhos de mão, pois todas correspondem à palavra solicitada. Porém, um sistema bem projetado determina desde o início que a tarefa trata de pneus de carros, ou especificamente de pneus para carros esportivos, e restringe as informações disponíveis a esse escopo.
Zade considera que inserir essas instruções apenas em um prompt de texto não garante que o agente as seguirá. Por isso, a engenharia de contexto exige controlar os dados aos quais o agente pode ter acesso, além de definir o que ele fará ao encontrar informações incompletas ou incorretas. Dessa forma, algumas variáveis são eliminadas das decisões do agente, em vez de deixá-lo decidir por conta própria se uma informação é confiável ou se o escopo da busca deve ser ampliado.
O sistema também inclui a memória do agente, permitindo que ele retenha o que realizou, aprendeu, discutiu e construiu até o momento. Essa memória se torna ainda mais importante quando vários agentes trabalham juntos ou quando uma tarefa é interrompida e retomada posteriormente.
Confiança, permissões e intervenção humana
O Stack Internal, segundo os palestrantes, oferece um exemplo de conexão entre o contexto, um sistema de confiança e um fluxo de verificação por especialistas. O conhecimento é classificado com níveis alto, médio ou baixo. Quando o nível é médio ou baixo, o usuário pode ser direcionado a um especialista no assunto para verificar a informação ou preencher as lacunas, em vez de o agente tomar uma decisão com base em conhecimento não confirmado.
A proteção de dados vai além da questão de saber se o agente consegue visualizar determinada informação. A informação pode estar disponível para o usuário, mas ser inadequada para a tarefa executada pelo agente. Por isso, os palestrantes descrevem dois níveis de controle:
- Permissões da fonte: o agente herda as permissões do usuário nos sistemas que pesquisa, como Slack, MS Teams, Google Drive ou SharePoint.
- Escopos: o usuário pode restringir o escopo dos dados disponíveis ao agente, mesmo que tenha permissão para acessar um conjunto mais amplo deles.
- Novos dados: é possível restringir o que o agente cria ou devolve ao sistema, fazendo com que envie o conteúdo primeiro ao usuário, sem adicioná-lo automaticamente à base de conhecimento geral ou compartilhá-lo com a equipe.
Essa distinção indica que o gerenciamento de contexto não diz respeito apenas à recuperação, mas também inclui o controle sobre a memória e o conhecimento criados pelo agente.
Por que a empresa pode comprar a solução em vez de construí-la?
Whitley afirma que construir uma engenharia de contexto é possível, mas o desafio não se limita à escrita do código. Quando a empresa reúne dados do Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub e Jira, precisa definir como indexá-los, filtrá-los e reordená-los, além de determinar como lidar com informações conflitantes, incompletas ou incorretas.
Zade considera que grande parte do trabalho está relacionada à definição da própria confiança. Um usuário especialista pode confiar nas saídas da inteligência artificial quando elas correspondem às suas expectativas e à sua experiência anterior, mas essa abordagem não está disponível da mesma forma para quem não tem experiência no domínio em que está pedindo à inteligência artificial que atue. Por isso, o sistema exige discussões sobre o que torna uma informação confiável, e não apenas soluções técnicas para coletá-la.
Whitley acrescenta que comprar uma solução pronta pode dar à empresa acesso à experiência acumulada com problemas enfrentados por outros clientes, incluindo casos extremos e problemas cotidianos que, segundo ele, sua equipe classifica em cerca de 20 categorias. Ainda assim, os dois palestrantes não descartam a construção interna; ela pode ser adequada quando o caso de uso é novo ou quando a empresa precisa de decisões de projeto próprias.
Para Whitley e Zade, a qualidade da engenharia de contexto é medida pela flexibilidade do sistema e por sua capacidade de oferecer resultados consistentes e previsíveis, não simplesmente por restringir seu escopo a uma única tarefa. Filtrar as informações antecipadamente também pode reduzir o número de tokens processados pelo agente: pesquisar em livros sobre carros custa menos do que pesquisar em uma biblioteca inteira, e pesquisar em páginas sobre pneus custa menos do que revisar todos os livros. O objetivo final continua sendo permitir que o agente execute a tarefa esperada e pare ou peça ajuda humana quando atingir limites que não deve ultrapassar.