Introdução

Grande parte das discussões atuais sobre IA generativa gira em torno de aumentar a sua eficiência através da redução da quantidade de contexto compartilhado.

Isso acontece porque muitas organizações descobriram na prática que fazer um simples dump de dados não estruturados e confiar que um modelo Frontier será capaz de processá-los de forma consistente em qualquer fluxo de trabalho raramente produz os resultados esperados.

Ou, quando produz, o custo não fecha a conta. Em resumo:

Too much brute force baby

No primeiro artigo desta série apresentei a hipótese de que a próxima geração de arquiteturas de IA não será definida apenas pelos modelos utilizados, mas pelas decisões tomadas antes de chamar esses modelos.

Diversos termos aparecem constantemente nessas discussões, como IA determinística, arquiteturas agentic e padrões modernos de orquestração, mas neste artigo quero focar em dois conceitos que surgem repetidamente quando o assunto é redução de contexto:

• Context Pruning
• Expert Judgment

Vou compará-los, discutir suas vantagens e limitações e apresentar um terceiro conceito que surgiu durante essa análise: Capability Routing.

Um conceito inspirado na forma como especialistas humanos resolvem problemas e que nasceu de uma pergunta que me incomodou bastante ao longo desta pesquisa:

Como reduzir contexto sem descartar justamente a informação necessária para gerar a resposta?

Dois conceitos que estão ganhando espaço

Antes de avançarmos, vale alinharmos rapidamente os conceitos que motivaram esta discussão:

A ideia por trás do Context Pruning é bastante intuitiva: se enviar muito contexto para um modelo é ruim, basta enviar menos contexto, adicionando uma etapa intermediária que será responsável por eliminar informações consideradas menos relevantes.

Usuário -> Recuperação (100 documentos) -> Pruning (10 documentos) -> LLM – Resposta

Em arquiteturas de AI generativa pro-code (utilizando por exemplo o Azure AI Foundry) é algo possível de ser implementado através de Query Planning, Retrieval, Agentic RAG e Reranking. No entanto, em plataformas no/low code como o Copilot Studio e M365 Copilot geralmente não existe o mesmo nível de controle sobre o pipeline interno de recuperação, o que limita a aplicação e efetividade da técnica.

Outro fator limitante é que quanto mais agressivo for o pruning, maior o risco de se perder contexto, evidências ou precisão. Em outras palavras, toda estratégia de Context Pruning assume implicitamente que consegue responder corretamente à seguinte pergunta:

“O que será importante para responder antes que a resposta exista?”

Expert Judgment, por outro lado, lida com a redução de contexto através de uma abordagem totalmente diferente. Por exemplo, para responder a pergunta “Como configurar políticas de DLP para agentes do Copilot Studio?”, um especialista humano poderia seguir uma das abordagens a seguir:

É óbvio que a abordagem 02 é muito mais eficiente: em poucos segundos o especialista já descartou mentalmente dezenas de domínios irrelevantes. Observe que o especialista não está tentando decidir quais páginas da documentação devem ser descartadas, ele está tomando uma decisão anterior:

Quais domínios, conhecimentos e capacidades merecem atenção.

O processo de análise só começa depois dessa decisão.

Por este motivo, mais as limitações citadas do Context Pruning, que acredito que adotar técnicas baseadas em Expert Judgement em arquiteturas no/low code de AI generativa tem o potencial de:

• Aumentar a eficiência, acuracidade e previsibilidade dos agentes e fluxos de trabalho já nas primeiras iterações.
• Empodera times de negócio e não especialistas ao permitir que foquem na criação e curadoria de conhecimento e documentação de processo de negócios para apoiar a tomada de decisão dos agentes.
• Acelera o desenvolvimento das soluções por permitir que os especialistas – no/low coders ou não – desacoplem contexto de negócio das instruções, o que inclusive facilita a manutenção e evolução da solução.

Capability Routing – estendendo o Expert Judgment para arquiteturas de agentes

Até este ponto discutimos duas abordagens diferentes para reduzir a quantidade de informação utilizada durante a resolução de um problema. Embora ambas possam produzir resultados semelhantes, existem diferenças importantes:

Isto me levou a formular um terceiro conceito, aplicável a arquitetura de agentes, que chamei de Capability Routing.

O que é Capability Routing?

É o processo de selecionar antecipadamente quais capacidades, especialistas, ferramentas, agentes e fontes de conhecimento devem participar da resolução de uma solicitação antes da fase de grounding.

A ideia é usar os mesmos mecanismos mentais que especialistas utilizam para orientar o funcionamento dos agentes.

Em vez de recuperar tudo para depois decidir o que remover, o agente busca determinar primeiro:

• Qual domínio está sendo discutido;
• Qual especialista deve participar;
• Qual ferramenta deve ser utilizada;
• Qual conhecimento deve ser consultado.

Somente depois disso a recuperação de contexto acontece.

Capability Routing na prática

Imagine um agente corporativo de RH.

Em uma primeira versão da solução, o agente possui acesso a toda a documentação relacionada à área.

• Benefícios
• Férias
• Folha de pagamento
• Admissão
• Desligamento
• Treinamento
• Avaliação de desempenho
• Políticas internas
• Regulamentos trabalhistas

Ela funcionaria adequadamente, mas para responder a pergunta “Quantos dias de férias posso vender este ano?” ele precisaria analisar todo esse material para decidir o que deve ou não participar da resposta.

Como um especialista humano resolveria esse mesmo problema

Agora imagine um analista experiente de RH recebendo exatamente a mesma pergunta. Normalmente aconteceria algo mais próximo disto:

Em poucos segundos o especialista já descartou mentalmente os subdomínios desnecessários sem nem precisar analisar nenhum documento.

Capability Routing aplicado a agentes

Uma arquitetura orientada por Capability Routing tentaria reproduzir exatamente ocomportamento do especialista humano.

Para a pergunta “Como solicito inclusão de dependentes no plano de saúde?” o fluxo de execução seria:

O que realmente está sendo reduzido?

Esse é um ponto importante. Capability Routing não reduz apenas contexto, ele reduz o espaço de decisão.

E tudo isso acontece antes mesmo da recuperação do conhecimento.

Por isso vejo o Capability Routing como uma extensão natural do Expert Judgment aplicada a arquiteturas de agentes.

Em resumo, o especialista humano reduz o problema identificando rapidamente o domínio correto. O agente deve fazer exatamente a mesma coisa ao selecionar antecipadamente quais capacidades, skills, ferramentas e fontes de conhecimento devem participar da resolução.

Cenas dos próximos capítulos

A teoria parece sólida. Mas como esse conceito se comporta em um ambiente real?

No próximo artigo apresentarei uma arquitetura de agentes construída no Copilot Studio que, sem utilizar mecanismos sofisticados de Context Pruning, já aplica diversos princípios de Capability Routing para selecionar antecipadamente quais capacidades, skills e fontes de conhecimento devem participar da resolução da solicitação antes da fase de grounding. Isso permitirá analisar como essas ideias podem ser aplicadas hoje em plataformas low/no-code, utilizando padrões relativamente simples de implementação.

Introdução

Nos últimos anos, a conversa sobre IA generativa foi dominada por uma pergunta relativamente simples:

Como podemos usar mais IA?

Cuja resposta era igualmente simples:

Com modelos maiores. Contextos maiores. Bases de conhecimento maiores. Mais agentes. Mais ferramentas. Mais automação. Mais tokens.

Mas nas últimas semanas comecei a notar um padrão curioso surgindo em artigos, pesquisas e discussões técnicas vindas de diferentes empresas e comunidades. Embora abordem problemas distintos, todos parecem apontar para a mesma direção:

O futuro da IA generativa talvez não esteja em usar mais inteligência artificial, mas em usar apenas a quantidade necessária.

Essa percepção surgiu ao ler três artigos publicados recentemente:

• Not everything should cost a token: the case for deterministic AI, da Vybe, que argumenta que nem toda decisão precisa ser delegada a um LLM e que lógica determinística continua sendo uma ferramenta arquitetural extremamente valiosa.
• How we taught a small LLM to throw away 68% of our RAG context, da Kapa AI, que mostra como reduzir drasticamente o contexto enviado ao modelo pode melhorar eficiência sem comprometer resultados.
• Learning to Replicate Expert Judgment in Financial Tasks, da Thinking Machines, que explora como modelos podem aprender a reproduzir o julgamento de especialistas em vez de simplesmente processar grandes volumes de informação.

Da arquitetura LLM-First para a arquitetura LLM-Last

Se os primeiros anos da IA generativa foram marcados pela corrida para incorporar modelos em praticamente qualquer aplicação, os sinais recentes apontam para uma mudança de maturidade. A pergunta já não parece ser:

Como posso usar um LLM aqui?

Mas sim:

