12-01-01 — Por que observabilidade em IA e diferente de software tradicional
TL;DR
Software tradicional falha de forma deterministica: exception, timeout, null pointer. LLMs falham de forma probabilistica e silenciosa: a API retorna 200, o agente "funciona", mas a resposta e factualmente errada, tendenciosa ou cara demais. APM classico (New Relic, Datadog) nao detecta isso. Voce precisa de uma camada de observabilidade especifica para IA — que mede qualidade, custo por token e comportamento semantico, nao apenas latencia e uptime.
O que muda com LLMs
1. Falhas silenciosas
Em um sistema .NET tradicional, quando algo da errado voce recebe um erro. Com LLMs:
- HTTP 200 OK — mas a resposta e uma alucinacao
- HTTP 200 OK — mas o agente ignorou uma tool call critica
- HTTP 200 OK — mas a resposta virou um loop infinito de raciocinio
Seu monitor de uptime vai mostrar tudo verde enquanto seus usuarios recebem lixo.
2. Nao-determinismo
A mesma entrada com temperature=0.7 pode gerar saidas completamente diferentes. Isso significa:
- Testes unitarios nao funcionam da mesma forma
- Um bug pode se manifestar em apenas 5% das requisicoes
- Reproducibilidade exige logging de inputs/outputs completos
3. Custo variavel por requisicao
Diferente de uma API REST onde o custo de infraestrutura e relativamente previsivel, com LLMs:
- Uma pergunta simples custa 500 tokens; uma complexa pode custar 50.000 tokens
- Um usuario "curioso" pode gerar 100x mais custo que um usuario normal
- Sem observabilidade de custo, voce descobre o problema na fatura do fim do mes
4. Sensibilidade a prompt
Mudancas minimas no system prompt podem degradar drasticamente a qualidade das respostas — sem nenhum erro de codigo. Um deployment que "melhorou o wording" do prompt pode introduzir regressoes que so aparecem em casos de borda raros.
Seu agente pode ter 99.9% de uptime e ainda ser completamente inutil se 30% das respostas sao incorretas. SLA de disponibilidade e necessario mas insuficiente para aplicacoes de IA.
As tres dimensoes de observabilidade em IA
O que o APM classico consegue (e o que nao consegue)
| Metrica | APM Classico | Obs. IA especifica |
|---|---|---|
| Latencia de API | ✅ Sim | ✅ Sim + por etapa (retrieval, generation) |
| Taxa de erro HTTP | ✅ Sim | ✅ Sim + erros semanticos |
| Throughput (req/s) | ✅ Sim | ✅ Sim |
| Custo por token | ❌ Nao | ✅ Sim |
| Qualidade da resposta | ❌ Nao | ✅ Sim (com evals) |
| Alucinacoes | ❌ Nao | ✅ Parcial (com grounding checks) |
| Tool calls executadas | ❌ Nao | ✅ Sim |
| Drift de qualidade | ❌ Nao | ✅ Sim (com baseline) |
Minimo viavel de observabilidade para IA em producao
Para uma aplicacao de IA em producao, voce precisa no minimo:
- Logging completo de inputs/outputs: Cada prompt enviado e cada resposta recebida, com timestamp e user ID
- Contagem de tokens e custo: Por requisicao, por usuario, por dia
- Latencia por etapa: Separar tempo de retrieval, tempo de LLM call, tempo de pos-processamento
- Taxa de erros (tecnicos e semanticos): Erros de API + respostas que falharam em validacoes de qualidade
- Amostras para revisao humana: 1-5% das conversas revisadas manualmente ou via LLM-judge
Nao precisa de uma plataforma cara no dia 1. Um simples log estruturado em JSON com
input, output, tokens_used, latency_ms e cost_usd ja e muito melhor do que zero observabilidade.
Como isso se conecta
- 12-01-02 Tracing: A solucao tecnica para rastrear o que acontece dentro de cada requisicao
- 12-03-01 Metricas: Definicao concreta das metricas que enderecam as tres dimensoes
- 12-03-02 Avaliacoes offline: Como medir qualidade de forma sistematica antes de ir para producao
- 09 Foundry: Azure AI Foundry tem tracing e avaliacao integrados — bom ponto de partida para stacks Microsoft