Este post é o primeiro da série Antes do Primeiro Token, onde apresento como arquitetar soluções de próxima geração que utilizem IA generativa de maneira eficiente.
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.
| Abordagem | Deterministic AI | Context Pruning | Expert Judgment |
|---|---|---|---|
| Objetivo | Eliminar inferência desnecessária | Eliminar contexto desnecessário | Eliminar análise desnecessária |
| Resultado | Agente ou automação com resultados mais previsíveis. | Modelo recebe menos informação, mas de maior qualidade. | Modelo concentra sua atenção naquilo que realmente importa |
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.
| LLM First | LLM Last |
|---|---|
| Usuário ↓ Busca ↓ LLM ↓ Resposta | Usuário ↓ Classificação ↓ Roteamento ↓ Ferramentas ↓ Conhecimento ↓ LLM ↓ Resposta |
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.
Deixe um comentário