Onde exatamente um LLM agrega valor aqui?

Essa pode parecer uma diferença sutil de formulação, mas ela muda profundamente a forma como arquitetamos soluções baseadas em IA generativa.

A primeira geração: LLM-First

As primeiras arquiteturas de IA generativa costumavam seguir um modelo relativamente simples:

Usuário -> LLM -> Resposta

Com o amadurecimento das técnicas de RAG (Retrieval-Augmented Generation), a arquitetura evoluiu para algo como:

Usuário -> Busca -> LLM -> Resposta

Ou ainda:

Usuário ->Knowledge Base -> LLM -> Resposta

Os sinais de uma mudança de paradigma

Se os três artigos apresentados até agora já sugerem uma mudança de direção no uso da IA generativa, o mais interessante é que essa mesma discussão está surgindo simultaneamente em diversos laboratórios de IA, hyperscalers e especialistas da indústria.

Embora utilizem terminologias diferentes e abordem problemas distintos, todos parecem convergir para uma conclusão semelhante:

O desafio não é mais colocar mais inteligência artificial nas aplicações. mas sim decidir quando, como e onde utilizá-la de forma eficiente.

Essa convergência é um forte indicativo de que não estamos diante de uma tendência passageira, mas sim de uma mudança estrutural na forma como arquitetamos sistemas baseados em IA.

Anthropic: comece pela solução mais simples

Um dos sinais mais claros dessa mudança aparece no artigo Building Effective Agents, publicado pela Anthropic.

Após trabalhar com dezenas de implementações corporativas de agentes, a empresa apresenta uma recomendação surpreendentemente simples:

Comece pela solução mais simples possível e só aumente a complexidade quando necessário.

Para a Anthropic, muitos problemas são melhor resolvidos por fluxos previsíveis e orientados por código do que por agentes altamente autônomos. A empresa inclusive recomenda que equipes esgotem abordagens mais simples antes de introduzir sistemas agentic complexos. Outro aspecto interessante é a presença de um padrão arquitetural chamado Routing, descrito como a classificação de uma solicitação seguida pelo encaminhamento para um especialista apropriado.

OpenAI: agentes devem ser usados onde realmente agregam valor

A OpenAI segue uma linha de pensamento muito semelhante.

Em seu guia prático para construção de agentes, a empresa argumenta que agentes devem ser utilizados quando abordagens tradicionais, determinísticas e orientadas por regras deixam de ser suficientes para resolver um problema. A implicação é direta é que:

Nem todo processo exige um agente e consequentemente, nem todo processo exige um modelo de linguagem sofisticado.

A OpenAI também enfatiza padrões arquiteturais como:

• agentes especialistas;
• coordenadores;
• handoffs;
• roteamento entre capacidades.

Novamente observamos um tema recorrente:

A discussão está migrando de qual modelo usar para como orquestrar modelos, ferramentas e especialistas.

Microsoft: o retrieval virou um problema de raciocínio

A evolução recente do Azure AI Search, Agentic Retrieval e Foundry IQ talvez represente um dos exemplos mais claros dessa transformação.

Tradicionalmente, Retrieval-Augmented Generation (RAG) era visto como um mecanismo relativamente simples:

Pergunta -> Busca -> Contexto -> LLM -> Resposta

Nas implementações mais recentes, entretanto, a própria recuperação de informações passa a ser tratada como um processo de planejamento, decomposição e tomada de decisão.

A proposta do Foundry IQ é particularmente emblemática.

A plataforma descreve retrieval como uma atividade de raciocínio capaz de planejar consultas, navegar entre fontes de informação e combinar conhecimento proveniente de diferentes repositórios.

Isso representa uma mudança sutil, mas importante. A pergunta deixa de ser “qual documento devo recuperar?” e passa a ser “como devo encontrar o conhecimento necessário para responder esta pergunta?“. O retrieval deixa de ser uma simples operação de busca e passa a se tornar uma etapa de decisão arquitetural.

Google Research: mais agentes não significa melhores resultados

Outro estudo relevante vem do Google Research.

Em uma avaliação envolvendo múltiplas arquiteturas de agentes, pesquisadores observaram que aumentar o número de agentes nem sempre melhora os resultados. Dependendo da natureza da tarefa, arquiteturas mais complexas podem inclusive degradar a performance.

A principal conclusão é especialmente relevante para arquitetos:

Eficiência arquitetural pode ser mais importante do que escala arquitetural.

