O que é observabilidade de IA?

A resposta curta

Observabilidade de IA é conseguir reconstruir, depois do fato, exatamente por que um sistema produziu uma resposta específica para uma requisição específica. Não se ele respondeu, mas por que respondeu daquele jeito.

Em software convencional, uma requisição funcionou ou deu erro, e o erro em geral aponta a causa. Aqui, as falhas mais caras retornam HTTP 200 com uma resposta confiante, bem formatada e errada. Nada do seu monitoramento atual vai perceber.

Por que APM padrão não basta

Sua ferramenta atual acompanha latência, taxa de erro e vazão, e deve continuar fazendo isso. Mas os três podem estar perfeitamente saudáveis enquanto o sistema fica inútil em silêncio.

A recuperação passa a devolver documento errado: latência igual, erro nenhum. Uma mudança de prompt deixa as respostas mais vagas: erro nenhum. O fornecedor do modelo publica atualização e o comportamento muda: erro nenhum.

O sinal de que você precisa é sobre conteúdo, não sobre disponibilidade, e nenhum dashboard genérico vai produzir isso para você.

O que um trace precisa conter

Para qualquer requisição você deveria ver a entrada completa como foi montada, não o template mas o texto final de verdade com tudo interpolado. Os trechos recuperados e suas notas. O modelo e a versão. Os parâmetros. A saída bruta antes de qualquer pós-processamento.

Depois cada chamada de ferramenta: qual, com que argumentos, o que voltou, quanto tempo levou. E para execuções de vários passos, a sequência inteira com a decisão de cada ponto.

Se qualquer parte disso falta, depurar vira reconstrução de memória, e memória não é evidência.

Rastrear uma requisição de vários passos

Uma requisição pode virar uma dúzia de chamadas de modelo e um punhado de invocações de ferramenta. Sem um trace que amarre tudo a um identificador único, você tem uma pilha de linhas de log soltas e nenhuma forma de saber quais pertencem juntas.

Propague um id de requisição por tudo, inclusive pelas chamadas de ferramenta que saem do seu processo. Registre as relações de pai e filho para a sequência ser reconstruível na ordem.

Isso vira inegociável quando você introduz indireção, que é um dos trade-offs de adotar MCP: a capacidade fica mais limpa e a depuração atravessa mais sistemas.

Observabilidade de custo e token

Registre contagem de tokens por requisição, quebrada por quem consumiu: instrução, contexto recuperado, histórico, definição de ferramenta, saída. Agregue por feature e por cliente.

Duas coisas caem no colo na hora. Você descobre qual feature é de fato cara, que quase nunca é a que as pessoas supõem. E você pega loop desgovernado, porque uma tarefa que normalmente leva quatro passos e de repente leva quarenta aparece como pico de custo muito antes de alguém reclamar.

Sem essa quebra, otimizar custo é adivinhação. O enquadramento de orçamento está em quanto custa.

Sinais de qualidade em produção

Feedback direto é o mais barato e o mais enviesado: joinha, correção, nova tentativa. Um usuário que reformula a mesma pergunta duas vezes está te dizendo algo mesmo sem clicar em nada.

Melhores são os sinais implícitos. Taxa de escalonamento para humano. Abandono no meio da conversa. Com que frequência o sistema recusou. Com que frequência a resposta não citou fonte quando deveria.

E amostre tráfego real para revisão pontuada contra a mesma rubrica do seu conjunto de referência, o que conecta monitoramento de produção de volta a evals de LLM. Passar no conjunto de teste diz que você lida com os casos que conhecia. Só a amostragem fala dos que estão chegando agora.

Alertar nas coisas certas

Alerte em taxa e tendência, não em resposta ruim isolada, porque em sistema probabilístico uma resposta ruim é esperada e acionar por isso treina todo mundo a ignorar o alerta.

Os alertas que merecem existir: taxa de ancoragem caindo abaixo de um limiar, taxa de recusa se movendo forte para qualquer lado, escalonamento subindo, uso de token no p95 dando salto, recuperação devolvendo vazio ou nota baixa com mais frequência que o normal.

Cada um desses descreve um sistema mudando de caráter, que é aquilo por que você de fato quer ser acordado.

Depurar uma resposta ruim, na ordem

Comece pela recuperação. O material correto estava no que foi montado? Se não, a geração nunca teria como acertar e o modelo não é o problema.

Se o material estava lá, olhe o contexto montado. O trecho certo ficou enterrado sob nove irrelevantes, ou empurrado para além do ponto em que ainda pesava?

Só então olhe o prompt e o modelo. Essa ordem importa porque os times instintivamente começam pelo fim, ajustando instrução para corrigir um problema que nasceu três passos antes, e a correção parece funcionar até parar de funcionar.

O que construir primeiro

Trace completo de requisição, antes de qualquer outra coisa. Se você consegue puxar uma requisição e ver tudo que aconteceu, você consegue depurar. Todo o resto é refinamento em cima disso.

Depois quebra de token e custo, porque é barato de adicionar e muda decisão imediatamente. Depois amostragem de produção com pontuação. Depois alerta nas taxas derivadas.

Os times costumam fazer isso ao contrário, comprando dashboard antes de conseguir reconstruir uma requisição. Observabilidade não é ferramenta que se compra, é propriedade que se constrói junto, e é parte do que faz IA em produção, ponta a ponta ser algo que você consegue de fato operar.