Observabilidade de LLM
Observabilidade de LLM e a pratica de instrumentar aplicações de LLM em produção para que as equipes possam ver o que o modelo esta fazendo, depurar falhas, medir custo e latencia, detectar deriva (drift) de qualidade e avaliar saidas ao longo do tempo. E o equivalente, na era dos LLMs, a observabilidade tradicional de apps - logs, traces e metricas - adaptada a sistemas probabilisticos em que a mesma entrada pode produzir saidas diferentes.
Observabilidade de LLM e a pratica de instrumentar aplicações de LLM em produção para que as equipes possam ver o que o modelo esta fazendo, depurar falhas, medir custo e latencia, detectar deriva (drift) de qualidade e avaliar saidas ao longo do tempo. E o equivalente, na era dos LLMs, a observabilidade tradicional de apps - logs, traces e metricas - adaptada a sistemas probabilisticos em que a mesma entrada pode produzir saidas diferentes.
Por Que Importa
Um app web tradicional ou funciona ou lança um erro. Um app de LLM pode "funcionar" (retornar uma resposta bem formatada) enquanto a resposta esta errada, fora do topico, alucinada, enviesada ou simplesmente pior que ontem. Sem observabilidade, essas falhas ficam invisiveis ate os usuarios reclamarem - momento em que a confiança ja esta abalada. 2024-2025 viu a observabilidade de LLM se tornar uma categoria distinta, com ferramentas como Langfuse, LangSmith, Helicone, Arize Phoenix, Weights & Biases Weave e Braintrust, cada uma ocupando uma fatia. Para qualquer equipe rodando LLMs em produção, a observabilidade agora e requisito basico, não um diferencial.
O Que Instrumentar
Traces: O caminho completo de execução - cada prompt, chamada de recuperação, invocação de ferramenta e resposta em uma unica requisição. Permite reproduzir o que o agente de fato fez.
Pares de entrada/saida: O prompt exato enviado e a conclusão exata recebida, versionados por template de prompt.
Custo por requisição: Contagem de tokens × preço de entrada e saida, por modelo. Agregado por recurso, usuario ou tenant.
Latencia: Tempo ate o primeiro token, tempo total de conclusão e tempo gasto em cada subetapa.
Erros e retentativas: Erros de limite de taxa, timeouts, falhas de chamada de ferramenta, erros de parse.
Sinais de qualidade: Joinha para cima/baixo do usuario, sinais implicitos (saida copiada, codigo executado, mensagem enviada) e pontuações de LLM-as-judge sobre saidas recentes.
Drift: Mudanças ao longo do tempo na distribuição de saida, na qualidade das respostas ou na taxa de chamada de ferramenta - frequentemente o primeiro sinal de que uma atualização de modelo ou mudança de prompt quebrou algo.
Por Que E Diferente da Observabilidade Tradicional
As saidas não são deterministicas: Mesma entrada, saida diferente. As metricas precisam tratar a variancia como conceito de primeira classe.
Os custos são por token, não por requisição: O APM tradicional não sabe o que são tokens. A observabilidade de LLM precisa saber.
A qualidade e subjetiva: Voce não pode afirmar "saida correta" com um teste simples. A avaliação precisa de revisão humana, juizes LLM ou comparações com verdade de referencia.
Prompts são codigo: Uma mudança de prompt e um deploy. Sem versionamento de prompt, voce não consegue dizer qual versão produziu o bug de ontem.
Cadeias de varias etapas importam: A maioria dos apps de LLM são pipelines. Voce precisa de traces aninhados que espelhem o grafo de chamadas, não logs planos.
O Panorama de Ferramentas (2026)
Langfuse (open source): Observabilidade focada em traces com avaliação, gestão de prompts e feedback de usuario. Popular entre equipes de auto-hospedagem.
LangSmith (LangChain): Fortemente integrado ao LangChain. Forte para equipes que ja estão nessa stack.
Helicone: Observabilidade leve baseada em proxy. Integração de uma linha, facil de adotar.
Arize Phoenix / Arize AX: Vem do mundo de observabilidade de ML; forte em drift, embeddings e ciencia de avaliação.
Braintrust: Plataforma focada em avaliação, util para equipes que querem tratar o desenvolvimento de LLM como um fluxo de experimentação.
Weave (Weights & Biases): Estende o rastreamento de experimentos de ML do WandB para o territorio dos LLMs.
Monitoramento de LLM do Datadog / New Relic: Fornecedores classicos de APM adicionando dashboards especificos de LLM.
Convenções semanticas GenAI do OpenTelemetry: Um padrão multifornecedor para tracing de LLM, ganhando adoção em 2025-2026.
O Que Observar
Custo por sessão de usuario: Picos repentinos costumam significar um bug (loop de retentativa, agente descontrolado) antes de significarem crescimento.
Latencia p95/p99: As caudas longas matam a UX. O pior caso importa mais que a media.
Drift da pontuação de avaliação: Uma pontuação semanal de LLM-as-judge sobre prompts representativos pega regressões silenciosas apos mudanças de prompt ou modelo.
Principais modos de falha: Categorize os erros - recusado, alucinado, fora do topico, formato ruim - para saber onde investir.
Desempenho por versão de prompt: Compare pontuações de avaliação entre versões de prompt para saber se a ultima mudança ajudou ou prejudicou.
Distribuição de tokens: Respostas longas elevam o custo. Caudas longas inesperadas costumam indicar deriva de prompt ou stop tokens quebrados.
Erros Comuns
Registrar apenas erros: Os LLMs falham em silencio. Registre tambem os sucessos, com metadados suficientes para avaliar a qualidade.
Sem estrategia de amostragem: Registrar 100% das requisições em escala e caro. Amostre de forma inteligente por segmento de usuario, faixa de custo ou mudança recente.
Não conectar traces ao feedback do usuario: O joinha para baixo precisa estar ligado ao trace exato que produziu a saida.
Isolado por equipe: Produto, ML e infra constroem cada um seus proprios dashboards. A observabilidade unificada e o ganho.
Ignorar testes de regressão: "Parece bom" não basta. Construa um conjunto de avaliação de regressão e rode-o antes de cada mudança de prompt.
Buscar lock-in de fornecedor: As convenções GenAI do OpenTelemetry permitem instrumentar uma vez e trocar de fornecedor de observabilidade depois.
Fontes: