Guia prático de observabilidade, custo e fallback em apps com IA

Chamar uma API de IA é só o começo. Quando a funcionalidade entra em um fluxo real, latência, custo, erro, validação, fallback e qualidade também precisam ser acompanhados.

Contexto

Nos últimos guias da série, a conversa foi ficando mais próxima de engenharia: RAG para buscar contexto, respostas estruturadas para transformar saída em dado, evals para medir comportamento, harness para repetir testes, agentes com ferramentas para consultar ou agir e agentes pessoais para pensar em autonomia, memória e canais.

Agora vem uma parte menos chamativa, mas muito importante: como acompanhar tudo isso quando a funcionalidade está rodando?

Uma feature com IA pode parecer ótima no teste manual e ainda assim falhar de formas pouco óbvias em uso real. Ela pode ficar lenta, custar mais do que o esperado, falhar na validação, acionar fallback toda hora ou retornar HTTP 200 com uma saída ruim para o sistema.

O problema

Em uma integração tradicional, muitos erros aparecem de forma direta: uma API retorna 500, uma chamada dá timeout ou um campo obrigatório vem vazio. Com IA, isso ainda existe, mas aparecem outros tipos de problema.

• O modelo pode responder dentro do tempo, mas ignorar uma regra importante.
• Pode devolver um JSON quase certo, mas inválido.
• Pode consumir muitos tokens em um caso que parecia simples.
• Pode precisar de retry e dobrar o custo daquela execução.
• Pode acionar fallback e esconder que o fluxo principal está falhando.

Sem registro, tudo isso vira sensação: "acho que ficou mais lento", "parece que está gastando mais", "algumas respostas pioraram". Quando não existe observabilidade mínima, investigar uma feature com IA vira uma mistura de palpite, print de conversa e memória recente.

Modelo mental

Um jeito simples de pensar em observabilidade para apps com IA é separar três camadas: confiabilidade, custo e qualidade.

1confiabilidade2  -> a chamada funcionou?34custo5  -> quanto essa execução consumiu?67qualidade8  -> a resposta foi útil e válida para o fluxo?

Essas três camadas precisam conversar. Não adianta olhar só para erro técnico se a resposta passa pela API, mas falha no schema. Não adianta olhar só para tokens se a resposta barata é ruim. E não adianta acionar fallback se ninguém registra quando ele entrou, por que entrou e qual foi o resultado.

Logs mínimos

Log não é sinônimo de guardar tudo. Em apps com IA, isso é especialmente importante porque prompt, contexto e resposta podem carregar dados sensíveis. O primeiro cuidado é não registrar mais do que você precisa para operar e investigar o fluxo.

1{2  "feature": "summary",3  "model": "model-name",4  "promptVersion": "summary-v3",5  "status": "fallback_used",6  "latencyMs": 1840,7  "inputTokens": 920,8  "outputTokens": 260,9  "estimatedCost": 0.0042,10  "validation": "passed"11}

Esse exemplo é fictício, mas mostra a ideia. Com poucos campos, já dá para investigar qual funcionalidade executou, qual modelo respondeu, qual versão de prompt estava ativa, quanto tempo demorou, quantos tokens foram usados, se a validação passou e se fallback foi acionado.

Log bom ajuda investigação sem virar vazamento esperando para acontecer.

Métricas importantes

Logs ajudam a investigar eventos específicos. Métricas ajudam a enxergar comportamento agregado. Em uma feature com IA, algumas métricas simples já ajudam bastante.

• Latência média e P95 para entender lentidão real.
• Taxa de erro para acompanhar falhas técnicas.
• Taxa de validação reprovada para separar resposta de API de resposta útil.
• Uso de fallback para saber se o plano B virou caminho principal.
• Tokens por execução e custo estimado por fluxo.
• Retries por execução para identificar custo ou espera duplicada.
• Correção ou revisão humana para criar sinal mínimo de qualidade.

Se uma mudança no prompt reduziu erro de schema, mas dobrou tokens, isso precisa aparecer. Se um modelo novo melhorou qualidade, mas aumentou latência de forma ruim para a experiência, isso também precisa entrar na decisão.

Qualidade também precisa de sinal

Uma armadilha comum é tratar observabilidade apenas como monitoramento técnico. Tempo de resposta, erro, timeout e custo são fundamentais, mas em IA existe uma pergunta adicional: a resposta foi boa para o que o sistema precisava fazer?

• A resposta passou pelo schema?
• A classificação bateu com o esperado?
• O usuário aceitou a sugestão?
• O usuário editou muito a resposta?
• Um revisor marcou a saída como correta, parcial ou ruim?
• Um eval conhecido passou ou falhou?
• O fallback foi acionado por baixa confiança, erro ou timeout?

Qualidade, nesse contexto, é menos sobre uma nota absoluta e mais sobre sinais consistentes. O sistema não precisa fingir que sabe medir tudo, mas precisa deixar claro o que está observando.

Retry, timeout e fallback

Retry e fallback parecem decisões simples. Na prática, exigem cuidado. Retry pode ajudar em erro temporário, instabilidade de rede ou timeout ocasional, mas também pode piorar a experiência se o problema for prompt ruim, entrada grande demais ou provedor instável.

Fallback também precisa de regra. Ele entra por erro, timeout, custo, validação ou baixa qualidade? Vai para qual modelo, fluxo ou resposta alternativa? O usuário precisa saber? O resultado passa pela mesma validação? Existe limite para não gerar custo duplicado?

Um bom fallback não é só "se falhar, tenta outro". É uma política explícita.

HTTP 200 não basta

Em apps com IA, sucesso técnico não significa sucesso funcional. A API pode responder com sucesso e mesmo assim a feature falhar.

• O JSON veio inválido.
• O campo obrigatório veio vazio.
• O modelo ignorou uma instrução.
• O resumo ficou longo demais.
• A classificação veio fora das opções permitidas.
• A resposta usou contexto errado.
• O usuário precisou reescrever quase tudo.

1api_success2validation_failed3fallback_used4human_review_required5user_corrected6completed

Esses estados ajudam a enxergar o fluxo real. Se tudo vira apenas "sucesso" ou "erro", muita coisa importante desaparece.

O que não logar

Observabilidade não pode virar desculpa para guardar dado sensível sem critério. Em muitos fluxos, o conteúdo enviado para o modelo pode incluir informações pessoais, dados internos, documentos, mensagens, contexto recuperado via RAG ou respostas ainda não revisadas.

• Preciso mesmo guardar isso?
• Por quanto tempo?
• Quem pode acessar?
• Existe uma forma anonimizada?
• Posso salvar apenas metadados?
• Isso ajudaria de verdade em uma investigação?

O objetivo é observar o sistema, não criar um arquivo gigante de conteúdo sensível. Quanto mais autonomia a feature tiver, mais importante fica essa pergunta.

Como começar simples

1. Definir os status principais do fluxo.
2. Registrar modelo, versão de prompt, latência, tokens e validação.
3. Marcar quando retry ou fallback acontecer.
4. Separar erro técnico de resposta inválida.
5. Criar uma visão simples de custo estimado por funcionalidade.
6. Revisar periodicamente casos com falha, fallback ou correção humana.
7. Usar os aprendizados para melhorar prompt, schema, retrieval ou modelo.

Isso já muda a conversa. Em vez de "acho que piorou", fica possível dizer: "a latência subiu em entradas longas, o fallback aumentou depois da última mudança e a validação falhou mais no campo de categoria".

Relação com evals e harness

Evals, harness e observabilidade se complementam. Evals ajudam a definir o que avaliar. Harness ajuda a rodar casos de forma repetível antes de aprovar uma mudança. Observabilidade ajuda a acompanhar o comportamento depois que a funcionalidade está rodando.

Antes de publicar uma nova versão de prompt, você pode rodar um harness com casos representativos. Depois de publicar, a observabilidade pode mostrar que a taxa de validação reprovada caiu, mas a latência aumentou em entradas grandes. Agora existe uma decisão real: aceitar, ajustar, criar fallback específico ou voltar para a versão anterior.

Quando manter mais simples ainda

Nem toda experiência pequena precisa nascer com rastreamento completo. Se você está estudando, prototipando ou testando uma ideia local, pode ser exagero montar uma estrutura inteira de logs, métricas e fallback.

Mas existe uma virada importante: quando a funcionalidade começa a lidar com usuários reais, dados importantes, custo variável, automação ou decisão que impacta o fluxo do produto, ela deixa de ser apenas experimento.

Checklist prático

• Sei qual modelo respondeu?
• Sei qual versão do prompt estava ativa?
• Consigo medir tempo de resposta?
• Consigo estimar custo por chamada ou por fluxo?
• Diferencio erro de API, timeout e resposta inválida?
• Valido a saída antes de usar no sistema?
• Sei quando retry e fallback acontecem?
• O fallback tem limite?
• Evito salvar dado sensível desnecessário?
• Tenho algum sinal de qualidade depois do uso real?

Conclusão

Funcionalidades com IA não falham apenas quando a API cai. Elas também falham quando respondem devagar demais, custam mais do que o previsto, devolvem saída inválida, acionam fallback sem registro ou parecem boas no texto, mas ruins para o fluxo do sistema.

O começo pode ser pequeno: logs seguros, métricas básicas, validação de saída, registro de fallback e revisão dos casos problemáticos. Isso não torna a IA perfeita. Mas tira a funcionalidade do escuro.

IA em produção também precisa de painel, limite e plano B.