Observabilidade de features de IA: latência, custo e qualidade

A pergunta que mais trava time de plantão diante de uma feature de IA é simples e desconfortável: o sistema está funcionando? Em serviço tradicional, a resposta vem de latência e taxa de erro. Numa feature de LLM, os dois podem estar perfeitos enquanto a resposta entregue ao usuário está errada.

Três sinais em vez de um

Uma feature de IA precisa ser observada em três eixos simultâneos, e eles não se substituem.

Latência responde se o usuário esperou demais. Com geração de texto, a métrica útil não é só o tempo total: é o tempo até o primeiro token, porque é ele que determina a percepção de resposta quando há streaming.

Custo responde se a operação é sustentável. É o eixo que não existe em serviço tradicional e o que mais costuma ser descoberto tarde.

Qualidade responde se a resposta serviu. É o único dos três que não sai de contador de servidor, e é o que realmente importa.

Painel que mostra só os dois primeiros dá uma sensação de controle que não corresponde ao estado do sistema.

Padronize os atributos antes de inventar os seus

O OpenTelemetry mantém convenções semânticas específicas para sistemas de IA generativa, definindo nomes de atributo para operação, modelo solicitado, modelo respondido, contagem de tokens de entrada e saída, temperatura e motivo de parada.

Vale adotá-las mesmo que hoje você use uma única ferramenta. O custo de renomear atributo depois de ter seis meses de histórico é alto, e a padronização é o que permite trocar de backend de observabilidade sem reescrever instrumentação.

O detalhe que mais rende: registrar separadamente o modelo solicitado e o modelo que de fato respondeu. Fornecedor que aponta um alias para uma versão nova muda o comportamento da sua aplicação sem nenhum deploy do seu lado, e sem esse par de atributos a investigação começa no lugar errado.

Qualidade precisa de proxy, porque não tem contador

Como não existe um contador de "resposta boa", a qualidade é observada por aproximação. Quatro proxies funcionam bem na prática:

• Sinal explícito do usuário, o polegar para cima ou para baixo. Volume baixo, valor alto.
• Sinal implícito, como refazer a mesma pergunta, abandonar o fluxo, editar pesadamente o texto sugerido ou escalar para atendimento humano.
• Verificação automática do que é verificável: o JSON é válido, a citação existe na base, o valor está dentro do intervalo possível.
• Amostra revisada por humano, pequena, contínua e sempre com o mesmo critério.

Nenhum isolado basta. Juntos, eles detectam a degradação silenciosa que nenhum alarme de latência pegaria.

SLO para resposta que varia

O capítulo de SLO do livro de SRE do Google parte de uma ideia que se encaixa bem aqui: escolher poucos indicadores que representem a experiência do usuário e definir um alvo realista, não perfeito.

Para feature de IA, um conjunto inicial razoável é: tempo até o primeiro token abaixo de um limite em 95% das requisições; taxa de falha dura abaixo de um teto; taxa de reclamação ou refação abaixo de um teto; custo médio por interação abaixo de um valor.

O ponto do SLO não é o número bonito no painel. É ter um orçamento de erro que decide se a próxima mudança pode ser arriscada ou não. Sem isso, a discussão sobre subir uma versão nova de prompt vira disputa de opinião.

Custo pertence ao painel principal

Custo por interação, por rota e por usuário deve estar no mesmo painel que latência, não num relatório financeiro separado que alguém abre no fim do mês.

O motivo é operacional: uma mudança de prompt que dobra o contexto enviado aparece como um degrau no gráfico de custo no mesmo dia. Se esse gráfico só é olhado trinta dias depois, a correlação com o deploy já se perdeu.

Registre o suficiente sem virar passivo

Prompt e resposta contêm dado do usuário. Registrar tudo indefinidamente cria um passivo de privacidade que não compensa.

O meio-termo que funciona: sempre registrar os metadados, ou seja, versões, tokens, latência, custo e resultado da verificação automática; registrar conteúdo por amostragem, com retenção curta e acesso restrito; e sempre registrar conteúdo quando houve falha de verificação, porque é exatamente aí que a investigação precisa olhar.

O que isso significa para o seu time

Se a sua feature de IA já está em produção sem observabilidade dedicada, comece pelo mais barato: registrar versão de prompt, versão de modelo, tokens e custo em cada chamada, com os nomes de atributo do OpenTelemetry. É trabalho de poucas horas e muda a natureza da próxima investigação.

Depois escolha um proxy de qualidade e coloque no mesmo painel de latência. Um só, o mais fácil de coletar no seu produto.

O relatório DORA de 2025 reforça um ponto que vale fechar com ele: adoção de IA amplifica a capacidade que já existe. Time com boa observabilidade fica mais rápido com IA. Time sem observabilidade só descobre os problemas mais tarde, e com mais código para revisar.