O problema
Um sistema com múltiplos passos — busca, chamada ao modelo, chamada de ferramenta, formatação de saída — começa a responder devagar em produção. Ninguém consegue dizer qual passo é o gargalo. A resposta reflexa é "vamos trocar pro modelo mais rápido" ou "vamos aumentar o timeout" — sem nenhuma evidência de qual passo, de fato, está consumindo o tempo.
Esse é o padrão que essa lição ataca: incidente sem instrumentação vira debate de opinião. Observabilidade não é um extra de maturidade — é o que transforma "algo está lento" em "o passo de recuperação está levando 4 segundos em p95, os outros três passos somam 400ms".
Instrumente proporcional à escala do sistema
Nem todo sistema precisa do mesmo nível de observabilidade. Um classificador de intenção com uma única chamada ao modelo não precisa de tracing distribuído — um log estruturado com latência e resultado já responde à maioria das perguntas de diagnóstico. Um pipeline multiagente com várias chamadas de ferramenta encadeadas precisa de tracing que amarra cada passo à mesma requisição raiz, porque sem isso é impossível saber qual chamada específica, dentro de uma cadeia de dez, causou o problema.
A pergunta que guia o nível de instrumentação: quantos passos independentes existem entre o pedido e a resposta, e cada um deles pode falhar ou atrasar de forma isolada? Quanto maior esse número, mais a observabilidade precisa amarrar os passos entre si, não só medir cada um isoladamente.
Latência e acurácia se balanceiam com evidência, não intuição
Um erro comum é assumir que o modelo mais lento é sempre o mais acurado, ou que reduzir o número de chamadas sempre piora a qualidade. As duas suposições podem estar erradas dependendo do sistema. A forma certa de decidir é medir: rodar o mesmo conjunto representativo de casos contra as alternativas, registrar latência em p50 e p95 (não só a média, que esconde os piores casos) e acurácia lado a lado, e decidir com o número, não com a expectativa.
Um distrator comum de cenário: otimizar latência cortando um passo de validação, sem medir o impacto na taxa de erro que chega ao usuário final. Latência ganha, confiabilidade perde — e sem medição, ninguém percebe até o incidente seguinte.
Logs, traces e métricas respondem perguntas diferentes
- Logs estruturados respondem "o que aconteceu nesta requisição específica" — úteis para investigar um caso pontual depois que ele já aconteceu.
- Traces respondem "onde o tempo foi gasto ao longo dos passos de uma requisição" — essenciais quando o sistema tem mais de um passo dependente.
- Métricas agregadas (latência p95, taxa de erro, custo por requisição ao longo do tempo) respondem "o sistema está degradando, e desde quando" — o sinal que dispara um alerta antes que um usuário precise reclamar.
Um sistema de produção madura tem as três camadas, cada uma respondendo a uma pergunta que as outras duas não respondem sozinhas.
Coloque em prática
O laboratório desta lição implementa um seletor de nível de observabilidade a partir da complexidade do sistema, um diagnosticador que aponta qual passo de um pipeline instrumentado está causando um pico de latência, e um avaliador de custo por requisição que compara alternativas com evidência.