Arquitetura depois dos LLMs: onde o modelo senta no sistema

A primeira arquitetura com LLM que quase todo time desenha é a mesma: o pedido do usuário entra, o modelo sai, a resposta volta. É a demo em forma de caixa. Funciona no palco. Em sistema, a pergunta útil é outra: onde o modelo senta, em quais rotas, e o que continua de pé quando ele atrasar, encarecer ou errar com educação.

“Depois dos LLMs” não quer dizer que o modelo virou o centro. Quer dizer que o centro — o domínio, o registro, a permissão, o acervo — ganhou um componente novo, falível de um jeito novo. Arquitetura boa decide a cadeira do modelo. Arquitetura ruim coloca o modelo em todas as cadeiras para não decidir.

Quatro cadeiras, quatro relógios

Chamada síncrona. O usuário espera. Serve ao gesto em que a prosa é a tela: rascunho, pergunta ao manual, reformulação de um parágrafo. Exige orçamento de latência, streaming, teto de tokens. Falhou o fornecedor, falhou a tela. Circuito de abertura, mensagem honesta, talvez um modelo menor de reserva.

Fila. O usuário não espera naquele clique. Sumário de um original, tagueamento de um acervo, e-mail de lançamento, reindexação comentada. O pedido vira trabalho. O trabalho tem retry, idempotência, dead letter. O modelo pode demorar um minuto. A falha não derruba a loja. Derruba um lote — o que já é grave, mas é um domínio outro.

Agente. O modelo escolhe passos e ferramentas. Senta atrás de um orçamento e de uma porteira, como no texto sobre agentes. Não senta na rota do checkout. Não senta em qualquer “assistente” que na verdade é uma pergunta ao manual.

Cache de respostas. Pergunta repetida, trecho estável, sinopse já aprovada. O modelo já trabalhou. O sistema serve o texto com versão. Invalida quando o índice, o prompt ou o fato mudam. Muita “arquitetura de IA” é, na prática, um cache que ninguém desenhou, então cada clique paga de novo.

flowchart TD
  U[Pedido] --> D{LLM nesta rota?}
  D -->|Não| S[Sistema clássico]
  D -->|Síncrono| L[Chamada direta]
  D -->|Fila| Q[Trabalho]
  D -->|Cache| K[Resposta pronta]
  D -->|Laço| A[Agente]
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class U,D ouro
  class L,Q,K,A verde
  class S fim

A decisão não é de moda. É de relógio e de falha. O mesmo modelo pode ocupar cadeiras diferentes em rotas diferentes. O erro é a cadeira única.

O modelo não é o sistema de registro

Preço, estoque, permissão, “este usuário comprou este PDF”, hash do original: isso mora em banco, em regra, em serviço que você testa sem prosa. O LLM lê uma projeção, no máximo. Nunca é a fonte da verdade. Um agente que “lembra” o preço no contexto da conversa e o usa para cobrar é uma regressão civilizatória: voltamos a ter o dado na cabeça de alguém, só que a cabeça é estatística.

O mesmo vale para busca. RAG é um caminho de leitura sobre um índice. O índice deriva de documentos versionados. Se o documento muda, muda o índice — não o parágrafo que o modelo citou ontem no cache sem chave de versão.

Integração, então, tem direção. O núcleo expõe ações estreitas (as mesmas que o MCP pode apresentar como ferramenta). O modelo chama o núcleo. O núcleo não chama o modelo para saber se o pagamento existiu.

Domínios de falha

Desenhe as costuras para rasgarem em lugares conhecidos.

Fornecedor do modelo. Quota, latência, mudança silenciosa de versão, recusa nova. Pin da versão, timeout, fallback para modelo menor ou para “não sei”, fila quando a rota aguentar. Sem pin, o seu teste de ontem não descreve o ar de hoje.

Índice e recuperação. Índice velho, corte ruim, filtro de permissão furado. Falha de qualidade, não de HTTP. Isolar ingestão de consulta. Poder reindexar um documento sem desligar a busca. Poder desligar o RAG e cair numa resposta de recusa, não num modelo solto inventando política.

Ferramentas e efeitos. Timeout, retried que cobra duas vezes, SQL largo, e-mail disparado. Idempotência e porteira. O domínio de falha aqui é o mundo real, não a prosa.

Prompt e versão de produto. Um texto de sistema novo é deploy. Vai com canário e rollback, como em IA em produção. Misturar prompt novo com índice velho é um domínio híbrido: os dois “funcionam” e a frase sai errada.

Quando tudo isso vive num único processo síncrono, a falha de um vira a falha de todos. Separar cadeiras é separar blast radius. A busca do site não deveria sentir o agente que resume originais à noite.

Não ponha o LLM em toda requisição

Há uma pressão estética: se temos o modelo, que ele “entenda” cada clique. Classificar um botão, parsear um CEP, decidir se o slug existe, ordenar a estante. Cada um desses casos já teve solução barata, testável, síncrona, sem fornecedor no meio.

Use o modelo onde a variação da linguagem é o problema. Não use onde o problema é dado, regra ou permissão. Uma heurística dura: se você consegue escrever o teste como entrada → saída sem um humano julgar a prosa, talvez não precise de LLM na rota.

Outra: se a rota precisa ser correta sempre — cobrança, ACL, watermark, download — o modelo não decide. Pode explicar depois, a partir de um log, o que o sistema fez. Explicar não é autorizar.

Na editora, isso fica concreto. A loja, o PIX, a biblioteca do leitor, o arquivo no storage: sistema clássico. A ajuda sobre um capítulo, o rascunho de orelha, a sugestão de termos, o lote que gera descrição: modelo, na cadeira certa. A tentação de um “orquestrador inteligente” no meio do checkout é a tentação de um domínio de falha inaceitável.

Um desenho mínimo que aguenta crescimento

1. Núcleo de registro e permissão, sem prosa.
2. Índice versionado para o que se recupera.
3. Rotas síncronas poucas, com streaming e teto.
4. Fila para o resto da geração.
5. Cache com chave de prompt, modelo e índice.
6. Agente só atrás de orçamento e porteira, se a ordem dos passos for de fato imprevisível.
7. Um interruptor por rota: modelo on, modelo off, fallback.

Isso é chato. Chatice é o ofício. O modelo é uma dependência com prosa. A arquitetura decide se essa dependência é um assistente numa sala ou o teto do prédio. Teto de prédio não deveria ser um token.

A Programming One continua sendo o chão: processo, fila, cache. A AI One acrescenta o modelo como mais uma dependência — não como substituto do desenho.

Leia também: IA em produção: latência, custo e rollback e MCP: modelos ligados a ferramentas.