← Blog

Observabilidade de sistemas de IA: o HTTP 200 não mede qualidade

Um endpoint de modelo que responde 200 em 400 ms parece saudável. Pode ter citado a política errada, inventado um prazo, chamado a ferramenta duas vezes e custado dez vezes o orçamento. A observabilidade clássica — CPU, erro HTTP, p95 — continua necessária. Não é suficiente. Sistemas de IA falham em prosa.

Desde 2023 este blog insiste numa ideia simples: o que não se vê não se corrige. Em notas, isso é título e fonte. Em produção de modelo, é o prompt que foi, o trecho que entrou, a ferramenta que rodou, a frase que saiu, e alguém — de vez em quando — lendo o pacote com uma rubrica. Sem isso, você opera um gerador de 200.

Este é o recorte mais recente desta série. Os textos de produção e de arquitetura pediam orçamento, canário e cadeira certa para o modelo. Aqui vai o que você precisa enxergar quando a cadeira já está ocupada.

O que um trace precisa carregar

Um request de LLM não é uma linha de log com status. É uma árvore.

  • identidade da rota, versão de prompt, id de modelo, versão de índice;
  • a pergunta do usuário (com redacção de segredo);
  • os trechos recuperados, com id de documento e posição no ranking;
  • cada chamada de ferramenta: nome, argumentos, duração, recusa ou resultado resumido;
  • o texto final, tokens de entrada e saída, latência por etapa;
  • a decisão de recusa, se houve.

Sem versão de prompt, você não compara. Sem trecho, você não sabe se o RAG falhou na busca ou na geração. Sem ferramenta, o agente é um narrador. Sem tokens, o custo é lenda.

Ferramentas de trace de LLM existem e ajudam. O critério não é a marca. É se um humano, na terça, abre um caso de sexta e reconstrói o que o modelo viu. Se o sistema só guarda a frase final, a reconstrução é adivinhação.

Cuide do PII. Prompt e observação puxam e-mail, CPF, trecho de original inédito. Trace com retenção infinita e acesso largo é um segundo produto, não um detalhe. Mascarar, recortar, expirar. Observabilidade que vaza o acervo não é maturidade.

flowchart LR
  P[Prompt] --> T[Trace]
  R[Trechos] --> T
  F[Ferramenta] --> T
  T --> M[Métricas]
  M --> A[Amostra humana]
  A --> Q[Qualidade]
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class P,R,F ouro
  class T,M,A verde
  class Q fim

Métricas além do 200

Agrupe o que você mede em quatro gavetas. Misturá-las num único “score de IA” esconde a gaveta que está pegando fogo.

Software. Latência por etapa, taxa de timeout, de 5xx, de fallback, saturação de fila. Isto diz se o encanamento aguenta.

Custo. Tokens por rota, por usuário, por dia; passos de agente; chamadas de ferramenta pagas. Isto diz se o orçamento ainda existe.

Qualidade automática. Parser ok, recusa quando o índice volta vazio, acerto de trecho no conjunto de ouro, taxa de citação com id válido, “o juiz-modelo achou fiel”. Isto é útil e enviesado. Use como alarme, não como sentença.

Qualidade humana. Amostra semanal com rubrica: fato, tom, recusa, utilidade. Comentário livre num campo. Isto diz se o produto ainda é o que a casa prometeu.

Alarmes bons são relativos à rota. O p95 da geração síncrona não se compara ao do lote noturno. A taxa de recusa que sobe depois de um deploy de índice pode ser vitória (o sistema parou de inventar) ou derrota (o índice sumiu). O trace diz qual das duas. A métrica sozinha, não.

Reformulação é um sinal generoso. A pessoa pergunta de novo, com outras palavras, em menos de um minuto. Algo não serviu. Não é perfeito — pode ser curiosidade — mas correlaciona com falha de recuperação mais do que o 200.

Amostra humana sem virar comitê

Ninguém vai ler todas as respostas. Por isso a amostra precisa de desenho, não de culpa.

  • um pouco do tráfego recente;
  • um pouco do que o juiz automático marcou ruim;
  • um pouco do que o usuário marcou ruim, se o botão existir;
  • um pouco do irreversível: e-mails, alterações, textos que saíram em nome da casa;
  • um pouco aleatório, para não viciar no incidente.

Rubrica curta. Quatro eixos, nota 0 ou 1, um comentário. Fato correto. Tom da casa. Recusou quando devia. Serviu à pergunta. Se a rubrica tiver doze dimensões, a amostra morre na terceira semana.

Quem lê: alguém do ofício, não só de plataforma. Em livro, um editor pega o tom que o engenheiro deixa passar. Em suporte, quem atende pega a política que o dashboard não conhece. Rodízio curto. A hora semanal é operação, não “pesquisa de UX quando der”.

O destino da amostra não é um slide. É um cartão: prompt a corrigir, corte a mudar, ferramenta a estreitar, caso a entrar no conjunto de ouro. Observabilidade que não muda o sistema é arquivística.

Avaliação contínua não substitui o trace

O conjunto de ouro em todo deploy — o que pedimos em produção — pega regressão conhecida. Não pega a pergunta nova de terça. Trace e amostra pegam a pergunta nova. Os dois se alimentam: o caso feio da amostra vira item do conjunto; o item que falhou no conjunto aponta o trace do canário.

Modelos-juiz aceleram. Também alucinam em uníssono, sobretudo no tom. Use-os para filtrar o que o humano vê, não para substituir o humano no que a casa considera voz. Uma editora que deixa o juiz automático aprovar orelha está, na prática, publicando a média.

O mínimo que eu instalaria amanhã

  1. Trace por requisição com prompt, trechos, ferramentas e versões.
  2. Painel com latência, tokens, recusa e erro de parser por rota.
  3. Conjunto de ouro no pipeline de deploy, com porta: se cair demais, não sobe.
  4. Botão de “não ajudou” ligado ao id do trace.
  5. Uma hora semanal de amostra com rubrica de quatro eixos.
  6. Retenção curta e acesso restrito ao que o usuário escreveu.

Nada disso é sofisticado. Sofisticado é operar sem isso e chamar de produto. O HTTP 200 diz que houve resposta. A observabilidade de IA diz se a resposta merecia ter saído — e, quando não merecia, aponta o trecho, a ferramenta ou o prompt que a produziu. Sem nome do culpado, o próximo deploy é outra demo. Com nome, é ofício.

Medir o modelo depois do ar é o encerramento natural da AI One: produção sem amostra é só demo com uptime.

Leia também: IA em produção: latência, custo e rollback e Arquitetura depois dos LLMs.

#Observabilidade#LLM#Avaliação#Produção

Thiago Nogueira

Autor de A Caixa Mágica e das séries Programming One e AI One na Editora Pensar Bem.

Capa de AI One

AI One · Volume 10

LLMs, RAG, agentes e avaliação: o assistente que não pode inventar imposto.