Essa observação reforça uma das hipóteses centrais deste artigo, de que eficiência arquitetural pode ser mais importante do que escala arquitetural.

Andrej Karpathy: a arquitetura voltou ao centro da discussão

Essa mesma tendência também aparece nas reflexões recentes de Andrej Karpathy sobre Software 3.0 e Agentic Engineering, onde ele argumenta que estamos migrando de um mundo onde o principal ativo era escrever código para um mundo onde o principal ativo passa a ser orquestrar sistemas inteligentes.

Talvez essa seja a melhor síntese para o movimento que estamos observando:

A inovação não está desaparecendo dos modelos, mas ela está migrando progressivamente dos modelos para a arquitetura.

A tese que emerge dessa convergência

Quando observamos em conjunto, surge uma conclusão difícil de ignorar:

A próxima geração de sistemas de IA generativa será definida menos pela capacidade de gerar respostas e mais pela capacidade de tomar boas decisões antes da geração.

Talvez este seja o verdadeiro pano de fundo por trás de todas essas discussões seja:

Antes de otimizar tokens, contexto e modelos, precisamos criar arquiteturas que tomem decisões antes que o primeiro token seja consumido.

O surgimento da arquitetura LLM-Last

O que vejo emergindo como padrão é uma arquitetura que coloca o modelo generativo no final da cadeia de decisão.

Algo que podemos chamar de LLM-Last Architecture, onde o LLM deixa de ser a aplicação e passa a ser apenas um componente da aplicação.

Usuário -> Classificação -> Roteamento -> Ferramentas -> Conhecimento -> LLM -> Resposta

O que muda na prática?

Em uma arquitetura LLM-First, o modelo recebe a responsabilidade de descobrir praticamente tudo:

• Como responder
• Qual é a intenção do usuário
• Quais fontes consultar
• Quais ferramentas utilizar
• Quais informações são relevantes

Na arquitetura LLM-Last, essas responsabilidades passam a ser distribuídas.

Classificação (Quem deve responder?)
↓
Roteamento (Qual capacidade utilizar?)
↓
Ferramentas (Quais dados recuperar?)
↓
Conhecimento (Quais evidências são relevantes?)
↓
LLM (Como transformar tudo isso em uma resposta útil?)

O modelo continua extremamente importante, mas ele passa a atuar onde efetivamente agrega valor:

• Síntese
• Explicação
• Contextualização
• Raciocínio complexo
• Interação natural

O novo objetivo: reduzir trabalho desnecessário do modelo

Foi nesse momento que percebi a conexão mais profunda entre os três artigos mencionados anteriormente.

Todos eles estão tentando resolver o mesmo problema através de abordagens diferentes.

Essas três abordagens podem ser resumidas em uma única diretriz arquitetural:

Use a menor quantidade possível de IA necessária para alcançar o resultado esperado.

Observe que isso não significa usar menos IA por usar menos IA. Significa reservar a capacidade dos modelos para aquilo que realmente exige inteligência generativa.

Arquiteturas LLM Last tendem a possuir as seguintes características:

• Maior governança
• Menor custo
• Menor latência
• Maior previsibilidade
• Melhor aproveitamento de SLMs
• Melhor aproveitamento de modelos especializados.

O impacto para arquitetos de soluções

Acredito que esta seja uma das mudanças mais importantes que estamos vivendo atualmente.

Nos primeiros anos da IA generativa, a inovação estava concentrada nos modelos, mas agora ela está migrando para a arquitetura, pois o principal diferencial competitivo não está mais apenas em possuir acesso ao melhor modelo, mas sim relacionado cada vez mais a capacidade de responder as seguintes perguntas ao arquitetar a solução:

• Quando devo usar um LLM?
• Quando não devo usar um LLM?
• Qual modelo devo utilizar?
• Que conhecimento realmente precisa participar da resposta?
• Qual decisão pode ser tomada antes da inferência?
• O uso de LLMs permite que a solução a ser criada será eficiente em termos de ROI e TCO?

Cenas dos próximos capítulos

Talvez estejamos focando na otimização errada.

Durante muito tempo, a principal preocupação das arquiteturas de IA generativa foi decidir quais informações deveriam chegar ao modelo. Mas e se a pergunta mais importante for outra?

E se antes de decidir qual contexto utilizar, precisássemos decidir quem deve responder?

No próximo artigo desta série explorarei essa ideia por meio de uma comparação entre duas abordagens cada vez mais presentes no mercado: Context Pruning e Capability Routing.