Nossa leitura
Comece com tracing e um pequeno conjunto de evals em um único agente e, antes de escrever qualquer monitor, defina quem será acionado. A PagerDuty mostra o ciclo completo: monitor, acionamento de baixa urgência, ticket no Jira. Trate as pontuações de eval como um sinal técnico; nenhum dos casos analisados aqui prova um resultado de negócio.
Comece com um agente, um responsável e um limite
O Arize AX é uma plataforma para fazer tracing, avaliar e monitorar agentes de IA. Uma aplicação convencional ou dá erro ou não dá. Um agente pode devolver uma resposta fluente depois de escolher a ferramenta errada, então você precisa ver cada etapa e pontuá-la. É essa a função que o Arize descreve para o AX: traces de ponta a ponta, evals no nível de span, de trace e de sessão, e sinais de produção que apontam problemas.
Meu conselho é fazer um piloto com um único agente e resolver três questões antes de o primeiro monitor entrar em produção: quem é alertado, a partir de qual limite de qualidade e quem corrige. O exemplo da PagerDuty é o modelo mais claro, porque responde às três.
Traces: o que é capturado e quanto cabe em um plano
A documentação de integrações separa tracing de avaliação. O tracing cobre 16 provedores de LLM (entre eles OpenAI, Anthropic, Google GenAI e AWS Bedrock), frameworks de agentes em Python, TypeScript ou JavaScript, Java e .NET, dez agentes de código como GitHub Copilot, Cursor e Devin, e plataformas como Dify, Flowise e LangFlow. Também aparecem rotas OpenTelemetry: Arize OTEL, OpenLLMetry e OpenLIT.
O volume define o plano. A grade de preços lista o AX Free com 25.000 spans de trace por mês e 15 dias de retenção, e o AX Pro a 50 dólares por mês com 50.000 spans e 30 dias. O Enterprise tem volume e retenção sob medida e pode ser auto-hospedado. Evals, experimentos e anotações humanas aparecem como ilimitados em todos os níveis. Como uma única execução de agente gera muitos spans, estime em um teste quantos spans cada execução produz antes de escolher um plano.
Evals: juiz, ground truth e feedback humano
A PagerDuty, segundo o Arize, roda vários tipos de avaliação em seus agentes no PagerDuty Advance. Perguntas determinísticas, como os incidentes de ontem, são conferidas com uma ground truth. Um LLM juiz pontua etapas individuais: escolha de ferramenta, precisão dos parâmetros e relevância da resposta. Os usuários também avaliam as respostas com um polegar para cima ou para baixo no Slack, e cada avaliação fica ligada a um ID de span, para que a equipe possa reconstruir o trace por trás dela.
A TheFork avalia componentes específicos, em vez de tratar o sistema como uma caixa-preta: qualidade das chamadas ao LLM, correção dos guardrails, qualidade da recuperação, latência, uso de tokens e erros. Ela combina LLMs juízes com verificações baseadas em código e mira as fatias de tráfego com mais sinal, como os spans que ultrapassam limites de latência ou de guardrail. As evals online rodam continuamente, com uploads a cada hora e reprocessamentos direcionados. O tracing revelou chamadas de embedding duplicadas em um caminho crítico, e removê-las reduziu a latência p95, segundo o relato do Arize.
Alertas: do monitor ao acionamento e ao ticket
Na PagerDuty, quando uma métrica de qualidade das respostas ultrapassa um limite, o Arize envia um alerta para a PagerDuty. O engenheiro de plantão da equipe do agente recebe um acionamento de baixa urgência, e um workflow de incidentes cria um ticket no Jira para dar visibilidade e definir o responsável. Em seguida, o próprio SRE Agent da PagerDuty faz a triagem dos incidentes de IA: classifica se é preciso escalar para um humano e traz para o incidente o contexto dos padrões de falha do Arize.
Sobre quem corrige, o caso descreve um modelo distribuído. Engenheiros especializados em agentes atuam como especialistas internos e constroem ferramentas compartilhadas, engenheiros de software de toda a empresa constroem agentes sobre elas, e gerentes de produto revisam cada vez mais o comportamento dos agentes para encurtar os ciclos de feedback. Defina cedo qual desses papéis é responsável pelo ticket no Jira na sua organização.
Booking.com: coletar uma vez, anonimizar, encaminhar
A Booking.com opera dois caminhos. Os traces dos agentes seguem as convenções OpenTelemetry e OpenInference e passam por um coletor central de telemetria de IA, que faz a amostragem, remove trechos sensíveis e os envia ao Arize e aos sistemas de analytics. Os modelos de ML tradicionais alimentam logs de previsão a partir do data warehouse, com rótulos adicionados quando ficam disponíveis. Se os seus agentes lidam com dados pessoais, um coletor na frente da ferramenta de observabilidade é o desenho a copiar.
O Arize relata dois episódios. Em um, o monitoramento detectou um agente cuja latência saltou vários desvios-padrão acima da referência inicial; a causa era um novo experimento que usava outro modelo sem o nível de serviço adequado. No outro, durante a prototipagem de um agente de planejamento de roteiros, a contagem de tokens no P90 disparou e os turnos mais tardios tiveram pontuações menores nas evals de múltiplos turnos; links longos de atrações reinseridos no histórico da conversa estavam inchando o contexto. Segundo o relato, a equipe interveio antes de essa configuração chegar à produção. São casos relatados pelo fornecedor sobre uma única empresa, não um benchmark.
Pontuação de qualidade não é resultado de negócio, e o que as fontes deixam em aberto
Todos os resultados desses casos são sinais técnicos: latência, escolha de ferramenta, qualidade da recuperação, pontuações de eval. As fontes lidas aqui não ligam uma pontuação de eval a receita, conversão ou custo de atendimento, então faça essa ligação você mesmo, por exemplo comparando os resultados das evals com uma métrica de negócio que a sua equipe de produto já acompanha. É uma recomendação editorial, não um recurso do Arize.
Vale fechar uma lacuna antes da compra. A página de integrações lista integrações de tracing e de avaliação, mas nenhuma de alertas ou notificações, enquanto a PagerDuty descreve acionamentos e tickets no Jira. Confirme em um teste como um monitor chega às suas ferramentas de plantão e de tickets. As contagens de clientes no usedby mostram quem usa o Arize, não quão bem ele funciona.
Método e limites
2026-10-20
Este instantâneo datado conta empresas distintas nas evidências públicas de clientes. Confirmado significa um estudo de caso, um depoimento nominal ou uma fonte de imprensa; Declarado significa que a própria empresa informou ao usedby; Observado significa uma listagem do fornecedor; Sinal significa um anúncio de vaga. Os quatro contam, mas a força deles difere. Linhas removidas e sem nível ficam de fora. Os exemplos são uma seleção limitada, verificada nos últimos 90 dias. Os dados de fornecedores são registros com fonte, verificados nos últimos 60 dias. A cobertura é desigual, e a ausência de evidências significa desconhecido. Esses números não medem participação de mercado nem desempenho do produto; as datas de captura não são datas de adoção.
