Observabilidade e avaliação de LLMs em produção

TL;DR

Em agentes em produção, observabilidade não é só registrar prompt e resposta: é acompanhar a trajetória completa, com chamadas de LLM, ferramentas, retrieval e estado, para entender onde a qualidade quebra. Em 2026, o ponto central é conectar essa telemetria a loops de avaliação offline e online, de preferência com padrões abertos como OpenTelemetry GenAI, para medir regressões sem criar lock-in.

O que muda quando o “produto” vira um agente

Um agente raramente falha em um único passo. Ele pode interpretar a intenção corretamente, chamar a ferramenta errada, recuperar contexto insuficiente, e ainda assim devolver uma resposta plausível. É por isso que observabilidade para agentes precisa ser pensada como trajetória, não como chamada isolada.

Na prática, isso significa modelar cada execução como uma árvore de eventos: decisão do modelo, uso de ferramenta, consulta a base vetorial, replanejamento e resposta final. Sem essa visão, uma métrica agregada de latência ou custo não explica o comportamento, e uma taxa de erro genérica não mostra em qual etapa o fluxo degradou.

O mínimo que você precisa capturar

• início e fim de cada run;
• tokens de entrada e saída por chamada;
• latência por etapa;
• nome e resultado das ferramentas;
• referências de retrieval e contexto usado;
• rastro de correlação entre traces, spans e avaliações.

A ideia é simples: se você consegue reconstruir a jornada do agente, você consegue explicar o erro. Se não consegue, você só enxerga sintomas.

OpenTelemetry como base de instrumentação

O avanço mais importante em 2026 é a consolidação de uma semântica GenAI em torno de OpenTelemetry. A proposta do ecossistema é registrar chamadas a modelos, invocações de ferramentas e trocas de tokens como telemetria correlacionável, com export para backends diferentes, em vez de amarrar tudo a um SDK fechado. Veja a referência oficial em OpenTelemetry: GenAI Observability.

Esse padrão ajuda em três frentes. Primeiro, reduz dependência de fornecedor. Segundo, permite integrar tracing com o restante da pilha de observabilidade que sua empresa já usa para serviços tradicionais. Terceiro, cria uma base comum para avaliações, porque o mesmo trace pode alimentar dashboards, alertas e pipelines de inspeção de qualidade.

Em fluxos de IA, a coleta de conteúdo completo pode exigir opt-in por sensibilidade e segurança. A documentação oficial de OpenTelemetry para GenAI destaca esse ponto e separa telemetria estrutural de captura de conteúdo.

Como pensar a telemetria

Em vez de anexar tudo a um único log, trate cada chamada como spans encadeados: agente principal, tool call, retrieval, re-rank, subprocesso de validação. Essa estrutura ajuda a responder perguntas operacionais simples, como “qual etapa está consumindo mais custo?” ou “em que ferramenta a taxa de falha começou a subir?”.

Outra vantagem é a compatibilidade com times que já operam observabilidade via APM. No contexto brasileiro, isso pesa bastante porque muitas empresas têm arquitetura híbrida, com sistemas legados, custos sensíveis em dólar e janelas de deploy curtas. Se sua telemetria de IA conversa com o stack já monitorado, você evita criar um silo caro de manter.

Evals offline, online e o ciclo de regressão

Observabilidade sem avaliação vira só visualização. O valor operacional aparece quando os traces alimentam avaliações contínuas. A documentação oficial do LangSmith separa offline evaluation e online evaluation, com avaliadores que podem ser humanos, regras, comparação pareada ou LLM-as-judge: LangSmith Evaluation.

O ponto não é escolher um único método. O ponto é combinar camadas. Offline eval vale para benchmark, comparação entre versões e construção de datasets de referência. Online eval serve para detectar regressões no tráfego real, em pequenas amostras, antes que o problema alcance uma fatia grande de usuários.

Quando usar cada camada

• Offline: validação antes do release, experimentos com datasets rotulados e comparação entre prompts ou modelos.
• Online: monitoramento em produção com sampling, para captar drift, alucinação recorrente e quedas de formato.
• Human review: amostragem de casos críticos, como fluxos financeiros, atendimento e decisões de risco.

Um detalhe importante na documentação do LangSmith é o uso de filtros e sampling para controlar o custo das avaliações online. Isso é especialmente útil quando você quer rodar LLM-as-judge em uma parte das execuções, em vez de avaliar 100% do tráfego. Em produção, esse recorte costuma ser suficiente para detectar regressões sem inflar demais a conta.

Ferramentas da stack: LangSmith, Langfuse, Phoenix e Datadog

O mercado de 2026 aponta para convergência em torno de tracing + avaliação. O Langfuse fornece uma base open-source para observability, tracing e evals, enquanto o SDK langfuse-js indica instrumentação integrada ao ecossistema OpenTelemetry. Já o projeto Arize Phoenix foca observabilidade e avaliação open-source para agentes e apps de IA.

