12-01-01 — Por que observabilidade em IA e diferente de software tradicional
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.
⚠️ O problema do 99% de uptime
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.
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
graph TD
OBS["Observabilidade em IA"] --> OP["Operacional\n(latencia, erros, uptime)"]
OBS --> CUSTO["Custo\n(tokens, $ por sessao, burn rate)"]
OBS --> QUAL["Qualidade\n(corretude, relevancia, seguranca)"]
OP --> APM["APM Classico\n(Datadog, App Insights)"]
CUSTO --> TOKEN["Token Tracking\n(LangSmith, Langfuse)"]
QUAL --> EVAL["Eval Frameworks\n(RAGAS, DeepEval, LLM-judge)"]
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
💡 Comece simples
Nao precisa de uma plataforma cara no dia 1. Um simples log estruturado em JSON com
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.