LLMOps: como observar e avaliar sistemas de IA em produção

Por que observabilidade de IA não é observabilidade de infraestrutura

Porque os sinais são de natureza diferente: infra monitora recurso determinístico, IA monitora comportamento não determinístico. Em infraestrutura, o time acompanha CPU, memória, disco e latência de rede — grandezas com limiar claro de certo e errado. Uma aplicação de LLM é o oposto: a mesma pergunta pode gerar respostas diferentes, o custo varia por chamada e a qualidade pode cair sem que nenhum alarme de servidor dispare. São disciplinas vizinhas, com ferramentas e métricas distintas.

O que se observa em uma aplicação de IA

O que se observa é qualidade da resposta, custo por token, latência de geração e regressão de comportamento — não saúde de máquina. A pergunta central deixa de ser "o servidor está de pé?" e passa a ser "a resposta continua boa, dentro do custo e no formato certo?". Uma aplicação de LLM pode estar com infraestrutura perfeita — CPU tranquila, latência de rede baixa — e ao mesmo tempo entregando respostas piores, mais caras ou fora de política. Esses são sinais que nenhum gráfico de infraestrutura mostra.

Sinais determinísticos versus não determinísticos

A diferença de fundo é o determinismo. Um sinal de infraestrutura é determinístico: 90% de uso de CPU é 90% de uso de CPU, e o limiar de alerta é objetivo. Um sinal de IA é não determinístico: a "qualidade" de uma resposta não é um número que o sistema devolve — precisa ser medida contra critérios definidos. Por isso a observabilidade de IA depende de avaliação (evals), e não só de métricas cruas. É uma tabela útil para fixar o contraste:

O que compõe LLMOps

LLMOps trata a aplicação de IA como um sistema a ser operado, não como um "endpoint mágico". A disciplina reúne versionamento (de prompt e de modelo), monitoramento (tracing e métricas em produção), avaliação (evals de qualidade) e melhoria contínua (realimentar o sistema com casos reais)^[6]. O que a caracteriza é a combinação de não determinismo, dependência de prompt, custo variável por chamada e a necessidade de versionar o que antes era só texto solto. Operar IA em produção sem essa disciplina é dirigir sem painel.

Tracing de workflows de agentes

Tracing é registrar cada passo de um fluxo de IA de forma consultável — prompt enviado, contexto recuperado, chamada de ferramenta, resposta intermediária e resultado final. Em um agente multi-step, que encadeia várias decisões e ações, o tracing é o que permite entender por que o agente fez o que fez. Sem ele, o fluxo é uma caixa-preta: entra uma pergunta, sai uma resposta, e ninguém sabe o que aconteceu no meio.

O que é tracing de agentes de IA

É o registro passo a passo de um fluxo agêntico, do prompt inicial ao resultado final. Cada etapa vira um evento consultável: qual prompt foi enviado, que contexto foi recuperado por retrieval, qual ferramenta o agente chamou, que resposta intermediária recebeu e como chegou ao resultado. Em um fluxo de um único passo, isso é simples; em um agente que encadeia dezenas de chamadas e decisões, o tracing é a única forma de reconstruir o caminho. É o equivalente, para IA, do trace distribuído que a observabilidade de infra usa para seguir uma requisição entre serviços.

Por que sem tracing não se audita o agente

Porque a resposta final não revela como o agente decidiu. Quando um agente devolve algo errado, a pergunta é "em que passo isso saiu do trilho?" — e só o tracing responde. Sem o registro de cada etapa, a equipe fica reduzida a tentar reproduzir o problema no escuro, sem saber se a falha foi no prompt, no contexto recuperado, na ferramenta chamada ou na síntese final. O tracing transforma "o agente errou" em "o agente errou no passo 3, quando recuperou o documento errado" — a diferença entre adivinhar e diagnosticar.

Evals: a avaliação contínua de qualidade

Evals são testes que medem a saída do modelo contra critérios definidos — qualidade, aderência a política, formato, ausência de alucinação. São a peça central de confiabilidade em IA generativa e o que sustenta upgrades de modelo com segurança^[1]. A mensagem que organiza toda a disciplina é "evaluation-first": em IA, a avaliação de qualidade é o painel primário, não um relatório de auditoria produzido depois do incidente.

O que são evals de LLM

Eval é o teste que compara a saída do modelo com um critério de referência. Em vez de checar se o serviço respondeu, o eval checa se respondeu bem: a resposta está correta, no formato pedido, dentro da política, sem inventar informação? Montar evals começa por construir um dataset de referência — um conjunto de casos com a entrada e a saída esperada (ou o critério de aceitação). Esse dataset é o gabarito contra o qual cada versão do sistema é medida. Ele é o ativo mais valioso da operação de IA: quem tem bons evals consegue mudar o sistema com confiança; quem não tem, muda no escuro.

Eval offline versus eval em runtime

São dois momentos diferentes de avaliação. O eval offline roda antes do deploy, contra o dataset de referência, para decidir se uma nova versão pode subir. O eval em runtime roda em produção, por amostragem, avaliando saídas reais para flagrar queda de qualidade que só aparece com dados do mundo real. Os dois se complementam: o offline é o portão de entrada, o de runtime é a vigilância contínua. Confiar só no offline deixa a produção sem monitoramento; confiar só no runtime descobre o problema tarde demais, quando já chegou ao usuário.