Em outro eixo, a proposta do Datadog Agent Observability é fechar o circuito entre desenvolvimento, monitoramento e iteração, com avaliação em produção e geração de datasets a partir de traces anotados. Isso é útil para empresas que já operam uma plataforma central de observabilidade e querem estender o mesmo fluxo para IA.

O que essas ferramentas têm em comum é a tentativa de unir duas perguntas que antes ficavam separadas: “o que o agente fez?” e “o que isso significou em qualidade?”. Sem essa união, você vê custo e latência, mas não sabe se a resposta foi realmente adequada.

Leitura prática da stack

Se você está começando do zero, vale organizar a decisão assim: primeiro defina o padrão de telemetria, depois escolha o backend, e só então desenhe as avaliações. Se você fizer o inverso, é comum construir um processo de review sem dados suficientes, ou um tracing rico sem critério de aceitação.

Um caminho pragmático é usar OpenTelemetry como camada de instrumentação, armazenar traces em um backend compatível e alimentar evals com amostras dos casos mais sensíveis. Para times com orçamento em BRL e cobrança em dólar, essa separação também ajuda a controlar custo por etapa, porque você pode amostrar pesado onde faz mais sentido e reduzir captura onde o ganho marginal é baixo.

Como transformar traces em datasets de avaliação

Traces de produção são matéria-prima para datasets mais realistas do que coleções sintéticas. A documentação da Datadog descreve esse fluxo como construção de golden datasets a partir de traces anotados: Agent Observability. Em termos operacionais, isso significa identificar runs representativas, rotular o que foi correto ou incorreto e reutilizar esses exemplos em regressões futuras.

Esse ciclo é valioso porque o comportamento do agente muda com frequência. Trocar modelo, ajustar prompt, mudar ferramenta ou alterar política de retrieval pode melhorar um cenário e piorar outro. Golden sets ajudam a medir esse impacto com base em evidência real, e não só em impressão de uso interno.

Se o seu fluxo depende de versão específica de SDK, API ou CLI, revise o changelog oficial antes de levar o pipeline para produção. Em IA, detalhes de rastreamento e avaliação mudam rápido.

Por que importa pro dev brasileiro

No Brasil, o peso disso é maior por dois motivos concretos. O primeiro é regulatório: em aplicações com dados pessoais, a LGPD exige cuidado com coleta, retenção e finalidade, o que torna especialmente relevante a separação entre telemetria estrutural e captura de conteúdo sensível. O segundo é econômico: muitas empresas pagam serviços e modelos em dólar, então uma estratégia de sampling para evals e de captura seletiva de traces ajuda a controlar custo sem perder visibilidade.

Há também um fator operacional típico do mercado local. Times brasileiros frequentemente precisam integrar IA com sistemas legados, canais de atendimento e janelas de alteração curtas, o que aumenta o valor de uma observabilidade que se encaixe no stack já existente. Nesse cenário, adotar padrões abertos como OpenTelemetry faz diferença porque reduz retrabalho quando o time troca de backend, de ferramenta de eval ou de provedor de nuvem.

Um desenho de arquitetura que funciona

Uma arquitetura pragmática para agentes em produção pode seguir quatro camadas: instrumentação, armazenamento de traces, avaliação e feedback. A instrumentação gera spans e atributos; o backend organiza consultas e correlação; o sistema de avaliação roda regras e juízos automatizados; e o feedback volta para prompt, retrieval, política de ferramentas ou modelo.

• Instrumentação: OpenTelemetry GenAI para captura padrão.
• Backend: escolha compatível com time, orçamento e retenção.
• Avaliação: regras, heurísticas, human review e LLM-as-judge.
• Iteração: ajuste de prompt, ferramentas, roteamento e guardrails.

Esse desenho evita um erro comum: tratar observabilidade como postmortem. Para agentes, o ideal é que a mesma infraestrutura sirva para depuração, controle de release e monitoramento contínuo.

Conclusão

LLM observability e evaluation deixaram de ser acessórios e viraram parte do ciclo de entrega de agentes em produção. Em 2026, o caminho mais seguro é instrumentar com padrões abertos, avaliar com bases reais e criar um loop curto entre trace, diagnóstico e correção. Para quem trabalha no Brasil, isso ainda ajuda a equilibrar custo em dólar, exigências de privacidade e integração com o stack já existente.

Uma ação prática que você pode executar em até 1 hora: abra a documentação oficial do OpenTelemetry GenAI e desenhe um mapa de spans para o seu agente atual, identificando ao menos três pontos de instrumentação: chamada ao modelo, ferramenta externa e etapa de retrieval.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.