Observabilidade para aplicações com LLM

A primeira feature com LLM que coloquei em produção tinha a mesma observabilidade do resto do serviço: logs de request, histogramas de latência, taxa de erro. Ficou tudo verde por uma semana enquanto a feature dava respostas cada vez piores em silêncio, porque o provedor tinha mudado algo do lado dele e nenhuma das minhas métricas enxergava qualidade. Observabilidade tradicional diz se o sistema está no ar. Para um modelo, estar no ar é a parte fácil. A pergunta é se ele está certo, e quanto custou estar certo, e os instrumentos para isso você tem que construir por conta própria.

O trace é a unidade

Para um request que passa por um modelo eu gravo o trace completo: o prompt final depois de toda a montagem, o contexto recuperado e suas fontes, cada chamada ao modelo com tokens de entrada e saída, a saída bruta antes do parsing, o resultado parseado, o resultado da validação, qualquer retry, e a latência total quebrada em segmentos. Não um resumo. As strings de verdade. Armazenamento é barato comparado à hora que você gasta adivinhando como estava o prompt quando um usuário reporta uma resposta ruim. Redija o que precisa ser redigido, guarde o resto, e defina uma política de retenção.

Quatro sinais além do uptime

Custo por request, em tokens, fatiado por feature e por tier de usuário, porque uma mudança de prompt pode dobrar a conta sem encostar na taxa de erro. Qualidade, medida por qualquer coisa que dê para medir automaticamente: validade do schema, taxa de acerto do retrieval, um modelo pequeno julgando saídas em uma amostra, feedback do usuário quando existe. Drift, ou seja, a distribuição de entradas e saídas ao longo do tempo, porque um modelo que começa a produzir saídas mais longas ou mais recusas está dizendo que algo mudou. E a taxa de fallback: com que frequência você serviu o caminho degradado em vez do modelo. Quando qualquer um desses se move, quero um alerta, e quero o trace que causou o movimento a um clique de distância.

Replay é a feature matadora

A capacidade mais valiosa que construí em cima desses traces é o replay. Pegue um trace armazenado, rode o mesmo prompt contra uma nova versão do modelo ou um novo template, e compare as saídas. Isso transforma "achamos que o prompt novo é melhor" em uma tabela de antes e depois sobre tráfego real. Também torna a resposta a incidentes possível: quando um usuário reporta uma resposta errada, eu não reconstruo, abro o trace, reproduzo, e vejo a falha. Replay exige que o trace tenha capturado tudo de que a chamada dependia, incluindo os resultados do retrieval e a versão do system prompt, então projete para isso desde o primeiro dia.

Amostragem e privacidade

Você não consegue julgar toda saída com um modelo, e não deveria guardar todo prompt para sempre. Eu amostro para pontuação de qualidade, com peso nos casos que importam: baixa confiança, retries, saídas longas, usuários novos. Faço hash dos identificadores de usuário e removo dados pessoais óbvios dos prompts armazenados antes de saírem do caminho do request. E deixo visível para o time que esses logs existem e o que tem neles, porque um sistema de observabilidade que guarda conversas de usuários em silêncio é um passivo esperando uma intimação.

Como é o dashboard

O meu tem custo por feature por dia, latência p50 e p95 com a chamada ao modelo separada, taxa de falha de validação, taxa de fallback, a pontuação da amostra de qualidade, e um fluxo dos traces com pior pontuação da última hora. Esse último painel é onde olho primeiro. Um modelo não falha fazendo barulho. Ele falha uma resposta de cada vez, educadamente, em frases completas, e o único jeito de ver é ir procurar.