Evals no CI/CD para pegar regressão

O ponto operacional central é rodar o conjunto de evals no pipeline antes de subir uma nova versão de prompt ou trocar de modelo. Mudança de prompt é mudança de código: precisa de teste automatizado, como qualquer alteração que vai para produção. Ao tornar os evals um gate no CI/CD, a regressão de comportamento é pega antes de chegar ao usuário — não depois, por reclamação. É a diferença entre descobrir que "a nova versão do prompt piorou as respostas" em um teste automatizado e descobrir isso pelo aumento de tickets de suporte.

Versionamento de prompt, custo e latência

Prompt é artefato de software e precisa ser versionado como código; custo e latência são as métricas de negócio e de experiência que completam o painel. Tratar o prompt como texto solto no código, o custo como surpresa no fim do mês e a latência como detalhe é o que separa uma operação de IA amadora de uma disciplina de LLMOps. As três dimensões precisam ser instrumentadas de propósito.

Versionamento de prompt como código

O prompt deve ser um artefato versionado, com histórico, autor, aprovação e capacidade de rollback. "Alguém mexeu no prompt e a qualidade caiu" só é rastreável e reversível se o prompt tiver versão — do contrário, a mudança se perde no meio do código e a regressão vira mistério. No menor porte, isso pode ser o prompt no repositório com mudança revisada em pull request; no maior, o prompt vira artefato de release com aprovação formal e rollback. O princípio é o mesmo: mudança de prompt é mudança que precisa de rastro.

Custo por token e atribuição de custo

Custo por token precisa ser instrumentado por chamada e atribuído a cada agente, fluxo ou time. Sem essa atribuição, a fatura de IA é um número agregado que ninguém consegue explicar nem otimizar. Vale deixar claro que o custo real de IA em produção vai além do preço do token: como referência de mercado, ele se decompõe em vários "baldes" — inferência, avaliação em runtime, observabilidade, infraestrutura de apoio e pessoas^[4]. É essa visão que sustenta o FinOps de IA — no maior porte, a atribuição por time/produto permite chargeback e controle real de orçamento.

Latência de geração como métrica de experiência

Latência de geração mede o tempo de resposta e é um sinal de experiência do usuário, separado da qualidade. Quando há streaming, o time-to-first-token — o tempo até o primeiro pedaço da resposta aparecer — importa tanto quanto o tempo total, porque define a percepção de rapidez. A separação entre latência e qualidade é deliberada: uma resposta rápida e errada não serve, e uma resposta certa mas lenta demais frustra. As duas métricas precisam ser lidas juntas, nunca uma no lugar da outra.

Regressão de comportamento e o fluxo evaluation-first

Regressão de comportamento é o risco central que a observabilidade de IA existe para pegar — e o fluxo evaluation-first é o roteiro que a mantém sob controle. É o tipo de falha que não aparece em nenhum gráfico de infraestrutura, porque não é o sistema que cai: é a qualidade que degrada. Instrumentar para detectá-la e reagir é o que mantém a IA confiável ao longo do tempo.

O que é regressão de comportamento em IA

Regressão é quando a mesma entrada passa a gerar uma resposta pior, fora de formato ou fora de política, depois de uma mudança de prompt ou de modelo. Diferente de uma falha de infra, nada "quebra": o serviço responde normalmente, só que pior. Uma troca de modelo por uma versão mais nova pode melhorar alguns casos e piorar outros; uma edição de prompt que resolve um problema pode criar outro. Sem evals comparando o antes e o depois contra o dataset de referência, essa piora passa despercebida até o usuário reclamar.

O fluxo evaluation-first na prática

O roteiro operacional encadeia os passos da disciplina em um ciclo contínuo. Na prática:

1. Instrumentar tracing em todos os fluxos, para tornar cada passo consultável.
2. Montar o dataset de evals a partir dos casos mais críticos do negócio.
3. Rodar os evals no CI/CD como gate antes de subir nova versão de prompt ou modelo.
4. Versionar o prompt com histórico, aprovação e rollback.
5. Monitorar custo, latência e qualidade em produção, por fluxo e por agente.
6. Realimentar o dataset com os casos reais que falharam, para o próximo ciclo pegar mais.

O ciclo se fecha em si mesmo: cada falha em produção vira um caso novo no dataset, que torna o gate mais rigoroso na próxima mudança. É assim que a operação de IA fica mais confiável com o tempo, em vez de acumular dívida.

Onde este tema encosta em governança e observabilidade de infra

Observabilidade de IA é o instrumento que a governança de agentes usa para verificar se o agente opera dentro do escopo — mas o foco aqui é a disciplina técnica de observar e avaliar qualidade e custo, não a governança em si. E vale a distinção explícita em relação à observabilidade de infraestrutura: monitorar logs, métricas e traces de servidores e serviços, e controlar o custo dessa observabilidade de infra, são temas vizinhos tratados à parte. Este artigo cobre a camada de cima — qualidade da resposta, não CPU e memória — e complementa aqueles sem repeti-los.