O mapa completo de uma arquitetura de IA em produção

Nos últimos meses escrevi sete posts separados sobre engenharia de IA para Senior e Staff Engineer: arquitetura, backend, agentes e MCP, RAG avançado, fine-tuning, deploy de modelos e observabilidade/segurança. Cada um tratou de uma camada isolada. Faltava juntar tudo num mapa só — porque na prática ninguém constrói essas camadas em sequência limpa, elas se atropelam o tempo todo.

Este post é esse mapa. Não é um resumo de cada post anterior, é a cola entre eles: onde uma camada termina e a outra começa, e o que quebra quando essa fronteira não é respeitada.

As sete camadas, numa frase cada

Arquitetura define como as peças se falam. Backend decide onde o estado vive e como ele é consistente sob carga. Agentes e MCP resolvem como o sistema toma decisões multi-etapa e chama ferramentas externas com segurança. RAG resolve como o modelo acessa conhecimento que não está nos pesos. Fine-tuning resolve o que RAG não resolve: comportamento, formato, domínio muito específico. Deploy resolve como colocar isso no ar sem explodir o orçamento. Observabilidade e segurança resolvem como saber que continua funcionando — e que ninguém está abusando do sistema.

Onde as camadas colidem

A colisão mais comum é entre RAG e fine-tuning. Times gastam semanas fazendo fine-tuning para "ensinar" o modelo sobre dados que mudam toda semana — quando o problema era simplesmente falta de contexto recuperável, não falta de capacidade do modelo. Fine-tuning resolve estilo e comportamento; RAG resolve conhecimento factual e volátil. Confundir os dois é o erro de arquitetura mais caro que vejo repetidamente.

A segunda colisão é entre agentes e observabilidade. Um agente que decide sozinho quais ferramentas chamar, em qual ordem, é uma caixa preta por definição — a menos que cada decisão seja logada com o mesmo rigor que uma transação financeira. Sistemas de agente que chegam em produção sem tracing decisão-a-decisão são, na prática, indepuráveis assim que o primeiro comportamento estranho aparece.

A terceira é entre deploy e backend. Decisões de infraestrutura de deploy (batching, quantização, cache de resposta) só fazem sentido se o backend já resolveu onde fica o estado de sessão. Otimizar latência de inferência sem antes resolver isso é otimizar a parte errada do sistema.

A ordem que eu recomendo seguir

Comece pela arquitetura — não a arquitetura de IA, a arquitetura do sistema como um todo, decidindo onde o modelo entra. Depois resolva o backend, porque ele carrega as decisões de estado que tudo depende. Só então decida entre RAG e fine-tuning, geralmente RAG primeiro, porque é reversível e mais barato de errar. Deploy vem depois que o comportamento está estável, não antes. Observabilidade não vem "depois" de nada — ela entra desde o primeiro commit, porque sem ela você não vai saber se as decisões anteriores estavam certas.

O que fica de fora deste mapa

Este mapa cobre construção. Não cobre avaliação sistemática (como você mede se o sistema está realmente funcionando, não só funcionando na demo), nem prompt engineering em produção, nem o pipeline de release contínuo depois que o primeiro modelo está no ar. Esses três temas vão ganhar posts próprios nas próximas semanas — porque cada um merece o mesmo nível de profundidade que os sete anteriores.

Se você chegou até aqui pelos posts da série, essa é a visão de conjunto que faltava. Se está chegando agora, comece por qualquer camada que for a sua dor mais urgente — o mapa funciona nos dois sentidos.